Tema
POL-007: Plan de Respuesta a Incidentes de Seguridad
| Campo | Valor |
|---|---|
| ID | POL-007 |
| Versión | 1.0 |
| Fecha de Emisión | 2026-03-13 |
| Próxima Revisión | 2027-03-13 |
| Propietario | CISO / Equipo de Respuesta a Incidentes |
| PCI DSS | Requisitos 12.10, 12.10.1 – 12.10.7 |
| Preguntas ControlCase | Q94, Q95 |
1. Propósito
Establecer un plan formal de respuesta a incidentes de seguridad que garantice la detección, contención, erradicación y recuperación oportuna ante incidentes que afecten la confidencialidad, integridad o disponibilidad de datos de titulares de tarjetas o sistemas en scope PCI DSS.
2. Equipo de Respuesta a Incidentes (IRT)
2.1 Composición
| Rol | Responsabilidad | Disponibilidad |
|---|---|---|
| Líder de Incidentes (CISO) | Coordinación general, decisiones de escalamiento, comunicación con gerencia y entidades reguladoras | 24/7 (on-call) |
| DevOps Lead | Contención técnica, aislamiento de sistemas, análisis forense de infraestructura | 24/7 (on-call) |
| Desarrollador Senior | Análisis de código comprometido, hotfixes, revisión de logs de aplicación | Horario laboral + on-call |
| DBA | Análisis de bases de datos afectadas, preservación de evidencia de BD | Horario laboral + on-call |
| Comunicaciones / Legal | Notificación a marcas de pago, entes reguladores, clientes afectados | Según necesidad |
| Gerencia Ejecutiva | Aprobaciones estratégicas, asignación de recursos | Según escalamiento |
2.2 Información de Contacto
Se mantiene una lista de contactos de emergencia actualizada con:
- Nombre, teléfono móvil, email de cada miembro del IRT
- Contactos de proveedores clave (DigitalOcean, procesador de pagos, ASV)
- Contactos de marcas de pago (Visa, Mastercard) para notificación de brecha
- Autoridades reguladoras (SFC Colombia, DIAN según aplique)
- Contacto de la empresa forense designada (PFI)
📁 Lista de contactos almacenada en: ubicación segura con acceso restringido al IRT
3. Clasificación de Incidentes
3.1 Niveles de Severidad
| Nivel | Descripción | Ejemplos | Tiempo de Respuesta |
|---|---|---|---|
| P1 – Crítico | Compromiso confirmado de datos de tarjetas, brecha activa | Acceso no autorizado al CDE, exfiltración de PANs, compromiso de claves de cifrado | 15 minutos |
| P2 – Alto | Intento de intrusión significativo, vulnerabilidad explotada sin acceso a datos | Intentos de inyección SQL exitosos, compromiso de cuenta administrativa, malware detectado | 1 hora |
| P3 – Medio | Actividad sospechosa sin compromiso confirmado | Escaneo de puertos anómalo, intentos fallidos de autenticación masiva, cambio no autorizado en firewall | 4 horas |
| P4 – Bajo | Eventos informativos o de baja prioridad | Falso positivo de IDS, phishing bloqueado, usuario bloqueado por intentos fallidos | 24 horas |
4. Fases de Respuesta a Incidentes
4.1 Fase 1: Detección e Identificación
Fuentes de detección:
- Alertas de Prometheus/AlertManager (anomalías de tráfico, errores 5xx)
- Alertas de IDS/IPS (Falco runtime security)
- Alertas de FIM (cambios no autorizados en archivos)
- Notificaciones de WAF (Kong rate-limiting, IP blocking)
- Reportes de empleados o usuarios
- Alertas de ASV o escaneos de vulnerabilidades
- Notificación externa (CERT, marcas de pago, terceros)
Acciones inmediatas:
- Registrar hora de detección y fuente de la alerta
- Clasificar severidad según §3.1
- Notificar al Líder de Incidentes
- Crear ticket de incidente con ID único:
INC-YYYY-NNN - Activar al equipo IRT según nivel de severidad
4.2 Fase 2: Contención
Contención inmediata (primeros 30 minutos para P1):
- Aislar el sistema o contenedor comprometido (kubectl cordon/drain)
- Bloquear IPs atacantes en DigitalOcean Cloud Firewall
- Revocar credenciales comprometidas (JWT keys, API keys, service accounts)
- Deshabilitar cuentas comprometidas
- Capturar snapshot de sistemas afectados antes de cualquier cambio
Contención a corto plazo:
- Redirigir tráfico fuera de sistemas afectados
- Aplicar reglas de firewall adicionales
- Activar modo de mantenimiento si es necesario
- Preservar todos los logs relevantes
4.3 Fase 3: Erradicación
- Identificar la causa raíz del incidente
- Eliminar malware, backdoors, o cuentas no autorizadas
- Parchear la vulnerabilidad explotada
- Verificar que no hay persistencia del atacante
- Revisar otros sistemas similares por indicadores de compromiso (IOCs)
- Actualizar reglas de IDS/IPS/WAF con IOCs identificados
4.4 Fase 4: Recuperación
- Restaurar sistemas desde backups verificados (si fue necesario)
- Re-desplegar contenedores desde imágenes limpias
- Rotar TODAS las claves y credenciales del CDE:
- Claves de cifrado (MEK, DEK)
- JWT signing keys
- Contraseñas de bases de datos
- API keys de servicios
- Re-habilitar sistemas de forma gradual con monitoreo intensificado
- Verificar integridad de datos restaurados
- Confirmar que controles de seguridad están operativos
- Monitoreo intensificado durante 72 horas post-recuperación
4.5 Fase 5: Lecciones Aprendidas
| Actividad | Plazo | Responsable |
|---|---|---|
| Reunión post-incidente | 5 días hábiles después del cierre | Líder de Incidentes |
| Informe formal de incidente | 10 días hábiles | CISO |
| Actualización de políticas/procedimientos | 30 días | CISO + DevOps |
| Implementación de mejoras | Según plan | Equipo asignado |
El informe post-incidente debe incluir:
- Cronología completa del incidente
- Causa raíz identificada
- Sistemas y datos afectados
- Acciones de contención y erradicación realizadas
- Eficacia de la respuesta
- Recomendaciones de mejora
- Actualización del plan de respuesta si aplica
5. Preservación de Evidencia
5.1 Procedimiento de Preservación
- No apagar sistemas comprometidos (preservar memoria volátil)
- Capturar snapshot de discos/volúmenes
- Exportar logs completos de todos los sistemas involucrados:
- Logs de aplicación (NestJS structured logs)
- Logs de Kong (access + error)
- Logs de PostgreSQL (query logs, auth logs)
- Logs de Kubernetes (events, audit)
- Logs de DigitalOcean Cloud Firewall
- Calcular hashes SHA-256 de toda evidencia recolectada
- Registrar cadena de custodia (quién recopiló, cuándo, dónde se almacena)
- Almacenar en ubicación segura con acceso restringido
5.2 Retención de Evidencia
- Mínimo 12 meses desde el cierre del incidente
- Indefinidamente si hay investigación legal en curso
6. Notificación y Escalamiento
6.1 Matriz de Escalamiento
| Nivel | Notificar a | Plazo |
|---|---|---|
| P1 | IRT completo + Gerencia + Legal | Inmediato |
| P2 | IRT + Gerencia | 1 hora |
| P3 | Líder de Incidentes + DevOps | 4 horas |
| P4 | Registro en sistema de tickets | 24 horas |
6.2 Notificación de Brecha de Datos de Tarjetas
Si se confirma compromiso de datos de tarjetas (PAN, nombre, fecha de expiración):
| Destinatario | Plazo | Método |
|---|---|---|
| Banco adquiriente | 24 horas | Teléfono + email |
| Marcas de pago (Visa/Mastercard) | 24-72 horas | Según protocolo de la marca |
| QSA/Evaluador | 72 horas | Email seguro |
| Autoridad reguladora (SFC) | Según regulación colombiana | Formato oficial |
| Titulares de tarjetas afectados | Según regulación | Comunicación directa |
| PFI (Forensic Investigator) | 72 horas | Contratación inmediata |
7. Pruebas y Mantenimiento del Plan
7.1 Pruebas
| Tipo | Frecuencia | Participantes |
|---|---|---|
| Ejercicio de mesa (tabletop) | Anual como mínimo | Todo el IRT |
| Simulación técnica | Anual | DevOps + CISO |
| Prueba de notificación | Semestral | Todo el IRT |
7.2 Escenarios de Prueba Sugeridos
- Compromiso de credenciales de base de datos del CDE — simular detección, contención, rotación de credenciales
- Exfiltración de PANs tokenizados — simular detección por anomalía de tráfico, análisis forense, notificación
- Ransomware en nodo de Kubernetes — simular aislamiento, recuperación desde imágenes limpias
- Insider threat — simular acceso indebido por empleado con privilegios
7.3 Revisión del Plan
| Actividad | Frecuencia |
|---|---|
| Revisión completa del plan | Anual |
| Actualización de lista de contactos | Trimestral |
| Revisión después de cada incidente real | Después de cada incidente |
| Revisión después de cambios significativos en infraestructura | Según cambio |
8. Capacitación
| Audiencia | Contenido | Frecuencia |
|---|---|---|
| Miembros del IRT | Plan completo, roles, procedimientos técnicos | Anual + al ingresar |
| Todo el personal | Cómo reportar un incidente sospechoso | Anual |
| DevOps | Procedimientos de contención y preservación de evidencia | Semestral |
| Gerencia | Roles de escalamiento y aprobación | Anual |
9. Integraciones con Otros Procesos
| Proceso | Referencia |
|---|---|
| Gestión de Vulnerabilidades | POL-006 |
| Logging y Monitoreo | POL-010 |
| Control de Acceso | POL-003 |
| Gestión de Cambios | POL-005 |
| Comunicación con Terceros | POL-008 |
| Cifrado y Claves | POL-004 |
Historial de Revisiones
| Versión | Fecha | Autor | Cambios |
|---|---|---|---|
| 1.0 | 2026-03-13 | CISO / Seguridad | Documento inicial |
Aprobación
| Rol | Nombre | Firma | Fecha |
|---|---|---|---|
| CISO / Oficial de Seguridad | _________________ | _________________ | //____ |
| Gerencia Ejecutiva | _________________ | _________________ | //____ |