Корреляция в режиме реального времени
Механизмы корреляции присутствуют только в коммерческих версиях RuSIEM.
Корреляция осуществляется на потоке в режиме реального времени. Поток событий расщепляется на корреляцию и сохранение в базу данных, поэтому не привносит задержку между поступлением событий на вход и сохранением в базу данных.
События, поступающие на вход корреляции, буферизуются на диск с помощью MQ с целью предотвращения потерь. Счетчики и триггеры также буферизуются. Таким образом, при внезапной перезагрузке сервера или процессов, сбоях — данные не будут потеряны.
Корреляция осуществляется уже по нормализованным данным (извлечены пары ключ-значение) и обогащенным симптоматикой.
В случае распределенной инфраструктуры, используется распределенная корреляция. Множество процессов корреляции объединяются через MQ, обмениваются микро транзакциями между собой без передачи событий. Например, в центральном офисе создано правило «Обнаружен вирус более чем на 20 узлах» с группировкой по имени вируса. На Филиалах — такие же правила, обособленные ноды, но счетчик на 10 узлов. Если на одном филиале будет выявлено 5 узлов, на другом 7 и на третьем 9 — в центральный офис будут переданы счетчики со всех филиалов и сработает правило корреляции. При этом, в центральный офис не производится передача событий, как это принято в классических SIEM.
В системе присутствует уже множество предзаданных системных правил корреляции. В случае системных правил, пользователь может их отключать, копировать правило полностью в пользовательское. Пользователи могут создавать свои пользовательские правила корреляции и производить с ними любые операции.
Любое правило корреляции можно отключить в любой момент времени.
Корреляция осуществляется на потоке в режиме реального времени. Поток событий расщепляется на корреляцию и сохранение в базу данных, поэтому не привносит задержку между поступлением событий на вход и сохранением в базу данных.
События, поступающие на вход корреляции, буферизуются на диск с помощью MQ с целью предотвращения потерь. Счетчики и триггеры также буферизуются. Таким образом, при внезапной перезагрузке сервера или процессов, сбоях — данные не будут потеряны.
Корреляция осуществляется уже по нормализованным данным (извлечены пары ключ-значение) и обогащенным симптоматикой.
В случае распределенной инфраструктуры, используется распределенная корреляция. Множество процессов корреляции объединяются через MQ, обмениваются микро транзакциями между собой без передачи событий. Например, в центральном офисе создано правило «Обнаружен вирус более чем на 20 узлах» с группировкой по имени вируса. На Филиалах — такие же правила, обособленные ноды, но счетчик на 10 узлов. Если на одном филиале будет выявлено 5 узлов, на другом 7 и на третьем 9 — в центральный офис будут переданы счетчики со всех филиалов и сработает правило корреляции. При этом, в центральный офис не производится передача событий, как это принято в классических SIEM.
В системе присутствует уже множество предзаданных системных правил корреляции. В случае системных правил, пользователь может их отключать, копировать правило полностью в пользовательское. Пользователи могут создавать свои пользовательские правила корреляции и производить с ними любые операции.
Любое правило корреляции можно отключить в любой момент времени.
Выходом правил корреляции являются:
- инцидент, назначенный на пользователей и групп с указанной темой и приоритетом (и уведомление по электронной почте о назначенном инциденте)
- уведомление по электронной почте внешних адресатов
- запуск скрипта с передачей значений инцидента в качестве аргумента (например, передача в качестве аргумента атакующего src.ip для блокировки)
- создание нового события с передачей в качестве аргумента параметров инцидента
Возможно указание дней недели и времени, когда правило активно. Например, в рабочие дни с 09:00 до 20:00. Если правило корреляции срабатывает в другое время — оно не создает инцидент. 
Правила очень гибкие, выглядят как набор логических условий. Условия правил могут быть объединяться между собой логическими операторами AND/OR/NOT и множественными скобками. В условиях правилах может быть использовано множество различных операторов сравнения.
Правило может срабатывать по:
- факту появления одного события, попадающего под условие
- по количеству событий в динамичном интервале времени
- по подсчету уникальных значений выбранного поля (например, «Соединение более чем на 60 уникальных портов в течение 60 секунд)
- по последовательности нескольких событий (например, «Инструментальное сканирование» и «Успешный вход» с этого src.ip)
- результатам выполнения функций-операторов
- уточняет условие и правило срабатывания
- предотвращает дублирование инцидентов
Для корректности необходимы уточнения: под каким именем пользователя, с какого хоста. Глупо было бы просто создать инцидент на первых поступивших 15 событиях, не так ли? Группировка служит уточнением, в ней мы можем указать одно или несколько имен ключей (полей).
Например, если имя пользователя одинаково во всех 15 событиях от второго узла, и другое на третьем и мы создадим группировку по имени пользователя AND src.ip, то будет сформировано два инцидента по второму узлу и третьему узлу с группировкой по имени пользователя и исходному ip адресу.
Если мы сделаем группировку только по src.ip, то в приведенном примере будет сформирован один инцидент, объединяющий события со всех трех узлов. Не важно, что событий в примере пришло больше количества, указанного в правиле — 15. Будет один инцидент, с временем создания по первым 15 событиям, а остальные события дополнят этот инцидент, обновят его время обновления (свойство инцидента).
Например, если имя пользователя одинаково во всех 15 событиях от второго узла, и другое на третьем и мы создадим группировку по имени пользователя AND src.ip, то будет сформировано два инцидента по второму узлу и третьему узлу с группировкой по имени пользователя и исходному ip адресу.
Если мы сделаем группировку только по src.ip, то в приведенном примере будет сформирован один инцидент, объединяющий события со всех трех узлов. Не важно, что событий в примере пришло больше количества, указанного в правиле — 15. Будет один инцидент, с временем создания по первым 15 событиям, а остальные события дополнят этот инцидент, обновят его время обновления (свойство инцидента).
Для корректности необходимы уточнения: под каким именем пользователя, с какого хоста. Глупо было бы просто создать инцидент на первых поступивших 15 событиях, не так ли? Группировка служит уточнением, в ней мы можем указать одно или несколько имен ключей (полей).
Например, если имя пользователя одинаково во всех 15 событиях от второго узла, и другое на третьем и мы создадим группировку по имени пользователя AND src.ip, то будет сформировано два инцидента по второму узлу и третьему узлу с группировкой по имени пользователя и исходному ip адресу.
Если мы сделаем группировку только по src.ip, то в приведенном примере будет сформирован один инцидент, объединяющий события со всех трех узлов. Не важно, что событий в примере пришло больше количества, указанного в правиле — 15. Будет один инцидент, с временем создания по первым 15 событиям, а остальные события дополнят этот инцидент, обновят его время обновления (свойство инцидента).
Например, если имя пользователя одинаково во всех 15 событиях от второго узла, и другое на третьем и мы создадим группировку по имени пользователя AND src.ip, то будет сформировано два инцидента по второму узлу и третьему узлу с группировкой по имени пользователя и исходному ip адресу.
Если мы сделаем группировку только по src.ip, то в приведенном примере будет сформирован один инцидент, объединяющий события со всех трех узлов. Не важно, что событий в примере пришло больше количества, указанного в правиле — 15. Будет один инцидент, с временем создания по первым 15 событиям, а остальные события дополнят этот инцидент, обновят его время обновления (свойство инцидента).
