Escribe tu primer informe de seguridad que la gente leerá

La mayoría de los primeros informes de seguridad fracasan de una manera predecible: conservan el proceso del tester. Después, el lector debe reconstruir el riesgo. Y el informe queda sin terminar. La legibilidad es un control de seguridad porque determina si un hallazgo llega a la persona que puede solucionarlo.

Comienza un informe de seguridad con la decisión. Separa la consecuencia ejecutiva de la prueba técnica. Verifica manualmente cada hallazgo. Proporciona a cada responsable una solución concreta. Después, edita para garantizar precisión, claridad y coherencia antes de entregarlo. La función del informe es impulsar la acción, no servir como diario de tus pruebas.

Primero, identifica a las personas que deben actuar y diseña el recorrido del lector. Escribirás un hallazgo de principio a fin y elegirás las pruebas. Después, editarás por fases y realizarás una comprobación de contradicciones antes de enviarlo.

En este artículo

• Los informes fracasan cuando el lector tiene que hacer el análisis
• Decide quién debe actuar antes de escribir
• Coloca la decisión al principio y conserva debajo la evidencia
• Escribe cada hallazgo para que un desconocido pueda entenderlo y actuar
• La evidencia debe demostrar la afirmación, no decorar la página
• Edita por fases porque se supone que el primer borrador debe ser malo
• Evita los atajos que hacen que un informe no sea fiable
• Ejecuta esta lista de comprobación final antes de enviar

Los informes fracasan cuando el lector tiene que hacer el análisis

Un informe puede ser técnicamente correcto y aun así no cumplir su propósito. En los primeros informes, el desequilibrio habitual es predecible: páginas de narración del scanner y muy poca explicación de la decisión que el lector debe tomar.

La mayoría de las plantillas de informes te enseñan dónde colocar la información. Rara vez te enseñan qué merece la atención del lector. Además, el documento debe conservar el trabajo necesario para comprender un riesgo confirmado. También debe mostrar cómo reproducirlo, solucionarlo y verificar el resultado. Los callejones sin salida, cada comando y cada captura de pantalla pertenecen a tus notas de trabajo, a menos que ayuden al lector a interpretar el resultado final.

Hack The Box plantea claramente el problema de la redacción: “Writing is a technology. One that’s been invented independently at least four or five times in humanity’s history.” Tu primer informe no necesita demostrar que naciste siendo redactor de seguridad. Necesita un método repetible.

Un informe que obliga al lector a reconstruir la ruta de ataque no es exhaustivo; está sin terminar.

Decide quién debe actuar antes de escribir

Un informe sirve a dos audiencias con distintos puntos de detención. La dirección necesita la decisión rápidamente. Los ingenieros necesitan el detalle que viene después.

Lector	Necesita primero	Necesita en las capas inferiores
Ejecutivos y responsables de seguridad	Consecuencia, área de negocio afectada y prioridad de mitigación	Exposición, limitaciones y decisión requerida
Equipos técnicos	Componente afectado, condición verificada y dirección de la remediación	Parámetros, causa raíz, pasos de reproducción y evidencia

Utiliza un solo informe con detalles por capas. Resume la decisión una vez y conéctala con el hallazgo técnico. Mantén una única versión del riesgo.

Considera este ejemplo ficticio e ilustrativo: un endpoint /admin/export sin autenticación devuelve registros de clientes. Este endpoint y su comportamiento son inventados para demostrar cómo redactar un informe.

Para un ejecutivo, el hallazgo podría decir:

El endpoint /admin/export de la aplicación devolvió registros de clientes sin requerir una sesión autenticada. El responsable debe restringir el endpoint a usuarios autorizados y revisar si los enlaces de exportación existentes siguen siendo válidos después de añadir la autorización.

Para un ingeniero, el mismo hallazgo necesita el método probado, la solicitud, la respuesta, el estado de autenticación, los datos afectados, los pasos de reproducción y los detalles de la remediación. La versión ejecutiva responde a “¿Qué decisión debemos tomar?”. La versión técnica responde a “¿Qué condición debemos cambiar y cómo verificaremos que se ha hecho?”.

Los ejecutivos necesitan la consecuencia y la decisión, no un recorrido por la cadena de ataque. Los equipos técnicos necesitan la cadena de ataque porque les indica qué deben cambiar.

UpGuard recomienda traducir el riesgo cibernético a nivel directivo a “dollars and cents”. Utiliza ese enfoque únicamente cuando el engagement respalde una cifra defendible. Este proceso no te indicará el coste empresarial real cuando el engagement no haya medido registros ni tiempo de inactividad. Tampoco midió el gasto de recuperación; en ese caso, prefiero informar de una exposición precisa antes que fabricar una cifra en dólares.

