Redacción de un informe de incidentes

Un informe de incidentes documenta qué ocurrió, cuál fue el impacto, qué respuesta se aplicó y qué recomendaciones se formularon. Está dirigido a públicos jurídicos, normativos, directivos y técnicos. Un informe bien redactado demuestra competencia y permite que la organización aprenda de lo ocurrido.

Secciones estándar de un informe de incidentes:

1. Resumen ejecutivo
2. Línea de tiempo de los eventos
3. Análisis técnico
4. Evaluación del impacto
5. Acciones de respuesta realizadas
6. Análisis de la causa raíz
7. Recomendaciones
8. Apéndices (evidencias, IOCs)

El resumen ejecutivo está destinado a la dirección no técnica. Debe responder, en 1 o 2 párrafos:

• ¿Qué ocurrió y cuándo?
• ¿Qué se vio afectado?
• ¿Qué se hizo al respecto?
• ¿Cuál es el estado actual?

No use jerga. Cuantifique el impacto (X registros, Y horas de inactividad, Z $ de costos).

La línea de tiempo es la base factual del informe. Incluya:

• Marca de tiempo (UTC; especifique la zona horaria)
• Qué ocurrió (hecho observable)
• Fuente de información (referencia de registro, herramienta o testigo)

Mantenga separados los hechos y la interpretación. Ejemplo: "14:32 UTC — Se activó una alerta del IDS en el host 10.0.1.5 (ref.: ID de evento 8842 del SIEM)"

La sección técnica documenta las TTP de los atacantes:

• Método de acceso inicial (phishing, explotación o robo de credenciales)
• Herramientas y malware utilizados (con sus hashes)
• Pasos del movimiento lateral
• Datos a los que se accedió o que se exfiltraron
• Mecanismos de persistencia instalados

Mapéelos al marco MITRE ATT&CK para lograr una comunicación estandarizada.

Cuantifique el impacto según la tríada CIA:

• Confidencialidad: ¿a qué datos se accedió o qué datos fueron robados? ¿PII, propiedad intelectual o información financiera?
• Integridad: ¿se modificaron datos?
• Disponibilidad: ¿cuánto duró la inactividad?
• Financiero: costos directos, multas normativas y pérdida de clientes
• Reputacional: divulgación pública y cobertura mediática

Incluya todos los indicadores de compromiso para su uso defensivo:

La causa raíz debe ser específica: "El atacante obtuvo acceso inicial mediante un correo electrónico de phishing que eludió el filtrado de correo debido a la ausencia de la aplicación de DMARC en el dominio de la víctima". Las recomendaciones deben ser concretas, estar priorizadas y asignarse a responsables con fechas límite.

Muchos incidentes activan la obligación de notificar:

• GDPR: notifique a la autoridad de control en un plazo de 72 horas desde que tenga conocimiento del incidente
• HIPAA: notifique al HHS en un plazo de 60 días (y a las personas afectadas también en un plazo de 60 días)
• PCI-DSS: notifique a las marcas de tarjetas en un plazo de 24 horas desde que sospeche que se produjo una vulneración

Clasifique el informe adecuadamente: contiene información sensible sobre vulnerabilidades y TTP de los atacantes. Distribúyalo únicamente según la necesidad de conocerlo. El asesor jurídico debe revisarlo antes de distribuirlo externamente. Las copias internas deben contar con registro de acceso.

Las recomendaciones del informe deben supervisarse hasta su finalización. Asigne a cada recomendación un responsable, una fecha límite y una prioridad. Realice el seguimiento del estado en su sistema de seguimiento de incidencias. Revíselo a los 30, 60 y 90 días. Las recomendaciones no implementadas se convierten en una responsabilidad legal en futuros incidentes.

Un informe de incidentes documenta qué ocurrió (línea de tiempo), cómo ocurrió (análisis técnico), cuál fue el impacto (tríada CIA), qué se hizo (acciones de respuesta) y qué debe corregirse (recomendaciones). El resumen ejecutivo no es técnico. Los IOCs se documentan para reutilizarlos con fines defensivos. Deben cumplirse los plazos de notificación normativa. Para que las recomendaciones sean aplicables, necesitan responsables y fechas límite asignados.