ЕСТЬ РЕШЕНИЕ

АНАЛИЗИРУЙ ЭТО

В прошлой статье мой коллега Александр Булатов говорил о том , как понять , что вам нужна SIEM и как убедить в этом несговорчивых руководителей ( см . статью « БОРОТЬСЯ И ИСКАТЬ , ДОГНАТЬ И ОБЕЗВРЕДИТЬ » в № 9 , Сентябрь ). Получилось неплохо , но в статье намеренно был пропущен один принципиально важный смысловой блок , а именно – прогноз . Куда движется развитие SIEM , каким функционалом обрастают эти решения по мере усложнения ИТ-инфраструктуры компаний и ландшафта киберугроз , какие новые задачи обучаются решать . Вопросы настолько интересные , что мы решили вынести их в отдельный материал .

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

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

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

Строго говоря , для этого были и есть системы оркестровки , автоматизации и реагирования – SOAR ( Security Orchestration , Automation and Response ). Они , как и многие другие классы ИБ-решений стали появляться по мере усложнения ИТ-инфраструктур , процессов и ландшафта угроз . Реагировать на атаки становилось все сложнее , поэтому вендоры придумали решения , позволявшие настроить плейбуки и сценарии реагирования на инциденты и затем обогащать их для реагирования на более сложные угрозы .

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

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

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

Второй вызов – это размывание границ между ИТ и ИБ . Средства защиты информации , к которым , без сомнения , относятся и SIEM , должны обеспечивать соответствие и интересам бизнеса в части обеспечения непрерывности процессов , и безопасности информации ( доступность , конфиденциальность , целостность ), и требованиям регуляторов ИБ . Угрозы , которые сейчас выявляются ИБ-системами и ИТ-системами по отдельности , будут сливаться ; для их обнаружения будет использоваться наиболее универсальное решение , каковым , без всякого сомнения , является SIEM . То есть , этому классу решений придется брать на себя реализацию не только ИБ , но и ИТ-функций . ИТ-системы никуда не исчезнут , но будут играть вспомогательную роль . Например , системы контроля доступности сервисов смогут учитываться в качестве источников событий для SIEM-систем . Или системы мониторинга ИТ-инфраструктуры , которые будут все больше сближаться до степени сращивания с SIEM-системами .

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

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

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

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

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