Plan de Respuesta a Incidentes
Runbook operativo. Define qué hacer cuando ocurre un incidente de seguridad. Cumple obligaciones de notificación bajo Ley 172-13 (R.D.), GDPR Art. 33-34 (UE), LGPD Art. 48 (Brasil). Adoptado por la Asamblea en [__]. Versión: 1.0.
1. Definiciones
Incidente: Evento que afecta o puede afectar la confidencialidad, integridad o disponibilidad de la información o sistemas de Lawra, o de los datos de clientes procesados como Encargado.
Brecha de seguridad: Incidente confirmado que resulta en acceso no autorizado, exposición, alteración o destrucción de datos personales.
Cuasi-incidente: Evento que pudo haber resultado en incidente pero fue contenido a tiempo. También se reportan y analizan, sin notificación regulatoria.
2. Severidades
| Nivel | Definición | Ejemplos | Tiempo de respuesta |
|---|---|---|---|
| P0 — Crítico | Afecta a múltiples clientes o expone datos confidenciales / personales sensibles | Brecha confirmada con datos de clientes; ransomware en producción; compromiso de credenciales del Gerente | < 30 min |
| P1 — Alto | Afecta a un cliente o expone datos internos confidenciales | Compromiso de cuenta interna sin escalada; pérdida de laptop con datos cifrados | < 2 horas |
| P2 — Medio | Afecta operaciones internas, sin impacto a clientes | Phishing intentado contra empleado; vulnerabilidad descubierta en dependencia | < 8 horas |
| P3 — Bajo | Anomalía menor, riesgo limitado | Login fallido masivo bloqueado por sistema; alerta automatizada de origen conocido | < 24 horas |
3. Roles del Equipo de Respuesta
| Rol | Responsable | Funciones |
|---|---|---|
| Incident Commander (IC) | Gerente o Oficial de Cumplimiento | Coordina respuesta global; toma decisiones críticas; comunica con socios |
| Líder Técnico | Senior Engineering | Contiene + erradica + recupera técnicamente |
| Líder de Comunicaciones | Gerente o designado | Comunicación con clientes, autoridades, medios |
| Asesoría Legal Interna | Tanya / Ana Carolina | Evalúa obligaciones legales de notificación |
| Documentador | Designado al inicio del incidente | Mantiene timeline detallado para post-mortem y auditoría |
En equipos pequeños (etapa actual de Lawra), una sola persona puede asumir múltiples roles, pero siempre debe haber separación entre IC y Documentador.
4. Fases de Respuesta (NIST 800-61 adaptado)
Fase 1 — Preparación
Continua, no incidental.
- Esta política existe y se ha capacitado;
- Backups verificados trimestralmente;
- Logs activos con retención de 12+ meses;
- Tabletop exercise anual;
- Lista de contactos de emergencia actualizada (asesoría legal, banco, sub-procesadores, autoridades);
- Templates de comunicación pre-aprobados.
Fase 2 — Identificación / Detección
Detección posible mediante:
- Alertas automáticas (Firebase Auth anomalies, vulnerability scanners, monitoring tools);
- Reportes de empleados / contratistas (canal:
security@lawra.io); - Reportes de usuarios / clientes;
- Reportes de bug bounty / disclosure responsable;
- Avisos de sub-procesadores;
- Hallazgos de auditoría.
Acciones inmediatas tras detección:
- Confirmar el evento — ¿es real o falso positivo?
- Asignar IC dentro del tiempo de respuesta de la severidad estimada.
- Abrir el incidente en el log centralizado (incluso una hoja Google Doc compartida vale al inicio).
- Clasificar la severidad provisional.
Fase 3 — Contención
Objetivo: detener la propagación, sin perder evidencia.
Acciones según escenario:
| Escenario | Acción inmediata |
|---|---|
| Compromiso de credenciales | Revocar tokens activos; rotar credenciales; forzar logout |
| Ransomware / código malicioso | Aislar red; desconectar dispositivo afectado; NO apagar sin antes preservar memoria |
| Brecha de datos vía aplicación | Deshabilitar la función afectada; bloquear IPs origen; activar WAF reglas adicionales |
| Pérdida de dispositivo | Remote wipe (si activado); reportar a TI / proveedor cloud; revocar accesos asociados |
| Brecha en sub-procesador | Recibir notificación; evaluar exposición; coordinar respuesta con el proveedor |
Fase 4 — Erradicación
- Identificar y eliminar la causa raíz (no solo el síntoma);
- Parchear vulnerabilidades explotadas;
- Cambiar todas las credenciales potencialmente comprometidas;
- Limpiar sistemas afectados.
Fase 5 — Recuperación
- Restaurar sistemas desde backups limpios verificados;
- Validar integridad antes de poner en producción;
- Monitoreo intensificado durante 30 días post-incidente;
- Comunicar restauración a stakeholders afectados.
Fase 6 — Lecciones Aprendidas (Post-Mortem)
Dentro de 7 días post-incidente, el IC convoca un post-mortem blameless:
- Timeline detallado de eventos;
- Causa raíz identificada;
- Qué funcionó y qué falló;
- Acciones de mejora con responsables y fechas;
- Actualización de runbooks, controles, capacitaciones según lecciones.
Reporte a la Asamblea trimestralmente (incidentes resueltos del trimestre + acciones implementadas).
5. Notificaciones Obligatorias
5.1 Internas (siempre)
- Socios fundadores: inmediatamente al confirmarse incidente P0 / P1.
- Empleados afectados: dentro de 24 horas.
5.2 A clientes
- Si afecta datos del cliente: notificación dentro de 48 horas del descubrimiento, conforme a obligación contractual del DPA.
- Información mínima: qué pasó, cuándo, qué datos afectados, medidas tomadas, recomendaciones al cliente.
5.3 A autoridades regulatorias
| Autoridad | Cuándo | Plazo | Notas |
|---|---|---|---|
| Autoridad de Protección de Datos R.D. (cuando se constituya bajo Ley 172-13 modificada) | Brecha que afecte datos personales | Sin demora indebida | Por confirmar plazo exacto cuando se constituya |
| EDPB / Autoridad nacional UE | Brecha que afecte residentes UE | 72 horas desde el descubrimiento | GDPR Art. 33; vía formulario de la Autoridad |
| ANPD (Brasil) | Brecha que afecte residentes Brasil | ”Em prazo razoável” (interpretado: 2-3 días hábiles) | LGPD Art. 48 |
| California Attorney General | Brecha que afecte ≥500 residentes CA | Sin demora indebida | CCPA / Cal. Civ. Code §1798.82 |
| MINUTUR / DGII / Superintendencia (R.D., según sector) | Si aplica regulación sectorial | Variable | Coordinación con asesoría legal |
5.4 A titulares de datos
- Si el incidente representa alto riesgo para los derechos y libertades del titular: notificación directa sin demora indebida (GDPR Art. 34; LGPD Art. 48);
- Excepción: si los datos afectados estaban cifrados con cifrado robusto y la llave no se comprometió, la notificación a titulares puede no ser obligatoria.
5.5 Plantillas de comunicación
Mantenidas en internal/templates/incident-response/:
- Notificación a clientes (DPA-compliant)
- Notificación regulatoria (GDPR Art. 33 form)
- Comunicación interna a equipo
- Comunicación pública (página de status / aviso del sitio)
- Press release (solo P0)
6. Documentación Obligatoria por Incidente
Para cada incidente se mantiene:
- Timeline detallado (fecha/hora de cada evento, acción y responsable);
- Datos afectados (categorías, número estimado de titulares, tipos);
- Vector / causa raíz identificado;
- Medidas de contención y erradicación ejecutadas;
- Comunicaciones realizadas (con quién, cuándo, qué se dijo);
- Lecciones aprendidas y acciones de mejora;
- Estado de cierre del incidente.
Retención: mínimo 5 años.
7. Tabletop Exercise Anual
Una vez al año, el equipo ejecuta un escenario hipotético (ej. “compromiso de cuenta del Gerente vía phishing”, “brecha en Firebase Authentication”, “ransomware en el sitio”) siguiendo este Plan.
Output del tabletop: revisión + actualización del Plan, identificación de gaps, capacitación.
8. Contactos de Emergencia
Internos:
- Gerente: [tel + email]
- Tanya Mejía-Ricart (asesoría legal interna): [tel + email]
- Ana Carolina Blanco (asesoría legal interna): [tel + email]
Externos:
- Notario: [a designar]
- Banco principal: [a designar]
- Cyber liability insurer: [a designar — Sprint 7E]
- DGII: [contacto fiscal]
- Sub-procesadores principales: Google Cloud Support, Anthropic Support, GitHub Support
Mantener actualizada esta lista trimestralmente.
Adoptado por la Asamblea General de Socios en fecha [__]. Próxima revisión + tabletop: [fecha + 12 meses].
Por LAWRA, S.R.L. — Gerente
Comments
Loading comments...