Elastic en Elastic: análisis a fondo de nuestra arquitectura SIEM
Elastic en Elastic
El equipo de Detecciones y Analíticas de seguridad de la información de Elastic es responsable de crear, ajustar y mantener las detecciones de seguridad que se utilizan para proteger todos los sistemas de Elastic. En Elastic nos llamamos a nosotros mismos "cliente cero" y nos esforzamos por usar siempre las versiones más recientes de nuestros productos.
En esta serie de publicaciones de blog ofreceremos una visión general de nuestra arquitectura, los datos que enviamos a nuestros clústeres, cómo y por qué usamos Cross Cluster Search (CCS) con las aplicaciones de seguridad y machine learning (ML), y de qué manera optimizamos y administramos esas alertas y las notificamos a los analistas.
Visión general del entorno de seguridad de la información de Elastic
Muchos productos de ciberseguridad y controles de seguridad están diseñados para dar soporte a una “red corporativa” tradicional con estaciones de trabajo y servidores en una red local, protegida por un firewall. Cuando se activa una alerta y necesitas realizar un análisis forense en un host, vas físicamente al sistema para volcar la memoria y crear una imagen del disco duro. En Elastic, por diseño, no somos una empresa “tradicional”, por lo que el equipo de seguridad de la información debe ser innovador y flexible para proteger Elastic sin intentar encasillar a la empresa “en nombre de la seguridad”. Por suerte, Elastic Stack es la solución perfecta para esto.
Elastic es una empresa global que está distribuida por diseño con clientes y empleados en más de 80 países de todo el mundo. La mayoría de nuestros empleados trabaja de forma 100 % remota y realiza sus tareas diarias desde una computadora portátil propiedad de Elastic, conectada a internet a través de redes no confiables de todo el mundo. Como empresa de open source, nuestro código fuente está en GitHub y nuestros sistemas de integración continua y compilación de software están basados en el cloud y son visibles públicamente para los colaboradores. Para monitorear y realizar análisis forenses con eficacia en esta red empresarial moderna distribuida, es necesario recopilar la información adecuada y tenerla disponible para los analistas en un solo lugar.
Además de nuestras estaciones de trabajo y sistemas empresariales, monitorizamos y protegemos Elastic Cloud, que ofrece servicios de Elastic SaaS que en la actualidad se ejecutan en 37 000 clústeres distribuidos en más de 40 regiones de la nube alojadas en AWS, GCP, Azure e IBM. Elastic Cloud es un entorno independiente con privilegios elevados, administrado por el equipo de Cloud, pero el equipo de seguridad de la información de Elastic es responsable de crear alertas, monitorizarlas y responderlas también.
Acercamiento a la infraestructura de seguridad de la información de Elastic
El equipo de ingeniería de seguridad (SecEng) de la seguridad de la información (Infosec) crea y mantiene nuestra colección de clústeres mediante Elastic Cloud on Kubernetes y Helm para desplegar infraestructura y mantenerse actualizado. SecEng administra siete clústeres diferentes: seis clústeres de "datos" con roles distintos y un séptimo clúster de "cabecera de búsqueda", como nuestra gestión de eventos e información de seguridad (SIEM) que usa CCS para hacer búsquedas y generar alertas sobre los datos en todos los demás clústeres. Usamos las versiones más recientes del stack y versiones preliminares con datos del mundo real con el fin de que los desarrolladores del stack usen con regularidad nuestros clústeres para buscar y solucionar problemas, y para mejorar a Elastic Stack para nuestros clientes.
Una de las claves para poder monitorear y proteger cualquier organización con éxito es recopilar los datos adecuados y tenerlos disponibles para su búsqueda en un solo lugar. No existe una única fuente de datos que tenga todo lo que necesitas para la seguridad de la información. Un reto común al que se enfrentan muchas organizaciones es no registrar y almacenar los tipos correctos de datos, sino hacerlo en ubicaciones separadas para cada tipo. A veces, los datos deben mantenerse separados debido a los distintos niveles de sensibilidad o privacidad. Con frecuencia, las fuentes de datos pertenecen a distintos equipos, que también las mantienen. Esto se debe al costo de transferir los datos a una sola ubicación. Gracias a las capacidades de CCS, podemos mantener los datos almacenados en clústeres separados y, al mismo tiempo, realizar búsquedas y generar alertas sobre esos datos desde una sola interfaz de Kibana, lo que ayuda a los analistas a tener el panorama completo.
Con toda la información visible en una sola ubicación, los analistas pueden crear sus entornos de detección, inteligencia de amenazas y respuesta a incidentes dentro de Elastic Stack. Cuando investigamos una alerta, podemos usar líneas de tiempo en la app Security para buscar algún valor en todos los índices. Además de las líneas de tiempo de la app Security, también usamos varios dashboards personalizados de "Investigación" que muestran la información que necesitamos de todos los distintos índices.
Escenario de alerta crítica
Imagina un escenario en el que recibimos una alerta crítica de que la cuenta de Okta de un empleado podría estar comprometida. También podemos ver que, durante el último mes, hubo algunas alertas de bajo riesgo relacionadas con el comportamiento en la estación de trabajo de ese usuario. Al principio se descartaron como falsas alarmas, pero ahora es necesario revisarlas de nuevo. Podemos usar el dashboard de investigación de usuario para buscar la dirección de correo electrónico de ese usuario y revisar con facilidad toda su actividad de autenticación de Okta, las apps a las que accedió mediante Okta Single Sign On, los archivos de Google Drive que consultó o modificó, su actividad en GitHub durante ese período y los archivos de o365 a los que se accedió mientras su cuenta podría haber estado comprometida. Un panel del dashboard muestra el inventario del sistema JAMF de la laptop de trabajo asignada a ese usuario, así como su información de contacto.
Con la información del sistema podemos pasar al dashboard de investigación de host para ver toda la actividad en ese sistema y si también ha sido comprometido o solo la cuenta de Okta. Si vemos que no hubo ningún usuario con sesión iniciada en el momento de las alertas, podemos saber que el sistema puede estar comprometido y que debe aislarse. Los eventos de Okta contienen la dirección IP que se usó para iniciar sesión. También podemos buscar esta IP para ver si aparece en alguno de nuestros otros conjuntos de datos, como los servicios de la nube en ese momento.
Las investigaciones de este tipo pueden llevar muchísimo tiempo si no tienes todos los eventos disponibles en un solo lugar. Sin una recopilación centralizada de los eventos, tendrás que iniciar sesión en las consolas de administración de cada uno de los servicios hospedados para revisar los logs en su entorno.
Lo mejor es la búsqueda entre clústeres (Cross Cluster Search)
La razón inicial por la que decidimos usar CCS fue que ya teníamos clústeres con datos, pero queríamos que se pudieran buscar todos nuestros datos desde un solo clúster para simplificar la administración de los Watchers, los dashboards, los trabajos de machine learning y las reglas del motor de detección. En lugar de migrar todos los datos a un solo clúster, decidimos usar CCS. Antes de CCS, teníamos que mantener todos esos objetos y configuraciones en varios clústeres, lo que solía duplicar el trabajo entre clústeres.
Cuando investigábamos una alerta, antes teníamos que abrir varias pestañas del navegador para ver las diversas fuentes de datos sobre el evento. Ahora, cuando investigamos una alerta, podemos crear un caso y una línea de tiempo en la app Security que incluyan cada evento relacionado con el caso. Por ejemplo, si vemos una alerta por actividad extraña en un servidor en los datos de Auditbeat y el evento contiene una dirección IP, podemos buscar esa IP dentro de una línea de tiempo en todos los índices y ver con rapidez si esa IP se detectó en alguno de nuestros otros servicios, como los datos de proxy de Nginx, Okta, GitHub, logs de Proveedor Cloud, eventos de estaciones de trabajo de Endgame y más. Gracias a ECS, los campos tienen un formato estándar en todos los patrones de índice, por lo que una búsqueda de source.ip devolverá documentos de cualquier índice con una coincidencia.
Además de estas razones iniciales, encontramos muchas más ventajas en esta configuración. A continuación, se encuentran algunas de las ventajas que hemos encontrado al usar Cross Cluster Search para seguridad.
- Al guardar diferentes tipos de datos en clústeres separados, evitamos tener un único punto de falla para todos nuestros datos. Al actualizar un clúster, todos los demás clústeres quedan disponibles para usarlos.
- Podemos ofrecer acceso a los desarrolladores para probar y solucionar problemas en un clúster de datos específico sin otorgarles acceso a todos los datos que usa Infosec.
- Los datos de los clústeres de Observability y APM suelen ser muy útiles para los analistas de seguridad durante una investigación. En lugar de duplicar todos los datos, podemos agregar los clústeres remotos a nuestra configuración de CCS.
- Se les pueden otorgar privilegios elevados a los analistas para crear y administrar alertas e índices en el clúster de SIEM, con acceso de solo lectura a los datos originales en el clúster remoto. Esto brinda a los analistas todas las capacidades en Kibana y también protege la integridad de los datos originales con fines de auditoría y cumplimiento normativo.
- Si actualizas el clúster principal de cabecera de búsqueda de Elastic a una versión nueva, tendrás acceso a todas las características nuevas de Kibana, incluso si los demás clústeres aún no se han actualizado. Esto te quita mucho estrés a la hora de actualizar tu SIEM de producción con frecuencia y desde el principio, ya que te permite probar las funciones más nuevas sin correr el riesgo de que se produzcan interrupciones en los clústeres que contienen los datos reales.
- A partir de la versión 7.13, los usuarios de Fleet deben tener privilegios de superusuario en el clúster. Podemos limitar la cantidad de administradores de Fleet en su clúster y, al mismo tiempo, otorgar a todos los demás usuarios privilegios de solo lectura sobre los eventos recopilados por el clúster de Fleet.
Customer Zero (continuación)
En esta publicación hicimos un repaso general de la forma en que el equipo de seguridad de la información de Elastic utiliza todas las capacidades de Elastic Stack para recopilar datos de diversas fuentes y ofrecer a los analistas una visibilidad excepcional de los eventos relacionados con la seguridad.
No olvides volver para leer la segunda parte de esta serie, que profundizará en los tipos de datos que se pueden buscar en Elastic SIEM y en cómo puedes ayudar a tus equipos a simplificar y agilizar sus esfuerzos.