Observational data collection

Uno de los elementos principales para una correcta correlación es que los campos de los distintos eventos tengan el mismo nombre cuando hacen referencia al mismo significado. Una IP de origen puede tomar distintos valores dependiendo de la fuente de origen (src_ip, src, srcIp, …) Esto hace que cuando deseamos buscar eventos distintos relacionados con una misma identidad, o no se pueda, o se deban contemplar todo el abanico de posibilidades dentro de la consulta. Para evitar todos estos problemas, se introduce el concepto de normalización de los campos dentro de los eventos. A partir de la normalización el campo IP origen pasa a llamarse, en cualquier caso, por ejemplo, src_ip.

La normalización que hemos elegido y que se puede aplicar tanto en origen (que será lo que haremos) como dentro de la arquitectura de Splunk, es la que se implementa dentro de Splunk.

Otro motivo justificado para usar esta normalización es que en un futuro con los campos en formato CIM se podrá migrar más fácilmente a una solución como es Splunk Enterprise Security.

Veamos pues en qué consiste el modelado CIM. Es un modelo semántico compartido cuyo objetivo es extraer valor de los datos. Se busca por tanto en base a una colección de modelos de datos, el tratamiento coherente y normalizado de los datos para conseguir una máxima eficiencia en el momento de la búsqueda.

Cada modelo de datos consta de un conjunto de nombres de campo que definen el mínimo común denominador de un dominio de interés (por ejemplo, la IP de origen que se comentaba anteriormente).

Mediante datos modelados correctamente podemos relacionar distintas fuentes, acelerar los datos clave en búsquedas y paneles, o la creación de informes y visualizaciones. Otro elemento que también usaremos serán las etiquetas. Estas etiquetas preconfiguradas permiten también agrupar valores de campo relacionados por el modelo de datos (crearemos etiquetas personalizadas, junto a las propias que ya existen dentro del modelo CIM). Todo lo anterior permitirán que los análisis, validación y las alertas sean implementadas de forma más fácil y consistente.

El motivo de la existencia del modelado CIM es que ayuda a la normalización de los datos dentro de Splunk. Estos datos coinciden con un estándar común,

utilizan los mismos nombre de campo y etiquetas agrupadas por eventos relacionados de diferentes fuentes o proveedores. Además, otra de las grandes ventajas que introduce esta normalización es la posibilidad de la aceleración de datos. Es interesante el parar de analizar el modelado CIM por un momento para explicar en qué consiste la aceleración de los datos: lo que se acelera es un modelo de datos, con esta acción lo que se le está diciendo a Splunk es que resuma sus datos sin procesar periódicamente, haciéndolo únicamente sobre los campos indicados. Es decir, se reindexan grupos de datos con un menor tamaño (solo los campos necesarios normalizados). Esto tiene un primer coste negativo a nivel de rendimiento y de consumo de licencia, pero que posteriormente se ve compensado en cuanto se pueden realizar búsquedas mucho más rápidas y por tanto más eficientes.

El CIM actúa como un esquema de tiempo de búsqueda ("esquema sobre la marcha") para permitirle definir relaciones en los datos del evento mientras deja intactos los datos sin procesar de la máquina.

Lo normal dentro de una arquitectura dedicada de Splunk es que los datos de las fuentes provengan de forma ‘desordenada’ de las distintas fuentes de origen. Dichos datos se almacenan en bruto (raw), para posteriormente y ya en tiempo de consulta, y mediante el uso de los add-ons, normalizase los campos. Sin embargo, en el presente proyecto la mayoría de las veces no lo haremos así. En base a la normalización que conocemos, enviaremos los eventos de origen (es decir, desde el Data Lake) ya normalizados. De esta forma, no será necesario ningún tipo de add-on (que deberíamos crear) de parseado para la normalización. De hecho, dado que los campos que provienen del Elastic son campos con valores tipo JSON, no tendría demasiado sentido el tener que crear los ficheros de parseo (transforms y props) dentro del SH en base a expresiones regulares cuando ya desde el origen le podemos dar el valor de campo deseado.

Actualmente dentro del modelo CIM de Splunk podemos encontrar hasta un total de 22 categorías. Estas son las siguientes: Alerts, Authentication, Certificates, Change, Databases, Data Loss Prevention, Email, Endpoint, Interprocess Messaging, Intrusion Detection, Inventory, Java Virtual Machines (JVM), Malware, Network Resolution (DNS), Network Sessions, Network Traffic, Performance, Splunk Audit Logs, Ticket Management, Updates, Vulnerabilities y Web.

Cada uno de los eventos que enviemos desde el Data Lake a Splunk deberá de identificarse dentro de cada una de estas categorías, para posteriormente identificar el nombre de cada uno de los campos de interés.

Como ejemplo vamos a ver cómo se parsearía un evento de tipo Malware. Dentro de la documentación de Splunk podemos ver que las etiquetas (tags) asociadas a este tipo de evento son las siguientes:

Dataset name Tag name

attack

Malware_Operations malware

operations Tabla 4. Etiquetas para tipo Malware

La documentación de Splunk nos indica que Malware_Attacks está diseñado principalmente para buscar y crear alertas relacionadas con posibles infecciones de malware en el entorno analizado. El Dataset Malware_Operations está relacionado con la monitorización de la salud y del estado operativo de las soluciones antivirus.

Nos facilita a su vez, una tabla donde se enumeran los campos extraídos y calculados para este Dataset en concreto. Un simple ejemplo lo podemos encontrar en parte de la siguiente tabla:

Nombre del Dataset Nombre del campo Tipo de dato Descripción Lista de posibles ejemplos Malware_Attacks action string Es la acción que

realiza el dispositivo. ES esperado: allowed Otros: blocked, deferred

Malware_Attacks category string Es la categoría del evento de malware, por ejemplo, podría ser un keylogger o un add-ware. Tabla 5. Ejemplo Dataset Malware

Por tanto, lo que vamos a tener que realizar es determinar los campos de los eventos relacionados con este tipo de categoría, y determinar si existe su equivalente. De ser así, dicho campo se normalizará. En caso de encontrarse con un campo no normalizado, se analizará si es posible realizar una normalización ad-hoc.