Documento de aocumento de Arquitectura de Solución V.1.

0
Documento de arquitectura de solución

Proyecto Claro SIEM+UEBA

AVISO DE CONFIDENCIALIDAD:

La información incluida en este documento ha sido preparada para ser utilizada en el contexto de este proyecto. No debería utilizarse como
modelo o precedente en ninguna situación fuera de este trabajo. Este documento es confidencial y su uso debe estar previamente autorizado. Ni
este documento ni ninguna de las informaciones contenidas en el mismo podrán ser reproducidas o divulgadas bajo ninguna circunstancia sin el
permiso expreso por escrito de Claro Colombia. Tenga en cuenta que la divulgación, copia, distribución o uso de este documento y la
información contenida en él está estrictamente prohibida.

INFORMACIÓN DE DOCUMENTO

Documento creado por: Equipo de proyecto NowBit.

Documento creado para:

Equipo de Ciberseguridad
Equipo de diseño Cloud y Datacenter

Versión de documento: 1.0

Fecha de documento: 23/Jun/2021

HISTORIAL DE VERSIONES

Versión Resumen de actualización Fecha de Autor

actualización

1.0 Versión inicial del documento 23/Jun/2021 Andrés Castiblanco

CONTENIDO
1 Alcance de este documento
2 Requerimientos iniciales de diseño
3 Principios y lineamientos de arquitectura:
4 Políticas de diseño de la solución
4.1 Política de seguridad:
4.2 Política de Datos
4.3 Política de duración del índice:
4.4 Política de tamaño máximo del índice:
4.5 Política de ciclo de vida del índice (ILM):
4.6 Política de características del índice:
4.7 Política de esquema Multitenant
4.8 Política de enrutamiento y comunicaciones
4.9 Política de definición de mapping
4.9.1 Host fields
4.9.2 Authentication fields
4.9.3 Uncommon process fields
4.9.4 Network fields
4.9.5 DNS query fields
4.9.6 HTTP request fields
4.9.7 TLS fields
4.10 Política de backup:
4.11 Política de notificaciones:

Alcance de este documento

El objetivo de este documento es presentar el diseño arquitectónico que aborda los requisitos técnicos y funcionales para el proyecto Diseño e
implementación solución SIEM+UEBA. Este documento detallará los componentes de Hardware y Software utilizados y configuración para la
solución, los componentes de infraestructura y los lineamientos de seguridad que se han definido en la esta solución.

Requerimientos iniciales de diseño

Los siguientes requerimientos se encuentran el marco de la fase de diseño y planeación detallada, y son elementos que permitirán la
construcción de la solución en el marco de buenas prácticas.

Capa Requerimiento Racional

OpenShift Se requiere contar con el usuario system:admin o con un Para realizar la instalación de los componentes de
usuario con los siguientes privilegios: orquestación Elastic requiere contar con los
permisos adecuados para el proceso.
Crear proyectos.
CRDs
RBAC a nivel de Clúster
Administrar recursos de Elastic en el namespace
Elastic-Operator.
Crear balanceadores a nivel Openshift.
Crear Secrets.

OpenShift Cuando se esté realizando la implementación del clúster de
OpenShift, se requiere realizar la configuración de los
siguientes parámetros a nivel de los nodos de OpenShift,
que serán disponibilizados para Elastic.
sysctl vm.max_map_count= 262144
node.store.allow_mmap = sin configurar
Antes de implementar un clúster de Elasticsearch
con ECK, asegúrese de que los nodos de
Kubernetes en su clúster tengan la configuración de
sysctl vm.max_map_count correcta. Por defecto, es
probable que los pods creados por ECK se ejecuten
con la restricción de contexto de seguridad (SCC)
que restringe el acceso privilegiado necesario para
cambiar esta configuración en los nodos Kubernetes
subyacentes.

OpenShift Los pods de Elasticsearch que tengan el mismo rol, deben Para evitar que la replicación que ofrece el clúster de
quedar en diferentes hardware físicos. Elasticsearch quede en el mismo hardware y genere
puntos únicos de falla.
Distintos roles si pueden convivir en el mismo hardware.

Los 3 pods Master, deben quedar en hardware

distintos.
Los 3 pods Hot Data, deben quedar en hardware
distintos.
Los 3 pods Warm Data, deben quedar en hardware
distintos.
Los 3 pods Cold Data, deben quedar en hardware
distintos.
Los 3 pods Machine Learning, deben quedar en
hardware distintos.
Los 3 pods Kibana, deben quedar en hardware
distintos.
Un pod Master y un pod Hot Data, por ejemplo,
pueden quedar en el mismo hardware.

