NIST CSF 2.0 — DETECT: Ver el ataque antes de que sea tarde
TechCorp Latam tenía controles implementados. Pero sin visibilidad, un atacante podía operar durante días sin ser detectado. DETECT es la función que cambia eso. Analizamos sus 2 categorías, construimos el flujo de detección y vemos las primeras alertas reales.
El problema de la ceguera operacional
TechCorp Latam llegó al Post 3 con algo que no tenía antes: controles de protección activos. MFA habilitado, EDR desplegado en 73% de los endpoints, firewall revisado, backups funcionando. Una base sólida.
Pero hay una trampa en la que caen muchas organizaciones después de implementar PROTECT: asumir que los controles bastan. Que si el firewall bloquea y el EDR está activo, no hay más que hacer hasta que ocurra algo.
Esa asunción es peligrosa. El tiempo promedio que un atacante permanece dentro de una red antes de ser detectado es, según estudios de la industria, más de 200 días en organizaciones sin capacidades de detección activa. Durante ese tiempo puede moverse lateralmente, exfiltrar datos, escalar privilegios y preparar el ataque definitivo.
"Un control de protección que nadie monitorea es una puerta cerrada sin cámara. Puede que funcione. Puede que no. Sin detección, nunca lo sabrás."
La función DETECT (DE) cierra esa brecha. Su objetivo es que la organización tenga la capacidad de identificar oportunamente cuando ocurre un evento de ciberseguridad — sea un ataque activo, un comportamiento anómalo o un indicador de compromiso.
¿Qué cubre la función DETECT en el NIST CSF 2.0?
DETECT es la función más acotada del framework en términos de estructura: solo 2 categorías y 7 subcategorías. Pero no por eso es simple — su implementación efectiva requiere integrar fuentes de datos, herramientas de correlación y procesos de respuesta en tiempo real.
| Código | Categoría | Resultado esperado |
|---|---|---|
| DE.CM | Continuous Monitoring | Los activos son monitoreados para identificar anomalías, indicadores de compromiso y otros eventos potencialmente adversos. Cubre redes, endpoints, aplicaciones, nube y actividad de usuarios. |
| DE.AE | Adverse Event Analysis | Las anomalías son analizadas para caracterizar los eventos adversos y evaluar su impacto potencial. Incluye correlación de eventos, estimación de alcance y notificación a partes interesadas. |
En la v1.1, DETECT tenía 3 categorías: Anomalies and Events (AE), Security Continuous Monitoring (CM) y Detection Processes (DP). En la v2.0 se consolidaron en 2: DE.CM absorbe el monitoreo continuo y la detección de procesos, mientras DE.AE profundiza en el análisis y la respuesta inicial al evento detectado.
El indicador clave de DETECT: MTTD
La función DETECT se mide principalmente con el MTTD (Mean Time To Detect) — el tiempo promedio entre el inicio de un ataque o anomalía y su detección por el equipo de seguridad. Un MTTD alto significa que los atacantes tienen más tiempo para actuar antes de ser detectados.
- Sin capacidades de detección: MTTD estimado > 72 horas (3 días) en entornos como el inicial de TechCorp Latam
- Con SIEM básico configurado: MTTD objetivo < 4 horas en el primer trimestre
- Con reglas de correlación maduras: MTTD objetivo < 30 minutos a mediano plazo
Paso a paso: Cómo implementar DETECT desde cero
La clave para implementar DETECT en una organización mediana es no intentar construir un SOC desde el día uno. El camino es iterativo: fuentes de log primero, correlación básica después, reglas avanzadas con el tiempo.
-
Centralizar los logs en un único punto (DE.CM)
Sin centralización no hay correlación. El primer paso es enviar los logs de tus fuentes más críticas — firewall, Active Directory / Azure AD, endpoints y servidores — a un colector centralizado. Herramientas accesibles para PyMEs: Wazuh (open source, gratuito), Graylog (community edition) o Microsoft Sentinel (incluido en algunos planes M365).
-
Habilitar alertas nativas de las plataformas que ya usas (DE.CM)
Antes de implementar herramientas nuevas, activa las alertas que ya tienes disponibles: Microsoft Defender alertas de identidad, Azure AD Identity Protection, las alertas de tu firewall y las notificaciones del EDR. Esto da visibilidad inmediata con cero inversión adicional.
-
Definir las reglas de detección prioritarias (DE.AE)
No intentes detectar todo desde el inicio — es la receta para el fatigue de alertas. Empieza con las 10 reglas de mayor impacto: múltiples fallos de login, acceso desde IPs anómalas, ejecución de PowerShell ofuscado, transferencias masivas de datos y acceso fuera de horario laboral. El framework SIGMA ofrece reglas reutilizables y gratuitas.
-
Establecer un proceso de triaje de alertas (DE.AE)
Una alerta sin proceso de análisis no sirve. Define quién revisa las alertas, en qué horario, con qué criterio de escalada y con qué tiempo máximo de respuesta inicial. Para medianas empresas sin SOC: un turno de revisión diaria de alertas priorizadas es suficiente para empezar.
-
Integrar inteligencia de amenazas básica (DE.AE)
Añadir listas de IPs maliciosas conocidas, dominios de C&C y hashes de malware a tus reglas de detección multiplica la efectividad sin costo. Fuentes gratuitas: MISP, AlienVault OTX, CISA Known Exploited Vulnerabilities y VirusTotal para verificación puntual.
-
Medir el MTTD desde el primer día (DE.AE)
Lo que no se mide no mejora. Registra en cada alerta la hora en que ocurrió el evento y la hora en que fue detectado. La diferencia es tu MTTD. Establece un objetivo trimestral y revísalo en el comité de ciberseguridad. Esta métrica es el indicador más honesto de tu capacidad de detección real.
La arquitectura de detección: fuentes, correlación y alerta
Implementar DETECT no significa necesariamente comprar un SIEM enterprise de seis cifras. Significa construir un flujo coherente desde las fuentes de datos hasta la alerta accionable. TechCorp Latam lo hizo con herramientas de código abierto y las funciones nativas de Microsoft 365.
El mayor error al implementar un SIEM es activar todas las reglas disponibles desde el inicio. El volumen de alertas se vuelve inmanejable, el equipo empieza a ignorarlas y la detección real cae. TechCorp Latam empezó con 10 reglas de alta precisión y las fue refinando antes de añadir más.
TechCorp Latam: Las primeras 48 horas de detección activa
En la primera semana tras desplegar Wazuh y activar Microsoft Defender Identity, el equipo de TechCorp Latam recibió 8 alertas reales. Dos de ellas eran incidentes activos que requerían acción inmediata. Sin capacidades de detección, habrían pasado desapercibidos durante días o semanas.
🏢 TechCorp Latam — Resultados de DETECT (semana 2)
El hallazgo más impactante fue la alerta de inicio de sesión desde una IP de red Tor — una cuenta de empleado comprometida que intentaba acceder a Azure AD. Sin DETECT, este acceso habría pasado completamente desapercibido. Con DETECT, fue bloqueado automáticamente en minutos y la cuenta fue asegurada. Esa sola alerta justificó toda la implementación.
Conclusión: DETECT como el sistema nervioso de la ciberseguridad
Si GOVERN es la columna vertebral del programa, DETECT es su sistema nervioso. Sin detección activa, la organización opera a ciegas — confiando en que los controles de PROTECT nunca fallen. Y eventualmente, fallan.
TechCorp Latam pasó de un MTTD estimado de más de 3 días a menos de 2 horas, sin inversión adicional, usando herramientas open source y las capacidades nativas de su stack existente. La diferencia no fue tecnológica — fue organizacional: alguien revisa las alertas, hay reglas claras de escalada y hay un proceso definido de triaje.
Pero TechCorp Latam está a punto de necesitar todo esto. En el siguiente post, el equipo enfrenta lo que tanto GOVERN, IDENTIFY, PROTECT y DETECT estaban preparando para contener: un incidente de ransomware real. Así comienza RESPOND.
📅 Serie: NIST CSF 2.0 en la práctica
Una publicación por día · Caso de estudio: TechCorp Latam
No hay comentarios.:
Publicar un comentario