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

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

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

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

Обычно при разработке правил корреляции мы можем использовать следующие основные условия:

• Подсчет количества полученных событий за определенный интервал времени

• Бездействие (не реагирование на получение событий) в течение определенного интервала времени

• Срабатывание на определенные события

Правила корреляции из коробки

Любая современная SIEM содержит в своем составе набор правил что называется “из коробки”. Такой подход имеет как ряд преимуществ, так и ряд недостатков.

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

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

Готовые правила позволяют сократить время реакции службы ИБ на новые угрозы. Между обнаружением инцидента и разработкой правил корреляции может пройти целая “вечность” и готовые правила могут ее существенно сократить.

В рамках определенного SIEM-решения мы можем унифицировать используемый набор правил на различных инсталляциях.

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

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

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

Корреляции в Wazuh

Перейдем к рассмотрению работы с правилами в Wazuh. В нашем SIEM также имеется набор готовых правил. которые можно использовать сразу после установки.

Принцип работы правил корреляции в Wazuh аналогичен работе правил нормализации. Здесь описание также представлено в формате XML в виде декодеров.

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

Файлы с описаниями правил находятся в каталоге /var/ossec/ruleset/rules.

 Здесь мы видим файлы с наборами правил для различных типов источников. В качестве примера посмотрим набор правил для SSH.

В файле есть множество различных правил. Мы рассмотрим связку из трех описаний, наглядно показывающих принцип написания правил корреляции в Wazuh.

Первым правилом в файле идет правило, по которому из исходных событий выделяются подходящие для данной группы:

 <rule id="5700" level="0" noalert="1">

    <decoded_as>sshd</decoded_as>

    <description>SSHD messages grouped.</description>

  </rule>

У нас все правила связаны с событиями от sshd поэтому в поле decoded_as мы указываем sshd. Далее идет множество различных правил, каждое из которых ссылается на 5700, то есть на первое правило, фильтрующее события от sshd.

Нас будут интересовать события неудачной аутентификации. В правиле 5716 мы сначала ссылаемся на 5700, затем в событиях от sshd ищем вхождения строк Failed или error для PAM: Authentication. Именно в этой строке производится фильтрация событий, поэтому, если вам необходимо поменять признаки фильтрации то необходимо поправить регулярное выражение в строке match. Далее идет описание, которое будет выведено в алерте.

И наконец поля mitre и group. В них указываются тактики из матрицы MITRE и пункты различных документов, под которые подпадает данный инцидент.

  <rule id="5716" level="5">

    <if_sid>5700</if_sid>

    <match>^Failed|^error: PAM: Authentication</match>

    <description>sshd: authentication failed.</description>

    <mitre>

      <id>T1110</id>

    </mitre>

    <group>authentication_failed,gdpr_IV_35.7.d,gdpr_IV_32.2,gpg13_7.1,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_10.2.4,pci_dss_10.2.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>

  </rule>

Это пример простого правила, срабатывающего при получении одного события. Но это не так интересно с точки зрения написания правил корреляции. Поэтому рассмотрим еще одно правило 5720, выявляющее множественные неудачные попытки входа.

Здесь в поле frequency мы указываем сколько раз должно произойти заданное событие, чтобы правило сработало. В поле if_matched_sid указываем правило, на основе которого мы и будем считать события. 5716 – неудачный вход в систему. Поле same_source_ip говорит нам о том, что во всех 5 событиях должен быть один и тот же адрес источника. Остальные поля здесь те же, что и в предыдущем правиле.

<rule id="5720" level="10" frequency="5">

    <if_matched_sid>5716</if_matched_sid>

    <same_source_ip />

    <description>sshd: Multiple authentication failures.</description>

    <mitre>

      <id>T1110</id>

    </mitre>

    <group>authentication_failures,gdpr_IV_35.7.d,gdpr_IV_32.2,gpg13_7.1,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_SI.4,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>

  </rule>

Естественно, список возможных условий не ограничивается представленными в примере. Так, если мы хотим, чтобы правило срабатывало при различных значениях портов и адресов источника и получателя события, то необходимо использовать условия different_srcport, different_dstport и аналогичные.

Общий синтаксис для работы с условием same_ представлен ниже:

<!-- {"key":"value", "key2":"AAAA"} -->

<rule id="100001" level="3">

  <decoded_as>json</decoded_as>

  <field name="key">value</field>

  <description>Testing JSON alert</description>

</rule>

 

<rule id="100002" level="10" frequency="4" timeframe="300">

  <if_matched_sid>100001</if_matched_sid>

  <same_field>key2</same_field>

  <description>Testing same_field option</description>

</rule>

Меняем правила

При необходимости вы можете изменить правила Wazuh по умолчанию. Для этого лучше всего  скопировать правила в файл в каталоге /var/ossec/etc/rules/, внести необходимые изменения и добавить к измененным правилам тег overwrite="yes". Эти действия гарантируют, что внесенные вами изменения не будут потеряны во время обновления.

Вот пример того, как изменить значение уровня в правиле SSH 5710 с 5 на 10. Откроем уже знакомый нам файл /var/ossec/ruleset/rules/0095-sshd_rules.xml.

Поместим изменяемое правило в /var/ossec/etc/rules/local_rules.xml. Изменим значение level и добавьте overwrite="yes", чтобы указать, что это правило перезаписывает уже определенное правило.

<group name="syslog,sshd,">

  <rule id="5710" level="10" overwrite="yes">

    <if_sid>5700</if_sid>

    <match>illegal user|invalid user</match>

    <description>sshd: Attempt to login using a non-existent user</description>

    <mitre>

      <id>T1110</id>

    </mitre>

    <group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>

  </rule>

</group>

 Далее можно просто рестартовать службу менеджера

systemctl restart wazuh-manager

Заключение

В этой статье мы поговорили о правилах корреляции, рассмотрели особенности использования правил из коробки. Также рассмотрели то, как строятся правила корреляции непосредственно в Wazuh. С использованием правил корреляции SIEM становится не просто “свалкой событий”, а становится полноценным средством автоматического выявления подозрительных активностей.

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