OpenShift Se requiere desarrollar e implementar las políticas
necesarias en la capa de VMware y OpenShift que
garanticen que los pods creados para el Clúster de
Elasticsearch, no cambien su ubicación a nivel de
Hardware, después de que hayan sido desplegados.
Elastic es una plataforma que resuelve las
características de alta disponibilidad (HA) y
tolerancia a fallos (FT) desde el Software, pero para
garantizarlo se deben asegurar estos dos últimos
requisitos.

OpenShift Se requiere aprovisionar el almacenamiento para los pods

de Elasticsearch de la siguiente manera:

Para los nodos Máster, ML y Kibana se puede utilizar:

SSD o HDD, ya que este rol no hace uso intensivo de I
/O. Sin embargo para un mejor desempeño
recomendamos aprovisionar SSD si cuentan con
capacidad.
 Para los nodos de Hot Data, se recomienda utilizar
discos tipo SSD, se pueden utilizar de tipo NVMe o
estándar SSD de (>200Gb/s) IOPS Lectura 412.500,
IOPS Escritura 180.000 . En su defecto seleccionar la
configuración que ofrezca la mejor tasa de I/O y menor
latencia posible.
Para los nodos de Warm y Cold Data se recomienda
utilizar discos de tipo HDD (Convencional) (~100Gb/s)
IOPS Generales 15.000 y como mínimo de 7200
RPMs. En su defecto seleccionar la mejor
configuración que ofrezca un balance entre I/O y
capacidad de almacenamiento posible.

DNS Se requieren dos dominios DNS, uno para Kibana y dos La configuración DNS para Elastic y Kibana, va a
para Elasticsearch, estos serán los que tengan asignadas permitir habilitar la comunicación cifrada, desde los
las IP de los balanceadores de carga y también tendrán los clientes de ingesta y de administración.
certificados SSL.

Seguridad Se requieren dos certificados emitidos por una CA
(preferiblemente pública, por el acceso de clientes de
Claro), uno para Kibana y otro para Elasticsearch, los
detalles de certificados deben ser como mínimo los
siguientes:
Algoritmo de cifrado: SHA-256 with RSA Encryption
V3, 256 Bits.
TLS 1.2 o superior (recomendable TLS 1.3)
Llave pública: RSA clave 2048.
Compartir los archivos
Certificado en formato tls.crt.
Llave privada en formato tls.key.
Si el certificado no es emitido por una CA pública,
compartir el archivo de cadena de confianza de la
CA en formato ca.crt.
Una parte crítica de la seguridad es mantener los
datos confidenciales protegidos. Las características
de seguridad de Elastic Stack utilizan TLS para
preservar la integridad de sus datos contra la
manipulación, al mismo tiempo que proporciona
confidencialidad mediante el cifrado de las
comunicaciones hacia, desde y dentro del clúster y
se realiza a través del proceso de configuración de la
encriptación a nivel SSL/TLS.
Algunas aplicaciones como el módulo de
alertamiento requieren de la configuración de SSL
/TSL activa, para su funcionamiento.

Autenticación por Para realizar la integración de autenticación con Directorio Para configurar las funciones de seguridad Elastic
Directorio Activo Activo se requiere la siguiente configuración: Stack para comunicarse con un servidor LDAP, para
autenticar a los usuarios con la plataforma de Elastic,
URL y puerto del servidor LDAP. se requiere de la información específica que permite
Contenedor DN donde serán buscados los usuarios la conexión con LDAP y poder realizar la integración
dentro la BD LDAP. de manera satisfactoria.
Usuario y contraseña que tendrá los permisos para
realizar las búsquedas en la BD de LDAP.
Si la comunicación por LDAP está cifrada se requiere
del certificado firmado en formato .PEM, generado por
la CA que firma los certificados de LDAP para
incorporar en Elastic.

Gestión de copias Se requiere aprovisionar un repositorio compartido para Una copia de seguridad permite tener los datos del
de seguridad alojar las copias de seguridad de la base de datos de clúster completo, incluyendo todos sus flujos de
Elastic con las siguientes características: datos e índices. También puede tomar instantáneas
de sólo flujos de datos específicos o índices en el
La carpeta compartida debe tener la capacidad de clúster. Y permite tener un punto de retorno en caso
almacenar el tamaño de la base de datos (Sin réplicas) de fallas o pérdida de información.
de Elasticsearch. Estaba BD irá aumentando en la
medida que se vayan ingestando información.
Los pods de datos del clúster de Elasticsearch deben
tener la capacidad de poder realizar operaciones de
lectura/escritura en el repositorio de copias de
seguridad.
Tener en cuenta que se requieren 2 repositorios 1 para
el ambiente de producción y otro para el ambiente de
pre-producción.

