- PVSM.RU - https://www.pvsm.ru -
Как корректно нормализовать событие? Как нормализовать аналогичные события от разных источников, ничего не забыв и не напутав? А что, если это будут делать два эксперта независимо друг от друга? В этой статье мы поделимся общей методологией нормализации, которая может помочь в решение этой проблемы.
Изображение: Martinoflynn.com [1]
Чаще всего правила корреляции строятся на основе нормализованных событий. Таким образом, нормализация событий и то, насколько корректно она выполнена, напрямую влияет на точность правил корреляции.
Проблемы, возникающие при нормализации событий, мы сформулировали в первой статье (тут [2]), а пути их решения предложили в последующих статьях (тут [3] и тут [4]). Теперь обобщим ранее описанное и сформируем общий подход к нормализации событий.
Для начала напомним, какие инструменты уровня нормализации мы выработали:
Вся методология нормализации событий состоит из трех шагов:
Чтобы было проще понять, как работает инструмент, выберем событие и подробно рассмотрим все шаги нормализации согласно нашей методологии.
Пусть у нас есть источник — СУБД Oracle Database со следующей сетевой адресацией:
С данного источника агент SIEM выгружает следующее событие:
В самом начале процесса нормализации события важно понять, о чем это событие. Достаточно проговорить его суть про себя. Если эксперт, из исходного, еще не нормализованного, события не понимает, о каких процессах, протекающих на источнике, идет речь, — с большой вероятностью он некорректно его нормализует. Тогда о какой корректной работе правил корреляции может идти речь?
Проблема с тем, насколько эксперт корректно интерпретирует событие, вполне реальна. К примеру, можно ли не эксперту понять, что означает следующее событие?
Если в исходном примере суть можно уловить из текста самого события, то в данном случае нужно хорошо понимать, с каким источником вы работаете и в каких случаях он генерирует подобное событие. Иногда даже приходится разворачивать отдельный стенд с источником, чтобы в полном объеме воспроизвести ситуацию, в которой он отправляет в SIEM сложное и тяжело интерпретируемое событие.
Вернемся к исходному примеру [7] с событием от СУБД Oracle Database. На этом этапе эксперт должен размышлять так:
«Я как эксперт считаю, что исходное событие описывает процесс отзыва роли одним пользователем у другого в СУБД Oracle Database».
Предыдущий шаг позволяет убедиться, что мы можем понять хотя бы общий смысл события. Теперь детально разберем, как выделить сущности и определить схему их взаимодействия.
По этой методологии для каждой схемы взаимодействия [3] нужно описать правила распределения ключевых идентификаторов сущностей по полям нормализованного события. При этом, определены правила для:
Важно помнить, что есть схемы, в которых Субъект равен Объекту и равен Источнику. Для таких схем необходимо явно определить правила заполнения полей всех трех сущностей. Если этого не сделать, то, на уровне правил корреляции или поиске событий начнутся проблемы и появится дополнительная логика для корректной интерпретации пустых полей. Об этом – в статье, посвященной схемам взаимодействий [3].
Посмотрим работу этого шага методологии на исходном примере [7]:
Для данных схем могут быть определены следующие правила нормализации:
После того, как были выявлены все ключевые сущности события, необходимо описать суть самого процесса, отраженного в событии, и переложить ее на язык нормализации. Для этих целей служит система категоризации событий. Система категоризации событий была подробно рассмотрена в отдельной статье [4], теперь посмотрим, как она работает на практике.
Для того чтобы унифицировать нормализацию, система категоризации определяет следующие правила:
Таким образом, выбранная для события категория устанавливает прямое соответствие между:
Этот подход позволяет из категории любого события четко понять, какие данные в каких полях нормализованного события находятся.
Если при поддержке новых источников выясняется, что из событий определенной категории необходимо дополнительно извлечь еще какую-то важную информацию, то она заносится в справочник. В этом случае нужно:
Таким образом поддерживается консистентность вносимых изменений. Рассмотрим на исходном примере.
Согласно системе категоризации, данное событие имеет следующие категории:
Справочник для этой категории выглядит так:
Этот справочник мы привели для демонстрации принципа его формирования, поэтому он не претендует на точность и полноту.
В итоге событие, нормализованное по данной методологии, выглядит так:
Пример нормализованного события на третьем шаге методологии.
Опыт показывает, что зачастую к ложным срабатываниям правил корреляции приводят именно ошибки нормализации и отсутствие единых правил нормализации. Теперь у нас есть подход, который позволяет, если не избавиться, то хотя бы минимизировать влияние проблемы.
Итак, подытожим — подход включает в себя три шага:
Теперь от построения правил корреляции «работающих из коробки» нас отделяет лишь проблема постоянного изменения самих сущностей — активов. У них меняются адреса, вводятся новые активы, выводятся из эксплуатации старые, переключаются ноды кластера, а виртуальные машины переезжают из одного ЦОД в другой и, порой, даже со сменой адресации. Как победить эти проблемы, мы поговорим в следующей статье цикла.
Глубины SIEM: корреляции «из коробки». Часть 1: Чистый маркетинг или нерешаемая проблема? [8]
Глубины SIEM: корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира» [9]
Глубины SIEM: корреляции «из коробки». Часть 3.1. Категоризация событий [4]
Глубины SIEM: корреляции «из коробки». Часть 3.2. Методология нормализации событий (Данная статья)
Автор: nvnikolai
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/302762
Ссылки в тексте:
[1] Martinoflynn.com: http://martinoflynn.com
[2] тут: https://habr.com/company/pt/blog/423431/
[3] тут: https://habr.com/company/pt/blog/424975/
[4] тут: https://habr.com/company/pt/blog/432352/
[5] уровней сети и приложений: https://habr.com/company/pt/blog/424975/#NetworkAppLevels
[6] структуру: https://habr.com/company/pt/blog/424975/#ChannelModel
[7] примеру: #ExampleEvent
[8] Глубины SIEM: корреляции «из коробки». Часть 1: Чистый маркетинг или нерешаемая проблема?: https://habr.com/company/pt/blog/423431
[9] Глубины SIEM: корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира»: https://habr.com/company/pt/blog/424975
[10] Источник: https://habr.com/post/433606/?utm_campaign=433606
Нажмите здесь для печати.