Respuesta a incidentes cibernéticos: las 4 fases del NIST
Las 4 fases del NIST SP 800-61, el escenario de las 02:17 y cómo reducir un dwell time de 194 días a minutos.
El NIST SP 800-61r2 (Computer Security Incident Handling Guide) sigue siendo la referencia para estructurar la respuesta a incidentes. No porque sea un documento estadounidense, sino porque las 4 fases que describe corresponden exactamente a la realidad operativa. El problema: 194 días de dwell time promedio (IBM 2025) demuestran que la mayoría de las organizaciones fallan desde la fase 2.
Fase 1: Preparación
La preparación es la fase más descuidada y la más determinante. Se divide en dos componentes:
Componente técnico
-
Inventario de activos: no puede proteger lo que no conoce. Mapeo de red, CMDB actualizada, Shadow IT identificado.
-
Monitoreo desplegado: SIEM operativo, EDR en los endpoints, logs centralizados (red, identidad, nube, aplicaciones)
-
Línea base establecida: ¿qué es "normal" en su red? Sin línea base, toda alerta es ruido de fondo.
-
Herramientas forenses listas: imágenes forenses preconfiguradas, acceso a snapshots, cadena de custodia documentada
Componente organizacional
-
Playbooks de incidentes: no un documento de 200 páginas que nadie lee. Fichas de referencia rápida de 2 páginas por escenario (ransomware, phishing, compromiso de cuentas, fuga de datos).
-
Equipo de respuesta identificado: quién hace qué, contactos actualizados, guardias definidas
-
Comunicación de crisis: plantillas prediseñadas para la dirección, los clientes y los reguladores
-
Ejercicios regulares: un ejercicio tabletop por trimestre como mínimo. Simule el escenario de las 02:17 un domingo, ¿quién responde? ¿En cuánto tiempo?
ThreatClaw cubre el componente técnico de la preparación en 48h: despliegue de agentes, línea base de comportamiento en 14 días, 49 habilidades de auditoría listas para usar.
Fase 2: Detección y Análisis
Aquí es donde todo se juega, y donde la mayoría de las organizaciones fallan. La detección se basa en tres pilares:
-
Detección por firmas: reglas YARA, Sigma, Snort/Suricata. Eficaz contra amenazas conocidas. Inútil contra zero-days o LOLBins (Living Off The Land).
-
Detección por anomalías: ML/comportamental. Identifica desviaciones respecto a la línea base. Es lo que atrapa las amenazas desconocidas, un usuario que ejecuta PowerShell por primera vez, un servidor que contacta un dominio nunca visto.
-
Threat intelligence: feeds de IoC (MISP, OTX, VirusTotal), correlación con campañas activas.
El análisis es el cuello de botella. Un SOC recibe 4 500 alertas/día (Splunk 2024). El analista debe determinar: ¿es un verdadero positivo? ¿Cuál es el impacto? ¿Cuál es el alcance? ¿Cuáles son los siguientes pasos? Este proceso de triaje toma 15-25 minutos por alerta, y explica por qué el 68 % de las alertas permanecen sin investigar.
El agente ThreatClaw automatiza el triaje: correlación multi-fuente, enriquecimiento contextual (¿la alerta es sobre un servidor de producción o una estación de desarrollo?), puntuación de criticidad adaptada a su entorno. El tiempo de triaje pasa de 20 minutos a 3 segundos.
Fase 3: Contención, Erradicación y Recuperación
Una vez confirmado el incidente, comienza la carrera contra el reloj.
Contención
La contención debe ser inmediata y proporcionada. Dos estrategias:
-
Contención a corto plazo: aislar el sistema comprometido de la red (VLAN de cuarentena, desactivación del puerto del switch, aislamiento EDR). El objetivo: detener la propagación sin destruir las evidencias.
-
Contención a largo plazo: si la erradicación no es inmediata, implementar controles temporales (reglas de firewall, bloqueo de cuentas, supervisión reforzada de sistemas adyacentes).
El escenario clásico: ransomware detectado a las 02:17 un domingo. El cifrado ha comenzado. Cada minuto cuenta. En modo Autónomo, ThreatClaw aísla la máquina en 90 segundos, bloquea la cuenta comprometida y captura un snapshot forense antes de que el cifrado se propague. En modo Híbrido, le envía la acción propuesta y espera su aprobación, pero para cuando vea el SMS, puede ser demasiado tarde.
Erradicación
-
Identificación y eliminación del malware
-
Cierre del vector de entrada (parche, desactivación del servicio vulnerable)
-
Restablecimiento de credenciales comprometidas
-
Verificación de sistemas adyacentes (¿movimiento lateral?)
Recuperación
-
Restauración desde copias de seguridad verificadas (pruebe sus backups antes del incidente)
-
Retorno progresivo a producción con monitoreo reforzado
-
Validación de que el atacante no dejó persistencia (cuentas, tareas programadas, claves SSH)
Fase 4: Actividad post-incidente
La fase más comúnmente apresurada. Después de un incidente, debe:
-
Post-mortem sin culpas: cronología factual, qué funcionó, qué falló, brechas identificadas
-
Actualización de playbooks: cada incidente debe mejorar su preparación (regreso a la fase 1)
-
Notificaciones regulatorias: RGPD Art.33 (72h a la autoridad de protección de datos), NIS2 Art.23 (24h al CSIRT), e informe final en el plazo de un mes
-
Indicadores de compromiso compartidos: contribuya al MISP de su sector
ThreatClaw genera automáticamente la cronología del incidente, el informe técnico y el informe de notificación regulatoria. El post-mortem toma 2 horas en lugar de 2 días.
Human-in-the-Loop: el equilibrio correcto
La automatización total da miedo, con razón. El concepto de HITL (Human-in-the-Loop) es central. La pregunta no es "¿automatizar o no?" sino "¿automatizar qué?":
-
Automatizar sin dudar: recolección de logs, correlación, enriquecimiento, notificación, generación de informes
-
Automatizar con aprobación: aislamiento de un endpoint, bloqueo de una cuenta, aplicación de una regla de firewall
-
No automatizar: comunicación de crisis, decisión de pagar o no un rescate, notificación a clientes
Los tres modos de ThreatClaw (Centinela, Híbrido, Autónomo) reflejan exactamente estos niveles de confianza. Usted ajusta el nivel.
Preguntas frecuentes
¿Cuál es la diferencia entre un incidente y un evento de seguridad?
Un evento es cualquier ocurrencia observable en un sistema (inicio de sesión, acceso a archivo, consulta DNS). Un incidente es un evento o serie de eventos que viola la política de seguridad o que constituye una amenaza inminente. Todos los incidentes son eventos, pero menos del 1 % de los eventos son incidentes.
¿Cuánto tiempo toma conformar un equipo de respuesta a incidentes?
Para una PyME, el equipo de respuesta suele ser el CISO + el administrador de sistemas + un proveedor externo. La conformación formal toma 2-4 semanas (identificación de roles, contactos, procedimientos). El primer ejercicio tabletop sistemáticamente revela 5-10 brechas críticas. Prevea 3 meses para alcanzar la madurez operativa.
¿NIST o ISO 27035 para estructurar la respuesta?
Ambos son válidos. NIST SP 800-61 es más operativo y concreto. ISO 27035 está más estructurado desde la perspectiva de gobernanza y se integra mejor con un SGSI ISO 27001. En la práctica, las fases son casi idénticas. Elija según su marco de referencia existente.
Mi organización nunca ha tenido un incidente. ¿Por qué invertir en respuesta?
Con todo respeto: probablemente nunca ha detectado un incidente. 194 días de dwell time significa que los atacantes suelen estar presentes sin ser detectados. El costo promedio de una brecha en 2025 es de 4,88 M USD (IBM). La inversión en detección y respuesta no es un costo, es un seguro medible. Compare las opciones.
Artículos relacionados
Gu\u00eda concreta de implementaci\u00f3n Zero Trust: NIST 800-207, microsegmentaci\u00f3n, enfoque identity-first y despliegue progresivo.
Una lista bruta de IP, dominios y hashes es fácil de encontrar y casi sin valor. El valor está en elegir el feed correcto y en explotarlo: licencia, corroboración, caducidad, y la regla que evita bloquear tu propio CDN.
Sale una CVE, el aviso de seguridad es público, pero aún no existe ninguna plantilla Nuclei. Aquí tienes cómo escribir una limpia: partir del hecho, construir los matchers, y sobre todo demostrar que se dispara en un objetivo vulnerable sin gritar en uno parcheado.
Un informe describe una técnica de ataque o la explotación de una CVE. Quieres detectarla en tus logs. Aquí tienes cómo escribir una regla Sigma que se dispare con el comportamiento real, sin inundar al SOC de falsos positivos, y cómo demostrarlo.