OP.EXP.9 Registro de la gestión de incidentes

Documentos de referencia

• Real Decreto 311/2022 - Anexo II, Medida OP.EXP.9
• T-024-011 - Registro de incidentes de seguridad
• T-024-014 - Base de datos de incidentes
• T-024-015 - Plantilla de registro de incidente
• GP-013 - Gestión de Ciberseguridad
• OP.EXP.7 - Gestión de incidentes
• ISO/IEC 27035 - Gestión de incidentes
• Directiva NIS2 - Requisitos de notificación

Guía de implantación

Objetivo

Establecer un sistema completo y detallado de registro de todos los incidentes de seguridad, desde su detección hasta su resolución completa, garantizando la trazabilidad, el análisis posterior y el cumplimiento de las obligaciones de notificación regulatoria.

Alcance

Este procedimiento cubre el registro de:

• Todos los incidentes de seguridad confirmados
• Eventos de seguridad bajo investigación
• Vulnerabilidades identificadas
• Casi-incidentes (near misses)
• Incidentes relacionados con el dispositivo médico
• Brechas de datos personales
• Incidentes de la cadena de suministro

Estructura del registro de incidentes

Información básica del incidente

Campos Obligatorios del Registro:

Campo	Formato	Valores Posibles	Descripción
ID_Incidente	INC-YYYY-MM-DD-NNNN	Formato: INC-2024-11-15-0001	Identificador único del incidente
Fecha_Detección	YYYY-MM-DD HH:MM:SS	Timestamp UTC	Cuándo se detectó el incidente
Fecha_Ocurrencia	YYYY-MM-DD HH:MM:SS	Timestamp UTC (estimada si necesario)	Cuándo ocurrió realmente el incidente
Reportado_Por	Texto	Nombre, Rol, Contacto	Quién reportó el incidente
Severidad	Enum	Crítica | Alta | Media | Baja	Nivel de gravedad
Estado	Enum	Abierto | En Investigación | Contenido | Resuelto | Cerrado	Estado actual
Tipo	Enum	Malware | Acceso No Autorizado | DoS | Fuga Datos | Física | Otro	Categoría del incidente
Sistemas_Afectados	Lista	Array de nombres de sistemas	Qué sistemas están impactados
Datos_Comprometidos	Booleano	Sí | No | En Investigación	Si hubo brecha de datos
Impacto_Dispositivo_Médico	Booleano	Sí | No | Potencial	Impacto en funcionalidad clínica

Clasificación detallada

Categorización NIS2:

• Impacto en servicios esenciales: Sí/No
• Número de usuarios afectados: [Cantidad]
• Duración de la interrupción: [Horas]
• Alcance geográfico: Local/Nacional/Internacional
• Impacto económico estimado: [EUR]

Categorización médica:

• Impacto en seguridad del paciente: Ninguno/Menor/Moderado/Grave/Crítico
• Funciones clínicas afectadas: [Lista]
• Datos clínicos comprometidos: Tipo y volumen
• Necesidad de notificación AEMPS: Sí/No

Fases de registro

Registro inicial (T=0 a T+1h)

Quién: Primer respondedor (Security Analyst, DevOps on-call, o sistema automatizado)

Cuándo: Inmediatamente tras la detección, máximo 1 hora

Campos Obligatorios del Registro Inicial:

Identificación del Incidente:

• incidentId: Formato INC-YYYY-MM-DD-NNNN (ej: INC-2024-11-15-0001)
• detectionTime: Timestamp UTC de la detección (ej: 2024-11-15T10:30:00Z)

Información del Reportero:

• Nombre: Persona que reporta (ej: Juan Pérez)
• Rol: Security Analyst, DevOps Engineer, etc.
• Contacto: Email o teléfono para seguimiento

Evaluación Inicial (Initial Assessment):

• Summary: Descripción breve del incidente (1-2 frases)
• Affected Systems: Lista de sistemas afectados (ej: ["API Gateway", "Database Server"])
• Initial Severity: Severidad inicial: CRITICAL | HIGH | MEDIUM | LOW
• Containment Actions: Acciones inmediatas tomadas (ej: ["Sistema aislado", "Accesos bloqueados"])

Timeline (Cronología Inicial):

Registrar cada acción con:

• Time: Hora exacta (HH:MM:SS)
• Action: Descripción de la acción o evento
• Performer: Quién realizó la acción

