Автономные SOC: будущее мониторинга ИБ и реагирования на инциденты

Число кибератак на организации по всему миру увеличивается от года к году. По нашим данным, количество успешных атак на организации за 2023 год увеличилось на 23% по сравнению с предыдущим годом. Увеличивается и размер ущерба от последствий атак — по данным IBM, средняя стоимость утечки данных в мире достигла рекордно высокого уровня в 2023 году и показала рост на 15,3% в сравнении с тремя годами ранее. Общий ущерб от возможных последствий кибератак, включая полную или частичную остановку бизнес-процессов и восстановление инфраструктуры, растет ежегодно на 15% и к 2025 году может составить около 10 трлн долларов.

Рост количества атак на компании происходит по разным причинам. Наблюдается тенденция всеобщей цифровизации — многие отрасли продолжают автоматизировать свои процессы, внедрять новые технологии, как следствие увеличивается количество устройств на внешнем и внутреннем периметре. По результатам исследования компании JupiterOne, общее количество ресурсов, участвующих в бизнес-процессах организаций, увеличилось на 133% за 2023 год. Одновременно с этим инструменты злоумышленников становятся более автоматизированными благодаря искусственному интеллекту, это снижает требования в квалификации для злоумышленников и дает им больше возможностей, например, для разведки данных в открытых источниках, поиска способов сокрытия ВПО от обнаружения, создания дипфейков и фишинговых писем. Как следствие, SOC не справляются с растущей нагрузкой — по данным отчета Devo, 78% сотрудников SOC работают сверхурочно. 

Оценивать способность команды SOC справляться (или не справляться) с возрастающим числом кибератак можно по-разному. Например, отталкиваясь от числа обрабатываемых срабатываний (сигналов тревоги) средств защиты, заведенных в SOC. По данным исследования компании Vectra AI, в среднем команды SOC получают 4484 сигнала тревоги ежедневно. При этом, по данным Positive Technologies, в среднем на анализ одного срабатывания аналитику необходимо около 10 минут, что при 10–12-часовой смене означает способность обрабатывать не более 100 срабатываний. Посмотрим на динамику роста необходимого числа аналитиков и попробуем оценить, какие финансовые ресурсы необходимы компаниям на поддержание такого числа аналитиков с учетом средних размеров заработной платы в России и мире.

Второй срез, по которому возможно оценить количество требуемых аналитиков SOC, — это время, затрачиваемое на работу с каждым инцидентом. И хотя разные инциденты требуют разного времени, согласно отчету Enterprise Strategy Group «SOC Market Trends Report», средняя длительность работы с одним инцидентом составляет 3 часа (при среднем числе задействованных инструментов ИБ — 6). При этом, по данным Morning Consult, в среднем 32% времени аналитика тратится на проверку инцидентов, которые не представляют реальной угрозы для бизнеса.

Зная свое количество срабатываний или инцидентов, вы можете примерно прикинуть, какое количество аналитиков SOC и какой фонд оплаты труда для них вам могут понадобиться (без учета резервирования аналитиков, работы в выходные и ночную смену, болезней и других факторов, что может потребовать увеличения их числа в 2–3 раза).

Но, даже имея необходимое число аналитиков SOC, большая часть их времени тратится неэффективно. По данным той же Vectra AI, 83% всех срабатываний средств защиты — ложные, но на их обработку уходит драгоценное время специалистов, не позволяя им обработать события, которые реально могут характеризовать инцидент ИБ. При этом, по статистике SANS 2023 Incident Response Survey, объем ложных срабатываний за последние годы вырос — с 75,9% в 2019 году до 95,8% в 2023 году. По статистике Morning Consult, аналитики SOC не могут обработать 49% получаемых ежедневно событий ИБ и 97% аналитиков из-за этого чувствуют дискомфорт и неуверенность в результате своей работы, что часто приводит к выгоранию.

Каким образом в таком случае SOC справляться с нарастающим объемом задач мониторинга ИБ? Альтернативным способом является автоматизация всех процессов обнаружения, расследования и реагирования на инциденты, направленная на снижение объема ручного труда специалистов.

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

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

