Reporte y Remediación

El Reporte es el Producto Final

Por más impresionantes que sean tus habilidades técnicas, el cliente solo recibe una cosa tangible: el reporte. Es el entregable que justifica el engagement, comunica el riesgo y guía la remediación. Un pentest brillante con un reporte deficiente aporta poco valor; un pentest sólido con un reporte excelente transforma la postura de seguridad de la organización. Por eso, redactar bien es tan importante como hackear bien.

El reporte debe servir a múltiples audiencias. La dirección necesita entender el riesgo de negocio sin tecnicismos; los equipos técnicos necesitan detalle suficiente para reproducir y corregir cada hallazgo. Equilibrar ambos niveles de detalle es el arte del reporte profesional, y suele resolverse con una estructura por capas.

Un buen reporte también es atemporal: alguien que lo lea meses después, sin haber participado del engagement, debe poder entender qué se encontró, por qué importa y cómo solucionarlo. La claridad y la completitud son tus objetivos centrales.

Marco ético: el reporte contiene las debilidades del cliente. Entrégalo por canales cifrados, limita su distribución y enmascara datos sensibles en la evidencia.

Estructura de un Reporte Profesional

Un reporte de pentest bien armado suele incluir varias secciones, y cada una tiene una audiencia distinta. El resumen ejecutivo condensa los hallazgos clave, el nivel de riesgo general y las recomendaciones prioritarias en lenguaje accesible para la dirección. No debe contener jerga técnica innecesaria; su audiencia toma decisiones de inversión, no de configuración, y muchas veces es la única sección que leen los ejecutivos.

La sección de alcance y metodología documenta qué se testeó, cuándo, con qué enfoque y bajo qué reglas de engagement. Esto contextualiza los hallazgos, demuestra rigor y delimita responsabilidades: lo que quedó fuera de alcance no fue evaluado. Su audiencia natural es el responsable técnico del proyecto y cualquier auditor que revise el trabajo.

Luego viene el cuerpo técnico: los hallazgos detallados, cada uno con su descripción, severidad, evidencia, impacto y remediación. Esta sección la consumen los equipos de TI y desarrollo que van a corregir. Finalmente, los anexos reúnen datos crudos, listados de escaneo, metodología ampliada o información de soporte; sirven de referencia para quien quiera reproducir o auditar el detalle fino.

Esta estructura por capas permite que cada lector acceda al nivel de detalle que necesita. La dirección lee el resumen ejecutivo; el equipo de TI profundiza en los hallazgos; el auditor recurre a los anexos. Un índice claro y una numeración consistente facilitan la navegación de un documento que puede ser extenso.

Clasificación de Severidad y CVSS

Cada hallazgo debe llevar una severidad clara que comunique su urgencia. Las categorías habituales son crítica, alta, media, baja e informativa. La severidad debe basarse en una combinación de probabilidad de explotación e impacto potencial, idealmente respaldada por una puntuación CVSS v3.1 que dé consistencia y objetividad a la clasificación.

CVSS descompone el riesgo en métricas: el grupo Base describe las características intrínsecas de la vulnerabilidad, y se expresa como un vector legible. Por ejemplo, una inyección remota sin autenticación con impacto total suele verse así:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Ese vector se lee como vector de red (AV:N), baja complejidad (AC:L), sin privilegios (PR:N) ni interacción del usuario (UI:N), con impacto alto en confidencialidad, integridad y disponibilidad (C:H/I:H/A:H), y arroja un puntaje base de 9.8 — crítico. Además del grupo Base, CVSS ofrece las métricas Temporal (madurez del exploit, disponibilidad de parche) y Ambiental, que permiten reponderar según el contexto del cliente.

Es importante que la severidad refleje ese contexto real, no solo la puntuación genérica. Una vulnerabilidad crítica en un sistema aislado sin datos sensibles puede merecer una severidad ajustada hacia abajo mediante las métricas ambientales, mientras que una falla media en un sistema expuesto que procesa datos de clientes puede elevarse. Explicar el razonamiento detrás de cada severidad — y publicar el vector CVSS junto al puntaje — aporta transparencia y credibilidad.

Una severidad consistente permite al cliente priorizar su esfuerzo de remediación de forma racional. Si todo se marca como crítico, nada es crítico; la calibración honesta de la severidad es parte de tu profesionalismo y del valor que entregas.

Plantilla de Hallazgo Reutilizable

Un formato uniforme para cada hallazgo mejora la legibilidad y evita que se te escape información. Reutiliza esta plantilla como punto de partida y adáptala al cliente. Es un template de reporte, no un ataque: describe cómo documentar de forma estructurada lo que encontraste durante un engagement autorizado.

### [ID: PT-2026-001] Título breve y descriptivo del hallazgo

- **Severidad:** Crítica
- **CVSS v3.1:** 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
- **Activo afectado:** app.cliente.com (10.0.4.12), endpoint /api/v1/login

**Descripción**
Qué es la vulnerabilidad, en qué componente reside y por qué existe.
Explicá la causa raíz, no solo el síntoma.

**Impacto**
Qué puede lograr un atacante si la explota, en términos de negocio:
acceso a datos, compromiso de cuentas, interrupción del servicio.

**Pasos de reproducción**
1. Enviar una petición al endpoint afectado con el parámetro X.
2. Observar la respuesta Y.
3. Confirmar la condición Z que demuestra la debilidad.

**Evidencia**
Captura, fragmento de salida o petición/respuesta que lo demuestra.
Enmascará credenciales y datos personales antes de incluirlos.

