29. Elaboración de reportes: severidad, impacto, evidencia y recomendaciones
Un pentest solo genera valor si sus resultados se entienden y se convierten en decisiones. El reporte debe comunicar riesgos reales, evidencia suficiente, impacto para el negocio y recomendaciones que los equipos puedan aplicar, verificar y priorizar.
Objetivo
Aprender a construir reportes de pentesting claros, rigurosos y útiles para audiencias técnicas y ejecutivas.
Enfoque
Ordenar hallazgos por impacto, severidad, evidencia, causa, alcance afectado y acciones de remediación.
Resultado
Entregar informes que faciliten corrección, seguimiento, retesting y mejora de seguridad.
29.1 Introducción
El reporte es el producto final más visible de un pentest. Puede haber un trabajo técnico excelente detrás, pero si el informe es confuso, exagerado, incompleto o poco accionable, la organización tendrá dificultades para corregir. Un buen reporte traduce evidencia técnica en riesgo comprensible y decisiones concretas.
Reportar no es volcar capturas de pantalla ni listar herramientas usadas. Es explicar qué se encontró, por qué importa, cómo se comprobó, qué sistemas afecta, qué impacto podría tener y qué debe hacerse para reducir el riesgo.
29.2 Audiencias del reporte
Un informe de pentesting suele tener varias audiencias. La dirección necesita entender riesgo, impacto y prioridad. Los equipos técnicos necesitan evidencia, causa y pasos de remediación. Seguridad necesita patrones, debilidades de control y seguimiento. Legal o cumplimiento puede necesitar alcance, fechas y trazabilidad.
Por eso, el reporte debe separar niveles de detalle. Un resumen ejecutivo no debe depender de jerga técnica, y una sección técnica no debe ocultar información necesaria para corregir el problema.
29.3 Estructura recomendada
La estructura puede variar por organización, pero debe permitir navegar desde la visión general hasta el detalle técnico. Lo importante es que cada hallazgo tenga contexto, evidencia y recomendación.
| Sección | Propósito | Audiencia principal |
|---|---|---|
| Resumen ejecutivo | Explicar riesgo, impacto y prioridades | Dirección y responsables de negocio |
| Alcance y metodología | Delimitar qué se probó y cómo | Seguridad, auditoría y gestión |
| Hallazgos técnicos | Documentar vulnerabilidades y evidencia | Desarrollo, infraestructura y seguridad |
| Recomendaciones | Orientar corrección y priorización | Equipos responsables de remediar |
| Anexos | Agregar datos complementarios | Equipos técnicos y cumplimiento |
29.4 Resumen ejecutivo
El resumen ejecutivo debe responder qué tan expuesta está la organización, cuáles son los riesgos principales, qué activos o procesos críticos se ven afectados y qué acciones deberían priorizarse. No necesita detallar cada petición HTTP ni cada comando usado.
Debe evitar alarmismo y minimizar ambigüedades. Frases como “riesgo alto de acceso no autorizado a datos de clientes por controles de autorización incompletos” son más útiles que “la aplicación es insegura”.
29.5 Alcance, supuestos y limitaciones
El reporte debe indicar qué fue evaluado: dominios, aplicaciones, APIs, redes, cuentas, roles, entornos, fechas, ventanas de prueba y restricciones. También debe mencionar qué no fue probado y por qué, para evitar interpretaciones incorrectas.
Las limitaciones no son excusas; son contexto. Si no se probó producción, si no hubo credenciales de ciertos roles o si una ventana fue reducida, esos datos ayudan a entender el nivel de cobertura y el riesgo residual.
29.6 Metodología
La metodología describe el enfoque general: reconocimiento autorizado, modelado de superficie, pruebas autenticadas y no autenticadas, validación manual, revisión de configuración, análisis de impacto, coordinación defensiva y documentación de evidencia.
No es necesario revelar detalles operativos sensibles que no aportan a la remediación, pero sí debe quedar claro que el trabajo fue sistemático, autorizado y alineado con el alcance.
29.7 Anatomía de un hallazgo
Cada hallazgo debe poder entenderse de forma independiente. Si un desarrollador recibe solo ese apartado, debería comprender qué ocurre, dónde, por qué es un problema, cómo se comprobó y qué cambio se espera.
- Título claro y específico.
- Severidad y justificación.
- Activo, endpoint, recurso o componente afectado.
- Descripción del problema.
- Impacto técnico y de negocio.
- Evidencia mínima suficiente.
- Causa probable o debilidad de control.
- Recomendación concreta.
- Referencias o criterios de verificación.
29.8 Severidad
La severidad expresa la prioridad del riesgo. Debe considerar impacto, probabilidad, exposición, facilidad de explotación, privilegios requeridos, datos afectados, controles existentes y contexto del negocio. No debe asignarse solo por el nombre de la vulnerabilidad.
Una misma falla puede ser crítica en un sistema de pagos y media en una aplicación interna aislada. El reporte debe explicar esa diferencia para que la prioridad sea defendible.
29.9 Uso de CVSS y escalas internas
CVSS puede ayudar a estandarizar la severidad técnica, pero no reemplaza el criterio. Algunas organizaciones combinan CVSS con criticidad del activo, exposición externa, requisitos regulatorios y datos afectados.
Si se usa CVSS, se debe incluir el vector o una justificación resumida. Si se usa una escala interna, el reporte debe explicar qué significa crítico, alto, medio, bajo e informativo para esa organización.
29.10 Impacto técnico e impacto de negocio
El impacto técnico describe qué puede ocurrir en sistemas: acceso no autorizado, modificación de datos, ejecución de acciones, exposición de secretos, escalamiento de privilegios o interrupción. El impacto de negocio conecta eso con consecuencias: fraude, pérdida de confianza, incumplimiento, afectación operativa o exposición de clientes.
La calidad del reporte mejora cuando ambos niveles se relacionan. “Permite leer registros de otros usuarios” es técnico; “puede exponer información personal de clientes y generar incumplimiento de privacidad” traduce el riesgo para la organización.
29.11 Evidencia suficiente y responsable
La evidencia debe demostrar el hallazgo sin ampliar el daño. Puede incluir capturas, solicitudes y respuestas, logs, IDs de prueba, timestamps, roles utilizados, configuraciones observadas o capturas de consola. Debe enmascarar datos personales, secretos y valores sensibles.
El objetivo no es llenar páginas de pruebas repetidas, sino aportar una demostración clara, reproducible y segura. Cuando el hallazgo afecta datos reales, se debe usar la mínima muestra autorizada.
29.12 Reproducibilidad
Un hallazgo reproducible permite a los equipos validar la corrección. El reporte debe indicar condiciones necesarias: rol, cuenta de laboratorio, endpoint, flujo, configuración, entorno, fecha y resultado esperado.
No siempre es apropiado incluir instrucciones explotables detalladas en un documento amplio. En esos casos, se puede separar evidencia sensible en anexos restringidos o sesiones técnicas con los responsables de remediación.
29.13 Causa raíz
Identificar causa raíz evita parches superficiales. Una autorización rota puede originarse en ausencia de controles centralizados, pruebas insuficientes, diseño incorrecto de roles o deuda técnica en endpoints antiguos.
Cuando el reporte solo indica “corregir endpoint X”, el problema puede reaparecer en otro módulo. Cuando explica la causa, permite aplicar patrones de remediación en toda la aplicación o plataforma.
29.14 Recomendaciones accionables
Una recomendación accionable dice qué cambiar, dónde aplicarlo y cómo validar que funciona. “Mejorar seguridad” no sirve. “Aplicar autorización por objeto en todos los endpoints que acceden a recursos de cliente y agregar pruebas automatizadas por rol” es mucho más útil.
Las recomendaciones pueden dividirse en corrección inmediata, mejora estructural y control preventivo. Esto ayuda a actuar rápido sin perder de vista la causa profunda.
29.15 Priorización
No todos los hallazgos pueden corregirse al mismo tiempo. La priorización debe considerar severidad, exposición, facilidad de abuso, criticidad del activo, esfuerzo de corrección, dependencias y existencia de mitigaciones temporales.
Un reporte útil agrupa acciones: correcciones urgentes, mejoras a corto plazo, deuda técnica a planificar y recomendaciones estratégicas. Así facilita decisiones y no deja al equipo con una lista plana de problemas.
29.16 Lenguaje claro y precisión
El lenguaje debe ser claro, preciso y verificable. Evita afirmaciones absolutas si no hay evidencia suficiente. Es mejor decir “se observó acceso no autorizado al recurso X con la cuenta Y” que “cualquier atacante puede comprometer toda la empresa” si eso no fue demostrado.
También se deben evitar juicios personales. El reporte evalúa sistemas, procesos y controles, no culpa a individuos. Esa neutralidad ayuda a que los equipos acepten el hallazgo y trabajen en resolverlo.
29.17 Hallazgos informativos
Los hallazgos informativos no representan una vulnerabilidad directa, pero aportan contexto: banners expuestos, versiones visibles, cabeceras ausentes de bajo impacto, documentación pública o configuraciones que podrían combinarse con otros riesgos.
Deben reportarse sin inflar severidad. Si todo se marca como alto, el reporte pierde credibilidad. La severidad baja o informativa también tiene valor cuando ayuda a mejorar higiene y reducir superficie.
29.18 Anexos técnicos
Los anexos permiten incluir información complementaria sin saturar el cuerpo principal: lista de activos evaluados, hashes de evidencia, capturas adicionales, versiones, pruebas no explotables, reglas de detección o referencias metodológicas.
Si el anexo contiene datos sensibles, debe tener distribución restringida. No todo lector del resumen ejecutivo necesita acceso a detalles que podrían facilitar abuso o revelar secretos.
29.19 Reporte de detección y respuesta
Cuando el pentest incluye coordinación defensiva, el reporte debe indicar qué actividades fueron registradas, alertadas, bloqueadas o investigadas. También debe incluir tiempos de detección, calidad de alertas, brechas de logging y oportunidades de mejora.
Esta información conecta el trabajo del tema anterior con el cierre del proyecto. Una vulnerabilidad corregida reduce riesgo; una detección mejorada reduce el tiempo de exposición si algo similar ocurre en el futuro.
29.20 Manejo seguro del reporte
Un reporte de pentesting es información sensible. Debe almacenarse, transmitirse y distribuirse con controles adecuados. Puede contener rutas internas, nombres de activos, capturas, configuraciones, debilidades y datos que no deben circular sin necesidad.
Es recomendable definir destinatarios, clasificación, cifrado, repositorio, retención y eliminación. También se debe evitar enviar evidencia sensible por canales informales o adjuntar secretos completos en documentos de amplia circulación.
29.21 Plantilla de hallazgo
Una plantilla consistente mejora lectura y seguimiento. Cada organización puede adaptarla, pero debería cubrir los campos necesarios para entender y corregir.
| Campo | Contenido esperado |
|---|---|
| Título | Descripción breve del problema y componente afectado |
| Severidad | Nivel y justificación basada en impacto y contexto |
| Descripción | Qué ocurre y cuál es la debilidad de control |
| Impacto | Consecuencia técnica y de negocio |
| Evidencia | Prueba mínima, enmascarada y reproducible |
| Recomendación | Acción concreta de corrección y validación |
29.22 Reunión de presentación
La entrega del reporte debería incluir una reunión de cierre. Allí se explican hallazgos críticos, prioridades, dudas técnicas, limitaciones, riesgos aceptados y próximos pasos. Esta reunión evita malentendidos y acelera la remediación.
Conviene preparar dos niveles: una presentación ejecutiva breve y una sesión técnica más profunda con los equipos que corregirán. Mezclar ambos niveles en una sola conversación puede dejar a todos con información insuficiente.
29.23 Errores frecuentes
Un error común es reportar demasiados detalles sin explicar impacto. Otro es exagerar severidad para llamar la atención. También es frecuente entregar recomendaciones genéricas, no indicar alcance, omitir limitaciones o no proteger adecuadamente el reporte.
El reporte debe ser exigente, pero justo. Si la evidencia no demuestra un impacto, se debe decir. Si un hallazgo depende de condiciones específicas, se deben aclarar. La precisión aumenta confianza y facilita corrección.
29.24 Qué debes recordar
Un buen reporte une técnica y decisión. Describe el problema con precisión, justifica la severidad, muestra evidencia responsable, explica impacto y propone acciones verificables. Su éxito se mide por la capacidad de la organización para corregir y reducir riesgo.
La claridad no significa simplificar en exceso. Significa dar a cada audiencia el nivel de detalle que necesita para actuar sin perder rigor.
29.25 Conclusión
La elaboración de reportes es una habilidad central del pentesting profesional. Sin un informe claro, el trabajo técnico queda aislado. Con un informe bien construido, los hallazgos se transforman en prioridades, correcciones, controles y aprendizaje organizacional.
En el próximo tema cerraremos el ciclo del pentest: remediación, retesting y plan de mejora continua, donde el reporte se convierte en seguimiento y reducción sostenida del riesgo.