En el actual paradigma en el que nos encontramos, donde cada vez las empresas tienen más proyectos en la nube o incluso ya trabajan de manera “híbrida”, la necesidad de contar con una plataforma de observabilidad que te permita averiguar fácilmente qué ocurre con cada uno de tus servicios o aplicaciones y ver cuál es su estado o posibles problemas, de una manera centralizada, es algo clave.
En las siguientes líneas vamos a intentar dar unas pequeñas pinceladas de los principios más importantes de la observabilidad y conoceremos una de las soluciones de la que muchos hablan y apuntan tendrá mucho peso dentro de las diferentes que ya hay en el mercado.
Observabilidad, en pocas palabras, es la capacidad de poder entender lo que está pasando a un servicio, aplicación o sistema gracias a la información recolectada y analizada de su funcionamiento
Dicho esto, puede que eso sea suficiente, pero al igual que hay una mentalidad DevOps, la observabilidad es un “mindset” que permite responder a cualquier pregunta acerca de mis aplicaciones y sistemas, mediante la recopilación y el análisis de datos los mismos.
Da igual la definición que queramos darle. La observabilidad no es sólo algo que pones a funcionar y luego cuentas en charlas o posts que tu aplicación “tiene observabilidad”; al final, lo importante, es que esta práctica añadida a tu negocio, te permitirá responder a preguntas y obtendrás un beneficio en forma de visibilidad e información, entendiendo por qué están ocurriendo las cosas.
“Nothing in life is to be feared, it is only to be understood. Now is the time to understand more, so that we may fear less”, Marie Curie.
Siguiendo con estas prácticas y filosofías los SOCs cuentan con un abanico de posibilidades de herramientas de SIEM que cada vez es más abundante.
Espera, espera… ¿SOCs?, ¿SIEM?
Un Centro de Operaciones de Seguridad (Security Operations Centre) es un equipo que supervisa, analiza y protege a una organización de todo lo referente a la seguridad y garantiza la seguridad de la información.
Este equipo no funciona de manera independiente a la empresa, sino que sigue una estrategia que integre los objetivos específicos de la empresa de los distintos departamentos.
Un SIEM (Security Information and Event Management) es una tecnología o serie de herramientas que proporcionan visibilidad de la red en un contexto de seguridad (indicando actividad sospechosa, gracias a diferentes reglas de configuración e inteligencia de correlación), permitiendo a los analistas de seguridad actuar sobre las amenazas sospechosas.
Hecho el breve pero necesario inciso para saber de qué hablamos, la mayoría de las herramientas SIEM que sirven para el objetivo de dar observabilidad a nuestra empresa se apoyan en los cimientos que el estándar de la industria, OpenTelemetry, va marcando. Este estándar tiene como idea fundamental dar recomendaciones de la industria para instrumentar aplicaciones que proporcionen esta telemetría, recogiéndose a través de la infraestructura y emitiendo toda lo recogido a un sistema de observabilidad.
Como decíamos antes, nos permitirá contestar diferentes preguntas, pero… ¿qué tipo de preguntas?
Evidentemente, partimos de la base de preguntas básicas como “¿por qué no responde nuestra aplicación?”, “¿qué error se está dando?”, “¿estoy siendo atacado?”, “¿han accedido a mi aplicación o los datos de la misma?”... Estas preguntas serán respondidas, pero esto es sólo la punta del Iceberg de la observabilidad.
Está práctica y el uso de estas herramientas debería permitirnos saber (o preguntar), si esos errores o problemas llegaron a impactar en la experiencia de nuestros usuarios.
Se trata de que estás métricas y por lo tanto estas preguntas y respuestas sean tan útiles que la observabilidad pase de ser algo “residual”, utilizado por un único equipo en la empresa, a que diferentes unidades técnicas o de negocio estén interesados en ella.
Un verdadero sistema de observabilidad debería poder responder tanto a las preguntas anteriores como ser capaz de responder a preguntas del tipo:
- ¿Qué provocó el error?
- ¿Qué éxito tuvo mi campaña de marketing?
- ¿Nuestra última release ha aumentado el ratio de conversión y compras?
- ¿El corte de servicio ha tenido un impacto negativo en nuestros usuarios en RRSS?
Recolectar datos e información es sólo el principio de ese “mindset” de observabilidad que hablábamos: hay que aplicar inteligencia a esa información y democratizar el acceso a la misma.
Hasta aquí hemos visto una mínima introducción a todo este mundillo de la observabilidad. Entre la amalgama de soluciones SIEM que hay, muchas de ellas de gran fama y recorrido, hay una de la que me gustaría hablar (y mojarme) y lo hago ahora que a día de hoy no ha salido siquiera en un cuadrante de Gartner, porque de lo contrario sería sencillo apostar ¿¿no?? :).
Como ya he adelantado se puede considerar a Chronicle una herramienta o solución SIEM, pero ¿qué la hace especial? Vamos a analizar diferentes puntos y veamos sus fortalezas.
Chronicle es un SIEM. La principal diferencia con productos similares es que es un SaaS construido sobre la infraestructura de Google Cloud, lo que aprovecha la integración con los productos de Google para resolver casos de uso de recopilación, correlación, búsqueda, detección y elaboración de informes sobre registros de seguridad locales y, ojo, importante, en diferentes nubes también.
Otra característica que en mi opinión lo hace diferencial es que por defecto conserva los registros de todo un año (365 días) sin procesar y normalizados, haciéndolos disponibles para la búsqueda, la detección y la elaboración de informes. Este punto es crítico para muchas empresas ya que elimina de un plumazo la barrera tradicional de: más datos igual a rendimiento más lento (o más coste), permitiendo a los usuarios escalar la detección de amenazas o anomalías en volúmenes de petabytes de datos.
Lo único que tienen que hacer los usuarios es enviar los registros de seguridad sin procesar a Chronicle, y su plataforma SaaS se encarga de toda la ingeniería de datos para que éstos sean útiles para poder explotarlos posteriormente.
Su arquitectura sigue las bases definidas en OpenTelemetry y pone a nuestra disposición una serie de vías para enviarle la información que queremos tener monitorizada
- Mediante un agente de ingesta, o lo que es lo mismo un software ligero implementado en la red o sistema origen que admite syslog, captura de paquetes y administración de registros o información de seguridad y repositorios de datos (SIEM) existentes.
Este agente recoge logs via syslog de los principales “appliances” como PaloAlto o Cisco los convierte a formato JSON y los envía a Chronicle - Un API de Chronicle que permite enviar registros directamente, lo que elimina la necesidad de usar más hardware o software en los entornos del cliente.
- Integraciones de terceros, a través de integración con API Cloud de terceros para facilitar la transferencia de registros, incluidas fuentes como Office 365 y Azure AD.
Los conjuntos de datasets actualmente soportados( para la ingesta en Chronicle es amplio y recoge muchas de las principales soluciones de mercado, nubes o productos de terceros lo que nos facilita de nuevo el poner todo a funcionar de manera rápida y una también rápida integración futura con nuevos orígenes de datos a monitorizar.
Cuando recogemos información de los diferentes sistemas, Chronicle nos da la posibilidad de dejarla en el formato que nos viene o nos ofrece transformarla a lo que llama UDM, o lo que es lo mismo, un modelo de datos unificados. Para ello, deberemos facilitar una mínima información para cumplir lo marcado por ese modelo. Esta información es variada, pero campos como el “tipo de evento a monitorizar” o “una marca de tiempo” serán necesarios.
¿Qué nos permite este formato UDM? Imaginemos que podemos ingestar todos los datos que recojamos de telemetrías y seguridad o que lo monitorizamos en una única y enorme tabla. Sigamos imaginando y pensemos que, gracias a ese formato, soy capaz de buscar por una IP o por un email. La potencia es enorme y su uso sencillo a la vez. Pero es que no queda aquí todo. Es que gracias a este formato, Chronicle irá “en background” correlacionando y normalizando datos para que datos como el host o direcciones MAC completen campos en registros que, de inicio, no los tenían, enriqueciendo la información recopilada de forma autónoma.
Gracias a ese formato UDM, Chronicle puede disponer de una capacidad de búsqueda muy potente.
Para empezar los usuarios cuentan con un dashboard de alarmado (que veremos más adelante), pero adicionalmente a este dashboard “reactivo”, los usuarios tienen la capacidad de buscar de forma activa entre los datos ingestados en Chronicle.
La solución permite hacer búsquedas “drill down” sobre eventos, tipos de evento y/o elementos monitorizados, sobre dominios, IPs o usuarios de una forma muy efectiva y rápida gracias al indexado de toda la información.
Adicionalmente, y como en otras herramientas, existe la capacidad de hacer búsqueda sobre la información “en crudo”, siempre algo menos efectiva pero necesaria en determinados casos. En este punto, ofrece el siempre interesante uso de las expresiones regulares para poder realizar una búsqueda mediante patrones.
Esta es una de las grandes bazas de Chronicle, la que en mi opinión hizo que fuera adquirido por Google por el potencial que tiene para ayudar a los clientes.
Chronicle trabaja de forma continua con los datos que el usuario le envía correlacionando una y otra vez con diferentes patrones/librerías de IOC (Inversión de control) para buscar anomalías o amenazas. Para esto, de base, cuentan con más de 500 librerías de inicio, y por si esto fuera poco nos permite crear las nuestras.
¿Es complejo crear mis propias reglas? Inicialmente solo hay una cosa que necesitas: conocer el lenguaje que utiliza para la creación de las mismas, Yara.
No es un lenguaje complejo y, gracias a la interfaz (IDE integrado) de Chronicle, nos va a permitir crear nuestras propias reglas, siempre teniendo en cuenta que vamos a tener que suministrar una información mínima para ello.
- Regla, un nombre y/o descripción.
- Meta, información adicional: una descripción más amplia, fecha de creación o autor.
- Eventos, donde definiremos “qué buscamos y dónde”. Aquí se puede hacer referencia a tipo de fichero, nombres, campos, etc.
- Match (opcional), otro parámetro importante porque te ayuda a “purgar” los resultados obtenidos, definiendo el número de resultados que te devuelve la regla/búsqueda, de tal forma que puedes hacer que esta regla sea más o menos específica en su búsqueda de anomalías.
- Condiciones, lista de condiciones que influyen sobre donde se aplicará el match de los eventos.
Aunque las diferentes soluciones SIEM de mercado permiten explorar datos (evidentemente), con mayor o menor acierto, una “necesidad” recurrente es la de poder explorar esos datos, o aplicar analítica y/o IA sobre los mismos, pero no siempre es posible.
A pesar de tener la información ya extraída desde sus orígenes y centralizada en un mismo sitio no es sencillo con algunos productos el poder realizar este tipo de exploraciones sobre los datos.
Aquí de nuevo Chronicle te da la posibilidad de buscar y explorar (como ya hemos visto) utilizando su potente buscador. Ahora bien, donde creo que es diferencial es que con muy pocos “clicks” somos capaces de volcar la información que nosotros queramos sobre Bigquery, lo que nos abre un abanico de posibilidades enorme.
Una vez en BigQuery puedes crear modelos que sean capaces de analizar tu información de manera constante o puedes conectar tu herramienta de BI preferida y tirar tus consultas para hacer dashboards de todo tipo o “trabajos forenses” mediante potentes consultas.
Es en este punto donde si no nos salimos del “ecosistema Google”, y lo conectamos con Looker, la integración se consigue en minutos y unos clicks. Además, el usuario puede aprovechar para construir sus informes del ecosistema “Looker Blocks” o, lo que es lo mismo, de un set de dashboards, alertas y filtros listos para usar.
Por último, pero no menos importante, me parece diferenciador el sistema de pricing que tienen. Muchas de las herramientas SIEM de este tipo, debido a que la volumetría suele ser enorme, cobran por volumetría. Aquí de nuevo Chronicle se desmarca al cobrar por licenciamiento de usuario, sin importar la cantidad de información que tú quieres meter en Chonicle.
Pienso que Chronicle va a dar mucho que hablar- No sé si será la herramienta que se establecerá como solución mayoritaria por tener a Google detrás y la competencia que ello supone, pero sí creo que su enfoque “estándar”, su facilidad de integración customización y explotación de la información, y posibilitar que los usuarios hagan suya la información recogida y le apliquen inteligencia relativa a su negocio, marcan un camino que seguirán incluso alguno de los grandes productos SIEM ya establecidos y reputados del mercado.
Y un último consejo: aplica la observabilidad o no lo hagas, pero no lo intentes!! :)
Tell us what you think.