• Недостаточная видимость постоянно меняющейся инфраструктуры и поверхности возможных атак.

• Нехватка контекста для анализа событий ИБ.

• Зависимость от своевременной доставки или разработки контента обнаружения.

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

• Сложности взаимодействия с подразделениями ИТ для оперативного реагирования на инциденты.

• Необходимость расширенного логирования или журналирования источников в инфраструктуре (для повышения шанса обнаружения хакера), которая приводит к большому объему событий ИБ, в том числе ложных срабатываний.

Перечисленные факторы приводят SOC к снижению оперативности детектирования и реагирования на инциденты ИБ, а также к появлению слепых зон в мониторинге инфраструктуры. По данным исследования Экспертного центра безопасности Positive Technologies (PT Expert Security Center/PT ESC) за 2021–2023 годы, среднее время, в течение которого злоумышленнику удавалось оставаться незамеченным в скомпрометированной инфраструктуре, составляет до 45 дней. При этом время, необходимое злоумышленникам для проведения атаки, значительно сокращается. Согласно недавно опубликованному исследованию Palo Alto, за 2023 год время между первоначальным доступом злоумышленника в инфраструктуру и извлечением конфиденциальных данных сократилось до нескольких часов и в 45% случаев не превышало одного дня.

Среди большого количества массовых атак, в том числе увеличивающихся на фоне быстрого развития инструментов ИИ, аналитики рискуют пропустить реальные атаки, которые становятся сложнее детектировать. Так, например, последние несколько лет злоумышленники активно применяют подход living off the land, когда после проникновения в инфраструктуру хакеры используют штатные инструменты скомпрометированной системы для развития атаки и продвижения внутри сети. Такие техники обнаружить достаточно сложно, поскольку активность злоумышленника маскируется под активность легитимных пользователей. Для решения этой задачи современные инструменты SOC должны как минимум иметь встроенные функции поведенческого анализа, основанного на алгоритмах ИИ. По результатам исследования Devo, 55% респондентов отметили, что отсутствие ML-алгоритмов обнаружения атак является основной причиной неэффективности SIEM-систем в их SOC.

Несмотря на многообразие инструментов для SOC, предназначенных для автоматизации обнаружения и реагирования на инциденты ИБ, некоторые ключевые процессы в SOC все еще не автоматизированы, и аналитикам часто приходится вручную выполнять ряд действий, в частности подключать новые источники телеметрии, собирать контекст инцидента в разных сенсорах, число которых в 68% случаев варьируется от 3 до 8, определять цепочку нелегитимной активности в инфраструктуре и формировать сценарии реагирования на инциденты. Фактически же на каждом этапе обнаружения и реагирования на инциденты ИБ есть такие задачи, где из-за нехватки автоматизации кратно возрастает объем нагрузки на аналитиков SOC. Мы собрали основной перечень таких сложных задач и оценили, к каким последствиям они ведут на каждом этапе (рисунок 3).

По результатам исследования SANS, более 40% компаний понимают необходимость движения по пути автоматизации в процессах реагирования на инциденты и восстановления инфраструктуры после кибератак. Сложности, с которыми сталкиваются команды реагирования на инциденты, привели в конечном итоге к осознанию необходимости создания SOC нового поколения, способного решить все сформировавшиеся сложные задачи. Разберемся теперь с тем, каким же должен стать SOC нового поколения и чего мы от него ожидаем?

Главным свойством SOC нового поколения (New Generation SOC) должна стать его самостоятельность, или, иными словами, автономность в обнаружении, расследовании и реагировании на инциденты. Поэтому NG SOC на практике получил название автономного SOC. Официального определения автономного SOC сейчас не существует, и ведущие игроки на рынке кибербезопасности каждый по-своему описывают, что же такое Autonomous SOC. Проанализировав более десятка разных определений, можем составить одно общее:

Появляется вопрос, как можно измерять уровень автоматизации процессов в SOC. Можно ли сразу построить полностью автономный центр мониторинга или необходимо пройти определенные этапы? Будет правильным провести аналогию с беспилотными автомобилями и системой классификации уровней автопилота от SAE и применить схожий подход к SOC. Ранее, в другом исследовании, мы уже изучали данный вопрос, где определили параметры, которыми можно описать разные стадии автоматизации SOC. Всего мы выделили 5 уровней автоматизации, где 1-й уровень предполагает полностью ручной анализ событий из журналов средств защиты, а 5-й уровень означает полную автономность процесса мониторинга ИБ и реагирования на инциденты. Более подробная таблица по стадиям автоматизации SOC представлена в приложении 1.

SOC, как и транспортные средства, проходит долгий путь эволюции от ручного анализа событий из журналов до полного автопилота. Автономность является свойством высокого уровня автоматизации, который достигается путем постепенного создания необходимых инструментов для решения задач SOC. Сложность достижения 5-го уровня (полного автопилота) по аналогии с транспортными средствами состоит в том, чтобы машина могла самостоятельно ориентироваться в неизвестной обстановке, когда нет карты местности, заранее определенных паттернов ситуаций и сценариев действий. Переводя на язык ИБ, как будет вести себя автономный SOC в случае реализации сложного и ранее неизвестного вектора атаки с применением нового сложнодетектируемого ВПО?

Классический центр реагирования на инциденты состоит из ряда компонентов:

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

Первое, с чем можно столкнуться на этапе внедрения SIEM, — это трудности с интеграцией различных источников телеметрии, поскольку встроенные коннекторы не всегда поддерживают необходимые источники и требуется писать коннекторы вручную. Но ряд вендоров уже развивают возможности автоматизации написания правил нормализации. Сложность этой задачи состоит в том, что, во-первых, необходимо определить, а какие данные вообще необходимо собирать с источника, чтобы они были достаточны для обнаружения действий злоумышленника, но не были избыточны, а во-вторых, в ряде случаев необходимо обеспечить конвертацию данных источника в подходящий для SIEM формат. Решением этого вопроса может стать создание такого модуля в SIEM-системе, который будет самостоятельно анализировать форматы различных источников телеметрии, размечать хранящиеся в них данные и передавать их в SIEM-систему. Это достаточно сложная задача, но уже появились первые решения. Например, израильский стартап Avalor создал модуль AnySource Connector, который способен собирать данные в любых форматах с любых источников. Быстрое подключение новых источников телеметрии достигается за счет возможности работать с любыми неструктурированными и неиндексированными данными. Для этого в SIEM-систему внедряются алгоритмы искусственного интеллекта.

Другой важной задачей в автономном SOC является автоматизация обработки огромного числа генерируемых алертов, многие из которых остаются в слепой зоне аналитиков, и устранение ложноположительных срабатываний (false positive). Какие механизмы должны быть реализованы для решения этой задачи?

Традиционно анализ журналов событий, поступающих в SIEM, основывается на правилах корреляции. В основе правил корреляции закладывается логика «если, то», которая позволяет относить события к подозрительным и генерировать оповещение безопасности (алерт). Деятельность злоумышленника в скомпрометированной инфраструктуре во многом часто схожа с легитимной активностью пользователей (принцип living off the land). Получается, что повседневные действия пользователей часто попадают под сработку правил корреляции, из-за чего SIEM генерирует много срабатываний false positive. 
В MaxPatrol SIEM, например, для автоматизации обработки однотипных срабатываний на действия обычных пользователей применяется механизм автоматического вайтлистинга — занесения каждого второго, третьего и последующего срабатывания в список исключений с отметкой ложноположительного.

Для снижения количества срабатываний в SIEM часть аналитических процессов может перекладываться на решения класса EDR/XDR, которые могут сразу на конечных устройствах проводить анализ событий и передавать в SIEM-систему только реальные срабатывания. Для сокращения объема журналов телеметрии могут применяться инструменты, реализующие сжатие, удаление данных и дедупликацию, которые встраиваются в цепочку передачи данных от сенсоров ИБ до хранилищ данных или SIEM-системы и уменьшают объемы передаваемых журналов. Кроме того, появились технологии интеллектуального сжатия журналов событий на основе временных интервалов, такой подход, например, реализован в решении LogSlash.

