Так как из программы SOC Forum меня генеральный партнер мероприятия выкинул, то устрою свой, онлайн SOC Forum в блоге. Буду всю неделю что-нибудь писать по этой теме и начну с обзора своей презентации по тенденциям систем мониторинга, регистрации и анализа событий ИБ, которые можно было бы назвать общепринятой аббревиатурой SIEM, а можно было бы использовать и реже применяемую — SAP (Security Analytics Platform), которую ввела в оборот компания Forrester (свеженький отчет по решениям SAP от Forrester можно найти у меня в канале).
Forrester определяет SAP как «платформу, которая объединяет логи из сети, оконечных устройств, приложений, средств идентификации и других релевантных источников ИБ для генерации высокоточных поведенческих сигналов тревоги и облегчения анализа инцидентов, их расследования и реагирования на них«.
Чем это отличается от SIEM, непонятно, но достаточно вспомнить историю с аббревиатурой EDR от Gartner, которой Forrester и IDC противопоставили свои STAP и EVC.
Но вернемся к основным тенденциям. То, что я опишу ниже базируется на трех ключевых проблемах, с которыми сегодня приходится сталкиваться компаниям:
- Нехватка кадров, особенно высококвалифицированных аналитиков
- Рост сложности и скорости атак
- Усложнение ландшафта современных инфраструктур и ИТ-окружения.
Есть и четвертая, очевидная проблема, которая заключается в необходимости миграции с иностранных решений (если вы сидели на них) на отечественные. Поэтому процесс выбора SIEM/SAP сейчас должен быть более осмысленным, так как и выбор стал e;t, и сроки поджимают, и цена ошибки возросла. Как следствие, мне видятся реалистичными (в том числе и опираясь на происходящее на мировом и российском рынке) следующие направления развития средств мониторинга и анализа событий ИБ:
- Хакерская экспертиза в правилах. Есть эмпирическое правило, что во многих SIEMах до 80% всех правил «из коробки» являются шлаком, который использовать нельзя и их сразу отключают, тратя драгоценное время на создание собственных правил и цепочек правил. При этом возникает сложность — чтобы создать правила, которые ловят хакеров, надо хорошо разбираться в том, как эти самые хакеры действуют. А так как специалисты по ИБ большинства компаний такой экспертизой не обладают, то чтобы SIEM был эффективен, ее надо где-то добыть и формализовать в виде правил для выбранного решения по мониторингу. Такие правила можно получить либо у вендора SIEM, либо у независимого поставщика правил. Будь у нас открыты границы, то можно было бы обратиться к какому-нибудь SOCprime или Picus Security и подписаться на их пакеты правил SIGMA, которые подходят ко многим решениям по мониторингу. Но, у нас, увы, этот вариант не подходит.
- Машинное обучение. Про него сказано уже немало, поэтому просто уточню, что к статическим правилам необходимо добавлять и возможность адаптации, которую и дает машинное обучение, изучающее большие объемы траффика и логов и выявляющее ранее незамеченные или неподпадающие под правила аномалии и подозрительные события. Этот механизм позволяет снизить число ложных срабатываний.
- Помощники. Как сейчас мы подключаем источники событий ИБ к средствам мониторинга? Иногда методом «пальцем в небо», то есть до чего дотянулись или что вспомнили, то и подключили. Более продвинутые компании используют для этого модель угроз, разработанные use cases, соответствующие им техники и тактики из матрицы ATT&CK и имеющиеся в описании каждой техники разделы Detections и Data Sources. Но, что если при инсталляции SIEM вам будут сразу подсказывать, какие источники вам надо подключить? И это только один пример возможных помощников, которые сильно облегчат процесс не только внедрения, но и эксплуатации средством мониторинга. Помощники могут подсказывать выбираемые правила, корректность цепочек правил, источники для обогащения и т.п. Если производитель может вложить в систему экспертизу Red Team, то почему не вложить туда и экспертизу Blue Team? Это в аутсорсинговом или своем SOCе такие «помощники» находятся в головах у своих экспертов, а в отчуждаемом продукте они должны быть «из коробки».
Маппинг источников телеметрии в техники ATT&CK - Мета-события. В свое время в некоторых системах обнаружения вторжений была попытка оперировать не отдельными сработками сигнатур, а целыми мета-событиями, когда отдельные срабатывания СОВ объединялись по определенными правилам, что позволяло не только снизить нагрузку на оператора СОВ, но и сократить число ложных срабатываний. Например, вместо, условно, 5 проверок открытых портов на узле за 1 секунду, мы идентифицировало это как «сканирование». Сейчас, когда в SIEM собираются не только результаты сработок систем обнаружения атак, но сканеров безопасности, EDR/XDR, WAF и других средства, у нас появляется возможность выстраивать гораздо более сложные цепочки, собираемые в мета-события. Причем, это могут быть не только «банальные» «шифровальщик LockBit 3.0», но и события более высокого уровня, ориентированные на бизнес, например, недопустимые события в терминологии Минцифры. Вместо «у вас использована техника Т1020.001 на узле с адресом 192.168.10.27» вы можете увидеть «У вас происходит кража денежных средств с компьютера бухгалтера».
- Data Lake и Fusion Center. Когда все крутится вокруг SIEM, который и является центром вселенной по ИБ, тогда все логи стекаются в систему мониторинга, которая и хранит все события, над которыми и происходит дальнейшая обработка. Тогда нам понадобится, чтобы SIEM умел собирать данные не только от средств защиты информации или операционных систем, но и от различных прикладных систем, в том числе от систем физической безопасности, а также неструктурированные данные из внешних источников типа Telegram, Twitter, соцсетей и т.п. Получается некий Fusion Center. Но что если компания достаточно продвинута и использует у себя озеро данных, в которое стекаются данные от бизнеса и от ИТ, которые используют Data Lake для принятия своих решений. Логично, что в этом случае SIEM будет использовать это озеро как еще один источник данных, что потребует немного иной архитектуры и принципов работы с информацией.
- Распределенная архитектура. В условиях необходимости сбора событий ИБ с площадок в разных часовых поясах по всей стране, а также появления решений класса EDR/NDR/XDR, которые могут и сами брать на себя многие задачи по обнаружению и реагированию, SIEM должны строиться с учетом распределенной, как вертикальной, так и горизонтальной архитектуры, с возможностью использования цепочек SIEM, схемы «главный-подчиненный» и т.п. Безусловно, для большинства компаний это может быть избыточно, но сама SIEM должны иметь возможность работать в разных схемах — и в одиночку, и в цепочке.
- Облака. Есть SIEM, которые могут быть установлены в облаке, а есть SIEM, которые изначально работают из облака. В мире последнее является прямо трендом №1 и такие SIEM «выживают» on-prem решения с рынка (у вторых годовой рост составляет около 4%, а у первых более 20-ти). Не уверен, что эта тенденции у нас находится в списке первоочередных, но со временем и она придет к нам. Все-таки для ряда сценариев, а также для небольших предприятий, это является очень неплохим вариантом решения проблемы с мониторингом ИБ.
- API. Тут все просто — чтобы уметь работать с разными средствами защиты и разными сервисами по ИБ, SIEM должен иметь интерфейс взаимодействия с внешним миром. Здесь скорее проблема в том, что многие российские средства ИБ не имеет таких API, является закрытыми не только для внешнего управления, но и для сбора данных из них.
- Маркетплейс. По желанию заказчиков производители часто делают доработки своих решений — новые коннекторы, новые наборы правил, новые функции и расширения, которые также часто и остаются только в компании-заказчике. Но очень часто заказчики хотят не чего-то необычного и редкого, а того, что могло бы пригодиться и другим компаниям. А при наличии правильной архитектуры SIEM, такие дополнения могут писать сами заказчики, а потом делиться ими. Все эти задачи решает маркетплейс, который присутствует сегодня у иностранных решений и будет появляться у отечественных.
- Автоматизация реагирования. Ну тут вроде тоже все понятно. Но я хочу посвятить этой теме отдельную заметку.
- Консолидация SecOps-инструментов. Вчера вечером в США начался свой «SOC Forum», на котором выступал представитель Gartner с обзором тенденций в области SOCостроения. И среди прочего он сделал предположение, что не только решения класса SOAR, IRP, TIP будут консолидироваться в рамках новой аббревиатуры (ох, любит Gartner придумывать новые аббревиатуры) TDIR (Threat Detection and Response), которая, в свою очередь, сольется с решениями класса SIEM / SAP. И если раньше считалось, что нужно разносить функции мониторинга/обнаружения угроз и функции реагирования, то сегодня акценты сместились и нехватка кадров и требование более оперативного реагирования, а это невозможно без более тесной интеграции компонентов между собой.
Не все из этого вам, возможно, понадобится в работе. Например, вы можете не работать с облаками или иметь небольшую инфраструктуру, что приводит к отсутствию необходимости поддержки облаков или работы из облака и требования к распределенной архитектуре для вас не так критичны. Поэтому оценивайте то, что вам нужно сейчас и может понадобиться в будущем. А пока сама презентация, которую я читал на конференции ФСТЭК:
