Qué debe decir una carta de autorización antes de una prueba de intrusión

Lo esencial

• Sin autorización del dueño del sistema, una prueba de intrusión (también llamada prueba de penetración o pentest) es un acceso ilícito. Lo castigan los artículos 211 bis 1 a 211 bis 7 del Código Penal Federal cuando el sistema está protegido por algún mecanismo de seguridad.
• La firma quien puede obligar a la empresa dueña del sistema. Si el servidor es de un proveedor de hospedaje o de nube, hace falta además su permiso o su política escrita.
• La carta dice qué se prueba y qué no, cómo, cuándo, desde dónde, quién responde de cada lado y qué pasa con los datos que se vean.
• No sustituye al contrato de servicios ni al acuerdo de confidencialidad. Va con ellos.

Por qué hace falta

El Código Penal Federal castiga a quien «sin autorización conozca o copie información contenida en sistemas o equipos de informática protegidos por algún mecanismo de seguridad» con tres meses a un año de prisión y de cincuenta a ciento cincuenta días multa, y a quien sin autorización la modifique, destruya o provoque su pérdida, con seis meses a dos años (artículo 211 bis 1). Una prueba de intrusión hace exactamente eso: entra, lee y a veces modifica. Lo único que la separa de un ataque es la autorización. La ley no pide que sea por escrito; la carta es la forma de probar que existió y hasta dónde llegaba.

Las penas suben si el sistema es del Estado (artículo 211 bis 2) o de una institución del sistema financiero (artículo 211 bis 4), y aumentan hasta en una mitad cuando la información se usa en provecho propio o ajeno (artículo 211 bis 7). El artículo 211 bis 3 castiga incluso a quien, estando autorizado para entrar a sistemas del Estado, modifica, destruye, hace perder o copia indebidamente la información que contienen; el 211 bis 5 hace lo mismo con los del sistema financiero. De ahí que la carta tenga que decir con precisión qué se autoriza: lo que quede fuera de ella se hace sin autorización.

Los estándares del oficio la piden antes de empezar. NIST SP 800-115 dedica su apéndice B a una plantilla de reglas de la prueba y pide que la firmen el líder del equipo que prueba y la dirección de la organización probada. PTES dice que la prueba no empieza hasta que el cliente firma el documento de permiso. Y los proveedores de nube la exigen: Microsoft no autoriza en nombre de sus clientes y pide que el tercero que prueba tenga autorización escrita del dueño del recurso; Amazon Web Services hace responsable al cliente de lo que haga el tercero que contrató.

Quién la firma

La empresa dueña del sistema, por medio de quien tenga facultades para obligarla: normalmente el representante legal. El documento debe decir su nombre y su cargo, y conviene guardar con la carta una copia del poder o del acta que le da esas facultades. El desarrollador que hizo el sistema, el encargado de sistemas o un gerente de área pueden ser el contacto técnico de la prueba, pero no quienes autorizan.

Firman las dos partes: quien autoriza y quien va a probar. Así las dos saben a qué se comprometen y qué queda fuera.

Si el sistema corre en servidores de un tercero, la firma del cliente no alcanza. PTES lo dice sin rodeos: el cliente no habla por sus proveedores. Cada proveedor tiene sus reglas:

• Amazon Web Services permite probar sin aviso previo una lista de servicios (entre ellos EC2, RDS, CloudFront, API Gateway, Lambda y Elastic Beanstalk) y prohíbe las pruebas de denegación de servicio, reales o simuladas, las inundaciones de peticiones, el secuestro de DNS por medio de Route 53 y la toma de subdominios. Para otros servicios hay que acordarlo antes con su soporte o con el representante de cuenta.
• Microsoft no exige aviso para probar recursos de Azure desde 2017, pero obliga a seguir sus reglas de la prueba, que prohíben la denegación de servicio, el uso de credenciales ajenas y la ingeniería social, contra el personal de Microsoft o desde sus servicios contra cualquier otro.
• En hospedaje compartido, el servidor es del proveedor y lo comparten otros clientes. Revise sus términos de servicio y pida su permiso por escrito; si no lo da, la prueba se limita a lo que el proveedor permita, y en todo caso solo encuentra fallas de la aplicación, no del servidor que la aloja.

Qué debe decir

Las diez cosas que siguen salen de la plantilla y la sección de planeación de NIST SP 800-115, de la guía de preparación de PTES y de nuestra práctica; lo que el punto 9 dice sobre datos personales sale de la ley mexicana. Una carta que las tenga todas cabe en dos páginas.