Firewall y Se requiere realizar la apertura de diferentes reglas en

comunicaciones el firewall para permitir la comunicación de los
servicios de Elasticsearch y los dispositivos.
La lista se adjunta en el archivo “Reglas_Firewall_V1”
en la sección Anexos.
Principios y lineamientos de arquitectura:

Lineamientos generales

Tipo Definición

Escalabilidad Elasticsearch se distribuye y escala horizontalmente. Los recursos del clúster crecerán en la medida
que el caso de uso lo requiera.

Comunicación Elasticsearch proporciona API REST para comunicarse con un clúster a través de HTTP/HTTPS

Componentes Elastic Stack es una colección de productos con Elasticsearch en el core.

Orquestación:
OpenShift 4.6
Elastic Cloud for Kubernetes
Ingesta:
Beats
Logstash
Almacenamiento, búsqueda, análisis:
Elasticsearch
Visualización y Administración
Kibana

Datos

Tipo Definición

Tipo de datos a ingestar Time series data: En Elastic se registrarán datos de eventos asociados con un momento en el
tiempo que aumentan rápidamente, como archivos de log o métricas

Campos adicionales en los eventos
Se debe agregar la siguiente información a cualquier evento o integración que ingeste
información a Elastic, la información que se debe adicionar es la siguiente.
Nombre del cliente.
Nombre de la plataforma.
Cumplimiento
Geolocalización (IP Pública)

Origen de los campos adicionales
Nombre del cliente: Equipo de Claro-Ciberseguridad entregará un diccionario de datos que
permitirá identificar el cliente asociado a un documento.
Nombre de la plataforma.
Cumplimiento.
Geolocalización (IP Pública).

Índices

Tipo Definición

Mapping Elasticsearch indexará en documentos tipo JSON la información ingestada. Sin embargo
Elasticsearch asigna tipos de datos a los campos en un Mapping

Elastic Common Schema ECS es una especificación de código abierto que define un conjunto común de campos de
documento.

ECS está diseñado para soportar modelado de datos uniforme y especifica nombres de campo y
tipos de datos para cada campo.

Elastic Common Schema niveles
de campo
ECS define dos niveles de campo: Core y Extended
ECS Core Fields son campos que son más comunes en todos los casos de uso y debe
centrarse en la población de estos campos primero.
Los Campos Extendidos ECS son cualquier campo que no sea un campo central que puedan
aplicar a casos de uso más estrechos.

Cada documento debe tener el campo @timestamp.

Guías generales para el uso de
Elastic Common Schema
Mapear tantos campos como sea posible a ECS.
Asegúrese de que los nombres de campo estén en minúsculas.
Combinar palabras usando guión bajo, sin caracteres especiales excepto guiones bajos.
Usar prefijos para todos los campos (<fieldset>.fieldname), excepto para los campos base.
Evite palabras de repetición (host.host_ip -> host.ip).
Evitar abreviaturas cuando sea posible.

Elasticsearch nodos.

Tipo Definición

Mecanismo de comunicación de red Transporte: Utilizado para la comunicación interna entre nodos dentro del clúster.
HTTP: Expone las APIs Rest de Elasticsearch para los clientes externos.

Puertos definidos para Transporte: 9300

comunicación HTTP: 9200

Rol Master Cada clúster tendrá un nodo designado como maestro.

El nodo maestro estará a cargo de la configuración del clúster y cambios de estado.

Elección de rol maestro El número de votos para elegir el nodo maestro es manejado automáticamente por
Elasticsearch para asegurar el quórum.
Que siempre debe ser N/2+1, donde N es el número de nodos principales elegibles.
Es importante tener asegurar quórum para evitar un evento de “Split Brain”

Alta disponibilidad del nodo maestro El propósito de tener 3 nodos aptos para ser maestros es que si el nodo maestro falla, hay 2 backup,
que mantendrán la disponibilidad del clúster.

Roles

Tipo Definición

Rol: Nodo de datos Almacena los shards que contienen los documentos que han sido indexados.

Ejecutan operaciones relacionadas con datos como CRUD, búsqueda y agregaciones.

Los nodos de datos son intensivos en I/O, CPU y memoria.

Es importante monitorear estos recursos y agregar más nodos de datos si están sobrecargados

