D4 · Respuesta a incidentes
Este plan define cómo se detecta, contiene, analiza, corrige y comunica un incidente de seguridad en Bolívar Connect, y quién hace cada cosa.
1. Qué es un incidente
Sección titulada «1. Qué es un incidente»Cualquier evento que compromete o puede comprometer la confidencialidad, integridad o disponibilidad de la plataforma o de sus datos. Por ejemplo:
- uso de una API key por quien no debe, o una credencial expuesta;
- acceso de un tenant a datos de otro;
- instrucciones de pago duplicadas, alteradas o no autorizadas;
- exposición de datos personales;
- caída del servicio o de una entidad financiera regulada;
- actividad anómala en la infraestructura.
2. Severidad
Sección titulada «2. Severidad»| Nivel | Criterio | Respuesta inicial |
|---|---|---|
| SEV1 — Crítico | Datos personales expuestos, instrucciones no autorizadas, acceso entre tenants o servicio caído | Inmediata, en cualquier horario |
| SEV2 — Alto | Credencial comprometida sin uso confirmado, degradación grave o fallo de un tercero | En menos de 4 horas |
| SEV3 — Medio o bajo | Evento sospechoso sin impacto confirmado | En el siguiente día hábil |
3. Roles
Sección titulada «3. Roles»| Rol | Quién | Función |
|---|---|---|
| Coordinador del incidente | Responsable de seguridad | Declara el incidente, fija la severidad, decide y coordina |
| Equipo técnico | Personal técnico de guardia | Contiene, analiza y corrige |
| Comunicación | Dirección | Avisa a clientes, terceros y autoridades cuando corresponde |
Cualquier persona del equipo que detecte un posible incidente lo reporta de inmediato al Coordinador.
4. Fases
Sección titulada «4. Fases»4.1 Detección y registro
Sección titulada «4.1 Detección y registro»Fuentes: rechazos anómalos de autenticación y de rate limiting, errores del circuit breaker de terceros, diferencias en la conciliación, avisos de clientes o terceros, y alertas de AWS. Se abre un registro del incidente con la hora de detección, la fuente y la severidad inicial.
4.2 Contención
Sección titulada «4.2 Contención»| Situación | Acción |
|---|---|
| API key comprometida | Revocación inmediata y emisión de una nueva al cliente |
| Secreto de webhooks expuesto | Rotación del secreto |
| Credencial de tercero o de infraestructura expuesta | Rotación en AWS Secrets Manager y reinicio del servicio |
| Tráfico malicioso | Restricción por IP en el grupo de seguridad |
| Beneficiario sospechoso | Bloqueo del beneficiario |
| Tercero con fallos | Circuit breaker, que lo saca de servicio |
| Compromiso de un servidor | Aislamiento de la instancia y recreación desde la infraestructura como código |
La evidencia se preserva antes de cualquier cambio destructivo: logs, snapshots y registro de auditoría.
4.3 Análisis
Sección titulada «4.3 Análisis»Se reconstruye lo ocurrido con el request_id de cada petición, el registro de
auditoría, el historial de estados de cada instrucción de pago y los logs de
AWS. Se determinan la causa raíz, el alcance (tenants, instrucciones y datos
afectados) y la ventana temporal.
4.4 Corrección y recuperación
Sección titulada «4.4 Corrección y recuperación»Se corrige la causa raíz con una prueba de regresión y se valida el servicio. Si hubo instrucciones de pago afectadas, se concilia contra el registro de la entidad financiera regulada antes de dar el incidente por cerrado.
4.5 Comunicación
Sección titulada «4.5 Comunicación»| A quién | Cuándo | Qué |
|---|---|---|
| Clientes afectados | En menos de 24 horas desde la confirmación de un SEV1 o SEV2 que los afecte | Alcance, impacto, medidas tomadas y siguiente actualización |
| Entidad financiera regulada | Cuando el incidente afecte a instrucciones que se le enviaron | Instrucciones afectadas y acción requerida |
| Autoridad de protección de datos | En menos de 72 horas cuando haya brecha de datos personales sujeta al RGPD o a la normativa aplicable | Lo exigido por la norma |
4.6 Cierre y lecciones aprendidas
Sección titulada «4.6 Cierre y lecciones aprendidas»En los 10 días hábiles siguientes al cierre de un SEV1 o SEV2 se redacta un informe con la cronología, la causa raíz, el impacto, las acciones correctivas y sus responsables. Las acciones se siguen hasta cerrarse.
5. Pruebas del plan
Sección titulada «5. Pruebas del plan»El plan se prueba al menos una vez al año con un ejercicio de mesa sobre un escenario realista, por ejemplo una API key filtrada o la caída de un tercero. El resultado y las mejoras se registran.
6. Contactos
Sección titulada «6. Contactos»La lista de contactos de escalado (equipo, Dirección, terceros y clientes) se mantiene actualizada fuera de este documento y se revisa en cada prueba del plan.