Un análisis de más de 14.000 reglas en producción revela que el 47% requiere corrección — el problema no es la falta de cobertura en papel, sino fallas lógicas que las vuelven inoperantes.
Una regla de detección puede aparecer como activa en el dashboard de cobertura de una organización y, aun así, nunca dispararse cuando un atacante usa exactamente la técnica que esa regla fue diseñada para identificar. Esa es la conclusión central de un análisis conducido por Conifers sobre 14.652 detecciones desplegadas en su base de clientes, que abarca reglas escritas internamente por equipos de seguridad y detecciones gestionadas por proveedores en herramientas SIEM, endpoint, cloud, identity, email y network. El hallazgo: en una organización promedio, el 47% de las detecciones en producción requiere atención porque no está funcionando como se esperaba.
El problema no es la ausencia de reglas, sino su funcionamiento silencioso
La investigación de Conifers no se enfocó en organizaciones sin capacidad de detección — al contrario, evaluó entornos donde las reglas ya están desplegadas y reportadas como operativas. El punto crítico es que esas reglas no están cumpliendo su función cuando se las necesita. Los fallos identificados se agrupan en cinco categorías, una de las cuales es logic bugs: errores en la lógica interna de la regla que hacen que nunca se active bajo las condiciones reales de un ataque, aunque técnicamente esté habilitada en el sistema.
Este tipo de fallo es particularmente insidioso porque no genera alertas de error ni aparece en reportes de salud del sistema. La regla existe, consume recursos de procesamiento, figura en la matriz de cobertura de MITRE ATT&CK que el equipo presenta a la dirección — pero en la práctica es inerte. El atacante ejecuta la técnica, la telemetría llega al SIEM o al EDR, la regla evalúa el evento y decide que no hay coincidencia porque la condición lógica está mal construida. No hay alerta, no hay investigación, no hay respuesta.
Por qué las reglas fallan sin que nadie lo note hasta que es tarde
Las detecciones gestionadas por proveedores no están exentas del problema. El análisis de Conifers incluyó tanto reglas escritas internamente por los clientes como detecciones que vienen preconfiguradas o actualizadas por los vendors de las plataformas de seguridad. Esto significa que una organización puede estar pagando por un servicio de detección gestionada, confiando en que el proveedor mantiene las reglas actualizadas y funcionales, y aun así tener un porcentaje significativo de esas reglas inoperantes por errores de lógica o configuración que el vendor no detectó en sus propios controles de calidad.
El problema se amplifica cuando las organizaciones dependen de dashboards de cobertura para validar su postura de seguridad. Estos dashboards suelen mostrar qué técnicas de ATT&CK están cubiertas por al menos una regla activa, pero no validan si esa regla realmente funciona en el entorno específico del cliente. Una regla puede estar mapeada a la técnica T1059.001 (PowerShell) en el dashboard, pero si tiene un logic bug que hace que solo se dispare cuando el comando tiene más de 500 caracteres y el atacante usa comandos de 300, la cobertura es ilusoria.
El impacto en América Latina: dependencia de detecciones gestionadas sin validación local
En organizaciones de América Latina, donde es común la adopción de plataformas de seguridad con detecciones gestionadas por el proveedor — especialmente en sectores financiero, retail y gobierno que operan con equipos de seguridad reducidos — este hallazgo tiene implicancias directas. La confianza en que las reglas del vendor están funcionando sin un proceso de validación interno deja a estas organizaciones expuestas a brechas de cobertura que no aparecen en ningún reporte de cumplimiento ni en las revisiones trimestrales con el proveedor.
El problema no es exclusivo de un país o sector, pero se agrava en contextos donde la capacidad de escribir y mantener reglas propias es limitada y la dependencia de contenido preempaquetado es mayor. Si el 47% de las detecciones en una organización promedio necesita corrección, y esa organización no tiene un proceso para identificar cuáles son esas detecciones antes de que ocurra un incidente, la brecha entre cobertura reportada y cobertura real puede ser determinante en la diferencia entre detectar un ransomware en la fase de reconocimiento o descubrirlo cuando ya cifró los servidores de producción.
Nuestro análisis
El hallazgo de Conifers no es una anomalía técnica — es un síntoma de cómo la industria de la seguridad ha priorizado la cantidad de cobertura sobre la calidad de funcionamiento. Las organizaciones acumulan reglas porque cada auditoría, cada marco de cumplimiento, cada evaluación de madurez pregunta cuántas técnicas de ATT&CK están cubiertas, no cuántas de esas coberturas fueron validadas en los últimos seis meses con datos reales o simulaciones controladas. El resultado es un inventario de detecciones que crece sin un proceso equivalente de mantenimiento y prueba continua.
Lo que falta no es tecnología — las herramientas para validar reglas existen, desde plataformas de purple teaming hasta frameworks de testing automatizado de detecciones. Lo que falta es el reconocimiento de que una regla de detección es código en producción y, como tal, requiere el mismo ciclo de vida que cualquier otro componente crítico: desarrollo, testing, despliegue, monitoreo de efectividad, y depreciación cuando deja de ser relevante. Mientras las organizaciones sigan tratando las reglas de detección como configuración estática en lugar de lógica operativa que necesita validación continua, el 47% de detecciones inoperantes va a seguir siendo la norma, no la excepción. ¿Cuántos incidentes más van a pasar desapercibidos antes de que validar las detecciones sea tan rutinario como parchear vulnerabilidades?