Версия: 4.2

Миграция на ECS

ECS (Elastic Common Schema) - спецификация, разработанная сообществом пользователей Elastic. ECS определяет общий набор полей при хранении данные о событиях в OpenSearch.

Использование ECS позволяет:

нормализовать свои данные о событиях для последующего анализа и визуализации этих данных, представленных в событиях
унифицировать данные для уменьшения трудозатрат в дальнейшем (максимизация совместимости и повторное использование, например, использование разработанных дашбордов со стороны без дополнительной адаптации)
ускорение работы OpenSearch в целом за счёт правильного распределения типов данных каждому полю

Подробнее можно узнать в официальной документации. Все описанное ниже актуально для версии 8.6.0.

Обратите внимание!

В данном руководстве рассматривается версия ECS 8.6.0. В Logstash 8.х версии ECS включен по умолчанию и соответствует версии v8, но вы можете при необходимости отключить данную функцию. При использовании версии 7.x по умолчанию ECS отключен, допускается использование версии v1. При обновлении до актуальной версии не рекомендуется выставлять режим v1, так как возможен конфликт именования полей который встроен в версии v8, в таком случае конвейер Logstash не запустится.

Уровни поля ECS

В ECS поля можно разделить на:

базовые (основные) (core fields) - относятся поля, которые подходят для любого источника данных. Например, @timestamp, tags, message и другие. В первую очередь требуется заполнять именно эти поля.
дополнительные - относятся остальные поля, чаще используются в более узких вариантах или могут быть открытыми в интерпретации. Есть вероятность, что в будущем могут быть изменены

Соглашения и правила ECS

Общие соглашения

Для типа данных integer(целые числа) в рамках ECS использовать тип long
для полей ID и кодов (например, код ошибки) использовать тип keyword
для текстового поля или мульти-поля
соглашение по умолчанию для Elasticsearch для текстовых полей, поле text индексируется дважды:
соглашение для ECS меняет подход, почти все текстовые поля имеют тип keyword за некоторым исключением. Если требуется полнотекстовый поиск, то допускается добавить мульти-поле (multi-field)
поля исключения, которые должны индексироваться для полнотекстового поиска

Шаблоны реализации

Base fields - базовые поля, группа индивидуальных полей верхнего уровня за пределами набора
host - содержит различные поля, относящиеся к устройству где произошло событие, может быть компьютером, виртуальной машиной, контейнером или облачным сервером
Agent и observer - агент и наблюдатель. Агент - это ПО, которое собирает, наблюдает, измеряет или обнаруживает событие. Примером агента является ElasticBeat. Наблюдателем является внешний мониторинг или устройство-посредник, например, firewall, APM server, web proxy.
Timestamp - каждое событие должно иметь временную метку, некоторые события также имеют дополнительные временные метки, следующие хронологическому порядку @timestamp < event.created < event.ingested:
Origin - определённые поля для фиксации места возникновения события
Categorization - классификация полей ECS (подробнее смотрите ниже)
Enrichting events - наполнение событий дополнительной информацией, в ECS есть много таких полей, которые можно добавить к событию
Lookups
Parsing
Related fields - связанные поля. Многие события имеют различные поля с идентичным содержимым, например, IP адрес, hash файла, имя хоста. Для обращения к таким полям используйте related.* поля, например, если для некоторого события IP есть в полях host.*, source.*, destination.*, добавьте все адреса в поле related.ip для удобства дальнейшего поиска

Обработка сетевых событий

Здесь расположены рекомендации по обработке событий, связанных с сетью. Подробнее можно посмотреть на официальной странице документации.

