Как использовать все преимущества SIEM-системы для конкретной компании

При выборе и оценке SIEM-систем обычно обращают внимание прежде всего на количественные характеристики ее контента. Указывают, сколько правил корреляции доступно сразу после установки, сколько новых сценариев добавили за определенный период и какую часть техник MITRE ATT&CK они охватывают. Эти показатели полезны: они дают общее представление о масштабе и развитии системы. Мы тоже время от времени делимся подобными цифрами. Однако большое число правил само по себе не делает SIEM надежнее и не гарантирует, что она будет эффективнее выявлять угрозы именно в вашей организации.

Правило корреляции — не универсальный защитный механизм, который начинает приносить пользу просто потому, что появился в интерфейсе. Количество правил скорее показывает, насколько широк круг возможных сценариев использования платформы. Для специалиста, который ежедневно работает с SIEM, важнее практический вопрос: какие из этих сценариев применимы к инфраструктуре компании и смогут обнаруживать в ней подозрительные действия? Ответ зависит не только от качества или точности правил. Не менее важно, какие данные поступают в систему и есть ли в них события, необходимые для работы конкретного сценария.

От чего зависит работа правила корреляции

В основе правила лежит заданная логика обработки событий. В нем описывается, какие данные нужно сопоставить, в какой последовательности следует искать связанные действия и за какой промежуток времени они должны произойти. Например, правило может сработать, только если система увидит несколько определенных событий в заданном порядке и в пределах установленного временного окна.

Помимо логики, правило обычно привязано к конкретным типам событий и источникам, из которых эти события должны поступать. Один сценарий может анализировать журналы безопасности Windows, другой — DNS-запросы, третий — телеметрию, собираемую с рабочих станций и серверов. Поэтому фактическая работоспособность правила напрямую связана с тем, подключены ли соответствующие источники к SIEM, настроен ли сбор данных и поступает ли необходимая информация в нужном формате.

Рассмотрим правило, которое отслеживает создание новой группы в Active Directory. Для его работы SIEM должна получать события из соответствующих журналов Windows. Если такие журналы не подключены, нужные записи не передаются или в компании вообще не используется Windows-инфраструктура, правило не сможет обнаружить целевое действие. При этом оно может успешно загрузиться в систему, отображаться в списке контента и выглядеть полностью готовым к применению. Формально правило присутствует, но практически оно бесполезно: событие, на которое оно настроено, в SIEM не поступает и, следовательно, условие для срабатывания никогда не выполняется.

Та же зависимость действует и для других сценариев. Правило, предназначенное для выявления подозрительной сетевой активности, не даст результата без необходимых сетевых данных, например DNS-запросов. А обнаружение манипуляций с процессами потребует телеметрии с конечных устройств. Если соответствующие источники отсутствуют или передают неполную информацию, правило не сможет корректно анализировать происходящее — независимо от того, насколько хорошо оно написано.

Почему начинать нужно с источников данных

Эта особенность определяет правильную последовательность настройки SIEM. Не следует сначала изучать длинный каталог правил и пытаться под него подстроить инфраструктуру. Гораздо эффективнее начать с инвентаризации источников: выяснить, какие системы и устройства используются в организации, какие из них уже подключены к SIEM, какие данные они передают и насколько полно эти данные покрывают необходимые события.

После этого можно сопоставить доступную телеметрию с правилами корреляции и определить, какие из них действительно способны работать в текущих условиях. Такой подход помогает отделить применимые сценарии от тех, которые пока не поддерживаются инфраструктурой компании. Если для важного правила не хватает источника, это становится понятной задачей: подключить нужную систему, настроить сбор событий или обеспечить передачу недостающих данных.

Если же действовать в обратном порядке — сначала ориентироваться на количество доступных правил, — легко сформировать завышенные ожидания. Например, в каталоге могут быть сотни сценариев, но после установки выяснится, что лишь небольшая часть из них связана с реально подключенными источниками. В результате компания видит большое число правил, однако получает мало полезных детектов. Это не обязательно означает, что правила низкого качества или сама SIEM работает неправильно: часто проблема заключается в несовпадении требований сценариев с фактически собираемыми данными.

Другой возможный результат — трудоемкая ручная проверка контента. Аналитику приходится последовательно разбирать правила, выяснять, какие события для них нужны, искать соответствующие источники и проверять, передаются ли данные в систему. Такой процесс отнимает время и затрудняет расстановку приоритетов: специалисты могут долго изучать сценарии, которые в текущей инфраструктуре в принципе не способны сработать.

Итоги

Оценивать SIEM-контент лучше не только по общему числу правил и охвату MITRE ATT&CK. Важно понимать, какие источники данных требуются каждому сценарию и присутствуют ли они в организации. Практическая ценность правила определяется не тем, что оно включено в каталог, а тем, может ли система получить необходимые события, обработать их и сформировать полезное обнаружение. Начав с анализа инфраструктуры и доступной телеметрии, можно реалистично оценить применимость правил, выявить пробелы в сборе данных и настроить SIEM так, чтобы она помогала решать конкретные задачи компании.

SIEM-системы в нашем каталоге для вашего пользования

• KUMA.
• RuSiem.