Cómo se hackea de forma legal — pódcast

El hacking arrastra una estampa que no se le cae: un sótano, una capucha, una pantalla verde y alguien haciendo algo que es evidentemente ilegal. La realidad del oficio es bastante menos cinematográfica. Se ejerce a plena luz, con un contrato firmado de por medio, un alcance cerrado por escrito y una factura al final. Me invitaron a un episodio dedicado precisamente a esa pregunta: ¿bajo qué condiciones entrar en un sistema que no es tuyo resulta perfectamente legal?

El episodio está grabado en eslovaco. Lo que viene a continuación no es una transcripción, sino el desarrollo en español de la idea que lo vertebra, con el marco jurídico que se aplica en España.

La misma técnica, dos actos jurídicos distintos

Un test de intrusión consiste en examinar aplicaciones, infraestructuras y redes para encontrar los fallos antes de que los encuentre alguien con otras intenciones. Técnicamente no se distingue del ataque que imita: las mismas herramientas, las mismas cadenas de explotación, la misma cabezonería de probar la variante número catorce cuando las trece anteriores no han dado nada.

La diferencia no está en el teclado, está en el papel. Existe un encargo. Alguien que responde de esos sistemas ha pedido por escrito que se intenten romper, ha dicho cuáles, ha dicho cuándo y ha dicho hasta dónde. Ese documento no acompaña al trabajo técnico: lo constituye. Quítalo y lo que queda no es un test mal documentado, es otra cosa con nombre propio en el Código Penal.

Las tres condiciones que hacen lícito el trabajo

Son tres. Ninguna es opcional y ninguna se arregla después.

1. La autorización, previa y por escrito

El derecho español no castiga el hacking. Castiga hacerlo sin permiso, y lo dice con una fórmula que reaparece tipo tras tipo, casi con las mismas palabras:

• Art. 197 bis.1 — acceder a un sistema de información ajeno, o mantenerse en él, vulnerando las medidas de seguridad establecidas para impedirlo, «sin estar debidamente autorizado».
• Art. 197 bis.2 — interceptar transmisiones no públicas de datos informáticos, igualmente sin estar debidamente autorizado.
• Art. 197 ter — producir, adquirir o facilitar programas, contraseñas o códigos de acceso concebidos para cometer lo anterior.
• Arts. 264 y 264 bis — borrar, dañar o alterar datos ajenos y obstaculizar el funcionamiento de un sistema informático; el art. 264 ter, facilitar los medios para hacerlo.

Fíjate en dónde está la bisagra. El permiso no es una circunstancia que se pondere al final, cuando ya ha pasado todo: es el elemento que decide si hay delito o no lo hay. De ahí que la buena intención no funcione como defensa, y que «solo estaba mirando» tampoco.

De esa redacción salen dos consecuencias prácticas que se pasan por alto con demasiada frecuencia. La primera: el permiso lo da quien responde del sistema, no quien casualmente te abre la puerta. Si la aplicación corre sobre infraestructura de un tercero —un proveedor de cloud, un hosting, un SaaS—, hace falta comprobar qué permite ese contrato y, cuando toca, pedir también esa autorización. La segunda: los arts. 197 quinquies y 264 quater extienden la responsabilidad penal a las personas jurídicas. Encargar un test sobre sistemas de los que no se responde, sin la autorización de quien sí responde, no es solo un problema de quien ejecuta.

2. El alcance, que es el borde exacto del permiso

La autorización vale para lo que cubre y para nada más. Por eso el alcance no es burocracia previa: es el contorno de lo que está permitido, y todo lo que cae fuera vuelve a los artículos de arriba.

Un alcance que sirve nombra los sistemas, los dominios y los rangos de IP, el entorno —¿producción o preproducción?—, las ventanas horarias, las técnicas expresamente excluidas y las personas a las que avisar cuando algo se tuerce. Las pruebas de denegación de servicio, por poner el caso más claro, se excluyen salvo pacto expreso: obstaculizar el funcionamiento de un sistema tiene su propio tipo en el art. 264 bis, y no se cubre con un «hacedlo todo» genérico.