Правила корреляции, как один из основных механизмов анализа журналов событий, и точка входа аналитической экспертизы в SIEM-систему пока никуда не исчезнут. Вместе с тем появляется возможность использовать ИИ для оценки потенциала правил корреляции. Например, у LogRhythm появился калькулятор risk-based priority (RBP), который оценивает вероятность того, что правило сгенерирует ложноположительный ответ. В то же время уже появляются решения на базе ИИ, которые обучаются на истории инцидентов и могут с определенной точностью самостоятельно оценивать срабатывания SIEM на предмет того, является ли оно истинно положительным или нет. Например, модуль automated responder knowledge (ARK) в Sumo Logic анализирует алерты и распознает в них реальные угрозы. Другим примером является ML-модуль поведенческого анализа — Behavioral Anomaly Detection (BAD) в MaxPatrol SIEM, который способен подтверждать срабатывания соответствующих правил корреляции. BAD работает как система second opinion (второе мнение) и повышает эффективность обнаружения атак за счет альтернативного метода оценки событий безопасности.

Существует, однако, и иной подход для борьбы со срабатываниями False Positive, который основан на внедрении алгоритмов обогащения данных через изучение причинно-следственных связей между несколькими событиями ИБ. Например, MaxPatrol O2 раскладывает все поступающие события на ресурсы (узлы, сессии, процессы, службы, файлы, задачи, учетные записи) и анализирует их, опираясь на знания паттернов действий злоумышленников. При этом MaxPatrol O2 может определять, какой узел или процесс действует активно как атакующий, а какой является реципиентом нелегитимной активности. Такой подход позволяет выделять из числа всех срабатываний SIEM логически связанные цепочки нелегитимной активности с высоким уровнем опасности и тем самым создает фильтр ложноположительных алертов, которые отсеиваются на этапе «склейки» нескольких событий.

Правила корреляции и сигнатуры вредоносной активности позволяют обнаруживать известные паттерны атак и достаточно эффективны в решении таких задач. Но когда речь заходит об обнаружении ранее неизвестного поведения и аномальной активности, то в игру вступают алгоритмы поведенческого анализа. UEBA-функционал заявлен практически в каждом решении, которое претендует на статус автономного SOC или платформы автономных операций безопасности (Autonomous Security Operations Platform). Ценность систем поведенческого анализа состоит в том, что они обнаруживают угрозы на основе отклонений в поведении пользователей, например фиксируют нетипичные запускаемые процессы и открываемые файлы. Это позволяет более точно определять, скрывается ли за действиями пользователя потенциальная вредоносная активность.

В UEBA-системах активно применяется ИИ, и каждый вендор по-своему реализует функционал поведенческого анализа. Так, в UEBA-системах распространены, например, следующие алгоритмы:

• Кластеризации, например метод К-средних (K-means) может разделить всех пользователей на поведенческие группы, а метод k-ближайших соседей (k-nearest neighbors) сравнивает поведение нового пользователя с поведением других пользователей и определяет, является ли он похожим на них.

• Метод опорных векторов (SVM) — алгоритм находит границы между безопасными и небезопасными пользователями и определяет, находится ли новый пользователь внутри или вне этой границы. SVM эффективно работает в пространствах большой размерности и может быть использован для классификации событий безопасности на «реальные» и «ложные».

• Сверточные нейронные сети — используются для обнаружения аномалий в сетевых данных. Они позволяют определить, есть ли в сети подозрительная активность, такая как попытки взлома или распространения вредоносного ПО.

• Алгоритмы коллаборативной фильтрации, изначально созданные для рекомендательных систем. Например, в модуле поведенческого анализа в составе MaxPatrol SIEM (Behavioral Anomaly Detection, BAD) используются именно такие алгоритмы.

Помимо информации о поведении пользователей и сущностей алгоритмы машинного обучения могут использовать знания о техниках злоумышленников, совершаемых на разных этапах атаки, в частности Execution (выполнение), Command and control (управление и контроль) и Lateral movement (перемещение внутри периметра), что дает возможность обогатить поведенческую аналитику экспертными знаниями. Такая интеграция знаний о тактиках и техниках действий злоумышленников реализована, например, в модуле BAD в составе MaxPatrol SIEM.

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