Rol: Nodo Machine Learning Este nodo tendrá la capacidad de ejecutar jobs de Machine Learning.

Mantener los requerimientos del API de Machine Learning.

Rol: Nodo Coordinator Es el nodo que recibe y maneja una solicitud de cliente específica.

Cada nodo es implícitamente un nodo coordinador envía la solicitud a otros nodos relevantes.

Luego combina esos resultados en una respuesta.

Nodos dedicados: La implementación actual tendrá nodos con roles dedicados para mejorar el uso de recursos y el
desempeño de los nodos.

Shards

Tipo

Shard Un shard es una unidad de trabajo que contiene datos y puede ser asignada a los nodos de datos.

Shard Primario y Réplica Existen 2 tipos de shards:

Primarios: Contiene la información original del índice.

Replicas: Es una copia del shard primario.

Los documentos serán almacenados en un shard primario y su réplica.

La distribución de un shard primario y un shard réplica se debe realizar en nodos diferentes.

Los shard replica van a ayudan a mejorar el rendimiento de las operaciones de lectura.
 Alta disponibilidad Contar con shard réplicas va a permitir mantener disponibilidad de los datos cuando un nodo falla.

Cuando este evento sucede las replicas serán promovidas a shard primarios.

Notificaciones:

Tipo

Concepto El módulo de “Alerting” funciona al ejecutar comprobaciones en un horario para detectar las
condiciones definidas por una regla. Cuando se cumple una condición, la regla la rastrea como una
alerta y responde activando una o más acciones.

Las acciones típicamente implican interacción con servicios de Kibana o integraciones de terceros.

Los conectores permiten que las acciones hablen con estos servicios e integraciones.

Reglas Una regla específica una tarea de fondo que se ejecuta en el servidor Kibana para verificar
condiciones específicas. Consta de tres partes principales:

Condiciones: ¿Qué es necesario detectar?

Horario: ¿Cuándo/con qué frecuencia deben realizarse los controles de detección?
Acciones: ¿Qué sucede cuando se detecta una afección?

Políticas de diseño de la solución

Política de seguridad:

La solución contará con diferentes capas de seguridad que van a controlar el acceso a los módulos e información almacenada en Elasticsearch.

Firewall: Para acceder al clúster de Elasticsearch se tendrán una serie de reglas de firewall con filtrado IP-Red para permitir sólo el
acceso a los servidores de Logstash y redes de usuarios administradores autorizados.
Encriptación: Las comunicaciones entre los nodos del clúster y clientes que se conecten a Elastic se realizarán través del cifrado de
tráfico usando SSL/TLS, por medio de certificados de autenticación de nodos.
Role-based access control (RBAC): El control de acceso basado en roles (RBAC) le permite autorizar a los usuarios mediante la
asignación de privilegios a roles y la asignación de roles a usuarios o grupos.
Para el control de usuarios y privilegios asignados, el equipo de administración de Claro, contará con una matriz que define los
grupos de usuarios que estarán habilitados sobre el Clúster.
Attribute-based access control (ABAC): Las características de seguridad de Elastic Stack también proporcionan un mecanismo de
control de acceso basado en atributos (ABAC), que le permite usar atributos para restringir el acceso a documentos en consultas de
búsqueda y agregaciones. Esto le permite implementar una política de acceso en una definición de rol para que los usuarios puedan
leer un documento específico sólo si tienen todos los atributos necesarios.

Política de Datos

La definición de la política de datos hace referencia a las características del índice destinado para el almacenamiento de los datos de la
plataforma de SIEM, haciendo referencia a la duración, ciclo de vida y características propias de cada índice. Esta política esta definida para
seguir los lineamientos de la arquitectura Hot/Warm/Cold planteada al equipo Claro y aprobada por el fabricante para la retención e ingesta
solicitadas.

Política de duración del índice:

Esta característica hace referencia a la duración máxima que puede tener un índice antes de crearse uno nuevo para cada una de las etapas de
la vida de del índice. Esto significa que al completarse la duración máxima deberá crearse un nuevo índice.

Etapa Duración de datos en la etapa Duración Máxima Máximo de índices simultáneos por duración

Hot 2 Meses 1 Mes 3 índices

Warm 1 Año 6 Meses 3 índices

Cold 3 Años No aplica 1 índice

Política de tamaño máximo del índice:

Esta característica hace referencia a el tamaño máximo que puede tener un índice antes de crearse uno nuevo para cada una de las etapas de
la vida del índice, esto significa que al completarse el tamaño máximo deberá crearse un nuevo índice.

