Skip to main content
Loading...

Механизмы корреляции присутствуют только в коммерческих версиях RuSIEM.

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

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

Корреляция осуществляется уже по нормализованным данным (извлечены пары ключ-значение) и обогащенным симптоматикой.

В случае распределенной инфраструктуры, используется распределенная корреляция. Множество процессов корреляции объединяются через MQ, обмениваются микро транзакциями между собой без передачи событий. Например, в центральном офисе создано правило "Обнаружен вирус более чем на 20 узлах" с группировкой по имени вируса. На Филиалах - такие же правила, обособленные ноды, но счетчик на 10 узлов. Если на одном филиале будет выявлено 5 узлов, на другом 7 и на третьем 9 - в центральный офис будут переданы счетчики со всех филиалов и сработает правило корреляции. При этом, в центральный офис не производится передача событий, как это принято в классических SIEM.

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

Любое правило корреляции можно отключить в любой момент времени.

Пользователи создают свои пользовательские правила в графическом конструкторе без написания и знания какого либо кода.

Выходом правил корреляции являются:

  • инцидент, назначенный на пользователей и групп с указанной темой и приоритетом (и уведомление по электронной почте о назначенном инциденте)
  • уведомление по электронной почте внешних адресатов
  • запуск скрипта с передачей значений инцидента в качестве аргумента (например, передача в качестве аргумента атакующего src.ip для блокировки)
  • создание нового события с передачей в качестве аргумента параметров инцидента

Возможно указание дней недели и времени, когда правило активно. Например, в рабочие дни с 09:00 до 20:00. Если правило корреляции срабатывает в другое время - оно не создает инцидент.

Правила очень гибкие, выглядят как набор логических условий. Условия правил могут быть объединяться между собой логическими операторами AND/OR/NOT и множественными скобками.  В условиях правилах может быть использовано множество различных операторов сравнения.

Правило может срабатывать по:

  • факту появления одного события, попадающего под условие
  • по количеству событий в динамичном интервале времени
  • по подсчету уникальных значений выбранного поля (например, "Соединение более чем на 60 уникальных портов в течение 60 секунд)
  • по последовательности нескольких событий (например, "Инструментальное сканирование" и "Успешный вход" с этого src.ip)
  • результатам выполнения функций-операторов

В правилах существует понятие группировки по объекту. Группировка служит нескольким целям:

  • уточняет условие и правило срабатывания
  • предотвращает дублирование инцидентов

К примеру, с 3 хостов приходят события о 10, 15 и 20 неуспешных входах соответственно. У нас есть правило "Более 15 неуспешных попытках входа в течение 120 секунд". Как должно себя повести правило?

Для корректности необходимы уточнения: под каким именем пользователя, с какого хоста. Глупо было бы просто создать инцидент на первых поступивших 15 событиях, не так ли? Группировка служит уточнением, в ней мы можем указать одно или несколько имен ключей (полей).

Например, если имя пользователя одинаково во всех 15 событиях от второго узла, и другое на третьем и мы создадим группировку по имени пользователя AND src.ip, то будет сформировано два инцидента по второму узлу и третьему узлу с группировкой по имени пользователя и исходному ip адресу.

Если мы сделаем группировку только по src.ip, то в приведенном примере будет сформирован один инцидент, объединяющий события со всех трех узлов. Не важно, что событий в примере пришло больше количества, указанного в правиле - 15. Будет один инцидент, с временем создания по первым 15 событиям, а остальные события дополнят этот инцидент, обновят его время обновления (свойство инцидента).

В правиле корреляции есть опция "Переоткрыть инцидент". Если инцидент был закрыт и после этого произошло повторное срабатывание по тому же самому объекту группировки - данная опция позволяет переоткрыть тот же самый инцидент, позволяя операторам обратить внимание на то, что инцидент произошел повторно и на то, какие работы были проведены в рамках данного инцидента.