Siem

В 2012 году мы начали делать новый большой продукт, призванный сменить MaxPatrol 8. Внутри компании он получил прозвище MaxPatrol X. К тому времени у нас сложилось понимание, что сделать качественно новый продукт можно только полностью поменяв подход к решению задачи. Подход был связан с идеями полномасштабного сбора и анализа информации обо всем происходящем в IT-инфраструктуре (анализ конфигурации узлов, конфигурации сети, анализ происходящего в сети то есть анализ трафика и на узле то есть анализ логов). Из необходимости собирать и анализировать логи, собственно, и родился SIEM. К пятилетию MaxPatrol SIEM, который вышел на рынок в 2015 году, мы решили рассказать историю разработки.

В ходе одного из проектов в 2013 году стали вырисовываться принципы необходимой нам архитектуры обработки данных. Сбор, нормализация, корреляция, хранение. В качестве базиса для нормализации избрали подход MITRE CEE (subject action object state), который в то время казался очень правильным и интересным. Но будущее показало, что реальные события не всегда идеально ложатся в прокрустово ложе академического подхода CEE.

Первые шаги и первые ошибки

В этом абзаце будет много непонятных названий, но мы решили рассказать вам всю правду целиком, и поэтому терпите :)

Первые версии компонентов пайплайна обработки событий были написаны на Python, а события сохранялись в MongoDB. Пропускная способность составляла всего несколько сотен EPS. В 2014 году наши наработки по сбору логов мы интегрировали с MaxPatrol X. Окончательно перешли на RabbitMQ в качестве шины обмена данными как между компонентами большого MaxPatrol X, так и внутри пайплайна SIEM. Расширили функциональность задач сбора данных с проведения сканов до сбора событий и остановились на Elasticsearch в качестве основного хранилища событий. Была разработана отдельная подсистема для работы с инцидентами, которая добавилась к системе сбора, обработки и хранения событий, что приблизило проект к традиционным SIEM-системам. Появился и первый набор предустановленных отчетов, а в качестве движка использовался стандартный компонент FastReport. Часть этих отчетов доступна в продукте до сих пор.

Но кое в чем мы тогда все-таки увязли. При разработке схемы отображения событий в структуру сохраняемого в Elasticsearch документа мы пошли по простому пути имена атрибутов совпадают, что оказалось большой ошибкой. В следующей мажорной версии Elasticsearch (2.x) перестал поддерживаться символ точки, активно используемый нами в качестве разделителя. От случившегося мы были в шоке, жизнь с более классическими технологиями нас к этому не подготовила. Это сильно усложнило переход на новые версии, и мы оказались надолго привязаны к старой версии Elasticsearch. Другим примером принятого тогда простого и быстрого решения с далеко идущими последствиями был выбор JSON в качестве основного формата представления события при его обработке и передаче между компонентами.Неприятных последствий в процессе эксплуатации и развития мы получили полную корзину.

С двигателем, но одним колесом

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

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

Под капотом у нас была интеграция системы с активами, что позволило реализовать важные сценарии: модельные корреляции с использованием данных об инфраструктуре и уязвимостях в правилах корреляции, автоматическое заведение активов из событий, привязку событий к активам и разграничение доступа на базе групп. Мы создали механизм активных списков на базе Redis для доступа к переменному контексту иинтегрировались с на тот момент времени еще PoC будущей системы PT Network Attack Discovery, научившись создавать активы из трафика и принимать из него инциденты. Фактически показали платформу, объединяющую network traffic analysis (NTA), asset management (AM), vulnerability management (VM) и SIEM.

Система работала не гладко (и это мягко сказано, сколько одних только баз данных мы перебрали: Redis, MongoDB, MS SQL, Elasticsearch, PostgreSQL, InfluxDB). Под честное слово к нам пришли первые компании практически на альфа-тестирование длиною в пару лет. В 2015 и 2016 годах мы не столько продавали, сколько ходили по заказчикам, делали пилоты и понимали, что по функциональности и стабильности проигрываем зарубежным конкурентам.

Романтика и суровая реальность