Etapa Tamaño máximo del índice en GB

Hot 50 GB

Warm No aplica

Cold No aplica

Política de ciclo de vida del índice (ILM):

El ciclo de vida del índice define los tiempos en los que los datos se moverán a través de las etapas Hot/Warm/Cold. Es decir cuando se
cumplen los máximos de duraciones establecidos los datos deberán desplazarse a lo largo de las distintas etapas Hot/Warm/Cold

Etapa Duración máxima del índice

Hot 2 Meses

Warm 1 Año

Cold 3 Años

Política de características del índice:

Estas definiciones determinan las características del índice a lo largo de su ciclo de vida, estas características definirán aspectos del índice que
tendrán afectaciones en su rendimiento, el espacio que ocupan, y como son referenciados dentro del clúster.

En primer lugar se tiene la definición del nombre del índice a lo largo de las etapas, y será de la siguiente forma:

Etapa Nombre del índice

Hot claro_siem-hot_%{YYYY.MM}-%{indexnumber}

Warm claro_siem-warm_%{YYYY}.%{semester}

Cold claro_siem-cold

Adicionalmente los índices tendrán una serie de características que tienen relación con el rendimiento de los índices y el espacio que ocupan

Etapa # shards primarios # shards replicas Estado del índice

Hot 1 1 Abierto

Warm 1 1 Cerrado

Cold 1 1 Congelado

Política de esquema Multitenant

En estas definiciones se encontrarán los lineamientos necesarios para llevar una arquitectura que permita la característica “multitenant“ para los
clientes finales de Claro en la herramienta de Elasticsearch.

En primer lugar, se tiene la segmentación por “spaces” de Kibana, donde se creara un espacio por cada cliente y uno para el área de seguridad
de Claro, en cada uno de los clientes se limitan las aplicaciones como lo muestra la imagen de referencia según lo descrito en el documento de
la matriz RACI
En segundo lugar, se definirá una política de roles basada en atributos. El atributo principal para la definición de roles es un ID único por cada
cliente. El valor del ID que corresponde a cada cliente será almacenado en cada documento en el campo customer.id , los roles se definir
usando un Query de DSL basado en el atributo como se muestra a continuación:

Con los puntos definidos anteriormente se tendría un esquema donde cada cliente tiene un espacio de Kibana, donde se limitan las aplicaciones
con las que puede contar, adicionalmente al rol se le especificarán permisos de Lectura, Lecto/Escritura o ninguno sobre cada una de las
aplicaciones que limitan al espacio de Kibana. Adicionalmente para el caso de los usuarios de los clientes finales el rol limitará el acceso basado
por documentos que comparten la característica del customer.id correspondiente.
Política de enrutamiento y comunicaciones

Estas definiciones hacen referencia a la capa de comunicaciones y redes. Adicionalmente también se definen las políticas de Firewall
necesarias para el correcto funcionamiento de la infraestructura de Elasticsearch como se manifiesta en la siguiente tabla:

Origen Destino Protocolo Puerto Descripción

Todos los pods Elasticsearch Servidor de Backup TCP 445 Acceso a carpeta compartida UNC para backup
tipo filesystem

Todos los servidores Logstash Todos los pods Elasticsearch TCP 9200 Conexión desde servidores Logstash a
Elasticsearch para ingesta de datos

API´s Externos Todos los pods Elasticsearch TCP 9200 Consumo de servicios de Elastic por clientes
externos

Todos los pods Elasticsearch Todos los pods Elasticsearch TCP 9300 Capa de transporte entre nodos

Usuarios que consumen Kibana Balanceador Kibana TCP 5601 Conexión a website de Kibana para administración
y consulta de la plataforma

Clientes que consumen Nodos Balanceador Elastic TCP 9200 Conexión a pods específicos de Elastic para
Elastic segmentar la lectura-escritura de nodos

Servidor Logstash Triara API´s Externos TCP 443 Conexión a fuentes externas SaaS que serán
integradas a Elastic Security

API´s Externos Servidor Logstash Triara TCP 5044 Puerto de servicio de Logstash

Política de definición de mapping

Esta política determina los campos que se emplearan en el índice de SIEM según los lineamientos del Elastic Common Schema.

Host fields

Estos campos se pueden asignar para mostrar datos de host adicionales en la aplicación Elastic Security:

Nombre del campo ECS Descripción

@timestamp Campo principal de serie de tiempo.

Tipo: Date
Nota: Este es un campo obligatorio para el uso del modulo de Elastic Security

host.name Nombre del anfitrión.

