Presentamos el Elastic Common Schema (ECS), una nueva especificación que proporciona una manera coherente y personalizable de estructurar tus datos en Elasticsearch y facilitar el análisis de datos de diferentes fuentes. Con ECS, el contenido de analíticas, como los dashboards y los trabajos de Machine Learning, pueden aplicarse de manera más amplia, las búsquedas pueden diseñarse de manera más limitada y los nombres de campo son más fáciles de recordar.

¿Por qué un esquema común (Common Schema)?

Ya sea que estés haciendo un análisis interactivo (por ejemplo, búsqueda, exploración profunda con dinamización, visualización) o un análisis automatizado (por ejemplo: alertas, detección de anomalías basada en Machine Learning), debes poder examinar tus datos de manera uniforme. Sin embargo, a menos que tus datos se originen en una sola fuente, te enfrentarás a incoherencias de formato, que son el resultado de lo siguiente:

Tipos de datos dispares (por ejemplo: logs, métricas, APM, flujos, datos contextuales)
Entornos heterogéneos con diversos estándares de proveedores
Fuentes de datos similares, pero diferentes (por ejemplo: fuentes múltiples de datos del punto de conexión, como Auditbeat, Cylance y Tanium)

Imagina que buscas un usuario específico entre los datos que se originan de fuentes múltiples. Solo para buscar este campo, es probable que debas tener en cuenta varios nombres de campo, como el usuario, el nombre de usuario, nginx.access.user_name y el inicio de sesión. Hacer una búsqueda profunda y optimizar esos datos presentaría un desafío aún mayor. Ahora, imagina el desarrollo de contenido de analíticas, como una visualización, una alerta o un trabajo de Machine Learning: cada nueva fuente de datos agregaría complejidad o duplicación.

¿Qué es el Elastic Common Schema?

ECS es una especificación de open source que define un conjunto común de campos de documentos para los datos ingestados en Elasticsearch. ECS está diseñado para admitir modelos de datos uniformes, lo que le permite analizar de forma centralizada datos de diversas fuentes con técnicas interactivas y automatizadas.

ECS ofrece tanto la previsibilidad de una taxonomía especialmente diseñada como la versatilidad de una especificación inclusiva que se adapta a casos de uso personalizados. La taxonomía de ECS distribuye elementos de datos en campos que están organizados en estos tres niveles:

Nivel	Descripción	Recomendación
Campos centrales de ECS	Conjunto de nombres de campo totalmente definido que existe bajo un conjunto definido de objetos de nivel superior de ECS	Estos campos son comunes a la mayoría de los casos de uso, por lo que el trabajo debe comenzar aquí
Campos extendidos de ECS	Conjunto de nombres de campo parcialmente definido que existe bajo el mismo conjunto de objetos de nivel superior de ECS	Los campos extendidos pueden aplicarse a casos de uso más limitados o estar más abiertos a la interpretación según el caso de uso
Campos personalizados	Conjunto de campos sin definir y sin nombrar que existe bajo un conjunto de objetos de nivel superior proporcionado por el usuario, que no son de ECS ni deben entrar en conflicto con los campos u objetos de ECS	Aquí es donde puedes agregar campos para los que ECS no tenga un campo correspondiente; aquí también puedes guardar una copia de los campos de eventos originales, como cuando haces la transición de tus datos a ECS

Elastic Common Schema en acción

Ejemplo 1: Análisis

Pongamos a ECS a trabajar en el siguiente log de Apache:

10.42.42.42 - - [07/Dec/2018:11:05:07 +0100] "GET /blog HTTP/1.1" 200 2571 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"

El mapeo de este mensaje a ECS organiza los campos del log de la siguiente manera:

Nombre del campo	Valor	Notas
@timestamp	`2018-12-07T11:05:07.000Z`
ecs.version	`1.0.0`
event.dataset	`apache.access`
event.original	`10.42.42.42 - - [07/Dec ...`	Log completo y sin modificaciones para auditorías
http.request.method	`get`
http.response.body.bytes	`2571`
http.response.status_code	`200`
http.version	`1.1`
host.hostname	`webserver-blog-prod`
message	`"GET /blog HTTP/1.1" 200 2571`	Representación de texto de la información significativa del evento para una visualización precisa en un visualizador de logs
service.name	`Company blog`	Tu nombre personalizado para este servicio
service.type	`apache`
source.geo.*		Fields for geolocation
source.ip	`10.42.42.42`
url.original	`/blog`
user.name	`-`
user_agent.*		Campos que describen al agente usuario

