Руководство по формату событий для разработчиков программного обеспечения в целях полноценного логирования и интеграции с любыми системами SIEM (Security information and event management) и LM (log management).

1. support@rusiem.com
https://rusiem.com
Руководство по
формату событий
(для разработчиков
программного обеспечения)
Версия 1, август 2018

2. • Данное руководство не является стандартом
• Все изложенные мысли основаны на опыте работы с различными
форматами и источниками, подключении их к системам
централизованной обработки событий
• Используя настоящее руководство, вы сможете создать
универсальный транспорт и формат событий в вашем продукте,
способный быстро интегрироваться и отвечать современным
потребностям пользователей. Не важно с каким SIEM/LM.
3
Лучше сделать изначально правильно, чем потом переделывать впопыхах.

3. Зачем логирование
• Ваше оборудование и программное обеспечение не может говорить с
пользователями
• Через события система общается с пользователями (операторами).
Рассказывает что с ней происходит, что происходит вокруг, что она
видит
• Это не только события об ошибках, но и:
• аудит (кто входит, кому права доступа предоставляются, кто обращается за
данными или записывает их)
• Сообщения о том, что обнаружила система
• Что делает или не смогла сделать система
• Вывод показателей и статистических данных
• Прочие результаты работы системы
4

4. Частота
• Насколько быстро вы бы хотели узнать что вашу машину угоняют?
Примерно также оценивайте насколько часто писать события.
• События нужно поставлять в журнал/на стрим в режиме близком
к реальному времени.
• Следует отталкиваться от критичности данных
• Скорее всего, нет необходимости в таких событиях, которые
нужно собирать всего лишь раз в сутки
• Если вы только пишете события в журнал событий, то будьте
готовы к частым обращениям за этими событиями. Чтобы потом
не кричать «наше API можно дергать только раз в 5 минут!».
5

5. Зачем нужно придерживаться форматов и
рекомендаций
• Ваши потребители рано или поздно будут читать ваши события
• События в современных системах отправляются на SIEM/LM системы, которые
позволяют:
• Своевременно определять неработоспособность системы
• Снимать статистически показатели для различных целей
• Обрабатывать автоматически события, предупреждая пользователей инцидентами в
режиме реального времени о различных угрозах
• Использовать для расследования инцидентов и предотвращения их в дальнейшем
• Разработчикам для отладки и понимания ситуации также необходимы журналы
событий
• У заказчиков в инфраструктуре десятки и сотни тысяч различных систем и при этом
он должен быть в курсе происходящего, держать руку на пульсе и своевременно
восстанавливать работоспособность, предотвращать угрозу
• Для разработчика ПО и заказчика подключение сбора событий в SIEM/LM систему
должно производится просто, в формате plug-and-play. К любой SIEM системе.
6

6. Зачем следовать формату событий
• Вы бы хотели работать с выборками данных, где, к примеру, в поле “balance”
периодически попадались не только цифры вашего баланса, но и
назначения платежей, какие то цифровые идентификаторы?
• Современные потребности предполагают, что пользователь работает с
событиями не в текстовом редакторе или вашем интерфейсе продукта, а в
централизованных системах, где агрегированы сотни миллионов событий с
тысяч различных гетерогенных систем – SIEM/LM
• Централизованный сбор подразумевает и обработку поступающих событий
– нормализацию (приведение к общему формату) и корреляцию
• Работая с выборками событий и выбирая, к примеру, src.ip:”172.16.0.1” или
user.id:”93411”, пользователь ожидает, что будут отображены события
касающиеся этих значений как по логам вашей системы, так и по логам из
других систем
7

7. Что такое событие
• Элементарное, минимальное сообщение, содержащее текст,
набор ключей и сопоставленных значений, повествующее о
каком либо произошедшем факте. Это как минимальное
повествовательное предложение.
• Рекомендуемый размер событий: 10-300 байт
Плохой пример:
• Xml формат, размер событий до 10 MB
8

8. Пример
• Размер отчета о результате сканирования – 10 MB. Но его можно
разбить на элементарные составляющие, отдельные события с
фактами. Например, событие повествующее что открыт 22 порт:
Aug 29 05:01:03 adm.local nmap: hops=1, ip=172.16.0.227,
hostname=, mac=00:00:16:8С:BA:B7, open_port=22, port_proto=tcp,
port_service=ssh, port_description=(protocol 2.0)
9

