Common Event Format изнутри

Один за одним производители программных и программно-аппаратных решений заявляют о получении сертификата, подтверждающего поддержку формата Common Event Format (CEF) компании HP ArcSight: Stonesoft, Tripwire, Citrix, Imperva, NetScout и еще несколько десятков вендоров…

Про SIEM

В соответствии с ежегодными отчетами Gartner, компания HP ArcSight (до сентября 2010 — ArcSight) уверенно держится в числе лидеров по разработке решений класса SIEM. Если кратко, то суть таких решений — собрать в одном месте сотни тысячи миллионы событий, генерируемых различными системами информационной безопасности, и произвести корреляционный анализ этих событий. Результатом корреляции являются инциденты безопасности, с которыми работает уже человек — администратор или оператор.

Каждый производитель SIEM-решений в своих рекламных брошюрах обычно указывает количество поддерживаемых источников событий. К примеру, заявляется, что ArcSight ESM поддерживает 300+ устройств и приложений, а у QRadar SIEM их «всего лишь» 200+. Кто там и как считает источники — сейчас неважно, поскольку в рамках данной статьи нас будет интересовать формат событий (журналов) информационной безопасности.

Про журналы

Каких-либо общих требований к структуре журналов и событий ИБ пока нет. Поэтому каждый разработчик оформляет журналы так, как ему удобнее.

Кто-то просто пишет их в текстовый файл, кто-то предоставляет возможность отправлять данные на Syslog-сервер. Одному хватает только SNMP, а другому хочется складывать все журналы в реляционную базу данных. Есть еще Microsoft с ее форматом .evt, есть CheckPoint с его OPSEC. И не забываем про SDEE.

Про проблему

И структура логов, и используемые для их передачи протоколы везде разные. С точки зрения интеграции с SIEM-решениями (и не только с ними), это — плохо. Потому что для унифицированной обработки логов их нужно нормализовать, т.е. привести к единому формату. В едином формате события проще хранить. Проще осуществлять поиск данных и формировать отчеты.

Нормализация подразумевает разбор событий (parsing) и сопоставление полей (mapping). Поэтому каждый коннектор между системой ИБ и SIEM-решением представляет собой приложение, которое парсит и маппит в соответствии со своими конфигурационными настройками.
Если у производителя SIEM нет поддержки нужного тебе продукта, значит придется выполнять конфигурационные настройки самому. Разрабатывать и тестировать регулярные выражения. Изучать структуру базы данных, осваивать SQL*Plus. Писать правила сопоставления. Грустить, в общем…

Предложенное решение

«Как было бы хорошо, если бы все производители систем ИБ отчуждали свои логи в понятном для всех виде» — подумали в ArcSight и в 2006 году представили на всеобщее одобрение обозрение разработанный ими формат CEF. На мой взгляд, в этом формате нет ничего сложного. Нужно выполнять всего несколько требований:

Требование №1 — В качестве транспорта используем Syslog

Тут, вроде бы, понятно.
Хочу — использую протокол UDP, хочу — TCP.

Требование №2 — Заполняем восемь обязательных полей

Разумеется, в начале сообщения должен присутствовать традиционный syslog header
Jan 18 11:07:53 host

А уже за ним — префикс CEF: и набор обязательных полей, разделенных символом "|"
CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|Extension

Здесь:

• Version — версия формата CEF
• Device Vendor, Device Product и Device Version — эти строки однозначно идентифицируют источник событий. Не существует продуктов, у которых будет одинаковый набор этих трех значений
• Signature ID — уникальный идентификатор типа события
• Name — понятное человеку описание события
• Severity — важность события (от 0 до 10)
• Extension — см. ниже

Требование №3 — Поле Extension заполняем в соответствии со словарем CEF

Поле Extension — это набор пар «ключ — значение». Приведу несколько ключей из словаря:

dmac — это Destination Mac Address (например, 00:0D:60:AF:1B:65)
spt — это Source Port (порт от 0 до 65535)
request — это Request URL (в случае с HTTP-request указывается URL-адрес)

В описании формата CEF словарь приведен полностью, с указанием типа данных по каждому ключу и максимально допустимого размера.

В конце документа приведены еще некоторые общие требования. В частности, для всего сообщения целиком должна использоваться кодировка UTF-8. Там же указаны правила оформления некоторых спецсимволов и многострочных записей.

В итоге, оформленное в точном соответствии с форматом CEF сообщение должно выглядеть примерно так:
May 29 15:26:33 host CEF:0|McAfee|Antivirus|5.2|100|worm successfully stopped|10|src=10.0.0.1 dst=2.1.2.2 spt=1232

В чем выгода?

1. Подключение нового источника событий превращается в «plug and play»
2. Снижается нагрузка на саму SIEM-систему
3. Производители SIEM-решений больше не меряются количеством поддерживаемых источников и уделяют больше внимания другим аспектам (юзабилити продукта, его отказоустойчивость и т.п.)
4. И вообще, этот формат придумали не только для SIEM. Его уже применяют и в других решениях, связанных с обработкой логов.