Puede contener qué nombre de host devuelve en los sistemas Unix, el nombre de dominio completo o
un nombre especificado por el usuario.

Tipo: palabra clave

Nota: Este es un campo obligatorio para el uso del modulo de Elastic Security

cloud.instance.id ID de instancia de la máquina host.

Tipo: palabra clave

Ejemplo: i-1234567890abcdef0

cloud.machine.type Tipo de máquina de la máquina host.

Tipo: palabra clave

Ejemplo: t2.medium

cloud.provider Nombre del proveedor de la nube. Los valores de ejemplo son aws, azure, gcp o digitalocean.

Tipo: Keyword

Ejemplo: aws

cloud.region Región en la que se está ejecutando este host.

 Tipo: Keyword

Ejemplo: us-east-1

host.architecture Arquitectura del sistema operativo.

Tipo: Keyword

Ejemplo: x86_64

host.id ID de host único.

Como el nombre de host no siempre es único, utilice valores que sean significativos en su entorno.

Tipo: Keyword

host.ip Direcciones IP de host.

Tipo: ip

Nota: este campo debe contener una array de valores.

host.mac Dirección mac del Host.

Tipo: palabra clave

Nota: este campo debe contener una matriz de valores.

host.os.* Los campos del sistema operativo contienen información sobre el sistema operativo.

Authentication fields

Estos campos deben asignarse para mostrar los datos de autenticación del host en la aplicación Elastic Security:

Nombre del campo ECS Descripción

event.category Este es uno de los cuatro campos de categorización de ECS e indica el segundo nivel en la jerarquía
de categorías de ECS.

event.category representa los "big buckets" de las categorías de ECS. Por ejemplo, filtrar event.
category: process muestra todos los eventos relacionados con la actividad del proceso. Este campo
está estrechamente relacionado con event.type, que se utiliza como subcategoría.

Este campo es una array. Esto permitirá la categorización adecuada de algunos eventos que caen en
múltiples categorías.

Tipo: keyword

Nota: este campo debe contener una array de valores.

Importante: el valor del campo debe ser uno de los siguientes:

authentication, configuration, database, driver, file, host, iam, intrusion_detection, malware, network,
package, process, registry, session, web

event.outcome Este es uno de los cuatro campos de categorización de ECS e indica el nivel más bajo en la jerarquía
de categorías de ECS.

event.outcome simplemente denota si el evento fue un éxitoso o fracasó desde la perspectiva de la

entidad que produjo el evento.

Tenga en cuenta que cuando una sola transacción se describe en múltiples eventos, cada evento
puede poblar diferentes valores de event.outcome, de acuerdo con su perspectiva.

También tenga en cuenta que en el caso de un evento compuesto (un solo evento que contiene
múltiples eventos lógicos), este campo debe completarse con el valor que mejor capture el éxito o el
fracaso general desde la perspectiva del productor del evento.

Además, tenga en cuenta que no todos los eventos tendrán un resultado asociado. Por ejemplo, este
campo generalmente no se completa para eventos de métricas, eventos con event.type: info o
cualquier evento para el cual un resultado no tiene sentido lógico.
 Tipo: Keyword

Importante: el valor del campo debe ser uno de los siguientes:

failure, success, unknown

user.name Nombre corto o nombre inicio de sesión del usuario.

Tipo: keyword

Multi-fields:

user.name.text (tipo: Text)

Ejemplo: albert

Uncommon process fields

Este campo debe asignarse para mostrar datos de proceso poco comunes del host en la aplicación Elastic Security:

Nombre del campo ECS Descripción

process.name Nombre del proceso.

Tipo: palabra clave

Multi-fields:

process.name.text (tipo: Text)

Ejemplo: ssh

agent.type Tipo de agente.

El tipo de agente siempre permanece igual y debe ser proporcionado por el agente utilizado. En el
caso de Filebeat, el agente siempre sería Filebeat también si se ejecutan dos instancias de Filebeat
en la misma máquina.

Tipo: keyword

Ejemplo: filebeat

event.action La acción capturada por el evento.

Esto describe la información del evento. Es más específico que event.category. Algunos ejemplos son
agregar grupos, iniciar procesos, crear archivos. El valor lo define normalmente el implementador.

Tipo: keyword

Ejemplo: user-password-change

event.code Código de identificación para este evento, si existe.

Algunas fuentes de eventos utilizan códigos de eventos para identificar los mensajes de manera
inequívoca, independientemente del idioma del mensaje o de los ajustes de redacción a lo largo del
tiempo. Un ejemplo de esto es el ID de evento de Windows.