Как автоматизировать процесс обогащения данных? В этом вопросе, так же как и в других, вендоры двигаются по разному пути. Во время анализа сработок правил корреляции у специалистов SOC много времени уходит на «раскручивание» последовательности запуска связанных между собой процессов, это необходимо для принятия решения, является ли сработка SIEM true positive или false negative, а данных только о родителе процесса зачастую недостаточно для оценки ситуации. В MaxPatrol SIEM, например, был реализован механизм, автоматизированно обогащающий любое скоррелированное событие, в котором есть информация о процессе, его полной цепочке, и записывающий данную информацию в отдельное поле.

Для анализа признаков вредоносной активности может потребоваться несколько параметров — учетная запись, хост, запускаемый процесс, IP-адреса источника и адресата и другие. Можно предположить, что алгоритмы искусственного интеллекта позволят создавать автоматизированные фильтры поиска в собранных данных и внешних источниках, анализировать их и выдавать результат — обогащенный контекст по событию ИБ. Например, Elastic модернизировали возможности поиска, внедрив технологии векторного преобразования неструктурированных данных в модуль Elasticsearch Relevance Engine (ESRE). ESRE предоставляет возможности для создания высокорелевантных поисковых приложений с использованием ИИ и дает разработчикам полный набор сложных алгоритмов поиска с возможностью интеграции с большими языковыми моделями (LLM). Результаты поиска могут собираться из разных источников и ранжироваться по релевантности методом Reciprocal rank fusion (RRF). Функционал единого поиска в нескольких хранилищах средств защиты еще, например, обеспечивает решение Query.AI, оно выполняет роль поисковой системы, которая самостоятельно ищет ответ на заданный вопрос во всех подключенных источниках ИБ.

С помощью технологий ИИ можно максимально уменьшить число сработок в SIEM, снизить False Positive, добавить контекст в события ИБ и получить на выходе реальное подозрение на инцидент. А дальше стоит задача развернуть полную цепочку атаки, чтобы понять, как инцидент развивался, где начался, как его остановить и предотвратить возможные дальнейшие шаги злоумышленника. Традиционно аналитики занимаются этим процессом вручную, и на это требуется высокий уровень компетенций, но теперь мы можем поручить эту задачу автономному SOC.

Алгоритмы могут самостоятельно проанализировать наличие связей между хостами, процессами, учетными записями, открытыми сессиями и выявить аномальное взаимодействие между объектами, которого в нормальном поведении системы не должно быть. Причем важно не только определить, между какими объектами или сущностями есть аномальные связи, но еще и определить вектор движения злоумышленника — какой ресурс в сети действует как атакующий, какие ресурсы захвачены злоумышленником, какие узлы подвергаются сканированию и попытке захвата. Для выявления цепочек атак используются данные об активах в защищаемой инфраструктуре, знания о тактиках, техниках и процедурах злоумышленников и индикаторы компрометации, интегрированные в алгоритмы. Такой функционал уже реализован во многих решениях, например MaxPatrol O2, Exabeam Fusion и Hunters Security демонстрируют возможности автоматического анализа и формирования «истории атаки». Информация о цепочках атак и задействованных в атаках ресурсах отображается в виде графа, в котором может быть несколько подграфов с векторами движения злоумышленника.

Автоматизированное построение цепочек атак подразумевает, что алгоритмы автономного SOC знают топологию сети и располагают информацией о защищаемых ресурсах. Значит, такие сведения необходимо сначала автоматизированно доставить в SOC.

