Un pentester hace lo mismo que un intruso: busca una forma de entrar y la utiliza. Las leyes sobre delitos informáticos de la mayoría de los países no preguntan por las intenciones. Preguntan si el acceso estaba autorizado. Toda la diferencia entre un servicio y un delito es un conjunto de documentos firmados por la persona adecuada antes de que empiece el trabajo.
Este artículo describe esos documentos. No es asesoramiento jurídico: la ley varía de un país a otro, y son sus abogados quienes deciden qué se le aplica a usted.
Los documentos
Contrato
El acuerdo comercial: qué se hace, en qué plazo, por qué importe, con qué responsabilidad y qué confidencialidad. El contrato por sí solo no es la autorización. Obliga a las partes entre sí; no establece por sí mismo qué se puede atacar.
Carta de autorización
La declaración con la que el propietario de los sistemas permite la prueba. Debe indicar:
- los sistemas, por dirección, dominio u otro identificador inequívoco;
- el periodo durante el que se permiten las pruebas;
- las personas o la empresa a las que se permite realizar las pruebas;
- la persona que firma y en calidad de qué firma.
Los pentesters la llevan consigo, en sentido literal o figurado, durante todo el proyecto. Cuando un proveedor de alojamiento o una autoridad policial pregunta qué está pasando, este es el documento que responde.
Reglas de enfrentamiento
Los límites técnicos: qué técnicas se permiten y cuáles se excluyen, el horario de las pruebas, la frecuencia de las peticiones, qué ocurre cuando un sistema se vuelve inestable, a quién llamar de noche. NIST SP 800-115 trata las reglas de enfrentamiento como una parte obligatoria de la planificación, y PTES las sitúa en la fase previa al proyecto por el mismo motivo: las cuestiones que no se resuelven antes de la prueba se resuelven durante un incidente.
Declaración de alcance
La lista de lo que está dentro y lo que está fuera. Las exclusiones importan tanto como las inclusiones: el proveedor de pagos que hay detrás del proceso de compra, la plataforma compartida de la empresa de alojamiento, el servicio de inicio de sesión único que pertenece a la empresa matriz.
Confidencialidad y protección de datos
Un acuerdo de confidencialidad (NDA), firmado antes de intercambiar detalles técnicos. Cuando puedan encontrarse datos personales, un contrato de encargo del tratamiento. En la Unión Europea, esto se deriva del artículo 28 del RGPD cuando el pentester trata datos personales por cuenta del cliente.
Quién puede firmar
La autorización vale lo que vale la autoridad de quien la firma.
- El propietario del sistema, no su usuario. Una empresa no puede autorizar pruebas de un producto SaaS al que está suscrita.
- Una persona facultada para obligar a la empresa. Un desarrollador que encarga una prueba del sistema de producción de su empleador sin que lo sepa la dirección no ha autorizado nada.
- Todos los propietarios, si hay varios. Un sistema que una empresa gestiona sobre la infraestructura de otra puede requerir la autorización de ambas.
Un proveedor cuidadoso lo verifica: consulta el registro mercantil, comprueba la propiedad de los dominios y confirma el encargo a través de un canal oficial de la empresa. Un proveedor que no pregunta debería preocuparle.
Terceros
Su autorización cubre lo que es suyo. A su alrededor suele haber sistemas que no lo son.
Proveedores de nube. Los grandes proveedores publican políticas para las pruebas de los recursos que los clientes ejecutan en sus plataformas. En el momento de escribir este artículo, AWS, Microsoft Azure y Google Cloud permiten a sus clientes probar sus propios recursos sin aprobación previa, dentro de las reglas que publica cada uno de ellos; AWS enumera además los servicios que se pueden probar. Todos ellos restringen las pruebas de denegación de servicio. Las políticas cambian, así que se consultan antes de cada proyecto y no se dan por sabidas del anterior.
Alojamiento y servicios gestionados. El alojamiento compartido, las bases de datos gestionadas y las redes de distribución de contenidos tienen sus propias condiciones. Algunos exigen aviso previo; otros prohíben las pruebas por completo.
Proveedores y socios. Una integración con un socio no extiende su autorización a la parte del socio. Sin el consentimiento por escrito del socio, las pruebas se detienen en el límite de lo que es suyo.
Las lagunas habituales
- La prueba ha empezado y la carta todavía «se está firmando».
- El alcance indica un dominio, y la aplicación que había detrás se trasladó a otra dirección el mes pasado.
- La carta la firma alguien que no tenía autoridad para firmarla.
- Producción está dentro del alcance y nadie ha avisado al equipo de operaciones.
- Se prueba una filial en otro país con la autorización de la matriz.
Cada una de ellas convierte una prueba autorizada en una no autorizada en una parte del trabajo, y ninguna es visible desde el lado técnico.
Un bug bounty también es una autorización
Un programa de bug bounty es una autorización otorgada en público: la política del programa indica qué se puede probar y cómo, y quien la cumple actúa con el permiso del propietario. Una cláusula de puerto seguro (safe harbour) añade el compromiso del propietario de no emprender acciones contra los investigadores que se mantengan dentro de la política. Solo obliga al propietario. No modifica el derecho penal ni obliga a terceros; por eso la política debe cumplirse al pie de la letra y por eso un sistema sin programa no es un objetivo.
En resumen
Antes de enviar el primer paquete debería haber un contrato, una carta de autorización firmada por alguien facultado para firmarla, unas reglas de enfrentamiento, un alcance con sus exclusiones y el consentimiento de cada tercero cuyos sistemas se vean afectados. Los detalles de cómo lo gestionamos están en la página Proceso de trabajo.