Detección de incidentes de seguridad

La detección de incidentes de seguridad es la capacidad de identificar, y de reaccionar rápido ante, eventos o actividad que apuntan a una amenaza o a una brecha de seguridad.

Significa vigilar de forma continua redes, sistemas y aplicaciones, buscando comportamientos anómalos o indicadores de compromiso que señalen un incidente en marcha.

La velocidad y la precisión son lo que hace que valga de algo. La diferencia entre un incidente encontrado en una hora y ese mismo incidente encontrado tres meses después suele ser la diferencia entre un suceso contenido y uno grave.

Qué implica

Vigilancia continua. Observar la actividad según ocurre: eventos de red, registros de sistema, registros de autenticación y cualquier otra cosa que lleve señal, para sacar los patrones que no encajan.

Indicadores de compromiso. Direcciones maliciosas conocidas, patrones de tráfico inusuales, firmas de malware conocidas. Correlacionar varios indicadores es lo que sube la confianza, porque cualquiera de ellos por su cuenta genera más ruido de lo que vale.

Un camino hasta la respuesta. Una detección que acaba en una alerta no es detección. Alguien tiene que poder actuar sobre ella: contener, investigar la causa y aplicar una corrección.

Qué la hace difícil

El volumen. Demasiados datos son un problema en sí mismos. Sin una forma de filtrar, la señal genuina queda enterrada bajo todo lo demás, que es técnicamente cierto y completamente irrelevante.

Los falsos positivos. Cada alerta que nadie tendría que haber mirado cuesta tiempo de analista y, peor todavía, entrena a la gente para ignorar la consola. Aquí la precisión no es un lujo, es lo que mantiene viva la capacidad.

Las técnicas nuevas. La detección describe lo que ya se conoce. El oficio del atacante se mueve, así que las reglas y la inteligencia tienen que moverse con él o la cobertura se degrada en silencio.

Un ejemplo práctico

Una empresa tiene vigilancia desplegada en todo su parque.

Durante la operación normal, el sistema localiza un patrón de tráfico inusual desde un servidor interno hacia una dirección externa asociada con malware, y levanta una alerta.

El equipo de respuesta la recoge e investiga de inmediato. Descubren que un dispositivo interno está comprometido y se está usando para sacar datos sensibles de la red.

Como la actividad se detectó en vez de descubrirse meses después, el equipo puede contener el dispositivo, eliminar el malware y cerrar la vía que se estaba usando.

Quién hace qué en la detección

Esta ficha describe la capacidad. El glosario tiene además una entrada para cada una de las piezas que la componen, y confundirlas es lo que lleva a las organizaciones a comprar una cosa creyendo que es otra.

El SIEM es la plataforma: recoge los registros de todo, los normaliza, los correlaciona y los guarda. Detecta lo que alguien haya escrito como regla, y nada más. Comprarlo no es tener detección.

La ingeniería de detección es la disciplina que escribe y mantiene esas reglas, tratándolas como software: con requisitos, versiones, pruebas y un dueño. Una regla que nadie ha probado ejecutando la técnica en este entorno no es una detección, es una suposición. Y las reglas se estropean en silencio, porque la ausencia de alerta se parece exactamente a la ausencia de ataque.

El threat hunting es la búsqueda deliberada de lo que las reglas no levantaron, partiendo de una hipótesis en vez de una alerta.

La detección de anomalías es un enfoque distinto al de la regla escrita: en vez de describir lo malo, describe lo normal y avisa de lo que se sale.

Y detectar no es responder. Identificar el incidente es lo que cuenta esta ficha; llevarlo hasta cerrarlo es la gestión de incidentes. La separación importa porque el fallo más repetido no es que no se detectara nada. Es que se detectó bien, quedó registrado con la severidad correcta, y nadie abrió la consola.

Dónde leer más

SANS Institute, Incident Handler’s Handbook: una guía práctica de detección y respuesta, que recorre las fases y lo que cada una tiene que producir.

MITRE ATT&CK como marco de respuesta a incidentes: cómo usar la matriz para decidir qué deberías ser capaz de detectar, en vez de catalogar lo que ya detectas.