9. Структура событий
10
Aug 29 11:57:01 adm kernel: [3589265.332265] iptables: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:9f:ef:c1:08:00
SRC=172.16.0.137 DST=172.16.0.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=17538 PROTO=UDP SPT=137
DPT=137 LEN=58
Aug 29 11:57:02 adm postfix/qmgr[2240]: 4FEC26A1158: from=<root@rusiem.local>, size=548, nrcpt=1 (queue
active)
Шапка событий, одинаковая в
рамках источника
Специфичные заголовки
источника, как правило
содержащие источник,
процесс, PID
Тело события, выделяем
в message (RAW).
Разделитель

10. Ужасный пример из mq: Raw + нормализованное в json формате
11

11. Пример raw события Windows event log
12
• Событие приходит с нашего агента RuSIEM. Получено с помощью tcpdump.
• Еще не обработано нормализацией
• Присутствуют rtn разделители
• Формат json
• Основное тело оригинального события обрамлено в json поле message
• Присутствует ключ-значение “module”:”msevt” идентифицирующее что это событие с windows event log

12. Обязательные поля в событии
• Дата возникновения события (факта)
• Имя хоста
• Маркер в событии, характеризующий что это событие от вашего
ПО
13

13. Рекомендуемые поля в событии
• Дата возникновения события (факта)
• Имя хоста где сформировано событие
• IP хоста где сформировано событие
• Маркер в событии, характеризующий что это событие от вашего
ПО
• Категория
• Критичность
• Тело события (текст + key:value)
14

14. Служебные поля событий
Нельзя использовать следующие именования полей:
• host
• hostname
• timestamp
• @timestamp
• event.time (запись с точкой в виде строки и json формат
“event”:{“time”})
• message
15

15. W7 методология
• Несмотря на минимализм каждого события, рекомендуем хорошую
идеологию для полноты события c времен IBM Tivoli SIEM:
1. Who
2. did What
3. When
4. Where
5. Where from
6. Where to
7. on What
16

16. Кто собирает и использует ваши события
• Администраторы в случае ошибок и сбоев
• SIEM/LM системы для аудита (процессов, сети, пользователей,
трафика, расширенного мониторинга)
• SIEM/LM для выявления сбоев, аномалий
• SIEM/LM и статистические системы – статистика и тенденции
• Для интеграции с другими системами
• Системы мониторинга для автоматического восстановления
работоспособности сервиса
• Для расследования инцидентов (в том числе в судах)
• В целях соответствия стандартам и требованиям регуляторов
17

17. Рекомендуемые категории для журналов
событий от вашего приложения
• Состояние системы (ошибки, сбои, перезагрузка, метрики)
• Изменения конфигураций (кто, когда, как, что)
• Управление правами, ролями, пользователями и группами
• Авторизация и аутентификация
• Доступы (кто, откуда, к чему)
• Детализация и категории событий должны определяться в
настройках.
18

18. События вашего приложения
• Позвольте пользователю выбирать – какие события/категории
• Используйте Severity/Facility если категории и типы события не
возможны
• Типы данных определяются возможностями вашего ПО
• Представьте, что пользователь не заглядывает в консоль вашего
ПО. Он смотрит только события удаленно в SIEM/LM.
Ориентируйтесь исходя из этого.
• Пишите простые и в то же время полноценные понятные события
• Используйте W7 методологию
19

19. Записывать и(или) отправлять
• Хранение. Ваше программное обеспечение пишет лог (в режиме,
близком к реальному времени), коннекторы SIEM/LM забирают
их
• Стриминг. Ваше ПО пишет и имеет возможность отправки логов в
режиме реального времени
Плохие примеры:
• Чтобы собрать события, нужно запустить скрипты/команды (MS
Exchange)
• Сброс логов через длинные интервалы времени
20

20. Лучшие транспорты логирования
• Текстовый лог
• Syslog
• Windows event log (кастомные логи)
21