**Remediación**
Acción concreta y accionable, con mitigación temporal si aplica.
Ej.: actualizar el componente X a la versión Y; validar el parámetro Z.

**Referencias**
- OWASP WSTG / ASVS: identificador correspondiente
- CWE-XXX, aviso del fabricante, CIS Benchmark relacionado

Un ID estable permite referenciar el hallazgo en el debrief, en el retesteo y en el seguimiento. Mantén los campos consistentes entre todos los hallazgos para que el cliente aprenda a leerlos de un vistazo.

Evidencia Clara y Reproducible

Cada hallazgo necesita evidencia que lo respalde: capturas de pantalla, fragmentos de salida de comandos, peticiones y respuestas, o pruebas de concepto. La evidencia transforma una afirmación ("este sistema es vulnerable") en un hecho verificable. Sin ella, el cliente no puede confirmar el problema ni convencer a sus propios equipos de actuar.

La evidencia debe ser reproducible: incluye los pasos suficientes para que el equipo técnico del cliente pueda confirmar el hallazgo por sí mismo. Al mismo tiempo, cuida los datos sensibles. Si una captura muestra credenciales o información personal, redacta o enmascara lo necesario para no exponer datos en un documento que circulará por la organización.

Mantén la evidencia proporcional. No necesitas volcar megabytes de salida cruda; basta con lo que demuestra el punto de forma inequívoca. Una evidencia bien elegida es más persuasiva que un anexo abrumador que nadie leerá.

Recomendaciones de Remediación por Estándar

La parte más valiosa de cada hallazgo es la recomendación de remediación. Encontrar problemas es útil; explicar cómo resolverlos es lo que justifica el engagement. Cada recomendación debe ser específica, accionable y realista para el entorno del cliente. "Parchear el sistema" es vago; "actualizar el componente X a la versión Y, o aplicar la mitigación Z mientras tanto" es accionable.

Vincular cada recomendación a un estándar reconocido refuerza su autoridad y facilita que el cliente la implemente. Estos son los marcos que conviene citar y cómo asociarlos:

• OWASP — para hallazgos de aplicaciones web, referencia la guía de testing WSTG (metodología de verificación) y el estándar ASVS (requisitos de seguridad por nivel). Ej.: "el hallazgo incumple ASVS V2.1 sobre autenticación".
• CIS Benchmarks — para configuraciones de sistemas operativos, servicios y nube, apunta al control específico del benchmark del producto (Linux, Windows, Kubernetes, etc.).
• NIST — para controles organizativos y de gestión, cita SP 800-53 o el Cybersecurity Framework cuando el hallazgo apunta a un proceso, no a un ajuste técnico.
• Recomendaciones del fabricante — enlaza el aviso de seguridad, la guía de hardening o el boletín de parches del vendor del componente afectado.

Al asociar cada recomendación con un identificador concreto del estándar (número de control, sección o CWE), le das al cliente un ancla verificable y trazable, en lugar de una opinión suelta.

Las buenas recomendaciones consideran el contexto operativo. A veces la solución ideal no es viable de inmediato, así que conviene ofrecer mitigaciones temporales además de la corrección definitiva. Cuando es posible, agrupa recomendaciones que abordan causas raíz comunes: si varios hallazgos derivan de una gestión deficiente de parches o de una falta de segmentación de red, señalar el problema sistémico aporta más valor que tratar cada síntoma por separado. Piensa en mejorar la postura de seguridad, no solo en tapar agujeros.

Cierre, Entrega Segura y Retesteo

El reporte se entrega de forma segura, ya que contiene información sensible sobre las debilidades del cliente. Cifrar el documento, usar canales protegidos y limitar su distribución a quienes deben conocerlo son prácticas estándar. Define una lista de destinatarios acotada, aplica cifrado extremo a extremo o al menos protección con contraseña fuera de banda, y evita enviar el reporte por correo sin proteger. La confidencialidad del entregable es parte del contrato, no un detalle opcional.

El debrief cierra la fase de comunicación: es una reunión donde recorres los hallazgos clave con el cliente, respondes preguntas y ayudas a priorizar. Su mecánica combina un repaso del resumen ejecutivo con la dirección y una sesión técnica más profunda con los equipos que van a remediar. Un buen debrief asegura que el mensaje se entienda y que se acuerden responsables y plazos para cada acción.

El valor del pentest se materializa en el seguimiento. Muchos engagements incluyen una fase de retesteo posterior para verificar que las remediaciones se aplicaron correctamente. Retestear cada hallazgo por su ID y documentar su estado — remediado, mitigado o pendiente — cierra el ciclo y demuestra el progreso tangible. Así, el reporte deja de ser un documento estático y se convierte en el motor de una mejora real y medible de la seguridad.

Checklist de Cierre de Calidad

Antes de entregar el reporte, verifica que cumple estos criterios:

• Claridad: cada sección se dirige a su audiencia y evita jerga innecesaria en el resumen ejecutivo.
• Evidencia reproducible: cada hallazgo incluye pasos que el cliente puede seguir para confirmarlo por su cuenta.
• Severidad calibrada: las severidades reflejan el contexto real, con puntaje y vector CVSS publicados y justificados.
• Remediación accionable: cada recomendación es específica, viable y está vinculada a un estándar reconocido.
• Datos protegidos: credenciales e información personal están enmascaradas en toda la evidencia.
• Entrega segura: el documento se cifra, se envía por canal protegido y su distribución está limitada.
• Seguimiento definido: hay un plan de retesteo y un mecanismo para documentar el estado de cada hallazgo.