Проверка наличия источника и назначения - если событие содержит информацию об источнике и принимающей стороне, то эти поля (source.* и destination.*) заполняются в первую очередь. Некоторые события могут указывать на роли каждого хоста (client и server), их стоит заполнять дополнительно к полям источника и назначения, т.е. поля из source.*/destination.* должны быть скопированы в client.*/server.*. Это важно заполнять для дальнейшей фильтрации по ролям или по источнику/назначению.
Заполняйте связанные поля, все IP адреса добавляйте в поле related.ip в качестве массива, также в сетевых событиях могут встречаться имена хостов, их тоже надо скопировать в related.hosts
Заполните поля категоризации, которые лучше всего характеризуют событие
Сочетание полей категоризации "event.category: network" и "event.type: protocol" требуют заполнения также поля network.protocol
при желании исходные поля можно сохранить как custom поля, например, для NGINX - Nginx.*

Принципы проектирования ECS

Общая схема - главная цель ECS это максимизировать совместимость и повторное использование
Поля устанавливают наборы имён - старайтесь разбить сложные концепции на более простые, например, dns.question.class, dns.question.answer, dns.question.type
Согласованность наименования - не ограничивайте термины с широким значением одним случаем, например:
Повторное использование
Custom fields - пользовательские поля во многих ситуациях потребуется создавать для полного описания события, но добавляйте их только если отсутствует соответствующее поле в концепции ECS

Поля классификации ECS

ECS предоставляет 4 уровня категоризации для общего описания независимо от источника событий. Для начала рассмотрите основные принципы классификации:

похожие события, которые можно рассматривать и анализировать вместе должны попадать в одно поле event.category
event.category и event.type являются массивами, поэтому старайтесь отнести событие ко всем относящимся категориям
должны использоваться только предопределённые значения, описанные ниже
event.outcome очень ограничен для использования результата события, действия зависящие от предметной области, например, запрет или разрешение, которые могут считаться результатами, должны фиксироваться в полях event.type и/или event.action, например, событие блокировки доступа, со стороны сетевого экрана событие успешно (event.outcome: success), но сам результат выполнения - отброшен (event.action: dropped)
значения event.category, event.type, event.outcome одинаковы для всех значений event.kind
если конкретное событие не соответствует ни одному из предопределённых значений классификации, поле следует оставить пустым

Рассмотрим 4 уровня классификации, представленные в виде поля, более детально.

`event.kind` - высший уровень категоризации события

Данное поле дает информацию о том, какой тип информации содержит событие, без явного указания содержания этого события. Значение этого поля можно использовать для информирования о том, как следует обрабатывать события такого рода. Должно содержать только одно из значений:

alert - событие реагирования на какое-то действие из вне, например, события сетевого экрана, обнаружение нового хоста, вход пользователя и др.
enrichment - события, содержащие дополнительный контент часто к уже существующему событию
event - используется для событий, указывающих на то, что что-то произошло
metric - указывается для описания числового измерения, выполненное в данный момент времени. Например, загрузку ЦП, использование памяти и др. Часто собираются с определённой частотой, например, раз в минуту.
state - похожее на событие метрики, тоже собирается с определённым интервалом, но содержит одно из фиксированных значений, например, closed, opened. Но обратите внимание, что само событие изменения состояния должно быть описано в event, поскольку изменение состояния соответствует более общему определению события
pipeline_error - указывает на то, что во время приёма события произошла ошибка, данные о событии могут отсутствовать или быть не верными. Часто связан с ошибками синтаксического анализа
signal - зарезервированное значение поля, используется решениями Elastic, например, security, observability для событий предупреждений, созданные правилами в среде уведомлений Kibana.

`event.category` - второй уровень категоризации события

Фильтрация по этому полю позволяет классифицировать исходные события по согласованным значениям. Это поле представляет собой массив, по значениям которого можно настраивать парсинг для различных источников. Значение тесно связано с третьим уровнем категоризации. Должно быть одним из следующих значений:

authentication - события, связанные с запросом и ответом, в котором учётные данные предоставляются и проверяются, например, события журнала Windows или журнала ssh. Ожидаемые типы категорий для третьего уровня категоризации: start, end, info
configuration - события связанные с конфигурациями - создание, изменение, удаление параметров процесса, приложения, системы. Например, журналы изменений политики безопасности, аудита конфигурации, мониторинг целостности системы. Ожидаемые типы категорий для третьего уровня категоризации: access, change, creation, deletion, info
database - события, относящиеся к системам хранения и поиска данных, причем не только реляционных. Например, логи MSSQL, PostgreSQL и др. Ожидаемые типы категорий для третьего уровня категоризации: access, change, info, error
driver - события связанные с драйверами устройств ОС и аналогичными программными продуктами, например, драйверы Windows, расширения ядра, модули ядра и др. Ожидаемые типы категорий для третьего уровня категоризации: change, end, info, start
email - события связанные с электронной почтой: сообщениями, вложениями и события, сетевой активностью, используемые протоколы. Например, сообщения почтового сетевого экрана, сообщения облачного сервиса почтового и др. Ожидаемые типы категорий для третьего уровня категоризации: info
file - события, относящиеся к созданной или существующим в файловой системе, используется для визуализации и анализа создания, доступа и удаления файлов, причем включая сетевые источники, например передача файлов Zeek file.log. Ожидаемые типы категорий для третьего уровня категоризации: change, creation, deletion, info
host - события визуализации или анализа информации инвентаризации хоста или события жизненного цикла хоста, например, в основном это события, наблюдаемые из вне, на самом хосте можно увидеть события start и end. Обратите внимание, что в этой категории события для информации о самих хостах и не предназначено для отслеживания активности происходящей на самом хосте. Ожидаемые типы категорий для третьего уровня категоризации: access, change, end, info, start
iam - события управления идентификацией и доступом (IAM), относящиеся к пользователям, группам и администрированию, например, для визуализации и анализа Active Directory, LDAP, Okta, Duo и других IAM. Ожидаемые типы категорий для третьего уровня категоризации: admin, change, creation, deletion, group, info, user
intrusion_detection - события обнаружения вторжений из систем и функций IDS/IPS, например, визуализация и анализ предупреждений об обнаружении вторжений из систем Snort, Suricata, Palo Alto и др. Ожидаемые типы категорий для третьего уровня категоризации: allowed, denied, info
malware - события обнаружения вредоносного ПО, например, антивирусы Kaspersky, Dr. Web, Elastic Endpoint Security и др. Ожидаемые типы категорий для третьего уровня категоризации: info
network - события, относящиеся к любой сетевой активности, включая жизненный цикл сетевого подключения, сетевой трафик и практически любое событие, включающее IP адрес, например, используются для визуализации и анализа количества сетевых портов, протоколов, адресов, геолокации. Ожидаемые типы категорий для третьего уровня категоризации: access, allowed, connection, denied, end, info, protocol, start
package - события, относящиеся к пакетам ПО, установленного на хостах, может также использоваться для определения уязвимости хоста при отсутствии данных сканирования уязвимостей. Ожидаемые типы категорий для третьего уровня категоризации: access, change, deletion, info, installation, start
process - события, относящиеся к визуализации и анализу информации о процессе, например, события жизненного цикла и происхождение процесса. Ожидаемые типы категорий для третьего уровня категоризации: access, change, end, info, start
registry - события, связанные с настройками и активами, хранящиеся в реестре Windows, например, доступ к реестру и его изменения. Ожидаемые типы категорий для третьего уровня категоризации: access, change, creation, deletion
session - события и метрики, касающиеся логических постоянных подключений к узлам и службам, например, сюда можно отнести данные из событий Windows, ssh, или сеансов без сохранения состояний типа cookie HTTP и др. Ожидаемые типы категорий для третьего уровня категоризации: start, end, info
threat - события для визуализации и анализа событий, описывающих цели и мотивы или поведение субъектов угроз. Ожидаемые типы категорий для третьего уровня категоризации: indicator
vulnerability - события результатов сканирования уязвимостей., например, Tenable, Qualys, сканеры уязвимостей и др. Ожидаемые типы категорий для третьего уровня категоризации: info
web - события доступа к web серверу, используется для анализа активности web сервера, прокси таких как IIS, nginx, Apache и др. Ожидаемые типы категорий для третьего уровня категоризации: access, error, info

