Unidad 2.

Capa de recolección

I. Introducción y objetivos

II. Capa de recolección

III. Resumen

IV. Caso práctico con solución

V. Lecturas recomendadas

VI. Enlaces de interés

VI. Glosario
Lección 1 de 7

I. Introducción y objetivos

1.1. Introducción unidad

En esta unidad se revisará la primera capa que se encuentra en el ciclo de vida de cualquier log inmerso en
el ecosistema SIEM: la capa de recolección.

El funcionamiento de las soluciones SIEM se basa en la recopilación de los logs generados por los
dispositivos propios para después poder realizar acciones a posteriori sobre ellos.

Para ello, los fabricantes proporcionan sus propias soluciones, cada una de ellas con diferentes
características, por lo que parte del trabajo por hacer consistirá en conocer las necesidades de los clientes
para poder aplicar las herramientas que más se adapten a ellos.

En líneas generales, porque luego se explica detalladamente en el epígrafe dedicado a cada paso, se citan
las distintas fases que hay que abordar antes de cualquier integración.

En primer lugar, hay que identificar cuáles serían los logs que pueden aportar mayor nivel de información
para poder prevenir cualquier anomalía y monitorizar el entorno.

En segundo lugar, una vez conocida la tecnología que integrar, hay que analizar cuál sería el método idóneo
entre los que se pueden encontrar: mediante syslog (más común y sencillo), por fichero, por base de datos,
por API, etc.

En tercer lugar, vendrían las acciones realizadas por el técnico en la máquina encargada de recoger los logs
con el fin de presentarse de manera legible en la consola, como, por ejemplo, el parseo, la normalización, la
categorización, la agregación y el filtrado.

C O NT I NU A R

1.2. Objetivos de la unidad

1 Conocer el ciclo de vida de un log desde que sale de la fuente hasta que llega al SIEM.

2 Entender el funcionamiento de una solución SIEM.

3 Ser capaz de parsear cualquier tipo de log.

4 Definir una categorización adecuada en los logs para no afectar al rendimiento de la

plataforma.

5 Identificar qué logs serían susceptibles de un filtrado para no aumentar el consumo de EPS.
Lección 2 de 7

II. Capa de recolección

2.1. Integración de logs

Es importante conocer que las tecnologías SIEM siempre están limitadas, ya sea por licenciamiento (EPS o
GB/día) o por capacidad del propio aplicativo.

Es por ello que los logs deben seguir un proceso previo antes de integrarlos en cualquier SIEM, ya que se
puede estar llenando de logs inservibles el SIEM, llevando a un estado de bloqueo o elevando el precio en
términos de licencia o hardware.

Para ello, será necesario conocer previamente las tecnologías que se van a integrar, así como las
volumetrías de log aproximadas que generarán.

Por lo tanto, se plantean las siguientes preguntas:

¿Qué fuentes hay que Número de fuentes y tipología

integrar? de estas.
 ¿Qué auditoría hay que Volumetría de eventos
habilitar? generada.

¿Qué finalidad van a tener Reglas de correlación y threat

los logs? hunting.

C O NT I NU A R
2.2. Tipos de recolección
Una de las principales características de todo SIEM es la centralización de logs de diferentes fuentes,
independientemente de su tipología o naturaleza. 

Figura 1. Integración de fuentes en un SIEM. 

Fuente: elaboración propia. 

Para ello, la integración de fuentes en el SIEM puede realizarse empleando diversas formas, normalmente,
condicionados por la propia naturaleza de la fuente o necesidades del integrador o cliente.

Así, se puede categorizar la recolección en dos bloques diferenciados por el modo en que los logs llegan al
SIEM:

R E C O LE C C I Ó N A C T I VA R E C O LE C C I Ó N PA S I VA
Aquella en la que el SIEM o recolector lanza petición a la fuente para recoger sus logs. 
Ejemplos: consulta a una base de datos, query LDAP, WMI/RPC…

R E C O LE C C I Ó N A C T I VA R E C O LE C C I Ó N PA S I VA

Aquella en la que es la propia fuente la que envía sus logs al SIEM o recolector. 
Ejemplos: syslog, suscripción Windows, recogida mediante agente…

C O NT I NU A R

