Мы завершаем серию статей, посвященных правилам корреляции, которые работают «из коробки».
Нашей целью было сформулировать подход, который позволил бы нам создать правила корреляции, которые могли бы работать «из коробки» с минимальным количеством ложных срабатываний.
Изображение: Маркетинг программного обеспечения
Все ключевые моменты статьи доступны в заключение , где данная методика представлена в графическом виде схема .
Коротко о том, что было в предыдущих статьях: описали, как должен выглядеть набор полей нормализованного события — схема ; какая система категоризация использование событий; как унифицировать, используя систему категоризации и схему процесс нормализация событий.
Также рассматривается контекст выполнение правил корреляции и проанализировано, что SIEM должен знать об Автоматизированной системе (АС), которую он контролирует, и почему.
Все перечисленные выше подходы и рассуждения являются блоками, из которых строится методология разработки правил корреляции.
Пришло время собрать их вместе и увидеть картину целиком.
Вся методика разработки правил корреляции состоит из четырех блоков:
- подготовка источников и среды;
- нормализация событий и их обогащение;
- адаптация правил корреляции к контексту AS;
- формирование триггерного соглашения.
В связи с этим крайне важно, чтобы источники, необходимые для правил корреляции, присутствовали в АС и были правильно настроены.
Подготовка исходников и среды Шаг 1 : Продумайте общую логику правила и поймите, какие источники событий нужны.
Если вы разрабатываете с нуля или берете готовое Правило сигмы корреляция, то надо понимать на основе событий, от каких источников это будет работать.
Шаг 2 : Убедитесь, что все необходимые источники есть в компании и их можно собрать.
Возможна ситуация, когда правило действует по цепочке событий из нескольких источников вида (событие А из источника 1) - (событие Б из источника 2) - (событие С из источника 3) в течение 5 минут. Если у вашей компании нет хотя бы одного источника, такое правило становится бесполезным, так как оно никогда не сработает. Необходимо понять, возможен ли в принципе сбор событий из необходимых источников и может ли это обеспечить ваш SIEM. Например, источник записывает события в файл, но файл зашифрован, или источник использует для хранения нестандартную базу данных, доступ к которой невозможно обеспечить через стандартный драйвер ODBC/JDBC. Шаг 3 : Подключите источники к SIEM. Как бы тривиально это ни звучало, на этом этапе необходимо реализовать сам сбор событий.
Здесь часто возникает множество проблем.
Например, организационные проблемы, когда руководство ИТ категорически запрещает подключаться к критически важным системам.
Либо технические, когда без дополнительных настроек SIEM-агент (SmartConnector, Universal Forwarder) просто «убивает» источник при сборе событий, что приводит к отказу в обслуживании.
Такое часто можно наблюдать при подключении высоконагруженной СУБД к SIEM. Шаг 4 : Убедитесь, что аудит источников настроен правильно и SIEM получает события, необходимые для корреляции.
Правила корреляции предполагают определенные типы событий.
Они должны быть созданы источником.
Часто бывает, что для генерации необходимых для правил событий источник необходимо дополнительно настроить: включить расширенный аудит и настроить вывод журнала в определенном формате.
Включение расширенного аудита часто влияет на объем потока событий (EPS), поступающего в SIEM из источника.
В связи с тем, что сам источник и SIEM находятся в ведении разных отделов, всегда есть риск, что расширенный аудит может быть отключен и, как следствие, необходимые типы событий перестанут поступать в SIEM. Эту проблему можно частично выявить, отслеживая поток событий для каждого источника или, точнее, отслеживая изменения количества событий в секунду (EPS).
Шаг 5 : Убедитесь, что события происходят, и настройте мониторинг источников.
В любой инфраструктуре рано или поздно возникают сбои в работе сети или самого источника.
В этот момент SIEM теряет связь с источником и не может получать события.
Если источник пассивен и записывает свои логи в файл или базу данных, события не потеряются в случае сбоя и при восстановлении соединения SIEM сможет их получить.
Если источник активен и сам отправляет события в SIEM, например, через syslog, не сохраняя их больше нигде, то в случае сбоя события будут потеряны, и ваше правило корреляции просто не сработает, так как не будет работать.
дождаться нужного события.
Копнув глубже, можно увидеть, что даже при работе с пассивным источником, при восстановлении связи с ним после сбоя, нет никакой гарантии, что правила корреляции сработают, особенно те, которые работают на временных окнах.
Рассмотрим пример правила, описанного выше: (событие A из источника 1) — (событие B из источника 2) — (событие C из источника 3) в течение 5 минут. Если после события B произошел сбой и через час соединение восстановилось, то корреляция работать не будет, так как событие C не придет в течение ожидаемых 5 минут. Учитывая эти особенности, следует настроить мониторинг источников, из которых собираются события.
Этот мониторинг должен контролировать доступность источников, своевременность поступающих от них событий и мощность потока собираемых событий (СПС).
Срабатывание системы мониторинга является первым звонком, свидетельствующим о возникновении негативного фактора, влияющего на выполнение всех или части правил корреляции.
Нормализация событий и их обогащение Собрать события, необходимые для корреляции, недостаточно.
События, поступающие в SIEM, должны быть нормализованы строго в соответствии с принятыми правилами.
О проблемах нормализации и формировании методологии нормализации мы писали в отдельной статье.
статья .
В целом этот блок можно охарактеризовать как борьбу с мусором на входе, мусором на выходе( ГИГО ).
Нормализация и обогащение событий Шаг 6 И Шаг 7 : Категоризация событий и нормализация событий в соответствии с категорией на основе методики.
Мы не будем на них подробно останавливаться, так как подробно эти шаги мы рассмотрели в статье.
«Методология нормализации событий» .
Шаг 8 : Дополнение событий недостающей и дополнительной информацией в соответствии с категорией.
Часто поступающие события не всегда содержат информацию в объеме, необходимом для работы правил корреляции.
Например, событие содержит только IP-адрес узла, но не содержит информации о его полном доменном имени или имени узла.
Другой пример: событие содержит идентификатор пользователя, но имени пользователя в событии нет. В этом случае необходимую информацию следует получить из внешних источников — баз данных, контроллеров домена или других каталогов и добавить в событие.
Важно отметить, что категоризация событий происходит в самом начале – до нормализации.
Помимо того, что категория определяет правила нормализации события, она также определяет список данных, которые необходимо искать во внешних источниках, если они отсутствуют в самом событии.
Адаптация правил корреляции к контексту AS После того, как вы подготовили входные данные (события) и перешли к разработке правил корреляции, необходимо учитывать специфику входящих событий, самой АС и ее изменчивости.
Подробнее об этом было в статье «Модель системы как контекст для правил корреляции» .
Адаптация правил корреляции к контексту AS Шаг 9 : Поймите частоту событий от каждого источника и определите временное окно корреляции.
Довольно часто правила корреляции используют временные окна, когда необходимо дождаться прихода определенного события в течение заданного интервала времени.
При разработке таких правил важно учитывать задержку получения событий.
Обычно они вызваны двумя факторами.
Во-первых , сам источник не может сразу записывать события в базу данных, в файл или отправлять через системный журнал.
Время этой задержки должно быть оценено и учтено в правиле.
Во-вторых , происходит задержка доставки событий в SIEM. Например, сбор событий из базы данных настроен так, что запрос события выполняется раз в 10 минут; естественно, корреляционное окно в 5 минут в такой ситуации – не лучшее решение.
Проблема усугубляется, когда вам нужно разработать правило корреляции, которое будет обрабатывать события из нескольких источников одновременно.
В этом случае важно понимать, что сроки доставки могут различаться.
В худшем случае события будут происходить в случайном порядке и вне хронологии.
В такой ситуации разработчику правил корреляции необходимо четко понимать, в какое время SIEM реализует корреляцию (во время события или в момент поступления события в SIEM).
Отмечу, что корреляция по времени прихода событий является наиболее технически простым и распространенным вариантом обработки событий в псевдореальном времени.
Однако этот вариант лишь усугубляет описанные выше проблемы, а не решает их.
Если ваш SIEM обеспечивает корреляцию времени событий, то он, вероятно, имеет механизмы переупорядочения событий, которые могут восстановить фактическую хронологию событий.
В случае, когда вы понимаете, что временное окно слишком велико для выполнения корреляции на потоке, вам необходимо использовать механизм ретрокорреляции, при котором уже сохраненные события выбираются из базы данных SIEM по расписанию и прогоняются по правилам корреляции.
Шаг 10 : Установите механизм введения исключений.
В реальном мире всегда будет объект с особым поведением, который не следует обрабатывать по тому или иному правилу корреляции, так как это приведет к ложному срабатыванию.
Поэтому на этапе разработки правил необходимо заложить механизмы включения таких объектов в качестве исключений.
Например, если ваше правило работает с IP-адресами машин, вам нужна таблица-список, куда можно добавить адреса, для которых правило не будет работать.
Аналогично, если правило работает с логинами пользователей или именами процессов, необходимо заранее включить в логику правила работу с табличными списками исключений.
Такой подход позволит автоматически или вручную добавлять объекты в исключения, не переписывая тело самого правила.
Шаг 11 : Установите физические и логические пределы применимости правила корреляции.
При разработке правила корреляции важно изначально понимать границы применимости (сферы) правила и существуют ли они вообще.
При проработке логики и отладке правила необходимо акцентировать внимание на специфике этой области.
Если правило начинает работать с данными, выходящими за пределы этой области действия, вероятность ложных срабатываний возрастает. Существует два типа области действия: физическая и логическая.
Физическая область — это сети компании и смежные сети, а логическая — части АС, бизнес-приложений или бизнес-процессов.
Примеры физической области: сегмент DMZ, внутренние и внешние подсети, сети удаленного доступа.
Примеры логической области действия правил: системы управления процессами, учет, сегмент PCI DSS, сегмент PDn или просто конкретные роли оборудования — контроллеры домена, коммутаторы доступа, маршрутизаторы ядра.
Можно установить области действия правил корреляции с помощью списков таблиц.
Их можно заполнять как вручную, так и автоматически.
Если в вашей компании вы находите время для управления активами, то все необходимые данные уже могут содержаться в модели AS, созданной в SIEM. Автоматическое формирование таких табличных списков позволяет динамически включать в область новые активы, появляющиеся в компании.
Например, если у вас есть правило, которое работает только с контроллерами домена, добавление нового контроллера в лес домена будет зафиксировано в модели и будет находиться в области действия вашего правила.
В общем, списки таблиц, используемые для исключений, можно рассматривать как черные списки, а списки, используемые для сферы действия правил, можно рассматривать как белые списки.
Шаг 12 : Используйте модель AC, чтобы прояснить контекст. При разработке правила корреляции, обнаруживающего вредоносные действия, важно убедиться, что они действительно могут быть реализованы.
Если вы не учтете это, то срабатывание правила, обнаружившего потенциальную атаку, окажется ложным, поскольку данный тип атаки может быть просто неприменим к вашей инфраструктуре.
Поясню на примере:
- Давайте создадим правило корреляции, которое обнаруживает удаленные RDP-соединения с серверами.
- Брандмауэр передает событие попытки подключения на TCP-порт 3389 сервера myserver.local.
- Правило срабатывает, и вы начинаете разбираться с потенциальным инцидентом с высоким приоритетом.
Другой пример: IPS отправляет событие о срабатывании сигнатуры из-за попытки эксплуатации уязвимости CVE-2017-0144, но в ходе расследования выясняется, что на атакуемой машине установлен соответствующий патч и в этом нет необходимости.
реагировать на такой инцидент с наивысшим приоритетом.
Использование данных модели AC поможет смягчить эту проблему.
Шаг 13 : Используйте идентификаторы объектов, а не их исходные ключи.
Как уже описано в статье «Модель системы как контекст для правил корреляции» IP-адрес, полное доменное имя и даже MAC-адрес актива могут измениться.
Таким образом, если вы используете исходные идентификаторы активов в правиле корреляции или списке таблиц, то велика вероятность получить ложные срабатывания через какое-то время по совершенно тривиальной причине, например, DHCP-сервер просто выдал этот IP другой машине.
.
Если в вашей SIEM есть механизм идентификации активов, отслеживания их изменений и позволяющий вам работать с их идентификаторами, вам следует использовать идентификаторы, а не исходные ключи активов.
Заключение триггерного соглашения Подходя к завершающему блоку создания правила корреляции, напомним, что результатом действия правила является инцидент, занесенный в SIEM. На подобный инцидент должны отреагировать ответственные специалисты.
Хотя в цель данной серии статей не входит рассмотрение процесса реагирования на инциденты, следует отметить, что часть информации об инциденте генерируется уже на этапе создания соответствующего правила корреляции.
Далее мы рассмотрим основные моменты, которые необходимо учитывать при настройке параметров срабатывания правила корреляции и генерации инцидента.
Заключение триггерного соглашения Шаг 14 : Определить условия агрегации и отключения в случае большого количества ложных срабатываний.
На этапе отладки и даже во время его работы, если не придерживаться этой методики :), могут возникнуть ложные срабатывания правил.
Хорошо, если таких триггеров будет один-два в день, но что, если у одного правила тысячи или десятки тысяч триггеров? Конечно, это говорит о том, что правило нуждается в совершенствовании.
Однако необходимо следить за тем, чтобы в таких ситуациях происходило такое массовое ложное срабатывание:
- Не повлияло на производительность SIEM.
- Среди массы ложных тревог не затерялись по-настоящему важные происшествия.
Существует даже отдельный вид атак, направленный на сокрытие основной вредоносной активности за множеством ложных сообщений.
Механизм агрегации инцидентов позволит не создавать миллионы одинаковых инцидентов, а «склеивать» новые инциденты в один, при условии, что они идентичны.
В крайних случаях, когда даже агрегация инцидентов создает значительную нагрузку, рекомендуется настроить автоматическое отключение правила корреляции при превышении заданного количества триггеров в единицу времени (минуту, час, день).
Шаг 15 : Определить правила наименования происшествия.
Этим моментом часто пренебрегают, особенно если правила разрабатываются не для собственной компании, например, если за внедрение SIEM и разработку правил отвечает сторонняя компания.
Название правила корреляции, а также инцидент, который оно порождает, должно быть кратким и четко отражать суть конкретного правила.
Если в вашей компании с инцидентами и правилами корреляции работает более одного человека, рекомендуется разработать правила именования.
Их должна понять и принять вся команда SIEM. Шаг 16 : Определить правила определения важности инцидента.
Большинство SIEM-решений на последнем этапе создания инцидента позволяют задать его важность и значимость.
Некоторые решения даже автоматически рассчитывают важность на основе контекста инцидента и задействованных объектов.
Если ваш SIEM только автоматически рассчитывает важность инцидентов, стоит понять, на основании чего и по какой формуле она рассчитывается.
Например, если важность рассчитывается на основе значимости активов, вовлеченных в инцидент, к управлению активами компании необходимо заранее отнестись серьезно.
Если вы назначаете серьезность инцидента вручную, рекомендуется разработать формулу расчета, учитывающую как минимум следующее:
- Важность области действия правила.
Например, инцидент в зоне критически важных систем для миссии может быть более критичным, чем если бы точно такой же инцидент произошел в зоне важных для бизнеса систем.
- Важность активов и учетных записей пользователей, вовлеченных в инцидент.
- Повторение данного инцидента в компании.
выводы Подводя итог нашей серии статей, хотелось бы отметить, что, на мой взгляд, можно создать правила корреляции, работающие «из коробки».
Решением может стать сочетание организационного и технического подходов.
Некоторые вещи SIEM должен уметь сам, а другие должны выполняться и быть известны специалистам, которые его эксплуатируют. Подведем итоги:
- Метод состоит из следующих блоков:
- Подготовка источников и среды.
- Нормализация событий и их обогащение.
- Адаптация правил корреляции к контексту AS.
- Заключение триггерного соглашения.
- Подготовка источников и среды.
- Каждый блок имеет организационную и техническую составляющие.
- С технической точки зрения описанные блоки влияют практически на все базовые функции SIEM — от сбора событий до генерации инцидента.
- Практически всю техническую составляющую данной методологии могут обеспечить существующие зарубежные, а также некоторые отечественные SIEM-решения.
- Более подробное обсуждение и обоснование этапов этой методологии было представлено в предыдущих статьях серии.
Ссылки на них даны в конец статьи.
Методология разработки правил корреляции, которые работают «из коробки» Огромное спасибо всем, кто дочитал всю серию статей или хотя бы дочитал до этих строк.
Если у вас есть вопросы, пишите в личное сообщение или задавайте их в комментариях.
Буду рад обсудить.
Серия статей: Глубины SIEM: корреляции «из коробки».
Часть 1: Чистый маркетинг или неразрешимая проблема? Глубины SIEM: корреляции «из коробки».
Часть 2. Схема данных как отражение модели «мира» Глубины SIEM: корреляции «из коробки».
Часть 3.1. Категоризация событий Глубины SIEM: корреляции «из коробки».
Часть 3.2. Методика нормализации событий Глубины SIEM: корреляции «из коробки».
Часть 4. Модель системы как контекст правил корреляции Глубины SIEM: корреляции «из коробки».
Часть 5. Методика разработки правил корреляции ( Эта статья ) Теги: #информационная безопасность #Анализ и проектирование систем #siem #siem #SIEM #ib #нормализация данных #корреляция данных
-
Gmail Открыт Для Всех
19 Oct, 24 -
Призрак В Зене
19 Oct, 24 -
Пробираемся Через Желудок
19 Oct, 24 -
6 Способов Убить Agile
19 Oct, 24 -
Полезно Для Android-Разработчиков №2.
19 Oct, 24
