En este artículo introduciremos Elastic Security, la solución de seguridad de Elastic basada en el Elastic Stack. El objetivo es mostrar la solución SIEM del fabricante, la cual abordaremos desde un pequeño ejemplo práctico que nos dará una primera visión de qué nos puede llegar a ofrecer el producto.
Elastic es una compañía de búsqueda, así Elastic Security se basa en Elasticsearch para proporcionarnos lo que mejor sabe hacer: buscar en tiempo real sobre un gran volumen de información, en este caso sobre nuestros eventos de seguridad.
Tras la adquisición el año pasado de Endgame, una solución de endpoint de reconocido prestigio, Elastic ha consolidado su solución de seguridad ofreciendo prevención, detección y respuesta a amenazas. En la actualizad, Elastic Security nos ofrece de forma gratuita SIEM, Endpoint Security, búsqueda de amenazas, etc.
Podría extenderme con toda la funcionalidad que nos proporciona Elastic Security en la actualidad, pero no es el objetivo de este post, el cual centraremos en la solución SIEM. Si se quiere conocer al detalle la funcionalidad que nos ofrece el producto, la documentación oficial del fabricante es muy completa.
Elastic Common Schema (ECS)
Cuando un analista ha de gestionar eventos de seguridad, que por su naturaleza provienen de diversas fuentes de información, es de vital importancia tener definida una especificación sobre los campos que permita examinar los datos de manera uniforme. De otra manera, sería costoso y complicado poder relacionar datos de distintas fuentes. Por ejemplo, si pensamos en una ip de origen, se dará el caso que varias fuentes de información puedan hacer referencia a ella con múltiples nomenclaturas (ip, ip_origen, mi_ip, ip.origen, source_ip, etc), al igual que podrían tener distinta tipología (texto, ip, etc).
Para abordar esta necesidad, Elastic ha creado el Elastic Common Schema (ECS). ECS es una especificación open source proporcionada por Elastic para utilizar a la hora de almacenar datos en Elasticsearch. Es un modelo de datos/información, en el cual se definen un conjunto común de campos y sus nomenclaturas.
ECS está optimizado para el uso en Elasticsearch y fue creado con las aportaciones de la comunidad, en base a necesidades identificadas en el uso de Elasticsearch. El objetivo es cubrir la definición de un estándar de campos de documentos para poder ser usados en eventos (métricas y logs) almacenados en Elasticsearch, con el claro propósito de poder ser usados en cualquier caso de uso en el Stack de Elastic (APM, seguridad, etc). Siguiendo el ejemplo anterior que poníamos de la ip de origen, ECS define el campo como ‘source.ip’ de tipo ‘ip’.
Beneficios principales de ECS
- Simplicidad para relacionar datos de distintas fuentes.
- Facilidad de recordar el nombre de campos comunes aun gestionando multitud de fuentes, ya que se mantienen en todas ellas igual.
- Posibilidad de reutilizar contenido de análisis previos, tanto visualizaciones y dashboards, como el resto de contenido, ya sean búsquedas, alarmas, reportes o trabajos de Machine Learning existentes.
Niveles de campos en ECS
ECS es una especificación inclusiva, ya que además de los campos establecidos, permite poder definir nuestros propios campos. Existen 3 niveles de campos:
- Core: listado de campos completamente definidos que están recogidos dentro del esquema.
- Extended: listado de campos parcialmente definidos que están recogidos dentro de ese mismo esquema.
- Custom: listado de campos definidos por el usuario que no están recogidos dentro del esquema, pero que siguen un patrón fijado para su normalización:
- Sólo utilizar minúsculas.
- No utilizar caracteres especiales, a excepción del punto y el guion bajo.
- No usar abreviaciones.
Respecto a estos últimos, es importante no olvidar que ECS es un esquema ‘vivo’ y que evoluciona, sufriendo modificaciones o ampliaciones en sus nuevas versiones. Por este motivo, es conveniente no definir campos que puedan entrar en conflicto con los ya existentes en ECS, o con los que puedan aparecer en un futuro. Para ello Elastic recoge una serie de buenas prácticas a tener en cuenta.
¿Cómo adoptar ECS a nuestro caso de uso?
Para aplicar ECS en los índices a gestionar de nuestras fuentes de datos en Elasticserach, como hemos comentado además de mantener la tipología necesaria de cada campo en nuestros índices, necesitaremos respetar la nomenclatura correspondiente en cada uno ellos. Para ello podemos realizar dos aproximaciones:
- Utilizar beats para la recogida de logs: Todos los beats respetan el ECS, por lo que no es necesario realizar modificaciones previamente a la ingesta en Elasticsearch.
- Modificar la nomenclatura antes de la ingesta en Elasticsearch: Para ello podemos utilizar alguna herramienta que nos permita realizar esta la transformación de nomenclatura. En el caso del Stack de Elastic, podríamos utilizar Logstash o los nodos de ingesta para este propósito.
Siguiendo el ejemplo anterior de la ip de origen, veamos cómo podemos hacerlo con el uso de rename, modificando el campo ‘mi_ip_origen’ por ‘source.ip’, el correspondiente en ECS:
Pipeline Logstash:
filter {
mutate {
rename => {
"mi_ip_origen" => "[source][ip]"
}
}
}
Pipeline ingesta:
{
"rename": {
"field": "mi_ip_origen",
"target_field": "source.ip"
}
}
Junto al cambio de nomenclatura, necesitaremos definir en el mapeo su tipología, que en este caso será ‘type: ip’.
SIEM (Security Information and Event Management)
Elastic Security ofrece SIEM (Security Information and Event Management). Esta solución gratuita del stack, nos brindará la información útil que necesitamos obtener sobre potenciales amenazas de seguridad, agilizando así su priorización, gracias a la estandarización de datos en ECS.
Como veremos posteriormente con un ejemplo práctico, esto es posible mediante la capacidad de análisis centralizado de los datos de seguridad que nos proporciona una consola interactiva, obteniendo y centralizando así los eventos de los múltiples sistemas de nuestra organización (aplicaciones de prevención de intrusiones, antivirus, firewalls, etc).
Adicionalmente, como viene siendo habitual con otros muchos módulos en Kibana, este módulo podremos integrarlo con ML si disponemos del licenciamiento correspondiente, y sacarle así todo su potencial. Para ello Elastic nos proporciona de forma predefinida decenas de trabajos de detección de anomalías.
Ejemplo práctico de Elastic SIEM
El objetivo de este post es mostrar, con un ejemplo lo sencillo, qué puede ser para un analista de seguridad empezar a ingestar datos en Elastic y monitorizarlos/explotarlos haciendo uso de la consola interactiva disponible en el módulo de seguridad de Kibana.
Para mostrarlo, vamos a basarnos en un ejemplo simple, que muestre cómo detectar actividad de login de usuarios anómala, en base a los eventos recogidos por Auditbeat. Como comentamos en el post anterior, Auditbeat es un Beat de Elastic que nos permite recoger datos de auditoría, monitorizando procesos y la actividad de usuario en tiempo real, así como la posibilidad de monitorizar la integridad de ficheros y reportar los cambios detectados en tiempo real. En este ejemplo usaremos la versión de Linux, la cual se integra con el framework de audit.
Una vez que Auditbeat esté recogiendo datos de auditoría de la máquina, simularemos un intento de autenticación anómalo en el servidor desde otro servidor de la red: se realizarán múltiples accesos que resultarán fallidos, con un último acceso correcto mediante el cual se realizará una ejecución de un servicio.
Veremos como toda esta actividad reportada por Auditbeat podrá ser visualizada ágilmente desde el módulo de seguridad de Kibana, aportando información valiosa al equipo de analistas de seguridad sobre las acciones realizadas. En un entorno real, ante una brecha de seguridad en nuestra organización, esta información podrá ser relacionada con otras fuentes de datos corporativas disponibles en nuestro clúster de Elastic, lo cual ofrecerá una visión global de los eventos producidos tanto en esa franja horaria como previamente y posteriormente, facilitando así su investigación. Todo el trabajo de investigación, podremos realizarlo mediante la relación de campos y filtros en la consola interactiva proporcionada (Timeline). Timeline permite guardar en todo momento los trabajos de investigación realizados, añadir comentarios sobre ellos, etc. pudiendo ser recuperados y modificados por otros miembros del equipo que requieran trabajar sobre ellos en cualquier momento. Además, la herramienta permite la creación y gestión de casos para que varios equipos puedan trabajar sobre el incidente desde Kibana, pudiendo adjuntar al caso los Timelines trabajados e incluso enviar dichos casos a sistemas externos de gestión de incidentes como ServiceNow, Jira o IBM Resilient.
Si nuestra organización dispone de una subscripción del producto, adicionalmente podremos obtener funcionalidad asociada a detecciones sobre nuestros eventos de seguridad. Por poner dos ejemplos sobre este mismo caso concreto que vamos a mostrar, podríamos tener configurada tanto una alarma (subscripción mínima Oro) que nos notificara por diversos métodos (mail, slack, webhook, Jira, PagerDuty, etc) ante errores continuados de autenticación, como también un job de Machine Learning (subscripción mínima Platino) que, en base al aprendizaje obtenido, alertara sobre esta actividad de login anómala.
Instalar Audibeat en el servidor que vamos a auditar
Para ello podemos seguir los pasos recogidos en la documentación oficial, donde tras realizar la instalación dejaremos por defecto la configuración de módulos predefinida en auditbeat.yml, ya que cubre nuestro caso de uso, y arrancaremos el servicio.
Respecto al uso de Auditbeat en este ejemplo, comentar que en la actualidad el road map de Elastic es acabar unificando todos los beats en un sólo agente, que en base a la configuración realizada cubra una o más funcionalidades. Actualmente este agente, Elastic Agent, se encuentra en fase Beta, por lo que no es recomendable todavía utilizarlo en entornos productivos. Os animo a descargarlo y probar funcionalidades como la gestión centralizada de agentes desde Kibana con fleet.
En este ejemplo, el servidor donde hemos instalado Auditbeat es ‘Elastic-Master’. Ahora, desde el servidor de la red 192.168.0.242, realizaremos acciones de autenticación anómala sobre ese servidor.
Acciones de autenticación anómala
En nuestro caso, las acciones realizadas han sido una petición de ping, seguida por varios intentos fallidos de login de varios usuarios, un último acceso válido con el usuario ‘demo’ y una subida de fichero a un ftp externo desde el entorno de ese usuario.
Todas estas acciones son monitorizadas por Auditbeat e ingestadas siguiendo ECS en Elasticsearch. En nuestro ejemplo hemos realizado una instalación por defecto del agente, por lo que los eventos han sido ingestados en el patrón de índices auditbeat-* con su esquema predefinido.
Comprobación de actividad
Para comprobar dicha actividad, abrimos el módulo de Security (https://kibana_node:port/app/security) en Kibana, y veremos distintas pestañas en las que nos podemos ir moviendo (Detections, Hosts, Network, etc.), cada una de ellas centrada en un enfoque concreto de tipo de información. Por centrarnos en lo que queremos mostrar con este ejemplo, podremos ver el registro de autenticaciones dentro de la pestaña Hosts, en Authentications, donde claramente se observan una multitud de eventos de login fallido en el periodo analizado:
Todo el módulo es interactivo, por lo que si queremos por ejemplo filtrar sólo por los eventos fallidos detectados, podremos situarnos sobre failure y clicar la lupa +:
Tras la activación del filtro, toda la información mostrada en el módulo aplicará esta restricción. El módulo permite en todo momento analizar el dato de forma interactiva, mediante el uso de filtros y búsquedas en la barra de búsqueda proporcionada.
Como vemos, todos los intentos de login fallido han sido en esa franja horaria y estos han sido de varios usuarios. Si queremos comprobar qué usuarios se han logueado satisfactoriamente en ese periodo de tiempo, una opción sería situarnos sobre la pestaña Events.
filtrar por la acción authenticated
y, clicando sobre el filtro previamente activo, excluir dichos resultados para obtener la información deseada. Esta acción sería similar a editar el filtro para filtrar por eventos success.
Vemos que se muestran 2 eventos relacionados con autenticaciones satisfactorias. El usuario que se indica es ‘demo’ y este se ha autenticado mediante ssh en el equipo ‘Elastic-Master’.
Respecto a la información mostrada en el resumen de eventos, podremos seleccionar qué campos mostrar en las columnas y en qué orden.
Analizando el dato y usando Timeline
Llegado a este punto podemos necesitar seguir analizando el dato en ese periodo de tiempo y dejarlo reflejado en un Timeline para recuperarlo con posterioridad o para que otros equipos de la organización puedan seguir trabajándolo. En nuestro caso vamos a ver si el usuario ‘demo’, que ha accedido remotamente al equipo, ha realizado alguna acción en este.
Timeline está visible en la parte derecha de la pantalla, permitiendo poder arrastra a él cualquier campo buscable del módulo de Elastic Security. Nos situaremos sobre el campo, y tras clicarlo lo arrastraremos a la derecha de la pantalla para añadirlo al Timeline.
Esta operación la haremos para todos los campos requeridos, seleccionando el operador AND o OR según queramos relacionar los campos para analizar los datos. En nuestro caso queremos ver los eventos realizados por el usuario ‘demo’, que podremos ver al abrir Timeline:
Los 20 resultados mostrados, los ordenamos cronológicamente pulsando sobre la columna @timestamp, y de un simple vistazo ya vemos como el usuario tras loguearse ha subido un fichero a un ftp externo.
Ante un ejemplo real en nuestra organización, donde contamos con miles de eventos y con orígenes de datos de varias fuentes de información, podríamos seguir investigando de forma ágil con sólo arrastrar o modificar los campos y sus relaciones en la parte superior del Timeline, obteniendo en cada caso los eventos relacionados.
Por ejemplo, podría tener sentido filtrar además por los que cuya acción haya sido marcada como ejecutada y visualizarlos junto a todos aquellos en que el destino haya sido la ip identificada en el ftp, cruzando la información entre todos los orígenes de datos definidos en la aplicación.
Como comentábamos con anterioridad, adicionalmente el módulo permite guardar nuestros Timelines, pudiendo añadir notas asociadas a estos y realizar toda la gestión de los Timelines guardados desde el propio módulo. Cualquier Timeline existente en el módulo, también podrá ser referenciado en los casos gestionados, ya sea en su apertura o durante su ciclo de vida.
Conclusiones
Si este sencillo ejemplo os ha dejado con ganas de profundizar más en la solución de seguridad que nos ofrece Elastic, está disponible la toda información del producto en la url oficial, así mismo, es posible tomar un primer contacto con la solución de forma rápida desde el propio entorno público de demo que ofrece Elastic.
Si requieres de soluciones relacionadas con Elastic Search o ciberseguridad, puedes contactarnos usando el formulario integrado en la esquina inferior derecha de esta página o usando el formulario de nuestra página de contacto.