La recogida por agentes se trata de un método muy extendido y que goza de gran aceptación dentro de los
despliegues SIEM, ya que facilita tremendamente la tarea de recogida de logs. Sin embargo, tiene como gran
impedimento que se trata de una acción “intrusiva”, ya que, como cualquier software, consume recursos en
la máquina destino y no es un software que se encuentre bajo el control del cliente.

Otra arquitectura que se puede encontrar es disponer de un agente como elemento “centralizador” de logs
desde donde recoger los logs de diferentes fuentes y que este, posteriormente, los envíe al SIEM. 

En este tipo de arquitectura propuesta, los agentes deben ser desplegados lo más próximo posible a las
fuentes de datos con el fin de recoger los logs evitando atravesar firewalls o elementos de seguridad que
puedan bloquear o modificar los logs enviados.
 Figura 2. Despliegue de agentes en un SIEM.
Fuente: elaboración propia. 

C O NT I NU A R

Aunque los agentes pueden ser desplegados en la misma máquina fuente donde se pretenda recoger
eventos, no es recomendable, ya que tienen requisitos en cuanto a recursos de la máquina (disco, memoria,
CPU…) que desaconsejan su instalación en sistemas críticos, por lo que las buenas prácticas indican que se
dedique un servidor intermedio (virtual o físico) para realizar su despliegue.

Dicha máquina, comúnmente, se denomina “recolector” o “colector”, y desde ella se podrán recoger logs de
diferentes fuentes con uno o más agentes.
 Figura 3. Funcionamiento de un recolector en un SIEM.
Fuente: elaboración propia.

Ejemplos tecnologías SIEM:

A R C S I G HT Q R A DA R

La configuración básica de un agente (en ArcSight, denominado connector) requiere de 256 MB de RAM
dedicados, 1 core CPU y 1 GB de espacio en disco. Estos valores son los “estándar”, pero con base en las
necesidades, volumetría de eventos por fuente…, pueden ser modificados.

Pueden ser desplegados sobre entornos Windows o Linux.

A R C S I G HT Q R A DA R

En QRadar el agente que realiza la recogida de eventos es denominado WinCollect.

Este puede recoger eventos del sistema local sobre el que se encuentre desplegado o realizar recogida de
logs de un equipo remoto.
A modo información, estas son las características de este tipo de agentes:
 1

Recogida eventos en local (propio equipo):

Elemento Descripción

Hasta 1 EPS: 35 MB.

Hasta 100 EPS: 27 MB.

Memoria
Hasta 1000 EPS: 97 MB.

Hasta 10 000 EPS: 201 MB.

Procesador Intel Core 2 Duo processor 2.0 GHz.

Recursos del procesador

20 %.
disponibles

3 GB de espacio libre disponible para eventos.

Espacio en disco
6 GB de espacio libre disponible para eventos.

Tabla 1. Recogida eventos en local (propio equipo).

Fuente: elaboración propia.
 2

Recogida de endpoints (sistemas) remotos:

Elemento Descripción

Hasta 5 endpoints: 80 MB.

Hasta 250 endpoints: 293 MB.

Memoria
Hasta 500 endpoints: 609 MB.

Hasta 1000 endpoints: 1,77 GB.

Procesador Intel Core 2 Duo processor 2.0 GHz.

Recursos del procesador disponibles 20 %.

3 GB de espacio libre disponible para eventos.

Espacio en disco
6 GB de espacio libre disponible para eventos.

Tabla 2. Recogida de endpoints (sistemas) remotos.

Fuente: elaboración propia.
 WinCollect únicamente puede ser desplegado sobre entornos Windows.

C O NT I NU A R

2.3. Acciones realizadas por los recolectores

Independientemente del tipo de recolección (activa o pasiva) que se realice, los sistemas involucrados en la
recolección realizarán las siguientes acciones:

Figura 4. Acciones realizadas por recolectores.

Fuente: elaboración propia.
Hay que tener en cuenta que no todas las tecnologías SIEM realizan estas acciones en el mismo orden ni
ejecutan todas ellas. 

C O NT I NU A R

2.3.1. Parseo de logs

Entendemos por parseo de logs la separación en campos diferenciados de aquellos elementos que
conforman un log.

Para ello, se hará uso de expresiones regulares (regex).

Ejemplo

Tomando el siguiente log como ejemplo, se tendría que aplicar una

expresión regular como la que se muestra tras este:

Figura 5. Parseo de logs.