Como se muestra arriba, el log sin procesar se preserva en el campo event.original de ECS para admitir casos de uso de auditorías. Además, ten en cuenta que por una cuestión de simplicidad, en este ejemplo se omiten algunos detalles sobre el agente de monitoreo (en el campo agent.*), algunos detalles sobre el host (en el campo host.*) y algunos campos más. Para obtener una representación más completa, revisa este evento de ejemplo en JSON.

Ejemplo 2: Búsqueda

Piensa en una investigación sobre la actividad de una IP específica a través de una pila web completa: Un firewall de Palo Alto Networks, HAProxy (como lo procesa Logstash), Apache (mediante el módulo Beats), Elastic APM y además, Suricata IDS (personalizado, con su formato EVE JSON).

Antes de ECS, tu búsqueda para esta IP podría haberse visto así:

src:10.42.42.42 OR client_ip:10.42.42.42 OR apache2.access.remote_ip:10.42.42.42 OR context.user.ip:10.42.42.42 OR src_ip:10.42.42.42

Pero si has mapeado todas tus fuentes a ECS, tu búsqueda es mucho más simple:

source.ip:10.42.42.42

Ejemplo 3: Visualización

El poder de ECS se revela de forma más fácil al ver cómo se puede aplicar a datos uniformemente normalizados de diversas fuentes de datos. Quizás estás monitoreando tu pila web en busca de amenazas con varias fuentes de datos de red: un firewall de Palo Alto de la nueva generación en el perímetro y los eventos y alertas de generación de Suricata IDS. ¿Cómo extraes los campos source.ip y network.direction de cada mensaje de manera tal que permita la visualización centralizada en Kibana y una exploración profunda con dinamización independiente? Con ECS, por supuesto, que te permite hacer un monitoreo centralizado con más facilidad que nunca.

Búsqueda de direcciones IP en Kibana mediante Elastic Common Schema

Búsqueda de IP 10.42.42.42

Beneficios del Elastic Common Schema

La implementación de ECS unifica todos los modos de análisis disponibles en el Elastic Stack, incluida la búsqueda, la exploración profunda con dinamización, la visualización de datos, la detección de anomalías basada en Machine Learning y las alertas. Una vez que se adopta completamente, los usuarios pueden hacer búsquedas con el poder de los parámetros de búsqueda estructurados y no estructurados. Además, ECS optimiza tu capacidad de correlacionar automáticamente los datos de diferentes fuentes, ya sea de dispositivos diferentes de un solo proveedor o de tipos de fuentes de datos completamente diferentes.

ECS también reduce la cantidad de tiempo que tu equipo dedica al desarrollo de contenido de analíticas. En lugar de crear nuevas búsquedas y dashboards cada vez que tu organización agregue una nueva fuente de datos, podrán continuar aprovechando sus búsquedas y dashboards existentes. ECS también le facilitará enormemente a tu entorno la adopción de contenido de analíticas directamente de otras partes que usan ECS, ya sea Elastic, un socio o un proyecto de open source.

Al hacer un análisis interactivo, ECS hace que sea más fácil recordar nombres de campo usados comúnmente, ya que hay un solo conjunto, en lugar de un conjunto diferente para cada fuente de datos. Con ECS, también es más fácil deducir nombres de campo olvidados, porque (salvo pocas excepciones) la especificación sigue una convención de nomenclatura simple y estándar.

¿No quieres comenzar a adoptar ECS? No hay problema: estará aquí cuando lo necesites, pero no será un requisito si no lo necesitas.

Primeros pasos con el Elastic Common Schema

ECS está disponible para revisión a través de un repositorio público de GitHub. Actualmente, la especificación está en versión Beta2 y pronto estará disponible para el público en general. Está publicado bajo la licencia de open source de Apache 2.0, lo que permite la adopción universal por parte de la comunidad de Elastic en general.

Suena automágico, ¿verdad? Bien, como con cualquier esquema, la implementación de ECS no es una tarea trivial. Pero si ya has configurado una plantilla de índice de Elasticsearch y has escrito algunas funciones de transformación con el nodo de ingesta de Logstash o Elasticsearch, tendrás cierta noción de lo que esto implica. Las versiones futuras de los módulos Elastic Beats producirán eventos con el formato de ECS de manera predeterminada y optimizarán esta parte de la transición. El nuevo módulo de sistemas para Auditbeat es el primero de muchos.

Para obtener más información sobre ECS, puedes ver nuestro seminario web Elastic Common Schema (ECS). En próximos artículos del blog, veremos cómo mapear tus datos a ECS (incluidos los campos que no están definidos en el esquema) y las estrategias para migrar a ECS.

Elastic for

App Search

Site Search

Enterprise Search

APM

Logs

Infrastructure

SIEM

Maps

Uptime

Articles By Mark Settle

Presentamos el Elastic Common Schema

Be in the know with the latest and greatest from Elastic.