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

Начнeм наше погружение с того, какие данные необходимы MaxPatrol O2 для работы.

Слева на схеме находятся сенсоры — продукты, разрабатываемые Positive Technologies, и данные, которые они могут отдавать в другие системы:

• срабатывания:

  • правил корреляции (MaxPatrol SIEM, MaxPatrol EDR, PT Application Firewall);

  • правил обнаружения сетевых угроз (PT Network Attack Discovery);

  • сетевых сигнатур АСУ ТП (PT Industrial Security Incident Manager);

• результаты проверок файлов (PT Sandbox, PT MultiScanner);

• данные топологии и сетевой достижимости узлов (MaxPatrol VM, MaxPatrol SIEM);

• данные уязвимостей на хостах организации (MaxPatrol VM);

• модули реагирования (MaxPatrol EDR, PT XDR).

Помимо сенсоров Positive Technologies, MaxPatrol O2 может работать и с данными от СЗИ других вендоров, если их срабатывания можно отправлять в MaxPatrol SIEM.

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

1. Моделирование угроз

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

2. Выделение ресурсов

MaxPatrol O2 анализирует срабатывания сенсоров Positive Technologies, определяет захваченные, атакованные и атакующие ресурсы, например учетные записи, узлы, сессии, процессы, файлы, письма.

3. Обогащение контекстом

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

4. Сбор цепочек активности

MaxPatrol O2 анализирует данные и связывает новые срабатывания сенсоров Positive Technologies с уже существующими цепочками активности в системе. Если ни одна из имеющихся цепочек активности не подходит под критерии «склейки», MaxPatrol O2 создает новую цепочку, к которой привязывает поступившую сработку от сенсора.

5. Оценка уровня опасности активностей

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

6. Остановка злоумышленника

MaxPatrol O2 предлагает аналитику варианты реагирования для каждого типа ресурса, чтобы остановить хакера и вернуть под контроль захваченные ресурсы. Все, что останется сделать аналитику, — это либо согласиться с предложенным сценарием реагирования, сформированным с учетом минимизации влияния на критически важные бизнес-процессы компании, либо скорректировать его по своему усмотрению. Само реагирование осуществляется единовременно агентами MaxPatrol EDR или PT XDR, развeрнутыми в инфраструктуре компании. После завершения выполнения сценария реагирования аналитик может перевести цепочку активности в статус «Архивная».

Теперь давайте разберeм каждый этап отдельно и узнаем, как именно работают технологии, заложенные в MaxPatrol O2.

Threat Modeling Engine

Одной из ключевых технологий MaxPatrol O2 является моделирование угроз, которое мы назвали Threat Modeling Engine (TME). Два года назад мы решили по-другому взглянуть на то, как действуют злоумышленники: что они делают, почему и как. Лучше всего это объяснять на примере.

Давайте рассмотрим, как выглядит глазами хакера почтовый сервис Microsoft Exchange, который всe ещe очень распространeн у наших заказчиков. На нижнем уровне хакер видит сетевые протоколы, например XML SOAP или WSMAN, которые могут содержать уязвимости, позволяющие ему завладеть этим сервисом. Уровнем выше уже находятся сервисы самого Exchange: например, autodiscovery, с помощью которого хакеры могут подбирать учeтные записи. И на самом верхнем уровне находится сама почта, через которую злоумышленники могут осуществлять фишинговые рассылки с целью получения доступа к пользовательским машинам и учeтным записям.

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

Например, злоумышленник хочет подключиться к вашему VPN-серверу. Пререквизитом будет являться учeтная запись с определeнными правами, а также сетевой доступ к данному серверу. Результатом этого действия будет получение сетевого доступа к вашей внутренней инфраструктуре. Или другой пример: хакер хочет проэксплуатировать сетевую уязвимость. Для этого ему нужен сетевой доступ к порту с уязвимым сервисом, а в результате он получит права на этом узле, а также сетевой доступ к другим узлам в инфраструктуре. Ещe один пример: хакер хочет считать память процесса lsass. Для этого ему необходимы права в операционной системе, и в результате он получит учетные записи с аутентификационной информацией из памяти процесса, которыми впоследствии сможет воспользоваться для получения доступа куда-то еще и (или) выполнения действий от имени этих пользователей. При создании MaxPatrol O2 мы смоделировали и разобрали таким образом все действия, которые могут совершать злоумышленники в процессе целевой атаки.

Далее нам пригодилась экспертиза технологий управления активами (asset management), которая накоплена за годы разработки и эксплуатации MaxPatrol SIEM и MaxPatrol VM. Она позволила получить информацию обо всех узлах в инфраструктуре и их конфигурациях (включая уязвимости, учетные записи, сетевые доступы и так далее), а также сетевой топологии. MaxPatrol O2 трансформирует эти знания в те самые ресурсы, которые могут быть интересны злоумышленнику конкретно в вашей инфраструктуре. Используя полученную информацию, MaxPatrol O2 накладывает ее на модель действий злоумышленника в TME, чтобы построить граф возможностей хакера в вашей инфраструктуре. По сути, на выходе метапродукт получает связь всех ресурсов между собой через возможности злоумышленника.

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

