Skip to main content
Loading...

Симптоматика - технология, разработанная нашей компанией и используемая в продукте с 2015 года.

Translation section to English will be available soon


1. Понимать что происходит

Пользователи, работающие с системой, работают не с одним источником, а с сотнями различных. События от них имеют разный формат, отличаются и текстом и event.id и категориями. Пользователю должно быть понятно что происходит. Представьте, что вы смотрите на события. Даже для эксперта - большой поток событий словно в фильме "Матрица" набор быстро сменяющихся символов. Представьте, что вы смотрите на такой экран. Что если вместо символов будут символические картинки? Например, фотография вашего друга, обозначение "ест", "бутерброд". Вы уже понимаете что происходит. И даже если посадить другого неподготовленного человека - он также будет понимать практически сразу.
Симптом в RuSIEM - базовый минимальный элемент, действие. Как мы рассматривали выше - "ест", "красный", "root", "неуспешный вход", "самоподписанный сертификат", "старт службы" и прочее.
Почти каждое событие в системе тегируется одним или несколькими симптомами. Мы заранее учим систему понимать источники, расширяя границы симптоматики. Пользователи также могут создать свои собственные симптомы и ими будут тегироваться события.
В большинстве - это общие симптомы, но есть и специфические для конкретных систем. На момент написания статьи в RuSIEM более 1,700 симптомов и их количество постоянно расширяется.


2. Оперативно найти необходимые данные

Пользователю необходимо быстро найти данные. Без экспертных знаний по источнику, долгих воспоминаний как выглядят искомые события. К тому же, в экстренных и стрессовых ситуациях при возникновении инцидента, в случае иных факторов (таких как болезнь. личные проблемы, метеорологические условия) - пользователь может упустить важные данные, не найти их. С использованием симптоматики можно не строить сложных запросов, а указать базовые понятные симптомы. Например, "создание учетной записи", "Успешный вход 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.
Пользователь может создать свои симптомы, которые будут увеличивать или уменьшать суммарные веса событий в зависимости от различных факторов. При поиске по событиям, мы можем в запросе указать вывести критичные события с весом, выше или равно указанного и, таким образом, отсеить незначимые, что позволяет сконцентрироваться на действительно важных событиях.


6. Хранить долго только критичные события

С симптоматикой изменяется и подход к хранению. Нет смысла экономить место на основной оперативной базе, выделяя архивное на старые более медленные диски. Если вам потенциально могут понадобиться события из архивного хранилища - вы не сможете все равно их оперативно подгрузить и использовать. В расследовании причин сбоя, инцидентов важно время. Вне зависимости от уровня систем защиты и обнаружения угроз, события приходится хранить от 3х месяцев до 3х лет. Иногда это регламентировано требованиями регуляторов и стандартов. Это достаточно большие объемы данных.
В RuSIEM нет разделения на оперативное (онлайн) и архивное хранилище. Данные разделяются на три основных типа - Unparsed (не распарсенные события), Inf (Информационные) и Imp (Impersonate, важные). В настройках указываются вес, который делает событие "Важным". По умолчанию, события с весом 7 и более - Важные. Критерий может быть изменен в настройках пользователем. События с весом 7 и более попадают под контроли в международных стандартах ИБ.
Как уже упоминали выше - пользователь может оперировать суммарными весами событий создавая свои симптомы с положительными и отрицательными весами.
Устаревшая концепция разделения на онлайн и архивное хранилище, а так же различные схемы масштабирования, создание отказоустойчивых производительных кластеров баз данных так же присутствует в продуктах.


7. Экономия трафика и пересылка событий в SOC

Суммарные веса событий используются и в фильтрации в различных схемах пересылки. Например, RuSIEM/RvSIEM установленный на небольшом филиале хранит все, а события с весом, к примеру, 12 и выше пересылает в режиме реального времени в центральный офис или SOC. Кроме того, возможна фильтрация по категориям и симптомам.


8. Машинное обучение и аналитика

Вы пытались хоть раз сделать простейшего робота с голосовым управлениям? Активация голосом схожа с симптоматикой. Вы сообщаете роботу "двигаться", указываете направление "вперед", указываете расстояние "2 метра". К этим командам привязана масса паттернов от голоса до конкретных команд шаговым двигателям. Если вы обучаете робота рисовать, то, наверное, вам придется ему сначала заложить понятия что такое квадрат, треугольник, линия, цвет.
Вернемся к нашим симптомам. Передавая события в модуль аналитики, мы уже передаем подготовленные события, имеющие пары ключ-значения в соответствии с таксономией, объекты, действия с ними. Складывая симптомы "Машина" + "едет" + "красный свет" мы агрегируем с различных источников и множества событий достаточные сведения об объекте, действиях над ним и свойствах, что позволяет улучшать работу AI, DL модулей и обнаружить сбои и инциденты на ранеей стадии возникновения, без необходимости писать правила корреляции под каждый конкретный случай.


 

Симптоматика работает как в коммерческой версии RuSIEM, так и в свободно распространяемой RvSIEM. Во всех версиях пользователь может создавать свои собственные симптомы и категории, работать с ними в любых разделах системы.
Для увеличения производительности, скорости прохождения события по симптомам и минимизации ложных срабатываний в каждом симптоме задается фильтр, определяющий какие события будут попадать под симптом.
При интеграции с новыми источниками мы формируем парсеры, симптоматику, правила корреляции и поставляем их в обновлениях.
Все управление симптоматикой осуществляется из веб интерфейса.
Поддерживается мультиязычность - достаточно переключиться на другой язык интерфейса, ввести имена симптомов/категорий на данном языке и сохранить.
В событиях сохраняются не имена симптомов, а их идентификаторы. Поэтому, переименовав симптом - он будет показываться новым именем в уже сохраненных событиях без необходимости операции Update по базе данных.