Практика применения SIEM

SIEM (Security Information and Event Management) — это термин, предложенный аналитиками Gartner в 2005 году для обозначения системы, объединяющей функции управления событиями безопасности (SEM, Security Event Management) и управления информацией о безопасности (SIM, Security Information Management).

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

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

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

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

• Ильшат Валеев, руководитель направления аналитических систем ИБ отдела технического консалтинга и инженерной поддержки компании Axoft.
• Сергей Кривошеин, директор центра развития продуктов NGR Softlab.
• Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG.
• Владислав Николаев, специалист по информационной безопасности, Астрал.Безопасность.
• Андрей Шабалин, аналитик по информационной безопасности NGR Softlab.
• Игорь Таланкин, старший инженер по информационной безопасности, «Лаборатория Касперского».
• Евгения Лагутина, эксперт по системам мониторинга ИБ и SOC-сервисам, «Лаборатория Касперского».
• Даниил Вылегжанин, начальник отдела технического сопровождения продаж RuSIEM.
• Павел Пугач, системный аналитик «СёрчИнформ».
• Василий Кочканиди, аналитик RuSIEM.
• Кирилл Власюк, системный архитектор отдела мониторинга и автоматизации информационной безопасности STEP LOGIC.
• Виктор Никуличев, продакт-менеджер R-Vision SIEM.
• Татьяна Мишина, менеджер по продуктовому маркетингу R-Vision.
• Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies.

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

Сергей Кривошеин, директор центра развития продуктов NGR Softlab:

Сергей Кривошеин, директор центра развития продуктов NGR Softlab 📷

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

Это EPS (поток событий в секунду), поступающий в SIEM. Он пределяет нагрузку в моменте для детектирующей логики, и из этого значения можно получить другую метрику — объемы хранилища, которые определяются длительностью горячего и холодного хранения. Метрики, уникальные для UBA, — количество сущностей, поведение которых анализируется, и экспертная оценка динамики изменений. Например, в условном банке изменений сильно меньше, чем в ИТ-интеграторе.

При этом в проектировании всегда есть ряд допущений при сайзинге: средний размер одного события, средний поток событий от источника событий, производительность дисковой подсистемы (задержи, IO-операции) и т. д. На практике нагрузка часто отличается от проектируемой или изменяется со временем в связи с изменениями инфраструктуры.

Тактики реагирования на изменения нагрузки только две: масштабироваться или тюнить систему:

• Первым делом надо, конечно, провести анализ и тюнинг: все ли события, поступающие в SIEM на хранение, нужны и можно ли что-то отфильтровать? Необходимые события требуют одинакового срока хранения? Какие из них нужны в оперативном доступе (и сколько это по времени), а какие можно поместить на более медленные диски? Что из оставшегося нужно архивировать? Точно ли в инфраструктуре применимы все включенные правила корреляции и какие из них дольше всего выполняются? Возможно ли уточнить правило корреляции, которое выдает большое количество низкокритичных срабатываний?
• Масштабировать SIEM, как и другие системы, можно горизонтально и вертикально. Главное, чтобы система позволяла масштабировать отдельные нагруженные компоненты. Важно, чтобы производитель предоставлял прозрачные и понятные инструкции по масштабированию. Однако в некоторых случаях поможет только анализ реальной нагрузки, например при масштабировании логики поведенческой аналитики: слишком много влияющих факторов, которые почти невозможно предугадать или узнать в опроснике».

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG:

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG 📷

«Идеально, когда основные метрики производительности системы реализованы в самом SIEM.

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

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

В таких случаях приходится углубляться в мониторинг потребления ресурсов компонентами и сущностями SIEM системы.

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

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

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

Необходимо постоянно работать над логикой и качеством создаваемого контента, т.к. плохо написанный контент способен утилизировать существенные ресурса сервера корреляции (ОЗУ и время ЦП).

Просадки производительности сервера хранения событий можно решить путем модернизации хранилища (переход на SSD диски, выбор более быстрого типа RAID), либо расширением базы данных дополнительными нодами».

Владислав Николаев, специалист по информационной безопасности, Астрал.Безопасность:

Владислав Николаев, специалист по информационной безопасности, Астрал.Безопасность 📷

«Существуют несколько ключевых метрик, которые позволяют оптимизировать работу SIEM, например:

• измерение общего объема данных, отправляемых в SIEM в килобайтах, мегабайтах или гигабайтах в день. Это позволяет понять нагрузку на систему;
• число событий в секунду (EPS), обрабатываемых SIEM;
• время, необходимое для обработки данных от момента их поступления до их анализа или уведомления для отслеживания задержек в обработке событий;
• нагрузка на CPU, память и диск. Отслеживание этих параметров позволяет выявить, когда система достигает предельных значений;

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

• провести аудит конфигурации системы и ресурсных затрат;
• настроить мониторинг для отслеживания состояния системы, например, Zabbix, чтобы быстро реагировать на изменения в показателях;
• настройка фильтрации для исключения ненужных событий или агрегацию событий, чтобы уменьшить объем обрабатываемых данных».

Игорь Таланкин, старший инженер по информационной безопасности, «Лаборатория Касперского»:

Игорь Таланкин, старший инженер по информационной безопасности, «Лаборатория Касперского» 📷

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

Первое — количество событий, которое система должна будет обрабатывать, и срок хранения. При этом важно иметь в виду, что имеет смысл рассчитывать не на средние значения EPS (events per second), но и закладывать дополнительные ресурсы на случай увеличения потока событий. Что касается срока хранения, то важно определить, какие данные потребуются в горячем хранении, какие — в холодном, а какие можно сгружать в архив, поскольку обращение к ним будет достаточно редким.

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

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

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

Даниил Вылегжанин, начальник отдела технического сопровождения продаж RuSIEM:

Даниил Вылегжанин, начальник отдела технического сопровождения продаж RuSIEM 📷

«Для современных SIEM-систем требуется достаточно высокая производительность, чтобы обрабатывать большие объемы событий безопасности и данных сетевой активности. Обычно необходимая производительность SIEM-системы измеряется на основе реальных нагрузочных тестов и может отличаться в зависимости от производителя.

Поэтому многие вендоры разработали свою методику расчета требований к виртуальной инфраструктуре, чтобы обеспечить должный уровень производительности системы под конкретного заказчика. Здесь учитывается множество различных параметров: пропускная способность обработки данных в секунду (Events per Second, EPS), возможные задержки при обработке событий, время ответа при выполнении запросов к базе данных, производительность хранилища событий и оценка возможностей гибкого, а главное, быстрого масштабирования системы.

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

Павел Пугач, системный аналитик «СёрчИнформ»:

Павел Пугач, системный аналитик «СёрчИнформ» 📷

«Чаще всего для оценки необходимых для SIEM ресурсов используют параметр Events Per Second (EPS) или количество событий в секунду. Он помогает примерно понять, какие мощности нужны системе для корректной работы.

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

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

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

