Conceptos

Incident Response and Incident Management

#defense#governance#logging#soc

Un incidente cibernético suele aparecer después de una cadena previa: evento → alerta → triaje → incidente.

Definición

Un incidente cibernético suele aparecer después de una cadena previa: evento → alerta → triaje → incidente.

  • Evento (event): actividad observable en sistemas/red (p. ej., un login, un proceso, un cambio de configuración).
  • Alerta (alert): evento anómalo o relevante que un control detecta (AV/EDR/SIEM/monitorización). Puede ser falso positivo.
  • Incidente (incident): situación que, tras triaje, tiene potencial de impacto significativo y/o requiere investigación/acciones coordinadas porque aún no se entiende el alcance.

Cuando una alerta “sube” a incidente, suelen entrar dos planos:

  • Incident Response (IR / Respuesta a incidentes): plano técnico para responder “¿qué pasó?” y delimitar alcance.
  • Incident Management (Gestión de incidentes): plano operativo/gestión para responder “¿cómo respondemos?” (priorizar, coordinar, comunicar, documentar, cerrar).

Relacionado:

Contexto

  • Los incidentes son parte de la vida actual; la pregunta no es “si”, sino “cuándo”.
  • Aunque montar una capacidad de IR/IM cuesta, el impacto de un incidente puede ser existencial. El RAW cita a la National Cybersecurity Alliance: ~60% de pequeñas empresas cierran en 6 meses tras un ciberataque.

Desarrollo (MIT-style)

1) Del SOC al incidente: evento → alerta → triaje → incidente

El RAW describe un flujo típico en un SOC (Security Operations Center):

  1. El SOC monitoriza eventos.
  2. Si un evento es anómalo, se genera una alerta.
  3. El SOC investiga la alerta y realiza triaje para estimar gravedad.
  4. Si la gravedad es suficiente (o el alcance es incierto), se declara incidente.

Equipo SOC

Idea clave: el SOC actúa como “filtro”. No todo evento/alerta termina en incidente.

Ejemplo (del RAW):

  • La organización recibe miles de correos de phishing. Muchos se bloquean (spam). Si alguien ejecuta malware, AV/EDR puede bloquearlo automáticamente: esto puede generar alertas que el SOC gestiona (p. ej., ajustando reglas o firmas) sin llegar a “incidente” si el impacto es contenido.

2) Incident Response (IR): “¿qué pasó?”

La respuesta a incidentes cubre el análisis técnico para entender:

  • vector inicial y “kill chain” observada
  • sistemas/cuentas afectadas
  • persistencia, movimiento lateral, exfiltración
  • alcance real (scope)

Fuentes de señales/hallazgos (según RAW):

  • EDR/AV: alertas de actividad anómala en un host (p. ej., keylogging).
  • Alertas de red: comportamiento anómalo (p. ej., un host escaneando otros hosts).
  • SIEM: correlaciones/reglas (p. ej., “viaje imposible”).

Cuando la info de alerta no es suficiente, entra el análisis forense digital (según RAW):

  • Adquisición/investigación de disco del host afectado.
  • Adquisición/investigación de memoria (RAM).
  • Recolección de registros (sistema/red) de múltiples dispositivos.

Riesgo crítico: scope mal estimado (según RAW):

  • Scope “demasiado grande” → acciones más disruptivas de lo necesario.
  • Scope “demasiado pequeño” → erradicación insuficiente y el atacante persiste.

Máquina infectada

3) Incident Management (IM): “¿cómo respondemos?”

La gestión de incidentes coordina el proceso y responde (según RAW):

  • Clasificar y actualizar gravedad conforme llega nueva evidencia.
  • Usar playbooks para guiar acciones.
  • Decidir acciones de contención, erradicación y recuperación.
  • Gestionar comunicación interna/externa.
  • Documentar acciones y su efecto.
  • Cerrar el incidente y capturar aprendizajes.

Punto importante del RAW: no basta con técnica; la gestión es igual de importante.

4) Niveles de respuesta/gestión (escalado)

El RAW propone 4 niveles (ejemplo guía: usuario reporta phishing). A medida que escalas:

  • participa más gente relevante
  • las acciones disponibles son más “potentes”, pero también más disruptivas

