Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Руководство по формату событий для разработчиков

201 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

Руководство по формату событий для разработчиков

  1. 1. support@rusiem.com https://rusiem.com Руководство по формату событий (для разработчиков программного обеспечения) Версия 1, август 2018
  2. 2. • Данное руководство не является стандартом • Все изложенные мысли основаны на опыте работы с различными форматами и источниками, подключении их к системам централизованной обработки событий • Используя настоящее руководство, вы сможете создать универсальный транспорт и формат событий в вашем продукте, способный быстро интегрироваться и отвечать современным потребностям пользователей. Не важно с каким SIEM/LM. 3 Лучше сделать изначально правильно, чем потом переделывать впопыхах.
  3. 3. Зачем логирование • Ваше оборудование и программное обеспечение не может говорить с пользователями • Через события система общается с пользователями (операторами). Рассказывает что с ней происходит, что происходит вокруг, что она видит • Это не только события об ошибках, но и: • аудит (кто входит, кому права доступа предоставляются, кто обращается за данными или записывает их) • Сообщения о том, что обнаружила система • Что делает или не смогла сделать система • Вывод показателей и статистических данных • Прочие результаты работы системы 4
  4. 4. Частота • Насколько быстро вы бы хотели узнать что вашу машину угоняют? Примерно также оценивайте насколько часто писать события. • События нужно поставлять в журнал/на стрим в режиме близком к реальному времени. • Следует отталкиваться от критичности данных • Скорее всего, нет необходимости в таких событиях, которые нужно собирать всего лишь раз в сутки • Если вы только пишете события в журнал событий, то будьте готовы к частым обращениям за этими событиями. Чтобы потом не кричать «наше API можно дергать только раз в 5 минут!». 5
  5. 5. Зачем нужно придерживаться форматов и рекомендаций • Ваши потребители рано или поздно будут читать ваши события • События в современных системах отправляются на SIEM/LM системы, которые позволяют: • Своевременно определять неработоспособность системы • Снимать статистически показатели для различных целей • Обрабатывать автоматически события, предупреждая пользователей инцидентами в режиме реального времени о различных угрозах • Использовать для расследования инцидентов и предотвращения их в дальнейшем • Разработчикам для отладки и понимания ситуации также необходимы журналы событий • У заказчиков в инфраструктуре десятки и сотни тысяч различных систем и при этом он должен быть в курсе происходящего, держать руку на пульсе и своевременно восстанавливать работоспособность, предотвращать угрозу • Для разработчика ПО и заказчика подключение сбора событий в SIEM/LM систему должно производится просто, в формате plug-and-play. К любой SIEM системе. 6
  6. 6. Зачем следовать формату событий • Вы бы хотели работать с выборками данных, где, к примеру, в поле “balance” периодически попадались не только цифры вашего баланса, но и назначения платежей, какие то цифровые идентификаторы? • Современные потребности предполагают, что пользователь работает с событиями не в текстовом редакторе или вашем интерфейсе продукта, а в централизованных системах, где агрегированы сотни миллионов событий с тысяч различных гетерогенных систем – SIEM/LM • Централизованный сбор подразумевает и обработку поступающих событий – нормализацию (приведение к общему формату) и корреляцию • Работая с выборками событий и выбирая, к примеру, src.ip:”172.16.0.1” или user.id:”93411”, пользователь ожидает, что будут отображены события касающиеся этих значений как по логам вашей системы, так и по логам из других систем 7
  7. 7. Что такое событие • Элементарное, минимальное сообщение, содержащее текст, набор ключей и сопоставленных значений, повествующее о каком либо произошедшем факте. Это как минимальное повествовательное предложение. • Рекомендуемый размер событий: 10-300 байт Плохой пример: • Xml формат, размер событий до 10 MB 8
  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. 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. 10. Ужасный пример из mq: Raw + нормализованное в json формате 11
  11. 11. Пример raw события Windows event log 12 • Событие приходит с нашего агента RuSIEM. Получено с помощью tcpdump. • Еще не обработано нормализацией • Присутствуют rtn разделители • Формат json • Основное тело оригинального события обрамлено в json поле message • Присутствует ключ-значение “module”:”msevt” идентифицирующее что это событие с windows event log
  12. 12. Обязательные поля в событии • Дата возникновения события (факта) • Имя хоста • Маркер в событии, характеризующий что это событие от вашего ПО 13
  13. 13. Рекомендуемые поля в событии • Дата возникновения события (факта) • Имя хоста где сформировано событие • IP хоста где сформировано событие • Маркер в событии, характеризующий что это событие от вашего ПО • Категория • Критичность • Тело события (текст + key:value) 14
  14. 14. Служебные поля событий Нельзя использовать следующие именования полей: • host • hostname • timestamp • @timestamp • event.time (запись с точкой в виде строки и json формат “event”:{“time”}) • message 15
  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. 16. Кто собирает и использует ваши события • Администраторы в случае ошибок и сбоев • SIEM/LM системы для аудита (процессов, сети, пользователей, трафика, расширенного мониторинга) • SIEM/LM для выявления сбоев, аномалий • SIEM/LM и статистические системы – статистика и тенденции • Для интеграции с другими системами • Системы мониторинга для автоматического восстановления работоспособности сервиса • Для расследования инцидентов (в том числе в судах) • В целях соответствия стандартам и требованиям регуляторов 17
  17. 17. Рекомендуемые категории для журналов событий от вашего приложения • Состояние системы (ошибки, сбои, перезагрузка, метрики) • Изменения конфигураций (кто, когда, как, что) • Управление правами, ролями, пользователями и группами • Авторизация и аутентификация • Доступы (кто, откуда, к чему) • Детализация и категории событий должны определяться в настройках. 18
  18. 18. События вашего приложения • Позвольте пользователю выбирать – какие события/категории • Используйте Severity/Facility если категории и типы события не возможны • Типы данных определяются возможностями вашего ПО • Представьте, что пользователь не заглядывает в консоль вашего ПО. Он смотрит только события удаленно в SIEM/LM. Ориентируйтесь исходя из этого. • Пишите простые и в то же время полноценные понятные события • Используйте W7 методологию 19
  19. 19. Записывать и(или) отправлять • Хранение. Ваше программное обеспечение пишет лог (в режиме, близком к реальному времени), коннекторы SIEM/LM забирают их • Стриминг. Ваше ПО пишет и имеет возможность отправки логов в режиме реального времени Плохие примеры: • Чтобы собрать события, нужно запустить скрипты/команды (MS Exchange) • Сброс логов через длинные интервалы времени 20
  20. 20. Лучшие транспорты логирования • Текстовый лог • Syslog • Windows event log (кастомные логи) 21
  21. 21. Могут также использоваться • Ваше API с определенным форматом • WMI • ODBC • MQ • SQL (TDS) • Oracle (TNS) • SDP • Таблица/представление в базе данных • Журналы событий на ftp • прочие 22
  22. 22. Нюансы по файловым логам Именования журналов: • С одним именем • С постфиксом в виде даты (например, error-29082018.log) • Внимание! При записи в один и тот же файл и его ротации необходимо как то сообщать сторонним его читателям, что файл был очищен. Например, меняя его дату создания. • Учитывайте права доступа. Много ошибок, когда нельзя сменить права для читателя без нарушения работоспособности. • Учитывайте в коде права доступа к файлам! Встречаются ошибки разработчиков, когда при отсутствии доступа к лог файлу ваше ПО перестает работать вовсе! • Не используйте монопольный доступ к файлу журнала событий 23
  23. 23. Нюансы по API и событиям в БД • Не мешайте в одной куче события различных категорий. Например, события о вирусах, события об установке ПО, события об обновлении. • Указывайте для каждого события возрастающее уникальное значение. • Сортируйте на своей стороне события по убыванию • Будьте готовы по производительности. Ваше api будут опрашивать на предмет новых логов каждые 10-20 секунд 24
  24. 24. API: хорошо и плохо • Хорошо: • Пример – доступ к логам Windows. Рабочих станций и серверов много в инфраструктуре. Установка агента или скрипта означает что добавляются промежуточные звенья – необходимо следить есть ли сбор или нет. И пользователь может это отключить. • Закрытая платформа, внутрь которой нельзя что то установить или получить доступы к файлам. • Плохо: • Сервер СКУД/мониторинга на *nix/Windows платформе, имеющий 500 EPS (events per second) и слабое аппаратное оборудование. • API, имеющая задержку в отдаче событий по запросу более 2-4х секунд. • API, с которой интегрированы реалтаймовые сервисы и попутно предназначенная для выдачи событий. 25
  25. 25. Недостатки W3C/csv форматов • Как правило, парсеры настроены жестко к значению в последовательности. То есть, парсер ждет в 5 по порядку поле src.ip. • Парсеры игнорируют шапку, в которой иногда прописаны поля • Современные системы предполагают возможность добавления каких либо полей. Добавляется поле, ломается последовательность и в пятом поле уже не src.ip, а src.user.name. • Csv логи плохо воспринимаются при просмотре, зато хорошо импортируются в Excel. • Как правило, в csv формате отсутствуют именования ключей, что затрудняет парсинг 26
  26. 26. Плохой пример API и журналов в БД • В одно и то же поле пишутся попеременно имя хоста, ip адрес, код или иное значение • Через API передаются несортированные события по дате или уникальному возрастающему значению • Строка в БД полностью перезаписывается, а не формируется новая с новым событием • Значения в строках БД событий перезаписываются, либо перезаписываются значения 27
  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. 28. Протоколы стриминга данных • Tcp • Udp • Tcp предпочтителен. Однако, при большом количестве логов возрастает нагрузка на оборудование при сборе/отправке. • Кейс: на Cisco 29xx при выставленном facility в 6 указали использовать tcp. Роутер завис и перестал отвечать на запросы из сети, отказ в обслуживании. 29
  29. 29. Нюансы по стримингу и сохранению логов • Отправка по одному событию (как только новые есть) • Отправка пачками (блобами) с возможностью установки количества Плохой пример: • Отправка раз в N минут • Запись в БД/файл блобами раз в N минут • Выдача в API не сортированных событий без уникального возрастающего идентификатора • Частая ротация 30
  30. 30. Рекомендуемые форматы логирования • CSV, Json, text • W3C, LEEF, CEF, NCSA • По умолчанию, используются уведомления для пользователей системы (по группам/пользователям/ролям) 31
  31. 31. Плохие форматы • Xml • Бинарный (часто встречается в СКУД) • Зашифрованные события изначально или весь лог 32
  32. 32. Разделители между событиями • /r – перевод строки Плохие примеры: • Использование /r, n, /r, /s • Другие спецсимволы 33
  33. 33. Разделители в событиях Для разделения между парами key:value : • , • ; • /s • Разделение между ключами и значениями: • = Плохие примеры: • Использование двоеточия : • Использование точки . • Использование /r, n, /r, $, #, [], {} • Использование одного или нескольких /s (иногда у вендоров попросту непредсказуемое количество пробелов) 34
  34. 34. Обрамление значений ключей • ”” • () • Плохие примеры: • Использование [] не для массивов ключей 35
  35. 35. Кодировка • UTF-8 • Забудьте о других, особенно, если события мультиязычны • Исключения – определенная базой данных кодировка, которую по каким то обстоятельствам нельзя сменить 36
  36. 36. Уровни логирования • Организация уровней детализации логов с возможностью переключения (см. Severity syslog) • Указание категорий событий (что пишется, см. Facility syslog) • Выбор конкретных фактов, типов событий, которые будут записываться 37
  37. 37. Разделение сущностей • Разделение на отдельные файлы/журналы о чем эти события. Например, отдельный файл для ошибок, отдельный для аутентификации и аудита. • Указание в событиях критичности для конкретных событий • Указание в событиях их категорий 38
  38. 38. Плохой пример Логирование через syslog в VmWare ESX 5.x: • Менее 1% полезных событий • Отсутствует информативность • Частое повторение одного и того же факта через короткие промежутки времени 39
  39. 39. Timestamp`s в событиях • Не придумывайте велосипед. Используйте ISO 8601. • Если используете другие форматы: • Указывайте время по GMT или часовой пояс источника, так как географически источники одной системы могут быть сильно разнесены. • Использование миллисекунд и более детального времени может использоваться в критических, высоконагруженных и реалтаймовых сервисах. • Используйте дату возникновения события, а не маркируйте дату временем записи 40
  40. 40. Идентификация отправителя/писателя • Host/hostname. Hostname остается постоянным при передаче и является идентифицирующим. • В событиях в windows event log/syslog указывайте уникальные поля для вашего ПО. Если в этом же потоке syslog или журнале windows будут события других источников – их можно будет разделить парсерами. 41
  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. 42. Изменения форматов от версии к версии • Старайтесь придерживаться основного формата при обновлении версий вашего ПО • Можно добавлять другие key:value • Губительно изменять: • Обрамление ключей (добавляя ””) • Разделители между ключами и значениями • Разделители между парами key:value • Вводить массивы вместо одиночных значений • Уникальные маркеры события о том, что это ваш продукт • Изменять названия ключей • Использовать и изменять заглавные буквы в именах ключей 43
  43. 43. Вариативные значения ключей • Если ваше ПО формирует в поле hostname, к примеру, то ip то fqdn имя – создайте дополнительное поле. • Если в какое то поле записываются то int значения, то string – разнесите эти поля. 44
  44. 44. Использование CEF/LEEF • Если используете стандарт – не отступайте от него • Если же существует потребность – займите частично от стандарта, изменив служебную обязательную шапку, сделав формат, не идентифицируемый парсерами как CEF/LEEF • Отступили от стандарта? Не указывайте что это CEF/LEEF/иной в своих руководствах. 45
  45. 45. Преимущества CEF формата • Быстрое подключение источника. Как правило, у большинства SIEM/LM систем имеются стандартные парсеры. • Имеются основные наименования ключей, кастомные можно расширять, размещая свои ключи и значения 46
  46. 46. Недостатки CEF формата • Кастомные ключи имеют различные данные у разных продуктов. В итоге, поле cs5 от двух различных продуктов может иметь разные по смыслу данные. • Несмотря на стандарт, придется все равно дорабатывать парсеры под продукт, извлекая, к примеру, cs5 в категорию события • Использование переменных для описания значения полей – увеличивают вес события, но мало добавляют информативности • С ростом зрелости продукта, формат окажется мал для вариативного описания событий 47
  47. 47. Использование Json формата • Предполагает строгое соответствия формата стандарту (потому что никто не пишет свою сериализацию и десериализацию объектов и все следуют RFC) • Типы данных должны соответствовать (int/string) • Если в каком то событии использовали user:{”admin1”}, то при последующих попытках записать user:{“name”:”admin1”} – скорее всего, возникнет ошибка (см. RFC8259 и определения объект, структура, строка) 48
  48. 48. Использование XML • Не рекомендуем использовать в виду сложной сериализации объектов (время на сериализацию/десериализацию значительно выше по сравнению с другими форматами) 49
  49. 49. Ротация журналов событий • При сохранении журналов событий учитывайте ротацию! В противном случае, диск переполнится и ваша система окажется неработоспособной. • Предлагаемые виды ротации: • По количеству записей • По времени (старше, чем) • Обязательно: • Контролируйте размер диска! • При установленном % от места на диске, можно выписывать предупреждение оператору • При установленном % от места на диске – включать более жесткую ротацию • Учитывайте EOF! • Это важно, так как периодически возникают проблемы, инциденты, что порождает нестандартные ситуации и быстро переполняет дисковое пространство 50
  50. 50. Концепция сбора SIEM/LM системами • Высоконагруженность. SIEM даже в SMB секторе собирают десятки тысяч событий в секунду. Задача – быстро собрать, нормализовать, обработать, обогатить метаинформацией, скоррелировать, сохранить и дать удобную навигацию пользователю по этим событиям. • Дубликаты. Дубликаты событий могут сломать статистику, спровоцировать многочисленные ложные инциденты. • Потери. Из за потери одного события из десятков тысяч можно не увидеть важного факта или инцидента. Терять события нельзя. • Промедление. В связи с тем, что большая часть бизнеса завязано на ИТ инфраструктуру, то каждое промедление о факте сбоя и угрозы может принести весомые финансовые потери. 51
  51. 51. Концепция сбора SIEM/LM системами • Принимают tcp/udp Syslog • Plain text Syslog или Syslog TLS • Имеют коннекторы: универсальные и специфические • Стандартные и специальные транспорты • Как правило, могут обратиться к базам данных Postgresql/Oracle/MS SQL/Mysql и представлениям за событиями • Коллектор/агент (сборщик событий) может быть как на платформе Linux (причем разнообразные версии), так и на Windows. Что накладывает свои ограничения на специфические транспорты. • При сборе, SIEM/LM не могут по тексту события определить – собрали они уже его или нет. Эти системы процессят десятки тысяч и более событий в секунду. • При сборе с удаленных узлов по открытым каналам связи может применяться туннелирование и шифрование трафика. 52
  52. 52. Позиционные маркеры • Встречаются довольно объемные журналы событий • Дубликаты событий могут сломать всю статистическую выборку, спровоцировать ложные срабатывания инцидентов. Поэтому каждое событие должно собраться только один раз. • Нельзя получать все события, чтобы из них выбрать новые • В связи с вышеперечисленными фактами, при сборе событий учитывается последняя прочитанная позиция. Именно с нее следующий раз начнется чтение новых событий. • Если не существует номера строки или уникального возрастающего идентификатора записи – используется поле, содержащее время записи/возникновения события. 53
  53. 53. Последствия с позиционными маркерами • Сортировка. Если ваше API не будет производить сортировку и не способно выдать запись старше N – будут дубликаты событий • Ротация файла. Если вы пишете в один и тот же файл, ротируете его без изменения даты создания – будут дубликаты событий (определить иначе сложно, особенно если запись событий частая) • Замена вместо новых. Если вы заменяете значения в строках таблицы БД не меняя идентификатор и имея более 2х меток времени – возможны дубликаты • Одинаковое время. Если не имеется уникального идентификатора записи, могут возникнуть несколько событий с абсолютно идентичной меткой времени, что привнесет коллизию и возможные потери событий • P.s. Не предлагайте разработчикам SIEM брать полную копию событий, искать в них уже собранные или сортировать на своей стороне  54
  54. 54. Концепция нормализации событий • Нормализация – процесс разбивки события на ключ:значение, приведение к общему виду именования ключей (таксономия) и трансформация событий в единый формат (как правило, json). • Нормализация необходима, чтобы пользователь мог выбрать, к примеру, все события по user.name:”admin” по любым источникам • Нормализация необходима для построения корректной статистики и отчетов • Data Learning/Machine Learning без нормализации на больших объемах - утопия • Применяется два вида нормализации: • трансформация события в режиме реального времени • Crazy вариант: Сохранение событий «как есть» и обращение к ним с регулярными выражениями • Как правило, сохраняется исходное (RAW) событие и выделяются нормализованные поля с значениями в отдельное событие (или с RAW в одном) 55
  55. 55. Почему нормализация всегда будет актуальна • Слишком много разнородных источников • Всегда есть вендоры, привносящие вариативность формата • В логировании допускаются различные ошибки: где то прокрадется двойной пробел, где то сделают табуляцию и так далее. Даже в журналах Microsoft эти ошибки и в syslog plain некоторые вендоры начинают рандомно вставлять украшательство в виде табуляций  • Разные исходные форматы (plain, json, xml, csv, …) 56
  56. 56. Валидация типов значений и маппинги • Часть нормализации – это также валидация типов значений • К примеру, для БД Elasticsearch если не указать в статическом шаблоне поле id с типом «string» и записать туда событие, содержащее id:”123” – в динамическом шаблоне автоматически создается поле id с типом «int». Если попытаться в такой индекс записать id:”mystring_id” – все событие не запишется! • Если приходит значение int не соответствующее json формату – опять же возникнет ошибка. • Если пишем данные формата int в типе string – то при попытках подсчетов среднего значения, сумм – нам придется на бекэнде обыгрывать эту ситуацию, причем не самыми производительными способами 57
  57. 57. Глубокое погружение в нормализацию Какие основные функции/методы используются для нормализации: • Kv (key:value) с заданным разделителем • Grok (regexp) • Regexp и логические сравнения • Csv с указанием какое порядковое значение к какому ключу относится • Mutate (замены, переименования и прочее) • Translate (замена слов в корейской Windows на английские соответствующие чтобы использовать одинаковые обработчики) • Date (приведение даты к стандартному используемому) 58 *Приведены имена функций как примеры методов извлечения key:value. Рассматривается формат реализации в RuSIEM и Logstash (взаимно не совместимы). Для других SIEM/LM визуально и по именам методы могут различаться, но на уровне ядра – примерно все тоже самое.
  58. 58. Примеры kv парсера • Предполагается для данного парсера, что события имеют одинаковый разделитель между key:value и одинаковый между соседними парами key:value 59 kv { source => "message” #по какому полю работаем include_keys => [ "LOGDATA", "AREA", "EMPHINT", "DEVHINT", "LOGTIME" ] #какие имена ключей выделяем из события value_split => ":” #разделитель между ключом и значением field_split => ",” #разделитель между парами ключ:значение }
  59. 59. Примеры grok парсера 60
  60. 60. Примеры mutate-rename 61
  61. 61. Что произойдет если ваши события будут «рандомного формата» • Что то не попадет под нормализацию и как следствие: • Не попадет под корреляцию и пользователь не увидит факт инцидента • Не попадет в отчет • Не будет участвовать в выборках и в визуализации • Возможно, будет утеряно вовсе • Будет попадать как событие от другого источника • Парсинг вашего источника будет затрачивать значительные аппаратные ресурсы • Долгое подключение источника • Не будет описаны четко вариации формата – необходимо будет эмулировать различные ситуации 62
  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. 63. Основные правила по формату событий • Разделяйте шапку и тело события. Например, с помощью двоеточия. • Используйте уникальный признак в событиях, что это ваш софт. Можно даже указать версию. • Используйте статическую не меняющуюся шапку, без добавления в нее новых данных в каких то событиях • Старайтесь использовать имена ключей с значениями • Используйте разделитель между парами key:value • Старайтесь использовать постоянную основную длину событий. Если имеются ключи и вариативные данные, которые есть не во всех событиях – поместите их в конец события • Можно не использовать разделитель между отдельными парами key:value, но в этом случае обрамляйте значения ключей кавычками. Часто встречается значения состоящие из нескольких слов с пробелами и на их извлечение тратятся ресурсы • Обрамляйте значения ключей одинаково • Не меняйте типы значений по возможности • Не используйте имена ключей с пробелом • Используйте одинаковые имена одних и тех же ключей в мульти-микросервисной архитектуре 64
  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. 65. Используйте уникальный признак в событиях, что это ваш софт. • Вы написали свой софт но он идентифицируется как другой? • Очень часто все события от источников идут вперемешку в одном потоке. • Бывает так, что отличить ваши события от других попросту не возможно, особенно если в одном потоке. • Можно добавлять информацию в шапку или тело события 66
  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. 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. 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. 69. Слабый разделитель • В качестве разделителя может использоваться и табуляция (или несколько пробелов s). Но количество ts должно быть константой! Если где то вкрадется вместо одного s два и более и это не будет предусмотрено парсером – событие будет утеряно. • Для парсера проверять не статичное количество пробелов – дополнительная нагрузка. 70
  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. 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. 72. Обрамляйте значения ключей одинаково • Если есть вероятность что значение будет содержать несколько слов с пробелами – обрамляйте кавычками. Как вариант – можно и скобками (). • Используйте одинаковые кавычки. Потому что есть ``, ‘’,””,«» 73
  73. 73. Нюансы журналов событий при сборе через syslog • Syslog не работает с файлами, имеющими в именах вариативные именования с префиксом или постфиксом в виде даты или времени • Syslog не работает с директориями, имеющими в именах префикс или постфикс в виде даты или времени • Выходом из такой ситуации может быть наличие директории current где будут просто журналы без префиксов и постфиксов в виде времени/даты, к примеру, dns.log и которая будет опрашиваться syslog демоном. А в директории по времени – уже раскладываться параллельно при ротации (пример на следующем слайде). 74
  74. 74. Пример с именованиями директорий в виде дат и current.
  75. 75. Заключение • Список программного обеспечения, с которого собираются события, слишком велик и многогранен для стандартизации формата событий. • В современных системах для комплексного анализа сводится множество разных источников, имеющих абсолютно разный формат. Без предварительной нормализации данных – в итоге будут ошибки. • Возможно использовать и сырые данные, определяя формат при анализе – но для этого необходимы аппаратные мощности в сотни и тысячи раз выше. И вероятность ошибки в этом случае – гораздо выше. • Чем сложнее описать машине правило парсинга и чем больше тактов потребуется для его нормализации – тем больше аппаратных мощностей придется привлечь, более затратным станет обработка вашего источника, больше будет задержка до уведомления об угрозе. • Следуя советам настоящего Руководства у вас обязательно получится сделать журналы вашего продукта читаемыми и подключаемыми к любой SIEM/LM системе. 76
  76. 76. Контактная информация: Сайт : https://www.rusiem.com Новости в телеграм: https://r.me/rusiem Фейсбук: https://www.facebook.com/rvsiem Инфо: support@rusiem.com СПАСИБО ЗА ВНИМАНИЕ Остались вопросы? Обращайтесь! 77 Олеся Шелестова, CEO RuSIEM oshelestova@rusiem.com

×