В 2016 году мы выпустили огромный релиз 12 (2.0). В нем были упакованы правила корреляции через графический интерфейс, пользовательские фильтры, уведомления по инцидентам, отчеты по событиям и инцидентам, поддержка импорта внешних логов, логирование и контроль задач, динамический расчет векторов атак потом мы выпилили эту историю, осознав, что рынок пока не готов к такой революции ;) и топология сети. В релиз мы поместили все самое необходимое, чтобы с чистой совестью назвать продукт SIEM-системой.

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

Это был один из самых сложных периодов в нашей работе над продуктом. Помню, как с Алексеем Андреевым, управляющим директором департамента исследований и разработки Positive Technologies, мы четыре часа ходили по улице и спорили. Рядом стоял зорб, символизируя наше настроение (полупрозрачный шар, в котором крутишься, как белка в колесе). Мы работали два или почти три года над SIEM, а скорость разработки становилась все медленнее. Алексей тогда на фоне всех этих сложностей слег с острым гастритом (надеюсь, такое больше никогда не повторится!).

Были и вдохновляющие моменты. В каждый проект мы вгрызались зубами, всегда пытались решить проблему заказчика, сталкиваясь с весьма нетривиальными задачами. Так, например у одной компании были подозрения, что внутренний злоумышленник манипулировал системой документооборота (удалял, редактировал и подделывал документы). Мы подключили всю систему к SIEM, нормализовали не просто события ИБ (кто, когда вошел или вышел, получил права), но и события бизнес-логики (кто, когда подписал документ, опубликовал, прочитал, удалил, направил на исполнение, сдвинул сроки и т. п.). В итоге мы нашли не только источник уже известных инцидентов, но и тех сотрудников, кто регулярно совершал другие злоупотребления, о которых заказчик и не знал. Мы, конечно, были вне себя от радости, а заказчик не очень видя происходящее в инфраструктуре. Ни один западный вендор тогда не стал бы (да и по сей день не будет) заниматься подобными задачами, требующими привлечения экспертов на фултайм. Они поставляют готовый продукт, а все остальное ложиться на плечи интегратора и самого заказчика. Фокус на потребностях клиента стал нашей тактикой на долгое время, так как на тот момент мы поддерживали десятка два популярных источников, а, к примеру, ArcSight (тогда HP, сейчас Micro Focus) и IBM QRadar по 300400. И единственное, в чем мы могли их победить, это в персонификации проблем и задач заказчика. Тогда же мы анонсировали и построили процесс, при котором поддерживали все необходимые системы заказчика: удругих вендоров 300 систем, но мы поддержим именно ваши 20, включая "1C", российскую "крипту" и все прочее.

Чуть позже мы получили сертификаты Министерства обороны РФ и ФСТЭК, и MaxPatrol SIEM оказался единственной сертифицированной отечественной SIEM-системой. Однако мы слегка удивились, когда обнаружили, что это было не так уж и востребовано рынком, а вот в стабильности, поддержке источников, нормализации, удобстве интерфейса зарубежным игрокам мы все еще проигрывали.

Тем не менее продукт потихоньку обрастал мясом; показательными в этом смысле стали 20162017 годы. Релизы 1315 были тяжелой работой по стабилизации и переписыванию большей части мэйнкода: по сути, заново создали продукт. Тогда мы окончательно отказались от Python в требовательных к скорости компонентах в пользу С++, сделали инструментарий разработки правил и формул для пользователей, добавили работу с пользовательскими фильтрами, уведомления, доставку отчетов на почту. Кроме того, мы реализовали механизмы контроля (watchdog) за состоянием системы и управления потоком.

Перестаем топтаться на месте

В релизе 16 мы впервые замахнулись на конкурентов. Пара слов о них. Когда мы презентовали SIEM в 2015 году, у ArcSight была большая часть рынка и сотни инсталляций (на круглом столе на Positive Hack Days в 2016 году их представитель говорил о 300 работающих инсталляциях в стране), а IBM QRadar только заходил на наш рынок, но делал это уже тогда стремительно и успешно. Одновременно с этим через IT-рынок к нам пришел Splunk, и сделал это весьма удачно: он был родом из систем IT-мониторинга, и хотя в нем не было многих важных черт SIEM, таких как агрегация, таксономия, нормализация, для многих задач ИБ он оказался очень удобен специалистам по ИБ (забегая вперед, скажем, что, ко всеобщему сожалению, Splunk принял решение покинуть российский рынок).

