Глубины SIEM: экспертиза. Чьи правила корреляции лучше

Глубины SIEM: экспертиза. Чьи правила корреляции лучше
Многие из тех, кто сталкивался с SIEM, знакомы с разработкой правил корреляции. Производители SIEM-решений, коммерческие SOC, интеграторы — все предлагают свои правила и утверждают, что они лучше других. Так ли это на самом деле? Как выбрать поставщика правил? Что такое экспертиза в SIEM? Поразмышляем на эти темы под катом.



Как всегда, в выводе собраны все ключевые тезисы статьи.

Любой специалист по информационной безопасности рано или поздно начинает использовать SIEM-системы или какие-то отдельные элементы систем данного класса.

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

Примерно через месяц после внедрения SIEM приходит понимание, что этот класс решений требует значительных трудозатрат. Искусство атак на информационные системы постоянно развивается. Нужно время на отслеживание современных трендов, их анализ, оценку применимости к своей инфраструктуре, а также на написание правил корреляции для выявления атак. Как правило, времени у специалистов на это не хватает.

Столкнувшись с подобными проблемами, компании решают либо строить свой SOC и привлекать выделенных специалистов, либо найти внешних поставщиков правил корреляции. Дальше мы разберем, как выбрать поставщика и достаточно ли конечному заказчику только правил корреляции.
name="Expertise">

Экспертиза и ее свойства


Под экспертизой мы будем понимать набор правил корреляции, знаний экспертов и данных, минимально необходимых для выявления и реагирования на инциденты. Экспертизу предоставляет поставщик (производитель SIEM-решения или SOC), а заказчик — ее потребитель.

Правила корреляции могут поставлять разработчики SIEM-решений, MSSP-провайдеры/SOC, интеграторы и сообщество. Каждый постулирует, что их правила корреляции качественные. Правда, зачастую понятие качества подменяется просто количеством доступных правил. Является ли количество показателем качества? В общем случае — это спорное утверждение. Качественная экспертиза обладает следующими свойствами:

  1. Точно выявляет нарушения в конкретной инфраструктуре заказчика.
  2. Выявляет актуальные угрозы мирового уровня. Выявляет угрозы, характерные для конкретной страны и отрасли заказчика.
  3. Имеет как реактивную, так и проактивную составляющую.
  4. Поясняет заказчику результаты своего логического вывода.
  5. Предоставляет пояснения по дальнейшим шагам реагирования на выявленный инцидент.

Часть из этих свойств налагает требования на разработчика экспертизы, а часть — на результат его работы — правила корреляции и сопутствующие материалы.
name="Developer">

Разработчик экспертизы и его компетенции


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

  • Выявлять актуальные угрозы мирового уровня. Это могут быть поставщики, у которых есть собственные аналитические центры, специализирующиеся на выявлении и анализе атак. В них должен проводиться регулярный мониторинг новейших типов атак и подходов к нарушению информационной безопасности систем.
  • Выявлять угрозы, характерные для конкретной страны и отрасли заказчика. В каждой стране ландшафт угроз и перечень типов атак может иметь свою специфику. Поэтому при выборе поставщика, важно, чтобы его аналитический центр имел четкий фокус на отслеживание угроз, присущих именно той стране, в которой располагается инфраструктура вашей компании. Специалисты центра должны не только понимать особенности угроз в определенной стране, но и уметь быстро реагировать на них. Не должно быть так, что поставщик реагирует на новую региональную угрозу через неделю после ее появления, только из-за того, что ваш регион не является для него приоритетным с точки зрения ведения бизнеса.
  • Иметь как реактивную, так и проактивную составляющую. Недостаточно набрать в центр аналитиков из числа пентестеров. Важно, чтобы эти эксперты не только понимали и умели взламывать системы, но и знали, как можно выявить попытки взлома и предотвратить, или остановить их на ранних стадиях. Практика показывает, что этому аспекту мало уделяют внимания: часто аналитические центры строятся из экспертов либо только в области нападения, либо только в сфере защиты, что непременно сказывается на уровне выпускаемой ими экспертизы.
  • Точно выявлять нарушения в конкретной инфраструктуре заказчика. Поставщик должен иметь методологию разработки правил корреляции, способных адаптироваться к конкретной инфраструктуре заказчика. Это нужно для того, чтобы минимизировать количество ложных срабатываний правил. Этому вопросу был посвящен большой цикл статей «Правила корреляции, работающие из коробки» . Важно помнить, что у поставщика должен быть выстроен процесс именно «промышленной разработки» правил корреляции. Из этого следует, что:
    • правила должны тестироваться на «живых», а не синтетических системах;
    • в процессе тестирования должны вживую воспроизводиться те типы атак, на выявление которых направлено тестируемое правило корреляции;
    • должны проводиться нагрузочные и регрессионные тесты, подтверждающие совместимость правил с SIEM;
    • поставщик должен выпускать обновления для ранее выпущенных правил, если выясняется, что правила имеют большое число ложных срабатываний;
    • сам SIEM и поставщик должны иметь каналы оперативной доставки обновлений и новых правил корреляции до конечных заказчиков.