При этом мы всегда советуем при возможности покупать оборудование «с запасом». Все же при некоторых атаках нагрузка на сервер возрастает на 3-4 порядка. В самой SIEM, конечно, есть ряд механизмов, которые позволяют это компенсировать, но все равно лучше не упираться в потолок.

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

Кирилл Власюк, cистемный архитектор отдела мониторинга и автоматизации информационной безопасности STEP LOGIC:

Кирилл Власюк, cистемный архитектор отдела мониторинга и автоматизации информационной безопасности STEP LOGIC 📷

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

Некоторые SIEM имеют функционал мониторинга собственного состояния, в т.ч. загрузки аппаратной части серверов системы, по которым можно отслеживать пики нагрузки по различным метрикам. Если же такого функционала нет, то отслеживать нагрузку можно с помощью сторонних решений по типу Zabbix или локальных утилит.

Важным является эмпирический опыт пользователей. Если система аномально долго загружает информацию, не может выполнить какую-либо задачу или «тормозит на ровном месте» – это повод обратить внимание на достаточность ресурсов.

Для различных компонентов SIEM разные метрики будут иметь отличный приоритет. Например, компонент, отвечающий за хранение событий, будет более требователен к скорости записи данных на диски и к ОЗУ, а компонент, отвечающий за корреляцию событий – к скорости вычислений. Соответственно, для одного будет более информативным отслеживание утилизации дисковой подсистемы и ОЗУ, а для другого – CPU. Но это не отменяет необходимость мониторинга остальных метрик.

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

Виктор Никуличев, продакт-менеджер R-Vision SIEM:

Виктор Никуличев, продакт-менеджер R-Vision SIEM 📷

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

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

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

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

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

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies:

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies 📷

«Типы и количество систем в инфраструктуре, которые определяют среднестатистическое число EPS, и количество площадок, с которых требуется собирать события».

С какими уникальными сложностями сталкиваются пользователи при масштабировании SIEM? Как вы помогаете им решать эти проблемы?

Виктор Никуличев, продакт-менеджер R-Vision SIEM, отметил, что масштабирование можно рассматривать с разных точек зрения: как расширение технологических возможностей за счёт увеличения используемых ресурсов, как расширение отдельных компонентов системы и как оптимизацию бизнес-процессов.

«Сложности масштабирования ресурсов SIEM вполне распространенные. Одна из распространенных проблем — масштабирование моноинсталляции. Многие проекты начинаются с небольших установок на одном сервере. Однако по мере роста инфраструктуры или подключения новых источников и правил корреляции возникает необходимость в дополнительных ресурсах.

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

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

Ещё один важный аспект, который следует учесть при масштабировании SIEM, — это возможности масштабирования отдельных компонентов. Если с базой данных и коллектором проблем не возникает, они отлично масштабируются горизонтально, то корреляция может стать ограничивающим фактором. Аналитики часто создают собственные правила, и их количество может превышать количество предустановленных. Эти правила могут потреблять больше ресурсов, чем контент от поставщика. В результате может возникнуть ситуация, когда необходимо обрабатывать тот же поток EPS, но с большей нагрузкой, чем было предусмотрено при оценке ресурсов, и масштабировать корреляцию. В таких случаях можно рассмотреть варианты приобретения более мощного оборудования или использования технологии распределённой корреляции, которая позволяет задействовать меньше ресурсов, сохраняя при этом отказоустойчивость и производительность.

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

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

«Это могут быть, например, нетипичное расположение компонентов в инфраструктуре. Либо необходимость нестандартной настройки:

• потоков данных между компонентами или от источников данных в систему;
• взаимодействия и связи между двумя изначально независимыми и несовместимыми инсталляциями систем.

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

Павел Пугач, системный аналитик «СёрчИнформ», указал на то, что кейсы масштабирования SIEM действительно могут быть уникальны.

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

«Например, у нас была ситуация, когда компания-клиент поглотила конкурента. Для ИТ и ИБ отделов это стало сюрпризом – их никто заранее не предупредил. Инфраструктура единомоментно увеличилась на 30%. В итоге к нам обратились за советом.

На помощь пришел «вшитый» инструмент вертикального масштабирования. Это когда организуется структурная схема с центральным и филиальными SIEM. Так и поступили. Выделили в поглощенной инфраструктуре сервер и поставили на него систему. Она взяла на себя нагрузку от нового сегмента и была подключена к центральной SIEM.

Также, у нас есть механизм горизонтального масштабирования — увеличение мощности системы за счет дополнительных серверов. Оба механизма могут быть реализованы без дополнительных лицензий или затрат. А это особенно важно при оперативном реагировании на изменения».

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

«Чтобы этого избежать, мы построили нашу систему на базе микросервисной архитектуры, предполагающей возможности независимого перезапуска отдельных компонентов системы (микросервисов) с сохранением всего потока событий, который продолжает непрерывно поступать в систему.

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

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

«Например, были сложности в горизонтальном масштабировании: некоторые системы имели ограничения по количеству агентов, коллекторов и корреляторов, которые технически было возможно подключить к одному центральному компоненту. С вертикальным масштабированием также были проблемы, поскольку, например, базы данных с устаревшей архитектурой не позволяли увеличивать объем хранимых событий. Были проблемы и с миграцией между версиями продукта, поскольку менялись базы данных.

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

Сергей Кривошеин, директор центра развития продуктов NGR Softlab: «Уникальность обычно кроется в технических аспектах реализации конкретной вычислительной сети заказчика. Например, у одного из заказчиков внедрена распределенная по всей РФ иерархическая инсталляция SIEM Alertix. Это обусловлено в том числе узкими каналами между отдельными площадками эксплуатации: радио или спутник, пропускной способности которых не хватит для потока событий.

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

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

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

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG, отметил, что в проектах его компании они заранее исследуют инфраструктуру заказчика и рассчитывают аппаратную составляющую комплекса SIEM таким образом, чтобы системы была способна справиться с расчетными потоками событий с некоторым порядком запаса. Если архитектура комплекса SIEM изначально спланирована грамотно, то процедура масштабирования проходит довольно безболезненно.

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

Уникальными являются случаи слияния ранее независимых инсталляций SIEM (при объединении группы компаний, к примеру) в единый комплекс. При этом резко возрастают итоговые потоки событий, которые необходимо обрабатывать ядру комплекса SIEM. В таких случаях мы можем предложить заказчику кластерное решение, увеличив мощности основных компонентов ядра SIEM, закупив необходимые аппаратные мощности и дополнительные лицензии, а высвободившиеся аппаратные мощности смежных инсталляций SIEM, по возможности использовать под нужды данной модернизации».

Как интегрировать нестандартные источники событий в SIEM?