В 2017 году мы сделали такие важные штуки, как табличные списки, группировка событий, контроль агентов с ядра то, что было только у очень взрослых игроков рынка. Добавили и механизмы, которых у конкурентов и вовсе не было. Прикрутили Endpoint Monitor (Kernel Mode driver), аналогичный по функциональности sysmon. На базе технологий DPI (Deep Packet Inspection) от PT Network Attack Discovery реализовали Network Sensor для сбора данных о трафике агентом. Создали собственное решение для единого управления пользователями и разграничения доступа для интеграции PT MultiScanner, PT Network Attack Discovery, MaxPatrol SIEM у одного клиента. Это дало первый ощутимый толчок в пилотах и далее в продажах (рис. 1).

Взросление

Два года до этого мы работали на износ, побеждая проблемы и нестабильность продукта. Это было время боли, пота и слез. И вот где-то, кажется, в 2018 году мы победили. В релизах 18 (4.0) и 19 произошли изменения, ради которых и создавался продукт. В первую очередь, система начала работать с активами. Полноценного механизма asset management не было ни у кого. Мы вспомнили идею, с которой все началось: сделать платформу, которая бы могла собирать информацию из множества источников и делать некую виртуальную копию инфраструктуры. После этого мы вживую на каждом пилоте и внедрении могли показать заказчику, что способны решать целый пласт задач, который для конкурентов или дорог, или вовсе невозможен. Но цель была не в преимуществах какой-либо функциональности перед функциональностью конкурентов.

С самого начала истории MaxPatrol SIEM мы стояли на том, что SIEM должен быть не просто инструментом (пусть очень дорогим и высокотехнологичным), SIEM должен содержать в себе готовую экспертизу, позволяющую решать задачи ИБ без целого штата экспертов. На том же круглом столе на PHDays, о котором я упоминал выше, мы рвали на себе рубашку заявляли об этом. Другие игроки смотрели на нас как минимум слегка снисходительно, но в то же время все были согласны друг с другом в том, что работающих SIEM-систем в заказчиках 1020% от общего числа, не больше, а все остальные не работают (и неважно, какой вендор). Главная причина нет квалифицированных кадров. Мы же считали (и считаем), что дело, в первую очередь, не в квалифицированных кадрах, а в том, что SIEM-система должна иметь работающую экспертизу внутри себя. Вы ведь не покупаете антивирус просто как набор инструментов, чтобы самим писать YARA-правила и наполнять список плохих хешей? В 2018 году был дан полноценный старт наполнению MaxPatrol SIEM знаниями. Хотя началось все еще в 2017-м: сначала случилась эпидемия вируса-шифровальщика WannaCry, и мы впервые выпустили правила корреляции вне релиза для его детекта (распространяли через Git в день, когда случилась эпидемия). Далее на весь мир прогремели NotPetya и Bad Rabbit, и осенью мы впервые выпустили пакет экспертизы, в котором собрали всю накопленную PT Expert Security Center экспертизу по детекту актуальных вирусов-шифровальщиков. Тогда же PT ESC принес результаты расследования деятельности хакерской группировки, атаковавшей, среди прочего, военно-промышленный комплекс, и мы сделали второй пакет экспертизы, а к началу 2018 года смогли наладить процесс поставки пакетов экспертизы в продукт.

И вот тут мы должны вернуться к теме asset management чтобы выявлять атаки из коробки, система должна знать инфраструктуру, в которой работает, должна понимать, где контроллер домена и какие события какому узлу принадлежат. Мы наконец-то научились автоматически привязывать события к активам вне зависимости от того, откуда они пришли (то есть даже если это логи с firewall, но в них написано, что с узла А был заблокирован трафик, это событие будет привязано к узлу А, и система будет знать обо всем, что происходило вокруг узла А).

Наконец, в 2018 году в продукте появилась PT Knowledge Base как единая точка входа для управления экспертным контентом. Это база знаний, которая представляет собой высокоуровневый постоянно пополняемый набор данных (рис. 2). Поняв, что хранилища key value на базе Redis нам недостаточно, мы начали разработку собственной базы in-memory. Так появились новые табличные списки, которые дали нам удобный механизм для интеграции SIEM с внешними источниками данных об индикаторах компрометации, для обогащения событий, реализации сложных сценариев обнаружения атак, накопления поведенческих профилей и поиска отклонений от них.

