Detections de Elastic SIEM
Con el lanzamiento de Elastic Security 7.6, anunciamos nuestra creación de un motor de detección moderno que proporciona a los equipos de SOC una experiencia de reglas de SIEM unificada a través de detections de Elastic SIEM. El motor de detección se basa en un conjunto especialmente diseñado de motores de analítica de Elasticsearch y se ejecuta en una plataforma de ejecución distribuida nueva en Kibana. En este blog, proporcionamos una breve visión general del flujo de detections en Elastic SIEM y hablamos sobre la UI y características de backend nuevas que ayudan a que estas detections funcionen sin problemas para nuestros usuarios.
Antes de pasar a las detections, una breve aclaración: si estás listo para probar la app SIEM, echa un vistazo a la serie del blog sobre SIEM para empresas pequeñas y en el hogar. La serie abarca la configuración en el cloud con nuestra prueba de Elasticsearch Service gratuita, el uso de Beats para recopilar y transmitir datos de forma segura desde tus sistemas hacia SIEM y más. (Es mucho más fácil de lo que imaginarías). También ofrecemos una guía de primeros pasos para despliegues híbridos.
Flujo de trabajo de UI para gestión de señales
Lo esencial de las detections de Elastic SIEM son las señales, que son documentos de Elasticsearch que se crean cuando se cumplen las condiciones de una regla de detección de señal. En el caso más simple, se crea un documento de señales para cada evento que coincida con la búsqueda definida en la regla. El documento de señales contiene una copia de los campos del documento que coincide y se mantiene en un índice de señales diferente. Los eventos originales no se modifican cuando se crea una señal.
Las señales se revelan en la app SIEM. Cuando un especialista ve por primera vez una señal nueva, está en estado abierto. Después de analizar y determinar los pasos siguientes, el especialista cambia el estado a cerrado. Todos estos cambios se pueden gestionar en la vista Detections (Detecciones) en la app SIEM.
El histograma de recuento de señales muestra las señales abiertas y permite comparaciones rápidas entre atributos clave:
- Puntuación, gravedad, tipo, nombre o nombre táctico de MITRE ATT&CK™
- Dirección IP de origen o destino
- Categoría o acción de evento
- Nombre de usuario o host
El paso siguiente es la investigación de señales en Timeline (Línea de tiempo):
Si no especificaste una plantilla de línea de tiempo cuando creaste una regla, Timeline (Línea de tiempo) se completa con un documento de señales. Si especificaste una plantilla de línea de tiempo, se completará con lo que guardó el usuario, lo cual acelera las investigaciones para ciertos tipos de reglas.
Los especialistas pueden ver alertas de sistemas de alertas externos, como Elastic Endpoint Security, Suricata o Zeek, en la pestaña específica External alerts (Alertas externas). Muchas organizaciones también implementan reglas que generan señales para alertas externas de alto valor con el objetivo de poder beneficiarse del flujo de trabajo de investigación mejorado para señales.
Una vez que se haya investigado una señal o un conjunto de señales a satisfacción del analista, pueden cerrar las señales de forma individual o masiva. También se pueden reabrir las señales, de ser necesario. Estamos buscando formas de automatizar el cierre de señales en lanzamientos futuros.
Flujo de trabajo de UI para la creación de reglas
Para que comiencen a mostrarse las señales, las detections necesitan que se ejecuten reglas. Crear una regla para detections de SIEM es simple y sencillo. Se reduce a tres pasos básicos:
1) Genera la búsqueda que se usará cada vez que se ejecute la regla. Esta búsqueda puede tener sintaxis de Lucene o KQL, ser una búsqueda guardada o importarse desde una línea de tiempo guardada (con muchas más opciones para búsquedas de reglas actualmente en desarrollo para un lanzamiento futuro):
2) Agrega algo de información que describa la regla (título, descripción, etc.):
3) Programa el intervalo cada el cual se debería ejecutar la regla y cualquier tiempo de retrospección adicional para comprobaciones de estado. Generalmente recomendamos cierto tiempo de retrospección para dar lugar a demoras que pueden ocurrir en el pipeline de ingesta de un usuario dado. También recomendamos cierto tiempo de retrospección porque no se garantiza que las reglas se ejecuten exactamente en el intervalo programado y, por lo tanto, puede haber demoras entre ejecuciones. Una cola sobrecargada del operario del administrador de tareas o recursos informáticos insuficientes pueden causar estas demoras.
Estos tres son los componentes básicos que conforman una regla de detections. También proporcionamos configuraciones para clasificar esta regla conforme a las tácticas y técnicas de MITRE ATT&CK, además de enlaces a referencias adicionales.
Los usuarios también pueden realizar acciones en reglas existentes de forma individual o masiva, como duplicar (para personalizaciones), desactivar, exportar y eliminar reglas. También tenemos una guía para más información sobre la gestión general de reglas.
Reglas prediseñadas
Puede ser difícil desarrollar las reglas y se requiere mucho tiempo para probarlas. Es por esto que las detections comenzaron con 92 reglas prediseñadas desarrolladas por el equipo de Inteligencia y Analíticas en Elastic Security y se usaron ampliamente en Elastic en un entorno de producción. Se están desarrollando continuamente reglas nuevas que responden a las amenazas críticas más recientes. Cargarlas y prepararlas para la ejecución es tan fácil como hacer clic en un botón. Puedes leer más sobre cómo usar y ajustar las reglas prediseñadas aquí.
Detalles de implementación de detections
Poco después de que las Alertas en el Elastic Stack se abrieran paso en Kibana para proporcionar soporte para alertas como entidades de primera clase, Elastic SIEM usó las alertas como base de las detections. Detrás de la UI, las detections usan una API sobre la API de alertas. La API de detections de SIEM aporta conveniencia, flujos de trabajo (como señales de apertura y cierre), los detalles del dominio de seguridad (como identificación de MITRE ATT&CK) y soporte para KQL.
Las reglas se ejecutan detrás de escena con la creación de una clave de API y el uso de dicha clave de API para realizar solicitudes en nombre del usuario. Estas reglas usan search after para encontrar eventos que coincidan y bulk create para copiar la información del evento a un documento de señales en el índice de señales. Una señal está compuesta por los detalles de la regla y los detalles del documento de evento original con el que coincide la regla.
Si se encuentran más de 100 documentos que coinciden en una ejecución de una sola regla, solo las últimas 100 coincidencias (por orden descendente de @timestamp [@marca de tiempo]) se copian en el índice de señales. El índice de señales se crea automáticamente por espacio de Kibana la primera vez que visitas la página de reglas de detección de señal. El formato del nombre del índice es `.siem-signals-
El mapeo del índice de señales de SIEM es una combinación de Elastic Common Schema (ECS) y un mapeo personalizado de nuestra definición de qué es una señal. Cuando se detecta un documento que coincide a partir de la búsqueda de la regla, se copiarán los campos de los índices de origen y se podrán hacer búsquedas en los campos de señal resultantes si los campos en el documento de origen cumplen con ECS. Si los campos de los índices de origen no son parte de ECS, aún se almacenarán en `_source` (_origen) de la señal y se podrán ver en Timeline (Línea de tiempo) y otras partes de la aplicación. Sin embargo, no se podrá buscar en ellos.
Escalabilidad
La UI de detections está creada sobre el marco de trabajo de Alertas de Kibana desarrollado recientemente y el administrador de tareas de Kibana. Ambos proporcionan capacidades de escalado horizontal y vertical, lo que permite una flexibilidad que se adapta mejor a cualquier hardware disponible en el momento. Puede aumentarse la cantidad de operarios del administrador de tareas de Kibana para aprovechar el escalado vertical o se pueden replicar en instancias de Kibana diferentes y escalar de forma horizontal.
Cuando se ejecutan varias instancias de Kibana, los administradores de tareas se coordinarán en la red para equilibrar las tareas de todas las instancias. Al actualizar el valor predeterminado 10 de la cantidad de max_workers (máx._operarios) en el archivo kibana.yml, puedes ampliar o reducir la escala de forma vertical para asignar recursos adecuadamente con más eficiencia por nodo de Kibana.
Deduplicación de señal
Cuando se está ejecutando una regla, genera señales basadas en los eventos que encuentra que coinciden con la búsqueda de la regla. En ocasiones pueden crearse señales duplicadas debido a búsquedas que se superponen en reglas diferentes o por la ejecución de una regla dos veces seguidas que capta la misma señal a causa de un tiempo de retrospección adicional prolongado. Para evitar que aparezca una señal duplicada en la tabla de señales, identificamos señales según el índice al que pertenece el evento de origen, el ID de documento del evento, el número de versión del evento de origen y el ID de la regla en ejecución. Mediante el uso de hash en estas propiedades, nos aseguramos de que solo se agreguen señales únicas al índice de señales.
Errores
En ocasiones aparecerán errores debido a un error de sintaxis en una búsqueda de regla u otro problema durante el período de ejecución de una regla. Los destacamos en la pestaña Failure History (Historial de fallas) de la página de detalles de la regla. Planificamos ampliar la visibilidad de la información de ejecución de la regla y el monitoreo general de reglas en el futuro.
Aquí podemos ver el historial de fallas, que muestra los últimos cinco errores que ocurrieron durante la ejecución de la regla:
Detections de SIEM del mañana
Lo más emocionante de trabajar en esta versión beta de detections de Elastic SIEM y de lanzarla son los comentarios tempranos y continuos de la comunidad en el foro de debate de Elastic SIEM y nuestra lista de rastreo de características abierta.
Tenemos grandes planes para hacer que detections sea incluso más poderoso. Ampliar las búsquedas de reglas para incluir agregaciones, tareas de Machine Learning y EQL son solo algunos. Si se te ocurre algo que sea un buen caso de uso de seguridad o deseas hacer algunas preguntas sobre lo que está sucediendo, únete a nosotros.