Ejemplo de Timeline:

Hora	Acción	Quién
10:30:00	Detección inicial por IDS	Sistema automatizado
10:35:00	Verificación manual del alerta	Juan Pérez (Security Analyst)
10:40:00	Escalado a CISO	Juan Pérez

Registro de investigación (T+1h a T+24h)

Información adicional:

• Vector de ataque identificado
• Vulnerabilidades explotadas (CVE si aplica)
• Indicadores de Compromiso (IoCs)
• Alcance real del incidente
• Datos/sistemas confirmados como afectados
• Evidencias recolectadas
• Análisis de causa raíz preliminar

Formato de Indicadores de Compromiso (IoCs):

Tipos de IoCs a Registrar:

Tipo de Indicador	Campos Requeridos	Ejemplo	Propósito
IP Address	• Tipo: "IP" • Valor: Dirección IP • Contexto: Descripción	192.168.1.100 Contexto: "IP origen del ataque"	Identificar fuentes de ataque
File Hash	• Tipo: "HASH" • Valor: Hash del archivo • Algoritmo: MD5/SHA-256 • Contexto: Descripción	5d41402abc4b2a76b9719d911017c592 Algoritmo: MD5 Contexto: "Malware detectado"	Detectar archivos maliciosos
Domain	• Tipo: "DOMAIN" • Valor: Dominio • Contexto: Descripción	malicious-domain.com Contexto: "C&C server"	Bloquear comunicaciones maliciosas
URL	• Tipo: "URL" • Valor: URL completa • Contexto: Descripción	https://phishing-site.com/login Contexto: "Sitio de phishing"	Prevenir accesos a sitios maliciosos
Email	• Tipo: "EMAIL" • Valor: Dirección email • Contexto: Descripción	attacker@evil.com Contexto: "Origen del phishing"	Bloquear remitentes maliciosos

Uso de IoCs:

• Compartir con sistemas SIEM para detección automática
• Actualizar reglas de firewall/IDS/IPS
• Distribuir a threat intelligence platforms
• Coordinar con otros sistemas de la organización

Registro de contención y erradicación (T+24h a T+72h)

Quién: Incident Response Team + DevOps + Security Team

Fase de Contención:

Acciones Inmediatas (primeras 2-4 horas):

Acción	Descripción	Timestamp Completado	Responsable
Aislamiento de Red	Desconectar sistemas afectados de la red para prevenir propagación	Completado 11:00	Network Admin
Bloqueo de Cuentas	Deshabilitar cuentas comprometidas o sospechosas	3 cuentas bloqueadas 11:15	Security Analyst
Preservación de Evidencias	Crear imágenes forenses de sistemas afectados antes de modificarlos	Imagen forense creada 11:30	Forensic Analyst

Acciones de Corto Plazo (24-48 horas):

Acción	Descripción	Resultado	Responsable
Parcheo de Vulnerabilidades	Aplicar parches de seguridad para vulnerabilidades explotadas	CVE-2024-1234 parcheado en todos los sistemas	DevOps Team
Cambio de Credenciales	Rotar todas las credenciales potencialmente comprometidas	Todas las contraseñas admin cambiadas	Security Team
Actualización de Reglas Firewall	Bloquear IPs/dominios maliciosos identificados	Nuevas reglas implementadas	Network Security

Fase de Erradicación:

Acción	Descripción	Resultado	Verificación
Eliminación de Malware	Ejecutar antivirus y herramientas de remediación	Antivirus ejecutado, 5 archivos maliciosos eliminados	Scan limpio confirmado
Cierre de Backdoors	Eliminar accesos no autorizados implantados por atacante	Puerto 4444 cerrado, servicio malicioso eliminado	Netstat verificado
Limpieza de Logs	Identificar y marcar entradas de logs relacionadas con el ataque	Entradas maliciosas identificadas y marcadas para análisis	Logs preservados
Verificación Final	Escaneo completo de seguridad para confirmar erradicación	Scan completo sin detecciones adicionales	Sistema limpio

Registro de recuperación (T+72h a cierre)

Plan de recuperación ejecutado:

• Orden de restauración de servicios
• Verificaciones realizadas por servicio
• Problemas encontrados durante recuperación
• Medidas adicionales implementadas
• Monitorización post-incidente

Plantilla completa de registro

Estructura del Documento de Registro de Incidente (T-024-015):