Fuente: elaboración propia.
 Regex: (\d{4}-\d{2}-
\d{2})\s(\d{2}:\d{2}:\d{2})\s(\S+)\s(\S+)\s(\S+)\s(\S+)\s(\S+)\s(\S+).

Entonces, ¿es necesario realizar esto para todos los logs que se integran en un SIEM? Por supuesto que no.

Los sistemas SIEM disponen de una base de tecnologías “conocidas” y disponen de parsers específicos
para todos los eventos recibidos de ellas. Sin embargo, sobre aquellos logs recibidos de tecnologías
desconocidas para el SIEM, será necesario realizar este tipo de acciones.

Ejemplo práctico: expresiones regulares y parseo/normalización de …  

  0:00 / 9:35 1x 

C O NT I NU A R
 2.3.2. Normalización
El proceso de normalización consiste en la asignación de campos identificados durante el proceso de
parseo a los campos definidos en la propia herramienta SIEM.

Esto significa que cada SIEM asignará sus propios nombres a los elementos de un log, no siendo
exactamente iguales en otro sistema de otro fabricante.

Sobre el ejemplo anterior:

Tabla 3. Proceso de normalización.

Fuente: elaboración propia.

La combinación parseo + normalización es algo esencial para poder analizar y usar los logs en reglas de
correlación, búsquedas, reportes…

C O NT I NU A R

2.3.3. Categorización
La categorización de logs se emplea como mecanismo de enriquecimiento de los logs proporcionado por el
SIEM.

El proceso consiste en asignar a dicho evento o log una categoría específica sobre la que se pueda
posteriormente explotarlo dentro del SIEM. 
¿Qué aporta exactamente?
–
Imagínese que se tienen integrados tres firewalls de diferentes fabricantes (cuyos logs son diferentes).

Por lo que, para un tráfico permitido, se tendrían en el campo “Action” Pass, Allow y Success para cada uno
de ellos.

De cara a hacer uso de esos eventos dentro del SIEM, habría que tener en cuenta siempre estos tres tipos
de eventos. 

Sin embargo, aplicándoles una categorización, se podría tener una categoría “Tráfico permitido”, la cual
recogiese estas tres casuísticas descritas anteriormente, simplificando el uso de todos ellos
enormemente.

Ejemplo

Otro ejemplo es disponer de una categoría que sea “Login”, la cual englobe
todos los eventos relacionados con login en entornos Windows (exitosos o
no), en entornos Unix, en aplicaciones propietarias, en sistemas críticos…, y
con una única búsqueda sobre los eventos, cuya categoría fuese “Login”,
estarían identificados.

Por último, los sistemas SIEM, actualmente, disponen de una categorización ya definida para aquellas
tecnologías que conozcan (dispongan de parsers nativos para ellos), pero ofrecen la posibilidad de crear
unas propias o modificar las existentes si así se necesita.
 C O NT I NU A R

2.3.4. Agregación
La agregación consiste en el proceso de agrupar aquellos eventos de la misma tipología que comparten
ciertos campos con idéntico valor recibidos en un periodo de tiempo definido, t, con el fin de reducir el
número de eventos recibidos.

Dichos campos son configurables por el administrador de la plataforma SIEM, así como la propia agregación
puede ser deshabilitada si así se desea.

Hay que tener en cuenta que no todos los SIEM ofrecen esta característica. Por ejemplo, en Splunk el
concepto de agregación no existe.

La siguiente imagen ilustra la agregación sobre eventos recibidos durante un periodo de tiempo t = 3 de un
firewall:
 Figura 6. Agregaciones sobre eventos recibidos.
Fuente: elaboración propia.

Como se puede apreciar en la imagen anterior, ante la llegada de tres eventos con ciertos campos iguales
(SourceIP, DestinationIP y DestinationPort), el SIEM agrega dichos eventos, quedando finalmente un único
evento, el cual mantiene los mismos campos y añade uno nuevo, EventCount, que corresponde al número de
eventos agregados que lo componen.

V E N TA JA DE S V E N TA JA S

La principal ventaja de la agregación reside, pues, en la cantidad de eventos recibidos en el SIEM, los cuales
se ven reducidos enormemente.

