Planificador de Respuesta a Incidentes

El Problema

Cuando ocurre una brecha de seguridad — y ocurrira — el caos es lo predeterminado. Sin un plan de respuesta a incidentes predefinido, los equipos desperdician horas criticas averiguando a quien llamar, que apagar y como comunicar. La evidencia se destruye con reinicios panicosos. Los atacantes mantienen acceso mientras el equipo discute prioridades. Y los plazos de notificacion regulatoria (72 horas bajo GDPR) pasan antes de que alguien entienda el alcance. El momento de planificar para incidentes es antes de que ocurran.

El Prompt

Eres un especialista en respuesta a incidentes de seguridad. Disena un plan integral de respuesta a incidentes para mi organizacion.

CONTEXTO DE LA ORGANIZACION:
- Tamano del equipo: [ej. 5 desarrolladores, sin equipo de seguridad dedicado]
- Infraestructura: [ej. AWS, Vercel, Docker, Hetzner, self-hosted]
- Sensibilidad de datos: [ej. PII de usuarios, datos de pago, registros de salud]
- Requisitos regulatorios: [ej. GDPR, HIPAA, PCI-DSS, SOC 2]
- Monitoreo actual: [ej. Sentry, CloudWatch, ninguno]
- Herramientas de comunicacion: [ej. Slack, email, PagerDuty]

Crear un plan de respuesta a incidentes cubriendo:

1. **Fase de Preparacion**:
   - Roles y responsabilidades del equipo de respuesta
   - Lista de contactos (interno, legal, proveedor de hosting, autoridades)
   - Inventario de herramientas para forense y respuesta
   - Acciones pre-autorizadas

2. **Deteccion y Analisis**:
   - Clasificacion de incidentes (niveles de severidad P1-P4)
   - Checklist de indicadores de compromiso (IoC)
   - Procedimiento de triage inicial (primeros 15 minutos)
   - Pasos de preservacion de evidencia

3. **Contencion**:
   - Contencion a corto plazo (detener el sangrado)
   - Contencion a largo plazo (preparar erradicacion)
   - Templates de comunicacion (interna, clientes, reguladores)

4. **Erradicacion y Recuperacion**:
   - Procedimiento de analisis de causa raiz
   - Restauracion de sistemas desde backups limpios
   - Checklist de rotacion de credenciales
   - Verificacion de eliminacion de la amenaza

5. **Post-Incidente**:
   - Template de post-mortem (sin culpas)
   - Reconstruccion de linea de tiempo
   - Lecciones aprendidas y acciones
   - Actualizaciones del plan basadas en hallazgos

Proporcionar runbooks especificos para incidentes comunes:
- Credenciales comprometidas / acceso no autorizado
- Brecha de datos / exfiltracion
- Ataque DDoS
- Ransomware
- Dependencia comprometida / ataque de cadena de suministro

Ejemplo de Salida

## Plan de Respuesta a Incidentes

### Clasificacion de Severidad
| Nivel | Descripcion | Tiempo de Respuesta | Ejemplo |
|-------|-------------|---------------------|---------|
| P1 Critico | Brecha de datos activa, sistema comprometido | 15 min | DB dumpeada, cuenta admin comprometida |
| P2 Alto | Brecha sospechada, vulnerabilidad explotada activamente | 1 hora | Patrones de login inusuales |
| P3 Medio | Vulnerabilidad encontrada, sin evidencia de explotacion | 24 horas | CVE en dependencia de produccion |

### Primeros 15 Minutos (P1 Critico):
1. Alertar al comandante de incidentes via PagerDuty
2. NO reiniciar servidores (preserva evidencia forense)
3. Capturar: conexiones actuales, procesos en ejecucion, logs recientes
4. Aislar: revocar credenciales comprometidas, bloquear IP del atacante en firewall
5. Preservar: snapshot de servidores/bases de datos afectados antes de cualquier cambio

Cuando Usar

Crear tu plan de respuesta a incidentes antes de que ocurra cualquier incidente — idealmente durante el setup inicial de infraestructura. Revisar y actualizar trimestralmente, despues de cada incidente de seguridad y cuando cambien miembros del equipo. Ejecutar ejercicios de mesa (incidentes simulados) anualmente. Esencial para cualquier organizacion que maneje datos de clientes.

Tips Pro

• Ejecuta ejercicios de mesa — simula un escenario de brecha con tu equipo trimestralmente. Recorre el plan paso a paso para encontrar brechas antes de que un incidente real lo haga.
• Pre-autoriza acciones criticas — decide AHORA quien puede revocar todas las API keys, apagar servidores o resetear contrasenas de todos los usuarios sin esperar aprobacion.
• Preserva la evidencia primero — el instinto de “arreglarlo rapido” destruye evidencia forense. Snapshot de servidores, exporta logs y documenta el estado actual antes de hacer cambios.
• Prepara templates de comunicacion — escribe emails de notificacion a clientes, actualizaciones internas y cartas de notificacion regulatoria por adelantado.