Sección 1: INFORMACIÓN GENERAL

• ID Incidente: INC-YYYY-MM-DD-NNNN
• Fecha/Hora Detección: Timestamp UTC
• Fecha/Hora Ocurrencia: Timestamp UTC (estimada si necesario)
• Fecha/Hora Cierre: Timestamp UTC
• Duración Total: Horas desde detección hasta cierre
• Clasificación: Severidad / Tipo / Estado

Sección 2: RESUMEN EJECUTIVO

• Descripción concisa del incidente (máximo 200 palabras)
• Qué ocurrió, impacto principal, cómo se resolvió
• Destinado a Management y Board

Sección 3: CRONOLOGÍA DETALLADA

• Tabla con cada evento del incidente:
  • Hora (HH:MM)
  • Evento/Acción realizada
  • Responsable (quién lo ejecutó)
  • Evidencia (link a screenshots, logs, etc.)

Sección 4: ANÁLISIS TÉCNICO

4.1 Vector de Ataque: Cómo accedió el atacante 4.2 Vulnerabilidades Explotadas: CVEs o configuraciones incorrectas 4.3 Sistemas Afectados: Tabla con sistema, impacto, datos comprometidos, tiempo inactivo 4.4 Indicadores de Compromiso: IPs maliciosas, dominios, hashes de archivos, patrones de comportamiento

Sección 5: IMPACTO

5.1 Impacto en el Negocio:

• % Disponibilidad perdida

• Número de usuarios afectados

• Pérdida económica estimada (EUR)

• Impacto reputacional (Bajo/Medio/Alto)

  5.2 Impacto en Datos:

• Confidencialidad: Qué datos fueron expuestos

• Integridad: Qué datos fueron modificados

• Disponibilidad: Qué datos no fueron accesibles

  5.3 Impacto Regulatorio:

• RGPD: ¿Brecha notificable? (Art. 33)

• NIS2: ¿Incidente significativo?

• MDR: ¿Impacto en dispositivo médico?

Sección 6: RESPUESTA

6.1 Contención: Medidas implementadas para limitar propagación 6.2 Erradicación: Acciones para eliminar amenaza 6.3 Recuperación: Proceso de restauración de servicios 6.4 Mejoras Implementadas: Controles adicionales para prevenir recurrencia

Sección 7: LECCIONES APRENDIDAS

7.1 Qué Funcionó Bien: Aspectos positivos de la respuesta 7.2 Qué Necesita Mejora: Áreas de oportunidad identificadas 7.3 Recomendaciones: Acciones correctivas con responsable y fecha

Sección 8: COMUNICACIONES

8.1 Notificaciones Internas: Tabla con stakeholder, fecha/hora, método, confirmación 8.2 Notificaciones Externas: Tabla con entidad (AEPD, INCIBE, AEMPS), requisito legal, fecha/hora, referencia

Sección 9: EVIDENCIAS

9.1 Capturas de Pantalla: Screenshots con descripción 9.2 Logs: Archivos de logs relevantes 9.3 Análisis Forense: Memory dumps, network captures, disk images

Sección 10: MÉTRICAS

Métrica	Descripción	Objetivo
MTTD (Mean Time To Detect)	Tiempo desde ocurrencia hasta detección	< 5 minutos
MTTR (Mean Time To Respond)	Tiempo desde detección hasta inicio de respuesta	< 15 minutos
MTTC (Mean Time To Contain)	Tiempo hasta contener el incidente	< 2 horas
MTTE (Mean Time To Eradicate)	Tiempo hasta erradicar amenaza	< 24 horas
Total Downtime	Tiempo total de indisponibilidad	Minimizar

Sección 11: FIRMAS Y APROBACIONES

• Preparado por: Incident Manager - Fecha
• Revisado por: CISO - Fecha
• Aprobado por: CTO/CEO - Fecha (para incidentes críticos)

Documento Almacenado: T-024-015 (Plantilla completa disponible en repositorio documental)

Base de datos de incidentes

Estructura de la base de datos

Base de Datos de Incidentes:

Tabla 1: incidents (Registro Principal de Incidentes)

