Tema 2
Una prueba de penetración solo es profesional cuando se realiza con autorización clara, límites definidos y responsabilidad sobre el impacto. La técnica ofensiva sin marco ético y legal deja de ser pentesting y se convierte en riesgo para todas las partes.
El pentesting usa técnicas que, fuera de un contexto autorizado, podrían considerarse intrusivas o ilegales. Escanear, enumerar, intentar validar una vulnerabilidad, acceder a un sistema de prueba o demostrar una debilidad no son actividades neutras: dependen del permiso, el alcance y el propósito.
Por eso, antes de hablar de herramientas o explotación, es imprescindible hablar de ética, legalidad y reglas de compromiso. Una prueba técnicamente correcta puede ser inaceptable si se ejecuta sobre un activo no autorizado, si expone datos innecesarios o si genera impacto operativo evitable.
Este tema explica qué debe existir antes de iniciar una prueba: autorización formal, alcance, límites, contactos, manejo de información, criterios de interrupción y responsabilidades de comunicación.
Tener conocimientos para encontrar una vulnerabilidad no significa tener derecho a probarla. En ciberseguridad ofensiva, la capacidad técnica siempre debe estar subordinada al permiso explícito y al alcance acordado.
Un profesional puede detectar un servicio expuesto, una aplicación vulnerable o una mala configuración. Sin autorización, no debe avanzar con pruebas activas sobre ese objetivo. Incluso una acción aparentemente simple puede generar registros, alertas, interrupciones o consecuencias legales.
La ética profesional en pentesting implica actuar de forma responsable aunque se tenga acceso a información sensible o a debilidades críticas. No basta con cumplir una lista mínima de requisitos legales: también hay que minimizar daño, respetar la confianza recibida y entregar valor defensivo.
Una persona puede tener intención de ayudar y aun así actuar ilegalmente si prueba sistemas sin autorización. Las leyes sobre acceso indebido, interceptación, daño informático, privacidad y protección de datos varían por país, pero suelen tener un punto común: acceder, alterar, interceptar o probar sistemas ajenos sin permiso puede traer consecuencias serias.
El pentesting profesional requiere autorización verificable del dueño del activo o de una persona con autoridad suficiente. En entornos corporativos, esa autorización debe estar respaldada por contrato, orden de trabajo, carta de autorización o documento equivalente.
| Situación | Riesgo | Conducta profesional |
|---|---|---|
| Encontrar una vulnerabilidad en un sitio público | Probarla sin permiso puede ser acceso indebido | Buscar un canal responsable de reporte o un programa autorizado |
| Un empleado pide probar un sistema interno | Puede no tener autoridad para autorizar la prueba | Validar autorización con responsables formales |
| Un dominio pertenece a un tercero o proveedor | El cliente puede no controlar ese activo | Excluirlo o pedir autorización específica del dueño |
| Una prueba puede afectar disponibilidad | Puede causar interrupción de negocio | Solicitar aprobación explícita y definir ventana controlada |
La autorización formal es la evidencia de que la prueba fue aprobada por quien corresponde. Debe existir antes de iniciar cualquier actividad activa sobre el objetivo. En un trabajo real, la autorización protege al cliente, al equipo técnico y a terceros que podrían verse afectados.
Una autorización útil debería incluir:
El alcance define qué se puede evaluar. Puede incluir dominios, direcciones IP, aplicaciones, APIs, redes internas, cuentas de prueba, repositorios, servicios cloud, entornos de desarrollo o segmentos específicos de infraestructura.
También debe indicar qué queda fuera. Esta parte es tan importante como la lista de activos incluidos, porque muchos incidentes durante pentests ocurren por asumir que un sistema relacionado también estaba autorizado.
Las reglas de compromiso, conocidas también como Rules of Engagement, describen cómo se ejecutará la prueba. Traducen la autorización y el alcance en condiciones operativas concretas.
Estas reglas evitan malentendidos durante la evaluación y sirven como referencia cuando aparece una situación no prevista.
| Regla | Qué define | Ejemplo |
|---|---|---|
| Ventanas de prueba | Cuándo se pueden ejecutar actividades | Solo fuera del horario comercial para pruebas de mayor carga |
| Intensidad | Nivel aceptado de escaneo o validación | Escaneos moderados, sin pruebas de denegación de servicio |
| Credenciales | Qué cuentas pueden utilizarse | Usuarios de prueba con roles definidos |
| Datos sensibles | Cómo se tratará la información encontrada | Registrar evidencia mínima y no descargar bases completas |
| Comunicación | A quién avisar ante hallazgos críticos o incidentes | Canal directo con responsable técnico y responsable de negocio |
No todas las técnicas de seguridad ofensiva tienen el mismo nivel de riesgo. Algunas son de bajo impacto, otras pueden afectar disponibilidad o confidencialidad si se aplican sin control. Por eso conviene clasificarlas antes de empezar.
La clasificación debe ser específica. Decir "se permite pentesting" es demasiado amplio. Es mejor indicar qué técnicas concretas se aceptan, bajo qué condiciones y con qué límites.
Durante una prueba pueden aparecer datos personales, credenciales, documentos internos, configuraciones, tokens, llaves, registros o información de clientes. El equipo evaluador debe tratar esa información con el mismo cuidado que tendría el dueño del sistema.
La comunicación evita que una prueba autorizada se confunda con un incidente real o que un hallazgo crítico quede sin atención. Antes de iniciar, deben definirse canales, responsables y tiempos de respuesta.
La comunicación puede dividirse en tres niveles:
También debe existir un procedimiento de pausa. Si una prueba genera impacto inesperado o se detecta actividad ajena sospechosa, el equipo debe saber a quién contactar y cuándo detenerse.
Según el objetivo de la prueba, el equipo defensivo puede estar informado o no informado. Ambas opciones son válidas si están acordadas. Si se busca evaluar detección y respuesta, puede limitarse la información compartida. Si se busca reducir riesgo técnico con mínimo impacto, conviene coordinar estrechamente con operaciones.
| Modelo | Características | Uso común |
|---|---|---|
| Informado | Defensa y operaciones conocen fechas, origen y alcance | Pentests técnicos con bajo riesgo operativo |
| Parcialmente informado | Algunos responsables conocen la prueba, otros no | Evaluaciones con componente de detección |
| No informado para defensa | Solo un grupo reducido sabe de la actividad | Ejercicios tipo red team, con autorización ejecutiva clara |
No todos los hallazgos deben esperar al reporte final. Si durante la prueba se descubre una exposición crítica, una credencial activa, un acceso administrativo indebido o una vulnerabilidad que pueda ser explotada de inmediato por terceros, debe comunicarse por el canal acordado.
Un aviso temprano debería incluir:
La explotación controlada sirve para demostrar impacto, pero debe tener límites. No siempre es necesario obtener el máximo privilegio posible o acceder al mayor volumen de datos para probar un riesgo. La validación debe detenerse cuando la evidencia ya demuestra el problema de forma suficiente.
La post-explotación también requiere autorización explícita. Acceder a sistemas internos, revisar rutas de privilegio, probar movimiento lateral o analizar datos disponibles puede ser útil, pero debe estar contemplado en el alcance y en las reglas de compromiso.
Muchos entornos modernos dependen de servicios externos: nube, CDN, proveedores de identidad, plataformas de correo, hosting, pasarelas de pago, sistemas SaaS y enlaces con socios. Que una organización use un servicio no significa que tenga permiso para probar toda la infraestructura del proveedor.
Cuando el objetivo incluye componentes de terceros, hay que verificar condiciones contractuales, políticas de uso aceptable y autorizaciones adicionales. Algunos proveedores permiten pruebas bajo reglas específicas; otros requieren notificación previa o limitan técnicas.
Antes de ejecutar la primera actividad activa, el proyecto debería tener documentación mínima. No es burocracia: es control de riesgo.
Una matriz simple ayuda a evitar ambigüedades. Puede adaptarse al tamaño del proyecto, pero siempre debe dejar claro qué se puede hacer y qué no.
| Elemento | Incluido | Condición | Restricción |
|---|---|---|---|
| Aplicación web principal | Sí | Pruebas con usuarios de laboratorio | No modificar datos reales |
| API pública | Sí | Rate limit acordado | No realizar carga masiva |
| Infraestructura de proveedor externo | No | Requiere autorización separada | No escanear rangos del proveedor |
| Ingeniería social | Condicionada | Solo con aprobación ejecutiva específica | No contactar clientes finales |
El pentesting no empieza con un escáner ni con una herramienta de explotación. Empieza con permiso, alcance, reglas claras y responsabilidad profesional. Esa base protege a las personas, a la organización y al propio valor técnico de la evaluación.
En el próximo tema estudiaremos metodologías profesionales como PTES, OWASP, NIST y enfoques basados en riesgo, que ayudan a organizar el trabajo de forma repetible, completa y orientada a resultados.