21. Могут также использоваться
• Ваше API с определенным форматом
• WMI
• ODBC
• MQ
• SQL (TDS)
• Oracle (TNS)
• SDP
• Таблица/представление в базе данных
• Журналы событий на ftp
• прочие
22

22. Нюансы по файловым логам
Именования журналов:
• С одним именем
• С постфиксом в виде даты (например, error-29082018.log)
• Внимание! При записи в один и тот же файл и его ротации необходимо как
то сообщать сторонним его читателям, что файл был очищен. Например,
меняя его дату создания.
• Учитывайте права доступа. Много ошибок, когда нельзя сменить права для
читателя без нарушения работоспособности.
• Учитывайте в коде права доступа к файлам! Встречаются ошибки
разработчиков, когда при отсутствии доступа к лог файлу ваше ПО перестает
работать вовсе!
• Не используйте монопольный доступ к файлу журнала событий
23

23. Нюансы по API и событиям в БД
• Не мешайте в одной куче события различных категорий.
Например, события о вирусах, события об установке ПО, события
об обновлении.
• Указывайте для каждого события возрастающее уникальное
значение.
• Сортируйте на своей стороне события по убыванию
• Будьте готовы по производительности. Ваше api будут опрашивать
на предмет новых логов каждые 10-20 секунд
24

24. API: хорошо и плохо
• Хорошо:
• Пример – доступ к логам Windows. Рабочих станций и серверов много в
инфраструктуре. Установка агента или скрипта означает что добавляются
промежуточные звенья – необходимо следить есть ли сбор или нет. И
пользователь может это отключить.
• Закрытая платформа, внутрь которой нельзя что то установить или получить
доступы к файлам.
• Плохо:
• Сервер СКУД/мониторинга на *nix/Windows платформе, имеющий 500 EPS
(events per second) и слабое аппаратное оборудование.
• API, имеющая задержку в отдаче событий по запросу более 2-4х секунд.
• API, с которой интегрированы реалтаймовые сервисы и попутно
предназначенная для выдачи событий.
25

25. Недостатки W3C/csv форматов
• Как правило, парсеры настроены жестко к значению в
последовательности. То есть, парсер ждет в 5 по порядку поле src.ip.
• Парсеры игнорируют шапку, в которой иногда прописаны поля
• Современные системы предполагают возможность добавления каких
либо полей. Добавляется поле, ломается последовательность и в
пятом поле уже не src.ip, а src.user.name.
• Csv логи плохо воспринимаются при просмотре, зато хорошо
импортируются в Excel.
• Как правило, в csv формате отсутствуют именования ключей, что
затрудняет парсинг
26

26. Плохой пример API и журналов в БД
• В одно и то же поле пишутся попеременно имя хоста, ip адрес,
код или иное значение
• Через API передаются несортированные события по дате или
уникальному возрастающему значению
• Строка в БД полностью перезаписывается, а не формируется
новая с новым событием
• Значения в строках БД событий перезаписываются, либо
перезаписываются значения
27

27. Плохие примеры транспортов
• Специфические транспорты (например, CheckPoint LEA)
• Требующие библиотек или SDK для разработки коннекторов
• Если SDK/библиотеки ориентированы на определенную ОС или
разрядность
• Не защищенные соединения и каналы передачи (например, только
http или syslog plain text)
• Не требующие авторизации для доступа из сети
• Snmp, redis, graphite, irc, imap, pop3, relp, xmpp, rss, ssh command, soa,
jdbc …
28

28. Протоколы стриминга данных
• Tcp
• Udp
• Tcp предпочтителен. Однако, при большом количестве логов
возрастает нагрузка на оборудование при сборе/отправке.
• Кейс: на Cisco 29xx при выставленном facility в 6 указали
использовать tcp. Роутер завис и перестал отвечать на запросы из
сети, отказ в обслуживании.
29

29. Нюансы по стримингу и сохранению логов
• Отправка по одному событию (как только новые есть)
• Отправка пачками (блобами) с возможностью установки количества
Плохой пример:
• Отправка раз в N минут
• Запись в БД/файл блобами раз в N минут
• Выдача в API не сортированных событий без уникального
возрастающего идентификатора
• Частая ротация
30