Tipo: keyword

Ejemplo: 4648

event.dataset Nombre del conjunto de datos.

Si una fuente de eventos publica más de un tipo de registro o eventos (por ejemplo, registro de
acceso, registro de errores), el conjunto de datos se usa para especificar de cuál proviene el evento.

Se recomienda, pero no es obligatorio, comenzar el nombre del conjunto de datos con el nombre del
módulo, seguido de un punto y luego el nombre del conjunto de datos.

Tipo: keyword

Ejemplo: apache.access
 event.module Nombre del módulo del que provienen estos datos.

Si su agente de monitoreo admite el concepto de módulos o complementos para procesar eventos de

una fuente determinada (por ejemplo, registros de Apache), event.module debe contener el nombre
de este módulo.

Tipo: keyword

Ejemplo: apache

process.args Array de argumentos del proceso, comenzando con la ruta absoluta al ejecutable.

Puede filtrarse para proteger la información confidencial.

Tipo: Keyword

Nota: este campo debe contener una array de valores.

Ejemplo: ["/usr/bin/ssh", "-l", "user", "10.0.0.16"]

user.id Identificador único del usuario.

Tipo: keyword

user.name Nombre corto o inicio de sesión del usuario.

Tipo: palabra clave

Campos múltiples:

user.name.text (tipo: Text)

Ejemplo: albert

Network fields

Nombre del campo ECS Descripción

destination.geo.* Campos que describen una ubicación

destination.ip Dirección IP del destino (IPv4 o IPv6).

Tipo: ip

source.geo.* Campos que describen una ubicación

source.ip Dirección IP de la fuente (IPv4 o IPv6).

Tipo: ip

destination.as.* Campos que describen un sistema autónomo (prefijo de enrutamiento de Internet).

destination.bytes Bytes enviados desde el destino al origen.

Tipo: long

Ejemplo: 184

destination.domain Dominio de destino.

Tipo: Keyword

source.as.* Campos que describen un sistema autónomo (prefijo de enrutamiento de Internet).

source.bytes Bytes enviados desde el origen al destino.

Tipo: long

Ejemplo: 184

source.domain Dominio de origen.

 Tipo:Keyword

DNS query fields

Nombre del campo ECS Descripción

dns.question.name El nombre que se consulta.

Si el campo del nombre contiene caracteres no imprimibles (por debajo de 32 o por encima de 126),
esos caracteres deben representarse como números enteros de base 10 de escape (\ DDD). Las
barras invertidas y las comillas deben omitirse. Las tabulaciones, los retornos de carro y los avances
de línea deben convertirse a \ t, \ r y \ n respectivamente.

Tipo: Keyword

Ejemplo: http://www.example.com

dns.question. El dominio registrado más alto, despojado del subdominio.

registered_domain
Por ejemplo, el dominio registrado para "foo.example.com" es "http://example.com ".

Este valor se puede determinar con precisión con una lista como la lista de sufijos públicos (http://publi
csuffix.org). Intentar aproximar esto simplemente tomando las dos últimas etiquetas no funcionará
bien para TLD como "co.uk".

Tipo: Keyword

Ejemplo: http://example.com

dns.question.type El tipo de registro que se consulta.

Tipo: Keyword

ejemplo: AAAA

HTTP request fields

Nombre del campo ECS Descripción

http.request.method Método de solicitud HTTP.

Tipo: palabra clave

Ejemplo: GET, POST, PUT, PoST

http.response.status_code Código de estado de respuesta HTTP.

Tipo: long

Ejemplo: 404

url.domain Dominio de la URL, como "http://www.elastic.co ".

En algunos casos, una URL puede hacer referencia a una IP y / o puerto directamente, sin un
nombre de dominio. En este caso, la dirección IP iría al campo de dominio.

Si la URL contiene una dirección IPv6 literal entre [y] (IETF RFC 2732), los caracteres [y] también
deben capturarse en el campo de dominio.

Tipo: palabra clave

Ejemplo: http://www.elastic.co

url.path Ruta de la solicitud, como "/búsqueda".

Tipo: keyword

TLS fields
 Nombre del campo ECS Descripción

tls.server.hash.sha1 Huella digital de certificado utilizando el resumen SHA1 de la versión codificada en DER del
certificado ofrecido por el servidor. Para mantener la coherencia con otros valores hash, este valor
debe formatearse como un hash en mayúsculas.

Tipo: palabra clave

Ejemplo: 9E393D93138888D288266C2D915214D1D1CCEB2A

tls.server.issuer Asunto del emisor del certificado x.509 presentado por el servidor.

