La diferencia entre una prueba de seguridad y un delito informático suele ser un papel firmado. Las técnicas son las mismas; lo que cambia es que alguien con autoridad sobre el sistema dijo que sí, y dijo exactamente qué, cuándo y cómo. Por eso las conversaciones previas a la primera prueba importan tanto como la prueba misma.
La autorización escrita
Tiene que venir de quien tiene potestad real sobre lo que se va a probar. Parece obvio, pero falla seguido: un desarrollador que autoriza la prueba de un sistema que hospeda su cliente, o un área que habilita algo que corre en infraestructura de otra. Si el sistema es de un cliente, la autorización es del cliente, no tuya. Si está en un servidor compartido, hay que contemplar a los demás que lo usan.
El documento debería nombrar a las partes, describir qué se autoriza, indicar el período y estar firmado por alguien con capacidad de decidir. Guardalo. Ante cualquier duda posterior, es lo que respalda a quien probó y a quien contrató.
Sobre las consecuencias de probar sin permiso, hablemos en general: acceder a sistemas ajenos sin autorización puede tener consecuencias legales serias, aunque la intención sea buena y aunque no se haya dañado nada. Si tenés dudas sobre tu situación concreta, consultá con un profesional del derecho.
Qué entra y qué no
El alcance es la lista concreta de lo que se puede probar. Cuanto más precisa, mejor.
- Dominios y subdominios específicos, no "el sitio".
- Rangos de direcciones IP, si corresponde.
- Aplicaciones web, aplicaciones móviles y APIs, con sus ambientes (producción, preproducción).
- Tipos de prueba permitidos: solo aplicación, también red, también ingeniería social.
Igual de importante son las exclusiones. Un servicio de pagos de un tercero, un sistema heredado frágil, el correo de la dirección: todo lo que no deba tocarse tiene que estar escrito. Lo que no figura en la lista no se prueba, aunque parezca relacionado y aunque aparezca en el camino. Si durante el trabajo surge algo interesante fuera del alcance, se avisa y se pide ampliar el acuerdo; no se explora por cuenta propia.
También se acuerdan las técnicas excluidas. Muchos equipos prohíben las pruebas de denegación de servicio sobre producción, o los ataques que puedan bloquear cuentas de usuarios reales. Es razonable, y conviene dejarlo por escrito.
Ventanas de tiempo y contactos
Las pruebas pueden generar carga, alertas y algún comportamiento extraño. Acordá en qué días y horarios se hacen, desde qué direcciones de origen se va a probar y a quién se avisa. Si tu equipo de operaciones o tu proveedor de hosting ve tráfico raro y no sabe que es una prueba, puede bloquearla, o peor, activar una respuesta a incidentes innecesaria.
Definí también un contacto de emergencia con teléfono, disponible durante la ventana. Si algo se cae o se encuentra una falla grave que esté siendo explotada por alguien más, hay que poder avisar de inmediato en vez de esperar al informe final. Y establecé qué pasa si hay un efecto no deseado: quién decide detener la prueba y cómo se retoma.
Tratamiento de los datos
Una prueba exitosa suele terminar viendo datos reales: registros de clientes, correos, documentos. Hay que acordar hasta dónde se llega. Una práctica sensata es demostrar el acceso con la mínima evidencia posible (por ejemplo, un registro o un campo parcialmente ocultado) y no descargar volúmenes.
Conviene dejar claro:
- Qué datos pueden verse y cuáles no deben tocarse.
- Cómo se guarda la evidencia durante la prueba y cuánto tiempo.
- Quién puede acceder a ella y cómo se destruye al terminar.
- Cómo se comunican los hallazgos, por un canal cifrado y no por correo común.
Si el sistema trata datos personales, hay obligaciones de protección que no desaparecen porque el acceso sea parte de una prueba. Otra razón para consultar con un especialista legal.
Terceros y proveedores
Tu aplicación probablemente corre sobre servicios que no controlás: un proveedor de nube, una pasarela de pagos, un servicio de correo. Cada uno suele tener su propia política sobre qué pruebas se pueden hacer contra su infraestructura, y algunos exigen aviso previo. Tu autorización cubre lo que es tuyo, no lo de ellos. Revisá las condiciones publicadas por cada proveedor antes de definir el alcance, y probá contra tu configuración y tu código, no contra la plataforma que los aloja.
Un acuerdo claro protege a todos. Quien contrata sabe qué se hizo, quien prueba sabe hasta dónde llegar, y si algo sale mal, el camino a seguir ya está escrito.