30. Рекомендуемые форматы логирования
• CSV, Json, text
• W3C, LEEF, CEF, NCSA
• По умолчанию, используются уведомления для пользователей
системы (по группам/пользователям/ролям)
31

31. Плохие форматы
• Xml
• Бинарный (часто встречается в СКУД)
• Зашифрованные события изначально или весь лог
32

32. Разделители между событиями
• /r – перевод строки
Плохие примеры:
• Использование /r, n, /r, /s
• Другие спецсимволы
33

33. Разделители в событиях
Для разделения между парами key:value :
• ,
• ;
• /s
• Разделение между ключами и значениями:
• =
Плохие примеры:
• Использование двоеточия :
• Использование точки .
• Использование /r, n, /r, $, #, [], {}
• Использование одного или нескольких /s (иногда у вендоров попросту
непредсказуемое количество пробелов)
34

34. Обрамление значений ключей
• ””
• ()
• Плохие примеры:
• Использование [] не для массивов ключей
35

35. Кодировка
• UTF-8
• Забудьте о других, особенно, если события мультиязычны
• Исключения – определенная базой данных кодировка, которую
по каким то обстоятельствам нельзя сменить
36

36. Уровни логирования
• Организация уровней детализации логов с возможностью
переключения (см. Severity syslog)
• Указание категорий событий (что пишется, см. Facility syslog)
• Выбор конкретных фактов, типов событий, которые будут
записываться
37

37. Разделение сущностей
• Разделение на отдельные файлы/журналы о чем эти события.
Например, отдельный файл для ошибок, отдельный для
аутентификации и аудита.
• Указание в событиях критичности для конкретных событий
• Указание в событиях их категорий
38

38. Плохой пример
Логирование через syslog в VmWare ESX 5.x:
• Менее 1% полезных событий
• Отсутствует информативность
• Частое повторение одного и того же факта через короткие
промежутки времени
39