Nivel 1 — Incidente SOC

  • Suele ser rápido y técnico; a veces ni se clasifica como “incidente”.
  • Ej.: bloquear remitente y actualizar filtro si es evento aislado.

Nivel 2 — Incidente CERT

  • Entra más personal SOC; investigación adicional porque preocupa el alcance.
  • Ej.: verificar quién recibió el correo, si hubo interacción, qué hacía el correo.

Nivel 3 — Incidente CSIRT

  • SOC en “máxima alerta”; forense + gestión coordinan contención/erradicación/recuperación.
  • Ej.: malware y usuarios que interactuaron; detener propagación y recuperar hosts.

Nivel 4 — Incidente CMT (Crisis Management Team)

  • Cibercrisis a gran escala: dirección + legal + comunicación, y potencialmente externos (regulador/policía).
  • Se contemplan acciones “nucleares” (del RAW): p. ej., desconectar a toda la organización para limitar daños.
  • Gestión del CMT, Hora Dorada, roles, comunicación y proceso cíclico: Crisis Management Team (CMT).

5) Roles típicos durante un incidente (según RAW)

  • Analista SOC: maneja eventos/alertas; suele ser de los primeros en intervenir.
  • Líder/manager del SOC: distribuye tareas y decide escalado; entiende lo técnico para coordinar.
  • Analista forense: investiga artefactos (memoria/disco) para entender qué ocurrió.
  • Analista de malware: profundiza en el malware (debug/decompile), extrae IoCs para detección.
  • Cazador de amenazas (Threat Hunter): busca activamente amenazas y crea reglas/alertas basadas en logs y señales.
  • Primer interviniente (First responder): a veces el incidente aparece primero como “incidente de negocio” (p. ej., app lenta); debe actuar sin destruir evidencia y escalar correctamente. Ver Incident First Responder (Evidence Preservation and Escalation).
  • Ingeniero de seguridad: SME del sistema/división; ayuda en investigación y asegura que el SOC reciba logs relevantes.
  • Oficial de seguridad de la información (ISO): más gestión; enlace entre IR/IM y su división para ejecutar acciones.
  • Gerente de incidentes (Incident Manager): coordina el proceso y documentación; asigna responsables y seguimiento.
  • Propietario del producto/proyecto: SME del servicio en entrega continua; colabora en investigación y mitigación.
  • Experto en la materia (SME): experto puntual (p. ej., admin de AD) para acotar alcance y medidas.
  • Gerente de crisis: lidera el CMT; asegura funcionamiento del equipo de crisis.
  • Ejecutivos (CEO/COO/CIO/CTO/CISO, etc.): participan en CMT cuando el incidente escala a crisis.

6) Proceso “tipo NIST” de gestión de incidentes

El RAW indica que muchas organizaciones basan su proceso en NIST (SP 800-61r2):

Marco de gestión de incidentes del NIST

6.1 Preparación

Objetivo: reducir errores bajo estrés (según RAW). Acciones típicas (RAW):

  • Identificar stakeholders y árboles de llamadas.
  • Crear/actualizar manuales/playbooks.
  • Practicar con tabletop exercises y juegos de guerra cibernética.
  • Hacer threat hunting continuo para crear nuevas reglas/alertas.

6.2 Detección y análisis (incluye triaje)

El RAW explica que a veces se separa “triaje” como etapa intermedia, pero NIST lo incluye aquí. Acciones típicas (RAW):

  • Revisar alertas en paneles de AV/EDR/SIEM.
  • Forense de artefactos en sistemas y red.
  • Analizar malware para entender comportamiento y generar firmas/detecciones.

6.3 Contención, erradicación y recuperación

Definiciones (RAW):

  • Contención: “detener la hemorragia” (evitar que empeore).
  • Erradicación: eliminar al agente amenazante del entorno.
  • Recuperación: volver a BAU (normalidad operativa).

Nomenclatura alternativa (RAW): muchas guías lo resumen en 6 fases: Preparación, Identificación, Contención, Erradicación, Recuperación y Lecciones aprendidas (mapea con NIST + post‑incidente).