Ильшат Валеев, руководитель направления аналитических систем ИБ отдела технического консалтинга и инженерной поддержки компании Axoft:

Ильшат Валеев, руководитель направления аналитических систем ИБ отдела технического консалтинга и инженерной поддержки компании Axoft 📷

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

Процесс в таком случае можно разбить на несколько ключевых этапов:

1. Исследование источника событий. Прежде, чем приступить к интеграции, необходимо тщательно изучить источник данных: Провести анализ документации, если она имеется, проверить информацию из открытых источников. Определить ОС, на которой работает источник. Выяснить, где хранятся логи: это может быть база данных, локальные файлы журналов (системные или собственные логи приложения) или другие места. Проверить возможность отправки логов по стандартным протоколам, таким как Syslog, что значительно упрощает интеграцию. Анализ формата логов: могут быть различные варианты, такие как CEF, LEEF, plain text, JSON и другие. Формат логов будет напрямую влиять на процесс нормализации в SIEM.
2. Настройка транспорта и сетевых взаимодействий. На этом этапе необходимо выбрать подходящий метод передачи данных от источника в SIEM. Это может быть пассивный сбор через протокол Syslog/NetfLow/и другие, прямой доступ к базе данных с помощью SQL-like запроса для извлечения логов, WMI-транспорт для удаленного сбора событий с Windows-инфраструктуры, использование дополнительных агентов/коллекторов или другие механизмы. Важно также настроить сетевые доступы, убедившись, что трафик безопасно проходит через сеть.
3. Нормализация событий. После успешной интеграции источника необходимо заняться анализом поступающих логов. Это тоже один из самых интересных этапов при подключении неподдерживаемых источников. Разные SIEM-системы предлагают свои инструменты для нормализации событий, чтобы переводить сырые логи в единый формат. Данный процесс требует разработки парсеров, фильтров и правил обработки событий. На этом этапе также важно определить, какие логи полезны аналитикам для мониторинга, а какие можно отфильтровать инструментами SIEM.
4. Оценка и корректировка. Интеграция не заканчивается на этапе подключения. Необходимо регулярно оценивать качество собираемых данных, корректировать правила обработки и нормализации по мере появления новых типов событий или изменений в логах источника.

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

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

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG: «Перед реализацией новых интеграций мы проводим детальное исследование потенциального источника и среды его функционирования, в рамках которого уточняем подробности о версиях ПО и ОС, возможностях подсистемы аудита и форматах ведения журналов событий.

В первую очередь, подсистема аудита событий источника, должна уметь хранить или экспортировать информацию в доступных для внешнего анализа форматах – это могут быть human-readable человекочитаемые лог-файлы, информация из таблиц базы данных, либо готовый модуль выгрузки событий по протоколу syslog или snmp. Сама платформа, на основе которой функционирует источник событий должна иметь техническую возможность взаимодействия по протоколам и механизмам сетевого доступа (SSH, API, RPC, NFS, ODBCJDBC и т.п.), для того чтобы агент SIEM смог удаленно подключиться к источнику и собрать интересующие нас данные.

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

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

Владислав Николаев, специалист по информационной безопасности, Астрал.Безопасность: «В зависимости от операционной системы, установленной на источнике, настройка отправки событий в SIEM будет отличаться. В случае, если на источнике установлена *nix подобная ОС, отправку событий необходимо настраивать через syslog, если на источнике установлена ОС Windows, то в конфигурации SIEM требуется указать директорию, из которой будут собираться логи.

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

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

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

«Соответственно, в первую очередь необходимо определить, каким образом возможен сбор событий с источника. Для этого иногда требуется не только обратиться к документации или к администраторам системы, но и написать разработчику ПО. Современные SIEM-системы поддерживают множество различных вариантов транспорта, начиная от стандартных протоколов tcp/udp, чтения файлов и обращения к таблицам баз данных и заканчивая некоторыми специфичными, такими как kafka и API.

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

Если же с транспортом проблем нет, то дальше разрабатывается нормализатор, что занимает не так много времени — от нескольких часов до недели-двух в случае с довольно объемными источниками в части телеметрии. Срок разработки зависит и от удобства инструмента, который предоставляет SIEM-система. Соответственно, важно обращать на это внимание на этапе выбора платформы».

Даниил Вылегжанин, начальник отдела технического сопровождения продаж RuSIEM, заявил, что в первую очередь, нужно определить транспорт, с помощью которого события «нестандартного» источника могут быть доставлены в систему: syslog, NetFlow, SNMP или же агентский сбор событий из баз данных, файлов, папок, REST API, SSH, Sysmon и т.д.

«Дальше необходимо написать парсер, для того чтобы событие из «сырого» вида было приведено к нормализованному. В нашей системе заказчик может сам написать новое правило нормализации либо обратиться за помощью к экспертам компании, в среднем, это занимает от 1 до 3 дней.

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

Павел Пугач, системный аналитик «СёрчИнформ», уверен, что зависит от того, что считать нестандартным источником. Если это источник, который обычно не подключается к SIEM, но вдруг понадобилось, то отталкиваться нужно от стандартов логирования.

«У нас, например, их поддерживается пять: Syslog, SNMP, NetFlow, SSH, Event Log. Если нужный источник поддерживает хоть один, с ним можно легко и быстро интегрироваться.

Если отходить от шаблонов, говорить про источники, которые пишут логи «как им удобно», например, в текстовом файле, то интеграция – индивидуальный вопрос вендору. У нас, например, для этого разработаны специальные механизмы и коннекторы, которые позволяют подключиться к источникам «без стандарта» не прибегая к помощи сторонних спецов».

Кирилл Власюк, системный архитектор отдела мониторинга и автоматизации информационной безопасности STEP LOGIC: «Современные решения класса SIEM обладают обширным функционалом по сбору данных. В большинстве случаев предоставляемых инструментов достаточно для решения задачи. Если же их недостаточно, то есть способы предварительно достать и обработать данные таким образом, чтобы их потом собрать SIEM-системой.

Базово план подключения нестандартных источников выглядит таким образом:

1. Определить, где и в каком виде хранятся данные;
2. Определить какие возможности по передаче или сбору данных предоставляет источник и выбрать оптимальный вариант;
3. Проработать вопрос дополнительной настройки источника или стороннего ПО для сбора или отправки данных в SIEM;
4. Определить, насколько информативными могут быть события от источника в зависимости от настроенного уровня логирования и выбрать достаточный уровень для заказчика;
5. Создать коннектор, используя предлагаемые SIEM системой инструменты, с помощью которого будет осуществляться сбор данных;
6. Используя документацию по источнику (или в случае ее отсутствия руководствуясь здравым смыслом), написать правила нормализации. События, обработанные такими правилами, будут удовлетворять парадигме обработки данных или дата-модели данного SIEM-решения. Иными словами, чтобы условное событие авторизации, воспринималось SIEM-системой как событие авторизации, а не событие выключения хоста».

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