39. Timestamp`s в событиях
• Не придумывайте велосипед. Используйте ISO 8601.
• Если используете другие форматы:
• Указывайте время по GMT или часовой пояс источника, так как
географически источники одной системы могут быть сильно разнесены.
• Использование миллисекунд и более детального времени может
использоваться в критических, высоконагруженных и реалтаймовых
сервисах.
• Используйте дату возникновения события, а не маркируйте дату
временем записи
40

40. Идентификация отправителя/писателя
• Host/hostname. Hostname остается постоянным при передаче и
является идентифицирующим.
• В событиях в windows event log/syslog указывайте уникальные
поля для вашего ПО. Если в этом же потоке syslog или журнале
windows будут события других источников – их можно будет
разделить парсерами.
41

41. Нюансы поля host при отправке через
syslog
• Когда syslog событие принимается получателем, поле host перезаписывается
значением, от какого хоста было принято событие (обычно host:src.port)
• Если хост получатель стоит за NAT с выключенным arp gateway – будет NAT адрес
42
Syslog relay/Collector
Ip:192.16.5.5
Syslog/Journal
Ip:192.168.0.1
final recipient 2
Aug 29 05:01:03 host=192.168.0.1
message
Aug 29 05:01:03 host=192.16.5.5
message
final recipient 1
Aug 29 05:01:03 host=172.16.0.1
message
Router
Ip:172.16.0.1

42. Изменения форматов от версии к версии
• Старайтесь придерживаться основного формата при обновлении
версий вашего ПО
• Можно добавлять другие key:value
• Губительно изменять:
• Обрамление ключей (добавляя ””)
• Разделители между ключами и значениями
• Разделители между парами key:value
• Вводить массивы вместо одиночных значений
• Уникальные маркеры события о том, что это ваш продукт
• Изменять названия ключей
• Использовать и изменять заглавные буквы в именах ключей
43

43. Вариативные значения ключей
• Если ваше ПО формирует в поле hostname, к примеру, то ip то
fqdn имя – создайте дополнительное поле.
• Если в какое то поле записываются то int значения, то string –
разнесите эти поля.
44

44. Использование CEF/LEEF
• Если используете стандарт – не отступайте от него
• Если же существует потребность – займите частично от стандарта,
изменив служебную обязательную шапку, сделав формат, не
идентифицируемый парсерами как CEF/LEEF
• Отступили от стандарта? Не указывайте что это CEF/LEEF/иной в
своих руководствах.
45

45. Преимущества CEF формата
• Быстрое подключение источника. Как правило, у большинства
SIEM/LM систем имеются стандартные парсеры.
• Имеются основные наименования ключей, кастомные можно
расширять, размещая свои ключи и значения
46

46. Недостатки CEF формата
• Кастомные ключи имеют различные данные у разных продуктов.
В итоге, поле cs5 от двух различных продуктов может иметь
разные по смыслу данные.
• Несмотря на стандарт, придется все равно дорабатывать парсеры
под продукт, извлекая, к примеру, cs5 в категорию события
• Использование переменных для описания значения полей –
увеличивают вес события, но мало добавляют информативности
• С ростом зрелости продукта, формат окажется мал для
вариативного описания событий
47

47. Использование Json формата
• Предполагает строгое соответствия формата стандарту (потому
что никто не пишет свою сериализацию и десериализацию
объектов и все следуют RFC)
• Типы данных должны соответствовать (int/string)
• Если в каком то событии использовали user:{”admin1”}, то при
последующих попытках записать user:{“name”:”admin1”} – скорее
всего, возникнет ошибка (см. RFC8259 и определения объект,
структура, строка)
48

48. Использование XML
• Не рекомендуем использовать в виду сложной сериализации
объектов (время на сериализацию/десериализацию значительно
выше по сравнению с другими форматами)
49

49. Ротация журналов событий
• При сохранении журналов событий учитывайте ротацию! В противном
случае, диск переполнится и ваша система окажется неработоспособной.
• Предлагаемые виды ротации:
• По количеству записей
• По времени (старше, чем)
• Обязательно:
• Контролируйте размер диска!
• При установленном % от места на диске, можно выписывать предупреждение
оператору
• При установленном % от места на диске – включать более жесткую ротацию
• Учитывайте EOF!
• Это важно, так как периодически возникают проблемы, инциденты, что
порождает нестандартные ситуации и быстро переполняет дисковое
пространство
50

50. Концепция сбора SIEM/LM системами
• Высоконагруженность. SIEM даже в SMB секторе собирают десятки
тысяч событий в секунду. Задача – быстро собрать, нормализовать,
обработать, обогатить метаинформацией, скоррелировать, сохранить
и дать удобную навигацию пользователю по этим событиям.
• Дубликаты. Дубликаты событий могут сломать статистику,
спровоцировать многочисленные ложные инциденты.
• Потери. Из за потери одного события из десятков тысяч можно не
увидеть важного факта или инцидента. Терять события нельзя.
• Промедление. В связи с тем, что большая часть бизнеса завязано на
ИТ инфраструктуру, то каждое промедление о факте сбоя и угрозы
может принести весомые финансовые потери.
51

51. Концепция сбора SIEM/LM системами
• Принимают tcp/udp Syslog
• Plain text Syslog или Syslog TLS
• Имеют коннекторы: универсальные и специфические
• Стандартные и специальные транспорты
• Как правило, могут обратиться к базам данных Postgresql/Oracle/MS SQL/Mysql и
представлениям за событиями
• Коллектор/агент (сборщик событий) может быть как на платформе Linux (причем
разнообразные версии), так и на Windows. Что накладывает свои ограничения на
специфические транспорты.
• При сборе, SIEM/LM не могут по тексту события определить – собрали они уже его
или нет. Эти системы процессят десятки тысяч и более событий в секунду.
• При сборе с удаленных узлов по открытым каналам связи может применяться
туннелирование и шифрование трафика.
52

52. Позиционные маркеры
• Встречаются довольно объемные журналы событий
• Дубликаты событий могут сломать всю статистическую выборку,
спровоцировать ложные срабатывания инцидентов. Поэтому каждое
событие должно собраться только один раз.
• Нельзя получать все события, чтобы из них выбрать новые
• В связи с вышеперечисленными фактами, при сборе событий
учитывается последняя прочитанная позиция. Именно с нее
следующий раз начнется чтение новых событий.
• Если не существует номера строки или уникального возрастающего
идентификатора записи – используется поле, содержащее время
записи/возникновения события.
53

53. Последствия с позиционными маркерами
• Сортировка. Если ваше API не будет производить сортировку и не способно
выдать запись старше N – будут дубликаты событий
• Ротация файла. Если вы пишете в один и тот же файл, ротируете его без
изменения даты создания – будут дубликаты событий (определить иначе
сложно, особенно если запись событий частая)
• Замена вместо новых. Если вы заменяете значения в строках таблицы БД не
меняя идентификатор и имея более 2х меток времени – возможны
дубликаты
• Одинаковое время. Если не имеется уникального идентификатора записи,
могут возникнуть несколько событий с абсолютно идентичной меткой
времени, что привнесет коллизию и возможные потери событий
• P.s. Не предлагайте разработчикам SIEM брать полную копию событий,
искать в них уже собранные или сортировать на своей стороне 
54

54. Концепция нормализации событий
• Нормализация – процесс разбивки события на ключ:значение, приведение к
общему виду именования ключей (таксономия) и трансформация событий в
единый формат (как правило, json).
• Нормализация необходима, чтобы пользователь мог выбрать, к примеру, все
события по user.name:”admin” по любым источникам
• Нормализация необходима для построения корректной статистики и отчетов
• Data Learning/Machine Learning без нормализации на больших объемах - утопия
• Применяется два вида нормализации:
• трансформация события в режиме реального времени
• Crazy вариант: Сохранение событий «как есть» и обращение к ним с регулярными
выражениями
• Как правило, сохраняется исходное (RAW) событие и выделяются нормализованные
поля с значениями в отдельное событие (или с RAW в одном)
55

55. Почему нормализация всегда будет актуальна
• Слишком много разнородных источников
• Всегда есть вендоры, привносящие вариативность формата
• В логировании допускаются различные ошибки: где то
прокрадется двойной пробел, где то сделают табуляцию и так
далее. Даже в журналах Microsoft эти ошибки и в syslog plain
некоторые вендоры начинают рандомно вставлять
украшательство в виде табуляций 
• Разные исходные форматы (plain, json, xml, csv, …)
56

56. Валидация типов значений и маппинги
• Часть нормализации – это также валидация типов значений
• К примеру, для БД Elasticsearch если не указать в статическом шаблоне
поле id с типом «string» и записать туда событие, содержащее id:”123”
– в динамическом шаблоне автоматически создается поле id с типом
«int». Если попытаться в такой индекс записать id:”mystring_id” – все
событие не запишется!
• Если приходит значение int не соответствующее json формату – опять
же возникнет ошибка.
• Если пишем данные формата int в типе string – то при попытках
подсчетов среднего значения, сумм – нам придется на бекэнде
обыгрывать эту ситуацию, причем не самыми производительными
способами
57

57. Глубокое погружение в нормализацию
Какие основные функции/методы используются для нормализации:
• Kv (key:value) с заданным разделителем
• Grok (regexp)
• Regexp и логические сравнения
• Csv с указанием какое порядковое значение к какому ключу относится
• Mutate (замены, переименования и прочее)
• Translate (замена слов в корейской Windows на английские
соответствующие чтобы использовать одинаковые обработчики)
• Date (приведение даты к стандартному используемому)
58
*Приведены имена функций как примеры методов извлечения key:value. Рассматривается формат
реализации в RuSIEM и Logstash (взаимно не совместимы). Для других SIEM/LM визуально и по именам
методы могут различаться, но на уровне ядра – примерно все тоже самое.

58. Примеры kv парсера
• Предполагается для данного парсера, что события имеют
одинаковый разделитель между key:value и одинаковый между
соседними парами key:value
59
kv {
source => "message” #по какому полю работаем
include_keys => [ "LOGDATA", "AREA", "EMPHINT", "DEVHINT", "LOGTIME" ] #какие
имена ключей выделяем из события
value_split => ":” #разделитель между ключом и значением
field_split => ",” #разделитель между парами ключ:значение
}

59. Примеры grok парсера
60

60. Примеры mutate-rename
61

61. Что произойдет если ваши события будут
«рандомного формата»
• Что то не попадет под нормализацию и как следствие:
• Не попадет под корреляцию и пользователь не увидит факт инцидента
• Не попадет в отчет
• Не будет участвовать в выборках и в визуализации
• Возможно, будет утеряно вовсе
• Будет попадать как событие от другого источника
• Парсинг вашего источника будет затрачивать значительные
аппаратные ресурсы
• Долгое подключение источника
• Не будет описаны четко вариации формата – необходимо будет
эмулировать различные ситуации
62

62. Рекомендуемые форматы событий
• Aug 31 03:01:43 adm.local nmap: something happened, hops=0,
ip=172.16.0.225, hostname=, mac=, open_port=3000,
port_proto=tcp, port_service=ntop-http, port_description=Ntop web
interface 5.0.1, os_name=
63
$timestamp $hostname $program $delimiter $key+$delimiter+$value

63. Основные правила по формату событий
• Разделяйте шапку и тело события. Например, с помощью двоеточия.
• Используйте уникальный признак в событиях, что это ваш софт. Можно даже указать версию.
• Используйте статическую не меняющуюся шапку, без добавления в нее новых данных в каких то
событиях
• Старайтесь использовать имена ключей с значениями
• Используйте разделитель между парами key:value
• Старайтесь использовать постоянную основную длину событий. Если имеются ключи и вариативные
данные, которые есть не во всех событиях – поместите их в конец события
• Можно не использовать разделитель между отдельными парами key:value, но в этом случае
обрамляйте значения ключей кавычками. Часто встречается значения состоящие из нескольких слов с
пробелами и на их извлечение тратятся ресурсы
• Обрамляйте значения ключей одинаково
• Не меняйте типы значений по возможности
• Не используйте имена ключей с пробелом
• Используйте одинаковые имена одних и тех же ключей в мульти-микросервисной архитектуре
64

64. Разделяйте шапку и тело события.
Используйте статичную шапку.
• Плохой пример:
• Aug 31 03:01:43 adm.local nmap something happened
• Aug 31 03:01:43 adm.local nmap scan something else happened
• Можно записать так:
• Aug 31 03:01:43 adm.local [nmap:scan] something else happened
• Или Aug 31 03:01:43 adm.local [nmap,scan]: something else happened
• Если и далее используются эти события – не должны прийти
разные шапки:
• Aug 31 03:01:43 adm.local [nmap,report]: something else happened
• Aug 31 03:01:43 adm.local nmap something else happened
65

65. Используйте уникальный признак в
событиях, что это ваш софт.
• Вы написали свой софт но он идентифицируется как другой?
• Очень часто все события от источников идут вперемешку в одном
потоке.
• Бывает так, что отличить ваши события от других попросту не
возможно, особенно если в одном потоке.
• Можно добавлять информацию в шапку или тело события
66

66. Старайтесь использовать имена ключей с
значениями
• Даже в csv формате
• Плохой пример:
• Aug 31 03:01:43 adm.local [nmap 2.1.1]: something happened, 0 172.16.0.225 22
• Лучше:
• Aug 31 03:01:43 adm.local [nmap|2.1.1]: hops=“0”, ip=“172.16.0.225”,
port=“22”
67

67. Несколько значений без разделителя
• Плохой пример:
• Aug 31 03:01:43 adm.local [nmap 2.1.1]: something happened, 0
172.16.0.225 22
• Фактически здесь два значения без имен ключей и разделителей.
Лучше оформление так:
• Aug 31 03:01:43 adm.local [nmap, 2.1.1]: something happened, hops=0 ip=172.16.0.225 port
22
• Aug 31 03:01:43 adm.local [nmap, 2.1.1]: something happened, hops=0, ip=172.16.0.225,
port 22
• Aug 31 03:01:43 adm.local [nmap|2.1.1]: hops=“0”, ip=“172.16.0.225”, port=“22”
68

68. Используйте разделитель между парами
key:value
• Плохой пример:
• Aug 29 05:01:03 adm.local nmap: open_port=22 port_proto=tcp
port_service=ssh port_description= protocol 2.0 hostname=
• Лучше:
• Aug 29 05:01:03 adm.local nmap: open_port=22, port_proto=tcp,
port_service=ssh, port_description=“protocol 2.0”, hostname=
69

69. Слабый разделитель
• В качестве разделителя может использоваться и табуляция (или несколько
пробелов s). Но количество ts должно быть константой! Если где то
вкрадется вместо одного s два и более и это не будет предусмотрено
парсером – событие будет утеряно.
• Для парсера проверять не статичное количество пробелов – дополнительная
нагрузка.
70

70. Старайтесь использовать постоянную основную длину
событий. Вариативные данные поместите в конец события.
• Плохой пример:
• Aug 29 05:01:03 adm.local nmap: open_port=22 port_proto=tcp
• Aug 29 05:02:31 adm.local nmap scanner: severity=7 vulnerability=CVE-2012-5975
open_port=22 port_proto=tcp
• Изменения в шапке не желательны. Либо регламентируйте варианты.
• Если используются разделители между парами key:value – то не страшна
вариативность для тела события
• Если значений у ключей может не быть – можно оставлять пустыми. Или не
указывать эти ключи если только применяется разделитель!
• Лучше записать так:
• Aug 29 05:02:31 adm.local [nmap,reporter]: open_port=22 port_proto=tcp vulnerability=CVE-
2012-5975
• Aug 29 05:02:31 adm.local [nmap,scanner]: severity=, vulnerability=, open_port=22,
port_proto=tcp
71

71. Используйте одинаковые имена одних и тех же
ключей в мульти микросервисной архитектуре
• Плохой пример приходящих последовательно событий:
• Aug 29 05:02:31 adm.local [nmap,scanner]: open_port=22 port_proto=tcp vulnerability=CVE-
2012-5975
• Aug 29 05:04:12 adm.local [nmap,reporter]: openport=22 proto=tcp vulnerability_cve=CVE-2012-
5975
• Разработайте и используйте единую таксономию: src_ip, dst_ip,
proto, vulnerability, open_port, error_id и так далее.
72

72. Обрамляйте значения ключей одинаково
• Если есть вероятность что значение будет содержать несколько
слов с пробелами – обрамляйте кавычками. Как вариант – можно
и скобками ().
• Используйте одинаковые кавычки. Потому что есть ``, ‘’,””,«»
73

73. Нюансы журналов событий при сборе через
syslog
• Syslog не работает с файлами, имеющими в именах вариативные
именования с префиксом или постфиксом в виде даты или
времени
• Syslog не работает с директориями, имеющими в именах префикс
или постфикс в виде даты или времени
• Выходом из такой ситуации может быть наличие директории
current где будут просто журналы без префиксов и постфиксов в
виде времени/даты, к примеру, dns.log и которая будет
опрашиваться syslog демоном. А в директории по времени – уже
раскладываться параллельно при ротации (пример на
следующем слайде).
74

74. Пример с именованиями директорий в виде дат и current.

75. Заключение
• Список программного обеспечения, с которого собираются события, слишком велик
и многогранен для стандартизации формата событий.
• В современных системах для комплексного анализа сводится множество разных
источников, имеющих абсолютно разный формат. Без предварительной
нормализации данных – в итоге будут ошибки.
• Возможно использовать и сырые данные, определяя формат при анализе – но для
этого необходимы аппаратные мощности в сотни и тысячи раз выше. И вероятность
ошибки в этом случае – гораздо выше.
• Чем сложнее описать машине правило парсинга и чем больше тактов потребуется
для его нормализации – тем больше аппаратных мощностей придется привлечь,
более затратным станет обработка вашего источника, больше будет задержка до
уведомления об угрозе.
• Следуя советам настоящего Руководства у вас обязательно получится сделать
журналы вашего продукта читаемыми и подключаемыми к любой SIEM/LM
системе.
76

76. Контактная информация:
Сайт : https://www.rusiem.com
Новости в телеграм: https://r.me/rusiem
Фейсбук: https://www.facebook.com/rvsiem
Инфо: support@rusiem.com
СПАСИБО ЗА ВНИМАНИЕ
Остались вопросы?
Обращайтесь!
77
Олеся Шелестова, CEO RuSIEM
oshelestova@rusiem.com