1. Las partes y la finalidad. Quién autoriza, a quién, y para qué: una prueba de intrusión, con qué objetivo.
2. El alcance, activo por activo. Dominios, direcciones IP, aplicaciones, redes y cuentas que entran, y una lista de lo que queda fuera. NIST la llama lista de exclusión. Antes de empezar, quien prueba comprueba que cada activo es de verdad del cliente.
3. Lo permitido y lo prohibido. La modalidad (caja negra, gris o blanca), si se pueden explotar las fallas o solo demostrarlas, y lo que no se hace salvo autorización expresa: denegación de servicio, ingeniería social, acceso físico. También si se pueden crear archivos o cuentas en los sistemas y qué pasa con ellos al terminar.
4. Los riesgos. La carta reconoce que una prueba puede provocar inestabilidad y dice qué cuidado se tendrá para evitarla y qué se hace si ocurre. PTES pide además que diga que el cliente no hará responsable a quien prueba de las caídas que ocurran pese a ese cuidado; en este modelo, esa cláusula va en el contrato de servicios.
5. Fechas, horarios y vigencia. Los días y las horas en que se puede probar (fuera del horario de más uso, de noche o en fin de semana, si el sistema está en producción), y la fecha en que la autorización vence.
6. Desde dónde. Las direcciones IP desde las que se va a probar, para que el cliente distinga la prueba de un ataque real en sus registros.
7. Quién responde de cada lado y cómo se avisa. Un contacto responsable y uno alterno por parte, con dos vías de localización inmediata a cualquier hora; cómo se comunican los hallazgos críticos (en cuanto se confirman, nunca después del mismo día); el criterio para detener la prueba si algo falla y quién autoriza reanudarla.
8. Los terceros. Qué proveedores operan los sistemas, qué permiso o política aplica a cada uno, quién lo gestiona y a quién se avisa en el proveedor si aparece una falla que afecte a otros clientes suyos.
9. Los datos y la confidencialidad. Quien prueba no copia datos personales: demuestra el acceso con capturas de la estructura, no de los registros. Si durante la prueba se accede a datos personales, el proveedor los trata por cuenta de la empresa; la Ley Federal de Protección de Datos Personales en Posesión de los Particulares llama a esa figura persona encargada (artículo 2, fracción XII) y la empresa sigue siendo responsable de que respete su aviso de privacidad (artículo 13). La carta dice también qué evidencia se guarda de cada acción (fecha y hora, quién la hizo, desde qué equipo, contra qué sistema, con qué herramienta y qué comando), cómo se transmite y almacena cifrada, cuánto tiempo se conserva y cómo se destruye.
10. Cambios y firmas. Cualquier cambio de alcance se acuerda por escrito y lo firma quien firmó la carta. Al final, nombre, cargo, fecha y firma de las dos partes, y una copia para cada una. Si alguien pregunta quién autorizó la prueba, esa copia es la respuesta.

Qué no sustituye

La carta es el permiso. El precio, los entregables, los plazos y la responsabilidad de cada parte van en el contrato de servicios. El detalle de qué información es confidencial y por cuánto tiempo va en el acuerdo de confidencialidad. El permiso del proveedor de hospedaje o de nube es aparte y lo gestiona el cliente, porque la cuenta es suya; la carta deja constancia de que se pidió y de qué contestó el proveedor. Y la carta tampoco hace inofensiva la prueba: por eso incluye los riesgos y los contactos.

Un ejemplo

Así se ve una carta con todo lo anterior. La empresa, las personas y las direcciones son inventadas.

Guadalajara, Jalisco, 3 de noviembre de 2026. Ejemplo, S.A. de C.V., representada por su director general, autoriza a Noxcom a realizar una prueba de intrusión sobre el portal de clientes en portal.ejemplo.com.mx, la API en api.ejemplo.com.mx y los servidores con direcciones 203.0.113.10 y 203.0.113.11, alojados en la cuenta de Amazon Web Services de la empresa. Quedan fuera el sistema de nómina y cualquier dirección no listada.

La prueba será de caja gris, con dos cuentas de usuario que la empresa entregará el primer día, del 10 al 21 de noviembre de 2026, de lunes a viernes entre las 22:00 y las 06:00. No se harán pruebas de denegación de servicio ni de ingeniería social. Noxcom podrá explotar las vulnerabilidades que encuentre para demostrarlas, sin alterar ni copiar datos de clientes; el acceso se probará con capturas de la estructura, no de los registros.

Las pruebas se harán desde las direcciones 198.51.100.20 y 198.51.100.21. Responde por la empresa su directora de sistemas y por Noxcom el responsable de la prueba, con los teléfonos y correos que se anexan. Los hallazgos críticos se comunicarán en cuanto se confirmen, el mismo día. Si el servicio se degrada, la prueba se detiene y se reanuda solo con el visto bueno de la directora de sistemas.

La empresa entiende que una prueba de este tipo puede causar inestabilidad y Noxcom pondrá el cuidado necesario para evitarla. Esta autorización vence el 21 de noviembre de 2026; cualquier cambio de alcance se acordará por escrito y lo firmarán las mismas personas. Se firma junto con el acuerdo de confidencialidad de la misma fecha, en dos ejemplares, con nombre y cargo de quienes firman.

Cómo lo hacemos en Noxcom

Mandamos este modelo con la propuesta y no empezamos ninguna prueba hasta tener la carta y el acuerdo de confidencialidad firmados por las dos partes. Entregamos por adelantado las direcciones desde las que probamos. Y si el sistema lo construyó o lo mantiene Noxcom, la prueba se autoriza aparte, con su propia carta.

Fuentes

• Código Penal Federal, texto vigente (Cámara de Diputados)
• Código Penal Federal, artículo 211 bis 1 (mLey)
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, apéndice B
• PTES, Pre-engagement Interactions
• Amazon Web Services, Penetration Testing
• Microsoft, Penetration testing en Azure
• Ley Federal de Protección de Datos Personales en Posesión de los Particulares, texto vigente (Cámara de Diputados)