Informa de la exposición verificada e identifica qué debería decidir el cliente. La precisión supera a la aritmética teatral.

Coloca la decisión al principio y conserva debajo la evidencia

La dirección debería poder comprender la exposición antes de abrir una captura de paquetes o una transcripción de una herramienta. Redacta primero los hallazgos detallados y, después, escribe el resumen ejecutivo una vez que los hechos y la remediación sean estables.

El documento debe seguir el recorrido del lector:

1. Resumen ejecutivo: Explica qué se evaluó y sus principales consecuencias. Incluye los hallazgos importantes y las decisiones o mitigaciones necesarias. Incluye un resumen de incidente o amenaza solo cuando el engagement haya implicado un incidente o una amenaza identificada.
2. Alcance y limitaciones: Define los sistemas y entornos evaluados. Incluye fechas, exclusiones, cuentas de prueba y condiciones que limiten la interpretación.
3. Metodología: Describe brevemente el enfoque de la evaluación. Menciona estándares o herramientas cuando aclaren la cobertura.
4. Resumen de hallazgos: Muestra cuántos hallazgos existen y cómo se distribuye su gravedad. Utiliza las mismas etiquetas en todo el documento.
5. Hallazgos detallados: Proporciona a cada debilidad confirmada su condición, impacto, evidencia, remediación y límites.
6. Estado de la remediación y del retest: Indica las acciones recomendadas y si las soluciones fueron verificadas, están pendientes o quedan fuera del engagement.
7. Apéndices: Traslada aquí las solicitudes detalladas y la salida de las herramientas. Incluye también aquí la terminología y el resto del material de apoyo.

Esta arquitectura es suficiente para la mayoría de los informes de penetration testing y de evaluaciones de seguridad. El resto es el recorrido del lector.

El problema ficticio de /admin/export debe aparecer en el resumen como una decisión:

La evaluación confirmó una debilidad de control de acceso en el endpoint /admin/export de la aplicación. El endpoint devolvió registros de clientes sin una sesión autenticada. La remediación requiere comprobaciones de autenticación y autorización en el servidor, seguidas de una revisión para determinar si los enlaces de exportación existentes siguen siendo válidos.

Después, el hallazgo detallado proporciona la prueba y el contexto de implementación. Este orden ofrece a cada lector un punto de entrada útil: la dirección ve la decisión, los responsables ven la acción, los ingenieros ven la condición y los auditores pueden comprobar el registro.

CVSS es metadatos útiles, no un sustituto para explicar el impacto empresarial. Un número de gravedad no puede indicar a un responsable qué debe solucionar primero.

Si tu organización utiliza CVSS, indica ese sistema de puntuación e incluye la puntuación y el vector cuando sea necesario. Explica la valoración técnica utilizando las condiciones de ataque y los privilegios relevantes. Incluye la interacción del usuario y las propiedades de seguridad afectadas. Mantén esa puntuación separada de la prioridad empresarial. Si la organización aplica un ajuste de gravedad local debido a la criticidad del activo y la sensibilidad de los datos. También señala la exposición o los controles compensatorios, indícalo y explica el motivo. Una prioridad local es una decisión organizativa; no es una puntuación CVSS disfrazada.

Escribe cada hallazgo para que un desconocido pueda entenderlo y actuar

Titula el hallazgo con la condición y el objetivo:

Acceso sin autenticación a las exportaciones de clientes en /admin/export

“Un problema de control de acceso” proporciona al lector una categoría y nada más. Un hallazgo útil responde a siete preguntas.

• ¿Qué ocurrió?
• ¿Dónde ocurrió?
• ¿Cómo se verificó?
• ¿Por qué importa?
• ¿Qué gravedad tiene según el método indicado?
• ¿Qué debería ocurrir a continuación?
• ¿Cuáles son los límites de la evidencia?

TrustedSec define el lenguaje claro como un lenguaje que “can be understood by a listener/reader the first time it’s encountered” y afirma que su objetivo es la claridad y la accesibilidad, no “dumbing down” content. Ese es el estándar adecuado para la redacción técnica de seguridad.

El lenguaje claro es redacción técnica que no obliga al lector a traducir cada frase. Utiliza un sujeto y un verbo concretos. Sustituye “ello” por el endpoint o el control cuando el pronombre pueda resultar ambiguo. Nombra el servicio o la cuenta cuando sea necesario. Desarrolla las abreviaturas la primera vez que las utilices. “Equipo de operaciones” ayuda a más lectores que “Ops”, y “sede central” es más claro que “HQ”.

Antes y después

Débil, deliberadamente débil