Como se verá posteriormente, los sistemas SIEM licencian según EPS (eventos por segundo) o GB/día de
datos recibidos, por lo que la agregación consiste en un proceso fundamental para evitar pagar sobrecostes
en términos de licencia.
Otra de las ventajas de la agregación es la liberación del sistema por el manejo de un menor número de
eventos.

Ejemplo

Por poner un ejemplo, los logs de un FW pueden llegar a tener una agregación
de 1/100.

V E N TA JA DE S V E N TA JA S

Sin embargo, también tiene desventajas en cuanto a que la información de aquellos campos por los que no
se agrega se pierde.

Ejemplo

En el caso de la imagen anterior, por ejemplo, los EventID se pierden y no

aparecen en el evento final.

Este proceso, pues, tiene sus pros y contras, y el administrador de la plataforma debe prestar especial
atención a este punto para evitar la pérdida de información importante por no aplicar unos parámetros de
agregación apropiados.

C O NT I NU A R
 2.3.5. Filtrado
Como su propio nombre indica, el proceso de filtrado sirve para, con base en unas condiciones definidas y
configurables por el administrador de la plataforma, filtrar aquellos eventos que no se quieren en el SIEM.

Idealmente, para evitar realizar cualquier tipo de filtrado, se debería ir a la fuente y configurar una política de
auditoría apropiada, de forma que se impida que los logs inservibles lleguen al SIEM. Sin embargo, en
multitud de ocasiones esto no es posible o simplemente el sistema genera cierta información sin posibilidad
de configurar su no envío.

Es por ello que este proceso cobra especial importancia, ya que, como se ha comentado anteriormente, la
agregación puede impactar negativamente en el rendimiento de la plataforma y el consumo de espacio en el
SIEM, y repercutir en costes directos en términos de licencia.
Lección 3 de 7

III. Resumen

Repasa los conocimientos adquiridos en la unidad

En esta unidad se analiza el ciclo de vida del log desde el momento en que sale de la fuente hasta que se
presenta en la consola.
Como se ha visto, el proceso consta de varias fases de las que el técnico es responsable, y se debe
realizar bajo unas directrices de buenas prácticas.

Con el objetivo de cubrir las necesidades (ausencia de casos de uso) en un área determinada, es
necesario conocer cuál es la tecnología adecuada que integrar y la manera correcta de proceder, que
suele venir recomendada por el fabricante.

El parseo de los logs y la normalización son tareas indispensables para cualquier acción que luego se
quiera llevar a cabo sobre los eventos desde un análisis forense, el desarrollo de un caso de uso o la
generación de un simple reporte.
Desde el punto de vista técnico, también hay otras opciones, como pueden ser la agregación o el filtrado,
que hay que tener en cuenta tanto para el rendimiento de la solución SIEM como para evitar sobrecostes
en términos de licencia.

En resumen, todo lo realizado en esta primera fase tiene sus consecuencias en las siguientes, por lo que
hay que tener los conceptos muy claros para saber cómo aplicarlos de la mejor manera.
Lección 4 de 7

IV. Caso práctico con solución

Aplica los conocimientos adquiridos en esta unidad

ENUNCIADO

En este ejercicio se pide parsear mediante una expresión regular los campos en negrita del log mostrado
a continuación:
DATOS

{"AffectedItems": [{"Attachments": "Insurance cost calculation x insurance company.xlsx (19584b)", "Id":

"RgAAAABc1F41o8sXSbWWUXSeV/YcBwDbvwsf12oFRqnnElbi1sqAAAAAAZbCAACKOIbgmUFLQ5JsM
ArMnfrdAAPj2Zp6AAAA", "InternetMessageId": "
<AM0PR0602MB3524EB4D3491A9EA451DFCA3CE9A9@AM0PR0602MB3524.eurprd06.prod.outlook.co
m>", "ParentFolder": {"Id":
"LgAAAABc1F41o8sXSbWWUXSeV/YcAQDbvwsf12oFRqnnElbi1sqAAAAAAZbCAAAB", "Path":
"\\Borradores"}, "Subject": "RV: cost calculation "}], "ClientIP": "0.0.0.0", "ClientIPAddress": "0.0.0.0",
"ClientInfoString": "Client=MSExchangeRPC", "ClientProcessName": "OUTLOOK.EXE", "ClientVersion":
"16.0.11029.20078", "CreationTime": "2021-03-01T16:29:11", "CrossMailboxOperation": false,
"ExternalAccess": false, "Folder": {"Id":
"LgAAAABc1F41o8sXSbWWUXSeV/YcAQDbvwsf12oFRqnnElbi1sqAAAAAAZbCAAAB", "Path":
"\\Borradores"}, "Id": "cc9230e8-3faf-4e28-4368-08d8dccf257e", "InternalLogonType": 0, "LogonType": 0,
"LogonUserSid": "S-1-5-21-1515633669-3533847684-4264747135-1036087", "MailboxGuid": "5e7803b5-
a8e4-48d4-a41e-2be174096387", "MailboxOwnerSid": "S-1-5-21-1515633669-3533847684-4264747135-
1036087", "MailboxOwnerUPN": " XXX@yyy.com", "Operation": "SoftDelete", "OrganizationId": "16ff544a-
8a38-409c-a005-e7b569bebd13", "OrganizationName": "YYY", "OriginatingServer": "AM0PR0602MB3524
(15.20.3868.031)\r\n", "RecordType": 3, "ResultStatus": "Succeeded", "UserId": "XXX@yyy.com", "Version":
1, "Workload": "Exchange"}