«Многие нестандартные источники предоставляют API, что значительно упрощает процесс автоматического сбора данных о событиях. Это избавляет от необходимости ручной настройки. Также активно используется протокол syslog для передачи событий из различных источников.

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

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

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies, отметил, что для этого необходимо написать правило нормализации и при необходимости – корреляции.

Как решить задачу снижения ложноположительных срабатываний в SIEM?

Игорь Таланкин, старший инженер по информационной безопасности, «Лаборатория Касперского»: «Есть несколько способов того, как увеличить точность сработок правил корреляции.

• Первый — разумеется, заниматься расследованием и корректировать правила на постоянной основе: этот процесс не должен заканчиваться, он должен быть регулярным, поскольку SIEM работает в условиях непрерывно меняющейся IT-инфраструктуры. Как минимум постоянно меняются составы учетных записей, в том числе привилегированных, меняется сетевая инфраструктура, а иногда и IT-ландшафт организации в целом. При этом нужно иметь в виду, что написать универсальные правила, которые не будут требовать списков исключений практически невозможно.
• Второе — при формировании корреляционного контента нужно оперировать всей доступной информацией о событии. Для получения таких данных нужно еще на этапе получения событий от источника оценить, какое обогащение доступно для данного события и как добавить к исходному событию максимально подробный контекст. Это могут быть как внутренние источники обогащения — информация о пользователе из контроллера домена, информация об уязвимостях на хостах и установленном ПО и т.д., так и внешние — тут речь об обогащении события данными об индикаторах компрометации.

Разумеется, эти способы лучше всего работают в комплексе, особенно если налажен процесс непрерывной работы с SIEM-системой в части развития корреляционного контента».

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

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

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

Комбинирование этих шагов позволяет постепенно снизить количество ложноположительных сработок больше чем на 80%. Хотя, конечно, полностью убрать ложноположительные сработки не получится. Это увеличивает риск пропуска реального инцидента».

Василий Кочканиди, аналитик RuSIEM:

Василий Кочканиди, аналитик RuSIEM 📷

«Снижение ложноположительных срабатываний в системе управления событиями информационной безопасности (SIEM) является важной задачей для повышения эффективности мониторинга. Чем меньше инцидентов, тем внимательнее они будут рассмотрены специалистами центра мониторинга (SOC), а значит уменьшится вероятность пропустить что-то важное.

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

• донастройка правил корреляции в соответствии с особенностями инфраструктуры;
• исключение шумовых событий, ошибок в конфигурации доменной инфраструктуры, сети, средств защиты информации и информационных систем;
• контекстуализация данных — добавление контекста, такого, как информация об активах, их уязвимостях или данных геолокации. Такая информация поможет лучше оценить реальные угрозы и отфильтровать ложноположительные срабатывания правил корреляции;
• и модерация базы данных сигнатур и индикаторов компрометации (IoC), удаление неактуальных (прежде всего, это касается IP-адресов, которые могут сменить владельца)».

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

«Чтобы ускорить этот процесс, необходимо:

1. Определить причину ложноположительного срабатывания и подтвердить легитимность данного действия;
2. Определить ключевые критерии, и на основании их значений решать легитимно данное действие или нет;
3. Собрать информацию по возможным значениям ключевых критериев, которые будут выступать признаками легитимности или нелегитимности произошедшего события. Например, перечень УЗ, перечень хостов, сопоставление УЗ-хост, время, день недели и т.д.;
4. Выполнить редактирование правила корреляции таким образом, чтобы его логика учитывала собранные ранее данные по признакам легитимности или нелегитимности событий. Необходимо предусмотреть возможность редактирования этих признаков, их добавления и удаления;

Могут помочь организационные и технические меры, такие как:

1. Уведомление администраторов SIEM через оповещение системы заявок о выдаче полномочий пользователю/изменению сетевых доступов/выполнении работ/другого потенциально вредоносного действия для превентивного внесения информации в соответствующие списки легитимной активности;
2. Приведение ролей/прав/должностей/других сущностей в соответствие правилам корреляции, для которых их действия будут считаться легитимными для ускорения процесса внесения исключений;
3. Автоматизации процесса внесения или удаления исключений».

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

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

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

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

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

Что касается популярной темы использования ИИ-инструментов, то тут нужно очень ответственно подходить. Эти инструменты могут работать некорректно, и следить за ними неподготовленному специалисту очень сложно. Существует множество сценариев, в которых они могут дать сбой, включая так называемые дрейф данных и переобучение (overfitting)».

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies: «В MaxPatrol SIEM заложен механизм автовайтлистинга – для снижения ложноположительных срабатываний необходимо заполнить специальные табличные списки. Также глобально решить проблему ложноположительных срабатываний помогает встроенная технология asset management (управление активами), обеспечивающая видимость инфраструктуры и прозрачность происходящего в ней. Сканирование инфраструктуры осуществляется в режиме белого ящика и не приводит к ложноположительным срабатываниям».

Андрей Шабалин, аналитик по информационной безопасности NGR Softlab:

Андрей Шабалин, аналитик по информационной безопасности NGR Softlab 📷

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

Такие ситуации нередки в системах, где существует необходимость в размещении различных стендов (например, для задач тестирования, разработки, проработки интеграций и т. д.), а также присутствует возможность инвентаризации активов «на лету». Следовательно, неплохим решением может также являться проработка логики наполнения таких списков.

Стоит также отметить, что иногда для минимизации ложноположительных срабатываний может возникнуть необходимость в обогащении имеющихся событий дополнительным контекстом из других источников. Также хорошей практикой может стать использование в правилах обнаружения событий от разных источников, например, алертов от UEBA-систем по подходящим конкретному правилу поведенческим признакам сущности. Однако всегда стоит помнить о том, что в погоне за минимизацией false-positive-сработок велик риск исключить из выборки что-то действительно ценное для ИБ-анализа».

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

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

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

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG, заметил, что борьба с false positive – это непрерывный процесс, решить его единожды и на 100% не получится, но работать над этой проблемой обязательно нужно. Эксперт уверен, что необходимо применять комплексный подход к настройкам ИТ-инфраструктуры и средств защиты.

«Определенно стоит начать с наведения порядка в IT-инфраструктуре, дабы минимизировать «паразитные» потоки событий с источников. Провести инвентаризацию активов и субъектов контролируемой зоны, чтобы качественно использовать данную информацию для настройки приоритезации и исключений в параметрах правил корреляции. Как пример: заставить администраторов инфраструктуры использовать только персонифицированные учетные записи на узлах сети, все сервисные учетные записи, их роли и права должны быть зафиксированы, также, как и подозрительные, на первый взгляд, но легитимные потоки между узлами сети. Всю эту информацию можно занести в специальные списки, далее необходимо настроить логику правил корреляции таким образом, чтобы они не реагировали на легитимные действия, основываясь на данных из созданных вами ранее списков.

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

Ильшат Валеев, руководитель направления аналитических систем ИБ отдела технического консалтинга и инженерной поддержки компании Axoft: «Снижение ложноположительных срабатываний (false positives) – одна из ключевых задач при внедрении и эксплуатации SIEM-систем. Ложные срабатывания увеличивают нагрузку на аналитиков, отвлекая специалистов от реальных инцидентов и снижая общую эффективность системы. Для минимизации их числа можно использовать несколько подходов:

1. Оптимизация правил корреляции. Необходимо регулярно пересматривать и корректировать правила корреляции в SIEM. На начальных этапах внедрения система может генерировать много ложноположительных срабатываний, так как правила часто настроены слишком широко или не учитывают специфику конкретной инфраструктуры. К оптимизации можно отнести: уточнение условий корреляции событий, добавление исключений для известной легитимной активности, настройка правил таким образом, чтобы они учитывали контекст, например, рабочее время, конкретные типы устройств и пользовательские роли.
2. Настройка метрик и порогов срабатывания. Иногда правила настроены на слишком чувствительные метрики, что приводит к частым срабатываниям на обычные действия. Нужно правильно определить базовые пороги для каждого типа активности.
3. Фильтрация легитимной активности. Если определённые действия или события постоянно вызывают ложные срабатывания, их можно исключить через белые списки (whitelisting) или настройку фильтров.
4. Использование механизмов машинного обучения. Некоторые SIEM-системы уже поддерживают машинное обучение, что позволяет выявлять аномалии и отклонения на основании прошлых данных. Обученные модели могут значительно уменьшить количество ложных срабатываний, так как они учатся отличать обычные рабочие процессы от потенциальных инцидентов.
5. Мониторинг качества правил и регулярный анализ. Необходимо внедрить процессы постоянного мониторинга качества срабатываний SIEM. Например, регулярный анализ инцидентов, отмеченных как ложные срабатывания, позволяет выявлять закономерности и улучшать правила. Важно взаимодействие аналитиков с инженерами для внесения оперативных изменений в правила корреляции и настройки.

Снижение ложноположительных срабатываний требует комплексного подхода. Внедрение этих мер поможет сфокусироваться на реальных угрозах, значительно увеличивая эффективность работы аналитиков и SOC».

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

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

«Наиболее частые вопросы, получаемые нами по линии технической поддержки от наших заказчиков — это вопросы настройки активов и источников, запросы на поддержку новых версий источников при их обновлении, а также кейсы, связанные с производительностью SIEM. Четко выстроенный процесс техподдержки, и ведение специалистами сервис центра собственной базы знаний по уже известным и решенным ранее кейсам, позволяет максимально оперативно предоставлять решения нашим заказчикам.

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

Владислав Николаев, специалист по информационной безопасности, Астрал.Безопасность: «В процессе технической поддержки SIEM у пользователей могут возникать следующие проблемы:

• необходимость доработки отправки событий с источника или подключение новых источников для увеличения количества логов;
• ненормализованные события;
• необходимость обогащения полей.

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

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

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

Евгения Лагутина, эксперт по системам мониторинга ИБ и SOC-сервисам, «Лаборатория Касперского»:

Евгения Лагутина, эксперт по системам мониторинга ИБ и SOC-сервисам, «Лаборатория Касперского» 📷

«Есть две основные группы проблем, с которыми пользователи приходят в поддержку производителя: если продукт не работает так, как должен, и если продукт не работал так, как хотелось пользователю, он попытался это исправить, и теперь продукт не работает так, как должен.

• В первом случае все сложности обычно связаны со сбором достаточного количества данных о системе: иногда приходится последовательно искать корень проблемы в разных компонентах. Либо данные, запрашиваемые инженерами поддержки, кажутся избыточными. А иногда и не кажутся.
• Второй случай предполагает, что пользователь приходит в поддержку с неподдерживаемым сценарием: некорректно выбрана ОС, сайзинг не соответствует минимальным требованиям либо пользователь пытался выполнить с системой операции, не предусмотренные документацией: например, правки и запросы напрямую во внутренние базы данных продукта или использование методов приватного API.

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

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

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

Кирилл Власюк, системный архитектор отдела мониторинга и автоматизации информационной безопасности STEP LOGIC, акцентировал внимание на том, что проблемы могут быть самые разные – от простого подключения источника до нетривиальных сбоев в работе компонентов системы или ее логики. Основным и самым лучшим практическим решением, которое может избавить от 90% проблем, является внимательное чтение документации и следование её требованиям. Чаще всего, там описаны типовые ошибки и способы их устранения. Проблемы могут возникать из-за непонимания пользователем того, как работает система или отдельные её механизмы. Тут поможет только практическое изучение системы, чтение документации, прохождение курсов.

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

Виктор Никуличев, продакт-менеджер R-Vision SIEM: «В этом году мы провели опрос среди пользователей SIEM-систем, чтобы узнать об их опыте работы с этой технологией. Респонденты выделили несколько трудностей, с которыми они столкнулись при использовании SIEM:

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

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

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

Современные архитектуры, такие как Kubernetes, обеспечивают простое масштабирование в несколько кликов, что делает SIEM-системы особенно привлекательными для бизнеса».

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies, заявил, что основные проблемы — это отсутствие знаний по «траблшутингу». Для решения этого вызова, мы выпустили специальный учебный курс. А также отсутствие системы мониторинга в компании.

«Чтобы решить это, мы в Positive Technologies разработали собственную систему самоанализа «здоровья» SIEM. Вместе с продуктом мы поставляем рекомендации по установке Grafana и готовые настройки для мониторинга «здоровья» уровня ОС для компонентов MaxPatrol SIEM. Для мониторинга «здоровья» продукта применяются внутренние механизмы в продукте».

Какие интеграции SIEM с Threat Intelligence предпочитают пользователи, и что делать, если такая интеграция не приносит ожидаемых результатов?

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies, заявил, что пользователи предпочитают интеграции с той системой, которая имеется у них в компании. А кастомизируемая карточка события в MaxPatrol SIEM позволяет обеспечить такую интеграцию для бесшовного запроса данных в TI прямо из SIEM.

Татьяна Мишина, менеджер по продуктовому маркетингу R-Vision:

Татьяна Мишина, менеджер по продуктовому маркетингу R-Vision 📷

«Интеграция SIEM с Threat Intelligence не имеет строгих правил, поскольку это зависит от навыков команды аналитиков. Например, можно загрузить IoC из доверенного источника в активные листы SIEM и добавить их в проверку через корреляцию. Другой способ заключается в настройке правила в SIEM, которое перенаправляет события в нужное место назначения — платформу Threat Intelligence. Платформа в свою очередь анализирует этот поток, выделяет события и ищет в них индикаторы, указывающие на компрометацию. Стоит отметить, что такой подход требует дополнительной настройки на стороне SIEM, при этом обеспечивает более высокую производительность. А платформа TI, как правило, дает больше возможностей по работе с индикаторами компрометации, что повышает их качество.

Если интеграция не даёт ожидаемых результатов, необходимо проанализировать всю цепочку действий. Возможно, из SIEM не приходит весь объем нужных событий. А может быть, правила, согласно которым TIP выделяет в событиях артефакты, также нуждаются в доработке.

Что касается целесообразности подобных интеграций, то здесь всё зависит от задач, которые решает команда».

Кирилл Власюк, системный архитектор отдела мониторинга и автоматизации информационной безопасности STEP LOGIC, уточнил, что в разных решениях класса SIEM интеграция с TI-платформами реализована по-разному. Где-то это поставляемые вендором фиды, которые просто хранятся в таблицах, участвующих в правилах корреляции. Где-то есть полноценное потоковое обогащение событий информацией о выявленных в них IoC или интеграция с TI-платформой, дающая возможность по запросу отправлять информацию из события на проверку на наличие IoC.

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

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

Василий Кочканиди, аналитик RuSIEM, указывает на то, что на сегодняшний день предпочтения пользователей сводятся к использованию интеграции для доступа к базам IoC. Это не всегда приносит результаты: если злоумышленники профессионалы, такие индикаторы компрометации (IoC), как IP серверов, hash суммы исполняемых файлов и url ссылки, становятся неактуальными после первого использования. Но и польза от них тоже есть – они защищают от уже известных векторов атак и их автоматизированных версий, которые используют ВПО или не очень квалифицированные взломщики.

«Для усиления защиты есть два пути:

• построить процесс выявления на поиске следов активности (специфических файлах, ветках реестра, утилитах), а также тактиках, методах атак (тут в помощь аналитикам придет проект MITTRE ATT&CK);
• использовать машинное обучение и искусственный интеллект, которые выявят аномалии в сетевом трафике, действиях пользователей и событиях, происходящих на рабочих станциях и серверах».

Павел Пугач, системный аналитик «СёрчИнформ»: «Пользователи в основном применяют те интеграции с Threat Intelligence (далее TI), которые «вшиты» в другие продукты: у антивирусов есть базы с хеш-суммами файлов, у NGFW списки скомпрометированных ресурсов и т.д. То есть SIEM уже получает логи с учетом встроенных TI.

Другая ситуация, если есть обязательные c точки зрения закона TI. Например, от ФинЦЕРТ. Это финансовый регулятор, который рассылает индикаторы компрометации. Банки и другие финорганизации должны использовать их в SIEM и вот здесь уже начинаются интеграции. Например, в нашей системе можно быстро сформировать на основе индикаторов компрометации от ФинЦЕРТ списки исключений, которые можно применять к имеющимся правилам любого источника».

Игорь Таланкин, старший инженер по информационной безопасности, «Лаборатория Касперского», признаёт, что Threat Intelligence — довольно широкое понятие, включающее в себя различные типы данных и инструменты для работы с ними. Их применимость различается в зависимости от уровня зрелости компании.

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

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

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

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

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG, объяснил, что смысл интеграции – передача от TI в SIEM индикаторов на проверку. Если результата в виде выявления инцидентов нет, то это говорит о том, что в инфраструктуре нет данных индикаторов, т. е. атак.

«Хорошо это или плохо? С одной стороны, хорошо, инфраструктура под защитой и не скомпрометирована, с другой стороны, причина, может быть, в плохой выборке индикаторов для проверки. В любом случае история с TI — это о поднятии компетенции SOC в части аналитики возможных угроз и ожидать гарантированного результата в обнаружении здесь не стоит. Скорее TI+SIEM — это прививка — профилактика против гриппа. В нашей компании такая интеграция в SOC построена».

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

Андрей Шабалин, аналитик по информационной безопасности NGR Softlab, указал, что, прежде всего, стоит чётко понимать заложенную в UBA-систему логику работы, т. к. методы поведенческого анализа в действительности различаются от системы к системе: например, одна система может использовать под капотом предобученные ML-модели, которые отлично справляются с типичными атаками, другая система — исключительно статистические матфункции, идеально подходящие для профилирования нормальной активности сущности, третья — и то и другое.

«За сложными угрозами зачастую стоят злоумышленники с компетенциями намного выше классических script kiddie. В таких случаях каждая атака ограничена лишь «полётом фантазии» хакеров, и их действия внутри инфраструктуры с высокой вероятностью будут хотя бы немного отличаться от организации к организации. Предобученные ML-модели в таких ситуациях могут оказываться чуть менее эффективными по сравнению с классическими статистическими методами анализа.

Базовыми поведенческими признаками вроде «Доступ в нерабочие часы», «Подключение из нестандартной локации», «Нетипичное время работы» и др., скорее всего, сейчас мало кого можно удивить, однако по сей день они являются весьма эффективными для обнаружения злонамеренной активности. В одном из кейсов профилирование активности сервисных учётных записей помогло вовремя выявить компрометацию одной из таких УЗ. Как это часто бывает в инфраструктурах с неоткалиброванными правилами детектирования, служебный пользователь генерировал значительное количество ложноположительных сработок в результате совершенно легитимной активности — регулярного создания бэкапов в ночное время. Триггером же для проведения дополнительных изысканий у заказчика в данном случае стали именно возникшие рядом со сработками алерты о нетипичном времени работы учетной записи, что в корне расходилось с расписанием выполнения задач по автоматизированному сбору информации на конечных хостах».

Игорь Таланкин, старший инженер по информационной безопасности, «Лаборатория Касперского», подчеркнул, что сценарии применения UBA достаточно ограничены: как следует из аббревиатуры, речь идет о поиске отклонений в поведении пользователей. При этом нужно учитывать, что если говорить именно о пользователе, а не о любой сущности в инфраструктуре (как если бы речь шла все-таки об UEBA), то описание профиля пользователя — не самая сложная задача для инструмента формальной логики. То есть для правил корреляции SIEM-системы.

«Соответственно, если говорить об эффективности применения UBA, стоит сначала определить, какие задачи анализа действий пользователя актуальны и нельзя ли обойтись теми возможностями, которые доступны в SIEM.

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

Павел Пугач, системный аналитик «СёрчИнформ», уточнил, что использовать UBA в связке с SIEM не совсем корректно. Эти системы «сосредоточены» на разных вещах, видят данные с разных сторон. SIEM, как система, работает с элементами IT-инфраструктуры: межсетевыми экранами, «свичами», а также с ПО, например, антивирусами. UBA же работает с пользователем. Составляет его «цифровой слепок» и мониторит в нем изменения.

«UBA корректнее использовать в связке с решением, объектом наблюдения которого является пользователь. Например, с DLP. Тем более в большинстве таких систем либо есть легкая интеграция с UBA, либо вовсе есть встроенные модули, отвечающие за поведенческий анализ».

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

«Интеграция UEBA и SIEM приносит ощутимые результаты в обнаружении случаев злоупотреблений правами и выявлении внутренних нарушителей. UEBA использует объектно-ориентированный подход, фиксируя все нелегитимные и аномальные действия объекта. Например, обращение пользователя к множеству документов и посещение нестандартных ресурсов. Возможность анализировать таймлайн объекта с точки зрения аномальных проявлений позволяет провести расследование и быстро определить артефакты инцидента. Одно из преимуществ UEBA — применение технологий машинного обучения и низкое потребление ресурсов сотрудников при высоком качестве детекта.

Например, один из наших клиентов, используя R-Vision UEBA, обнаружил набор сервисов, в которых хранились учетные данные пользователей, и они в автоматическом режиме выполняли сбор данных».

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies: «В MaxPatrol SIEM используется модуль Behavior Anomaly Detection (BAD). Этот модуль анализирует поведение как пользователей, так и процессов и хостов, выявляя аномалии в поведении. В продукте реализована передача части нормализованных событий для поддерживаемых в BAD систем, где они анализируются моделями машинного обучения и каждому событию присваивается risk score. Далее у оператора SIEM есть возможность обращать дополнительное внимание на инциденты, где есть события с высокими показаниями риска или вывести события, не участвующие в корреляционных событиях, у которых тем не менее есть высокий risk score. Тем самым мы можем искать злонамеренную активность, на которую не сработали или еще не написаны правила корреляции.

Также мы можем избежать пропуска злонамеренной активности, которая случилась из-за излишнего вайтлистинга».

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG: «UBA или UEBA-система получает события безопасности из SIEM для проведения поведенческого анализа.

Использование UBA в связке с SIEM позволяет:

1. Выявить отклонения в легитимных действиях, минимизировать ложноположительные срабатывания правил корреляции SIEM. Например, скомпрометированная учетная запись при атаке может выполнять допустимые политиками безопасности действия, такие как создание/удаление задач в планировщике, запуск команд, системных утилит и прочее. И при создании правил корреляции SIEM на подобные легитимные события, неизбежны ложноположительные инциденты. При поведенческом анализе, паттерн поведения скомпрометированной УЗ будет отличаться от паттерна нормального поведения этой УЗ, что позволит обнаружить признаки компрометации и снизить ложноположительные срабатывания правил SIEM на каждое легитимное событие.
2. Приоритизировать расследование инцидентов. В случае, когда одновременно регистрируется множество инцидентов на разных хостах или по одинаковым правилам корреляции SIEM, приоритизировать очередь расследования инцидента поможет уровень скоринга хоста, рассчитываемый UEBA.

Т. е. первым взять в работу следует инцидент, в котором вовлеченные объекты (хосты, учетные записи) имеют максимальный уровень скоринга».

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

Татьяна Мишина, менеджер по продуктовому маркетингу R-Vision, отметила, что SIEM и SOAR — это ключевые инструменты для решения задач по выявлению и реагированию на инциденты. Качественная интеграция работы этих инструментов напрямую влияет на работу всего SOC.

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

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

Самой объемной задачей на нашей практике был кейс, когда было необходимо реализовать полную автоматизацию SOC и контента SOAR под кастомный контент в заказчике. Необходимо было сопоставить каждое правило заказчика с техникой Mitre».

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies, назвал блокировку ряда учетных записей с закрытием сетевого доступа во время реагирования на атаку при помощи MaxPatrol О2.

Кирилл Власюк, системный архитектор отдела мониторинга и автоматизации информационной безопасности STEP LOGIC: «У одного из наших клиентов процесс расследования инцидента был формализован в виде простого, но весьма обширного списка действий, которые нужно выполнить вручную, а сам процесс расследования инцидента никак не фиксировался. Интеграция SIEM с SOAR позволила нам не только настроить полноценный плейбук с ветвлением по древу выборов в зависимости от принятого специалистом решения, но и автоматизировать все рутинные действия с помощью скриптов, API-запросов и других инструментов SOAR.

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

Павел Пугач, системный аналитик «СёрчИнформ»: «Если речь идет прежде всего про время реагирования на инцидент, то эффективнее всего будет оставаться в рамках одной системы. Любая интеграция SIEM с SOAR или IRP будет работать медленнее, чем использование соответствующего функционала в SIEM (если он есть).

Да, автоматическое реагирование на инциденты (а именно оно, пожалуй, является наиболее значимым отличием SOAR и IRP от SIEM) — не совсем характерный для SIEM функционал. Но когда-то и полностью зрелые классы решений только приобретали свои очертания. Возможно, в будущем это станет определенной «базой». Об этом, например, говорят сами ИБ-специалисты, у них есть на это запрос».

Евгения Лагутина, эксперт по системам мониторинга ИБ и SOC-сервисам, «Лаборатория Касперского»: «У одного из заказчиков был уже устоявшийся план реагирования на алерты от системы DLP. Как можно понять, DLP генерирует алерты на постоянной основе, на которые в той или иной мере следует реагировать как минимум с помощью запроса объяснений от пользователя, который нарушил политику. Для автоматизации этого процесса были выделены несколько веток действий в различных ситуациях в зависимости от типа алерта от DLP.

При срабатывании алерта в SOAR передавался лишь ID события, после чего все дальнейшие действия по большей части происходили автоматически: по данному ID обогащалась карточка инцидента, по данным учетных записей заполнялась детальная информация по пользователям, после чего генерировалось автоматическое письмо на адрес руководителя сотрудника, нарушившего политику, с просьбой пояснить необходимость отправки подозрительного письма. Письмо содержало всю детальную информацию, соответственно, глядя на него, можно было легко сориентироваться и выбрать один вариантов — подтвердить или не подтверждать легитимность действий подчиненного. После этого ответное письмо приходило обратно на адрес SOAR и плейбук продолжал дальнейшую работу по реагированию. Если легитимность не была подтверждена, то инициировалась блокировка пользователя, создавался тикет в систему заявок с просьбой связаться с пользователем с целью сброса пароля или дальнейшей переустановки ОС (если легитимность письма не была подтверждена самим пользователем). Также происходило подключение к почтовому серверу. Данное письмо выгружалось как вложение в SOAR, а также отдавалась команда DLP заблокировать данное действие, так как после алерта данное письмо находилось в ожидании решения. Также данная автоматизация включала и другие сценарии, но они были чуть проще и не подразумевали таких кардинальных действий.

Автоматизация такого плейбука в значительной степени разгрузила аналитиков, так как не было необходимости самостоятельно составлять письма и вовремя анализировать ответы от них, не требовалось работать в нескольких консолях, а в случае неоднозначных ситуаций SOAR-система сама оповещала аналитиков, когда было необходимо их решение».

Как эффективно интегрировать SIEM с системами управления уязвимостями (Vulnerability Management), чтобы ускорить устранение критических уязвимостей? Можете привести пример, когда такая интеграция помогла оперативно предотвратить серьезные угрозы?

Павел Пугач, системный аналитик «СёрчИнформ», заявил, что интеграция SIEM с любой Vulnerability Management (далее VM) системой реализуется через специальный коннектор. Это повышает скорость при выявлении и устранении уязвимостей. Но помимо скорости устранения, также важна и вариативность.

«Приведу пример. У нас в системе помимо коннекторов к VM-системам, условному сканеру RedCheck, есть еще и встроенный сканер сети, с возможностью сканирования сети на уязвимость. Он не старается конкурировать с какими-то профессиональными решениями, а позволяет выявлять уязвимости со стороны 9 разных БДУ (баз данных уязвимостей): IBM, Microfocus, MITRE, ФСТЭК и т.д. Это дает возможность пользователю принимать наиболее взвешенное решение».

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

«Для этого можно создать группы активов с определенными уязвимостями или табличные списки с уязвимыми активами, настроить правила корреляции таким образом, чтобы они учитывали информацию в этих группах или таблицах. Тогда, например, инцидент простого будничного сканирования хоста внешнего периметра инфраструктуры сразу из критичности INFO перейдет в CRITICAL, если правило корреляции увидит, что хост имеет уязвимость, которая позволяет выполнить на него удаленную атаку. Таким образом, VM помогает SIEM с приоритезацией инцидента, а SIEM – указывает, что уязвимость, которую не устранили ранее, могла быть теоретически проэксплуатирована и требует внимания».

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

Евгения Лагутина, эксперт по системам мониторинга ИБ и SOC-сервисам, «Лаборатория Касперского», прокомментировала, что интеграция любого средства защиты информации с SIEM позволяет оперативнее реагировать на те инциденты, которое оно выявляет. В случае с VM — это наличие критических уязвимостей.

«В данном случае SIEM может ускорить процесс устранения несколькими способами. Первый — универсальный: оповестить администраторов ИБ о том, что найдена критическая уязвимость, либо создать тикет в IRP/SOAR/ITSM, который будут требовать немедленного решения в соответствии с заранее описанным процессом. Второй — зависит от возможностей SIEM и степени интеграции с VM или другим средством контроля состояния конечных точек: сразу же запускать задачу загрузки и установки патча, изолировать уязвимый хост, дополнительно сканировать хост для получения актуальной информации о его состоянии.

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

Дмитрий Шамаев, менеджер по продукту Ankey SIEM NG:

1. «Система VM должна оперативно в режиме реального времени обновлять данные в SIEM о выявленных уязвимостях на хостах. Системы VM передаёт данные о найденных уязвимостях в SIEM, где они сопоставляются с событиями и логами в реальном времени. Это позволяет более точно оценить, какие уязвимости могут представлять реальную угрозу на основе активности и попыток эксплуатации.
2. Корреляция попыток эксплуатации уязвимости и данных о наличии уязвимостей на сервере. Т. е. SIEM видит какие уязвимости эксплуатируют и каким уязвимостям действительно подвержены серверы, что позволит получать уведомления и максимально оперативно выполнять действий в отношении защищаемого хоста, изоляция, обновление, hot fix.
3. Применение автоматизации – т. е., если правило с пункта 2 отработало, то к хосту могут быть применено реагирование: например, временная изоляция, до применения обновлений или других исправлений уязвимости
4. Приоритезация хостов – т. е. хосты, которые чаще других подвержены атакам получают обновления в первую очередь (публикуемые ресурсы и т.д.)
5. Обратная связь в режиме реального времени, т.е. если обновление было выполнено SIEM получает об этом информацию, дабы избежать ложных срабатываний и отслеживать динамику исправлений уязвимостей».

Как использовать SIEM для анализа и прогнозирования инцидентов в условиях гибридной инфраструктуры? Можете привести примеры, когда это дало ощутимые бизнес-результаты?

Евгения Лагутина, эксперт по системам мониторинга ИБ и SOC-сервисам, «Лаборатория Касперского»: «В контексте информационной безопасности прогнозирование инцидента — это, скорее всего, просто выявление атаки на её ранних этапах, то есть поиск отклонений от заданных политик безопасности до того, как они станут критичными и повлекут за собой серьезные последствия. Соответственно, здесь могут использоваться все возможности SIEM-системы, независимо от того, идет ли речь об on-prem инсталляции или гибридной схеме. В обоих вариантах существенную роль играет анализ архитектуры и бизнес-процессов в процессе формирования корреляционной логики, поскольку независимо от объема и качества предустановленного контента любая компания будет обладать индивидуальностью как в части устройства ИТ-инфраструктуры, так и в части ролей и прав пользователей. Однако в любом случае важно обратить внимание на процесс приоритизации событий и корреляционных сработок. Это возможно реализовать, включая, но не ограничиваясь, профилирование пользователей и активов, описание в SIEM структуры сети и критичности различных сегментов, обогащение событий информацией об индикаторах компрометации и т.д. И, разумеется, необходимо корректное и детальное формирование корреляционного контента».

Сергей Сухоруков, лидер практики продуктов по мониторингу ИБ и управлению инцидентами, Positive Technologies: «Для Махpatrol SIEM нет разницы: on-premise, cloud или гибридная инсталляция. Мы можем работать во всех инфраструктурах при условии выполнения аппаратных и программных требований».

Виктор Никуличев, продакт-менеджер R-Vision SIEM: «Сегодня гибридные инфраструктуры уже не редкость, они часто встречаются в самых разных инфраструктурах. На самом деле, подход в правильном применении SIEM-систем уже не зависит от того, используются ли облачные технологии в организации. SIEM — технология, задача которой получить все необходимые логи и провести их анализ. Инфраструктура в облаках — лишь один из таких источников.

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

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

Павел Пугач, системный аналитик «СёрчИнформ»: «Суть SIEM — работать с источниками событий безопасности. Для нашей системы нет значительной разницы в том, где они расположены — в соседней комнате или в облаке, на другом конце города.

Вопрос при работе с гибридной инфраструктурой немного в другом. Имеет ли система необходимые возможности? Например, отдельные «облачные» коннекторы и правила корреляции, механизмы, которые будут прогнозировать инциденты, как из физической инфраструктуры, так из облачной.

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

Оригинал публикации на сайте CISOCLUB: "Практика применения SIEM".

Смотреть публикации по категориям: Новости | Мероприятия | Статьи | Обзоры | Отчеты | Интервью | Видео | Обучение | Вакансии | Утечки | Уязвимости | Сравнения | Дайджесты | Прочее.

Подписывайтесь на нас: VK | Rutube | Telegram | Дзен | YouTube | X.