Respuesta a incidentes — qué hacer cuando todo falla

Cualquier sistema SSI gob enfrentará incidentes. La pregunta no es si — es cuándo + cómo se responde. Esta guía cubre los escenarios típicos + sus respuestas operativas.

Los 5 incidentes típicos

Cinco escenarios que debe planificar todo proyecto SSI:

1. Compromiso de clave del issuer

El peor caso: la clave privada del issuer fue robada o comprometida.

Respuesta inmediata:

1. 1
   Detectar. Monitoring + alertas indica firma sospechosa (volumen anormal, IP inusual).
2. 2
   Confirmar. Audit del HSM, logs, certifications.
3. 3
   Contener. Desactivar el HSM comprometido. Detener emisión.
4. 4
   Notificar. AAIP, organismos relacionados, AAIP, ciudadanos afectados.
5. 5
   Revocar. Toda credencial emitida con la clave comprometida.
6. 6
   Rotar. Generar nueva clave en HSM nuevo.
7. 7
   Re-emitir. Las credenciales legítimas con la nueva clave.
8. 8
   Investigar. Cómo sucedió + cómo evitar recurrencia.

Costo operativo: enorme. Tiempo: semanas a meses. Pero necesario.

2. Bug en código del issuer

Caso menos severo: un bug del sistema causa emisión incorrecta de credenciales (datos errados, formato malo, firma mala).

Respuesta:

1. 1
   Detectar. Reportes de verifiers + monitoring de error rates.
2. 2
   Triagear. ¿Qué credenciales están afectadas? ¿Cuántas?
3. 3
   Detener emisión del tipo afectado.
4. 4
   Identificar root cause y fix.
5. 5
   Decidir alcance de re-emisión. Solo las erróneas o todas las del período?
6. 6
   Re-emitir las afectadas.
7. 7
   Comunicar a los holders y verifiers afectados.

3. Fraude en emisión

El caso interno: alguien con acceso al sistema emite credenciales fraudulentas.

Respuesta:

1. 1
   Detectar. Audits internos + comportamiento anormal de funcionario.
2. 2
   Aislar. Suspender accesos al funcionario sospechoso.
3. 3
   Investigar. Auditoría forense del sistema.
4. 4
   Revocar. Credenciales fraudulentas identificadas.
5. 5
   Reportar. Autoridades + AAIP + ciudadanos afectados.
6. 6
   Reforzar controles. Para que no se repita.

4. Cool-down del HSM

Caso operacional: el HSM se rompe o tiene problemas. No comprometido, solo no operativo.

Respuesta:

1. 1
   Detectar. Monitoring + alertas de operations.
2. 2
   Activar HSM secundario (que debe existir como parte del plan).
3. 3
   Continuar emisión con el secundario mientras se diagnostica.
4. 4
   Diagnosticar y reparar el primario.
5. 5
   Restaurar la redundancia cuando esté listo.

Si no hay HSM secundario, el servicio se interrumpe temporalmente. Por eso el secundario es prerequisito operativo.

5. Disclosure pública de datos

Caso de privacy: se filtran datos del sistema (PII de ciudadanos, logs, etc.).

Respuesta:

1. 1
   Detectar. Reportes externos + monitoring.
2. 2
   Confirmar magnitud. Qué datos, cuántos individuos.
3. 3
   Notificar. AAIP (obligación regulatoria), ciudadanos afectados (LPDP).
4. 4
   Contener. Cerrar el vector de disclosure.
5. 5
   Investigar root cause.
6. 6
   Compensar daño cuando aplique.
7. 7
   Reforzar controles y comunicar lecciones aprendidas.

Los 4 principios del incident response

Sin importar el tipo de incidente:

El plan de respuesta a incidentes

Documentación obligatoria antes del primer incidente:

• Roster de personas: quién toma qué decisión.
• Procesos por tipo de incidente: los 5 anteriores + others específicos.
• Comunicación interna: Slack, email, calls.
• Comunicación externa: AAIP, ciudadanos, medios.
• Templates de comunicación: pre-aprobados para situaciones comunes.
• Plan de continuidad: cómo opera el sistema durante el incidente.

Sin esto documentado, durante el incidente se improvisa — y se improvisa mal.

El equipo de respuesta

Composición típica:

Estos roles deben estar preparados antes del incidente, no improvisados durante.

El post-mortem

Después del incidente, escribir un post-mortem riguroso:

• ¿Qué pasó? Timeline detallado.
• ¿Por qué pasó? Root cause analysis.
• ¿Qué se hizo? Acciones tomadas.
• ¿Qué se aprendió? Lecciones para el futuro.
• ¿Qué cambia? Cambios concretos en procesos / sistema / equipo.

Idealmente, el post-mortem es publicado (al menos versión sanitizada). Esto:

• Construye confianza pública.
• Permite que otras provincias / organismos aprendan.
• Demuestra responsabilidad organizacional.

Los benchmarks internacionales

Casos de incidentes públicos bien manejados:

• Estonia 2017 ID card crisis: vulnerabilidad criptográfica en chips de DNI. Estonia revocó + re-emitió todos. Confianza preservada.
• Aadhaar India incidents: múltiples disclosures handled con transparencia variable. Aprendizajes mixtos.

Argentina puede aprender de ambos: la respuesta importa más que la prevención perfecta.

Referencias

• NIST SP 800-61 — Computer Security Incident Handling Guide
• Estonia ID Card Crisis Post-Mortem

Relacionados

• Key management del issuer — el corazón de la seguridad — la prevención
• Audit trail y compliance — trazabilidad sin tracking — la detección
• ¿Cómo empieza una provincia con SSI? — el contexto