La aplicación tiene un problema de gravedad alta que podría permitir el acceso no autorizado.

Esta frase oculta el endpoint, la condición de acceso, el recurso afectado y la acción. “Problema” no dice prácticamente nada. “Podría potencialmente” añade confusión en lugar de una incertidumbre útil.

Más sólido

El endpoint /admin/export devolvió registros de clientes sin requerir una sesión autenticada. Un usuario sin autenticación podría descargar la URL de exportación y acceder a los registros. Restringe el endpoint a usuarios autenticados y autorizados, y después revisa si los enlaces de exportación existentes siguen siendo válidos después de añadir la autorización.

La primera frase indica la condición verificada. La segunda indica la ruta de acceso demostrada. La tercera proporciona al responsable un requisito de remediación ordenado. El ejemplo sigue siendo ficticio e ilustrativo.

Utiliza la voz pasiva cuando haga más clara la condición. “La cuenta se deshabilitó durante el retest” es perfectamente válido cuando el actor es irrelevante. Evita las construcciones pasivas que oculten al responsable o la acción.

Indica la causa raíz cuando la conozcas. Si verificaste que faltaba autorización en el endpoint, pero no estableciste qué componente del framework lo provocó, informa de la condición del control de acceso. Adivinar sobre el middleware o el proceso de desarrollo debilita el hallazgo.

La remediación debe nombrar el control y su ubicación. “Aplica las buenas prácticas de seguridad” es la forma en que un hallazgo se registra, se admira y se ignora. Para este endpoint ficticio, exige comprobaciones de autenticación y autorización en el servidor y después revisa los enlaces de exportación existentes. Si esos enlaces siguen siendo válidos después de añadir la autorización, invalídalos o sustitúyelos. Esos son requisitos de remediación, no observaciones sobre lo que la prueba ya demostró.

Por último, describe el resultado de verificación esperado. Una solicitud sin autenticación debería recibir un error de autorización, y un usuario permitido debería recuperar únicamente los registros que su rol autorice. El retest debe establecer ese resultado; una recomendación no es un retest.

La evidencia debe demostrar la afirmación, no decorar la página

La salida del scanner puede orientarte hacia un hallazgo, pero la verificación manual la convierte en evidencia. Si no verificaste manualmente el hallazgo, no lo presentes como una debilidad confirmada.

Incluye en el texto el método, la URL o el parámetro y el estado de autenticación. Incluye la respuesta y el resultado esperado. Utiliza la captura de pantalla para que el hecho visual decisivo sea fácil de confirmar. Las capturas de pantalla complementan los pasos de reproducción. No los sustituyen.

Para el hallazgo ficticio de /admin/export, los pasos escritos deben explicar cómo realizar la solicitud de forma segura en el entorno de prueba designado y qué respuesta establece la condición. La captura de pantalla debe mostrar la solicitud y la respuesta relevantes, con el resultado del acceso exitoso visible.

Una captura de pantalla útil proporciona contexto, muestra el paso relevante y deja claro el objetivo alcanzado. Amplía la prueba. Añade un recuadro, un círculo o una flecha cuando reduzca el tiempo de búsqueda. Elimina los comandos no relacionados. Redacta las credenciales, tokens, información personal y datos del cliente.

Añade un pie a la ilustración ficticia: “La solicitud sin autenticación devuelve la exportación de clientes; token, nombres y valores redactados.” Un pie como ese indica al lector dónde mirar. Un escritorio completo, diez comandos no relacionados y una diminuta línea de evidencia producen el efecto contrario.

Indica si la evidencia procede de producción, staging o de un entorno de prueba designado. Si las pruebas se detuvieron después de confirmar el acceso, dilo. Un límite preciso evita que el lector infiera una exposición mayor que la establecida por la evaluación.

Edita por fases porque se supone que el primer borrador debe ser malo

Editar forma parte de la evaluación. Es más que un acabado administrativo. Cada frase poco clara añade una pregunta que el lector debe responder antes de asignar o solucionar el problema.

Redacta primero los hallazgos. Deja pasar al menos 15 minutos antes de editar; uno o dos días es mejor cuando el calendario lo permita. Hack The Box ofrece un consejo que vale la pena conservar: “Some of the best writing advice I’ve ever gotten is to write the first draft badly, and come back to fix it later.” Edita los hallazgos, escribe el resumen ejecutivo y después realiza una última revisión de coherencia en todo el informe.

Utiliza cinco fases:

1. Precisión. Comprueba el alcance, los activos y los endpoints con respecto al registro de pruebas. Comprueba también los datos afectados, las referencias de evidencia, la gravedad, la remediación y las afirmaciones sobre el retest.
2. Prueba del lector. Marca cada consecuencia y decisión del resumen. En cada hallazgo, marca cada activo, referencia de prueba, acción del responsable o detalle de reproducción que falte.
3. Lenguaje. Sustituye los sustantivos vagos, los pronombres poco claros, los acrónimos sin explicar y la narración innecesaria de las herramientas. Elimina los detalles del proceso que no ayuden a interpretar el resultado. (Para la parte de escaneo, consulta nuestra guía para elegir herramientas de pentesting.)
4. Coherencia. Haz coincidir el número de hallazgos y las etiquetas de gravedad. Después, comprueba la terminología, las mayúsculas, el uso de acrónimos y el orden de las listas. Comprueba todas las tablas, gráficos, resúmenes y referencias cruzadas.
5. Presentación. Comprueba los encabezados, las tablas y los saltos de página. Revisa la legibilidad de las capturas de pantalla, las redacciones, la navegación y el formato del PDF exportado.

Lee el informe en voz alta. Después, lee una sección desde el final hacia el principio. La lectura inversa interrumpe el flujo narrativo y revela frases repetidas, incompletas o poco naturales que tu cerebro omite en el orden normal. Cambia la fuente o el fondo si la página se ha vuelto visualmente invisible para ti.

Utiliza una lista de comprobación en lugar de confiar en la memoria. Si es posible, pide a otra persona que lo lea: un no autor puede probar la explicación empresarial, mientras que un compañero técnico puede probar la reproducción. Un lector externo es mejor que ninguno.

Evita los atajos que hacen que un informe no sea fiable

Los fallos habituales son mundanos: alcance incorrecto, salida no verificada, ausencia del estado del retest y un lector que nadie identificó. Trátalos como comprobaciones del proceso.

• Desviación del alcance: Confirma primero los hosts y las aplicaciones. Después, comprueba las cuentas, las fechas, los entornos y las exclusiones. No sugieras cobertura para sistemas que el engagement no evaluó.
• Dependencia del scanner: Comprueba manualmente los hallazgos automatizados, registra lo que observaste y etiqueta la salida no verificada como una pista.
• Ausencia del estado del retest: Indica si se probó una solución, cuándo se probó y qué resultado se observó. Si el retest quedaba fuera del engagement, dilo.
• Mapeo irreflexivo de cumplimiento: Mapea los hallazgos a NIST, ISO, CMMC, PCI u otro framework únicamente cuando el engagement requiera esa cobertura y las pruebas la respalden. Una referencia a un control no demuestra el cumplimiento.
• Desajuste entre las partes interesadas: Confirma la audiencia y la escala de gravedad antes de escribir. Comprueba también el formato requerido y la fecha límite para la decisión. Un hallazgo técnicamente preciso sigue necesitando un responsable identificado y una acción siguiente.

Estas son recomendaciones generales para la elaboración de informes reflejadas en las directrices de Indusface y GuidePoint Security, no resultados universales medidos. Utilízalas para cuestionar tu flujo de trabajo, no para añadir estadísticas sin respaldo a tu informe.

Ejecuta esta lista de comprobación final antes de enviar

Copia esto en tu ticket interno de QA:

Decisión

• El resumen ejecutivo aparece cerca del principio.
• El resumen ejecutivo indica la consecuencia y la decisión requerida.
• El alcance y las exclusiones son explícitos. También lo son las fechas, los entornos y las limitaciones.
• Cada recomendación identifica una acción del responsable.

Evidencia

• Cada hallazgo nombra el activo y la condición. También indica el impacto, el método de gravedad, la remediación y la referencia de evidencia.
• Los hallazgos confirmados se verificaron manualmente.
• Las pistas no verificadas están claramente etiquetadas.
• Los pasos de reproducción identifican el estado de autenticación y el resultado esperado.
• Las capturas de pantalla muestran contexto y pruebas.
• Las credenciales, tokens, PII y datos del cliente están redactados.
• El estado del retest indica si la solución fue verificada.

Coherencia

• Los recuentos de hallazgos coinciden en el texto, las tablas y los gráficos.
• Las etiquetas de gravedad y las decisiones de prioridad local son coherentes.
• Los acrónimos y las mayúsculas coinciden. También la terminología y el orden de las listas.
• Las referencias de cumplimiento aparecen únicamente cuando el engagement las respalda.
• Un no autor leyó la explicación empresarial, si estaba disponible.
• Un compañero técnico comprobó la reproducción, si estaba disponible.

Antes de enviarlo, pregunta si la persona que toma la decisión puede priorizar el problema, si el responsable puede asignarlo y si el ingeniero puede verificar la solución. Si alguna respuesta es no, el informe sigue formando parte de la evaluación.