Tipo: Keyword

Ejemplo: CN=Example Root CA, OU=Infrastructure Team, DC=example, DC=com

tls.server.ja3s Un hash que identifica a los servidores en función de cómo realizan un protocolo de enlace SSL /
TLS.

Tipo: keyword

Ejemplo: 394441ab65754e2207b1e1b457b3641d

tls.server.not_after Fecha que indica cuándo el certificado del servidor ya no se considera válido.

Tipo: fecha

Ejemplo: 2021-01-01T00: 00: 00.000Z

tls.server.subject Asunto del certificado x.509 presentado por el servidor.

Tipo: keyword

Ejemplo: CN=www.example.com, OU=Infrastructure Team, DC=example, DC=com

Política de backup:

Elastic cuenta con la capacidad generar copias de seguridad, a través la API Snapshot and Restore que proporciona un mecanismo de copia de
seguridad del clúster que toma el estado actual y los datos en el clúster y los guarda en un repositorio de file server para tal fin.

Para la solución se define tener un repositorio compartido a través de la red y que debe ser posible acceder a través de los pods, para que
puedan realizar el respectivo backup. Este repositorio tendrá la capacidad de almacenar la copia de seguridad de Elasticsearch.

Pre-requisitos:

Montar la carpeta compartida del files server en la misma ubicación en todos los nodos maestros y de datos.

Se va aplicar la siguiente configuración en la política de backup:

Policy name: fs-snapshot-policy-produccion

Snapshot name:
<fs-snapshot-diario-{now/d}>
<fs-snapshot-semanal-{now/d}>
<fs-snapshot-mensual-{now/d}>
Repository: fs-snapshots
Tipo de repositorio: Shared Filesystem.
Schedule diario: 0 0 1 1/1 * ? *
Schedule semanal: 0 0 1 ? * SUN *
Schedule mensual: 0 0 2 1 1/1 ?
Índices dentro de la copia de seguridad: todos los índices, incluyendo global state.
Snapshot retention:
Backup incremental diario que se retiene 7 días en disco.
Backup full semanal que se retiene por 30 días en disco.
Backup full mensual que se realiza el ultimo fin de semana del mes que se retiene por 1 año
Elastic genera el archivo/archivos de copia de seguridad y la herramienta definida por Claro para backup realiza la gestión de las
políticas.
Política de notificaciones:

Definición general: La política de notificaciones a aplicar en la solución de SIEM es la de Detección Activa, consiste en utilizar el
modulo de alertamiento de Elastic para desplegar un set de indicadores de compromiso (Reglas de detección) previamente definidos,
dichos indicadores de compromiso son diferentes a las provistas por defecto por el módulo de seguridad para evitar la presencia de
falsos positivos. El set de reglas de detecciones a utilizar consta de alrededor de 100 reglas, estas reglas serán provistas por el equipo
de ciberseguridad de Claro.
La arquitectura de dichas reglas no consta de agrupaciones, se prevé que cada regla de detección será asociada de manera
individual a un cliente de modo a que se tenga un control más organizado de dichos indicadores de compromiso.
Al ser realizada una detección se seguirá un set de acciones que son definidos en la guía de respuesta, dicha guía de
respuesta consta de todos los lineamientos, procesos y acciones que se deben llevar a cabo ante cualquier tipo de detección
por parte de los indicadores de compromiso.
La primera parte de dichas guías de respuesta consiste en el envió de notificaciones especificas para el soporte 7X24 de
ciberseguridad claro y el cliente al cual está asociada dicha regla.
Notificación por correo: Para configurar el envío de notificaciones por correo se necesita disponer de una cuenta de correo
proporcionada por Claro para fungir como conector entre Elastic y los correos de destino. Un conector es una entidad utilizada para
administrar las comunicaciones entre el alertamiento de Kibana y un correo o aplicación en específico.
El correo proporcionado por claro debe disponer de la verificación de 2 pasos y las credenciales especificas de acceso para su
configuración, adicionalmente las direcciones receptoras del equipo de Ciberseguridad y el cliente en específico.
Las características del correo deben ser las siguientes:
Verificación de 2 pasos activada.
En su defecto permitir que aplicaciones menos seguras tengan acceso a dicho correo en la configuración de nuestra
cuenta.
Correo y nombre de usuario de dicha cuenta.
Contraseña de acceso.
Creación de nuevas alertas: Se requiere la siguiente información para la construcción de las alertas requeridas por el área de
Ciberseguridad.
Condición
Programación
Acciones
Alerta.