Для эффективного автоматизированного построения цепочек атак необходима актуальная информация о топологии сети и активах. Для этого в автономный SOC интегрируются функции систем класса Asset Management, чтобы непрерывно получать информацию о ресурсах сети с сенсоров, а затем анализировать, находить связи и строить карту активов: устройства, пользователи, программное обеспечение, приложения, данные и конфигурации. Причем карта активов инфраструктуры должна динамически перестраиваться при изменениях в сети, таких как появление новых узлов, изменение системных и сетевых конфигураций или вывод активов из эксплуатации. Кроме того, в менеджмент активов должны передаваться актуальные данные об уязвимостях из систем класса Vulnerability Management, поскольку уязвимости имеют большое влияние на возможные сценарии атак и должны отслеживаться в режиме реального времени. Например, такая интеграция информации об активах инфраструктуры (Asset Management), уязвимостях (Vulnerability Management) и контроле соответствия активов требованиям безопасности (Host Compliance Control) реализована в MaxPatrol SIEM и MaxPatrol VM, которые вместе позволяют собирать в единое хранилище данные со всех источников в адаптированном формате с возможностью построения запросов на языке PDQL.

Для построения карты активов используются графовые алгоритмы анализа данных, и это является по сути графовым представлением всех собранных сведений. При этом важно, чтобы все компоненты автономного SOC отрабатывали слаженно: оперативная доставка телеметрии от сенсоров к системам Asset Management, анализ данных, выявление связей и построение графов связей. Затем на динамическую карту активов можно накладывать сценарии атак. В перспективе появляется возможность автоматического блокирования запрещенных или опасных маршрутов на карте активов. Если на графовом представлении активов мы укажем наиболее критичные ресурсы, то сможем оценивать, насколько реализуемый злоумышленником сценарий атаки близок к реализации недопустимого события.

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

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

При таком подходе можно оценивать критичность цепочек атак в целом, а не отдельных инцидентов. Критериями оценки могут выступать близость злоумышленника к цели и количество маршрутов потенциальных атак, пролегающих через скомпрометированные узлы, — чем больше путей у злоумышленника для развития атаки, тем критичнее цепочка. Такой функционал, например, реализован в модуле Threat Modeling Engine (TME) в составе метапродукта MaxPatrol O2. Некоторые производители решений по безопасности для расчета оценки критичности цепочки атаки учитывают и другие критерии. Например, в платформе для облачной безопасности OrcaSecurity реализован механизм Business Impact Score (BIS), он оценивает следующие факторы: уровень критичности ресурса для бизнеса (Business Impact), критичность эксплуатируемой уязвимости или недостатка безопасности (Severity), уровень доступности точки проникновения в инфраструктуру (Accessibility), риск перемещения внутри сети с этой точки и сколько переходов остается для достижения конечной цели (Lateral Movement Risk), уровень предоставляемых прав доступа и привилегий (Access Level). Автономный SOC может в таком случае приоритизировать цепочки атак по критичности и предлагать релевантные сценарии реагирования на инциденты.

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

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

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

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

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

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

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

Вторым направлением является предоставление аналитикам SOC возможности самим писать новые правила детектирования в специальной консоли. В некоторых SIEM-системах нового поколения такие детекты пишутся с помощью Jupyter Notebook (например, в RunReveal и Cortex XSIAM) или на Python (например, в Panther или Matano), поддерживая при этом концепцию detection-as-a-code, то есть реализуя полноценный конвейер разработки правил обнаружения, включая их тестирование и проверку работоспособности.

Еще один вариант — использование готовой сторонней экспертизы. Можно обратиться к маркетплейсам и приобрести модули и коннекторы к различным средствам защиты, а также новый контент обнаружения, в том числе разработанный другими пользователями системы мониторинга событий безопасности (например, такое есть в MaxPatrol SIEM, Splunk, QRadar, LimaCharlie). Если квалификация аналитиков SOC позволяет, то можно использовать свободно распространяемый контент обнаружения в формате SIGMA. В публичном репозитории правил SIGMA содержится несколько тысяч правил, которые можно использовать в качестве контента обнаружения.

И наконец, будущее автономных SOC — автоматическое создание правил обнаружения за счет потенциальной способности ИИ к самообучению и интеграции нового опыта в экспертную базу. В какой-то момент появятся достаточно интеллектуальные системы, способные анализировать трафик и логи так, чтобы выявлять в них ранее неизвестные паттерны атак и добавлять на их основе новые тактики, техники и процедуры в те же матрицы ATT&CK и ATLAS.