Набор требований достаточно широкий. К сожалению, если выделить для разработки правил корреляции одного специалиста, который будет тратить на эту активность 2 часа в день, это не позволит добиться той самой качественной экспертизы.

Правила корреляции и их окружение


Посмотрим теперь на сами правила корреляции глазами заказчика. Он хочет получить от поставщика качественные правила и без проблем активировать их в своем SIEM. На деле не все так просто.

Для работы правил нужно подключить к SIEM требуемые источники. Они должны быть настроены так, чтобы генерировать необходимые для правил события. Смотря на само правило, важно, чтобы из него была понятна логика его работы. Помимо этого, заказчику необходимо понимать, как реагировать в случае, если правило срабатывает.

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


Экспертиза замкнутого цикла

Рассмотрим каждое звено этой цепи:

  1. Поставщик/производитель SIEM. Экспертиза начинается с того, что поставщик, обладающий соответствующими компетенциями , разрабатывает правила корреляции, согласно технологическому процессу.
  2. Список и настройки источников. Разработанные правила корреляции снабжаются описанием тех источников, на основе которых работает правило корреляции. Также поставщик подробно описывает, каким образом должен быть настроен источник, чтобы он обеспечивал генерацию требуемых типов событий. Хорошим тоном будет, если поставщик представит экземпляр самих событий.
  3. Описание логики правила. Для того чтобы заказчик понимал, какие принципы срабатывания заложены в правила корреляции, поставщик описывает логику каждого правила в виде блок-схем или текстового описания.
  4. Правила корреляции. Непосредственно сами правила корреляции и методика приоритизации порожденных ими инцидентов.
  5. Планы реагирования. Срабатывания правила корреляции может являться инцидентом информационной безопасности. Заказчику важно понимать, как нужно реагировать на данный инцидент с целью минимизации его влияния на инфраструктуру. Также в план должны быть включены пояснения, какие данные необходимо дополнительно собрать, в случае появления инцидента. Бесспорно, заказчик должен адаптировать правила реагирования под специфику своей компании. Однако в рамках планов реагирования поставщик должен отразить обобщенные рекомендации по действиям пользователя при инциденте, вызванном конкретным правилом. Так заказчику будет от чего оттолкнуться, адаптируя под себя общий процесс реагирования.
  6. Телеметрия. Правила корреляции работают не в сферическом вакууме, а в конкретных условиях компании заказчика. Поставщик отвечает за качество предоставляемых правил и должен понимать, как они работают. Таким образом в SIEM должна собираться статистика по работе правил.
  7. Поставщик/производитель SIEM. Собранная телеметрия в обезличенном виде должна поступать обратно поставщику. Статистика помогает ему оперативно вносить изменения в правила, в случае их ложных срабатываний. Также она позволяет выявлять новые техники и тактики атак и оперативно выпускать новые правила корреляции для их детектирования.

Набор требований к поставщику, а также все вышеописанные звенья цепи, по совокупности называются экспертизой. Как можно заметить, цепочка замкнута, поэтому данный подход обозначен как «экспертиза замкнутого цикла».

