Impacto, Dolor, Accionabilidad y Severidad del SIEM
Tabla de contenidos:
Propósito
El propósito de esta publicación del blog es presentar las métricas (Dolor, Viabilidad, Impacto en SIEM y Severidad) que han sido introducidas en el Marketplace de Detección de Amenazas de SOC Prime.
Introducción
SOC Prime’s Marketplace de Detección de Amenazas mejora sus operaciones de seguridad con contenido de detección de calidad.Como con toda tecnología defensiva, desplegar todo el contenido posible “de inmediato” no es recomendable, y elegir qué contenido proporciona más valor puede ser a veces difícil. Con las nuevas métricas Impacto en SIEM, Dolor, Viabilidad y Severidad, SOC Prime espera que decidir qué reglas son adecuadas para usted sea más sencillo.
Sin embargo, estas métricas no reflejan directamente la calidad de un elemento de contenido. Una regla puede tener potencialmente una baja puntuación en la mayoría de las métricas pero seguir siendo una detección de calidad.
- Impacto en SIEM: Es el impacto anticipado en el rendimiento en un SIEM
- Dolor: La puntuación refleja dónde cae la regla en la pirámide del dolor. Las reglas de mayor dolor son ideales para los cazadores de amenazas y los operadores de nivel 3.
- Viabilidad: Qué tan obvio es el triaje. Una alta puntuación de viabilidad refleja que un analista de nivel 1 podrá entender rápidamente los próximos pasos. Una regla de baja viabilidad puede requerir pasos avanzados como forense de memoria, contactar al propietario de la cuenta, o realizar múltiples búsquedas adicionales.
- Severidad: Qué tan crítico es revisar cualquier alerta causada por esta lógica. Esto se deriva del campo de nivel SIGMA.
Dolor, Viabilidad y Severidad son proporcionados por el analista que creó la regla en un esfuerzo de buena fe para reflexionar sobre las cualidades de la regla. SOC Prime revisa todo el contenido y puede ajustar valores basados en nuestro conocimiento experto y retroalimentación de clientes. El impacto en SIEM actualmente se asigna mediante medios semi-automatizados, y esto se implementará completamente en el futuro.
En las siguientes secciones describiré cómo se puntúan y tratan estos elementos dentro del Marketplace de Detección de Amenazas.
Obteniendo las Métricas
Cuando selecciona una regla en el panel de búsqueda, las métricas sobre la regla se llenarán en el lado derecho de la pantalla. Estas métricas estarán disponibles para contenido comunitario y exclusivo.
Impacto en SIEM (1 – 3, más alto es menos impacto)
El impacto en SIEM es el impacto anticipado en el sistema contra el que ejecutará la regla.
Los SIEMs son sistemas analíticos que requieren enormes cantidades de poder computacional para lograr un resultado positivo. Esto hace que la tarea de ajustar cada bit y byte de la configuración del SIEM sea una rutina diaria. Las personas que han pasado años en ingeniería de detección y SIEM o están familiarizadas con las mejores prácticas de regex saben que una regla con una declaración event=/.*amenaza.*/ es una regla ‘hambrienta’. Añada una de ellas en una gran instalación de producción y puede experimentar búsquedas más lentas. Añada cien, y hasta un sistema distribuido comenzará a perder rendimiento. Hemos observado a varios proveedores de SIEM proporcionando declaraciones hambrientas en entrenamiento como una mejor práctica, para enfatizar lo fácil que es encontrar amenazas. Sin embargo, en producción es importante hacer reglas rentables y es exactamente por eso que hemos introducido esta métrica.
A medida que la complejidad de la regla y la cantidad de ruido en la(s) fuente(s) de datos aumenta, la puntuación de impacto en SIEM será menor.
| Puntuación | Lógica | Razonamiento |
| – | el mensaje contiene «a» OR «b» OR «c» OR «d» OR «e» OR «f» OR «g» OR «h» OR «i» OR «j» OR «k» OR «l» OR «m» OR «n» OR OR «o» OR «p» OR «q» OR «r» OR «s» OR «t» OR «u» OR «v» OR «w» OR «x» OR «y» OR «z» OR «1» OR «2» OR «3» | Esta regla no sería aceptada ya que es demasiado impactante. |
| 1 | usuario = «*$» AND (commandline contiene «TVqAA») (commandline contiene «http://» OR commandline contiene «https://» OR commandline contiene «ftp» OR commandline contiene «file:\\») | Mucho uso de comodines/contiene |
| 2 | eventid=4688 Y commandline contiene «scrobj.dl» | El uso de contains aumenta la carga en SIEM. |
| 3 | eventid:5140 Y sharename:Admin$ | La coincidencia exacta en campos es óptima desde una perspectiva de rendimiento |
_
Dolor (1 – 3, más alto es más conductual/menos fácil de eludir)
La puntuación de Dolor es una abstracción de dónde encaja la regla en la Pirámide del Dolor de David Bianco y qué tan fácilmente se puede eludir la lógica. Cuanto más conductual y menos probable sea que se eluda la regla, mayor será la puntuación de dolor. Las reglas conductuales son generalmente mejores para la búsqueda de amenazas y a menudo pueden ser más ruidosas o requerir cosas como el conteo de pilas para ser efectivas. Las reglas basadas en IOC deberían causar menos ruido, pero pueden ser muy raras de activar o solo útiles para análisis históricos. El mecanismo de registro que se deshabilite o subvierta completamente no se tiene en cuenta con este puntaje (es decir, herramientas como fantasma en los registros)
| Puntuación | Lógica | Razonamiento |
| 1 | destination.ip=»1.1.1.1″ Y destination.port=53 | Esta es una detección basada en IP, las IP son fácilmente cambiables. |
| 2 | eventid=4688 Y commandline contiene «scrobj.dl» | Esta es una detección de comportamiento pero scrobj.dll puede ser renombrado para evitar esta detección. |
| 3 | eventid:5140 Y sharename:Admin$ | Si alguien se conecta a un recurso compartido de administrador en Microsoft, este registro no es fácilmente eludible |
_
Viabilidad (1 – 3, más alto es más obvio)
La puntuación de Viabilidad reflejará qué tan «digerible» es la regla. A menudo, esto es un reflejo directo de la fuente del registro en sí. Cuanto más contexto esté disponible en la fuente de registro original, mayor será la puntuación de viabilidad. Nuevamente, esto se basa en los datos de la alerta en sí. La viabilidad de todas las reglas en su entorno puede aumentar considerablemente mediante la automatización y la orquestación. Esto no se tiene en cuenta.
| Puntuación | Lógica | Razonamiento |
| 1 | destination.ip=»1.1.1.1″ Y destination.port=53 | Dependiendo de la fuente de datos, esta alerta podría ser muy difícil de clasificar. A menudo, reglas como esta se activan en hosts que no están gestionados (red de invitados, etc.). Además, DHCP puede introducir complejidades en la identificación del host infractor. |
| 2 | eventid:5140 Y sharename:Admin$ | El ID de evento 5140 de Windows proporcionará el nombre de usuario y el nombre del host/IP que accedió a un recurso compartido. Sin embargo, probablemente se requieran búsquedas adicionales para identificar si esto es el resultado de un compromiso. |
| 3 | eventid=4688 Y commandline contiene «scrobj.dl» | El ID de evento 4688 de Windows proporciona mucho contexto inmediatamente útil para un analista. Es probable que identificar un compromiso probable sea posible solo con ver esta alerta. |
Severidad (1 – 3, más alto es una alerta más crítica)
La severidad es una abstracción de los niveles SIGMA (bajo, medio, alto y crítico).
| Puntuación | Nivel SIGMA | Razonamiento |
| 1 | Low | Por favor ver: https://github.com/Neo23x0/sigma/wiki/Rule-Creation-Guide |
| 2 | Medio | |
| 3 | Alto & Crítico |
Conclusión
Encontrar un contenido adecuado a sus necesidades debería ser lo más simple posible. Al introducir las métricas Impacto en SIEM, Dolor, Viabilidad y Severidad, SOC Prime espera ayudar a coincidir el contenido de los desarrolladores de nuestro Programa de Recompensas de Amenazas con los requisitos de su operación defensiva.
Si tiene un equipo interno de ingeniería de detección, recomendamos que implementen estos conceptos y los capturen como una métrica durante la creación de contenido defensivo.
Meta
Publicado – Abril 2020
Última actualización – 15 de abril de 2020
Autores – Adam Swan (@acalarch) | Andrii Bezverkhyi (@andriinb)