В автономном SOC возникает потребность в новых инструментах для решения бизнес-ориентированных задач. Возможно, эти инструменты в будущем выделятся в новый класс средств для мониторинга ИБ, такие как Autonomous Security Operations Platform, Extended Security Intelligence and Automation Management, Automated Threat Actor Detection and Response, но на данный момент такого единого стандартизированного класса решений пока не сформировалось. В конечном итоге независимо от наименования важно наличие инструмента, способного на автоматическое обнаружение инцидентов, сбор и расследование полных цепочек атак, выявление из них критических и принятие мер по реагированию.

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

Немаловажную роль в SOC будущего будут играть большие языковые модели (LLMs) и генеративный ИИ (Generative AI). За счет доступа к огромным базам знаний и своей способности понимать запросы и давать ответ на человеческом языке генеративный ИИ может работать в режиме «второго пилота» (co-pilot) или даже полного автопилота. В число функций, решаемых за счет LLMs и GenAI, можно отнести анализ больших объемов данных от различных источников телеметрии и выявление ошибок в конфигурациях (например, Exabeam Threat Explainer), анализ и классификацию различных типов угроз и вредоносного ПО, предсказание потенциальных векторов кибератак (например, LogRhythm AI Engine), генерацию стратегий действий по реагированию на угрозы (например, Fortinet Advisor for FortiSIEM), прогнозирование возможных результатов и последствий принятых решений.

В SOC принято оперировать целым набором метрик. Эти метрики отражают время, за которое SOC способен выполнить полный цикл от обнаружения инцидента в инфраструктуре до устранения его последствий. Представим все известные нам метрики на временной шкале (рисунок 6).

В классическом SOC после срабатывания оповещения о подозрительном событии освободившийся аналитик через какое-то время берет это срабатывание в работу и начинает анализ, поэтому применяются такие метрики, как время до взятия алерта в работу из очереди (Queue Wait Time) и время до верификации, является ли срабатывание инцидентом (Time to Qualify). Если сработка указывала на реальный инцидент, то начинается его расследование (Time to Investigation). Теперь посмотрим, как меняется подход в автономном SOC. SOC нового поколения будет работать не с отдельными событиями ИБ, а с цепочками атак. Такой SOC сможет самостоятельно провести обогащение данных и ретроспективный анализ связанных событий ИБ. При таком подходе очередь атомарных событий ИБ, ожидающих внимания человека, уже не будет накапливаться, и тогда временные метрики Queue Wait Time, Time to Qualify, Time to Investigation максимально сократятся практически до стирания границ между срабатыванием оповещения и получением полной информации об инциденте.

Похожую аналогию можно провести с метриками TTC (Time To Contain) и TTE (Time to Eradicate). В традиционном SOC после верификации инцидента аналитик предпринимает действия по блокированию злоумышленника на том узле, где он был обнаружен. Затем проводит расследование, какие еще устройства в инфраструктуре, программные компоненты и учетные записи были скомпрометированы и могут использоваться для возобновления атаки. Создается сценарий реагирования и выполняется либо вручную, либо частично автоматизированно через XDR-решения. После этого можно говорить о полном устранении злоумышленника в инфраструктуре. Теперь посмотрим, как меняется подход в автономном SOC. NG SOC автоматизированно собирает всю цепочку атаки от конечной точки обнаружения инцидента до момента проникновения злоумышленника в сеть, затем формирует сценарий реагирования для всей цепочки атаки. В зависимости от встроенного уровня автоматизации SOC либо сразу запустит сценарий реагирования, либо будет ожидать верификации аналитиком. Получается, что метрики TTC и TTE также будут стремиться к смещению в одну точку на временной шкале.