Salirse del alcance, aunque sea por curiosidad y aunque no se rompa nada, es salirse del encargo. De ahí que un documento firmado valga infinitamente más que un «adelante, mirad lo que queráis» dicho en una reunión: delimita el trabajo, sí, pero sobre todo protege a quien contrata tanto como a quien ejecuta.

3. La divulgación responsable

Un fallo encontrado se comunica. No se explota más allá de lo necesario para demostrar su impacto y no se guarda. Quien contrata recibe la prueba de concepto, los pasos para reproducirla y la recomendación de corrección; los datos recogidos durante el trabajo se devuelven o se destruyen según lo pactado. Si durante el test aparece una brecha de datos personales real —no la simulada: la que ya estaba ahí antes de que llegáramos—, el plazo de 72 horas del art. 33 del RGPD para notificar a la AEPD empieza a correr igual que con cualquier otro incidente, y conviene tener decidido de antemano quién abre el expediente interno.

Merece la pena ser claro con lo que ocurre fuera de un encargo, porque es la pregunta que más se repite cuando sale el tema. En España no existe un puerto seguro para quien investiga por su cuenta: avisar después no borra el acceso anterior, porque el tipo se consumó al entrar. Si te topas con algo en un sistema que no es tuyo, lo sensato es parar en ese punto, no seguir probando «para confirmar» y usar el canal que la propia organización publique —un fichero security.txt, una dirección de contacto de seguridad, un programa de divulgación—. Para vulnerabilidades de producto, INCIBE-CERT actúa como punto de coordinación y publica avisos de seguridad prácticamente a diario.

Qué gana la organización que lo encarga

Corregir antes del incidente, no después. El coste de una vulnerabilidad encontrada en un test es el de su corrección. El de esa misma vulnerabilidad encontrada por un atacante incluye la interrupción del servicio, el trabajo forense, la notificación y la conversación que hay que mantener con la clientela.

Una lectura que la herramienta sola no da. Un análisis de vulnerabilidades señala versiones afectadas por fallos conocidos y configuraciones débiles, y hace falta. Lo que no hace es entender tu lógica de negocio: no ve que cambiando un identificador en una petición se leen los pedidos de otra persona, ni que un flujo de recuperación de contraseña permite rodear el segundo factor. Dónde acaba una cosa y empieza la otra lo contamos en análisis de vulnerabilidades o pentest.

Una prueba oponible. El informe fechado es el documento que acaba pidiendo quien audita, un cliente grande o una aseguradora. El art. 32.1.d) del RGPD exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas», y una buena intención no es evidencia de nada. En el sector público —y en quien le vende— el Esquema Nacional de Seguridad añade además su auditoría ordinaria al menos cada dos años, en el art. 31 del RD 311/2022; qué exige de verdad ese decreto en materia de pentesting, con los códigos de medida delante, está en qué exige realmente el ENS.

Por qué el marco no es papeleo

Un sistema que se dio por seguro hace dos años no lo es necesariamente hoy: cambió una configuración, se actualizó una dependencia, se añadió una integración, entró un proveedor nuevo. Probar con regularidad, dentro de un marco definido, es la única manera de saber en qué punto estás en lugar de suponerlo.

Y el marco, insisto, no envuelve el trabajo técnico: lo define. Es lo que convierte un conjunto de actos idénticos en un servicio profesional y no en un delito, y es la parte del oficio que no admite improvisación por mucha prisa que traiga el calendario. Quien te ofrezca empezar mañana sin alcance firmado no te está haciendo un favor.

Preguntas frecuentes

Si lo que quieres es la versión aplicada a tus propios sistemas, eso es exactamente un test de intrusión: el mismo trabajo del que hablo en el episodio, con un encargo firmado, un alcance cerrado, un informe de hallazgos priorizados y una comprobación posterior de las correcciones. La conversación completa sobre el oficio está en el otro episodio sobre hacking ético.

Y si todavía estás en el paso anterior, el de decidir a quién encargárselo, aquí tienes las preguntas que conviene hacer antes de firmar y, para la duda que aparece siempre con un proveedor que no está establecido en España, qué dice realmente la normativa al respecto.

Nuestros servicios relacionados: pentesting y tests de intrusión de tus aplicaciones e infraestructuras · Red Team: una simulación de ataque realista