Campo	Tipo	Descripción	Validación/Valores
incident_id	VARCHAR(20)	Identificador único (PK)	Formato: INC-YYYY-MM-DD-NNNN
detection_timestamp	TIMESTAMP	Cuándo se detectó (obligatorio)	UTC, NOT NULL
occurrence_timestamp	TIMESTAMP	Cuándo ocurrió (estimado)	UTC
reporter_id	INTEGER	Usuario que reportó	FK a tabla users
severity	ENUM	Severidad del incidente	CRITICAL | HIGH | MEDIUM | LOW
status	ENUM	Estado actual	OPEN | INVESTIGATING | CONTAINED | RESOLVED | CLOSED
type	VARCHAR(50)	Tipo de incidente	Malware, Acceso No Autorizado, DoS, etc.
affected_systems	JSON	Sistemas afectados	Array de nombres de sistemas
data_breach	BOOLEAN	¿Hubo brecha de datos?	true/false
medical_device_impact	BOOLEAN	¿Impacto en dispositivo médico?	true/false
description	TEXT	Descripción del incidente	Texto largo
root_cause	TEXT	Causa raíz identificada	Texto largo
iocs	JSON	Indicadores de compromiso	Array de IoCs
timeline	JSON	Cronología de eventos	Array de eventos
communications	JSON	Notificaciones realizadas	Array de comunicaciones
evidence_links	JSON	Enlaces a evidencias	Array de URLs/paths
metrics	JSON	Métricas (MTTD, MTTR, etc.)	Objeto con métricas
created_at	TIMESTAMP	Fecha de creación del registro	Auto-generado
updated_at	TIMESTAMP	Última actualización	Auto-actualizado
closed_at	TIMESTAMP	Fecha de cierre	NULL si abierto

Índices para Performance:

• idx_severity - Búsquedas por severidad
• idx_status - Búsquedas por estado
• idx_dates - Búsquedas por rangos de fechas

Tabla 2: incident_actions (Acciones Durante el Incidente)

Campo	Tipo	Descripción	Validación/Valores
action_id	INTEGER	ID único auto-incrementado (PK)	AUTO_INCREMENT
incident_id	VARCHAR(20)	Incidente relacionado	FK a incidents.incident_id
action_timestamp	TIMESTAMP	Cuándo se realizó la acción	UTC, NOT NULL
action_type	ENUM	Tipo de acción	DETECTION | CONTAINMENT | ERADICATION | RECOVERY | COMMUNICATION
action_description	TEXT	Descripción de la acción	Texto largo
performed_by	INTEGER	Quién realizó la acción	FK a tabla users
evidence_link	VARCHAR(500)	Link a evidencia	URL o path

Índices para Performance:

• idx_incident - Búsquedas por incidente
• idx_timestamp - Ordenación cronológica

Relaciones:

• incidents.reporter_id → users.user_id
• incident_actions.incident_id → incidents.incident_id
• incident_actions.performed_by → users.user_id

APIs de registro

API para Gestión de Incidentes:

Endpoint 1: Crear Nuevo Incidente

Parámetro	Valor
Método	POST
URL	/api/incidents
Headers	Content-Type: application/json Authorization: Bearer [token]

Payload (Body):

• detection_time: Timestamp UTC (ej: "2024-11-15T10:30:00Z")
• severity: HIGH | MEDIUM | LOW | CRITICAL
• type: UNAUTHORIZED_ACCESS, MALWARE, DOS, DATA_BREACH, etc.
• affected_systems: Array de sistemas (ej: ["api-gateway", "database"])
• initial_description: Texto descriptivo del incidente

Quién puede ejecutar: Security Analysts, DevOps on-call, Incident Response Team

Respuesta:

• Status 201 Created
• Body: { "incident_id": "INC-2024-11-15-0001", "status": "OPEN" }

Endpoint 2: Actualizar Incidente

Parámetro	Valor
Método	PATCH
URL	/api/incidents/{incident_id}
Headers	Content-Type: application/json Authorization: Bearer [token]

Payload (Body) - Campos Opcionales:

• status: INVESTIGATING | CONTAINED | RESOLVED | CLOSED
• root_cause: Texto con causa raíz identificada
• containment_actions: Array de acciones tomadas
• iocs: Array de indicadores de compromiso
• evidence_links: Array de enlaces a evidencias

Quién puede ejecutar: Incident Manager, CISO, Incident Response Team

Respuesta:

• Status 200 OK
• Body: Incidente actualizado con campos modificados

Notificaciones y reportes

Notificaciones automáticas

