Despliegue de un SIEM en una red corporativa
Sergio Faraldo Graña
Tutores: Ana Fernández Vilas y Esteban Martínez Germande
Curso 2020/2021 Sergio Faraldo Graña Despliegue de un SIEM en una red corporativa Trabajo Fin de Máster. Curso 2020/2021 Tutores: Ana Fernández Vilas y Esteban Martínez Germande
Máster Inter-Universitario en Ciberseguridad Universidade de Vigo Escuela de Ingeniería de Telecomunicación Rúa Maxwell s/n 36310, Vigo Abstract
This thesis details the implementation of a SIEM (Security Information and Event Management) system in the CTAG’s corporate network. This system gathers in- formation from networking hardware (firewalls, switches and routers) and from the main servers in order to present it in a unified manner, through visualizations and alerts. This facillitates significantly the detection and investigation of security incidents.
The implemented SIEM system combines Wazuh, mainly in charge of collecting logs, with Elastiflow, which collects network packet flow data. Both tools use Elastic- search for data storage and Kibana for visualizations. The fact these two programs form the backend allows the addition of new visualizations and the incorporation other kinds of data in order to increase the scope of the SIEM system or to enrich the data collected by Wazuh or ElastiFlow.
The system’s deployment was done on several virtual machines, in the form of a cluster, with the goal of improving its availability. Once the deployment had been completed, tests were carried out in order to verify its correct operation.
Keywords — SIEM, Wazuh, ElastiFlow, Elastic Stack, Cibersecurity, Monitoring
iii
Resumen
En este TFM se detalla el proceso de implementación de un sistema SIEM (siglas de security information and event management system, en español: gestión de in- formación y eventos de seguridad) en la red corporativa del CTAG. Este sistema recoge información del hardware de red (firewalls, switches y routers) y de los prin- cipales servidores presentes en ella para presentarla de forma unificada mediante visualizaciones y alertas. Esto facilita en gran medida la detección y la investigación de incidentes de seguridad.
El sistema SIEM implementado combina Wazuh, encargado principalmente de la recogida de logs, con ElastiFlow, el cual recolecta datos del flujo de paquetes de red. Ambas herramientas usan Elasticsearch para el almacenamiento de datos y Kibana para su visualización. El hecho de que usen estos dos programas permite añadir visualizaciones nuevas e incorporar otros datos para aumentar el alcance del SIEM o enriquecer la información recogida por Wazuh o ElastiFlow.
El despliegue del sistema se realizó en máquinas virtuales, en forma de clúster, con el objetivo de mejorar su disponibilidad. Finalizado dicho despliegue, se realizaron pruebas sobre el mismo para comprobar su correcto funcionamiento.
Palabras clave — SIEM, Wazuh, ElastiFlow, Elastic Stack, Ciberseguridad, Moni- torización
v
Índice general
1. Introducción 1 1.1. Contexto y objetivos ...... 1 1.2. Metodología ...... 3 1.3. Estructura del documento ...... 5
2. Estado actual de la red 7 2.1. Tipos de datos ...... 8 2.1.1. Logs ...... 9 2.1.2. Flujo de red ...... 10
3. Software SIEM en el mercado 13 3.1. Software para el tratamiento de logs ...... 13 3.2. Software para el tratamiento de datos de flujo de red ...... 15 3.3. Elección de software ...... 16 3.3.1. Software para el tratamiento de logs ...... 16 3.3.2. Software para el tratamiento de datos de flujo de red ..... 19 3.3.3. Funcionamiento conjunto del software ...... 19
4. Recomendaciones oficiales de hardware 21 4.1. Elasticsearch ...... 21 4.2. Wazuh ...... 22 4.3. ElastiFlow ...... 23
5. Estimación del almacenamiento 25
6. Diseño 27 6.1. Diseño completo ...... 27 6.2. Funcionamiento del SIEM ...... 29 6.2.1. Logs ...... 29 6.2.2. Datos de flujo de red ...... 30 6.3. Clúster Elasticsearch ...... 30 6.4. Clúster Wazuh ...... 32 6.5. ElastiFlow ...... 33 6.6. Alcance del SIEM ...... 34
vii 7. Implementación 35 7.1. Instalación de un clúster laboratorio ...... 35 7.1.1. Clúster Elasticsearch ...... 36 7.1.2. Clúster Wazuh ...... 36 7.1.3. ElastiFlow ...... 37 7.1.4. Agente Wazuh de prueba ...... 37 7.2. Creación de decoders y reglas personalizadas ...... 37
8. Despliegue en producción y realización pruebas 41 8.1. Prueba de carga ...... 41 8.1.1. Resultados ...... 42 8.2. Pruebas del agente Wazuh ...... 47 8.3. Prueba de ElastiFlow ...... 54
9. Cambios adicionales realizados 59 9.1. Dashboard resumen ...... 59 9.2. Dashboard de inicios de sesión de VPN ...... 59 9.3. Integración con DHCP ...... 62
10.Conclusión 65 10.1. Trabajo futuro ...... 66
Bibliografía 67
A. Apéndices 71 A.1. Despliegue del clúster Elasticsearch ...... 71 A.1.1. Instalación del repo de elastic 7.x ...... 71 A.1.2. Instalación de los programas ...... 71 A.1.3. Configuración ...... 72 A.2. Despliegue del clúster Wazuh ...... 75 A.3. Despliegue de ElastiFlow ...... 78 A.4. Actualización de versión del sistema ...... 80 A.4.1. Actualización de Wazuh ...... 80 A.4.2. Actualización de ElastiFlow ...... 80 A.5. Decoders y reglas creados ...... 81 A.5.1. Swivel ...... 81 A.5.2. Fortigate ...... 85 A.5.3. Cisco Firepower ...... 91
viii Introducción 1
Este trabajo consiste en el despliegue de un sistema SIEM en la red del Centro Tecnológico de Automoción de Galicia (CTAG).
Un sistema SIEM (siglas de Security Information and Event Managment, en español: Gestión de Información y Eventos de Seguridad) recoge, almacena y procesa datos sobre eventos de seguridad producidos en los sistemas de la red. La mayor parte de esta información se suele recoger en forma de logs, aunque también pueden recoger paquetes IP u otras formas de telemetría. Estos datos se almacenan de forma centralizada permitiendo correlacionarlos para obtener más información sobre eventos de seguridad, y facilitando la creación de alertas y visualizaciones para mejorar la visibilidad de eventos importantes.[1]
El CTAG es un centro tecnológico reconocido por el Ministerio de Economía y Competitividad. Fue fundado en el año 2002, emplea a más de 600 ingenieros y técnicos, y ofrece a empresas del sector de la automoción servicios auxiliares de desarrollo, diseño, prototipado y prueba de vehículos y sistemas del automóvil. Tiene su sede principal en Porriño, en el Polígono Industrial de A Granxa, y otras dos sedes en Francia y Rumanía.
El despliegue del SIEM1 será un importante paso para el CTAG en cuanto a la mejora de la ciberseguridad en la extensa red interna, con más de 1000 equipos, entre ordenadores personales, servidores y equipos vinculados a maquinaria.
1.1 Contexto y objetivos
Durante la pandemia del COVID-19, con el cambio del modelo de trabajo presencial a uno de principalmente teletrabajo, se ha visto un gran aumento en el número de ciberataques. La implementación de nuevos servicios para el teletrabajo ha causado el aumento en el número de vulnerabilidades en muchas empresas, aumento que ha sido aprovechado por grupos de cibercriminales.[2]
1De esta página en adelante, me referiré a los sistemas SIEM simplemente como SIEM (omitiendo sistema)
1 En Suiza, en abril de 2020 se han registrado aproximadamente 350 ciberataques por semana, frente a la cifra normal de entre 100 y 150.[3] Entre las víctimas de esta ola de ciberataques, también se encuentra el CTAG, que sufrió un ataque el pasado octubre.[4] En este ambiente de elevada ciberdelincuencia, el cual no va a mejorar en el futuro próximo según proyecta INTERPOL, es necesario reforzar la seguridad informática de la empresa.[2]
Mejorar la ciberseguridad implica la creación de un SOC (Centro de Operaciones de Seguridad), esto es, un equipo de ciberseguridad. Para ello no solamente hace falta tener el personal, sino también tener desplegadas las herramientas necesarias para sus operaciones, siendo la herramienta principal un SIEM.[5]
La red del CTAG ya tiene sistemas de recolección de logs y de datos de flujo de red, pero no están siendo analizados. Esto dificulta el proceso de detección de eventos de seguridad y la respuesta a ellos, dado que el único modo de filtrar información es la búsqueda entre los logs, archivo por archivo.
El principal objetivo del despliegue de un SIEM es ganar visibilidad sobre los eventos de seguridad que tengan lugar en la red y en los dispositivos conectados a ella. En base a este objetivo general, se definen los siguientes objetivos específicos: Centralización de los datos
La centralización de los datos en un único programa es uno de los principales ob- jetivos del sistema SIEM. Esta es una de las principales funcionalidades que debe proporcionar, y facilitará considerablemente la investigación y detección de eventos de seguridad.[1] Creación de visualizaciones
La principal herramienta para detectar problemas de seguridad serán las visualiza- ciones. Estas pueden ser simples métricas que resuman los datos recogidos con el sistema (máximos, mínimos, medias), mapas (mapas con la geolocalización de los usuarios, por ejemplo), histogramas u otros tipos de gráficas. Estas visualizaciones permiten observar el estado de la red, y detectar de forma visual grandes anomalías, como usuarios intentando conectarse desde un país inusual, o picos de uso de red inesperados (posible señal de un ciberataque).
En el futuro, tras ganar algo de experiencia en el uso del SIEM, se podrían definir alertas, pero definirlas de forma prematura podría crear un gran número defalsas alarmas en caso de que se definan alertas muy sensibles a cambios en la red o podrían crear una falsa sensación de seguridad en caso de que sean todo lo contrario. Hasta
2 Capítulo 1 Introducción que se gane experiencia con el SIEM, entonces, se optará por usar las visualizaciones como método de detección de eventos de seguridad.
Filtrado y búsqueda datos
Para facilitar el proceso de respuesta a incidentes de seguridad y de investigación de los mismos a posteriori, es necesario poder usar filtros y búsquedas para obtener información más precisa. Filtros por IP, fecha y hora o usuario serían de gran utilidad, y estos filtros deberían poder aplicarse a las visualizaciones, además dea los datos en sí.
1.2 Metodología
Análisis
Para poder hacer un diseño del sistema, es necesario conocer tanto el software SIEM que se va a usar como los recursos hardware necesarios para ejecutar el software elegido. Para poder obtener estos datos, se ha realizado:
1. La definición del alcance inicial del SIEM en cuanto a tipo de datos ymáquinas de las que se van a recoger.
2. Una comparación de las opciones disponibles en el mercado en cuanto a soft- ware SIEM
3. Un estudio de los recursos de computación recomendados por el desarrollador del software para desplegarlo en un entorno de producción. Estas recomen- daciones se tendrán en cuenta a la hora de determinar el hardware necesario para el sistema.
4. Un análisis del espacio de almacenamiento que ocupan los datos de logs que se estaban recogiendo antes del despliegue del SIEM, para poder estimar el almacenamiento necesario.
Diseño
Una vez finalizado el proceso de análisis, se ha llevado a cabo el diseño del sistema. El diseño del sistema incluye no solamente las máquinas, sino también las conexiones
1.2 Metodología 3 entre ellas. Además, se da una estimación del hardware necesario para realizar el despliegue final, dado que para hacerlo se van a adquirir nuevos servidores. Implementación
Antes de realizar el despliegue de producción, se desplegó una versión simplificada del sistema. Este despliegue sirvió de laboratorio para crear las configuraciones necesarias para la correcta recolección de datos. También se han creado manuales para guiar el proceso de despliegue y actualización del SIEM(Apéndices A.1 A.2 y A.3).
En cuanto a configuración para la recolección de datos, se ha creado para loslogsde firewalls Cisco Firepower, firewalls Fortigate y servidores de autenticación Swivel. El resto de los dispositivos que forman parte del alcance del SIEM cuentan con con- figuraciones creadas por los desarrolladores del software empleado para recolección e ingesta de logs. Despliegue en producción y pruebas
En esta fase, se ha desplegado en SIEM en producción, en la red corporativa. Se han añadido los datos de forma progresiva para comprobar que el servidor soporta la carga de todos los logs y datos de flujo de red que forman parte del alcance. También se ha verificado el funcionamiento correcto del SIEM, con tests orientados a probar las funcionalidades del SIEM que no son simplemente recolección de logs o datos de red. En el caso del software elegido, esto incluye pruebas sobre:
• Inventario de H/W y S/W en los equipos monitorizados
• Control de integridad de archivos
• Detección de vulnerabilidades
• Evaluación de la configuración de seguridad
También se realizó un barrido de red, simulando la fase de reconocimiento de un posible ataque, para comprobar si es posible con el SIEM detectar un ataque en esta fase. El barrido no genera muchos paquetes, lo cual podría dificultar su detección a través de las visualizaciones de los datos de flujo de red. Adiciones finales al sistema
Una vez desplegado el sistema en producción, se realizaron también unas adiciones al sistema, las cuales no formaban parte del alcance inicial del proyecto. Están descritas en el apartado 9.
4 Capítulo 1 Introducción 1.3 Estructura del documento
El documento consta de las siguientes partes:
• Estado actual de la red. En este apartado, se describe a grandes rasgos la red interna, y se establece el alcance del SIEM.
• Software SIEM en el mercado. En este capítulo se enumeran las opciones en cuanto a software que se han considerado. Se expone también la elección del software a usar y los criterios empleados para tomar esa decisión.
• Recomendaciones oficiales de hardware. Para poder realizar una estima- ción inicial del hardware necesario, se ha partido de las recomendaciones ofi- ciales. En este capítulo se listan dichas recomendaciones.
• Estimación del almacenamiento. Además de las recomendaciones oficiales, también se debe conocer aproximadamente la cantidad de almacenamiento necesario para almacenar toda la información. En este apartado se muestra el análisis que se realizó en base a la cantidad de logs recogidos antes del despliegue del SIEM.
• Diseño. Este apartado detalla el diseño del SIEM, incluyendo los requisitos de hardware para los distintos servidores que lo conforman.
• Implementación. En este capítulo se describe el proceso de creación de ins- trucciones, configuraciones y demás archivos necesarios para la realización del despliegue.
• Despliegue en producción y realización pruebas. Este apartado detalla el proceso de despliegue en producción y las pruebas que se realizaron para asegurar el correcto funcionamiento del SIEM.
• Cambios adicionales realizados. Tras haber desplegado el SIEM en produc- ción, se realizaron adiciones al sistema que no estaban incluidas en el alcance inicial, en concreto la creación de tres dashboards (paneles de visualizaciones) y la adición de dos nuevas fuentes de datos (datos que se muestran en dos de los dashboards creados).
• Conclusión. En este último apartado, se resumen los resultados obtenidos, y se proponen futuras adiciones al SIEM con el fin de mejorarlo.
1.3 Estructura del documento 5
Estado actual de la red 2
La red del CTAG consta de un switch de capa 3 principal, al cual están conectados tres firewalls. Uno de ellos separa a la intranet de internet, mientras que losotros dos sirven principalmente como servidores VPN. Una DMZ1 con los servidores expuestos a internet está conectada directamente al firewall principal. El resto de la red interna está conectada al switch principal.
Se puede ver un esquema resumido de la red en la figura 2.1
FW1 Red DMZ
FW3/VPN FW2/VPN2 Switch Capa 3
Redes internas
Fig. 2.1.: Esquema general de la red del CTAG
1DMZ, siglas en inglés de "Zona desmilitarizada"(Demilitarized Zone), se refiere a una sección de la red expuesta tanto al resto de la red interna como a internet. Estas zonas suelen albergar servidores web o de correo electrónico y otros servicios que se tengan que ofrecer a internet.[6]
7 La intranet se divide en varias VLANs con distintos propósitos y distintos tipos de dispositivos: VLAN de pruebas, VLAN de administración, VLAN de servidores, VLAN de vigilancia y VLAN de mantenimiento, entre otras. También hay conexio- nes con sedes remotas, cada una con sus propias VLANs. La red es muy extensa, y con los recursos de los que se dispone actualmente para el despliegue del SIEM es inviable realizar recogida de logs de todos los servidores y el hardware de red.
Como ya se menciona en el apartado 1.1, ya se hacía recolección de logs y datos de flujo de red en un único servidor. Este servidor hace recolección de estos datosde una serie de máquinas, que por su importancia en la red es necesario monitorizar, principalmente el hardware de red. En concreto, se reciben logs de:
• 23 Switches Cisco
• 3 Switches SAN Brocade2
• 1 Firewall Fortigate
• 2 Firewalls Cisco ASA
• 1 Servidor de autenticación Swivel
Comparativamente con el número de dispositivos de la red, no es una gran cantidad, pero se trata de algunos de los más importantes en cuanto a seguridad (los firewalls, switches y un servidor de autenticación).
2.1 Tipos de datos
Los logs y la información de flujo de red se pueden presentar en distintos formatos, y antes de poder seleccionar un SIEM, es necesario saber qué formatos va a tener que procesar.
2Un switch SAN es un switch para una área de almacenamiento local (Storage area network), esto es, una red dedicada al acceso a almacenamiento nivel de bloques a una red de dispositivos. En este caso, estos switches están funcionando como una comunicación de alta velocidad entre los distintos edificios
8 Capítulo 2 Estado actual de la red 2.1.1 Logs
Los logs son entradas en un archivo de texto, en las cuales se registra un evento en un sistema. En los sistemas Linux, cada entrada se representa mediante una única línea de texto, en la cual se puede ver la fecha y hora del evento, el ordenador del que proviene (si no proviene del mismo ordenador en el que está el fichero de logs), el proceso que ha enviado el log, y el mensaje. El propio mensaje puede tener una estructura interna, incluyendo campos como la importancia del evento, el usuario que ha generado el evento u otros muchos, dependiendo del tipo de log y del programa que lo genere
Los mensajes pueden provenir del mismo ordenador donde se almacenan o pueden provenir de uno distinto. Para enviar estos logs a través de la red, se suele utilizar el protocolo Syslog. Este es el protocolo más usado en Linux y está disponible en el hardware de red que tiene el CTAG en CTAG (Cisco y Fortinet).[7]
Windows, al contrario que Linux, almacena los eventos en archivos binarios XML, con la extensión .evtx, y utiliza el protocolo WS-Management Protocol para trans- mitirlos a través de una red.[8][9]
En los archivos .evtx, a diferencia de en los logs de linux, se almacenan las entra- das en forma de datos estructurados, en vez de una única línea de texto. La gran ventaja de este sistema es que no es necesario desarrollar un decodificador para cada programa por separado, basta con crear uno para este tipo de archivo.
1
2.1 Tipos de datos 9 20 PORTATILSERGIO$ 21 WORKGROUP 22 0x3e7 23 S-1-5-96-0-0 24 UMFD-0 25 Font Driver Host 26 0x156b5 27 2 28 Advapi 29 Negotiate 30 - 31 {00000000-0000-0000-0000-000000000000} 32 - 33 - 34 0 35 0x384 36 C:\Windows\System32\wininit.exe 37 - 38 - 39 %%1833 40 - 41 - 42 - 43 %%1842 44 0x0 45 %%1843 46 47
El principal problema de estos archivos es que los logs no son legibles con un editor de texto, lo cual dificulta la creación de un decodificador propio sin laayudade librerías externas para realizar la lectura de este formato de archivo.
Como la red tiene tanto sistemas Linux como Windows, es importante que el SIEM soporte ambos formatos de logs.
2.1.2 Flujo de red
Los datos de flujo de red aportan información sobre el tráfico de red. En elcasode la red del CTAG, como la mayor parte de la red consta de dispositivos Cisco, esta información estará en el formato Netflow. En concreto, estará en la versión más reciente, Netflow V9, especificada en el RFC 3954 (Octubre [de 2004). 10][11]
10 Capítulo 2 Estado actual de la red Netflow es un protocolo generalmente encapsulado enUDP3. En cada paquete se envía información sobre uno o más Flow Records. En cada Flow Record se recoge información sobre un grupo de paquetes IP con características similares, un Flow. En concreto, todos los paquetes representados en un flow deben tener las mismas IPs y puertos (si el protocolo de transporte tiene puertos) de origen y destino y el mismo protocolo.
Netflow exporta, a grandes rasgos, una versión resumida y agrupada en Flowsdelos paquetes que observa un dispositivo de red. Para cada Flow no solamente exporta IPs, puertos y protocolos, se graban también otros datos como la interfaz por la que se ve el paquete (campo IF_NAME en NetFlow V9), direcciones mac de entrada y salida (IN_DST_MAC y OUT_SRC_MAC), número de paquetes asociados con el flow (IN_PKTS), otros 75 campos definidos en el RFC3954[11]. Además de los definidos en el RFC, hay muchos más, dado que la lista es ampliable. Netflowv9, a día 5 de Julio de 2021, cuenta con 98 campos definidos. IPFIX, otro protocolo similar, y compatible con Netflow v9, tiene[ 462 12][10]. No se emiten siempre todos los campos, dado que la mayoría de ellos son específicos de ciertos tipos de paquete, como bgpCommunity, pero aún así, el número de campos es muy elevado.
Con los datos de flujo de red, y unas herramientas de visualización adecuadas, se puede conseguir una imagen del estado de la red muy similar al estado real. Nunca se conseguirá una imagen exacta, ya que solamente se inspecciona una fracción de los paquetes que pasan por un dispositivo de red para crear datos de flujo de red, pero la información que proporciona sigue siendo de gran utilidad.
3Originalmente, estaba diseñado únicamente como un protocolo sobre UDP, aunque en la versión 9 se ha cambiado el diseño por uno agnóstico al protocolo de transporte empleado. En la red del CTAG, todos los paquetes de Netflow van encapsulados en datagramas UDP.
2.1 Tipos de datos 11
Software SIEM en el mercado 3
En este apartado se listan las distintas opciones que se han considerado en cuanto a software para crear el SIEM. Están divididas según el tipo de datos que reciben: logs o datos de flujo de red. La búsqueda fue centrada en estos dos tipos de software por separado con el objetivo de emplear ambas herramientas como parte del SIEM.
Se va a considerar únicamente software gratuito. Esto no solamente afectará en los costes, sino que también permitirá hacer un desarrollo y despliegue más rápido, dado que elimina la necesidad de esperar a la aprobación del gasto en licencias antes de comenzar
3.1 Software para el tratamiento de logs
El software considerado consiste de tres herramientas desarrolladas por empresas que también comercializan SIEMs de pago (SIEMonster CE, AlienVault OSSIM y Prelude OSS) y otras herramientas que carecen de competencia del mismo desa- rrollador (MozDef, Elastic Security y Wazuh). A continuación las presento en ese orden.
SIEMonster Community Edition
SIEMonster Community Edition es una colección de herramientas de código abierto y de los desarrolladores del software SIEMonster creada con el objetivo de crear un SIEM más accesible. El conjunto de herramientas incluye Elasticsearch, Kibana, Apache Ni-Fi, Suricata, Apache Kafka, The Hive, Cortex, PatrOwl, OPEN CTI, Wazuh y Prometheus.
Con todas estas herramientas, ofrece respuesta a incidentes, orquestación de opera- ciones de seguridad, administración de información de ciberinteligencia, y captura y análisis de paquetes de red. Es una solución muy completa, pero está limitada en
13 cuanto a escalabilidad (hasta 100 endpoints y 5000 eventos por segundo, despliegue limitado a 1 servidor[13]). AlienVault OSSIM
AlienVault OSSIM es una versión gratuíta de AlienVault USM Anywhere, con fun- cionalidades limitadas. La herramienta de pago es muy completa, pero en su versión gratuita, tiene carencias importantes, como la gestión de logs para investigaciones forenses.[14] Prelude OSS
Prelude OSS es la versión de código abierto de Prelude SIEM. Se define como un SIEM de código abierto para entornos de pruebas, limitado por su bajo desempe- ño. Los desarrolladores aconsejan usar Prelude SIEM para despliegues en produc- ción.[15] MozDef
MozDef, desarrollado por Mozilla, actúa como una capa intermedia entre un “ship- per”, el cual se encargaría de realizar todo el proceso de traducción de logs a formato JSON, y una base de datos, en el caso de MozDef, Elasticsearch.[16] Elastic Security
Se trata de un proyecto de los desarrolladores del Elastic Stack, una popular suite software para la recogida, procesamiento y visualización de logs.
El Elastic Stack está compuesto por[17]:
1. Elasticsearch: Motor de búsqueda basado en Apache Lucene. Almacena los datos (en este caso logs), y permite realizar consultas contra ellos (similar a una base de datos).
2. Kibana: Herramienta de visualización. Proporciona una interfaz web para la consulta de los datos almacenados en Elasticsearch y la creación de gráficas, tablas, mapas y otras visualizaciones.
3. Logstash: Software de ingesta. Se encarga del procesado de la información antes de su almacenamiento.
4. Beats: Agentes de recogida de datos. Los Beats son una familia de agentes (Winlogbeat, Filebeat, Metricbeat, Packetbeat…) que permiten recoger infor- mación en un equipo de la red y enviarla a Logstash o Elasticsearch para su procesamiento o almacenamiento.
14 Capítulo 3 Software SIEM en el mercado Elastic Security es un SIEM que se ejecuta sobre el Elastic Stack[18], dando acceso a todas las herramientas de procesamiento y recogida de datos nativas del mis- mo. Resulta muy atractivo debido a la gran cantidad de integraciones nativas que tiene.[19]
Wazuh
Este software fue creado en 2015, en base al proyecto OSSEC. Está basado en el stack de Elastic, utilizando Elasticsearch para almacenar las alertas y Kibana para su visualización. Wazuh ofrece, además del análisis de logs, monitorización de archivos, análisis de configuración y detección de vulnerabilidades en los dispositivos que tengan agente. Se incluyen también paneles preconfigurados de visualización para estas funcionalidades, así como paneles dedicados a la respuesta a incidentes y conformidad con normativas.[20]
3.2 Software para el tratamiento de datos de flujo de red
Una vez vistas las opciones para una herramienta de tratamiento de logs, se han buscado opciones para el tratamiento de datos de flujo de red. Estas son las opciones que se han considerado:
NFSen
NFSen es el programa que está desplegado actualmente. Se trata de una front-end para nfdump, que almacena los datos en una base de datos “round-robin”, esto es, tiene una cantidad de almacenamiento asignada y cuando llena esa cantidad, sobreescribe datos antiguos.
Muestra la información en forma de histogramas y tablas de datos principalmente. Se pueden también generar alertas con esta herramienta. El principal problema de este programa es que lleva sin recibir actualizaciones desde 2011.[21]
NFSen-NG
Diseñado como un sustituto de NFSen, también está basado en nfdump, y también utiliza una base de datos ‘round-robin”. Utiliza librerías más modernas para crear las visualizaciones, con lo cual ofrece una interfaz más moderna y compatible con
3.2 Software para el tratamiento de datos de flujo de red 15 dispositivos móviles[22]. Dicho esto, aún no tiene todas las funciones que tiene el original NFSen, como alertas o perfiles.[23] pmacct
pcmacct es un conjunto de herramientas de monitorización pasiva de red. Las he- rramientas en conjunto pueden capturar directamente paquetes IP, datos de flujo de red, paquetes BGP y BMP (BGP Monitoring Protocol).[24][25]
Un plugin basado en pmacct, pmacct-to-elasticsearch, permite exportar la salida de pmacct a elasticsearch, pero no proporciona ninguna visualización pre-hecha de los datos.[26] Manito Networks Flow Analyzer
Manito Networks Flow Analyzer es un recolector de datos de flujo de red que almacena su salida en Elasticsearch e incluye visualizaciones en Kibana.[27] ElastiFlow
ElastiFlow es un programa muy similar a Manito Networks Flow Analyzer. Hasta inicios de este año, empleaba Logstash para realizar la ingesta de datos, pero ahora ha cambiado a un sistema propio, con el objetivo de mejorar el rendimiento. Este nuevo sistema de ingesta tiene integración nativa con RisqIQ y las bases de datos de geolocalización de IPs de MaxMind para enriquecer la información. Igual que Flow Analyzer, también incluye visualizaciones de kibana prediseñadas.[28][29]
3.3 Elección de software
Una vez examinadas todas las opciones del apartado anterior, se ha elegido el soft- ware a usar. En este apartado se listarán los requisitos que deben cumplir las he- rramientas, y la elección que se realizó.
3.3.1 Software para el tratamiento de logs
Requisitos
A continuación, se indican los requisitos que debe cumplir el software de tratamiento de logs, junto con la justificación detrás de cada uno de ellos:
16 Capítulo 3 Software SIEM en el mercado 1. Compatibilidad nativa con parte del hardware y software del alcance. No se espera compatibilidad nativa con todo el hardware y software del alcance, pero sí se espera, al menos, la compatibilidad nativa con logs de Cisco ASA y Windows, debido a la gran variedad de mensajes que hay en los logs de Cisco ASA[30] , y debido a que los de Windows utilizan un formato de XML binario en vez de uno tradicional (texto plano, un log por línea)[8].
2. Agente para la recogida de logs compatible con Windows y Linux. El SIEM va a tener que recoger logs de máquinas Windows y Linux
3. Fácilmente extensible. En el futuro será necesario añadir logs de software o hardware que no es compatible de forma nativa con el SIEM. El software debe ofrecer opciones para poder añadir de forma sencilla compatibilidad con nuevos tipos de logs o nuevas fuentes de datos
4. Escalable. Inicialmente, no se van a incorporar logs de todas las máquinas de la red empresarial. El SIEM debe poder adaptarse a futuros aumentos en el número de máquinas monitorizadas, con lo cual, la posibilidad de desplegar el SIEM en un clúster es de gran importancia.
Elección
SIEMonster Community Edition queda descartado dado a que, como se menciona en la página del producto[31], está orientado a compañías con menos de 100 endpoints, lo cual podría ser limitante, dado que la red del CTAG tiene alrededor de 1000 equipos, como ya he mencionado en la introducción.
AlienVault OSSIM y MozDef quedan automáticamente descartados debido a que no permiten la creación de clústers. En cuanto a Prelude OSS, los propios desarro- lladores lo recomiendan solamente para pruebas, recomendando la solución de pago Prelude SIEM para despliegues en producción.[15]
Tras descartar estas opciones, tan sólo quedan Elastic Security y Wazuh.
Las principales desventajas de Elastic Security son:
• Proyecto muy reciente. El lanzamiento de este SIEM fue en junio de 2019[32], y algunas partes como el agente Endpoint Security aún tienen muchas carac- terísticas por implementar.[33]
• No está disponible para la versión de código abierto de Elasticsearch.[34] Esto nos obligaría a contratar una suscripción si se quiere añadir al SIEM los módulos de inteligencia artificial y LDAP oficiales de Elastic, en vez depoder
3.3 Elección de software 17 usar los módulos de Open Distro for Elasticsearch1, u optar por substituír Elasticsearch por OpenSearch, que también proporciona estos módulos de forma gratuíta.
• Incerteza en cuanto a licencias. Inicialmente se anunció que no todas las funcionalidades del agente serían gratuítas, pero esa información ha sido eli- minada recientemente[37][38]. Esto no deja claro si en el futuro se podría seguir utilizando Endpoint Security con las versiones gratuítas de Elasticsearch o si habría que pasar a una licencia de pago para poder usar el agente.
Al contrario que Elastic Security, Wazuh sí que es compatible con Open Distro for Elasticsearch.[39] La principal desventaja de Wazuh es la imposibilidad de definir varios masters en un clúster. Es un problema reconocido por los desarrolladores, y que está en proceso de discusión, según el issue de Github abierto para este problema (https://github.com/wazuh/wazuh/issues/811). La consecuencia más importante de esto es que el clúster dejaría de funcionar si en algún momento falla el máster. Esto causaría que cuando se quisiera realizar una actualización, habría que apagar por completo el SIEM.
Otra desventaja de Wazuh es que es compatible de forma nativa con menos hard- ware y software que Security[20][19]. Las principales ausencias en la lista son Cisco Firepower, y una versión actualizada del decodificador para dispositivos Fortiga- te. Para suplir esta falta, habría que crear decodificadores personalizados para los servicios necesarios.
Tras tener todo esto en cuenta, sobre todo la incerteza en cuanto a licencias, se ha optado por seleccionar Wazuh para el análisis de logs.
1Open Distro for Elasticsearch es un proyecto creado por Amazon para añadir a los servicios ges- tionados de Elasticsearch ofrecidos por Amazon Web Services funcionalidades de las versiones de pago del Elastic Stack.[35] Este año, como respuesta a un cambio en la licencia empleada por Elastic, Amazon ha creado un fork de Elasticsearch y Kibana, denominados OpenSearch y OpenSearch Dashboards (aún en beta)[36], con las mismas funcionalidades añadidas que Open Distro for Elasticsearch.
18 Capítulo 3 Software SIEM en el mercado 3.3.2 Software para el tratamiento de datos de flujo de red
Requisitos
En base a la elección de Wazuh como herramienta para el tratamiento de logs, se va a exigir que el software para el tratamiento de datos de flujo use también Elasticsearch como backend. Elección
De entre las opciones consideradas, NFSen y NFSen-NG quedan descartados por no usar Elasticsearch como backend[21][22].
Pmacct es un buen candidato, pero su integración con Elasticsearch, la cual permiti- ría integrar la información de flujo de red con la de los logs, lleva sin actualizaciones desde noviembre de 2019. Esto podría provocar problemas de compatibilidad con las últimas versiones de Elasticsearch[26].
Manito Networks Flowanalyzer es muy buen candidato, dado que usa Elasticsearch como backend e incluye visualizaciones para Kibana, pero lleva bastante tiempo sin actualizaciones (desde 2017), con lo cual queda descartado[27].
ElastiFlow es, entonces, la opción más lógica. Está en soporte activo y está bien integrado con Elasticsearch y Kibana, permitiéndo crear dashboards personalizados, aparte de los creados por el desarrollador[29].
3.3.3 Funcionamiento conjunto del software
Los dos programas elegidos, Wazuh y ElastiFlow se encargan respectivamente de la ingesta de logs y datos de flujo de red, y del envío de estos a un único clúster de Elasticsearch. Los datos son son visualizados en Kibana, el front-end web del stack Elastic. Este permite explorar los datos recogidos y crear visualizaciones en base a ellos. Tanto Wazuh como ElastiFlow programas, además, incluyen visualizaciones predefinidas para Kibana.
Se pueden añadir, además, otros tipos de datos al SIEM haciendo uso de las demás herramientas del Elastic Stack, como por ejemplo Logstash. Esto podría ser útil, por ejemplo, para monitorizar sistemas que no emitan logs tradicionales (como sistemas que deban ser monitorizados a través de una API).
Un diagrama explicativo del flujo de datos se puede ver en la figura 3.1.
3.3 Elección de software 19 Datos de flujo de red
H/W ElastiFlow de red
Otros tipos de datos
Logstash Elasticsearch Kibana
Logs
Agente Wazuh Wazuh
Fig. 3.1.: Esquema del funcionamiento general del software elegido
20 Capítulo 3 Software SIEM en el mercado Recomendaciones oficiales 4 de hardware
El último paso antes de realizar el diseño de la instalación es realizar una estimación del hardware necesario. Antes de realizar un despliegue de prueba, es complicado hacer estimaciones fiables, pero es útil hacer una estimación inicial para tenerun punto de partida. Para poder realizar esta primera estimación, se va a tomar como referencia las recomendaciones oficiales de hardware de los desarrolladores delas distintas herramientas que se van a emplear.
Aparte de las recomendaciones de hardware para Wazuh y ElastiFlow, también se van a tener que revisar las de Elasticsearch, dado que ambos programas necesitan un clúster Elasticsearch como backend. Además, Wazuh necesita un nodo balancea- dor de carga, un proxy, para los despliegues en clúster; se realizará también una estimación del hardware necesario para este nodo.[20]
4.1 Elasticsearch
Los dos recursos de mayor importancia para Elasticsearch son RAM y almacena- miento.[40] La CPU influye también en el rendimiento, pero los principales cuellos de botella, según afirman los desarrolladores, son el rendimiento de lectura yescri- tura del disco duro y la cantidad de RAM (utilizada como caché del disco duro por el sistema operativo, y necesaria para procesar consultas contra grandes conjuntos de datos).
A continuación se muestran las recomendaciones oficiales en cuanto a RAM, alma- cenamiento y CPU RAM
En cuanto a RAM, se recomienda no asignar más de 32GB, debido a un cambio en la forma en la que java expresa los punteros a objetos. Hasta 32 GB, Java utiliza punteros a objetos comprimidos (Compressed OOPs)[41]. Estos punteros ocupan la mitad de espacio que los punteros no comprimidos (32 bits en vez de 64). Como
21 consecuencia de la desactivación de los punteros comprimidos, se utiliza más me- moria para almacenarlos y más ancho de banda de la conexión entre la CPU y la memoria. Hasta los 40-50 GB esta pérdida de memoria no se recupera.[42]
En base a este dato, se recomienda tener entre 32 y 64 GB de RAM en cada máquina, la mitad de este espacio asignado a Elasticsearch, mientras el restante se deja libre para que el sistema operativo lo use como caché del disco duro.[42] Almacenamiento
Para el almacenamiento, Elastic, la empresa desarrolladora de Elasticsearch y el resto del stack Elastic, recomienda encarecidamente el uso de SSDs por su mayor velocidad de lectura y escritura. Sobre todo se recomienda el uso de SSDs para clústers de ingesta de logs, como el que se quiere desplegar[40]. CPU
Según Elastic, Elasticsearch suele ser bastante ligero en cuanto a utilización de CPU. La principal recomendación que proporciona la empresa es la elección de CPUs con mayor número de núcleos. Mencionan que la mayoría de los despliegues de Elasticsearch utilizan máquinas de entre dos y ocho núcleos, aunque este dato pueda no ser correcto, debido a la cantidad de tiempo que ha pasado desde la publicación de la última versión de la guía de hardware.[40]
4.2 Wazuh
Para los nodos Wazuh, a diferencia que para Elasticsearch, sí que hay recomenda- ciones de hardware hh. Estas son 8GB de RAM y 4 núcleos de CPU.[20]
Para crear un clúster, es necesario añadir un proxy balanceador de carga. Para esta función, NGINX sería una buena opción, dado que es un servidor web y proxy muy popular[43], y Wazuh proporciona una guía sobre cómo configurarlo correctamente para uso como balanceador de carga de un clúster Wazuh (https://wazuh.com/ blog/nginx-load-balancer-in-a-wazuh-cluster/).
NGINX tiene una guía de dimensionado de hardware, en la cual se dan estimacio- nes de la cantidad de solicitudes HTTP, conexiones SSL y Gb de información que NGINX puede gestionar por segundo con diferentes configuraciones de hardware. En el caso de Wazuh, como NGINX solamente actúa como un proxy TCP, y no va a tratar con archivos grandes, la métrica que sería más cercana a la realidad del sisitema SIEM sería la de solicitudes HTTP por segundo. Tomando este dato
22 Capítulo 4 Recomendaciones oficiales de hardware como referencia, y multiplicándolo por el tamaño del paquete de respuesta que se indica en la misma página, se pueden obtener los datos de rendimiento en MB/s para solicitudes pequeñas de la tabla 4.2.[44]
Hardware MB/s en solicitudes pequeñas
2 cores, 4GB RAM 87,890625 4 cores, 4GB RAM 170,8984375 8 cores, 4GB RAM 341,796875 16 cores, 4GB RAM 634,765625 32 cores, 8GB RAM 976,5625 44 cores, 16GB RAM 1171,875 Tab. 4.2.: Recomendaciones oficiales de NGINX en base al tráfico en MB/s para solicitudes pequeñas
4.3 ElastiFlow
En cuanto a ElastiFlow, la empresa desarrolladora del software utiliza el dato de 4000 flows/segundo/core (fig. 4.1) para estimar el número de núcleos de CPU nece- sarios para un sistema.
Fig. 4.1.: Estimaciones usadas por los desarrolladores de ElastiFlow - Enlace al mensaje: https://elastiflowcommunity.slack.com/archives/C01EBFTRLK0/p161856 6711245100
4.3 ElastiFlow 23
Estimación del 5 almacenamiento
Para estimar tamaño de almacenamiento necesario para almacenar los logs, se ha realizado un estudio de cuánto espacio de almacenamiento se está utilizando cada día. Los datos se han tomado del servidor que se está utilizando ahora mismo para la recolección de logs.
Se puede observar en la tabla 5.2 que la mayor parte de la carga viene de firewall.log. Este archivo acumula la información proveniente de todos los firewalls de la red. Se guarda casi toda la información sobre conexiones entre la red corporativa e internet, lo cual lleva a una cantidad de datos muy grande.
MB Días MB/Día Archivo MB-Picos Días-Picos MB/Día-Picos Tamaño picos
0 1 0 alternatives.log.1 0,8 1 0,8 200% 0 1 0 aptitude.1 0,6 1 0,6 200% 0,3 3,5 0,0857143 auth.log.1 0,4 6 0,066666667 25% 0 1 0 btmp.1 0,0003 1 0,0003 200% 10 2,5 4 cisco.log.1 135 30 4,5 12% 8 5 1,6 daemon.log.1 11 6 1,833333333 14% 7 5 1,4 debug.1 13 6 2,166666667 43% 0 1 0 dpkg.log.1 0,3 1 0,3 200% 257 0,5 514 firewall.log.1 584 1 584 13%
Tab. 5.2.: Espacio ocupado por los logs en el servidor de recogida
Teniendo en cuenta estos datos, y, tomando los datos de los picos como referencia, se llega a que se van a necesitar por lo menos 600 MB al día. Como se puede ver en la tabla 5.4, esto supondría 213,86 GB de espacio para almacenar un año de logs.
MB/Día GB/Mes GB/Cuadrimestre GB/Año
600,00 17,578125 70,3125 213,867188
Tab. 5.4.: Estimación de uso de espacio
25 Como Elasticsearch comprime los datos, posiblemente se necesite menos, pero el grado en el cual se pueden repetir estos datos depende de la cantidad de información repetida en cada una de las entradas.Al tratarse de logs, posiblemente se repitan ciertas estructuras, y también es de esperar que cada día se repitan logs, como los de inicio de sesión de las VPNs. Aún así, no es posible verificar el tamaño de los logs comprimidos antes de desplegar el SIEM[45], con lo cual, se tomará la cifra de 213,86 GB como referencia a la hora de recomendar un tamaño de almacenamiento para los servidores.
26 Capítulo 5 Estimación del almacenamiento Diseño 6
Una vez escogido el software que se va a emplear, y una vez se han realizado las estimaciones de los requisitos de hardware, se puede realizar un diseño del sistema.
El sistema diseñado es el mínimo que se haría en cuanto a número de máquinas. En caso de que fuese necesario por motivos de rendimiento, se podrían añadir más nodos, pero no se podría reducir su número. El hardware propuesto, sin embargo, podría reducirse o ampliarse para ajustarse a la carga.
6.1 Diseño completo
El diseño completo del SIEM es el mostrado en la la figura 6.1.
Clúster Elasticsearch Red interna exclusiva para el clúster Elasticsearch Intranet
Datos-1 Datos-2
Clúster Wazuh
Ingesta-1 / Ingesta-2 / Agentes Wa-Master Proxy Logstash Logstash Wazuh Máster / Kibana
Hardware de ElastiFlow red
Fig. 6.1.: Diseño del clúster
El clúster Elasticsearch cuenta con una red interna para realizar las comunicaciones entre nodos. Se opta por aislar este tráfico en una red exclusiva por motivos de
27 seguridad y para evitar carga innecesaria en la intranet. Además de a esta red interna, todos los nodos del clúster tienen acceso a la intranet.
El clúster Elasticsearch consiste del número mínimo de nodos para crear un clúster de alta disponibilidad con nodos de datos e ingesta. Según la documentación, se necesitan al menos dos nodos de cada tipo y al menos 3 nodos elegibles como máster. En este caso, consta de:
• 2 nodos de datos (Datos-1 y Datos-2). Se encargan del almacenamiento de datos y del procesamiento de solicitudes sobre esos datos.
• 2 nodos de ingesta (Ingesta-1 e Ingesta-2). Se encargan del pre-procesamiento de los datos. Aparte de Elasticsearch, en estos nodos también se instalará Logstash. Tanto los nodos de ingesta de Elasticsearch como Logstash se en- cargan del pre-procesado de la información antes de su almacenamiento en los nodos de datos. Estos nodos serán además candidatos a máster
• 1 nodo máster. Este nodo será candidato a máster y albergará Kibana, el front- end web de Elasticsearch. Los nodos candidatos a máster pueden convertirse en el máster de la red mediante una serie de mecanismos internos, y, en el caso de que se conviertan en máster, se encargarán de orquestrar la red. Kibana proporcionará visualizaciones sobre los datos y permitirá consultarlos desde una interfaz web.
Crear un clúster de alta disponibilidad permite que, aunque se pierda uno de los no- dos, el SIEM siga funcionando correctamente. Separar los nodos de ingesta permite liberar a los nodos de datos de realizar otros labores que no sean el procesamiento de consultas y la escritura de datos, mejorando así el rendimiento del clúster en conjunto[46].
El clúster Wazuh consta de dos máquinas, el servidor máster de Wazuh y un proxy balanceador de carga. Como Wazuh no puede crear un clúster de alta disponibili- dad, solamente interesaría crear un clúster con varios servidores Wazuh por motivos de rendimiento. Tener un máster y un proxy ya desplegados haría posible añadir al clúster nodos extra solamente creando los servidores Wazuh adicionales y cam- biando la configuración del máster y el proxy. Así, ya no sería necesario cambiarla configuración en los agentes que se desplieguen.[20]
ElastiFlow se despliega en una sola máquina, dado que tampoco permite la crea- ción un clúster de alta disponibilidad. Como se detalla más adelante, no se espera necesitar más de una máquina ElastiFlow para la totalidad de la red, debido a la poca carga que genera ElastiFlow en cuanto a uso de CPU.
28 Capítulo 6 Diseño 6.2 Funcionamiento del SIEM
Antes de continuar, es preciso mostrar el funcionamiento interno del SIEM. En la figura 6.2 se puede ver el camino que siguen los logs y los datos de flujo de red en el sistema, el cual será detallado en los siguientes apartados.
Clúster Elasticsearch Clúster Wazuh
Servidor Agente Datos Ingesta Proxy Wazuh Wazuh Alertas Logs (JSON)
Hardware de ElastiFlow red Datos de flujo de red Datos de flujo de red enriquecidos (JSON) (Protocolo Netflow)
Fig. 6.2.: Flujo de la información en el sistema SIEM
6.2.1 Logs
El procesamiento de los logs en Wazuh sigue el siguiente proceso: Recogida de logs
Los logs son obtenidos por el agente Wazuh, el cual se instala o bien en el ordenador que genera los logs o bien en un servidor que se encargará de recogerlos.
El agente envía estos logs al servidor Wazuh, también llamado manager en la docu- mentación oficial. La comunicación entre el servidor y el agente puede ser através de un proxy, en caso de que el servidor sea uno de los nodos de un clúster. Procesamiento
Los logs son procesados por Wazuh en tres pasos: pre-decodificación, decodificación y comprobación de reglas.
El primer paso consiste en la extracción de datos básicos, como la fecha y hora, el nombre de host de la máquina o el nombre del programa que ha creado el log.
Durante el segundo, se aplican los decodificadores, definidos en archivos XML. Cada decodificador está especializado en un programa o una clase de log. El decodificador se encarga de extraer datos más específicos.
6.2 Funcionamiento del SIEM 29 Una vez finalizado el paso anterior, se comprueban los datos del log con lasreglas existentes, definidas también en archivos XML. Estas reglas definirán si seenvíao no una alerta, y pueden añadir información extra sobre la misma.
Envío a Elasticsearch
Las alertas generadas se escriben a un fichero en formato JSON a medida que se crean. Este fichero es vigilado por Filebeat, el colector de datos de archivos de Elastic. Cada vez que se añade información al archivo de alertas, Filebeat se encarga de transmitirlas a Elasticsearch. Una vez enviadas, son almacenadas en Elasticsearch directamente, donde se pueden consultar usando Kibana.[20]
6.2.2 Datos de flujo de red
Los datos de Flujo de red son enviados directamente por el hardware de red a ElastiFlow. Este programa se encarga de extraer toda información de estos datos y enriquecerla. Después, ElastiFlow envía los datos directamente a Elasticsearch en formato JSON.[28]
6.3 Clúster Elasticsearch
A la hora de diseñar el clúster, se ha intentado añadir la mayor redundancia posible. En Elasticsearch, es posible hacer un cluster que soporte la pérdida de una máquina cualquiera, incluso un máster. Esto requiere la existencia de al menos 3 nodos eligibles a ser másters y 2 nodos de cada uno de los demás tipos que se requieran en la instalación.[46][47]
Este tipo de clúster de alta disponibilidad permite hacer actualizaciones de Elastic- search en todos los nodos del clúster sin perder en ningún momento la disponibili- dad.[46]
En base a las estimaciones realizadas, se ha diseñado un clúster con, como mínimo, las características listadas en la figura 6.3.
30 Capítulo 6 Diseño Datos Software a instalar: Almacenamiento de datos y procesamiento de consultas. Datos 1 Datos 2 Elasticsearch (nodo de tipo data) 8+ cores 32-64GB RAM 1/2 TB SSD
Ingesta Software a instalar:
Pre-procesamiento de datos. Ingesta 1 Ingesta 2 Elasticsearch Candidatos a master en caso Candidato Master Candidato Master (nodo de tipos ingest de que el principal falle. y master) Logstash 4-6 cores 16GB RAM
Master/Kibana Software a instalar: Coordianción del cluster y Elasticsearch dasboard. Master / Kibana (nodo tipo master) 4 cores Kibana 8GB RAM
Fig. 6.3.: Esquema de las máquinas del clúster Elasticsearch
En los nodos de datos, se han recomendado entre 1 y 2 TB de espacio en SSD para contar con amplio espacio para futuros aumentos en la cantidad de información almacenada en el SIEM. Se recomiendan entre 32 y 64GB para poder aprovechar la compresión de punteros de Java mencionada en el apartado 4.1, y se sugiere para estos nodos como mínimo 8 núcleos de CPU. En el apartado 4.1, se menciona que, en el momento en que realizó la última versión de la guía de dimensionado de hardware (2015), los nodos de Elasticsearch desplegados solían ser de entre 4 y 8 núcleos. Se han recomendado como mínimo 8 núcleos, dado que desde que se creó esta guía, se han añadido funcionalidades nuevas a Elasticsearch que podrían aumentar considerablemente el uso de CPU, como la compresión de datos almacenados[45].
Para los nodos de ingesta, se ha recomendado hardware más modesto: 16GB de RAM y entre 4 y 6 núcleos de CPU. Como no tienen que realizar consultas contra grandes sets de datos, puesto que solamente van a realizar el pre-procesado de la información, se espera un menor uso de CPU y RAM.
Los nodos de ingesta también tendrán instalado Logstash, programa que es parte del Elastic Stack y que también hace labores de pre-procesamiento. El programa
6.3 Clúster Elasticsearch 31 se utilizará para añadir información extra al SIEM a lo largo del ciclo de vida del SIEM.
El nodo máster tendrá instalado Kibana, el servidor web encargado de proporcionar las visualizaciones de los datos. Se ha elegido instalar Kibana en este nodo por el hecho de que va a ser el que menos carga tenga, dado que no procesa datos o solicitudes externas, solamente se encarga de orquestar el clúster. Por este motivo, se considera que una máquina con 4 núcleos de CPU y 8GB de RAM es suficiente.
6.4 Clúster Wazuh
Wazuh, al contrario que Elasticsearch no soporta tener más de un máster en ca- da clúster, y los agentes se conectan exclusivamente a un servidor, forzando a la utilización de un proxy para balancear la carga entre los nodos del clúster. Como consecuencia, no es posible crear un clúster wazuh de alta disponibilidad, porque si falla el proxy o el master, caerá el clúster en su totalidad. El único caso en el que sería útil crear un clúser sería para aumentar la capacidad de procesamiento.[20]
Podría optarse a no crear un clúster de Wazuh, y restringirlo únicamente a una máquina, pero esta decisión complicaría la creación en el futuro es de un clúster Wazuh si fuese necesario. Por este motivo, se ha desplegado un clúster consistente de un nodo Wazuh (sería el máster de un futuro clúster) y un proxy, como se indica en la figura 6.4. De este modo, no se tendrá que modificar la configuración de los agentes si fuese necesario desplegar más nodos de Wazuh.[20][44]
En cuanto al hardware recomendado para las máquinas, el proxy NGINX debería contar con al menos 2 núcleos de CPU y 4GB de RAM. En caso de que se sostenga un pico máximo de 87 MB/s (el máximo que podría procesar un servidor de estas características, según los datos mostrados en el apartado de requisitos de Wazuh) durante una hora, se generarían 313.2 GB de información. Esto supondría en una hora más logs que los aproximadamente 213 GB/Año que se generan en la red según los cálculos del apartado de requisitos de Elasticsearch.
Con respecto al nodo Wazuh, se seguirá la recomendación del desarrollador, men- cionada en el apartado de requisitos de Wazuh: esto es, 8GB de RAM y 4 núcleos de CPU.
32 Capítulo 6 Diseño Nodos Wazuh Wa-01 Software a instalar:
Pre-procesamiento de logs Wa-01 provenientes de los agentes Wazuh. Wa-Master Wazuh
4 cores Wa-01 8GB RAM · · ·
Proxy Software a instalar: Balanceador de carga, IP a la que se Proxy conectarán los agentes wazuh. Nginx 2 cores 4GB RAM
Fig. 6.4.: Esquema de las máquinas del clúster Wazuh
6.5 ElastiFlow
Para ElastiFlow, solamente se desplegará una máquina con el software. Para poder calcular el hardware necesario para este servidor, se ha tomado una medida de la cantidad de flows por segundo que recibe el actual servidor de NFSen en las horas de mayor uso. Como se puede observar en la figura 6.5, las horas de mayor uso son entre las 8 y media de la mañana y las 2 de la tarde. Se ha medido una media de 798,9 flows por segundo, con un pico de 1000 paquetes por segundo.
Fig. 6.5.: Flows por segundo, medidos en el servidor NFSen
6.5 ElastiFlow 33 En base a estas medidas y la estimación de 4000 flows/s por cada núcleo de CPU del apartado de requisitos de ElastiFlow, se sugiere usar una máquina con al menos 2 núcleos de CPU y 4 GB de RAM.
6.6 Alcance del SIEM
El SIEM debe recoger los datos que ahora mismo se están centralizando en el servidor mencionado en el apartado 2, exceptuando los switches SAN. Estos switches se habían considerado inicialmente, pero apenas generan logs, y todos los generados son del mismo tipo. Debido a esto, no se podrían crear alertas útiles, dado que no se conocen los logs derivados de anomalías en los switches.
Se instalarán, además, agentes en algunos ordenadores con permisos de acceso eleva- dos. Una vez desplegado el sistema, y con el paso del tiempo se irán añadiendo más servidores, con el objetivo de mantener vigilada la mayor parte de la red posible.
34 Capítulo 6 Diseño Implementación 7
Una vez escogido el software a usar y diseñado el sistema, se pasa a la implemen- tación. Esta implementación se dividirá en dos pasos: el despliegue de un clúster laboratorio y la creación de decoders y reglas personalizadas.
Durante la primera fase, se crearán instrucciones para el despliegue del sistema, así como los archivos de configuración necesarios. Toda esta información se utilizará para realizar el despliegue final.
Una vez creado el clúster laboratorio, se crearán decoders y reglas para los tipos de logs que Wazuh no soporte de forma nativa. En concreto, se crearán decoders y reglas para los firewalls Firepower y Fortigate, y para el servidor Swivel.
7.1 Instalación de un clúster laboratorio
La instalación se realiza con un número de máquinas reducido. El despliegue resul- tante sería el que se puede ver en la figura 7.1.
Clúster Elasticsearch Red interna exclusiva para el clúster Elasticsearch Intranet
Datos
Clúster Wazuh
Agente Máster / Ingesta / Wa-Master Proxy Wazuh de Kibana Logstash prueba
Fig. 7.1.: Esquema del clúster laboratorio
35 En los siguientes apartados, se muestra la configuración de las distintas máquinas.
7.1.1 Clúster Elasticsearch
La instalación de Elasticsearch se va a realizar sobre el sistema operativo Ubuntu Server 20.04.2 LTS. Se ha escogido este sistema operativo por el mayor volumen de instrucciones de instalación oficiales y el largo período de soporte oficial de Canonical (5 años).[48]
La versión elegida de Elasticsearch es la última versión soportada por la versión más actual de Wazuh (a día del 5 de marzo de 2021, es la 4.1.1). Esta restricción también se debe tener en cuenta a la hora de realizar una actualización del sistema. En el apéndice A.4 se detalla el proceso, pero es necesario asegurar la compatibilidad entre las diferentes partes del sistema.
Los nodos se han configurado de la siguiente forma[46]:
1. Nodo de Datos: nodo de tipo data. Es el encargado de almacenar la informa- ción y procesar las consultas de datos.
2. Nodo de Ingesta: nodo de tipos master e ingest. Es candidato a nodo mas- ter en caso de que el máster principal falle y es el encargado de realizar el preprocesado de la información.
3. Nodo Máster: nodo de tipo master. Se trata de otro candidato a máster. Idealmente este será el designado como máster, pero no hay forma de forzar su elección.
Tener un número par de candidatos a máster no es ideal, y Elasticsearch desaconseja esta configuración. Se ha realizado así en el despliegue de pruebas para que sealo más similar posible al despliegue de producción. En este último, al haber dos nodos de ingesta, el número total de nodos candidatos a máster queda en 3.
Los pasos seguidos para el despliegue se detallan en el apéndice A.1.
7.1.2 Clúster Wazuh
El clúster Wazuh (consistente también de máquinas Ubuntu 20.04.2 LTS) está formado por el máster Wazuh y un proxy balanceador de carga, igual que en el despliegue de producción.
36 Capítulo 7 Implementación Los pasos seguidos para el despliegue se detallan en el apéndice A.2.
7.1.3 ElastiFlow
ElastiFlow se ha desplegado usando la imagen oficial de Docker. Se ha añadido además la base de datos de geolocalización MaxMind GeoLite2 para enriquecer los datos.
ElastiFlow procesa los datos de flujo de red y, tras procesarlos, los envía directa- mente a los nodos de ingesta de Elasticsearch. Debido al hecho de que no almacena datos localmente, ElastiFlow es especialmente adecuado para desplegar en Docker, ya que no necesitar persistencia. El despliegue en Docker, además, facilita el proceso de actualización, dado que basta con eliminar el contenedor y la imagen actuales y descargando una nueva, como se indica en el apéndice A.4.
Los pasos seguidos para el despliegue se detallan en el apéndice A.3.
7.1.4 Agente Wazuh de prueba
Se trata de una máquina Ubuntu 20.04.2 LTS, en la cual se ha instalado el agente de Wazuh, siguiendo las instrucciones dadas por la propia aplicación de Wazuh.
La instalación del agente se puede realizar con un sólo comando:
curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.1.1-1_amd64.deb && sudo WAZUH_MANAGER='--IP-PROXY--' WAZUH_AGENT_GROUP='default' dpkg -i ./wazuh-agent.deb
Después de realizar la instalación, solamente falta activar el agente ejecutando
sudo systemctl daemon-reload sudo systemctl enable wazuh-agent sudo systemctl start wazuh-agent
7.2 Creación de decoders y reglas personalizadas
Una vez realizado el despliegue de pruebas, se ha pasado a crear los decoders y las reglas necesarias para que Wazuh pueda procesar logs de todo el hardware que
7.2 Creación de decoders y reglas personalizadas 37 forma parte del alcance. En concreto, era necesario crear reglas y decoders para Cisco Firepower Threat Defense (Cisco FTD) y para firewalls Fortigate. Firepower
Para los logs de Cisco Firepower, se ha partido de los decoders creados por el usuario 15U12U en GitHub (https://github.com/wazuh/wazuh-ruleset/pull/727). Se ha actualizado para hacerlo coincidir con la documentación de logging de la última versión de Cisco Firepower.
Para poder generar avisos en base a distintas categorías de URLs, se han creado las reglas de bloqueo mostradas en la tabla 7.1 en el firewall.
Nombre de la regla Block-URLs-MAL Block-URLs-TUN Block-URLs-DWN Block-URLs-IOC Malicious Sites Malware Sites Cryptojacking Illegal Downloads Personal VPN Ebanking Fraud Linkshare Categorías de Open HTTP Proxy Filter Avoidance Peer File Transfer Indicators of Compromise URLs bloqueadas DNS-Tunneling Phishing File Transfer Services TOR exit Nodes Spyware and Adware Online Storage and Backup Botnets Hacking Tab. 7.1.: Reglas de bloqueo creadas en cisco Firepower
Las reglas creadas en Wazuh en base a las reglas creadas en el firewall son las siguientes:
38 Capítulo 7 Implementación
Fortigate
Para poder monitorizar Fortigate, se creó un decoder nuevo para la última versión del firmware. Para realizarlo, se emplearon los logs de ejemplo de la documentación de Fortinet (https://docs.fortinet.com/document/fortigate/6.4.4/admin istration-guide/954635/getting-started). Una vez creados los decoders, se crearon reglas basadas en las reglas oficiales de Fortigate.
Se intentó inicialmente añadir una regla fortigate-firewall-v6, y luego añadirla a la regla Fortigate messages grouped, tal y como está implementado en las reglas existentes de Fortigate:
Esto aplicaría a los logs de la nueva versión de Fortigate las reglas que se aplican a las versiones antertiore, pero las reglas son incompatibles con el nuevo formato de los logs. Campos como type=traffic y action=blocked han cambiado de for- mato a type="traffic" y action="blocked". Como consecuencia de esto, se han reimplementado las reglas.
Cabe destacar que algunos de los logs de ejemplo en la documentación muestran diferencias de formato con respecto a los logs que envían los dispositivos Fortigate
7.2 Creación de decoders y reglas personalizadas 39 de la red del CTAG. En los casos en los que había diferencias, se ha optado por con- servar la compatibilidad con los logs que envían los dispositivos Fortigate instalados en la red del CTAG. Swivel
En el caso de Swivel, se detectó un problema mientras se intentaban crear los decoders: en los logs se incluye el símbolo UTF-8 U+00A0 (No-Break Space - NBSP). Es similar al espacio, pero que impide que se corte la línea en ese símbolo. El NBSP se encuentra en dos ubicaciones dentro de una línea de log:
(...) WARN From the IP Address[NBSP]10.xx.xx.xx Agent Name[NBSP]AGENT01 - Login failed (...)
Wazuh no es capaz de decodificarlo correctamente, y falla el procesamiento dela entrada de log completa. Para solventar el problema, se ha creado un ejecutable externo, programado en C. Este programa se encarga de substituír los dos bytes que ocupa el carácter NBSP por dos espacios, y es llamado por el módulo mmex- ternal de rsyslog para procesar los logs provenientes del servidor Swivel. Esto se ha configurado en las siguientes líneas de configuración de rsyslog:
module(load="mmexternal")
if $fromhost-ip == 'SWIVEL-IP' then { action(type="mmexternal" binary="/root/AUXFiles-serfar/filterNBSP.out" interface.input="msg") }
Tras esto, Wazuh recibe dos espacios en vez del NBSP, evitando así el problema.
El código del binario, los decoders y las reglas creadas se pueden ver al completo en el apéndice A.5.
40 Capítulo 7 Implementación Despliegue en producción y 8 realización pruebas
Una vez finalizado todo el proceso de implementación, se ha realizado un desplie- gue completo en la red de producción. El despliegue se ha realizado en máquinas virtuales por dos motivos:
1. Aún no se dispone del hardware final para realizar el despliegue, con lo cual es necesario desplegarlo en uno de los servidores de virtualización disponibles.
2. Desplegarlo en una máquina virtual permite, tanto ahora como en el futuro, expandir su capacidad de RAM y el número de núcleos de CPU de forma fácil si fuera necesario.
La topología del despliegue es la especificada en el apartado de diseño (figura 6.1.
Se han seguido las instrucciones de despliegue detalladas en los apéndices A.1, A.2 y A.3, y se han copiado las reglas y decoders de Cisco FTD y Fortigate del nodo de Wazuh pruebas al nodo de producción.
8.1 Prueba de carga
Como el hardware del que se dispone para realizar este primer despliegue en produc- ción es mucho menor que el proyectado, se decidió ir añadiendo los logs y los datos de flujo de red de forma progresiva, para así comprobar el nivel de cargaquees capaz de soportar. Se inició el despliegue añadiendo los logs de uno de los firewalls, el FW1. Este es con gran diferencia el que envía más logs a la máquina de recogida de logs que ya estaba desplegada. Tras eso, se han desplegado agentes Wazuh en los ordenadores que forman parte del alcance. Después, se han añadido el resto de logs del servidor de recogida.
Una vez añadidos los datos de logs, se ha procedido a añadir los datos de flujo de red de forma progresiva. Para evitar interrumpir la recolección que ya se estaba reali- zando de estos datos, se ha utilizado UDP Samplicator para enviar los datos tanto a ElastiFlow como a la instancia de NfSen que se estaba utilizando. En concreto, se ha
41 utilizado el docker de esta herramienta publicado en Docker Hub por Rob Cowart, creador de ElastiFlow (https://hub.docker.com/r/robcowart/samplicator).
8.1.1 Resultados
En ningún momento de la prueba de carga han fallado los servidores, pero es nece- sario tomar medidas del uso de CPU y RAM de cada equipo para comprobar que el SIEM es estable.
Las mediciones se tomaron a las 11:50 el día 24 de Junio de 2021, a pesar de los valores mostrados en el eje horizontal de las gráficas. Las medidas se tomaron con el software sar, una utilidad que forma parte del paquete sysstat. Las gráficas se han generado usando la web SARchart.
Uso de recursos en nodos de datos
El rendimiento de Elasticsearch es aceptable por lo general, pero las visualizaciones suelen tardar en cargar. Se espera que estos problemas de rendimiento sean solven- tados en cuanto se adquiera un servidor propio para el SIEM, el cual tendrá discos duros más rápidos, así como más recursos en general.
Como consecuencia de esto, se evaluará el uso de recursos en los nodos de datos sin ninguna visualización abierta y sin hacer peticiones sobre los datos almacenados.
Almacenamiento
Logs
Los logs están ocupando, como se puede observar en la figura 8.1, entre 5 y 13 GB diarios. El rango es bastante amplio, pero los datos son mucho mayores de lo que se esperaba inicialmente, 600 MB diarios según las estimaciones realizadas en el apartado de análisis.
Se ha verificado que desde el momento en que se realizaron las medidas sehan habilitado logs para más servidores y hardware de red. Se tomará este gran aumento en el número de logs almacenados en cuenta a la hora de adquirir los servidores dedicados para la instalación del SIEM.
42 Capítulo 8 Despliegue en producción y realización pruebas Fig. 8.1.: Almacenamiento ocupado por los logs en el clúster Elasticsearch, por días
Datos de flujo de red
Los datos de flujo de red ocupan alrededor de 6 GB diarios para el switch principal, como se puede ver en la figura 8.2.
En base a los datos que se están recogiendo de la totalidad de la red en el servidor NFSen, se espera que el consumo de almacenamiento de la totalidad de la red sea entre el doble y 5 veces más. Esta estimación se basa en que el switch añadido representa menos de la mitad de los datos de flujo de red por segundo emitidos de media a lo largo de un día, y aproximadamente una quinta parte de los paquetes que procesa la red.
Fig. 8.2.: Almacenamiento ocupado por los datos de flujo de red en el clúster Elasticsearch, por días
8.1 Prueba de carga 43 Flows/s Paquetes/s . . . RACK29SW1 3.2 /s 3.7 k/s . . . RACK8SW1 5.3 /s 6.2 k/s RACK28SW1 1.3 /s 6.1 k/s RACK4SW1 4.6 /s 7.0 k/s RACK27SW1 1.2 /s 1.0 k/s RACK2SW1 7.6 /s 15.0 k/s RACK26SW1 1.3 /s 100.1 /s RACK25SW1 1.6 /s 2.5 k/s RACK15SW1 2.1 /s 7.0 k/s RACK24SW1 1.0 /s 715.5 /s FW2 18.5 /s 133.0 k/s RACK14SW1 36.1 /s 51.3 k/s RACK1SW3 192.9 /s 95.9 k/s RACK1SW1 12.6 /s 10.4 k/s FW-AT 0.6 /s 283.3 /s RACK21SAN1 2.6 /s 132.9 k/s RACK3SW3 16.8 /s 17.2 k/s FW1 197.6 /s 0 /s . . . TOTAL 507.1 /s 490.3 k/s . . .
CPU
El uso de CPU es bastante bajo excepto en picos de entre 25% y 50% de uso de CPU en los nodos de datos de Elasticsearch(figs. 8.3 y 8.4). Es importante mencionar que en los picos más altos se han detectado cargas de alrededor del 100% en una de las 4 CPUs asignadas a cada una de las máquinas virtuales(fig. 8.5).
Esta elevada carga es esperada, dado que las máquinas virtuales tienen caracterís- ticas muy inferiores a las sugeridas en el diseño.
Percentage of CPU-all utilization at the user level [application]
ES-dat1 40 l e v e l
r e s u 30 e h t
t ) a r s n u o i % t (
a ] z i n l i o t i 20 t u
l a l c a i l - p U p P a [ C
f o
e
g 10 a t n e c r e P
0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:50 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am
Fig. 8.3.: Porcentaje de uso de CPU - Nodo 1 de datos
Percentage of CPU-all utilization at the user level [application]
ES-dat2
l 60 e v e l
r e
s 50 u
e h t
t ) a
r 40 s n u o i % t (
a ] z i n l i o t i 30 t u
l a l c a i l - p U p P a
[ 20 C
f o
e g a
t 10 n e c r e P 0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:52 am
Fig. 8.4.: Porcentaje de uso de CPU - Nodo 2 de datos
44 Capítulo 8 Despliegue en producción y realización pruebas Percentage of CPU-2 utilization at the user level [application]
ES-dat2 ]
n 110 o i t a c i
l 100 p p a [
90 l e v e l
80 r e s u 70 e h t
t ) r
a 60
s n u o % i ( t 50 a z i l i t
u 40
2 - U
P 30 C
f o 20 e g a t
n 10 e c r
e 0 P 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:52 am
Fig. 8.5.: Porcentaje de uso del núcleo 2 de CPU - Nodo 2 de datos
RAM
El uso de RAM es muy reducido. Dicho esto, la configuración del uso de RAM por defecto de Elasticsearch limita el uso automáticamente en base a la RAM de la que dispone el sistema[46].
Percentage of used memory
ES-dat1 100 ) d e s u m e m % (
y r o m e m
d e s u
f o
e g a t n e c r e P
0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:50 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am
Fig. 8.6.: Porcentaje de uso de RAM - Nodo 1 de datos
Percentage of used memory
ES-dat2 100 ) d e s u m e m % (
y r o m e m
d e s u
f o
e g a t n e c r e P
0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:52 am
Fig. 8.7.: Porcentaje de uso de RAM - Nodo 2 de datos
Uso de recursos en el servidor Wazuh
CPU
8.1 Prueba de carga 45 El uso de CPU y RAM es muy reducido en el servidor Wazuh. El uso de CPUo sube en ningún momento por encima del 10%.
Percentage of CPU-all utilization at the user level [application]
Wa-master
l 10 e v e l
r e s u
e h t
t ) a r s n u o i % t (
a ] z i n l i o t i t u
a l l c i a l - p U p P a [ C
f o
e g a t n e c r e P 0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:52 am 9:52 am
Fig. 8.8.: Porcentaje de uso de CPU - Servidor Wazuh
RAM
El uso de RAM es mínimo, alrededor de un 6,5% en todo momento. La máquina virtual tiene 6GB de RAM, muy cerca de los 8GB que se sugieren en el diseño. Con este bajo nivel de uso de la CPU, no parece necesario tener que desplegar más servidores wazuh para distribuír la carga.
Percentage of used memory
Wa-master 100 ) d e s u m e m % (
y r o m e m
d e s u
f o
e g a t n e c r e P
0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:52 am 9:52 am
Fig. 8.9.: Porcentaje de uso de RAM - Servidor Wazuh
Uso de recursos en el servidor ElastiFlow
En este caso, se está midiendo el uso completo de la máquina que aloja, en conte- nedores Docker, ElastiFlow y Samplicator. El uso de CPU y RAM fue reducido, a pesar de albergar la máquina ambas herramientas.
CPU
El uso de CPU se sitúa siempre por debajo del 10%
46 Capítulo 8 Despliegue en producción y realización pruebas Percentage of CPU-all utilization at the user level [application]
SIEM-Docker
l 10 e v e l
r e s u
e h t
t ) a r s n u o i % t (
a ] z i n l i o t i t u
a l l c i a l - p U p P a [ C
f o
e g a t n e c r e P 0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:50 am 9:50 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am
Fig. 8.10.: Porcentaje de uso de CPU - Servidor ElastiFlow
RAM
El uso de RAM siempre está alrededor del 6%.
Percentage of used memory
SIEM-Docker 100 ) d e s u m e m % (
y r o m e m
d e s u
f o
e g a t n e c r e P
0 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 20210624 9:50 am 9:50 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am 9:51 am
Fig. 8.11.: Porcentaje de uso de RAM - Servidor ElastiFlow
8.2 Pruebas del agente Wazuh
El agente de Wazuh no solamente ofrece la recogida de logs, sino que además incluye otras funciones para vigilar la seguridad del sistema en el que está instalado. Se ha comprobado el correcto funcionamiento de cada una de de estas características.
Inventario del equipo
Wazuh recoge datos del hardware y software presente en el equipo. Esto se realiza mediante escaneos cada cierto tiempo. En estos escaneos se registran los programas instalados, los procesos en ejecución, el hardware presente en el pc y la configuración de red. Esta información se puede ver en las visualizaciones de la figura 8.12.
8.2 Pruebas del agente Wazuh 47 Fig. 8.12.: Visualización de inventario de Wazuh
48 Capítulo 8 Despliegue en producción y realización pruebas Para comprobar que los datos se actualizan correctamente cuando se producen cam- bios, se ha realizado actualizado uno de los programas instalados en el ordenador, Docker, de la versión 3.3.3 a la 3.4.0. Como se puede ver en la figura 8.13, se ha actualizado correctamente en la tabla.
Fig. 8.13.: Visualización de inventario de Wazuh - Después de la actualización
Control de integridad de archivos
Otra de las opciones que permite el agente de Wazuh es controlar la creación mo- dificación y eliminación de archivos en una carpeta. Por defecto, algunas delas carpetas que almacenan partes importantes del sistema operativo, como los drivers, son vigiladas por el agente de Wazuh. Para poder realizar las pruebas sin riesgo de causar problemas, se ha configurado el control de integridad en una carpeta nueva.
A continuación se puede ver un fragmento de la configuración del control de inte- gridad de archivos. Como se puede ver, se están vigilando algunas carpetas dentro de C:\Windows y algunas entradas en el registro. Al final del extracto del archivo de configuración, se puede ver la configuración añadida para realizar la prueba.
8.2 Pruebas del agente Wazuh 49
Con la opción check_all se especifica que se quieren vigilar tanto creaciones de archivos dentro de la carpeta como eliminaciones y modificaciones, y la opción whodata añade a los datos recogidos el usuario que ha realizado el cambio.
Como se puede ver en la figura 8.14, se ha registrado la creación, modificación y eliminación de un archivo correctamente.
Fig. 8.14.: Eventos generados por el módulo de control de integridad de archivos
50 Capítulo 8 Despliegue en producción y realización pruebas Detección de vulnerabilidades
En base al inventario del equipo, Wazuh avisa de las vulnerabilidades presentes en el software instalado. Esta funcionalidad no está activada por defecto, con lo cual es necesario activarla en la configuración del servidor Wazuh, cambiando la variable
Una vez activada la detección de vulnerabilidades, se pueden ver estas en el dash- board de la figura 8.15.
8.2 Pruebas del agente Wazuh 51 Fig. 8.15.: Dashboard de detección de vulnerabilidades de Wazuh
A modo de prueba, se han instalado Apache Tomcat 8.5.11 y Apache HTTPD 2.2.8, dos versiones antiguas de estos dos programas con bastantes vulnerabilidades[49][50]. Como se puede ver en la figura 8.16, estos dos programas son detectados correcta- mente por Wazuh y añadidos al inventario
Fig. 8.16.: Programas de apache, listados en el inventario del equipo
Aún así, Wazuh no ha detectado ninguno de estos dos programas como vulnerables. Tan sólo ha reconocido como vulnerables los siguientes:
• Wireshark 2.6.3 64-bit
• Oracle VM VirtualBox 6.1.18
52 Capítulo 8 Despliegue en producción y realización pruebas • Microsoft Office Proofing Tools 2016
• Adobe Reader XI (11.0.10) - Español
• VMware Player
Como consecuencia de la poca fiabilidad de la detección de vulnerabilidades de Wazuh, se ha optado por desactivarla de nuevo. Evaluación de la configuración de seguridad (SCA)
Esta función realiza una serie de comprobaciones sobre la configuración del equipo, cuyo objetivo es detectar configuraciones potencialmente inseguras. Como se puede ver en la figura 8.17, se asigna al equipo una puntuación porcentual en base al número de comprobaciones exitosas, y se proporcionan para cada comprobación fallida las posibles consecuencias en cuanto a ciberseguridad y los pasos a seguir para corregir el posible defecto, visibles en la figura 8.18. A modo de prueba, se han seguido los pasos descritos en la figura 8.18.
Fig. 8.17.: Panel de visualización de SCA
Fig. 8.18.: Detalle de la salida de una comprobación SCA
8.2 Pruebas del agente Wazuh 53 Fig. 8.19.: Panel de visualización de SCA tras remediar un problema detectado
Una vez aplicados los cambios indicados al registro, y tras la siguiente evaluación de la configuración realizada por Wazuh, se puede comprobar en lafigura 8.19 como aumenta la puntuación y se puede ver que el resultado de ese test aparece como exitoso.
8.3 Prueba de ElastiFlow
Con las visualizaciones de ElastiFlow se puede detectar un ataque que cree una gran cantidad de tráfico. Cualquier pico de tráfico es fácil de ver, y puede ser investigado en las distintas visualizaciones de ElastiFlow. Lo que sí resultaría más complicado en un principio sería detectar algo como un barrido de pings en una red.
Para esta prueba, se ha realizado un barrido de pings contra una 255 IPs (10.57.1.1- 255) desde la máquina con IP 10.1.100.21. En un momento con poca carga en la red, y filtrando exclusivamente paquetes ICMP, se puede observar el momento en el que se realizó el barrido en el histograma de carga (figura 8.20).
Es necesario aplicar el filtro de paquetes ICMP, dado que sin eso, es imposible detectar nada, dado que el pico es de tan sólo 50 kbits/s, lo cual realmente hace imposible su detección sin el filtro.
54 Capítulo 8 Despliegue en producción y realización pruebas Fig. 8.20.: Histograma de tráfico, filtrando únicamente paquetes ICMP
En la visualización de orígenes y destinos de paquetes, capturada en la figura 8.21 tampoco es visible a primera vista el barrido de pings.
Fig. 8.21.: Visualización del flujo de red en ElastiFlow
Al filtrar por la IP desde la que se realizó el barrido, se puede ver en la parte inferior y superior un gran número de conexiones pequeñas (figura 8.22).
8.3 Prueba de ElastiFlow 55 Fig. 8.22.: Visualización del flujo de red en ElastiFlow, filtrado por la IP que realizó el barri- do
Si se excluyen las conexiones con mayor número de datos, se puede ver en la figura 8.23 que ha accedido a una gran variedad de IPs locales, lo cual sugiere que ha realizado un barrido de algún tipo sobre una gran cantidad de IPs de la red.
Fig. 8.23.: Visualización del flujo de red en ElastiFlow, filtrado por la IP que realizó el barri- do, eliminando la conexión más grande
56 Capítulo 8 Despliegue en producción y realización pruebas Estas visualizaciones de ElastiFlow permiten un análisis a posteriori de las comu- nicaciones de un equipo, y detectar grandes cantidades de datos, pero no facilitan la detección ataques más sigilosos. Para detectar algunos de estos tipos de ataque, los creadores de ElastiFlow han creado una serie de configuraciones para el módu- lo de machine learning de Elasticsearch, al cual no se tiene acceso con la licencia gratuita[51].
8.3 Prueba de ElastiFlow 57
Cambios adicionales 9 realizados
En base a la experiencia del despliegue en producción, se han realizado una serie de adiciones para mejorar el sistema, las cuales no formaban parte del alcance inicial:
9.1 Dashboard resumen
Este dashboard es la página principal del SIEM. Contiene enlaces rápidos a los demás dashboards, un histograma del número de usuarios conectados a la VPN, un mapa con la geolocalización de los que están conectados en ese momento y una gráfica de uso de red.
Este dashboard se ha creado a modo de resumen de la información que se espera sea más útil, y se puede ver en la figura 9.1
Fig. 9.1.: Dashboard resumen creado
9.2 Dashboard de inicios de sesión de VPN
Los datos de inicio de sesión son de gran importancia a la hora de llevar a cabo labores de mantenimiento de las máquinas de la red y para detectar actividades
59 anómalas. Este tipo de información ahora mismo no está centralizada de ningún modo, pero una vez desplegado el SIEM, resulta posible crear una única página donde visualizar esta información.
El dashboard, que se muestra en la figura 9.2, consta de cinco visualizaciones:
1. Dos mapas con la geolocalización de los clientes conectados actualmente a la VPN y los que se han conectado en los últimos 8 días.
2. Dos histogramas en distintas escalas temporales que muestran la cantidad de usuarios que están conectados a la VPN en todo momento. Podrían ayudar a detectar problemas en el VPN, o conexiones extrañas (en días festivos o a deshora).
3. Una lista con los últimos inicios de sesión realizados
Fig. 9.2.: Dashboard de inicios de sesión de VPN
Los datos de cuantos usuarios hay conectados no se derivan de los logs recogidos por Wazuh, dado que eso sería demasiado costoso computacionalmente. Se ha optado por ejecutar un script Python para solicitar una lista de los usuarios conectados cada diez minutos:
#!/usr/bin/env python3 import re, os from netmiko import ConnectHandler from datetime import datetime from time import sleep
# [ ... ]
cisco1 = { # Configuración de la conexión
60 Capítulo 9 Cambios adicionales realizados "device_type": "cisco_asa", # [ ... ] }
# Definición y ejecución del comando command = "show vpn-sessiondb anyconnect" output = "" with ConnectHandler(**cisco1) as net_connect: output = net_connect.send_command(command)
# Regex de la información que quiero sacar en cada línea userline = re.compile("Username[\s]*: ([\S]*).*") ipline = re.compile("Assigned IP[\s]*: ([\S]*)[\s]*Public IP[\s]*: ([\S]*)") groupline = re.compile("Group Policy[\s]*: ([\S]*).*") timeline = re.compile("Login Time[\s]*: (.*)")
# Parto la salida en líneas y preparo un string con lo que se va a escribir en el ,→ archivo de salida outlines = output.splitlines() finalstr = "" usr="" IPad0="" IPad1="" GrouP=""
# Bucle para crear el CSV for line in outlines: if line.startswith("Username"): matches = userline.findall(line) for m in matches: usr=m elif line.startswith("Assigned IP"): matches = ipline.findall(line) IPad0 = matches[0][0] IPad1 = matches[0][1] elif line.startswith("Group Policy"): matches = groupline.findall(line) for m in matches: GrouP = m elif line.startswith("Login Time"): matches = timeline.findall(line) for m in matches: # UTC -> hora local finalstr += dateTime + "," + usr + "," + IPad0 + "," + IPad1 + "," + ,→ GrouP + "," + datetime.strptime(m, "%H:%M:%S %Z %a %b %d ,→ %Y").astimezone().isoformat() + "\n" usr="" IPad0="" IPad1="" GrouP=""
# Escribo la información en el archivo with open(outfilename,"w") as outfile: outfile.write(finalstr)
9.2 Dashboard de inicios de sesión de VPN 61 La salida de este script se recoge con Filebeat, y se envía a Logstash, donde se hace el pre-procesamiento. Cabe destacar que en este paso se añaden los datos de geolocalización. A continuación se muestra la configuración de logstash empleada:
input { # Entrada de filebeat beats { port => 5044 codec => csv { columns => ['time','user','localip','publicip','policy','logon'] } } } filter { date { # Selección del campo de fecha y hora del evento match => ["time", "ISO8601"] } date { # Convertir la fecha y hora de inicio de sesión de String a Date match => ["logon","ISO8601"] target => "logon" remove_field => ["time","host"] } geoip { # Geolocalización source => "publicip" database => "/usr/share/GeoIP/GeoLite2-City.mmdb" } } output{ elasticsearch { # Salida a elasticsearch (algunos datos han sido eliminados por ,→ seguridad) hosts => ["https://[IP nodo ingesta 1]:9200","https://[IP nodo ingesta ,→ 2]:9200"] user => 'logstash_writer' password => [Contraseña] cacert => '/home/user/elasticsearch-ca.pem' index => "logstash-anyconnect-users-%{+YYYY.MM.dd}" } }
9.3 Integración con DHCP
Los datos de las asihgnaciones DHCP se reciben en uno de los nodos de ingesta mediante SFTP de forma periódica. Desde ahí, se realiza la ingesta con logstash, con la siguiente configuración:
input { file { path => ["/home/transfer/*.txt"] mode => "read" codec => csv { columns => ['HostName','IPAddress','AddressState','ClientId'] charset => "UTF-16BE"
62 Capítulo 9 Cambios adicionales realizados } } } # Filtro para eliminar la línea de título filter{ if ![IPAddress]{ drop {} } } output{ elasticsearch { hosts => ["https://IP-ING1:9200","https://IP-ING2:9200"] user => 'logstash_writer' password => '--CONTRASEÑA--' cacert => '/home/user/elasticsearch-ca.pem' index => "logstash-dhcp-%{+YYYY.MM.dd}" } }
Esta información se hace accesible luego a través de un dashboard, visible en la figura 9.3. Este permite filtrar por IP, Hostname, estado de la asignación deIPy fecha y hora.
Fig. 9.3.: Dashboard de consulta DHCP
9.3 Integración con DHCP 63
Conclusión 10
El despliegue del SIEM es un gran paso a la hora de mejorar la seguridad de la red interna del CTAG. Por lo de ahora está limitado en cuanto a alcance, debido a las limitaciones del hardware sobre el que está desplegado. Las máquinas que están siendo monitorizadas permiten mantener un grado de control sobre la red. Faltan servidores importantes por añadir, como el de directorio activo o los de almacenamiento compartido. Con el tiempo se irán añadiendo al SIEM, y el alcance del sistema incluirá cada vez más secciones de la red.
Los objetivos propuestos se han cumplido: gracias al uso de dos programas que usan Elasticsearch como backend (Wazuh y ElastiFlow), todos los datos están almacena- dos en el mismo sistema, y ambos son accesibles desde Kibana para su consulta y para la creación de visualizaciones. Como se puede ver en el apartado de cambios adicionales, es posible crear visualizaciones nuevas en base a los datos existentes, y también añadir nuevos tipos de datos. El filtrado y la búsqueda de estos datos se hace sencillo con las herramientas de Kibana, y se han usado en el apartado de prue- bas del agente de Wazuh para verificar si funcionaba correctamente (en concreto, en la sección de pruebas sobre el Control de integridad en archivos).
En base a las pruebas de carga realizadas, las estimaciones de hardware por lo general parecen acertadas. La única excepción a esto es la estimación de almace- namiento. Desde que se tomaron las medidas ha aumentado significativamente la cantidad de logs recibidos, y se espera que con el tiempo, aumente aún más la canti- dad de espacio necesaria para el SIEM. En vista de esto, se empleará, en vez de un almacenamiento basado exclusivamente en SSDs, un almacenamiento híbrido: SSDs para los datos más recientes y discos duros convencionales para almacenamiento a más largo plazo.
El SIEM no va a permitir la detección todo tipo de ataques, como queda patente tras las pruebas realizadas con ElastiFlow. Como ya he mencionado, el SIEM es un gran paso, y para poder mejorar aún más la seguridad de la empresa, va a ser necesario añadir otras herramientas, como un EDR para proteger y monitorizar todos los ordenadores personales, servidores señuelo (honeypots) para facilitar la detección de escaneos de red, y sistemas de búsqueda y gestión de vulnerabilidades para poder encontrar puntos débiles en la red.
65 10.1 Trabajo futuro
El SIEM es una herramienta que evolucionará y crecerá constantemente. A medi- da que se vayan añadiendo dispositivos a la red, habrá que aumentar el alcance del SIEM para mantener la seguridad de la red bajo control. La construcción de dashboards nuevos, la creación de nuevas integraciones y el despliegue de agentes nuevos van a ser tareas que se repetirán durante la vida del SIEM.
Uno de los mayores factores limitantes ahora mismo es la falta del hardware final. Por lo de ahora, el hardware asignado al SIEM es suficiente, a pesar de que las consultas y visualizaciones tardan unos segundos en cargar. Se espera que en cuanto se mueva la instalación al hardware definitivo, este problema de rendimiento se solucionará y se podrá considerar desplegar agentes en más máquinas.
El SIEM no debe ser la única herramienta a disposición del equipo de ciberseguridad. A esta herramienta se le deben añadir otras, como puede ser un EDR, herramientas de análisis de malware y sistemas de detección y gestión de vulnerabilidades para facilitar el trabajo diario del equipo de ciberseguridad.
66 Capítulo 10 Conclusión Bibliografía
[1]K. M. Kavanagh, O. Rochford y T. Bussa, “Magic quadrant for security information and event management”, Gartner Group Research Note, 2020.
[2]INTERPOL. (2020). “INTERPOL report shows alarming rate of cyberattacks during COVID-19”, dirección: https://www.interpol.int/News-and-Events/News/2020 /INTERPOL-report-shows-alarming-rate-of-cyberattacks-during-COVID-19 (visitado 5 de feb. de 2021).
[3]C. Nabe. “Deloitte Impact of COVID-19 on Cybersecurity”, dirección: https://www2.d eloitte.com/ch/en/pages/risk/articles/impact-covid-cybersecurity.html (visitado 5 de feb. de 2021).
[4]L. D. de Aguilar. (26 de nov. de 2020). “El Gobierno de Argentina y el CTAG de Galicia víctimas de REvil Ransomware”, dirección: https://derechodelared.com/gobierno -de-argentina-ctag-galicia-victimas-de-revil/ (visitado 5 de feb. de 2021).
[5]Oracle. “?Qué es un SOC?”, dirección: https://www.oracle.com/es/database/secu rity/que-es-un-soc.html (visitado 5 de feb. de 2021).
[6]Cybersecurity and Infrastructure Security Agency (CISA), Dept. of Homeland Security (EE.UU.) “Control System Security DMZ”, dirección: https://us-cert.cisa.gov/ic s/Control_System_Security_DMZ-Definition.html (visitado 7 de jun. de 2021).
[7]R. G. Adiscon GmbH. (2009). “RFC5424: The Syslog Protocol”, dirección: https://d atatracker.ietf.org/doc/html/rfc5424 (visitado 10 de feb. de 2021).
[8]NXLog. “About Windows Event Log”, dirección: https://nxlog.co/documentation /nxlog-user-guide/eventlog-about.html (visitado 10 de feb. de 2021).
[9]D. B. M. J. M. S. S. Microsoft Steven White David Coulter. (2018). “Windows Remote Management”, dirección: https://docs.microsoft.com/en-us/windows/win32/wi nrm/portal (visitado 10 de feb. de 2021).
[10]Cisco Systems. (2011). “NetFlow Version 9 Flow-Record Format”, dirección: https: //www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper 09186a00800a3db9.html (visitado 6 de jul. de 2021).
[11]E. B. Claise. (2004). “RFC3954: Cisco Systems NetFlow Services Export Version 9”, dirección: https://www.ietf.org/rfc/rfc3954.txt (visitado 12 de feb. de 2021).
[12]IANA. “IP Flow Information Export (IPFIX)”, dirección: https://www.iana.org/assi gnments/ipfix/ipfix.xhtml (visitado 6 de jul. de 2021).
[13]SIEMonster. “Product Overview”, dirección: https://siemonster.com/products-ov erview/ (visitado 5 de jun. de 2021).
67 [14]AT&T. “AlienVault OSSIM”, dirección: https://cybersecurity.att.com/products /ossim (visitado 15 de feb. de 2021).
[15]CS. “Prelude SIEM | OSS Versions”, dirección: https://www.prelude-siem.com/en /oss-version/ (visitado 15 de feb. de 2021).
[16]Mozilla. (2021). “Introduction - Mozilla Enterprise Defense Platform”, dirección: htt ps://mozdef.readthedocs.io/en/latest/introduction.html#event-pipeline (visitado 15 de feb. de 2021).
[17]Elastic. “ELK Stack: Elasticsearch, Logstash, Kibana”, dirección: https://www.elasti c.co/es/what-is/elk-stack (visitado 15 de feb. de 2021).
[18]——, “SIEM en el Elastic Stack”, dirección: https : / / www . elastic . co / es / siem (visitado 15 de feb. de 2021).
[19]——, “Elastic Integrations”, dirección: https://www.elastic.co/es/integrations (visitado 15 de feb. de 2021).
[20]Wazuh. (2021). “Wazuh 4.1 documentation”, dirección: https://documentation.wa zuh.com/4.1/ (visitado 25 de feb. de 2021).
[21]NFSen. “Documentation”, dirección: http://nfsen.sourceforge.net/ (visitado 5 de jun. de 2021).
[22]M. Bolli. “NFSen-NG”, dirección: https://github.com/mbolli/nfsen-ng/ (visitado 5 de jun. de 2021).
[23]——, “NFSen-NG - Future Work”, dirección: https://github.com/mbolli/nfsen-ng /wiki/Future_Work (visitado 5 de jun. de 2021).
[24]pmacct. “pmacct project”, dirección: http://www.pmacct.net/ (visitado 5 de jun. de 2021).
[25]——, “pmacct wiki”, dirección: https://github.com/pmacct/pmacct/wiki (visitado 5 de jun. de 2021).
[26]P. C. Chiodi. “pmacct-to-elasticsearch”, dirección: https://github.com/pierky/pma cct-to-elasticsearch (visitado 5 de jun. de 2021).
[27]M. Tyler Hart. “Manito Networks Flow Analyzer”, dirección: https://github.com/ty jhart/flowanalyzer (visitado 5 de jun. de 2021).
[28]ElastiFlow. (2021). “Elastiflow documentation”, dirección: https://docs.elastiflo w.com/docs/ (visitado 5 de mar. de 2021).
[29]——, “Product Overview”, dirección: https://www.elastiflow.com/product (visita- do 5 de jun. de 2021).
[30]Cisco Systems. “Cisco ASA Series Syslog Messages”, dirección: https://www.cisco.c om/c/en/us/td/docs/security/asa/syslog/b_syslog.html (visitado 12 de feb. de 2021).
[31]SIEMonster. “Community Edition”, dirección: https://siemonster.com/community- edition/ (visitado 5 de jun. de 2021).
68 Bibliografía [32]Elastic. (25 de jun. de 2019). “Presentación de Elastic SIEM”, dirección: https://www .elastic.co/es/blog/introducing-elastic-siem (visitado 15 de feb. de 2021).
[33]——, “Endpoint Security”, dirección: https://www.elastic.co/es/endpoint-secur ity/ (visitado 15 de feb. de 2021).
[34]——, “Suscripciones del Elastic Stack”, dirección: https://www.elastic.co/es/sub scriptions (visitado 15 de feb. de 2021).
[35]A. G. Amazon. (11 de feb. de 2020). “Launching Open Distro for Elasticsearch security features on Amazon Elasticsearch Service”, dirección: https://aws.amazon.com/es /blogs/opensource/launching-open-distro-for-elasticsearch-security-fea tures-on-amazon-elasticsearch-service/ (visitado 18 de feb. de 2021).
[36]J. G. e. a. A. Carl Meadows. (12 de abr. de 2021). “Introducing OpenSearch”, dirección: https : / / aws . amazon . com / es / blogs / opensource / introducing - opensearch/ (visitado 15 de abr. de 2021).
[37]Elastic. “Elasticsearch Endpoint Security”, dirección: https://web.archive.org/we b/20210224194812if_/https://www.elastic.co/endpoint-security/ (visitado 24 de feb. de 2021).
[38]——, “Elasticsearch Endpoint Security”, dirección: https://www.elastic.co/endpo int-security/ (visitado 24 de mayo de 2021).
[39]Amazon. (2021). “Open Distro for Elasticsearch Documentation”, dirección: https: //opendistro.github.io/for-elasticsearch-docs/ (visitado 25 de feb. de 2021).
[40]Elastic. (2015). “Elasticsearch Guide | Hardware”, dirección: https://www.elasti c.co/guide/en/elasticsearch/guide/current/hardware.html (visitado 5 de mar. de 2021).
[41]Oracle. “Java HotSpot Virtual Machine Performance Enhancements”, dirección: https ://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhanc ements-7.html (visitado 5 de mar. de 2021).
[42]Elastic. (2016). “Elasticsearch: The Definitive Guide [2.x] - Heap: Sizing and Swap- ping”, dirección: https://www.elastic.co/guide/en/elasticsearch/guide/curr ent/heap-sizing.html (visitado 5 de mar. de 2021).
[43]Netcraft. (31 de mayo de 2021). “May 2021 Web Server Survey”, dirección: https: //www.nginx.com/resources/datasheets/nginx-plus-sizing-guide/ (visitado 5 de jun. de 2021).
[44]F5 Networks. (11 de nov. de 2019). “Sizing Guide for Deploying NGINX Plus on Bare Metal Servers”, dirección: https://www.nginx.com/resources/datasheets/nginx- plus-sizing-guide/ (visitado 5 de mar. de 2021).
[45]A. G. Elastic. (18 de nov. de 2020). “Save space and money with improved storage efficiency in Elasticsearch 7.10”, dirección: https://www.elastic.co/es/blog/save -space-and-money-with-improved-storage-efficiency-in-elasticsearch-7-1 0 (visitado 5 de mar. de 2021).
Bibliografía 69 [46]Elastic. “Elasticsearch Guide”, dirección: https://www.elastic.co/guide/en/elast icsearch/reference/7.13/index.html (visitado 5 de mar. de 2021).
[47]A. B. Elastic. (25 de jun. de 2019). “Elasticsearch in Production”, dirección: https: //www.elastic.co/es/blog/found-elasticsearch-in-production (visitado 15 de feb. de 2021).
[48]Canonical. “Ubuntu release cycle”, dirección: https://ubuntu.com/about/release- cycle (visitado 5 de feb. de 2021).
[49]NIST. “NVD - CVE-2017-9798”, dirección: https://nvd.nist.gov/vuln/detail /CVE-2017-9798 (visitado 15 de jun. de 2021).
[50]CVE Details. “Apache Tomcat 8.5.11: Security vulnerabilities”, dirección: https://ww w.cvedetails.com/vulnerability-list/vendor_id-45/product_id-887/versio n_id-568969/Apache-Tomcat-8.5.11.html (visitado 15 de jun. de 2021).
[51]ElastiFlow. (2021). “Elastic Machine Learning”, dirección: https://github.com/ela stiflow/elastiflow_for_elasticsearch/tree/master/ml (visitado 14 de jun. de 2021).
70 Bibliografía Apéndices A
A.1 Despliegue del clúster Elasticsearch
Se ha partido para todas las máquinas de una instalación de Ubuntu 20.04.2 LTS
La instalación se ha realizado siguiendo la documentación de la versión 7.10 de elasticsearch, kibana y logstash.
A.1.1 Instalación del repo de elastic 7.x
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo
,→ apt-key add -
sudo apt-get install apt-transport-https
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main"
,→ | sudo tee /etc/apt/sources.list.d/elastic-7.x.list
A.1.2 Instalación de los programas
Se instalará elasticsearch para todos los nodos:
sudo apt-get update && sudo apt-get install elasticsearch=7.10.2
Adicionalmente, se instalará también kibana en el nodo máster y logstash en los nodos de ingesta.
sudo apt-get install kibana=7.10.2
sudo apt-get install logstash=7.10.2
71 A.1.3 Configuración
Configuración Elasticsearch general
En el archivo /etc/elasticsearch/elasticsearch.yml, es necesario cambiar las siguientes configuraciones:
1. cluster.name: -> Definir un nombre para el clúster. Caracteres válidos: letras minúsculas, guiones y números
2. node.roles: -> para los nodos de datos, node.roles: [ data ], para los de ingesta [ ingest, master ] y para el master [ master ].
3. http.host: -> IP en la intranet
4. transport.host: -> IP en la red interna del clúster ES.
Además de eso, hay que añadir:
discovery.seed_hosts: - 10.49.18.1 - 10.49.18.2 - 10.49.18.3 - 10.49.18.4 - 10.49.18.5
Se trata de la lista de todas las IPs de los nodos en la red interna del clúster. Por último, y esta configuración se debe eliminar tras el primer arranque satisfactorio del clúster, hace falta añadir a los nodos máster la lista inicial de nodos elegibles a máster:
cluster.initial_master_nodes: - ES-ing1 - ES-ing2 - ES-master
Certificados y cuentas de usuario
Las comunicaciones de los nodos Elasticsearch, tanto las realizadas entre ellos como las comunicaciones con el exterior estarán cifradas, con lo cual es necesario crear una autoridad certificadora, en el caso del clúster, el nodo máster.
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil ca
72 Apéndice A Apéndices Tras ejecutar este comando, se solicitará una contraseña para el certificado de la CA. Esta contraseña se solicitará para la creación del resto de certificados.
A continuación, se crean un certificado de comunicación interna por cada unode los nodos. sudo /usr/share/elasticsearch/bin/elasticsearch-certutil cert --name
,→ ES-dat1 --ca elastic-stack-ca.p12
Tras ejecutar este comando, se solicitará la contraseña del certificado de la CA, así como una contraseña para el certificado creado. Este sera necesario para la configuración de los nodos.
Los únicos certificados que faltan por crear son los certificados https. Para crearlos, se ejecuta el siguiente comando: sudo /usr/share/elasticsearch/bin/elasticsearch-certutil http
Se van a pedir una serie de datos durante el proceso de generación de los certifica- dos:
1. Generar CSR -> No
2. Usar CA -> Sí -> Introducir ubicación del archivo elastic-stack-ca.p12 -> Introducir contraseña
3. Introducir fecha de expiración de los certificados
4. Generar un certificado por nodo -> Sí
5. Por cada nodo, introducir el nombre del nodo, el nombre DNS (en nuestro caso ninguno), y la IP
6. Introducir una contraseña para los certificados
Habrá que generar un certificado por cada nodo elasticsearch más uno por cada instancia de kibana o logstash.
Para completar la seguridad, solamente falta añadir usuarios y contraseñas para los servicios que van a conectarse a Elasticsearch, esto es: Kibana, Logstash y Filebeat (Filebeat se encarga de enviar los datos desde Wazuh). sudo /usr/share/elasticsearch/bin/elasticsearch-setup-passwords auto
Este comando autogenerará contraseñas seguras para todos los usuarios, pero tam- bién se puede optar por usar el siguiente comando para elegirlas:
A.1 Despliegue del clúster Elasticsearch 73 sudo /usr/share/elasticsearch/bin/elasticsearch-setup-passwords
,→ interactive Habilitar la seguridad en Elasticsearch
Para habilitar la seguridad en los nodos Elasticsearch, se añaden al final del archivo /etc/elasticsearch/elasticsearch.yml las siguientes líneas:
xpack.security.enabled: true xpack.security.http.ssl.enabled: true xpack.security.http.ssl.keystore.path: "http.p12" xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: none xpack.security.transport.ssl.keystore.path: "ES-mast.p12" xpack.security.transport.ssl.truststore.path: "ES-mast.p12"
y se crea un keystore con las contraseñas de los certificados:
sudo /usr/share/elasticsearch/bin/elasticsearch-keystore create sudo /usr/share/elasticsearch/bin/elasticsearch-keystore add
,→ xpack.security.transport.ssl.keystore.secure_password sudo /usr/share/elasticsearch/bin/elasticsearch-keystore add
,→ xpack.security.transport.ssl.truststore.secure_password sudo /usr/share/elasticsearch/bin/elasticsearch-keystore add
,→ xpack.security.http.ssl.keystore.secure_password
En los comandos referidos a xpack.security.transport se introduce la contraseña del certificado para la comunicación inter-nodos y en el último, la de la comunicación con la intranet.
Y luego solamente falta copiar los certificados generados a /etc/elasticsearch/. Configuración de Kibana
En /etc/kibana/kibana.yml, modificar la siguiente configuración:
server.host: "0.0.0.0" elasticsearch.hosts:
,→ ["https://IP-MASTER:9200","https://IP-ING1:9200","https://IP-ING2:9200"] elasticsearch.ssl.certificateAuthorities: [
,→ "/etc/kibana/elasticsearch-ca.pem" ] server.ssl.keystore.path: "/etc/kibana/ES-kibana.p12" server.ssl.enabled: true
74 Apéndice A Apéndices Habría que substituír IP-MASTER, IP-ING1 e IP-ING2 por las IPs del máster y los dos nodos de ingesta. Se ha optado por no añadir los de datos para evitar carga innecesaria sobre ellos.
Hay que copiar el certificado http creado para kibana y el certificado público dela CA (elasticsearch-ca.pem) a /etc/kibana/.
Por último, solamente falta añadir la contraseña del certificado http de kibana ala keystore:
sudo /usr/share/kibana/bin/kibana-keystore create --allow-root sudo /usr/share/kibana/bin/kibana-keystore add
,→ server.ssl.keystore.password --allow-root
A.2 Despliegue del clúster Wazuh
Despliegue del servidor Wazuh
Primero, se deben instalar Wazuh y Filebeat
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key
,→ add - echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | sudo
,→ tee -a /etc/apt/sources.list.d/wazuh.list sudo apt update sudo apt install wazuh-manager sudo apt install filebeat=7.10.2 sudo curl -s
,→ https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.1.tar.gz
,→ | sudo tar -xvz -C /usr/share/filebeat/module
La configuración de Filebeat se ha creado en base a la presente en el githubde wazuh ( https://raw.githubusercontent.com/wazuh/wazuh/4.1/extensio ns/elasticsearch/7.x/wazuh-template.json). Se ha colocado en el archivo /etc/filebeat/filebeat.yml.
# Wazuh - Filebeat configuration file output.elasticsearch.hosts:
,→ ["https://IP-ING1:9200","https://IP-ING2:9200"] output.elasticsearch.password: --CONTRASEÑA--
A.2 Despliegue del clúster Wazuh 75 filebeat.modules: - module: wazuh alerts: enabled: true archives: enabled: false
setup.template.json.enabled: true setup.template.json.path: /etc/filebeat/wazuh-template.json setup.template.json.name: wazuh setup.template.overwrite: true setup.ilm.enabled: false
output.elasticsearch.protocol: https output.elasticsearch.ssl.certificate:
,→ /etc/filebeat/certs/Wa-master.crt output.elasticsearch.ssl.key: /etc/filebeat/certs/Wa-master.key output.elasticsearch.ssl.certificate_authorities:
,→ /etc/filebeat/certs/ca/ca.pem output.elasticsearch.username: elastic
Se han movido los certificados creados para el servidor Wazuh a /etc/filebeat/certs/.
Una vez finalizada la configuración de Filebeat, se pasa a realizar la configuración de NGINX. Servidor NGINX
Se ha instalado el paquete nginx-core, dado que es la versión más ligera de NGINX con el módulo de stream.
sudo apt install nginx-core
Se han deshabilitado todos los módulos excepto el módulo stream, que venía habi- litado por defecto:
sudo rm /etc/nginx/modules-enabled/50-mod-mail.conf sudo rm /etc/nginx/modules-enabled/50-mod-http-*
Se ha utilizado la siguiente configuración (/etc/nginx/nginx.conf). Se ha substi- tuído la IP del servidor Wazuh en la intranet por IP-WAZUH:
76 Apéndice A Apéndices user www-data; worker_processes auto; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf; events { worker_connections 768; # multi_accept on; } stream { upstream WazuhMaster { server IP-WAZUH:1515; } upstream WazuhCluster { hash $remote_addr consistent; server IP-WAZUH:1514; } server { listen 1515; proxy_pass WazuhMaster; } server { listen 1514; proxy_pass WazuhCluster; } }
Configuración adicional kibana
En Kibana, es necesario instalar el plugin de Wazuh: sudo chown -R kibana:kibana /usr/share/kibana sudo -u kibana /usr/share/kibana/bin/kibana-plugin install
,→ https://packages.wazuh.com/4.x/ui/kibana/wazuh_kibana-4.1.1_7.10.2-1.zip
Tras eso, se debe modificar la configuración del plugin, el archivo /usr/share/kib ⌋ ana/data/wazuh/config/wazuh.yml. En concreto, hay que modificar los siguientes campos:
A.2 Despliegue del clúster Wazuh 77 hosts: - wazuh_prod: url: https://IP-WAZUH
enrollment.dns: 'IP-PROXY'
Una vez esté configurado esto, el servidor Wazuh está listo para recibir nuevos agentes y mostrar las visualizaciones.
A.3 Despliegue de ElastiFlow
El despliegue se va a realizar usando el Docker-compose oficial de ElastiFlow. Se han cambiado los siguientes atributos:
EF_FLOW_DECODER_ENRICH_MAXMIND_GEOIP_ENABLE: 'true' #EF_FLOW_DECODER_ENRICH_MAXMIND_GEOIP_CACHE_SIZE: 262144 EF_FLOW_DECODER_ENRICH_MAXMIND_GEOIP_PATH:
,→ 'maxmind/GeoLite2-City.mmdb' EF_FLOW_OUTPUT_ELASTICSEARCH_ENABLE: 'true' EF_FLOW_OUTPUT_ELASTICSEARCH_INDEX_TEMPLATE_OVERWRITE: 'true' EF_FLOW_OUTPUT_ELASTICSEARCH_INDEX_TEMPLATE_SHARDS: 1 EF_FLOW_OUTPUT_ELASTICSEARCH_INDEX_TEMPLATE_REPLICAS: 0 EF_FLOW_OUTPUT_ELASTICSEARCH_ADDRESSES:
,→ 'IP-ING2:9200,IP-ING1:9200' EF_FLOW_OUTPUT_ELASTICSEARCH_USERNAME: 'elastic' EF_FLOW_OUTPUT_ELASTICSEARCH_PASSWORD: '--CONTRASEÑA--' EF_FLOW_OUTPUT_ELASTICSEARCH_TLS_ENABLE: 'true' EF_FLOW_OUTPUT_ELASTICSEARCH_TLS_SKIP_VERIFICATION: 'true'
También se ha empleado UDP Samplicator con el siguiente Docker-compose:
version: '3' services: samplicator-netflow: image: robcowart/samplicator:1.0.1_1.3.8rc1 container_name: samplicator-netflow restart: unless-stopped
78 Apéndice A Apéndices network_mode: host command: -s 0.0.0.0 -p 2057 -S -d 0 127.0.0.1/9995
,→ 10.0.99.150/2057
La base de datos de geolocalización utilizada por ElastiFlow es la GeoLite2 de MaxMind. Para actualizarla se emplea la herramienta geoipupdate, proporciona- da por Maxmind. La herramienta se ha instalado siguiendo las instrucciones de MaxMind: sudo add-apt-repository ppa:maxmind/ppa sudo apt update sudo apt install geoipupdate
La configuración para el programa se ha creado en base a la de ejemplo, disponible en https://www.maxmind.com/en/accounts/current/license-key/GeoIP.conf (guardada en el archivo /usr/local/etc/GeoIP.conf:
# GeoIP.conf file for `geoipupdate` program, for versions >= 3.1.1. # Used to update GeoIP databases from https://www.maxmind.com. # For more information about this config file, visit the docs at # https://dev.maxmind.com/geoip/geoipupdate/.
# `AccountID` is from your MaxMind account. AccountID YOUR_ACCOUNT_ID_HERE
# Replace YOUR_LICENSE_KEY_HERE with an active license key
,→ associated # with your MaxMind account. LicenseKey YOUR_LICENSE_KEY_HERE
# `EditionIDs` is from your MaxMind account. EditionIDs GeoLite2-City
Para facilitar el proceso de actualización de la base de datos que usa elastiflow, se ha creado un script que ejecuta la herramienta geoipupdate para descargar la última versión de la base de datos y la copia a la carpeta correcta:
#!/bin/bash geoipupdate cp "/usr/share/GeoIP/GeoLite2-City.mmdb" /etc/elastiflow/maxmind/
A.3 Despliegue de ElastiFlow 79 Una vez finalizado eso, solamente falta descargar las visualizaciones de elastiflow para kibana (https://docs.elastiflow.com/docs/kibana) e importarlas a través de la interfaz web (en la configuración: Stack Management -> Saved Objects -> Import)
A.4 Actualización de versión del sistema
El proceso de actualización del sistema, como por desgracia no se puede realizar sin pérdida de datos, debería realizarse en un momento de bajo riesgo (fines de semana, fuera de horas laborables, por ejemplo).
No se incluyen instrucciones exactas, dado que pueden variar de versión a versión.
A.4.1 Actualización de Wazuh
La versión a la que se quiera actualizar Wazuh dictaminará la versión a la que se actualizará el clúster de Elasticsearch, dado que Wazuh tiene que soportar la versión de Elasticsearch a instalar. En concreto, el plugin de Wazuh para kibana debe ser compatible. Esto se puede verificar en los changelogs del repositorio del plugin en Github, https://github.com/wazuh/wazuh-kibana-app.
Desde ahí, se debe seguir la última guía de actualización de Wazuh disponible. Esta se puede encontrar en https://documentation.wazuh.com/current/upgrade-gu ide/
Una vez actualizados todos los servidores, se pueden actualizar los agentes desplega- dos de forma remota, mediante el comando agent_upgrade -a ID_AGENTE, como se muestra en https://documentation.wazuh.com/current/user-manual/agen ts/remote-upgrading/upgrading-agent.html.
A.4.2 Actualización de ElastiFlow
Para actualizar ElastiFlow, bastaría con eliminar el contenedor docker, descargar la última versión del archivo docker-compose de https://docs.elastiflow.co m/docs/install_docker, aplicar los mismos cambios en la configuración que se realizaron durante la instalación original, y volver a lanzar el docker.
80 Apéndice A Apéndices A.5 Decoders y reglas creados
A.5.1 Swivel
Programa de filtrado de logs
1 #include
3
4 /* 5 * Este programa implementa un filtro externo para rsyslog para eliminar el caracter ,→ UTF-8 "NBSP" (non-breaking space) 6 * ---> ' ' (U+00A0) 7 * Este caracter en representación UTF-8 ocupa dos bytes: 0xC2 0xA0. Se eliminan ambos ,→ y se substituyen por un espacio 8 * ===> ' ' (U+0020) 9 */
10
11 int main() { 12 char buf[4096]; 13 int running = 1;
14
15 while (running == 1){ 16 unsigned int bufsize = sizeof(buf); 17 if (fgets(buf, bufsize,stdin) == NULL){ 18 running = 0; // EOF significa que tengo que parar el programa 19 } 20 for (unsigned int i = 0; buf[i] != '\0' || i < bufsize; i++){ // for hasta ,→ final de búfer o hasta encontrar el caracter NULL 21 if (buf[i] == '\xc2'){ // Primer byte de NBSP en UTF-8 22 i++; 23 if (buf[i] == '\xa0'){ // Segundo byte de NSBP 24 buf[i] = ''; // Substitute both bytes for spaces (simplest ,→ solution) 25 buf[i - 1] = ''; 26 } else { 27 i--; // Si el segundo byte no coincide, retrocedo un caracter 28 } 29 } else if (buf[i]=='\n' && buf[i+1]=='\0'){//elimino el último \n 30 buf[i]='\0'; 31 } 32 } 33 printf("{ \"msg\" : \"%s\" }\n", buf); // Salida en formato json para el módulo ,→ mmexternal de rsyslog 34 fflush(stdout); 35 }
A.5 Decoders y reglas creados 81 36 return EXIT_SUCCESS; 37 }
Decoder
1
5
6
11
12
17
18
23
24
29
30
35
36
41
42
82 Apéndice A Apéndices 44
Reglas
1
13
,→ hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.8,tsc_CC7.2, ⌋ ,→ tsc_CC7.3, 14
15
16
20
,→ gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14, ⌋ ,→ nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 21
22
23
30
,→ gpg13_7.8,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14, ⌋
,→ nist_800_53_AC.7,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, ⌋ ,→ 31
32
33
A.5 Decoders y reglas creados 83 35
37
,→ gdpr_IV_32.2,hipaa_164.312.a.2.I,hipaa_164.312.a.2.II,hipaa_164.312.b, ⌋
,→ nist_800_53_AC.2,nist_800_53_IA.4,nist_800_53_AU.14,nist_800_53_AC.7, ⌋ ,→ tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 38
39
40
44
,→ gdpr_IV_32.2,hipaa_164.312.a.2.I,hipaa_164.312.a.2.II,hipaa_164.312.b, ⌋
,→ nist_800_53_AC.2,nist_800_53_IA.4,nist_800_53_AU.14,nist_800_53_AC.7, ⌋ ,→ tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 45
46
47
51
,→ gdpr_IV_32.2,hipaa_164.312.a.2.I,hipaa_164.312.a.2.II,hipaa_164.312.b, ⌋
,→ nist_800_53_AC.2,nist_800_53_IA.4,nist_800_53_AU.14,nist_800_53_AC.7, ⌋ ,→ tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 52
53
54
62
,→ gdpr_IV_35.7.d,hipaa_164.312.a.1,nist_800_53_AC.7,nist_800_53_SI.4,tsc_CC6.1, ⌋ ,→ tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 63
64
65
84 Apéndice A Apéndices 72
74
75
80
81
86
87
92
93
97
,→ gdpr_IV_32.2,hipaa_164.312.a.2.I,hipaa_164.312.a.2.II,hipaa_164.312.b, ⌋
,→ nist_800_53_AC.2,nist_800_53_IA.4,nist_800_53_AU.14,nist_800_53_AC.7, ⌋ ,→ tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 98
99
100
A.5.2 Fortigate
Decoder
1 5
A.5 Decoders y reglas creados 85 7
9
10
15
16
21
22
27
28
33
34
39
40
45
46
51
52
86 Apéndice A Apéndices 55
57
58
63
64
69
70
75
76
81
82
87
88
93
94
99
100
A.5 Decoders y reglas creados 87 103
105
106
111
112
117
118
123
124
129
130
135
136
141
142
147
148
88 Apéndice A Apéndices 151
Reglas
1 5
10
11
15
17
18
25
,→ hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.8,tsc_CC7.2, ⌋ ,→ tsc_CC7.3, 26
27
28
32
34
35
A.5 Decoders y reglas creados 89 39
,→ gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14, ⌋ ,→ nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 40
41
42
46
48
49
56
,→ hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.8,tsc_CC7.2, ⌋ ,→ tsc_CC7.3, 57
58
59
63
65
66
73
,→ gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.6, ⌋
,→ nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC7.2,tsc_CC7.3,tsc_CC6.1,tsc_CC6.8, ⌋ ,→ 74
90 Apéndice A Apéndices 75 78
83
,→ gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14, ⌋ ,→ nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3, 84 85
92
,→ gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.6, ⌋
,→ nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC7.2,tsc_CC7.3,tsc_CC6.1,tsc_CC6.8, ⌋ ,→ 93 94
A.5.3 Cisco Firepower
Decoder
1 7 10 11
92 Apéndice A Apéndices 41
A.5 Decoders y reglas creados 93 88
96 Apéndice A Apéndices 215
98 Apéndice A Apéndices 306
100 Apéndice A Apéndices 396 397 403
A.5 Decoders y reglas creados 103 516 520
104 Apéndice A Apéndices 556 557 562
A.5 Decoders y reglas creados 105 595 596 600
108 Apéndice A Apéndices 703
A.5 Decoders y reglas creados 109 746
110 Apéndice A Apéndices 791
A.5 Decoders y reglas creados 111 836
114 Apéndice A Apéndices 963
A.5 Decoders y reglas creados 115 1006
116 Apéndice A Apéndices 1049
A.5 Decoders y reglas creados 117 1093
Reglas
1
118 Apéndice A Apéndices 5 6
A.5 Decoders y reglas creados 119