В мае этого года мы запустили в опытно-промышленную эксплуатацию MaxPatrol O2 — наш автопилот для результативной кибербезопасности. В этом материале расскажем, что подтолкнуло нас к созданию этого метапродукта, как он влияет на метрики SOC и какие вызовы мы ставим перед ним в этом и следующем году.
В Positive Technologies регулярно проводятся киберучения, мы вышли на багбаунти по реализации недопустимых для себя событий и даже увеличили стоимость выплат вознаграждения с 10 до 30 млн рублей. Команды этичных хакеров атакуют нашу инфраструктуру, а специалисты ИБ и сотрудники SOC защищаются. Таким образом мы не только повышаем собственную безопасность, но и тестируем свои продукты, решения и концепции в условиях, приближенных к реальным.
Напомним, что наш основной подход связан с результативной кибербезопасностью и недопустимыми событиями. Мы привыкли проверять все на собственной практике и начали с определения недопустимых событий для компании вместе с нашим топ-менеджментом и отделом консалтинга (хищение денежных средств, кража конфиденциальной информации, внедрение вредоносного кода в продукты). Затем мы приземлили их на инфраструктуру вместе с архитекторами ИБ и коллегами из ИТ, чтобы понять, на каких хостах и при каких условиях они могут быть реализованы. После мы задействовали наши же продукты и технологии с открытым исходным кодом, чтобы совместно с инженерами и архитекторами построить центр противодействия киберугрозам (ЦПК), который должен обеспечить невозможность реализации тех самых недопустимых событий. И конечно же, наши безопасники, пентестеры, ИТ и DevOps достаточно сильно поработали над усилением защиты нашей инфраструктуры, внедрив 96 контролей безопасности (в том числе отказ от доменной авторизации на гостевом Wi-Fi, переход на 2FA и т. д.). Дальше мы подключили к ЦПК ключевые и целевые системы и начали проводить первые киберучения. Тут наш SOC столкнулся с новой для него ситуацией.
Источники в инфраструктуре Positive Technologies генерировали около 1 млрд событий в сутки: серверы, рабочие станции, сетевое оборудование, межсетевые экраны, средства защиты информации (PT XDR, PT Network Attack Discovery, PT Sandbox, PT Application Firewall, Kaspersky Security Center), бизнес-приложения (например, «1С»), инфраструктурные сервисы (Microsoft AD, DHCP, DNS, Exchange, VPN, SCCM), системы виртуализации и пр. После обработки в MaxPatrol SIEM эти события превращались в 30 тыс. срабатываний правил корреляции.
Такое количество срабатываний возникает из-за необходимости гарантированно выявлять действия злоумышленников, которые в ходе атаки часто используют легитимные инструменты, максимально маскируясь под деятельность сотрудников компании. До момента верификации контекста аналитиком сложно отделить легитимную активность от удачно замаскированной злонамеренной. А наша основная цель — не допустить ложноотрицательного результата, благодаря которому злоумышленник сможет продолжать оставаться незамеченным. Мы всегда руководствуемся этим принципом при написании правил корреляции, сигнатур и детектов в наших сенсорах.
В итоге при каждом реальном инциденте (true positive) аналитику в SOC приходилось обрабатывать множество различных срабатываний СЗИ (инцидентов, корреляционных событий, детектов, срабатываний сигнатур и т. д.), порожденных легитимной активностью (false positives), затрачивая в среднем от 7 до 30 минут. В итоге аналитик тратил более 80% времени на обработку сработок, которые на самом деле не требовали его реакции. В результате один аналитик SOC в среднем за смену мог обработать не более 50–100 инцидентов. Такой темп работы может привести к быстрому выгоранию сотрудника, снижению эффективности его работы и появлению ошибок.
Ежедневно обрабатывать вручную такое количество сработок попросту невозможно. Приходится определять критически значимые типы сработок, которые точно необходимо расследовать, например на ключевых системах. У себя мы пришли к числу в 300 сработок в день, которые круглосуточно обрабатывала команда мониторинга (3 смены по 8 часов, по два эксперта в каждой смене).
И эта проблема касается не только нашей компании. По нашей оценке, для осуществления рутинных операций на каждые 10 000 активов инфраструктуры нужно в среднем 5–10 сотрудников SOC. Нехитрые вычисления показывают, что для покрытия командами SOC в топ-50 крупнейших компаний России потребуется около 10 000 экспертов. Такого количества кадров на рынке сейчас просто нет. Поэтому 100% наших клиентов, имеющих собственный SOC, сейчас испытывают кадровые проблемы и нуждаются в расширении штата аналитиков более чем в 2 раза. Как итог — у них нет возможности расширять SOC так же быстро, как растет бизнес компании.
Для себя же мы понимали, что фактически перегружаем свою команду мониторинга выполнением рутинных задач. Мы поняли, что для повышения эффективности команды мониторинга в общем и для масштабирования мониторинга в частности нам нужен автопилот для результативной кибербезопасности. Изучив этот вопрос под другим углом, мы приступили к созданию MaxPatrol О2 — он стал логическим продолжением развития технологий в нашей компании.
У Positive Technologies есть продукты почти для всех направлений ИБ, лучшая команда пентестеров (более чем за 20 лет на рынке ребята накопили большой опыт и ежегодно проводят 60+ пентестов), а PT Expert Security Center ежегодно проводит более 50 расследований. Кроме того, мы являемся организаторами кибербитвы Standoff, которую в этом году провели уже в 11-й раз. Мы наблюдаем изнутри, как работают другие команды пентестеров, какие технологии и техники они используют, как применяются наши продукты Positive Technologies. Оставалось автоматизировать эти знания и обернуть их в форму конечного решения. И у нас это получилось!
MaxPatrol O2 vs. Классический SOC
Давайте посмотрим, как выглядит работа SOC в классическом варианте и как она меняется с внедрением MaxPatrol O2.
В классическом SOC аналитик не предпринимает никаких действий до появления нового инцидента в используемой IRP/SOAR-системе. Однако в некоторых компаниях аналитик может заниматься проактивным обнаружением угроз (threat hunting), просматривая новые срабатывания правил корреляции в SIEM в свободное от разбора инцидентов время.
При появлении нового инцидента начинается отсчет классической метрики TTR, которая разбивается на несколько этапов:
Первый этап, который делает аналитик, — верифицирует новую сработку в системе управления инцидентами по соответствующему плейбуку, чтобы понять, не является ли она ложной (false positive). Этот этап характеризуется метрикой TTQ, и, по нашей оценке, он занимает 5–7 минут.
Далее при подозрении на нелегитимную активность аналитик идет за дополнительными данными (контекстом) в SIEM-систему и (или) другие источники событий или средства защиты, чтобы собрать полную картину: что именно делал пользователь в рамках своей сессии, какие запускались исполняемые файлы или скрипты, переходил ли он на другие машины и т. д. Этот этап характеризуется метрикой TTI и, по нашей оценке, занимает в среднем 20–30 минут.
После того как весь контекст по инциденту собран, аналитик формирует план с необходимыми шагами для реагирования. Если план окажется не слишком сложным, например разорвать сессию пользователя или удалить письмо, то аналитик сможет выполнить его самостоятельно. В других случаях ему придется открыть заявки в соответствующей IT-системе, где он опишет, какие действия и где именно необходимо выполнить для реагирования на инцидент. Этот этап характеризуется метрикой TTM (Time To Mitigate) и, по нашей оценке, в лучшем случае он занимает 5 минут. Однако зачастую, в зависимости от своей загруженности, IT-отдел может приступить к выполнению заявки гораздо позже.
И последняя метрика, которая может сильно варьироваться по времени, называется TTV. Это время, которое требуется аналитику для восстановления инфраструктуры в исходное состояние (самостоятельно или с привлечением коллег из ИТ) и для контроля отсутствия новых сработок в рамках уже закрытого инцидента. Появление таких сработок будет являться признаком продолжения атаки, что приведет к повторному прохождению аналитиком описанного выше пути. В лучшем случае на этот шаг может уйти полчаса, но в случае сложной целевой атаки он может занимать до нескольких месяцев.
теперь давайте посмотрим, сколько будет затрачено времени на те же самые шаги, но уже с учетом внедренного метапродукта MaxPatrol O2 в SOC организации:
Аналитику нет необходимости вручную анализировать каждую отдельную сработку СЗИ, так как MaxPatrol O2 самостоятельно анализирует все поступающие сработки от SIEM-системы и других средств защиты в инфраструктуре. Когда в MaxPatrol O2 собирается цепочка активности (связанные между собой сработки) с высоким уровнем опасности, которая может потенциально вести к реализации недопустимого события, она переводится в статус «Требует внимания» и аналитик получает оповещение, например в Telegram.
Аналитик верифицирует цепочку, чтобы принять решение, действительно ли она похожа на деятельность злоумышленника. А затем он может открыть автоматически сгенерированный сценарий реагирования, изменить его при необходимости и запустить. По нашей оценке, это займет у него примерно 5 минут: от момента открытия цепочки до момента запуска сценария реагирования.
Чтобы убедиться в отсутствии признаков продолжения атаки, аналитику достаточно проверить новые цепочки активности на наличие в них ранее захваченных ресурсов. В любом случае любая новая активность злоумышленника будет точно так же собрана MaxPatrol O2 в цепочку активности вместе со всем дополнительным контекстом атаки.
MaxPatrol O2 на защите Positive Technologies
Сейчас MaxPatrol O2 развернут и функционирует в тестовом режиме в инфраструктуре Positive Technologies. Во время внутренних испытаний мы подтвердили факт того, что система в автоматическом режиме способна детектировать хакерскую активность и даже применять некоторые механизмы по реагированию. И в качестве резюме мы хотим с вами поделиться результатами, которые получили на своей собственной инфраструктуре в 5000 активов. Мы собрали статистику работы нашего внутреннего SOC, который использует классическую систему управления инцидентами, и MaxPatrol O2, который работал независимо от нашего SOC в параллели.
В среднем в классической системе управления инцидентами регистрируется порядка 300 сработок в день, требующих внимания аналитика. На их обработку уходит около 2100 минут или 35 часов времени, что выливается в непрерывную работу двух аналитиков в смене для нашей инфраструктуры. Версия MaxPatrol O2 в 2022 году уже вдвое сокращала количество сработок, поступающих на аналитика, и в три раза — время на расследование за счет автоматически собранного контекста атаки! Коммерческая версия MaxPatrol O2 в мае 2023 года уже показывала десятикратное сокращение таких сработок и времени, затрачиваемого на расследование. А к концу этого года мы стремимся к показателю всего 10 сработок в день, требующих внимания аналитика. Он будет способен обработать их примерно за час своего рабочего времени. Эта цифра становится все ближе благодаря текущим пилотным проектам, которые проходит MaxPatrol O2 у наших заказчиков, и мы обязательно поделимся с вами их результатами ближе к концу года. Полученный опыт помогает нам дорабатывать механизмы сбора и обогащения цепочек активностей, а также механизмы расчета уровня опасности полученных цепочек.
Планы, цели и вызовы
На данный момент MaxPatrol O2 уже позволяет «переваривать» все сработки, получаемые из различных систем, и выделять из них конкретные атаки, которые за ними скрываются. Такой подход позволит освободить команду ИБ от рутинной работы, ведь даже один выделенный эксперт в смене сможет обеспечить по-настоящему результативную кибербезопасность в компании.
То, к чему мы идем в компании, — это полный автопилот, когда аналитик вовсе не требуется для штатного функционирования системы. Конечно, такая амбициозная цель вряд ли может быть достижима в рамках одного года, но мы стремимся приблизиться к ней на горизонте двух-трех лет.
К концу 2023 года мы планируем поставить под защиту MaxPatrol O2 один виртуальный офис c недопустимыми событиями на площадке Standoff 365. Он будет одним из публичных референсов метапродукта, и мы обязательно поделимся с вами результатами его работы, разбирая зафиксированные цепочки атак.
Авторы:
Михаил Помзов
Директор по разработке метапродуктов
Михаил Стюгин
Руководитель направления автоматизации информационной безопасности
Антон Исаев
Технический менеджер по продуктовому маркетингу