RuSIEM - это коммерческая версия класса SIEM (Security information and event management), включает корреляцию в реальном времени, визуализацию и поиск данных, долгосрочное хранение сырых и нормализованных событий, встроенное управление инцидентами и отчеты.
→
→
RuSIEM
Корреляция в режиме реального времени
Механизмы корреляции присутствуют только в коммерческих версиях 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 событиям, а остальные события дополнят этот инцидент, обновят его время обновления (свойство инцидента).
Симптоматика — технология, разработанная нашей компанией и используемая в продукте с 2015 года.
Понимать, что происходит
1.
Пользователи, работающие с системой, работают не с одним источником, а с сотнями различных. События от них имеют разный формат, отличаются и текстом и event.id и категориями. Пользователю должно быть понятно что происходит. Представьте, что вы смотрите на события. Даже для эксперта — большой поток событий словно в фильме «Матрица» набор быстро сменяющихся символов. Представьте, что вы смотрите на такой экран. Что если вместо символов будут символические картинки? Например, фотография вашего друга, обозначение «ест», «бутерброд». Вы уже понимаете что происходит. И даже если посадить другого неподготовленного человека — он также будет понимать практически сразу.
Симптом в RuSIEM — базовый минимальный элемент, действие. Как мы рассматривали выше — «ест», «красный», «root», «неуспешный вход», «самоподписанный сертификат», «старт службы» и прочее. Почти каждое событие в системе тегируется одним или несколькими симптомами. Мы заранее учим систему понимать источники, расширяя границы симптоматики. Пользователи также могут создать свои собственные симптомы и ими будут тегироваться события.
В большинстве — это общие симптомы, но есть и специфические для конкретных систем. На момент написания статьи в RuSIEM более 1,700 симптомов и их количество постоянно расширяется.
Симптом в RuSIEM — базовый минимальный элемент, действие. Как мы рассматривали выше — «ест», «красный», «root», «неуспешный вход», «самоподписанный сертификат», «старт службы» и прочее. Почти каждое событие в системе тегируется одним или несколькими симптомами. Мы заранее учим систему понимать источники, расширяя границы симптоматики. Пользователи также могут создать свои собственные симптомы и ими будут тегироваться события.
В большинстве — это общие симптомы, но есть и специфические для конкретных систем. На момент написания статьи в RuSIEM более 1,700 симптомов и их количество постоянно расширяется.
Оперативно найти необходимые данные
2.
Пользователю необходимо быстро найти данные. Без экспертных знаний по источнику, долгих воспоминаний как выглядят искомые события. К тому же, в экстренных и стрессовых ситуациях при возникновении инцидента, в случае иных факторов (таких как болезнь. личные проблемы, метеорологические условия) — пользователь может упустить важные данные, не найти их.
С использованием симптоматики можно не строить сложных запросов, а указать базовые понятные симптомы. Например, «создание учетной записи», «Успешный вход RDP», «Включение в группу», «Отключение логирования», «Создание таблицы БД». При этом, возможно указание нескольких симптомов или категорий наряду с массивом уточняющих других факторов.
Указание через понятные слова и фразы (имена симптомов) возможно во всей системе. На дашбордах, при поиске событий, в отчетах, в правилах корреляции и аналитики.
С использованием симптоматики можно не строить сложных запросов, а указать базовые понятные симптомы. Например, «создание учетной записи», «Успешный вход RDP», «Включение в группу», «Отключение логирования», «Создание таблицы БД». При этом, возможно указание нескольких симптомов или категорий наряду с массивом уточняющих других факторов.
Указание через понятные слова и фразы (имена симптомов) возможно во всей системе. На дашбордах, при поиске событий, в отчетах, в правилах корреляции и аналитики.
Видеть все глобальнее
3.
В SIEM системы сводится множество гетерогенных источников. Для операторов важно видеть масштабно что происходит в инфраструктуре. Например, не важно в какой системе появились «Критический сбой» или «Привилегированный доступ», на какой версии ОС произошло, в какой БД. Необходимо увидеть в событиях по всей инфраструктуре, не рассматривая события по каждому источнику. Симптом с таким значением будет выведен оператору в выводе по запросу в сохраненном представлении, на дашбордах, в отчетах и в инцидентах при необходимости. И далее оператор примет решение. Самое важное — что он будет доступен для поиска вне зависимости в какой системе это произошло.
Рассмотрим другой пример. У оператора несколько представлений, в одном из них — отображение неуспешных попыток входа сразу по всем событиям/системам. Оператору сразу открывается вид на все события сразу по инфраструктуре. Нет необходимости рассматривать каждую систему по отдельности, выстраивая полную картину происходящего и склеивая ее воедино. Возможно к каждой системе провалиться по отдельности, но рассматривать можно начать с более глобального взгляда. Зачастую, это позволяет оперативнее найти причину сбоя, инцидента, локализовать очаг угроз и понять что вообще происходит и какие системы затронуты.
Рассмотрим другой пример. У оператора несколько представлений, в одном из них — отображение неуспешных попыток входа сразу по всем событиям/системам. Оператору сразу открывается вид на все события сразу по инфраструктуре. Нет необходимости рассматривать каждую систему по отдельности, выстраивая полную картину происходящего и склеивая ее воедино. Возможно к каждой системе провалиться по отдельности, но рассматривать можно начать с более глобального взгляда. Зачастую, это позволяет оперативнее найти причину сбоя, инцидента, локализовать очаг угроз и понять что вообще происходит и какие системы затронуты.
Одно правило корреляции вместо множества под каждый источник
4.
Теперь нет необходимости писать паттерны текста событий в правилах корреляции. К примеру, есть симптом «Неуспешный вход ssh». Это разовые, не многократные попытки доступа. Для многократных — есть симптом «Многочисленные неуспешные попытки входа ssh». События от Ubuntu, Sun OS, Red Hat, Suse, FreeBSD — все имеют различный формат событий. У нас есть правила для обнаружения неуспешных попыток доступа по ssh для критичных активов, служебных учетных записей, многочисленных и распределенных по времени атак и прочие правила, где необходимо оперировать именно этим фактом «неуспешного входа по ssh». С симптоматикой, достаточно сделать один симптом, характеризующий это действие/воздействие и уже к нему же привязывать паттерны в зависимости от различных источников с разными форматами событий.
Использование симптомов и категорий в правилах корреляции позволяет сделать правила корреляции более универсальными. При этом, при подключении к системе совершенно нового источника достаточно добавить условия в симптомы. События от нового источника начнут тегироваться данными симптомами и старые правила корреляции будут работать с этим новым потоком событий.
Использование симптомов и категорий в правилах корреляции позволяет сделать правила корреляции более универсальными. При этом, при подключении к системе совершенно нового источника достаточно добавить условия в симптомы. События от нового источника начнут тегироваться данными симптомами и старые правила корреляции будут работать с этим новым потоком событий.
Приоритезация и веса событий, критичность
5.
Вполне естественно для SIEM системы принимать десятки тысяч событий в секунду и искать события на интервале в недели и месяцы назад. Найти потенциально критичное событие среди десятков миллионов и, тем более, заметить его — подобно иголке в стоге сена.
Симптоматика RuSIEM помимо тегирования текстом учитывает числовые метрики. Каждый симптом имеет понятный текст событий и вес симптома в виде цифры. Вес может быть как положительный, так и отрицательный. События, проходя сквозь листья бинарного дерева симптоматики получают массив имен симптомов, массив их весов, а также поле суммарного веса нескольких симптомов в событии. Например, событие
<38>Oct 24 23:36:24 mail sshd|LS|25433|RS|: Failed password for invalid user webadmin from 80.26.116.5 port 41438 ssh2
попадает под следующий массив симптомов:
Unsuccessful ssh login. Incorrect password, Invalid ssh user password, Non-existent user
имеющих соответственно веса: 10, 5, 8.
Событие дополняется полем symptoms.sweight=23 (сумма весов). Таким образом, вес события равен 23.
Пользователь может создать свои симптомы, которые будут увеличивать или уменьшать суммарные веса событий в зависимости от различных факторов. При поиске по событиям, мы можем в запросе указать вывести критичные события с весом, выше или равно указанного и, таким образом, отсеить незначимые, что позволяет сконцентрироваться на действительно важных событиях.
Симптоматика RuSIEM помимо тегирования текстом учитывает числовые метрики. Каждый симптом имеет понятный текст событий и вес симптома в виде цифры. Вес может быть как положительный, так и отрицательный. События, проходя сквозь листья бинарного дерева симптоматики получают массив имен симптомов, массив их весов, а также поле суммарного веса нескольких симптомов в событии. Например, событие
<38>Oct 24 23:36:24 mail sshd|LS|25433|RS|: Failed password for invalid user webadmin from 80.26.116.5 port 41438 ssh2
попадает под следующий массив симптомов:
Unsuccessful ssh login. Incorrect password, Invalid ssh user password, Non-existent user
имеющих соответственно веса: 10, 5, 8.
Событие дополняется полем symptoms.sweight=23 (сумма весов). Таким образом, вес события равен 23.
Пользователь может создать свои симптомы, которые будут увеличивать или уменьшать суммарные веса событий в зависимости от различных факторов. При поиске по событиям, мы можем в запросе указать вывести критичные события с весом, выше или равно указанного и, таким образом, отсеить незначимые, что позволяет сконцентрироваться на действительно важных событиях.
Хранить долго только критичные события
6.
С симптоматикой изменяется и подход к хранению. Нет смысла экономить место на основной оперативной базе, выделяя архивное на старые более медленные диски. Если вам потенциально могут понадобиться события из архивного хранилища — вы не сможете все равно их оперативно подгрузить и использовать. В расследовании причин сбоя, инцидентов важно время. Вне зависимости от уровня систем защиты и обнаружения угроз, события приходится хранить от 3х месяцев до 3х лет. Иногда это регламентировано требованиями регуляторов и стандартов. Это достаточно большие объемы данных.
В RuSIEM нет разделения на оперативное (онлайн) и архивное хранилище. Данные разделяются на три основных типа — Unparsed (не распарсенные события), Inf (Информационные) и Imp (Impersonate, важные). В настройках указываются вес, который делает событие «Важным». По умолчанию, события с весом 7 и более — Важные. Критерий может быть изменен в настройках пользователем. События с весом 7 и более попадают под контроли в международных стандартах ИБ.
Как уже упоминали выше — пользователь может оперировать суммарными весами событий создавая свои симптомы с положительными и отрицательными весами.
Устаревшая концепция разделения на онлайн и архивное хранилище, а так же различные схемы масштабирования, создание отказоустойчивых производительных кластеров баз данных так же присутствует в продуктах.
В RuSIEM нет разделения на оперативное (онлайн) и архивное хранилище. Данные разделяются на три основных типа — Unparsed (не распарсенные события), Inf (Информационные) и Imp (Impersonate, важные). В настройках указываются вес, который делает событие «Важным». По умолчанию, события с весом 7 и более — Важные. Критерий может быть изменен в настройках пользователем. События с весом 7 и более попадают под контроли в международных стандартах ИБ.
Как уже упоминали выше — пользователь может оперировать суммарными весами событий создавая свои симптомы с положительными и отрицательными весами.
Устаревшая концепция разделения на онлайн и архивное хранилище, а так же различные схемы масштабирования, создание отказоустойчивых производительных кластеров баз данных так же присутствует в продуктах.
Экономия трафика и пересылка событий в SOC
7.
Суммарные веса событий используются и в фильтрации в различных схемах пересылки. Например, RuSIEM/RvSIEM установленный на небольшом филиале хранит все, а события с весом, к примеру, 12 и выше пересылает в режиме реального времени в центральный офис или SOC. Кроме того, возможна фильтрация по категориям и симптомам.
Машинное обучение и аналитика
8.
Вы пытались хоть раз сделать простейшего робота с голосовым управлениям? Активация голосом схожа с симптоматикой. Вы сообщаете роботу «двигаться», указываете направление «вперед», указываете расстояние «2 метра». К этим командам привязана масса паттернов от голоса до конкретных команд шаговым двигателям. Если вы обучаете робота рисовать, то, наверное, вам придется ему сначала заложить понятия что такое квадрат, треугольник, линия, цвет.
Вернемся к нашим симптомам. Передавая события в модуль аналитики, мы уже передаем подготовленные события, имеющие пары ключ-значения в соответствии с таксономией, объекты, действия с ними. Складывая симптомы «Машина» + «едет» + «красный свет» мы агрегируем с различных источников и множества событий достаточные сведения об объекте, действиях над ним и свойствах, что позволяет улучшать работу AI, DL модулей и обнаружить сбои и инциденты на ранеей стадии возникновения, без необходимости писать правила корреляции под каждый конкретный случай.
Вернемся к нашим симптомам. Передавая события в модуль аналитики, мы уже передаем подготовленные события, имеющие пары ключ-значения в соответствии с таксономией, объекты, действия с ними. Складывая симптомы «Машина» + «едет» + «красный свет» мы агрегируем с различных источников и множества событий достаточные сведения об объекте, действиях над ним и свойствах, что позволяет улучшать работу AI, DL модулей и обнаружить сбои и инциденты на ранеей стадии возникновения, без необходимости писать правила корреляции под каждый конкретный случай.
Симптоматика работает как в коммерческой версии RuSIEM, так и в свободно распространяемой RvSIEM. Во всех версиях пользователь может создавать свои собственные симптомы и категории, работать с ними в любых разделах системы.
Для увеличения производительности, скорости прохождения события по симптомам и минимизации ложных срабатываний в каждом симптоме задается фильтр, определяющий какие события будут попадать под симптом.
При интеграции с новыми источниками мы формируем парсеры, симптоматику, правила корреляции и поставляем их в обновлениях.
Все управление симптоматикой осуществляется из веб интерфейса.
Поддерживается мультиязычность — достаточно переключиться на другой язык интерфейса, ввести имена симптомов/категорий на данном языке и сохранить.
В событиях сохраняются не имена симптомов, а их идентификаторы. Поэтому, переименовав симптом — он будет показываться новым именем в уже сохраненных событиях без необходимости операции Update по базе данных.
Для увеличения производительности, скорости прохождения события по симптомам и минимизации ложных срабатываний в каждом симптоме задается фильтр, определяющий какие события будут попадать под симптом.
При интеграции с новыми источниками мы формируем парсеры, симптоматику, правила корреляции и поставляем их в обновлениях.
Все управление симптоматикой осуществляется из веб интерфейса.
Поддерживается мультиязычность — достаточно переключиться на другой язык интерфейса, ввести имена симптомов/категорий на данном языке и сохранить.
В событиях сохраняются не имена симптомов, а их идентификаторы. Поэтому, переименовав симптом — он будет показываться новым именем в уже сохраненных событиях без необходимости операции Update по базе данных.
Управление инцидентами
Управление инцидентами присутствует только в коммерческих версиях RuSIEM.
Управление инцидентами в RuSIEM построено по стандарту ITIL. Инциденты формируются автоматически в результате срабатывания правил корреляции.
Работа с инцидентами осуществляется через веб интерфейс.
Управление инцидентами в RuSIEM построено по стандарту ITIL. Инциденты формируются автоматически в результате срабатывания правил корреляции.
Работа с инцидентами осуществляется через веб интерфейс.
Инциденты имеют «область видимости» — инцидент виден только тем пользователям, на которых он назначен (или пользователь входит в группы, на которые назначен инцидент).
Пользователю может быть предоставлено права на инцидент если поставить задачу внутри инцидента на этого пользователя или группу, в которую он входит.
Область видимости также изменяется при эскалации инцидента. При этом, если инцидент эскалирован на других пользователей и группы, то предыдущие исполнители перестают его видеть.
Пока инцидент открыт, в работе, назначен — новые инциденты по этому же правилу корреляции и объекту не создаются, предотвращая дублирование, а дописываются к уже имеющемуся инциденту.
Если инцидент закрыт и повторяется повторно — он автоматически открывается и устанавливается статус «Переоткрыт».
При возникновении инцидента пользователь уведомляется всплывающим сообщением в правом верхнем углу экрана. По клику на уведомлении в новом окне браузера открывается карточка инцидента. Количество всплывающих уведомлений ограничено пятью одновременными уведомлениями.
Из инцидента можно посмотреть правило корреляции, по которому он был сформирован.
История статусов инцидента доступна для просмотра из инцидента. В ней указываются смены статусов, кем изменялись и когда.
Пользователю может быть предоставлено права на инцидент если поставить задачу внутри инцидента на этого пользователя или группу, в которую он входит.
Область видимости также изменяется при эскалации инцидента. При этом, если инцидент эскалирован на других пользователей и группы, то предыдущие исполнители перестают его видеть.
Пока инцидент открыт, в работе, назначен — новые инциденты по этому же правилу корреляции и объекту не создаются, предотвращая дублирование, а дописываются к уже имеющемуся инциденту.
Если инцидент закрыт и повторяется повторно — он автоматически открывается и устанавливается статус «Переоткрыт».
При возникновении инцидента пользователь уведомляется всплывающим сообщением в правом верхнем углу экрана. По клику на уведомлении в новом окне браузера открывается карточка инцидента. Количество всплывающих уведомлений ограничено пятью одновременными уведомлениями.
Из инцидента можно посмотреть правило корреляции, по которому он был сформирован.
История статусов инцидента доступна для просмотра из инцидента. В ней указываются смены статусов, кем изменялись и когда.
Удалить инцидент для сокрытия нельзя. Возможно только закрыть инцидент и он останется, будет отображаться в закрытых инцидентах с указанием кто, когда и с каким решением его закрыл.
Для массовых ошибок все же существует кнопка удаления всех инцидентов (в том числе открытых и закрытых для всех пользователей), доступная только для администратора системы.
Имеются массовые операции для легитимного закрытия множества выделенных инцидентов.
Для массовых ошибок все же существует кнопка удаления всех инцидентов (в том числе открытых и закрытых для всех пользователей), доступная только для администратора системы.
Имеются массовые операции для легитимного закрытия множества выделенных инцидентов.
Agent Management
Для получения событий с транспортов, отличных от syslog, в RuSIEM коммерческой версии и свободно распространяемой RvSIEM free используются агенты для Windows.
Агенты устанавливаются в качестве службы Windows, управляются через веб-консоль сервера управления и позволяют собирать события как локально, так и одновременно из нескольких удаленных источников безагентным методом. То есть, вы устанавливаете агента на один из серверов и этот агент собирает с сотен других Windows, MS SQL/Mysql/Oracle/file серверов, на которых не установлен агент.
По количеству агенты не лицензируется, их может быть сколько угодно. Для мобильных устройств (ноутбуков) рекомендуется установка агента локально. В этом случае, при отсутствующем подключении, агент будет собирать события в свою локальную базу данных, ротируемую в зависимости от свободного места на диске во избежание потери событий при ротации или действиях злоумышленника. А при наличии соединения с сервером, события будут переданы на него.
Для сбора Windows event logs удаленно безагентным способом используются WMI транспорт (устаревший) и EVT (начиная с Windows 7, более быстрый и стабильный).
У агента имеются универсальные транспорты, позволяющие собирать события с:
Агенты устанавливаются в качестве службы Windows, управляются через веб-консоль сервера управления и позволяют собирать события как локально, так и одновременно из нескольких удаленных источников безагентным методом. То есть, вы устанавливаете агента на один из серверов и этот агент собирает с сотен других Windows, MS SQL/Mysql/Oracle/file серверов, на которых не установлен агент.
По количеству агенты не лицензируется, их может быть сколько угодно. Для мобильных устройств (ноутбуков) рекомендуется установка агента локально. В этом случае, при отсутствующем подключении, агент будет собирать события в свою локальную базу данных, ротируемую в зависимости от свободного места на диске во избежание потери событий при ротации или действиях злоумышленника. А при наличии соединения с сервером, события будут переданы на него.
Для сбора Windows event logs удаленно безагентным способом используются WMI транспорт (устаревший) и EVT (начиная с Windows 7, более быстрый и стабильный).
У агента имеются универсальные транспорты, позволяющие собирать события с:
- Windows event log (любые журналы)
- Checkpoint LEA
- Cisco SDEE
- File logs
- Logs on ftp servers
- Hash logs (запущенные процессы их sha1/md5/sha256)
- Logs on Mysql/Oracle/MS SQL таблицах и представлениях
- WMI logs
- Информация об установленном ПО и патчах
- Информация об открытых процессами портах
Автоматическая установка агента
Агент может быть развернут из .msi дистрибутива локально, либо автоматически на множестве устройств другим контролирующим агентом.
Например, вы устанавливаете один контролирующий агент на одном из серверов, указываете этому агенту в разделе веб-интерфейса «Источники —> Удаленная установка» параметры установки агентов и этот агент автоматически установит агентов и проконтролирует их работоспособность. В случае выхода из строя какого либо подконтрольного агента — его работа будет автоматически восстановлена контролирующим агентом.
Возможно указывать как по одному хосту для установки агента, так и добавить через список массово.
Например, вы устанавливаете один контролирующий агент на одном из серверов, указываете этому агенту в разделе веб-интерфейса «Источники —> Удаленная установка» параметры установки агентов и этот агент автоматически установит агентов и проконтролирует их работоспособность. В случае выхода из строя какого либо подконтрольного агента — его работа будет автоматически восстановлена контролирующим агентом.
Возможно указывать как по одному хосту для установки агента, так и добавить через список массово.
Дистрибутив агента и обновление
Актуальный дистрибутив агента для 32/64 битных платформ можно скачать в разделе «Источники» в правом верхнем углу. Скачивание дистрибутива происходит непосредственно с управляющего сервера, установленного в вашей компании. Обновление дистрибутива на сервере производится вместе с обновлением пакета rusiem-web для коммерческой и свободно-распространяемой версий.
Обновление дистрибутива уже установленного агента и его модулей производится автоматически, при обновлении компонентов на управляющем сервере. Обновление можно отключить для отдельных агентов через веб-интерфейс управляющего сервера.
Обновление дистрибутива уже установленного агента и его модулей производится автоматически, при обновлении компонентов на управляющем сервере. Обновление можно отключить для отдельных агентов через веб-интерфейс управляющего сервера.
Шейпинг канала между агентом и сервером
Для агентов можно установить параметры пропускной способности, ограничивающие скорость передачи на слабых каналах связи в зависимости от времени и дня недели.
Резервный сервер для агентов
Агент поддерживает два сервера для передачи событий. Основной и резервный. В случае недоступности основного сервера — передача осуществляется на резервный. При восстановлении основного — возобновляется передача на него.
Резервный сервер для агента устанавливается глобально для агентов в разделе веб-интерфейса «Настройки» и может быть переопределен в разделе «Источники» индивидуально для агента.
Управляющий сервер агента
Управляющий сервер у агента может быть только один. Агент опрашивает управляющий сервер по протоколу https, авторизуется на управляющем сервере и получает с него параметры сбора, настройки агента и параметры передачи. Изменить управляющий сервер возможно:
Агент передает события на основной/резервный сервер по tcp/3515 в зашифрованном виде. Параметры шифрования индивидуальны для каждого агента.
Сервера, на которые отправляет события агент могут быть отличные от управляющего сервера.
Назначение источников сбора для агентов
Назначение источников сбора для агентов и управление ими осуществляется непосредственно с веб-интерфейса.
После установки агента, он подключается к указанному в настройках управляющему серверу, регистрируется на нем с уникальным идентификатором. По умолчанию, в случае установки вручную, для агента не назначено источников сбора.
Поддержка NAT и DHCP
При подключении к управляющему серверу, агент получает уникальный идентификатор и аутентифицирующие параметры. Вся дальнейшая работа с агентом осуществляется вне зависимости от IP адреса агента, имени его хоста. При этом, агент может быть за NAT.
Локальная база данных агента
Агент содержит в составе дистрибутива собственную встроенную базу данных с шифрованием данных. Нет необходимости в установке и приобретении сторонних баз данных и лицензий.
Встроенная база данных служит посредником для сохранения событий во избежании их потерь в случае отсутствующего подключения с сервером.
Во избежание переполнения диска, существуют параметры ротации, которые можно изменить индивидуально для каждого агента. По умолчанию, в случае остатка свободного места на диске 15% — агент отправляет на сервер предупреждение (и регистрируется инцидент в коммерческой версии RuSIEM по правилу корреляции). А в случае остатка 12% и менее — включается ротация (перезатираются старые события). Режим ротации предназначен для мобильных устройств в случае долгого отсутствия подключения к серверу отправки событий.
Агент поддерживает два сервера для передачи событий. Основной и резервный. В случае недоступности основного сервера — передача осуществляется на резервный. При восстановлении основного — возобновляется передача на него.
Резервный сервер для агента устанавливается глобально для агентов в разделе веб-интерфейса «Настройки» и может быть переопределен в разделе «Источники» индивидуально для агента.
Управляющий сервер агента
Управляющий сервер у агента может быть только один. Агент опрашивает управляющий сервер по протоколу https, авторизуется на управляющем сервере и получает с него параметры сбора, настройки агента и параметры передачи. Изменить управляющий сервер возможно:
- редактированием секции конфигурации агента C:\Program Files\Rusiem\LogAgent.config — <add key="AdminUrl" value="https://172.16.0.124/api/v1/remote/encrypt/agent" />, где 172.16.0.124 — пример ip управляющего сервера
- с помощью утилиты RuSIEM Agent Replicator, позволяющей удаленно установить, удалить и управлять агентами
- при установке «Выборочная» msi пакета
- в секции веб-интерфейса «Источники —> Удаленная установка» на контролирующем агенте
Агент передает события на основной/резервный сервер по tcp/3515 в зашифрованном виде. Параметры шифрования индивидуальны для каждого агента.
Сервера, на которые отправляет события агент могут быть отличные от управляющего сервера.
Назначение источников сбора для агентов
Назначение источников сбора для агентов и управление ими осуществляется непосредственно с веб-интерфейса.
После установки агента, он подключается к указанному в настройках управляющему серверу, регистрируется на нем с уникальным идентификатором. По умолчанию, в случае установки вручную, для агента не назначено источников сбора.
Поддержка NAT и DHCP
При подключении к управляющему серверу, агент получает уникальный идентификатор и аутентифицирующие параметры. Вся дальнейшая работа с агентом осуществляется вне зависимости от IP адреса агента, имени его хоста. При этом, агент может быть за NAT.
Локальная база данных агента
Агент содержит в составе дистрибутива собственную встроенную базу данных с шифрованием данных. Нет необходимости в установке и приобретении сторонних баз данных и лицензий.
Встроенная база данных служит посредником для сохранения событий во избежании их потерь в случае отсутствующего подключения с сервером.
Во избежание переполнения диска, существуют параметры ротации, которые можно изменить индивидуально для каждого агента. По умолчанию, в случае остатка свободного места на диске 15% — агент отправляет на сервер предупреждение (и регистрируется инцидент в коммерческой версии RuSIEM по правилу корреляции). А в случае остатка 12% и менее — включается ротация (перезатираются старые события). Режим ротации предназначен для мобильных устройств в случае долгого отсутствия подключения к серверу отправки событий.
Удаленное управление нодами
И в коммерческой версии RuSIEM и в свободно распространяемой версии RvSIEM имеется возможность удаленного управления нодами.
В распределенной инфраструктуре устанавливается множество серверов RuSIEM/RvSIEM, которыми необходимо управлять. Сервера могут быть связаны разнообразными способами, могут быть независимыми. Подключаться к серверам можно и через веб интерфейс с URL сервера, к которому необходимо подключиться, но это не всегда удобно. Поэтому, существует возможность удаленного подключения из того же веб интерфейса без смены URL с мгновенным переключением на другой сервер, где можно посмотреть инциденты, добавить правила корреляции, изменить настройки сервера. Достаточно в правом верхнем углу выбрать меню ноды, выбрать саму ноду и нажать кнопку подключения.
В распределенной инфраструктуре устанавливается множество серверов RuSIEM/RvSIEM, которыми необходимо управлять. Сервера могут быть связаны разнообразными способами, могут быть независимыми. Подключаться к серверам можно и через веб интерфейс с URL сервера, к которому необходимо подключиться, но это не всегда удобно. Поэтому, существует возможность удаленного подключения из того же веб интерфейса без смены URL с мгновенным переключением на другой сервер, где можно посмотреть инциденты, добавить правила корреляции, изменить настройки сервера. Достаточно в правом верхнем углу выбрать меню ноды, выбрать саму ноду и нажать кнопку подключения.
Подключение осуществляется по протоколу https через действующий API key на ноде, к которой осуществляется подключение и с правами пользователя на этой ноде. Пользователь может обладать ограниченными правами, отличными от прав на ноде, с которой он подключается. Это актуально может быть, например, для SOC.
В редакторе нод возможно выстроить удобную для вас топологию с вложенностью для более интуитивного понимания расположения серверов.
Спецификация
Не лимитировано:
- Размер хранилища
- Срок хранения
- Количество пользователей
- Количество агентов
- Поисковые запросы
- Количество источников и устройств
- Отчеты
- Правила корреляции
- Дашборды
Возможности
- безлимитное количество подключаемых источников и пользователей (операторов)
- cбор событий с источников
- нормализация событий по единой таксономии
- симптоматика: тегирование событий понятными оператору фразами
- индивидуальные для каждого оператора представления
- поиск и навигация по событиям
- сортировка/группировка и визуализация поиска
- формирование сохраненных запросов оператором для оперативного вывода данных
- рискменеджмент: определение весов событий по их содержанию через симптоматику
- возможность переопределения веса событий оператором
- создание собственных симптомов оператором
- долгосрочное хранение
- навигация по событиям
- отображение на виджетах дашбордов
- построение отчетов
- формирование и отправка отчетов по расписанию
- аутентификация внутренняя/LDAP/гибридная
- ролевая модель доступа
- управление агентами из web интерфейса
- управление другими нодами из web интерфейса
- корреляция в режиме реального времени
- создание новых правил корреляции операторами в графическом конструкторе без написания кода
- использование списков в правилах корреляции
- оповещение в случае срабатывания правила корреляции
- изменение шаблона присылаемых уведомлений оператором
- регистрация инцидента во встроенном workflow, построенному по ITIL
- запуск проактивного действия (скрипта) при срабатывании правила корреляции
- формирование нового события в результате срабатывания правила корреляции
- разделение доступа и областей видимости в инцидентменеджмент в соответствии с ролевой моделью
- изменение областей видимости в инцидентменеджмент при переназначении/эскалации инцидентов, либо постановке задач внутри инцидента
- эскалация/переоткрытие/переназначение инцидентов
- постановка задач в инцидентах
- уведомление о задачах по электронной почте
- решение кейса: Интерактивный вход без прохода в офис с интеграцией со СКУД
Масштабирование
- Масштабируется вертикально (по филиалам и регионам)
- Масштабируется горизонтально (увеличение производительности)
- Кластер базы данных может быть установлен на несколько серверов (без дополнительных лицензий)
- Возможно разделить компоненты по нескольким серверам
- Распределенная корреляция
- Распределенные запросы без необходимости централизации событий
Требования
RuSIEM Monitoring позволяет оценивать в моменте нижеследующие параметры, а также большое количество других показателей, доступных через WMI, SSH, SNMP.
ТРЕБОВАНИЯ К ПЛАТФОРМЕ
Установка возможна на гипервизоры или физические сервера.
ОПЕРАЦИОННАЯ СИСТЕМА
Продукт может быть установлен на операционные системы:
Рекомендуемые
· Ubuntu 22.04x64 (полная версия, НЕ minimized)
· Astra Linux Special Edition РУСБ.10015-01
(версия не ниже обновления 1.7)
Поддерживаемые
· Ubuntu 18.04x64
Рекомендуется установка на свежую установленную операционную систему.
Рекомендуемые
· Ubuntu 22.04x64 (полная версия, НЕ minimized)
· Astra Linux Special Edition РУСБ.10015-01
(версия не ниже обновления 1.7)
Поддерживаемые
· Ubuntu 18.04x64
Рекомендуется установка на свежую установленную операционную систему.
Мы предоставляем возможность попробовать триальную версию. Продукт может быть развернут у вас вашими силами, либо мы можем подобрать сертифицированного партнера, который вам поможет установить и настроить.
Демо-версия