Помимо этого, мы реализовали поддержу географически распределенных иерархических инсталляций с настраиваемой репликацией событий и прозрачным доступом к данным любых площадок. Также добавили модуль для работы с внешними TI-фидами (threat intelligence) и начали переход с MS SQL на PostgreSQL. Все это были потребности наших very large enterprise клиентов, которые теперь готовы на супербольшие проекты с нами.

Настоящее

В 2019 году в релизах 21 (5.0) и 21.1 мы сделали пласт доработок, направленных на архитектурные улучшения для стабильного функционирования в очень больших проектах. Сейчас на нашем продукте без сбоев функционирует один из самых крупных проектов в стране, который входит в топ-10 SIEM-инсталляций России по числу источников событий и объему обрабатываемых событий в секунду. В релизе 21.1 мы также подготовили продукт к OEM-поставкам для тех, кому нужен собственный SIEM, реализовали функциональность по ретроспективному анализу событий на предмет наличия в них индикаторов компрометации, добавили конструктор отчетов и графический конструктор правил корреляции. Появился и доступ к произвольным данных об активах в пайплайне обработке событий через механизм asset grids.

Отдельно отмечу историю нашего партнерства с Solar JSOC. У коллег есть большой опыт работы с SIEM-системами и, главное, с реальными инцидентами и задачами по их обнаружению и реагированию. Некоторые релизы были целиком основаны на запросах в рамках нашего сотрудничества. Больше двух лет кропотливой работы дали свой результат, и сегодняшнее стратегическое партнерство, то, как используют наш продукт, еще больше убеждает нас в том, что мы стали вендором со зрелым продуктом. В 2019 году мы начали поставлять нашу экспертизу на постоянной основе. Это абсолютно уникальная история, которой ни у кого нет, к тому же технологически почти нереализуемая для старых игроков рынка. Сейчас в MaxPatrol SIEM загружен уже 23 пакета экспертизы и они выходят регулярно.

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

Сегодня MaxPatrol SIEM выглядит почти таким, каким мы его и задумывали. Система большими технологическими прыжками догнала западных конкурентов, а во многих моментах и превзошла их. И это нашло отражение в расстановке сил на рынке: по данным IDC, у MaxPatrol SIEM, ArcSight и QRadar примерно по 25% российского рынка (и это было два года назад, сегодня мы оцениваем свою долю в 30%). Но теперь нам и этого мало. И дело даже не в объеме продаж: мы стремимся создать систему, которая изменит привычное представление о SIEM-системах, систему, которая несет в себе знания о том, как выявлять большинство известных инцидентов, и при этом проста и понятна в эксплуатации, не требует экспертов сверхвысокой квалификации. Поэтому работы еще много.

Автор: Владимир Бенгин, директор по развитию продуктового направления Positive Technologies

Огромная благодарность за помощь в написании статьи Роману Сергееву, Алексею Андрееву, Наталии Казаньковой, Андрею Войтенко.

Как видно из названия статьи, сегодня речь пойдет о двух технологиях SOAR и XDR, основное предназначение которых - помочь специалистам по информационной безопасности в вопросе противодействия самым сложным угрозам, APT и целенаправленным атакам.

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

SOAR это следующий шаг эволюции SIEM систем. Осуществляет оркестрацию и автоматизацию процессов управления разнородными ИБ- и ИТ- системами от разных производителей и обеспечивает реагирование на инциденты посредством заранее подготовленных планов реагирования (playbook) без необходимости переключения между различными консолями.

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

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

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

Согласно матрице приоритетов Security Operations от аналитического агенства Gartner за 2020 год, которую я привожу ниже, зрелость технологии XDR и SOAR находятся на одном уровне, в то время как выгода от этих технологий разная, высокая и средняя соответственно. Из матрицы недвусмысленно следует предположение о том, что XDR опережает по своим возможностям технологию SOAR.

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

Какой вывод можно сделать из увиденного? Для этого, на самом деле, достаточно посмотреть на последние две строки в таблице. Технология SOAR никогда не сможет включить в себя XDR функциональность, только если не путем объединения с XDR от этого же вендора или поглащения, например.

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

В общем, лично я ставлю на XDR и его светлое будущее.

А у вас какие мысли?