Nota:

Se recomienda usar la herramienta online Regex101 para facilitar la tarea

y comprobar los resultados.
 VER SOLUCIÓN

SOLUCIÓN

(Una de las posibles, ya que la resolución tiene caminos múltiples e igualmente válidos):

CreationTime = 2021-03-01T16:29:11 -> .?\CreationTime\".*?\s\"(.*?)\"

Path = \\Borradores -> .*?\"Path.*?\s\"(.*?)\"

ClientIP = 0.0.0.0 -> .*?ClientIP.*?\s\"(.*?)\"

ResultStatus = Succeeded -> .*?ResultStatus.*?\s\"(.*?)\"

UserID = XXX@yyy.com -> .*?UserId.*?\s\"(.*?)\"

Lección 5 de 7

V. Lecturas recomendadas

Azodi, A.; Jaeger, D.; Feng, C.; Meinel, C. “A new approach to building a multitier direct access
knowledgebase for IDS/SIEM systems”. 2013 IEEE 11th International Conference on
Dependable, Autonomic and Secure Computing; 2013. DOI: 10.1109/DASC.2013.48.

Bussa, T.; Kavanagh, K. M. “Magic quadrant for security information and event management”.
Gartner; 2017. 

García, M.; Neves, N.; Bessani, A. “An intrusion-tolerant firewall design for protecting SIEM
systems”. 43rd Annual IEEE/IFIP Conference on Dependable Systems and Networks Workshop
(DSN-W); 2013. DOI: 10.1109/DSNW.2013.6615538.
Lección 6 de 7

VI. Enlaces de interés

ArcSight Enterprise Security Manager

IR A ENLACE

IBM QRadar

IR A ENLACE

Splunk Enterprise Security

IR A ENLACE

“WinCollect overview”.
IBM; s. f.

IR A ENLACE
Lección 7 de 7

VI. Glosario

El glosario contiene términos destacados para la

comprensión de la unidad

Agente
–
Elemento centralizador desde el que se recogen los logs de diferentes fuentes y que, posteriormente, el
agente envía al SIEM. 
Agregación
–
Proceso de agrupar aquellos eventos de la misma tipología que comparten ciertos campos con idéntico
valor recibidos en un periodo de tiempo definido, t, con el fin de reducir el número de eventos recibidos. 

Categorización
–
Mecanismo de enriquecimiento de los logs proporcionado por el SIEM. El proceso consiste en asignar a un
evento una categoría específica sobre la que posteriormente se pueda explotar dentro del SIEM.

Filtrado
–
Evitar aquellos eventos que no se quieren en el SIEM con base en unas condiciones definidas y
configurables por el administrador de la plataforma.

Normalización
–
Asignación de campos identificados durante el proceso de parseo a los campos definidos en la propia
herramienta SIEM.

Parseo de logs
–
Separación en campos diferenciados de aquellos elementos que conforman un log.
Recolección activa
–
Aquella en la que el SIEM lanza petición a la fuente para recoger sus logs.

Recolección pasiva
–
Aquella en la que es la propia fuente la que envía sus logs al SIEM.

Recolector o colector
–
Máquina desde la cual se pueden recoger los logs de diferentes fuentes con uno o más agentes.