Qué es detection engineering y qué problema resuelve

Imagine que trabaja en el SOC de Cooperativa Pacífico Sur, una entidad financiera ficticia de Pérez Zeledón. Cada mañana llegan 900 alertas; el equipo cierra 850 como falsos positivos y, de vez en cuando, un incidente real pasa sin que ninguna regla lo vea. El problema no es la gente del SOC: es la calidad de las detecciones. De eso se ocupa la ingeniería de detecciones, conocida en inglés como detection engineering.

Una definición práctica

La ingeniería de detecciones es la disciplina que diseña, construye, prueba, despliega y mantiene la lógica que convierte datos de seguridad en alertas útiles. Una detección no es solo una consulta en el SIEM: es un producto con un objetivo, un dueño, documentación, pruebas y un ciclo de vida.

La palabra clave es ingeniería: la regla se trata como software. Se versiona, la revisa otra persona, se prueba contra datos conocidos y se mide si funciona.

Qué problema resuelve

Sin ingeniería de detecciones, los SOC suelen caer en tres trampas:

• Ruido: reglas genéricas que disparan con cualquier tarea administrativa, hasta que los analistas cierran alertas sin leerlas (fatiga de alertas).
• Ceguera: técnicas de ataque frecuentes para las que no existe ninguna regla, o reglas que existen pero dependen de un log que nadie está recolectando.
• Reglas huérfanas: detecciones que alguien creó hace años, que nadie entiende y que nadie se atreve a borrar.

El ingeniero de detecciones ataca las tres: ajusta la lógica, cierra huecos con reglas nuevas y mantiene un inventario vivo.

Dónde encaja en el equipo

En un SOC pequeño, quien atiende alertas también escribe reglas. En equipos grandes hay un rol dedicado que se relaciona con todos:

• Analistas L1 y L2: son sus clientes; le cuentan qué reglas hacen ruido y qué falta en la alerta.
• Threat hunting: le entrega hallazgos que merecen ser detecciones permanentes.
• Threat intelligence: le dice qué técnicas usan los grupos que atacan al sector financiero.
• Respuesta a incidentes: tras cada incidente le pregunta por qué no se detectó antes.
• Infraestructura y arquitectos de SIEM: habilitan y normalizan los logs que hacen falta.

Breve historia: de las firmas a las detecciones como producto

La idea de detectar ataques con reglas no es nueva; lo nuevo es tratarlas con disciplina de ingeniería.

Con esas piezas, hacia finales de la década de 2010 se empezó a hablar de detection as code y de detection engineering como rol propio, hoy habitual en SOC maduros y fabricantes de EDR.

Detecciones atómicas y de comportamiento

Conviene distinguir dos estilos, que la Pirámide del Dolor ordena según cuánto le cuesta al atacante esquivarlos. Una detección atómica busca un indicador concreto: una IP, un hash, un dominio. Es fácil de escribir, pero el atacante la evade cambiando ese valor. Una detección de comportamiento busca lo que el atacante necesita hacer: por ejemplo, que Excel lance un intérprete de scripts o que alguien borre las copias de sombra de Windows.

Atómica:       destino = 198.51.100.200
Comportamiento: proceso padre = excel.exe  Y  proceso hijo = powershell.exe

Las de comportamiento duran más, pero hacen más ruido, porque algunos administradores hacen cosas parecidas. Equilibrar eso es el corazón del oficio.

Por qué importa en el trabajo del defensor

Cada regla mala cuesta tiempo humano: si una alerta toma 8 minutos de triaje y una regla dispara 600 veces al mes, consume 80 horas de analista. Cada regla que falta es un ataque que nadie ve. Sin esta disciplina, el SOC termina con miles de reglas copiadas, alertas que nadie lee y una falsa sensación de cobertura.

Dónde se usa

Conceptos clave

Además de SIEM, log y analista L1, que ya conoce, el curso usará estos términos: