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. На вопросы ответили представители NGR Softlab.
Какие метрики наиболее эффективны на практике для оценки потребности в ресурсах для SIEM, и что вы предпринимаете, когда эти показатели перестают точно отражать реальную нагрузку системы?
Сергей Кривошеин, директор центра развития продуктов NGR Softlab:
«Самыми ресурсоемкими в любой SIEM являются хранилище событий и сложная поведенческая и реже — корреляционная логика или реалтайм-поиск по индикаторам компрометации. Таким образом, есть несколько основных метрик.
При этом в проектировании всегда есть ряд допущений при сайзинге: средний размер одного события, средний поток событий от источника событий, производительность дисковой подсистемы (задержи, IO-операции) и т. д. На практике нагрузка часто отличается от проектируемой или изменяется со временем в связи с изменениями инфраструктуры.
Тактики реагирования на изменения нагрузки только две: масштабироваться или тюнить систему:
·Первым делом надо, конечно, провести анализ и тюнинг: все ли события, поступающие в SIEM на хранение, нужны и можно ли что-то отфильтровать? Необходимые события требуют одинакового срока хранения? Какие из них нужны в оперативном доступе (и сколько это по времени), а какие можно поместить на более медленные диски? Что из оставшегося нужно архивировать? Точно ли в инфраструктуре применимы все включенные правила корреляции и какие из них дольше всего выполняются? Возможно ли уточнить правило корреляции, которое выдает большое количество низкокритичных срабатываний?
·Масштабировать SIEM, как и другие системы, можно горизонтально и вертикально. Главное, чтобы система позволяла масштабировать отдельные нагруженные компоненты. Важно, чтобы производитель предоставлял прозрачные и понятные инструкции по масштабированию. Однако в некоторых случаях поможет только анализ реальной нагрузки, например при масштабировании логики поведенческой аналитики: слишком много влияющих факторов, которые почти невозможно предугадать или узнать в опроснике».
С какими уникальными сложностями сталкиваются пользователи при масштабировании SIEM? Как вы помогаете им решать эти проблемы?
Сергей Кривошеин, директор центра развития продуктов NGR Softlab:
«Уникальность обычно кроется в технических аспектах реализации конкретной вычислительной сети заказчика. Например, у одного из заказчиков внедрена распределенная по всей РФ иерархическая инсталляция SIEM Alertix. Это обусловлено в том числе узкими каналами между отдельными площадками эксплуатации: радио или спутник, пропускной способности которых не хватит для потока событий.
«Уникальность обычно кроется в технических аспектах реализации конкретной вычислительной сети заказчика. Например, у одного из заказчиков внедрена распределенная по всей РФ иерархическая инсталляция SIEM Alertix. Это обусловлено в том числе узкими каналами между отдельными площадками эксплуатации: радио или спутник, пропускной способности которых не хватит для потока событий.
Центральная инсталляция обращается к автономным в регионах и используется только для централизации сведений по запросу: просмотреть инциденты, осуществить осмысленный поиск по событиям конкретной инсталляции или по всем сразу. При централизованном поиске и ожидании ответа от нескольких инсталляций всегда есть какой-то таймаут. Т. е. если какая-то инсталляция долго не отвечает, не надо ждать от нее ответа бесконечно. Однако таймауты в SIEM также связаны с конкретными сетевыми флагами на транспортном уровне, поверх которого он работает.
В конкретной ИТ-инфраструктуре канальное оборудование поддерживало соединение служебными пакетами, что не приводило к разрыву https-сессии по причине недоступности удаленной инсталляции, и таймаут ожидания ответа не происходил. Это вызывало длительные зависания системы в ожидании ответа, который не приходил, но и явного отсутствия сетевой связанности также не было.
Мы реализовали настройку в интерфейсе, позволяющую исключить отдельные инсталляции из поиска вручную на некоторое время. По истечении времени инсталляция возвращалась в состояние доступной для поиска. При этом автоматизировать выявление таких «замерзших по сети инсталляций» не представлялось возможным, т. к. за все время наблюдения отличительных признаков, позволяющих обнаружить ситуации заранее, мы так и не нашли».
Как решить задачу снижения ложноположительных срабатываний в SIEM?
Андрей Шабалин, аналитик по информационной безопасности NGR Softlab:
«Безусловно, первым шагом для снижения ложноположительных срабатываний будет являться дополнительный анализ таких сработок для извлечения дополнительного контекста. В результате проведенных изысканий может быть, к примеру, сформирован список дополнительных исключающих фильтров, который нужно будет добавить в исходное правило. Подобные исключения иногда могут требовать использования активных списков, например в случаях, когда причиной ложноположительных срабатываний является динамично меняющаяся или разрастающаяся инфраструктура.
Такие ситуации нередки в системах, где существует необходимость в размещении различных стендов (например, для задач тестирования, разработки, проработки интеграций и т. д.), а также присутствует возможность инвентаризации активов «на лету». Следовательно, неплохим решением может также являться проработка логики наполнения таких списков.
Стоит также отметить, что иногда для минимизации ложноположительных срабатываний может возникнуть необходимость в обогащении имеющихся событий дополнительным контекстом из других источников. Также хорошей практикой может стать использование в правилах обнаружения событий от разных источников, например, алертов от UEBA-систем по подходящим конкретному правилу поведенческим признакам сущности. Однако всегда стоит помнить о том, что в погоне за минимизацией false-positive-сработок велик риск исключить из выборки что-то действительно ценное для ИБ-анализа».
Как на практике эффективно использовать UBA в связке с SIEM для выявления сложных угроз?
Андрей Шабалин, аналитик по информационной безопасности NGR Softlab, указал, что, прежде всего, стоит чётко понимать заложенную в UBA-систему логику работы, т. к. методы поведенческого анализа в действительности различаются от системы к системе: например, одна система может использовать под капотом предобученные ML-модели, которые отлично справляются с типичными атаками, другая система — исключительно статистические матфункции, идеально подходящие для профилирования нормальной активности сущности, третья — и то и другое.
«За сложными угрозами зачастую стоят злоумышленники с компетенциями намного выше классических script kiddie. В таких случаях каждая атака ограничена лишь «полётом фантазии» хакеров, и их действия внутри инфраструктуры с высокой вероятностью будут хотя бы немного отличаться от организации к организации. Предобученные ML-модели в таких ситуациях могут оказываться чуть менее эффективными по сравнению с классическими статистическими методами анализа.
Базовыми поведенческими признаками вроде «Доступ в нерабочие часы», «Подключение из нестандартной локации», «Нетипичное время работы» и др., скорее всего, сейчас мало кого можно удивить, однако по сей день они являются весьма эффективными для обнаружения злонамеренной активности. В одном из кейсов профилирование активности сервисных учётных записей помогло вовремя выявить компрометацию одной из таких УЗ. Как это часто бывает в инфраструктурах с неоткалиброванными правилами детектирования, служебный пользователь генерировал значительное количество ложноположительных сработок в результате совершенно легитимной активности — регулярного создания бэкапов в ночное время. Триггером же для проведения дополнительных изысканий у заказчика в данном случае стали именно возникшие рядом со сработками алерты о нетипичном времени работы учетной записи, что в корне расходилось с расписанием выполнения задач по автоматизированному сбору информации на конечных хостах».
Прочитать статью целиком можно на сайте CISOCLUB.