`event.type` - третий уровень категоризации события

Представляет собой массив значений, которые при совместном использовании с полем event.category позволит классифицировать события, которые могут относиться к различным типам событий. Позволяет категоризировать и фильтровать события для одиночной визуализации. Также представляет собой массив значений как и event.category. Должен быть одним из следующих значений:

access - доступ к чему-либо, для дополнительного разделения событий можно использовать поле event.action
admin - тип административного события, используется для событий связанных с административными объектами, например, изменения в структуре IAM не влияющие на пользователя или группу, для дополнительного разделения событий можно использовать поле event.action
allowed - события указывающие на то, что что-то было разрешено. Для дополнительного разделения событий можно использовать поле event.action
change - события указывающие, что что-то было изменено. Для дополнительного разделения событий можно использовать поле event.action
connection - события сетевого трафика, включающего анализ потока или соединения. События должны включать как минимум IP адреса источника и получателя, TCP/UDP порты и содержат количество переданных байтов, пакетов. Обратите внимание, что события межсетевого экрана следующего поколения тоже попадают в эту категорию. Для дополнительного разделения событий можно использовать поле event.action
creation - события, указывающие что что-то было создано
deletion - события, указывающие что что-то было удалено
denied - события, указывающие что что-то было отклонено, например, события сетевого экрана. Для дополнительного разделения событий можно использовать поле event.action
end - события указывающие что что-то закончилось
error - события, описывающие ошибку. Обратите внимание, что для ошибок работы самого pipeline стоит использовать event.kind: pipeline_error
group - события связанные с групповыми объектами. Для дополнительного разделения событий можно использовать поле event.action
indicator - события индикатора компрометации (IOCs)
info - события информации, не несущее информацию изменения состояния или действия
installation - события указывающие на то, что что-то было установлено
protocol - события сведения о протоколе или анализе. Обратите внимание, что события содержащие только имя протокола или его идентификатор не должны использовать данный тип
start - события, указывающие на то, что что-то началось
user - события, связанные с пользовательскими объектами. Для дополнительного разделения событий можно использовать поле event.action

`event.outcome` - нижний уровень категоризации события

Данное поле можно использовать как флаг, описывающий успех или неудачу со стороны объекта, вызвавшего событие. Стоит обратить внимание, что при использовании цепочек событий для описания одной транзакции каждое событие может иметь различное значение данного поля со стороны объекта. Также в случае составного события лучше для каждого события использовать конечный результат. Данное поле не заполняется для событий метрик, информационных событий, а также событий, для которых результат не имеет логического смысла. Должен принимать одно из следующих значений:

failure
success
unknown - указывает на события, результат которого не известен с точки зрения производителя события. Например, если событие содержит только информацию об отвечающей стороне запроса транзакции. Не стоит использовать это значение, когда результат не имеет логического смысла - в таких случаях это поле не следует заполнять.

Справочник по полям ECS

Как было сказано выше, поля классифицируются на базовые и расширенные. Справочник по полям определяет несколько "групп", которые называются наборами полей, например, Base, Agent, Device, DNS и др. Речь пойдет о расширенных полях. Ознакомиться с набором полей можно в официальной документации.

В каждом событии в корне может быть несколько объектов (наборы полей) и базовые поля

Для различных типов данных в ECS определяются группы связанных полей. Все наборы полей определяются как объекты в Elasticsearch, внутри которых определяются все поля, исключением являются базовые поля (Base), которые располагаются в корне события. Рассмотрим пример https://www.elastic.co/guide/en/ecs/current/ecs-http.html. Рассмотрим пару полей, ознакомится с остальными можно по указанной ссылке.

В данном примере описаны поля HTTP запроса. В данном случае, http - объект в Elasticsearch, а оставшаяся часть - определенный набор полей по ECS.

Т.е., например, http - объект ES, request.body.bytes - именование поля в котором содержатся указанные данные.