Например, возьмeм одно из недопустимых событий Positive Technologies — хищение денежных средств. Мы приземлили его на инфраструктуру вместе с архитекторами ИБ и коллегами из ИТ. В итоге мы получили три варианта, которые могли бы позволить злоумышленнику реализовать это недопустимое событие. Один из них — это формирование или модификация платeжного поручения в 1С. То есть, обладая необходимыми привилегиями, хакер сможет создать платeжку, верифицировать еe и отправить на исполнение. Если детализировать этот вариант ещe больше, то мы сможем определить, какие ресурсы потребуются хакеру, чтобы реализовать это действие. В нашем случае это определeнные права в 1С и определeнные права на операционной системе, где установлено это решение.

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

Собираем цепочки активности

Теперь давайте разберeмся, как MaxPatrol O2 строит цепочки активности. Ведь именно благодаря этой функциональности аналитику не придeтся обрабатывать каждую сработку отдельно и раскручивать всю цепочку атаки вручную, что значительно сократит итоговое время реагирования на инцидент (TTT, TTI, TTM).

Мы назвали этот алгоритм грубой склейкой. Он лeг в основу технической сборки MaxPatrol O2 в 2022 году.

Алгоритм связывал действия атакующих по смыслу:

1. Если нелегитимная активность происходит на одном хосте и на это указывают несколько срабатываний СЗИ, то MaxPatrol O2 свяжет их в одну цепочку.

2. Если со скомпрометированного хоста происходит обращение на сервер атакующих, то эта сработка тоже привяжется к цепочке активности.

3. Если со скомпрометированного хоста начинается продвижение внутрь инфраструктуры (техники lateral movement, discovery), то эти сработки также попадут в уже существующую цепочку.

Такая связка срабатываний становится возможной благодаря выделению ресурсов и их анализу. Когда очередное срабатывание от СЗИ приходит в MaxPatrol O2, оно как бы раскладывается «по полочкам» и из него выделяются ресурсы. Примерами таких ресурсов могут быть хосты, пользовательские сессии в приложениях и на хостах, процессы, учeтные записи и так далее. Допустим, в MaxPatrol O2 поступили сработки, из которых были выделены следующие наборы ресурсов: «хост 1, сессия 1, процесс 1» и «хост 1, хост 2». Благодаря тому что MaxPatrol O2 находит совпадение по ресурсам — «хост 1» — в первом и втором наборах, он склеивает эти срабатывания в одну цепочку.

Также между ресурсами существуют различные типы связей:

1. Если злоумышленник эксплуатирует сетевую уязвимость на каком-то узле в сети, то MaxPatrol O2 определит тип связи ресурсов как «хост захватывает хост».

2. Если злоумышленник проводит разведку со скомпрометированной машины внутри инфраструктуры, то MaxPatrol O2 определит тип связи ресурсов как «взаимодействие без захвата».

3. Если в поступившей сработке придeт информация про хост, сессию и процесс, то MaxPatrol O2 выстроит их в иерархическое взаимодействие.

Разумеется, у алгоритма грубой склейки были свои преимущества и недостатки:

1. Грубая склейка хорошо решала задачу полноты: всe, что происходило на скомпрометированном узле, точно попадало в цепочку активности.

2. Однако такая склейка была избыточна, и цепочки очень быстро разрастались из-за смешения легитимной активности, которую вызывали ложноположительные (false positive) сработки средств защиты, и нелегитимной активности реального злоумышленника.

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

Автоматическое расследование

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

1. Давать ответ на вопрос: склеить или не склеить?

Например, в MaxPatrol O2 поступило две сработки, в первой из которых есть информация о хостах A -> B, а во второй о B -> C. Если обогащение сможет установить между ними причинно-следственную связь, то тогда они попадут в одну цепочку. Таким образом получится цепочка без примеси легитимной активности, а значит, аналитику не придeтся тратить лишнее время на еe валидацию.

2. Вторая задача — это уточнение связей.

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

3. И самая главная задача — это раскручивание цепочек без наличия сработок.

Для примера рассмотрим ситуацию, когда на узле происходит какая-то нелегитимная
активность и MaxPatrol O2 получает сработку от СЗИ, которая на это
указывает. Как правило, в этот момент у аналитика в SOC появляется вопрос: как
атакующие туда попали? И без MaxPatrol O2 человек бы раскручивал эту
цепочку руками, обращаясь к сенсорам за следующими данными:

• Кто заходил на этот хост?

• С каких хостов на него заходили?

• Какие процессы на них запускались?

• И так далее.

В итоге он дойдeт до той точки, с которой началась атака. Мы решили это автоматизировать и написали обогащение Lateral Movement в MaxPatrol O2, которое отвечает на вопрос «откуда началась атака?»

Рассмотрим пример на скриншоте, где мы видим атакующий узел слева и скомпрометированный узел справа, на котором выполнялись команды через SmbExec. В центре мы видим контроллер домена, на котором атакующие воспользовались уязвимостью для повышения привилегий и закрепления. Эту активность не увидело ни одно СЗИ, и поэтому в MaxPatrol O2 не поступило ни одной сработки, указывающей на эти действия. Но вся цепочка была полностью восстановлена в хронологическом порядке благодаря механизму обогащения Lateral Movement. И теперь аналитик увидит, какие ещe хосты были задействованы в атаке, а самое главное — какие процессы задействованы в нелегитимной активности. Без этой информации было бы невозможно провести полноценное реагирование на инцидент.

Оценка уровня опасности

Теперь, когда мы достаточно точно собрали цепочку активности в MaxPatrol O2, встаeт вопрос оценки еe уровня опасности.

Для этого мы можем оперировать сработками, которые попали в цепочку, и ресурсами, которые из них выделились. Сработки оцениваются по уровню опасности (Incident, High, Medium, Low), а также по тому, к какой технике и тактике матрицы MITRE ATT&CK они принадлежат. Кроме того, при оценке уровня опасности MaxPatrol O2 агрегирует однотипные сработки, чтобы их количество не влияло на кратность повышения уровня опасности. Ведь сканирование 500 узлов не сильно отличается от сканирования 5 узлов с точки зрения негативного воздействия на инфраструктуру.

Ресурсы же оцениваются по их роли в сработке: например, атакующие ресурсы имеют больший вес, чем атакованные, но ещe не скомпрометированные. Кроме того, для каждого ресурса рассчитывается показатель Centrality, который характеризует то, насколько этот ресурс привлекателен для злоумышленника. Для этого MaxPatrol O2 обращается к TME, чтобы узнать, какие возможности будут у атакующего после захвата того или иного ресурса и сколько через него пролегает путей до реализации недопустимых событий.

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

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

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

Выбиваем хакера из инфраструктуры

В итоге при получении оповещения о цепочке в статусе «Требует внимания», например, в Telegram, аналитику остаeтся сделать следующее:

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

2. Ознакомиться с автоматически сгенерированным MaxPatrol O2 сценарием реагирования.

3. При необходимости скорректировать его и запустить.

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

Например, если захваченный ресурс — это доменная учeтная запись, то можно заблокировать ее в домене или сбросить от неe пароль. Если учeтная запись локальная, то мы можем выполнить соответствующие действия, но уже на конечных точках (windows\linux\macos). В случае с узлами вам может потребоваться локальная изоляция, либо же, например, блокировка конкретного узла на межсетевом экране.

Таким образом, для каждого типа ресурса мы разработали свой модуль реагирования для агентов MaxPatrol EDR или PT XDR. И когда аналитик открывает вкладку реагирования в цепочке MaxPatrol O2, для каждого типа ресурса подбирается соответствующий модуль реагирования. Помимо этого, метапродукт автоматически решает, какой из агентов сможет реализовать необходимое действие. В итоге аналитик получает полный перечень возможных действий по реагированию, который он может скорректировать по своему усмотрению и запустить.

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

Непрерывное улучшение технологий

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

С 2021 года MaxPatrol O2 работает в тестовом режиме на регулярных киберучениях Positive Technologies параллельно с классическим SOC. В 2022 году мы начали пилотные тестирования в инфраструктурах некоторых клиентов. Именно этот опыт, совмещeнный с экспертизой нашей команды пентестеров (ребята ежегодно проводят более 60 пентестов) и PT Expert Security Center (ежегодно проводит более 50 расследований), позволяет нам улучшать MaxPatrol O2.

На Standoff 12 мы развернeм MaxPatrol O2 в SOC, который будет следить за ходом всего противостояния, и поделимся результатами в телеграм-канале Positive Events, а также на трансляции Standoff Talks 24 ноября.

На этом у нас всe. В следующий раз мы вернeмся к вам с подробным разбором цепочек активности, которые были зафиксированы MaxPatrol O2, и выясним, как должен мыслить аналитик, который будет заниматься их анализом. До новых встреч!

Авторы:

Михаил Помзов

Директор по разработке метапродуктов, Positive Technologies

Антон Тюрин

Руководитель экспертизы метапродуктов, Positive Technologies

Антон Исаев

Технический менеджер по продуктовому маркетингу, Positive Technologies