Можно ли категорировать все события, поступающие в SIEM, и какую систему категоризации для этого использовать? Как применить категории в правилах корреляции и поиске событий? Эти и другие вопросы мы разберем в новой статье из цикла, посвященного методологии создания работающих «из коробки» правил корреляции для SIEM-систем.
Изображение: Worktrooper
Статья подготовлена в соавторстве с Михаилом Максимовым и Александром Ковтуном.
Предупреждаем: статья большая, так как она описывает построение системы категоризации и наши цепочки рассуждений. Если вам лень читать ее целиком, то можно сразу перейти к разделу с выводами — там мы подытожили все, о чем говорили в статье, и обобщили результаты.
В предыдущей статье мы выяснили, что события содержат много важной информации, которую нельзя потерять в процессе нормализации. Описание схемы взаимодействия относится к такого рода данным. Для систематизации типов взаимодействия мы сделали следующее:
В результате анализа логов с различных типов программного и аппаратного обеспечения нам удалось выделить сущности: Субъект, Объект взаимодействия, Источник и Передатчик.
Теперь поговорим про семантику взаимодействия этих сущностей и ее отражение в категоризации событий. Прежде чем описывать подход к формированию и категории, нужно ответить на два вопроса: зачем нужно определять категории события и какими свойствами должна обладать система катетеризации.
Для начала определим, для чего необходимо категорировать события. Если коротко: категоризация нужна для того, чтобы одинаково работать с семантически схожими событиями независимо от типа источника. К типам источников мы относим основное назначение источника: сетевое оборудование, операционные системы, прикладное ПО. За фразой «одинаковым образом работать с семантически схожими событиями» стоит понимать следующее:
Чтобы все это получить, нужно сформировать систему категоризации событий и использовать ее при написании правил корреляции, расследовании инцидентов, и в случаях, если в организации с SIEM-системой работает более одного человека.
Что касается требований к системе категоризации, то она должна удовлетворять четырем свойствам:
Перейдем к описанию системы категоризации: начнем с двух больших доменов, к которым относятся подключаемые к SIEM источники событий и в которых они генерируют события.
Внедрение SIEM часто начинается с подключения источников, которые генерируют разнородные события. Важное свойство этих событий — то, что они отражают функциональность самих источников.
Можно выделить два глобальных домена:
Рассмотрим принципиальные различия между событиями этих доменов.
IT-источники сообщают о фактах происшествия каких-либо явлений в автоматизированной системе, без их оценки уровня защищенности — «хорошо» или «плохо». Примеры: применение новой конфигурации устройством, резервное копирование данных, передача файла по сети, отключение сетевого порта на коммутаторе.
В отличие от IT-источников, ИБ-источники обладают дополнительными внешними знаниями о том, как трактовать те или иные события с точки зрения безопасности, — политики. Таким образом, использование политик позволяет ИБ-источникам принимать решения — является ли наблюдаемое явление «хорошим» или «плохим» — и сообщать об этом в SIEM через сгенерированное ИБ-события.
Рассмотрим следующий пример: Так, в целом нейтральное событие передачи файла по сети расценивается межсетевым экраном уровня Next Generation как «плохое»: выясняется, что файл — документ Word, передаваемый из внутренней сети компании на внешний сервер по протоколу FTP, а настроенная политика запрещает такие информационные взаимодействия. Отключение сетевого порта трактуется как нарушение прав доступа решением по контролю действий администраторов: так как отключение порта делается пользователем Alex, у которого нет на это прав, и происходит в его нерабочее время, согласно настроенной политики безопасности.
Однако не совсем верно говорить, что ИБ-источники генерируют только ИБ-события. ИБ-источники генерируют ИБ- и IT-события. ИБ-источники генерируют IT-события, как правило, когда сообщают об изменении своего состояния: изменение конфигурации, переключение узлов кластера, резервное копирование. В целом эти события можно отнести к внутреннему аудиту действий и состояния источника. При этом, когда активность касается применения политик безопасности, этот же источник уже генерирует ИБ-события, тем самым сообщая о результатах их применения.
Мы сознательно так подробно описали различия между двумя доменами. События каждого домена несут в себе свой смысл и, порой, могут принципиально отличаются друг от друга. Эти отличия привели к существованию двух отдельных систем категоризации событий, отвечающих за IT-события и ИБ-события.
Домены событий
Существует еще один редкий тип источников, которые генерируют события отдельного, третьего домена —домена атак. События данного домена можно получать от источников уровня защиты конечных точек (Endpoint Protection), других нижестоящих SIEM (если они выстроены в иерархию), или иных решений, способных на базе анализа IT- и (или) ИБ-событий определить, что автоматизированная система или ее часть подвергается хакерской атаке.
В рамках этого цикла статей мы будем пользоваться следующими понятиями при разделении атак и ИБ-событий от конечных средств защиты:
Существует несколько подходов к категоризации атак, например, набирающая популярность MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), но этот домен мы не будем рассматривать в наших статьях.
Общесистемное прикладное программное и аппаратное обеспечение, которое мы относим к IT-источникам событий, призвано реализовывать или поддерживать определенные процессы для выполнения поставленных перед ним задач. В ходе их решения совершившиеся факты фиксируются отдельными IT-событиями. Их можно отнести к процессу, в рамках которого каждое из них произошло.
Выделив процессы, происходящие в IT-источниках, можно сформировать первый уровень категоризации (его в последствии мы назовем контекстом). Он будет определять семантическое поле, позволяющее верно интерпретировать IT-события.
При анализе событий становится понятно, что в каждом из них описывается взаимодействие нескольких сущностей в рамках уже определенного процесса. Выделяя как основную одну из этих сущностей в качестве объекта взаимодействия, формируем второй уровень категоризации.
Характер поведения основной сущности в событии в рамках конкретного процесса будет играть роль третьего уровня категоризации IT-событий.
Итого, на выходе мы получили следующие уровни:
Таким образом, мы сформировали три уровня категоризации IT-событий, позволяющие удобно оперировать семантически схожими событиями от различных типов источников в IT-инфраструктуре.
Чтобы обеспечить однозначность полученной системы категоризации, сформируем отдельные домены каждого уровня.
Система категоризации IT-событий. Первый уровень.
Схожий процессный подход к работе с IТ-системами применяется и в ITSM (IT Service Management, управление IТ-услугами), который постулирует о некоторых базовых процессах, проходящих в IТ-сервисах. На этот подход мы и будем опираться при формировании возможных процессов, или по-другому — контекстов, при рассмотрении IТ-источников событий.
Выделим основные процессы этого уровня:
Важно понимать, что различные процессы могут происходить на одном и том же IT-источнике. Так, например, в сервисе DHCP, развернутом в ОС Unix, могут происходить как процесс Network Management (генерируя, например, событие обновление IP-адреса у узлов), так и процесс System Management, генерируя событие перезапуска сервиса или ошибки разбора конфигурационного файла.
Система категоризации ИБ-событий. Первый и второй уровни.
Второй уровень отражает объект взаимодействия, описываемый в событии. Отметим, что в событии может описываться несколько сущностей. Например, возьмём следующее событие: «пользователь направил серверу сертификации запрос на выпуск личного сертификата». В событиях такого рода необходимо выбирать одну, основную, сущность в качестве объекта взаимодействия, которая является центральной в событии. Здесь мы можем определить, что основная сущность — «запрос к серверу сертификации», так как пользователь, очевидно, — это субъект взаимодействия, а личный сертификат — результат взаимодействия субъекта и объекта. Собирая и анализируя большой массив событий, можно выделить группы сущностей:
Эти группы не претендуют на роль всеобъемлющих, но покрывают основные задачи для назначения категорий второго уровня. При необходимости, представленные группы могут расширяться.
Система категоризации IT-событий. Первый, второй и третий уровни.
В рамках конкретного процесса характер поведения основной сущности можно свести к следующим значениям:
Последний домен выделяется среди прочих: он включает события, которые фактически не описывают никакого взаимодействия, но содержат информацию о сущности или переходах сущности между состояниями. Например, событие, описывающее лишь текущее состояние системы (о текущем системного времени, об изменении состояния лицензии на продукт).
События описывают не только само взаимодействие, но и его результат. Важно понимать, что от результата взаимодействия не зависит контекст, основная сущность, характер поведения объекта в рамках контекста. В качестве результата может быть «успех» и «неуспех». Также событие может описывать происходящий в настоящий момент процесс еще незавершенного взаимодействия. Назовем этот статус «происходящий в настоящее время».
Для каждого домена каждого уровня можно выделить определенный набор данных, содержащий события.
Разберем пример события:
Его можно трактовать как «соединение от узла 10.0.1.5 к узлу 192.168.149.2 было разорвано». Рассматривая контекст события, можно заметить, что в нем описывается сетевое соединение. Соответственно, мы попадаем в контекст «Network Interaction Management».
Далее определяем основную сущность в событии. Очевидно, что в событии описываются три сущности: два узла и сетевое соединение. Отталкиваясь от вышеуказанных рекомендаций, понимаем, что основная сущность в данном случае это именно сетевое соединение, а узлы — это участники взаимодействия, конечные точки, выполняющие действия над сущностью. Итого получаем основную сущность из домена «Сетевые соединения», а действие, выполняемое над сущностью, — «закрытие канала связи», что можно отнести к домену Communication.
Однако у нас есть еще довольно много данных, которые можно было бы сохранить из события. Так, набор сущностей второго уровня «Сетевые соединения» имеют общие свойства:
Также, к примеру, действие третьего уровня категоризации «закрытие соединения», принадлежащее домену Communication, может содержать следующие данные, вне зависимости от того, какое именно соединение было закрыто и какой источник об этом сообщил:
Еще в качестве примера можно выделить набор основных сущностей «Сущности хранения информации в ОС», для которых характерны следующие данные:
Относящийся к этой сущности набор действий, например, «копирование», который включается в домен третьего уровня «Manipulation», можно охарактеризовать такими свойствами:
Опционально мы можем получить все эти данные из события. Главное, что категория, которую мы определили, позволяет выделить определенный набор данных, который можно извлечь из события, заранее понимая, что эти данные будут семантически схожими.
И в этом отношении категории становятся удобным инструментом. Сопоставив каждому уровню доменов определенный набор таких данных, мы получаем возможность сохранить семантически схожие данные в одинаковые поля нормализованного события, вне зависимости от производителя и модели источника события. Это сильно упрощает поиск данных в большом объеме событий, а, следовательно, и осуществление корреляций по таким событиям.
Ситуация 1: Необходимо найти все события, в которых описывается подключение и отключение периферийных устройств от любых источников.
Каждый из источников генерирует события, после нормализации которых в полях Level 1 (первый уровень категоризации), Level 2 (второй уровень) и Level 3 (третий уровень) содержатся категории. В описанной ситуации все интересующие события будут содержать категории:
Домен первого уровня не столь важен, так как операции с оборудованием могут происходить в различных контекстах.
Таким образом, для отображения требуемых событий достаточно написать следующий запрос:
Ситуация 2: Необходимо найти все события, в которых описывается попытка изменения объектов файловой системы с именем, начинающимся на «boot».
Источники, подключенные к SIEM, могут производить совершенно различные события о модификации файлов. Однако назначение соответствующих категорий событиям позволяет выделить нужные из всего массива:
Кроме того, задано условие по имени файла: применяя заранее определенные наборы данных, можно ожидать, что для этой категории имя файла будет находиться в поле object.name. Следовательно, для выборки событий можно сформировать следующий запрос:
Если сущность была скопирована, мы найдем информацию о ней и о том, что она была скопирована из другой сущности, — это даст толчок к дальнейшему расследованию.
Ситуация 3: Необходимо обеспечивать простое профилирование сетевых соединений на пограничных маршрутизаторах различных производителей, установленных в филиалах компании. В SIEM поступают события от каждого из этих пограничных маршрутизаторов.
Каждый из маршрутизаторов генерирует IT-события, после нормализации которых в полях Level 1, Level 2, Level 3 содержатся категории. В описанном примере для профилирования необходимо и достаточно анализировать события об открытии и закрытии сетевых соединений. Согласно представленной системе категоризации, такие события будут содержать следующие поля категорий:
Дополнительно, для операций открытия и закрытия соединений, можно указать действия «open» и «close», а также статус действия «успех».
Кроме того, имея наборы данных для каждого из уровней категории, можно быть уверенным в том, что в событии об открытии соединения будет зафиксировано время начала этого соединения, а в событии закрытия соединения будет помещена информация об узлах — участниках сетевого взаимодействия, а также в полях «количество переданных байт», «количество переданных пакетов» и «длительность» будут помещены соответствующие данные о длительности соединения и количестве переданной информации соответственно.
Таким образом, фильтруя поток событий по указанным категориям и действиям, можно отобрать только необходимые события для осуществления операции профилирования, без необходимости указывать перечень конкретных идентификаторов событий.
Прежде чем говорить о системе категоризации, отметим, что мы будем рассматривать исключительно события, приходящие со средств защиты. Категоризация хакерских атак, как цепочек злонамеренных действий, — отдельная область со своей системой категоризации.
Система категоризации ИБ-событий основана на определенной парадигме. Она формулируется так: любой инцидент, который происходит в автоматизированной системе, имеет свое отражение в одной или сразу нескольких средах: уровня конкретного хоста, уровня сети, уровня физической среды.
Средства защиты, работающие на этих уровнях, выявляют инцидент или его «отголоски» и порождают ИБ-события, которые поступают на вход в SIEM.
Например, передача вредоносного файла по сети на конкретный хост может быть детектирована на уровнях сети и хоста, в процессе обработки сетевого трафика средствами сетевой защиты или анализа областей оперативной памяти соответствующими модулями антивирусных средств защиты.
Несанкционированный физический доступ в помещение может быть детектирован на уровне физической среды средствами СКУД и на уровне хоста, средствами СЗИ от НСД при авторизации пользователя на хост в нерабочее время.
При работе с событиями ИБ часто бывает необходимо понимать, в какой среде был зафиксирован инцидент. И уже исходя из этого строить дальнейший путь расследования или формировать логику правила корреляции. Таким образом, среда детектирования — первый уровень системы категоризации.
Система категоризации ИБ-событий. Первый уровень.
Второй уровень системы категоризации связан с первым, но имеет особенности, обусловленные следующими предпосылками:
Поэтому на втором уровне выделяется группа категорий, соответствующая нарушениям уровня физической среды, и группы категорий, общие для нарушений уровня сети и хоста.
Третий уровень системы категоризации уточняет второй и описывает непосредственно сами нарушения, суть которых и отражается в ИБ-событиях.
Мы проанализировали системы категоризации событий ИБ-решениях IBM QRadar, Micro Focus Arcsight и Maxpatrol SIEM для нарушений уровня сети и хоста. По итогам сделали вывод: все они очень похожи, а наиболее полной и объединяющей системой категоризации может служить eCSIRT.net mkVI. Именно она была взята за основу в приведенной ниже системе категоризации.
Система категоризации ИБ-событий. Нарушения уровня хоста и уровня сети.
Система категоризации ИБ-событий. Нарушения уровня физической среды.
Нарушения в физической среде, значимые с точки зрения информационной безопасности, имеют свою отдельную «ветку» в системе категоризации. Важно, что в этом случае система категоризации имеет всего один уровень.
Такое «урезанное» представление системы категоризации в первую очередь обусловлено крайне редкими случаями интеграции SIEM с физическими средствами защиты. Исключения — системы контроля и учета доступа (СКУД), довольно часто подключаемые к SIEM. В остальном при составлении данной «ветки» системы категоризации у нас не было достаточно статистических данных для систематизации именно этого направления.
Применим описанную систему категоризации для написания высокоуровневых правил корреляции и поиска событий в процессе расследования. Рассмотрим две ситуации.
Ситуация 1: средствами правила корреляции необходимо выявлять утечку конфиденциальной информации в следствии взлома активов автоматизированной системы. В SIEM поступают события от следующих средств защиты:
Каждое из них генерирует ИБ-события, после нормализации в полях Level1, Level2, Level3 которых содержатся проставленные категории.
Текст правила корреляции на псевдокоде может выглядеть следующим образом:
Ситуация 2: мы расследуем инцидент на конкретном хосте — alexhost.company.local. Необходимо понять, что с ним происходило в период с 04:00 по 06:00 08.11.2018 года. За это время в самом SIEM порядка 21 600 000 событий с этого хоста (средний поток событий равен 3000 EPS). Сейчас 11:00 09.11.2018, все события лежат в базе SIEM, на момент инцидента в SIEM не было установлено ни одного правила корреляции.
Очевидно, что проанализировать все события вручную — плохая идея. Необходимо как-то уменьшить их объем и локализовать проблему. Попробуем поискать интересующие нас события в этом множестве. Для примера запросов будет использован SQL-подобный синтаксис.
Мы описали принципы построения системы категоризации событий и выдвинули требования, которые определили подходы и принципы ее формирования. Исходя из специфики источников событий, подключаемых к SIEM, система категоризации была разделена на два направления: категоризации событий от IT-источников и категоризации событий от ИБ-источников.
Система категоризации IT-событий была сформирована на основе следующих принципов:
Система категоризации ИБ-событий сформирована на основе следующих принципов:
Также в статье были приведены примеры использования данной системы категоризации при написании правил корреляции и расследовании инцидентов.
Общая схема системы категоризации
Методологии поддержки источников событий будет посвящена отдельная статья. Методология объединит все уже описанное и покажет, как подойти к нормализации событий с позиции унификации. Ее применение избавит правила корреляции от ошибок в данных, поступающих в них в виде нормализованных событий, тем самым повысит их точность.
Цикл статей:
Глубины SIEM: корреляции «из коробки». Часть 1: Чистый маркетинг или нерешаемая проблема?
Глубины SIEM: корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира»
Глубины SIEM: корреляции «из коробки». Часть 3.1. Категоризация событий (Данная статья)
Изображение: Worktrooper
Статья подготовлена в соавторстве с Михаилом Максимовым и Александром Ковтуном.
Предупреждаем: статья большая, так как она описывает построение системы категоризации и наши цепочки рассуждений. Если вам лень читать ее целиком, то можно сразу перейти к разделу с выводами — там мы подытожили все, о чем говорили в статье, и обобщили результаты.
В предыдущей статье мы выяснили, что события содержат много важной информации, которую нельзя потерять в процессе нормализации. Описание схемы взаимодействия относится к такого рода данным. Для систематизации типов взаимодействия мы сделали следующее:
- выделили основные схемы, присущие любым типам событий;
- определили, какие именно сущности участвуют в схемах;
- сформировали базовый набор полей, необходимый для описания всех найденных в исходном событии сущностей и канала взаимодействий между ними.
В результате анализа логов с различных типов программного и аппаратного обеспечения нам удалось выделить сущности: Субъект, Объект взаимодействия, Источник и Передатчик.
Теперь поговорим про семантику взаимодействия этих сущностей и ее отражение в категоризации событий. Прежде чем описывать подход к формированию и категории, нужно ответить на два вопроса: зачем нужно определять категории события и какими свойствами должна обладать система катетеризации.
Для начала определим, для чего необходимо категорировать события. Если коротко: категоризация нужна для того, чтобы одинаково работать с семантически схожими событиями независимо от типа источника. К типам источников мы относим основное назначение источника: сетевое оборудование, операционные системы, прикладное ПО. За фразой «одинаковым образом работать с семантически схожими событиями» стоит понимать следующее:
- Семантически схожие события от любого типа источника имеют общую категорию.
- Для событий каждой категории определены четкие правила заполнения полей схемы. Так мы эффективно боремся с хаосом, который возникает на этапе нормализации событий и часто приводит к множественным ложным срабатываниям правил корреляции.
- Оперирование категориями позволяет не делать лишних проверок в коде правил корреляции, чтобы понять семантику события. К примеру, нет необходимости проверять определенные поля на наличие данных, чтобы определить, что событие описывает вход пользователя, а не резервное копирование системы.
- Категоризация — общая терминологическая база, которая помогает при написании правил корреляции и расследовании инцидентов, оперировать единым набором терминов и их общепринятых значений. К примеру, четко понимать, что изменение конфигурации сети и изменение конфигурации ПО — совершенно разные типы событий, несущие абсолютно разный смысл.
Чтобы все это получить, нужно сформировать систему категоризации событий и использовать ее при написании правил корреляции, расследовании инцидентов, и в случаях, если в организации с SIEM-системой работает более одного человека.
Что касается требований к системе категоризации, то она должна удовлетворять четырем свойствам:
- Однозначность. Одно и тоже событие должно быть отнесено к одной и только одной категории.
- Компактность. Общее количество категорий должно быть таким, чтобы их можно было легко запомнить эксперту.
- Иерархичность. Система должна строится по иерархической схеме и состоять из нескольких уровней, так как это наиболее простая для запоминания структура. При этом иерархия должна строиться по принципу «от общего к частному»: на первом уровне располагаются более «общие» категории, а на последнем — узкоспециализированные.
- Расширяемость. Принципы, по которым она построена, должны позволять вносить обновления в систему категоризации при появлении новых типов событий, требующих отдельных категорий, при этом не меняя основного подхода.
Перейдем к описанию системы категоризации: начнем с двух больших доменов, к которым относятся подключаемые к SIEM источники событий и в которых они генерируют события.
Домены источников и событий
Внедрение SIEM часто начинается с подключения источников, которые генерируют разнородные события. Важное свойство этих событий — то, что они отражают функциональность самих источников.
Можно выделить два глобальных домена:
- IT-источники — общесистемное прикладное программное и аппаратное обеспечение, порождающее IT-события.
- ИБ-источники — специализированное программное и аппаратное обеспечение информационной безопасности компании, порождающее ИБ-события.
Рассмотрим принципиальные различия между событиями этих доменов.
IT-источники сообщают о фактах происшествия каких-либо явлений в автоматизированной системе, без их оценки уровня защищенности — «хорошо» или «плохо». Примеры: применение новой конфигурации устройством, резервное копирование данных, передача файла по сети, отключение сетевого порта на коммутаторе.
В отличие от IT-источников, ИБ-источники обладают дополнительными внешними знаниями о том, как трактовать те или иные события с точки зрения безопасности, — политики. Таким образом, использование политик позволяет ИБ-источникам принимать решения — является ли наблюдаемое явление «хорошим» или «плохим» — и сообщать об этом в SIEM через сгенерированное ИБ-события.
Рассмотрим следующий пример: Так, в целом нейтральное событие передачи файла по сети расценивается межсетевым экраном уровня Next Generation как «плохое»: выясняется, что файл — документ Word, передаваемый из внутренней сети компании на внешний сервер по протоколу FTP, а настроенная политика запрещает такие информационные взаимодействия. Отключение сетевого порта трактуется как нарушение прав доступа решением по контролю действий администраторов: так как отключение порта делается пользователем Alex, у которого нет на это прав, и происходит в его нерабочее время, согласно настроенной политики безопасности.
Однако не совсем верно говорить, что ИБ-источники генерируют только ИБ-события. ИБ-источники генерируют ИБ- и IT-события. ИБ-источники генерируют IT-события, как правило, когда сообщают об изменении своего состояния: изменение конфигурации, переключение узлов кластера, резервное копирование. В целом эти события можно отнести к внутреннему аудиту действий и состояния источника. При этом, когда активность касается применения политик безопасности, этот же источник уже генерирует ИБ-события, тем самым сообщая о результатах их применения.
Мы сознательно так подробно описали различия между двумя доменами. События каждого домена несут в себе свой смысл и, порой, могут принципиально отличаются друг от друга. Эти отличия привели к существованию двух отдельных систем категоризации событий, отвечающих за IT-события и ИБ-события.
Домены событий
Существует еще один редкий тип источников, которые генерируют события отдельного, третьего домена —домена атак. События данного домена можно получать от источников уровня защиты конечных точек (Endpoint Protection), других нижестоящих SIEM (если они выстроены в иерархию), или иных решений, способных на базе анализа IT- и (или) ИБ-событий определить, что автоматизированная система или ее часть подвергается хакерской атаке.
В рамках этого цикла статей мы будем пользоваться следующими понятиями при разделении атак и ИБ-событий от конечных средств защиты:
- Атака — злонамеренная последовательность действий злоумышленника, направленных на достижение определенной цели внутри компании.
- Атака может стоять из одного или нескольких событий — цепочки ИБ-событий и/или IT-событий, являющимися нарушениями политик ИБ.
Существует несколько подходов к категоризации атак, например, набирающая популярность MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), но этот домен мы не будем рассматривать в наших статьях.
Система категоризации IТ-событий
Общесистемное прикладное программное и аппаратное обеспечение, которое мы относим к IT-источникам событий, призвано реализовывать или поддерживать определенные процессы для выполнения поставленных перед ним задач. В ходе их решения совершившиеся факты фиксируются отдельными IT-событиями. Их можно отнести к процессу, в рамках которого каждое из них произошло.
Выделив процессы, происходящие в IT-источниках, можно сформировать первый уровень категоризации (его в последствии мы назовем контекстом). Он будет определять семантическое поле, позволяющее верно интерпретировать IT-события.
При анализе событий становится понятно, что в каждом из них описывается взаимодействие нескольких сущностей в рамках уже определенного процесса. Выделяя как основную одну из этих сущностей в качестве объекта взаимодействия, формируем второй уровень категоризации.
Характер поведения основной сущности в событии в рамках конкретного процесса будет играть роль третьего уровня категоризации IT-событий.
Итого, на выходе мы получили следующие уровни:
- Контекст (процесс), в рамках которого произошло событие.
- Объект (основная сущность), описываемый событием.
- Характер поведения объекта в рамках заданного контекста.
Таким образом, мы сформировали три уровня категоризации IT-событий, позволяющие удобно оперировать семантически схожими событиями от различных типов источников в IT-инфраструктуре.
Чтобы обеспечить однозначность полученной системы категоризации, сформируем отдельные домены каждого уровня.
Система категоризации IT-событий. Первый уровень.
Схожий процессный подход к работе с IТ-системами применяется и в ITSM (IT Service Management, управление IТ-услугами), который постулирует о некоторых базовых процессах, проходящих в IТ-сервисах. На этот подход мы и будем опираться при формировании возможных процессов, или по-другому — контекстов, при рассмотрении IТ-источников событий.
Выделим основные процессы этого уровня:
- Business Continuity Management (управление непрерывностью работы) — события, связанные с операциями для поддержания непрерывной работы систем: процессы репликации, миграции и синхронизации виртуальных машин, баз данных и хранилищ, операции резервного копирования и восстановления;
- Users And Rights Management (управление пользователями и правами) — события, связанные с работой с группами и аккаунтами пользователей;
- Access Management (управление доступом) — события, связанные с процессами Authentication, Authorization, Accounting (ААА) и любыми попытками доступа в систему;
- Availability Management (управление доступностью) — события, связанные с любыми действиями по запуску, остановке, включению, выключению, прерыванию работы сущностей, включая информационные сообщения от систем контроля за доступностью сущности;
- Deployment Management (управление развертыванием) — события, связанные с привнесением в систему новых сущностей извне, а также с удалением сущности из этой системы;
- Network Interaction Management (управление сетевыми взаимодействиями) — события, связанные с передачей данных через сеть, включая установление соединений, открытие и закрытие туннелей;
- Network Management (управление сетью) — события, связанные с сетевым стеком: включая любые действия с политиками и правилами сетевой фильтрации;
- Virtual Infrastructure Management (управление виртуальной инфраструктурой) — события, связанные с инфраструктурой виртуализации;
- Database Management (управление базами данных) — события, связанные с функционированием СУБД и действиями пользователей и процессов в ней;
- System Management (управление системой) — события, связанные с функционированием операционной системы и ПО, являющимся частью операционной системы;
- Generic Application Management (управление прочими приложениями) — события, связанные с функционированием прочих приложений, установленных пользователем и не являющихся частью ОС.
Важно понимать, что различные процессы могут происходить на одном и том же IT-источнике. Так, например, в сервисе DHCP, развернутом в ОС Unix, могут происходить как процесс Network Management (генерируя, например, событие обновление IP-адреса у узлов), так и процесс System Management, генерируя событие перезапуска сервиса или ошибки разбора конфигурационного файла.
Второй уровень категоризации IТ-событий (сущности)
Система категоризации ИБ-событий. Первый и второй уровни.
Второй уровень отражает объект взаимодействия, описываемый в событии. Отметим, что в событии может описываться несколько сущностей. Например, возьмём следующее событие: «пользователь направил серверу сертификации запрос на выпуск личного сертификата». В событиях такого рода необходимо выбирать одну, основную, сущность в качестве объекта взаимодействия, которая является центральной в событии. Здесь мы можем определить, что основная сущность — «запрос к серверу сертификации», так как пользователь, очевидно, — это субъект взаимодействия, а личный сертификат — результат взаимодействия субъекта и объекта. Собирая и анализируя большой массив событий, можно выделить группы сущностей:
- идентифицирующие: аккаунт пользователя, группа пользователей, сертификат — сущности, которые позволяют идентифицировать пользователя либо систему;
- исполняемые: приложение, исполняемый модуль — все то, что может быть запущено операционной системой и содержит в себе определенный алгоритм;
- правила и политики: любые правила, политики доступа, включая групповые политики OC Windows;
- сущности хранения информации в ОС: файл, ключ реестра, объект группы каталогов — все то, что может выступать в качестве хранилища информации уровня приложений;
- сетевые соединения: сессии, потоки (flows), туннели — сущности, несущие в себе поток данных от одного узла к другому;
- сущности сетевой идентификации узла: сетевой адрес, сокет, непосредственно сам сетевой узел — все те сущности, без которых не обходится ни одна система мониторинга;
- сетевые L5-L7: почтовое сообщение, поток медиа-данных, список рассылки — сущности, передающие информацию на уровнях L5-L7 модели OSI;
- служебные сетевые: DNS зона, таблица маршрутизации. Эти сущности отвечают за корректное функционирование сети, не неся полезной нагрузки для конечного пользователя;
- сущности отказоустойчивых конфигураций: RAID, элементы кластерной сети;
- сущности систем виртуализации: виртуальные машины, виртуальные жесткие диски, снимки виртуальных машин;
- сущности баз данных: таблицы, базы данных, СУБД;
- физическое оборудование: подключаемые устройства, элементы СКУД (турникеты, IP-камеры);
- прочие сущности ОС: команда в консоли управления, системная консоль, системный журнал — те сущности ОС, которые не подошли к прочим категориям;
- прочие сетевые сущности: сетевой интерфейс, общедоступный сетевой ресурс — те сущности сетевой подсистемы, которые не подошли к прочим категориям.
Эти группы не претендуют на роль всеобъемлющих, но покрывают основные задачи для назначения категорий второго уровня. При необходимости, представленные группы могут расширяться.
Третий уровень категоризации IT-событий (характер взаимодействия)
Система категоризации IT-событий. Первый, второй и третий уровни.
В рамках конкретного процесса характер поведения основной сущности можно свести к следующим значениям:
- Control — взаимодействие, влияющее на функционирование сущности;
- Communication — коммуникация между сущностями;
- Manipulation — действия по работе с самой сущностью, включая манипуляцию ее данными;
- Embedding — взаимодействие, в результате которого происходит добавление новой сущности в контекст (либо удаление сущности из контекста);
- State — информационные события об изменении состояния сущности.
Последний домен выделяется среди прочих: он включает события, которые фактически не описывают никакого взаимодействия, но содержат информацию о сущности или переходах сущности между состояниями. Например, событие, описывающее лишь текущее состояние системы (о текущем системного времени, об изменении состояния лицензии на продукт).
События описывают не только само взаимодействие, но и его результат. Важно понимать, что от результата взаимодействия не зависит контекст, основная сущность, характер поведения объекта в рамках контекста. В качестве результата может быть «успех» и «неуспех». Также событие может описывать происходящий в настоящий момент процесс еще незавершенного взаимодействия. Назовем этот статус «происходящий в настоящее время».
Формирование набора данных на основе трех уровней
Для каждого домена каждого уровня можно выделить определенный набор данных, содержащий события.
Разберем пример события:
Его можно трактовать как «соединение от узла 10.0.1.5 к узлу 192.168.149.2 было разорвано». Рассматривая контекст события, можно заметить, что в нем описывается сетевое соединение. Соответственно, мы попадаем в контекст «Network Interaction Management».
Далее определяем основную сущность в событии. Очевидно, что в событии описываются три сущности: два узла и сетевое соединение. Отталкиваясь от вышеуказанных рекомендаций, понимаем, что основная сущность в данном случае это именно сетевое соединение, а узлы — это участники взаимодействия, конечные точки, выполняющие действия над сущностью. Итого получаем основную сущность из домена «Сетевые соединения», а действие, выполняемое над сущностью, — «закрытие канала связи», что можно отнести к домену Communication.
Однако у нас есть еще довольно много данных, которые можно было бы сохранить из события. Так, набор сущностей второго уровня «Сетевые соединения» имеют общие свойства:
- инициатор соединения (адрес + порт + интерфейс);
- получатель (цель) соединения (адрес + порт + интерфейс);
- протокол, по которому выполняется соединение.
Также, к примеру, действие третьего уровня категоризации «закрытие соединения», принадлежащее домену Communication, может содержать следующие данные, вне зависимости от того, какое именно соединение было закрыто и какой источник об этом сообщил:
- количество переданных/отправленных байт;
- количество переданных/отправленных пакетов;
- длительность.
Еще в качестве примера можно выделить набор основных сущностей «Сущности хранения информации в ОС», для которых характерны следующие данные:
- имя сущности;
- путь расположения сущности в ОС;
- размер сущности;
- привилегии доступа к сущности.
Относящийся к этой сущности набор действий, например, «копирование», который включается в домен третьего уровня «Manipulation», можно охарактеризовать такими свойствами:
- новое имя сущности;
- новый путь расположения сущности;
- новые привилегии доступа к сущности.
Опционально мы можем получить все эти данные из события. Главное, что категория, которую мы определили, позволяет выделить определенный набор данных, который можно извлечь из события, заранее понимая, что эти данные будут семантически схожими.
И в этом отношении категории становятся удобным инструментом. Сопоставив каждому уровню доменов определенный набор таких данных, мы получаем возможность сохранить семантически схожие данные в одинаковые поля нормализованного события, вне зависимости от производителя и модели источника события. Это сильно упрощает поиск данных в большом объеме событий, а, следовательно, и осуществление корреляций по таким событиям.
Примеры использования системы категоризации
Ситуация 1: Необходимо найти все события, в которых описывается подключение и отключение периферийных устройств от любых источников.
Каждый из источников генерирует события, после нормализации которых в полях Level 1 (первый уровень категоризации), Level 2 (второй уровень) и Level 3 (третий уровень) содержатся категории. В описанной ситуации все интересующие события будут содержать категории:
- Level 2: Физическое оборудование;
- Level 3: Embedding.
Домен первого уровня не столь важен, так как операции с оборудованием могут происходить в различных контекстах.
Таким образом, для отображения требуемых событий достаточно написать следующий запрос:
Select * from events where Level2 = “<один из элементов из сущностей физического оборудования>” and Level3 = “Embedding” and time between (<временной диапазон>)Ситуация 2: Необходимо найти все события, в которых описывается попытка изменения объектов файловой системы с именем, начинающимся на «boot».
Источники, подключенные к SIEM, могут производить совершенно различные события о модификации файлов. Однако назначение соответствующих категорий событиям позволяет выделить нужные из всего массива:
- Level 1: System Management;
- Level 2: Сущности хранения информации в ОС;
- Level 3: Manipulation.
Кроме того, задано условие по имени файла: применяя заранее определенные наборы данных, можно ожидать, что для этой категории имя файла будет находиться в поле object.name. Следовательно, для выборки событий можно сформировать следующий запрос:
Select * from events where Level1 = “System Management” and Level2 = “<один из элементов из сущностей хранения информации в ОС>” and Level3 = “Manipulation” and (object.name like “boot.%”)Если сущность была скопирована, мы найдем информацию о ней и о том, что она была скопирована из другой сущности, — это даст толчок к дальнейшему расследованию.
Ситуация 3: Необходимо обеспечивать простое профилирование сетевых соединений на пограничных маршрутизаторах различных производителей, установленных в филиалах компании. В SIEM поступают события от каждого из этих пограничных маршрутизаторов.
Каждый из маршрутизаторов генерирует IT-события, после нормализации которых в полях Level 1, Level 2, Level 3 содержатся категории. В описанном примере для профилирования необходимо и достаточно анализировать события об открытии и закрытии сетевых соединений. Согласно представленной системе категоризации, такие события будут содержать следующие поля категорий:
- Level 1: Network Interaction Management;
- Level 2: Сетевые соединения;
- Level 3: Communication.
Дополнительно, для операций открытия и закрытия соединений, можно указать действия «open» и «close», а также статус действия «успех».
Кроме того, имея наборы данных для каждого из уровней категории, можно быть уверенным в том, что в событии об открытии соединения будет зафиксировано время начала этого соединения, а в событии закрытия соединения будет помещена информация об узлах — участниках сетевого взаимодействия, а также в полях «количество переданных байт», «количество переданных пакетов» и «длительность» будут помещены соответствующие данные о длительности соединения и количестве переданной информации соответственно.
Таким образом, фильтруя поток событий по указанным категориям и действиям, можно отобрать только необходимые события для осуществления операции профилирования, без необходимости указывать перечень конкретных идентификаторов событий.
Система категоризации ИБ-событий
Прежде чем говорить о системе категоризации, отметим, что мы будем рассматривать исключительно события, приходящие со средств защиты. Категоризация хакерских атак, как цепочек злонамеренных действий, — отдельная область со своей системой категоризации.
Система категоризации ИБ-событий основана на определенной парадигме. Она формулируется так: любой инцидент, который происходит в автоматизированной системе, имеет свое отражение в одной или сразу нескольких средах: уровня конкретного хоста, уровня сети, уровня физической среды.
Средства защиты, работающие на этих уровнях, выявляют инцидент или его «отголоски» и порождают ИБ-события, которые поступают на вход в SIEM.
Например, передача вредоносного файла по сети на конкретный хост может быть детектирована на уровнях сети и хоста, в процессе обработки сетевого трафика средствами сетевой защиты или анализа областей оперативной памяти соответствующими модулями антивирусных средств защиты.
Несанкционированный физический доступ в помещение может быть детектирован на уровне физической среды средствами СКУД и на уровне хоста, средствами СЗИ от НСД при авторизации пользователя на хост в нерабочее время.
При работе с событиями ИБ часто бывает необходимо понимать, в какой среде был зафиксирован инцидент. И уже исходя из этого строить дальнейший путь расследования или формировать логику правила корреляции. Таким образом, среда детектирования — первый уровень системы категоризации.
Первый уровень системы категоризации ИБ-событий
Система категоризации ИБ-событий. Первый уровень.
- Host violations (нарушения уровня хоста) — события, поступающие от средств защиты, устанавливающихся на конечные рабочие станции и сервера. Как правило, ИБ-события данного уровня описывают срабатывания политик безопасности в результате анализа внутреннего состояния хоста средствами защиты. Под анализом внутреннего состояния здесь понимается анализ запущенных процессов, данных в областях оперативной памяти, файлов на диске.
Типы источников событий: антивирусные средства защиты, системы контроля целостности, системы обнаружения вторжений уровня хоста, системы контроля и разграничения доступа. - Network violations (нарушения уровня сети) — события, поступающие от систем, анализирующих сетевой трафик и применяющие к нему набор установленных политик безопасности.
Типы источников событий: средства межсетевого экранирования, системы обнаружения и предотвращения вторжений, системы обнаружения DDoS. Некоторые хостовые средства защиты также имеют отдельные модули анализа сетевого трафика. К примеру, антивирусные средства защиты и некоторые отечественные СЗИ от НСД. - Physical violations (нарушения уровня физической среды) — события, поступающие от средств физической безопасности.
Типы источников событий: системы охраны периметра, СКУДы, системы защиты от утечек информации по виброакустическим каналам и каналам ПЭМИН.
К этой категории также относятся инциденты, выявленные службой физической или экономической безопасности в процессе внутренних мероприятий и заведенные во внутренние базы компании, информация из которых может собираться SIEM. Из-за некоторых организационных причин — это крайне редкий, но все же возможный случай.
Второй и третий уровень системы категоризации ИБ-событий
Второй уровень системы категоризации связан с первым, но имеет особенности, обусловленные следующими предпосылками:
- инциденты информационной безопасности не всегда имеют проявления в физической среде;
- инциденты в физической среде не всегда связаны с инцидентами информационной безопасности, но бывают и пересечения;
- инциденты на уровнях сети и конечного хоста часто имеют схожую структуру и семантику.
Поэтому на втором уровне выделяется группа категорий, соответствующая нарушениям уровня физической среды, и группы категорий, общие для нарушений уровня сети и хоста.
Третий уровень системы категоризации уточняет второй и описывает непосредственно сами нарушения, суть которых и отражается в ИБ-событиях.
Мы проанализировали системы категоризации событий ИБ-решениях IBM QRadar, Micro Focus Arcsight и Maxpatrol SIEM для нарушений уровня сети и хоста. По итогам сделали вывод: все они очень похожи, а наиболее полной и объединяющей системой категоризации может служить eCSIRT.net mkVI. Именно она была взята за основу в приведенной ниже системе категоризации.
Система категоризации ИБ-событий. Нарушения уровня хоста и уровня сети.
- Abusive Content (зловредный контент) — контент, доставленный легальным образом до конечного пользователя, побуждающий к противоправным действиям (умышленным или не умышленным) или содержащий зловредные/мусорные данные.
Категории третьего уровня: Spam, Phishing.
Типы источников событий: proxy-сервера с контролем контента (Microsoft Threat Management Gateway), средства защиты веб-трафика (Cisco Web Security Appliance, Check Point URL filtering blade), средства защиты почты (Cisco Email Security Appliance, Kaspersky Secure Mail Gateway), средства защиты конечных хостов со встроенными модулями контроля web и email (McAfee Internet Security, Kaspersky Internet Security). - Information Gathering (сбор данных) — сбор данных об объекте защиты из открытых и закрытых источников информации, используя активные и пассивные методы сбора.
Категории третьего уровня: Fingerprinting, Sniffing, Scanning, Bruteforce.
Типы источников событий: как правило, сетевые средства защиты, а именно: межсетевые экраны (Cisco Adaptive Security Appliance, Checkpoint Firewall blade), средства обнаружения и предотвращения вторжений (Cisco Firepower Next—Generation IPS, Check Point IPS blade). - Availability (Нарушение доступности) — злонамеренное или случайное нарушение доступности отдельных сервисов и систем в целом.
Категории третьего уровня: DDoS, DoS, Flood.
Типы источников событий: межсетевые экраны и системы обнаружения и предотвращения вторжений, а также системы выявления и блокировки сетевых DoS-атак (Arbor Pravail APS, Arbor Peakflow SP, Radware DefensePro, МФИ Софт АПК «Периметр»). - Vulnerability Exploration (обнаружение уязвимости) — выявление уязвимости или группы уязвимостей. Важно отметить, что эта категория описывает именно ИБ-события об обнаружении уязвимости, но не ее эксплуатация.
Категории третьего уровня: Firmware, Software.
Типы источников событий: события со встроенного в SIEM или интегрированного внешнего сканера безопасности и аудита (Tenable Nessus Vulnerability Scanner, Positive Technologies Maxpatrol 8, Positive Technologies XSpider, Qualys Vulnerability Scanner, Burp Suit). - Vulnerability Exploitation (эксплуатация уязвимости) — выявление целенаправленного негативного воздействия на систему или эксплуатацию уязвимости системы. В данном случае, часто к категориям третьего уровня могут относится отдельные техники атак, приведенные в MITRE ATT&CK(ссылка) и определяемые средствами защиты.
Категории третьего уровня: XML External Entities, Cross Site Scripting, Insecure Deserialization, Routing Poisoning и т.д.
Типы источников событий: системы обнаружения и предотвращения вторжений уровня сети (Positive Technologies Network Attack Discovery, Positive Technologies Web Application Firewall, Imperva Web Application Firewall, Cisco Firepower Next Generation IPS, Check Point IPS blade,) или уровня хоста (Carbon Black Cb Defense, HIPS модули антивирусных средств защиты, OSSEC). - Hacktool (хакерские утилиты) —использование утилит, применяемых для взлома систем или реализации иных противоправных действий для получение конфиденциальной информации и обхода средств защиты.
Категории третьего уровня: Scanner, Bruteforcer, Exploit Kit, Password dumper, Vulnerability scanner, TOR client, Sniffer, Shellcode, Keylogger.
Типы источников событий: системы обнаружения и предотвращения вторжений уровня сети и уровня хоста, сканеры безопасности и аудита, антивирусные средства защиты. - Malicious Code (Вредоносный код) — выявление использования вредоносного кода.
Категории третьего уровня: Virus, Worm, Botnet, Rootkit, Bootkit, Trojan, Backdoor, Cryptor.
Типы источников событий: любые сетевые и хостовые антивирусные средства защиты, системы обнаружения и предотвращения вторжений уровня сети. - Compliance (нарушение комплаенса) — выявление фактов невыполнения проверок, определенных в политиках комплаенса. В данном случае под политиками комплаенса понимаются требования PCI DSS, Приказа ФСТЭК №21, корпоративных стандартов безопасности.
Категории третьего уровня: Integrity control, OS settings control, Application settings сontrol.
Типы источников событий: сканеры безопасности и аудита. - Information Leak (утечка информации) — выявление утечки конфиденциальных данных по любым коммуникационным каналам.
Категории третьего уровня: Email, Messenger, Social net, Mobile device, Removable storage.
Типы источников событий: Системы предотвращения утечек данных (Ростелеком—Solar Dozor, InfoWatch Traffic Monitor). - Anomaly (аномалии) — существенные отклонение параметров объекта защиты или его поведения от ранее установленной нормы.
Категории третьего уровня: Statistical, Behavioral.
Типы источников событий: сетевые средства защиты нового поколения (Next Generation), системы предотвращения утечек данных, системы класса User and Entity Behavior Analytics (Splunk User Behavior Analytics, Securonix User and Entity Behavior Analytics, Exabeam Advanced Analytics).
Система категоризации ИБ-событий. Нарушения уровня физической среды.
Нарушения в физической среде, значимые с точки зрения информационной безопасности, имеют свою отдельную «ветку» в системе категоризации. Важно, что в этом случае система категоризации имеет всего один уровень.
Такое «урезанное» представление системы категоризации в первую очередь обусловлено крайне редкими случаями интеграции SIEM с физическими средствами защиты. Исключения — системы контроля и учета доступа (СКУД), довольно часто подключаемые к SIEM. В остальном при составлении данной «ветки» системы категоризации у нас не было достаточно статистических данных для систематизации именно этого направления.
- Theft (кража) — кража физических носителей или вычислительных средств (ноутбуки, планшеты, смартфоны) с конфиденциальной информацией с территории компании или у сотрудников компании.
Типы источников событий: базы инцидентов службы физической безопасности, кадровые системы. - Intrusion (физическое проникновение) — несанкционированный или нерегламентированный обход физической системы защиты.
Типы источников событий: базы инцидентов службы физической безопасности, СКУД, системы охраны периметра. - Damage (повреждение) — целенаправленное повреждение, уничтожение, снижение срока эксплуатации оборудования или каналов связи.
Типы источников событий: базы инцидентов службы физической безопасности.
Примеры использования систем категоризации
Применим описанную систему категоризации для написания высокоуровневых правил корреляции и поиска событий в процессе расследования. Рассмотрим две ситуации.
Ситуация 1: средствами правила корреляции необходимо выявлять утечку конфиденциальной информации в следствии взлома активов автоматизированной системы. В SIEM поступают события от следующих средств защиты:
- системы предотвращения утечек данных;
- системы обнаружения и предотвращения вторжений уровня сети;
- системы обнаружения и предотвращения вторжений уровня хоста;
- антивирусное средство защиты.
Каждое из них генерирует ИБ-события, после нормализации в полях Level1, Level2, Level3 которых содержатся проставленные категории.
Текст правила корреляции на псевдокоде может выглядеть следующим образом:
# В потоке находим события от любых подключенных систем защиты. Назовем это событие «Host_poisoning
event Host_poisoning»:
# Нам важно смотреть на события на каждом хосте в отдельности, поэтому мы их сгруппируем по заданному полю
group by dst.host # В этом поле лежит hostname/fqdn/ip хоста, на котором происходят нарушения
filter {
Level2 = “Malicious Code” OR
Level2 = “Vulnerability Exploitation”
}
# Теперь в потоке событий находим событие от системы предотвращения утечек данных:
event Data_leak:
group by dst.host
filter {
Level2 = “Information Leak” AND
Level3 = “Email” # К примеру попробуем выявить утечку через почту
}
# Описание самого правила с именем Host_poisoning_and_data_leakage: ждем событие «Host_poisoning», а потом «Data_leak» в течение 24 часов на одном и том же хосте:
rule Host_poisoning_and_data_leakage: (Host_poisoning —> Data_leak) within 24h
emit {
# Делаем что—то полезное при срабатывании
}Ситуация 2: мы расследуем инцидент на конкретном хосте — alexhost.company.local. Необходимо понять, что с ним происходило в период с 04:00 по 06:00 08.11.2018 года. За это время в самом SIEM порядка 21 600 000 событий с этого хоста (средний поток событий равен 3000 EPS). Сейчас 11:00 09.11.2018, все события лежат в базе SIEM, на момент инцидента в SIEM не было установлено ни одного правила корреляции.
Очевидно, что проанализировать все события вручную — плохая идея. Необходимо как-то уменьшить их объем и локализовать проблему. Попробуем поискать интересующие нас события в этом множестве. Для примера запросов будет использован SQL-подобный синтаксис.
- Узнаем, что «видели» средства защиты в это время:
Select * from events where Level1 in (“Host violations”, “Network violations”, “Physical violations”) and dst.dost=“alexhost.company.local” and time between (<временной диапазон>)
Пусть на этот запрос мы получили 10 000 событий из доменов Host violations и Network violations. Все равно много, для ручного анализа. - Попробуем понять, могло ли в процессе инцидента произойти взлом хоста, при этом нам не важно какие средства защита это вывили.
Select * from events where Level2 in (“Vulnerability Exploitation”) and dst.dost=“alexhost.company.local” and time between (<временной диапазон>)
Пусть на этот запрос мы получили 500 событий от систем обнаружения и предотвращения вторжений уровня сети и хоста. Отлично! С этим уже можно поработать вручную. - В процессе расследования мы поняли, что взлом произошел изнутри компании. Попробуем узнать, «видело» ли какое-то из средств защиты установку или выполнение хакерских утилит на любом из хостов компании.
Select * from events where Level3 = “Exploit kit” and time between (<последние 3 дня>)
Выводы
Мы описали принципы построения системы категоризации событий и выдвинули требования, которые определили подходы и принципы ее формирования. Исходя из специфики источников событий, подключаемых к SIEM, система категоризации была разделена на два направления: категоризации событий от IT-источников и категоризации событий от ИБ-источников.
Система категоризации IT-событий была сформирована на основе следующих принципов:
- IT-события отражают этапы или детали IT-процессов, которые поддерживаются или реализуются источниками событий.
- Система категоризации состоит из 3-х основных уровней и одного дополнительного, определяющего успешность или не успешность действия, описанного в событии.
- На первом уровне выделяются IT-процессы, в рамках которых работает источник событий.
- Второй уровень описывает основные сущности, которые участвуют в данном процессе.
- Третий уровень определяет то, какие действия выполняются этой или над этой сущностью в рамках процесса.
- Дополнительный уровень описывает статус данных действий (успех, неуспех).
Система категоризации ИБ-событий сформирована на основе следующих принципов:
- Категоризация применяется исключительно к ИБ-событиям, собираемых со средств защиты и не затрагивает категоризацию атак на автоматизированные системы. Отличия атак от ИБ-событий средств защиты были даны в начале статьи.
- Система категоризации состоит из 3-х уровней.
- На первом уровне выделяются домены, в которых могут быть зафиксированы нарушения ИБ: нарушения уровня хоста, сети и физической среды.
- Второй уровень категоризации образуют конкретные классы нарушений.
- Третий уровень образуют конкретные типы нарушений, определяемые в рамках заданного класса.
Также в статье были приведены примеры использования данной системы категоризации при написании правил корреляции и расследовании инцидентов.
Общая схема системы категоризации
Методологии поддержки источников событий будет посвящена отдельная статья. Методология объединит все уже описанное и покажет, как подойти к нормализации событий с позиции унификации. Ее применение избавит правила корреляции от ошибок в данных, поступающих в них в виде нормализованных событий, тем самым повысит их точность.
Цикл статей:
Глубины SIEM: корреляции «из коробки». Часть 1: Чистый маркетинг или нерешаемая проблема?
Глубины SIEM: корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира»
Глубины SIEM: корреляции «из коробки». Часть 3.1. Категоризация событий (Данная статья)