В итоге классические метрики станут неприменимы для автономного SOC, и тогда будут необходимы другие способы оценки эффективности. В автономном SOC становится возможным в режиме реального времени отслеживать прогресс атаки (Time To Attack) и прогресс реагирования на угрозу (Time To Response). Вместо времени будет фактически учитываться количество шагов до реализации недопустимого события (подробнее об этом мы рассказывали в другом нашем исследовании). При сравнении метрик SOC сможет отслеживать, чтобы ни при каких обстоятельствах не нарушалось уравнение TTA >= TTR. Основным же критерием эффективности NG SOC в таком случае станет невозможность достижения злоумышленником недопустимого события, и проверять это можно, например, посредством регулярного проведения киберучений.

Говоря о технологиях автоматического обнаружения и реагирования на инциденты, неизбежно появляется вопрос, какова будет роль человека после внедрения автономного SOC?

Даже на самом высоком уровне автоматизации, когда SOC достигает полной автономности, участие человека все равно необходимо для выполнения ряда задач: контроля за системой, принятия решений в сложных ситуациях, запуска проверяющих тестов, определения актуальных угроз, проектирования дашбордов, внедрения и поддержки функционирования сенсоров. По аналогии с идеальным уровнем автопилота в автомобилях, где тем не менее участвует человек, контролирующий корректные реакции встроенных алгоритмов на препятствия, изменения дорожного ландшафта, погодных условий карты дорог и так далее. NG SOC, подобно автопилоту, должен уметь ориентироваться в новых обстоятельствах, когда появляются неизвестные ранее паттерны атак и вредоносные инструменты. На более ранних стадиях развития платформ для автономных операций безопасности перечень действий, в которые вовлекается аналитик, более широкий. На том же 4-м уровне автоматизации участие человека необходимо также для подтверждения обнаруженных критичных цепочек атак, верификации сценариев реагирования на инциденты и их выполнения. Кроме того, у команд по ИБ остается много задач, связанных с харденингом инфраструктуры, — сегментация устройств в сети, работа с правами доступа и привилегиями пользователей, устранение слабостей конфигураций ИТ-систем), поэтому освободившиеся ресурсы можно переключить на эти задачи.

Задачей автономного SOC является достижение результата, когда для хакера не остается возможности реализовать критичные риски для компании в условиях нехватки кадров на ИБ. Автономность не значит, что люди не нужны, их просто будет необходимо меньше. Новое поколение SOC необходимо для решения вопроса острого дефицита аналитиков SOC, задача не стоит в том, чтобы увольнять людей. С внедрением автономного SOC снизится необходимое количество человеко-часов на мониторинг и обработку инцидентов в сутки. Традиционно эта величина не относится к параметрам, на которые можно было бы влиять, — исходя из условий работы SOC (количество защищаемых активов, подключенных источников телеметрии, количество срабатываний в SIEM в сутки) производится расчет, сколько надо человеко-часов, и SOC пытается закрывать эту потребность в людях. С внедрением автономных SOC можно будет говорить о том, что для эффективного управления киберугрозами будет необходимо в разы меньше людей. На примере внедрения MaxPatrol O2 измерения показателей показывают повышение результативности SOC минимум в 30 раз.

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

Подведем итоги, какими ключевыми свойствами должен обладать центр мониторинга и реагирования на инциденты нового поколения?

Автоматизация на максимум

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

Адаптация к новым условиям игры

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

Аналитика данных и принятие решений

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

Автономность

Вобрав в себя все предыдущие свойства, NG SOC, по сути, стремится к достижению полной автономности процесса мониторинга ИБ и реагирования на инциденты. Если раньше разработчики инструментов для центра реагирования на инциденты руководствовались принципом «создать средства автоматизации в помощь аналитикам SOC» (Automation-Assisted Security Operations), то теперь подход сдвинулся в направление «создать автономную систему, решения которой проверит и скорректирует аналитик при необходимости» (Analyst-Assisted Security Operations). Это позволит центру реагирования без участия человека анализировать данные о событиях безопасности, определять инциденты, приоритизировать их и предлагать релевантные меры по реагированию.

Данные и выводы, представленные в этом отчете, основаны на собственной экспертизе Positive Technologies, а также анализе общедоступных ресурсов, включая публикации правительственных и международных организаций, научно-исследовательские работы и отраслевые доклады. Термины, которые мы используем в исследовании, приведены в глоссарии на сайте Positive Technologies.