Métodos típicos de contención/aislamiento (RAW, ejemplos):

  • Segmentación de red (mover el host a un segmento aislado) para frenar propagación.
  • Aislamiento físico (retirar/confiscar el host) cuando se requiere preservar evidencia y detener acciones.
  • Aislamiento virtual (EDR) para restringir comunicaciones de forma remota (con caveat: si EDR está comprometido puede fallar).
  • En casos puntuales, limitar conectividad (“hacerlo lento”) para ganar tiempo de observación sin levantar sospechas inmediatas.

Orden importa (RAW): si erradicas/recuperas antes de contener, el atacante puede persistir.
Ejemplo del RAW: si AD está comprometido, cambiar contraseñas sin cerrar acceso primero puede permitir al atacante recuperar credenciales.

Además, el RAW indica que fases 2–3 son cíclicas: se actúa mientras se sigue entendiendo el alcance, observando el efecto de medidas hasta volver a normalidad.

Nota de continuidad (BCP/DR): en incidentes severos, la organización puede invocar un BCP para acelerar decisiones/cambios y volver a BAU (sin sustituir contención). Ver Business Continuity Plan (BCP) and Business Impact Analysis (BIA).

6.4 Post-incidente

Último paso (RAW): evaluar lo ocurrido, capturar lecciones y mejorar preparación/procesos para el siguiente incidente.

Ejemplos

Ejemplo 1 — Login anómalo (del RAW)

Una alerta de login anómalo puede requerir responder preguntas como:

  1. ¿De quién es la cuenta?
  2. ¿Desde dónde se inició sesión?
  3. ¿Dónde se usaba esa cuenta antes?
  4. ¿Hay más actividad anómala asociada?

Ejemplo 2 — Phishing escalando niveles (del RAW)

  • Nivel 1: correo aislado → bloquear remitente/regla.
  • Nivel 2: múltiples destinatarios → ampliar investigación.
  • Nivel 3: malware + interacción → contención/erradicación/recuperación coordinada.
  • Nivel 4: impacto masivo → CMT + posibles acciones disruptivas.

Pitfalls / Errores comunes (del RAW + ampliación)

  • Endurecimiento insuficiente: omitir hardening aumenta incidentes; moverlo a etapas tempranas (“shift left”). Ver DevSecOps, Secure SDLC (SSDLC).
  • Registro insuficiente: sin logs suficientes el blue team opera “a ciegas”; el coste de ingesta/telemetría y la baja retención local empeoran el problema.
  • Alerta insuficiente o excesiva: demasiados falsos positivos → “fatiga” y se ignoran alertas (“grito de lobo”); demasiada poca alerta → incidentes detectados tarde. El threat hunting debe optimizar señal/ruido.
  • Alcance mal determinado: subestimar deja persistencia; sobreestimar genera interrupción innecesaria.
  • Responsabilidad insuficiente: se discuten acciones pero nadie las ejecuta; IM debe asignar owner y documentar.
  • Backups insuficientes: sin copias no hay recuperación real tras ransomware; además, DR “siempre online” puede replicar el cifrado: se necesitan copias remotas y/o offline.

Diagrama

flowchart TD
E[Eventos] --> A[Alertas]
A --> TR[Triage]
TR -->|impacto alto o alcance incierto| INC[Incidente]
TR -->|falso positivo o impacto contenido| CLOSE[Cerrar/ajustar reglas]

INC --> DA[Detección y análisis]
DA --> CER[Contención / Erradicación / Recuperación]
CER -->|iterar| DA
CER -->|BAU| POST[Post-incidente]
POST --> PREP[Preparación]
PREP --> E

Referencias

  1. TryHackMe — Introducción a la seguridad defensiva: https://tryhackme.com/jr/defensivesecurity
  2. NIST SP 800-61r2 — Computer Security Incident Handling Guide (PDF): https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
  3. National Cybersecurity Alliance: https://staysafeonline.org/
  4. TryHackMe — Secure SDLC (mencionado por el RAW al hablar de “Shift Left”): https://tryhackme.com/jr/securesdlc