El SOC de un proveedor fintech operaba tres plataformas SIEM en su entorno de nube híbrida: Microsoft Sentinel para las cargas de trabajo de Azure, Splunk para la infraestructura local y una agregación de AWS Security Hub para sus cargas de trabajo nativas de la nube. El número total de reglas en las tres plataformas superaba las cuatrocientas reglas de correlación y políticas de detección. El equipo de ingeniería de detección lo formaban dos analistas sénior que mantenían las cuatro plataformas además de sus funciones habituales de SOC. Las cuatrocientas reglas se habían acumulado durante seis años: algunas las había escrito el equipo original de SOC a partir de hallazgos de incidentes concretos y la mayoría se había heredado de plantillas de los proveedores de las plataformas y de integraciones de fuentes de inteligencia de amenazas. Las reglas personalizadas propias del panorama de amenazas del sector fintech (manipulación de transacciones, abuso de API para fraude financiero, relleno de credenciales contra endpoints de procesamiento de pagos) eran menos de veinte. Las trescientas ochenta restantes eran reglas genéricas aplicables a cualquier organización. Cuando un sofisticado grupo de amenazas con motivación financiera, dedicado específicamente a la infraestructura fintech, empezó a sondear el entorno del proveedor, utilizó técnicas diseñadas para confundirse con las operaciones fintech normales: patrones de llamadas de API coherentes con un procesamiento legítimo de pagos de alto volumen, secuencias de autenticación que imitaban flujos de conciliación automatizados y patrones de acceso a datos indistinguibles del procesamiento por lotes habitual de fin de día. Las reglas de detección genéricas no generaron ninguna alerta. Las veinte reglas específicas del sector fintech estaban ajustadas para patrones de ataque más antiguos que el equipo había observado antes. Las técnicas del actor de amenazas eran nuevas.
¿Qué son realmente las brechas de ingeniería de detección?
La ingeniería de detección es la disciplina de diseñar, desarrollar, probar y mantener la lógica de detección (reglas de correlación, analítica de comportamiento y políticas de detección de anomalías) que permite a un SIEM y a un SOC identificar actividad maliciosa en un entorno concreto. Las brechas de ingeniería de detección son las carencias en la cobertura de la lógica de detección: reglas que no se han escrito para técnicas de ataque concretas, reglas heredadas de plantillas genéricas sin personalizar, reglas que han perdido relevancia a medida que han evolucionado el entorno y el panorama de amenazas, y reglas que nunca se prueban para confirmar que siguen activándose según lo previsto.
El problema de heredar los valores predeterminados de la plataforma es la brecha de ingeniería de detección más extendida. Las plataformas SIEM incluyen conjuntos de reglas predeterminados: cientos de reglas de correlación y políticas de detección derivadas de inteligencia de amenazas general y de patrones de ataque comunes. Estos valores predeterminados proporcionan cobertura de detección inmediata desde el primer momento y son valiosos para detectar amenazas genéricas. No están diseñados para los patrones de ataque concretos de un sector, una pila tecnológica o un perfil de actor de amenazas en particular. Las organizaciones que dependen principalmente de los valores predeterminados heredados sin desarrollar lógica de detección específica de su sector y de su entorno tienen una cobertura de detección calibrada para el panorama de amenazas promedio y no para su panorama de amenazas real.
El problema del deterioro de las reglas agrava la brecha de los valores predeterminados heredados. Las reglas de detección pierden relevancia con el tiempo a medida que cambia el entorno, evolucionan las técnicas de ataque y los ajustes realizados para reducir falsos positivos estrechan de forma involuntaria el alcance de detección de la regla. Una regla escrita hace cinco años para detectar un patrón de ataque concreto puede haberse estrechado progresivamente mediante ajustes hasta activarse solo en circunstancias que coinciden exactamente con el incidente original que la motivó, y pasar por alto el patrón más amplio que debía detectar. Los programas de ingeniería de detección que revisan y actualizan las reglas con regularidad mantienen la relevancia de la detección. Los programas que se limitan sobre todo a añadir reglas nuevas sin retirar ni renovar las antiguas acumulan deuda de detección.
- Reglas predeterminadas de la plataforma sin personalización sectorial: cobertura genérica para el panorama de amenazas promedio
- Equipo de ingeniería de detección de dos personas que mantiene cuatrocientas reglas en varias plataformas
- Deterioro de reglas: los ajustes reducen el alcance de detección con el tiempo
- Técnicas específicas del sector sin cubrir: el actor de amenazas utiliza métodos propios del sector
- Sin frecuencia de pruebas de reglas: no se verifica que las reglas sigan activándose según lo previsto
Por qué es importante
Las brechas de ingeniería de detección son importantes para TPRM porque la capacidad de detección del SOC solo es tan buena como las reglas que se han desarrollado y mantenido. Un proveedor con una plataforma SIEM madura y un despliegue completo de reglas predeterminadas tiene la infraestructura necesaria para una detección eficaz. Que esa infraestructura sea realmente eficaz frente a las amenazas concretas relevantes para los datos del cliente depende de si el programa de ingeniería de detección ha desarrollado y mantenido reglas para esas amenazas concretas. La madurez de la plataforma y la madurez de la ingeniería de detección son dimensiones distintas de la misma capacidad de SOC.
La dimensión de la cadena de suministro es especialmente relevante para las amenazas propias de cada sector. Los clientes fintech que comparten datos con proveedores fintech se enfrentan al mismo panorama de amenazas del sector. Los clientes del sector salud que dependen de proveedores de tecnología sanitaria están expuestos a los mismos actores de amenazas que atacan los datos de salud. Un proveedor cuyo programa de ingeniería de detección cubre patrones de ataque genéricos pero carece de lógica de detección específica del sector es un proveedor cuyo SOC pasará por alto las técnicas concretas que usan los actores de amenazas con más probabilidad de atacar los datos del cliente a través de la relación con el proveedor.
Dónde se equivocan la mayoría de los equipos
El error más habitual es aceptar el número de reglas como indicador de la calidad de la ingeniería de detección. El número de reglas mide el volumen. La calidad de la ingeniería de detección mide la relevancia, el mantenimiento y la frecuencia de las pruebas.
- Se acepta el número de reglas como indicador de cobertura
- Dependencia de los valores predeterminados de la plataforma sin evaluar: no se solicita la proporción de reglas personalizadas frente a heredadas
- Capacidad del equipo de ingeniería de detección sin evaluar en relación con la carga de mantenimiento de reglas
- Cobertura de reglas específicas del sector sin verificar
- No se pregunta por la frecuencia de pruebas de reglas: cuándo se validaron las reglas por última vez
Cómo se ve una buena práctica
Los programas maduros de ingeniería de detección mantienen un inventario de reglas que distingue los valores predeterminados de la plataforma de las reglas personalizadas, prueban las reglas con regularidad para confirmar que se activan según lo previsto y priorizan el desarrollo y mantenimiento de reglas para los actores de amenazas y las técnicas más relevantes para el sector y el perfil de amenazas de la organización.
- Proporción de reglas personalizadas: qué parte de las reglas es específica del entorno frente a los valores predeterminados heredados
- Detección específica del sector: reglas escritas para técnicas de ataque propias del sector
- Pruebas periódicas de reglas: reglas validadas para que se activen ante los patrones de ataque relevantes
- Gestión de la deuda de detección: reglas obsoletas retiradas, reglas deterioradas renovadas
- Hoja de ruta de ingeniería de detección: brechas conocidas y plazo para mejorar la cobertura
Herramientas
Plataformas SIEM: Microsoft Sentinel, Splunk, Elastic SIEM con desarrollo de reglas personalizadas
Las plataformas SIEM proporcionan la infraestructura para desarrollar reglas de detección personalizadas. Para los profesionales de TPRM, preguntar qué proporción de las reglas del proveedor está escrita a medida frente a los valores predeterminados de la plataforma ofrece el indicador de dedicación a la ingeniería de detección que el número total de reglas no ofrece.
Inteligencia de amenazas: MITRE ATT&CK, ISAC del sector
La inteligencia de amenazas sectorial de los ISAC y las correspondencias de técnicas de ATT&CK para grupos de amenazas conocidos proporcionan el material de partida para reglas de ingeniería de detección calibradas al panorama de amenazas concreto. Para los profesionales de TPRM, preguntar si las reglas de detección del proveedor están asociadas a las técnicas de ATT&CK más vinculadas a los actores de amenazas de su sector ofrece una pregunta concreta sobre su relevancia.
Desafíos de gobernanza
El desafío de gobernanza de la ingeniería de detección es la capacidad. Desarrollar y mantener reglas de detección de alta calidad, probadas y específicas del sector requiere mucho tiempo de los analistas, que compite con las operaciones diarias del SOC. La solución de gobernanza consiste en dedicar una capacidad específica a la ingeniería de detección, separando el trabajo de desarrollo de detecciones del trabajo de clasificación de alertas, y en utilizar SOAR y pruebas automatizadas para reducir la carga de mantenimiento continuo.
- Solicitar la proporción de reglas personalizadas frente a predeterminadas: qué parte es específica del entorno
- Solicitar el número de reglas específicas del sector: cuántas reglas abordan técnicas propias del sector
- Solicitar la frecuencia de pruebas de reglas: con qué frecuencia se validan las reglas
- Solicitar la última revisión de cobertura de ATT&CK para los actores de amenazas relevantes del sector
- Solicitar la capacidad dedicada del equipo de ingeniería de detección
Si usted forma parte de un equipo pequeño
Haga a su proveedor de mayor riesgo tres preguntas sobre ingeniería de detección. Primera: ¿qué porcentaje de sus reglas de detección está escrito a medida para su entorno concreto y cuántas se heredan de los valores predeterminados de la plataforma? Segunda: ¿tienen reglas de detección escritas específicamente para las técnicas de ataque que usan los actores de amenazas conocidos por atacar su sector? Tercera: ¿cuándo se probaron por última vez sus reglas de detección para confirmar que se activan ante los patrones para los que fueron diseñadas? Esas tres preguntas revelan si las cuatrocientas reglas son personalizadas y probadas, o heredadas y sin verificar.
- Preguntar por la proporción de reglas personalizadas frente a predeterminadas
- Solicitar la cobertura de técnicas de ataque específicas del sector
- Preguntar cuándo se probaron por última vez las reglas para confirmar que se activan
- Solicitar la cobertura de ATT&CK para los grupos de amenazas relevantes del sector
Qué exigir
Pregunte directamente:
“¿Qué porcentaje de sus reglas de detección de SIEM están escritas a medida para su entorno y cuántas se heredan de los valores predeterminados de la plataforma? ¿Tienen reglas específicas para las técnicas de ataque que usan los grupos de amenazas conocidos por atacar su sector?”
Evidencia que debe esperar
- Proporción de reglas personalizadas frente a predeterminadas
- Número de reglas específicas del sector y cobertura de técnicas
- Frecuencia de pruebas de reglas y fecha de la última prueba
- Mapa de cobertura de ATT&CK para los actores de amenazas del sector
A un proveedor con cuatrocientas reglas de detección se le debe preguntar cuántas de ellas se han creado a medida para su panorama de amenazas concreto. Cuatrocientas reglas predeterminadas y cuatrocientas reglas personalizadas representan inversiones muy distintas en ingeniería de detección.
Cómo demostrarlo
- Documentación de la proporción de reglas personalizadas
- Registros de cobertura de detección específica del sector
- Registros de la frecuencia de pruebas de reglas
- Evaluación de la cobertura de ATT&CK
Conclusión clave
Cuatrocientas reglas. Trescientas ochenta predeterminadas de la plataforma. Veinte reglas personalizadas para patrones antiguos del sector. El actor de amenazas fintech utilizó técnicas actuales propias del sector fintech. Cero alertas. La infraestructura de SIEM era madura. El programa de ingeniería de detección no había desarrollado las reglas para usarla contra esa amenaza concreta. El número de reglas describe la inversión en infraestructura de detección. La proporción de reglas personalizadas y la cobertura de técnicas específicas del sector describen si esa infraestructura se ha diseñado para detectar las amenazas reales. Los valores predeterminados cubren el promedio. Las reglas personalizadas cubren lo específico. Lo específico es lo que importa.