На данный момент этот подход используют основные зарубежные лидеры SIEM-рынка: IBM QRadar, Micro focus ArcSight. В России он применяется в нашей компании Positive Technologies в продукте MaxPatrol SIEM. В рамках сообщества развивается интересный вендоронезависимый проект — Atomic Threat Coverage , продвигающий схожую идеологию. Далее приведу его описание, взятое со страницы проекта.

Atomic Threat Coverage позволяет автоматически сгенерировать базу аналитических данных, предназначенную для противодействия угрозам, описанным в MITRE ATT&CK с позиций Обнаружения, Реагирования, Предотвращения и Имитации угроз. Он включает в себя:

  1. Detection Rules — Правила Обнаружения (корреляции), основанные на Sigma — общем формате описания правил корреляции для SIEM систем.
  2. Data Needed — данные, которые необходимо собирать для обнаружения конкретной угрозы.
  3. Logging Policies — настройки логирования, которые необходимо произвести на устройстве для сбора данных, необходимых для обнаружения конкретной угрозы.
  4. Enrichments — настройки обогащения данных (Data Needed), необходимые для реализации некоторых Правил Обнаружения (Detection Rules).
  5. Triggers — сценарии имитации атак, основанные на Atomic Red Team — атомарных тестах/сценариях реализации угроз из MITRE ATT&CK.
  6. Response Actions — атомарные шаги реагирования на инциденты.
  7. Response Playbooks — сценарии реагирования на инциденты, сгенерированные в ходе обнаружения конкретной угрозы, составленные на основе Response Actions.
  8. Hardening Policies — настройки систем, которые позволяют нивелировать конкретную угрозу.
  9. Mitigation Systems — системы и технологии, которые позволяют нивелировать конкретную угрозу.


Отдельно отмечу момент, который часто выпадает из поля зрения заказчиков и поставщиков. Иногда случаются сложные инциденты, которые невозможно распутать силами специалистов заказчика. Поставщик не должен оставлять заказчика один на один с его проблемой: «Мы поставляем вам правила, они работают, остальное — не наши проблемы». На мой взгляд, серьезные поставщики экспертизы должны иметь в своем портфеле услуги расследования инцидентов, которыми заказчик может воспользоваться в любое время 24/7 в случае возникновения критической ситуации.
name="Conclusions">

Выводы


Подытожим:

  1. Заказчик, купивший SIEM, часто не имеет возможности выделить отдельных специалистов для работы с решением 100% рабочего времени. В таком случае SIEM через некоторое время перестает использоваться.
  2. Одних правил корреляции недостаточно для того, чтобы обеспечивать выявление актуальных угроз безопасности. В связи с этим одни лишь правила корреляции не могут называться экспертизой. Экспертиза — набор правил корреляции, знаний экспертов и данных, минимально необходимых для выявления и реагирования на инциденты.
  3. Экспертиза должна обладать следующими свойствами :
    • точно выявляет нарушения в конкретной инфраструктуре заказчика;
    • выявляет актуальные угрозы мирового уровня, а также характерные для конкретной страны и отрасли заказчика;
    • имеет как реактивную, так и проактивную составляющую;
    • поясняет заказчику результаты своего логического вывода;
    • предоставляет пояснения по дальнейшим шагам реагирования на выявленный инцидент.
  4. Недостаточно поставлять готовые Sigma-правила, чтобы считаться поставщиком экспертизы. Поставщик экспертизы должен удовлетворять ряду требований .
  5. Поставляемая экспертиза состоит из следующих взаимосвязанных элементов:
    • списка и настройки источников;
    • описания логики правила;
    • правила корреляции;
    • планов реагирования;
    • телеметрии по срабатыванию правил.
  6. Поставщики экспертизы должны иметь в своем портфеле услуги расследования, которыми заказчик может воспользоваться в случае, если у него не хватает собственных компетенций для анализа сложного инцидента.
Alt text

Где кванты и ИИ становятся искусством?

На перекрестке науки и фантазии — наш канал

Подписаться