Encontrar una vulnerabilidad puede contribuir a mejorar la seguridad de una organización. Sin embargo, utilizarla sin autorización, superar los límites acordados o acceder a información que no formaba parte de una prueba puede generar consecuencias técnicas, contractuales, éticas y jurídicas.
La diferencia entre el hacking ético y una conducta potencialmente ilícita no depende únicamente de los conocimientos, las herramientas o la intención declarada por quien realiza la actividad.
El elemento central es la autorización.
Un profesional puede tener una intención defensiva y utilizar técnicas reconocidas de seguridad; pero si actúa sin permiso o por fuera del alcance acordado, la actividad deja de estar claramente respaldada por la organización responsable del sistema.
Surge entonces una pregunta fundamental para la ciberseguridad contemporánea:
¿Dónde termina una prueba de penetración legítima y comienza el acceso no autorizado?
El hacking ético no significa autorización ilimitada
El hacking ético puede entenderse como la utilización autorizada y controlada de conocimientos, metodologías y herramientas de seguridad ofensiva para identificar vulnerabilidades antes de que sean aprovechadas por actores maliciosos.
Su finalidad puede incluir:
Evaluar la seguridad de una infraestructura.
Identificar vulnerabilidades técnicas.
Comprobar la eficacia de los controles.
Analizar configuraciones inseguras.
Simular determinadas acciones de un adversario.
Medir la capacidad de detección y respuesta.
Proponer medidas de mitigación.
Fortalecer la gestión del riesgo.
Sin embargo, la expresión “hacking ético” no constituye por sí misma un permiso para intervenir cualquier sistema.
Tampoco basta con afirmar que la actividad buscaba ayudar. La legitimidad de una prueba depende de que exista una autorización válida y de que las acciones realizadas respeten las condiciones establecidas.
¿Qué establece la legislación colombiana?
En Colombia, la Ley 1273 de 2009 incorporó al Código Penal disposiciones relacionadas con la protección de la información y de los datos.
El artículo 269A regula el acceso abusivo a un sistema informático y contempla el acceso realizado sin autorización o por fuera de lo acordado.
Esta redacción contiene dos situaciones especialmente relevantes para el hacking ético:
Acceder sin contar con autorización.
Tener algún tipo de autorización, pero superar lo que fue expresamente acordado.
El texto oficial también puede consultarse en la Secretaría Jurídica del Senado de la República.
Esto permite comprender que la discusión no se limita a determinar si existía un contrato o un permiso general. También debe revisarse si la persona respetó el alcance, las técnicas, los activos, los horarios, las restricciones y los objetivos aprobados.
La valoración jurídica de una situación concreta corresponde a las autoridades competentes y requiere estudiar sus circunstancias particulares. No obstante, desde la gestión de una prueba de seguridad, resulta evidente que la autorización debe ser clara, demostrable y suficientemente detallada.
Tener permiso no significa poder hacer cualquier cosa
Una organización puede autorizar la evaluación de una aplicación web, pero eso no implica necesariamente que el profesional pueda intervenir:
Los servidores de producción.
Las cuentas de clientes.
La infraestructura de un proveedor.
Los sistemas conectados de otra empresa.
Las aplicaciones móviles.
El correo corporativo.
Los mecanismos de respaldo.
Los servicios alojados en la nube.
Los dispositivos personales de los empleados.
Las redes inalámbricas.
Las instalaciones físicas.
Cada uno de estos elementos puede tener propietarios, responsables, condiciones contractuales y riesgos diferentes.
También puede existir autorización para identificar vulnerabilidades, pero no para explotarlas hasta obtener información confidencial, modificar datos o afectar la disponibilidad del servicio.
Por eso, una prueba de penetración profesional no debería iniciar con la pregunta “¿qué herramientas vamos a utilizar?”, sino con preguntas como:
¿Quién tiene autoridad para aprobar la prueba?
¿Cuáles activos están incluidos?
¿Cuáles están excluidos?
¿Qué técnicas se encuentran autorizadas?
¿Qué información podría consultarse?
¿Hasta dónde puede demostrarse una vulnerabilidad?
¿Cuándo debe detenerse la prueba?
¿Cómo se reportará un incidente?
¿Quién asumirá la coordinación durante una emergencia?
La importancia de las reglas de compromiso
El Instituto Nacional de Estándares y Tecnología de Estados Unidos, NIST, define las reglas de compromiso o Rules of Engagement como las directrices y restricciones detalladas que regulan la ejecución de una prueba de seguridad.
Estas reglas se establecen antes de comenzar y proporcionan al equipo evaluador la autoridad para desarrollar actividades previamente definidas. La definición oficial puede consultarse en el glosario de NIST sobre Rules of Engagement.
La guía NIST SP 800-115: Technical Guide to Information Security Testing and Assessment también ofrece recomendaciones para planificar, ejecutar y documentar evaluaciones técnicas de seguridad.
Un documento de reglas de compromiso debería establecer, como mínimo:
Identificación de las partes.
Responsable que autoriza la prueba.
Objetivo de la evaluación.
Activos incluidos.
Activos excluidos.
Direcciones IP, dominios y aplicaciones autorizadas.
Fechas y horarios.
Técnicas permitidas.
Técnicas prohibidas.
Límites de explotación.
Manejo de datos personales y confidenciales.
Procedimiento ante hallazgos críticos.
Canales de comunicación.
Contactos de emergencia.
Criterios para suspender la prueba.
Conservación y eliminación de la información obtenida.
Estructura y destinatarios del informe.
Obligaciones de confidencialidad.
Las reglas de compromiso protegen a la organización, al equipo evaluador, a los usuarios y a los terceros que podrían verse afectados.
Escenarios en los que puede superarse el alcance
1. Acceder a otro servidor mediante una vulnerabilidad
Un profesional está autorizado para evaluar una aplicación específica y descubre credenciales que permiten acceder a un servidor diferente.
Aunque técnicamente sea posible utilizar esas credenciales, hacerlo podría superar el alcance si el segundo servidor no estaba autorizado.
La actuación prudente consiste en documentar el hallazgo, proteger la información y solicitar una ampliación formal antes de continuar.
2. Consultar información real de clientes
Durante una prueba se identifica una vulnerabilidad que aparentemente permite acceder a datos de clientes.
No siempre es necesario descargar toda la base de datos para demostrar el riesgo. Puede ser suficiente obtener la mínima evidencia técnica necesaria, detener la explotación y comunicar el hallazgo.
Acceder masivamente a información personal o conservarla sin necesidad puede aumentar el impacto y generar nuevos riesgos.
3. Realizar ingeniería social sin autorización
Una evaluación técnica de una aplicación no autoriza automáticamente el envío de correos de phishing, llamadas engañosas o intentos de obtener credenciales de empleados.
La ingeniería social necesita autorización expresa, definición de los grupos participantes, protección de los trabajadores y procedimientos para manejar los resultados.
4. Probar un proveedor externo
Una empresa puede contratar servicios en la nube o utilizar plataformas de terceros, pero esto no significa que pueda autorizar unilateralmente cualquier ataque contra la infraestructura del proveedor.
Deben revisarse los contratos, políticas y procedimientos aplicables al servicio externo.
5. Continuar después de encontrar un incidente real
Si durante la prueba aparece evidencia de un ataque activo, fraude, fuga de información o compromiso no relacionado con el ejercicio, el equipo no debería improvisar.
Debe activar el canal de escalamiento definido, conservar la información necesaria y coordinar con los responsables de respuesta a incidentes.
La metodología no reemplaza la autorización
Existen marcos técnicos reconocidos para evaluar la seguridad. La OWASP Web Security Testing Guide reúne buenas prácticas para realizar pruebas sobre aplicaciones y servicios web.
La versión estable OWASP WSTG 4.2 organiza pruebas relacionadas con:
Estas metodologías ayudan a establecer qué evaluar y cómo documentarlo, pero no conceden permiso para intervenir un sistema.
Una herramienta legítima puede utilizarse de manera incorrecta. De igual forma, una técnica ampliamente aceptada puede resultar indebida si se aplica contra un activo no autorizado.
La metodología aporta rigor técnico; la autorización aporta legitimidad al ejercicio.
Principio de mínima intervención
Una prueba responsable debería buscar demostrar el riesgo con el menor impacto posible.
Este principio implica:
No acceder a más información de la necesaria.
Evitar cambios permanentes.
No destruir ni alterar datos.
No afectar deliberadamente la disponibilidad.
No conservar información sensible sin justificación.
Detenerse cuando el riesgo ya ha sido demostrado.
Solicitar autorización adicional antes de ampliar la explotación.
Documentar las acciones realizadas.
La habilidad de un profesional no se demuestra causando el mayor impacto posible. Se demuestra identificando el riesgo, controlando la prueba, protegiendo la información y produciendo recomendaciones útiles.
Divulgación responsable de vulnerabilidades
Otra situación frecuente ocurre cuando una persona descubre una vulnerabilidad en un sistema sin haber sido contratada para evaluarlo.
Encontrar accidentalmente un posible problema no autoriza a explotarlo, acceder a información, modificar datos ni mantener presencia dentro del sistema.
Una actuación responsable puede incluir:
Detener la actividad.
No descargar ni divulgar datos.
Conservar únicamente la información mínima necesaria.
Revisar si la organización dispone de una política de divulgación.
Utilizar el canal oficial de seguridad.
Explicar el hallazgo de manera prudente.
Evitar publicar detalles que faciliten su explotación.
Esperar instrucciones antes de realizar nuevas pruebas.
Los programas de recompensas o bug bounty tampoco constituyen autorizaciones ilimitadas. Cada programa establece activos incluidos, vulnerabilidades aceptadas, técnicas prohibidas y condiciones de reporte.
Participar en uno exige leer y respetar esas reglas.
¿Qué papel cumple la ética profesional?
Cumplir formalmente un contrato no agota la responsabilidad del profesional.
El hacking ético también demanda principios como:
El profesional debe reconocer sus propias limitaciones. Si una prueba requiere conocimientos, herramientas o capacidades que no posee, debería informarlo y evitar actuaciones improvisadas.
También debe comunicar con honestidad:
Un informe de seguridad no debería exagerar los hallazgos ni presentar posibilidades teóricas como compromisos confirmados.
Inteligencia artificial y ampliación del riesgo
La inteligencia artificial está facilitando tareas como:
Reconocimiento de superficies de ataque.
Análisis de código.
Generación de pruebas.
Clasificación de vulnerabilidades.
Automatización de consultas.
Elaboración de informes.
Correlación de resultados.
Sin embargo, la automatización también puede ejecutar acciones a mayor velocidad y escala. Un agente podría consultar activos equivocados, generar solicitudes no previstas o continuar una secuencia de explotación sin comprender completamente sus consecuencias.
Por eso, utilizar inteligencia artificial no elimina la responsabilidad de quien dirige la prueba.
Antes de incorporar herramientas autónomas o semiautónomas deben establecerse:
Sistemas autorizados.
Acciones permitidas.
Controles humanos.
Límites de ejecución.
Registro de actividades.
Protección de la información enviada al modelo.
Procedimientos de interrupción.
Validación humana de los hallazgos.
La autonomía tecnológica no debería superar la autorización humana y organizacional.
¿Dónde está realmente el límite?
El límite entre hacking ético y acceso no autorizado no se encuentra únicamente en la herramienta utilizada ni en la intención afirmada por el evaluador.
Se encuentra en la relación entre:
Una prueba legítima debe poder responder claramente:
¿Quién autorizó esta acción, sobre cuál sistema, durante qué periodo, con qué finalidad y bajo cuáles restricciones?
Si la respuesta no puede demostrarse, la organización y el profesional se encuentran ante un riesgo innecesario.
Reflexión final
El hacking ético cumple una función fundamental: permitir que las organizaciones conozcan sus debilidades antes de que sean aprovechadas por actores maliciosos.
Pero la capacidad técnica debe estar acompañada de límites.
La autorización no puede asumirse. El alcance no puede interpretarse de manera ilimitada. Las herramientas no sustituyen el juicio profesional y una buena intención no corrige automáticamente una actuación realizada por fuera de lo acordado.
Por eso, el verdadero profesional de seguridad no solamente sabe cómo encontrar una vulnerabilidad. También sabe cuándo detenerse, cómo documentarla, a quién comunicarla y hasta dónde puede llegar.
La ética comienza precisamente donde la capacidad técnica encuentra un límite responsable.
Sobre el autor
César Antonio Villamizar Núñez – TriHacker
Ingeniero de Sistemas, CISO en Ciberseguridad, investigador, docente, informática forense, evidencia digital, hacking ético, innovación y liderazgo académico.
Este artículo forma parte de una línea de reflexión académica y profesional relacionada con la construcción de un marco ético y legal para el hacking ético en pruebas de penetración.
El contenido tiene una finalidad educativa y de divulgación. No constituye asesoría jurídica ni reemplaza el análisis particular realizado por un profesional del derecho o por las autoridades competentes.
Fuentes consultadas