Evento	Destinatarios	Canal	Tiempo
Nuevo incidente P1/P2	CISO, CTO, On-call	SMS + Email	Inmediato
Cambio estado	Incident Manager	Email	Inmediato
Cierre incidente	Stakeholders	Email	< 1 hora
Informe semanal	Management	Email	Lunes 9:00
Informe mensual	Board	Portal	Día 1 del mes

Reportes periódicos

Reporte semanal:

• Resumen de incidentes nuevos
• Estado de incidentes abiertos
• Métricas de respuesta
• Tendencias identificadas

Reporte mensual:

• Análisis estadístico completo
• Comparativa con meses anteriores
• Top 10 vulnerabilidades
• Efectividad de controles
• Recomendaciones de mejora

Reporte anual:

• Análisis comprehensivo
• Evolución de la postura de seguridad
• ROI de inversiones en seguridad
• Benchmarking con industria
• Plan de mejora para siguiente año

Análisis y métricas

KPIs del proceso de registro

Métrica	Objetivo	Medición
Completitud registro inicial	100% campos obligatorios	Por incidente
Tiempo registro inicial	< 1 hora desde detección	Por incidente
Actualización timeline	Cada 2 horas durante incidente	Por incidente
Calidad de RCA	90% con causa raíz identificada	Mensual
Cumplimiento notificaciones	100% en plazo legal	Mensual

Análisis de tendencias

Análisis Mensual de Tendencias de Incidentes:

Quién: Security Operations Manager + Data Analytics Team

Frecuencia: Mensual (generado el día 1 de cada mes)

Métricas Analizadas:

Métrica	Descripción	Fuente de Datos	Objetivo de Análisis
Total de Incidentes	Conteo de incidentes por mes	Base de datos incidents	Identificar incrementos o decrementos
Por Severidad	Distribución por nivel (Critical, High, Medium, Low)	Campo severity	Evaluar gravedad general
Por Tipo	Agrupación por categoría (Malware, DoS, Phishing, etc.)	Campo type	Identificar vectores de ataque más comunes
Tendencia de MTTR	Evolución del tiempo promedio de respuesta	Campos timestamps	Medir mejora en capacidad de respuesta
Incidentes Recurrentes	Patrones de incidentes repetidos	Análisis de root_cause	Identificar problemas sistémicos
Impacto Económico	Costo estimado mensual de incidentes	Campo metrics + datos financieros	Cuantificar pérdidas

Proceso de Análisis:

1. Recolección de Datos: Extraer todos los incidentes del mes anterior
2. Cálculo de Métricas: Generar estadísticas para cada categoría
3. Análisis Comparativo: Comparar con meses anteriores (tendencias)
4. Identificación de Patrones: Buscar incidentes recurrentes o relacionados
5. Generación de Informe: Crear reporte ejecutivo con visualizaciones
6. Recomendaciones: Proponer acciones basadas en hallazgos

Resultado:

• Informe mensual de tendencias (PDF + dashboard interactivo)
• Distribuido a: CISO, CTO, Management, Board (trimestral)
• Almacenado en repositorio de compliance (R-024-XXX)

Retención y archivo

Políticas de retención

Tipo de registro	Retención online	Archivo	Eliminación
Incidentes críticos	5 años	10 años	Nunca
Incidentes altos	3 años	7 años	10 años
Incidentes medios	2 años	5 años	7 años
Incidentes bajos	1 año	3 años	5 años
Evidencias forenses	5 años	Indefinido	Caso por caso

Proceso de archivo

1. Exportación trimestral: JSON + PDF
2. Verificación de integridad: Hash SHA-256
3. Cifrado: AES-256
4. Almacenamiento: S3 Glacier + Copia física
5. Indexación: Base de datos de archivo
6. Prueba de recuperación: Anual

Integración con otros sistemas

• SIEM: Alimentación automática de eventos
• Ticketing: Creación de tickets para acciones
• CMDB: Actualización de estado de activos
• Risk Management: Actualización de matriz de riesgos
• Compliance: Evidencias para auditorías
• Threat Intelligence: Compartir IoCs

Formación y procedimientos

• Formación inicial: Cómo registrar incidentes correctamente
• Actualizaciones: Cambios en procedimientos (trimestral)
• Simulacros: Práctica de registro durante ejercicios
• Lecciones aprendidas: Sesiones post-incidente
• Certificación: Personal autorizado para registro

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001