Автономный SOC — это закономерный этап развития безопасности, обещающий переход от ручного труда к предиктивной, самообучающейся защите. Однако путь к этой автономии сопряжён не только с технологическими прорывами, но и с комплексными рисками. Готова ли современная ИБ к полному доверию алгоритмам?
- Введение
- Что такое автономный SOC?
- Модели построения автономного SOC
- Какие задачи вы поручаете ML?
- Что является ядром автономного SOC?
- Как обеспечить качество датасета?
- Кто несёт ответственность за действия автономного SOC?
- Прогнозы экспертов
- Выводы
Введение
Эволюция центров управления безопасностью (SOC) вступает в новую фазу, ознаменованную переходом от человеко-ориентированных процессов к машинно-управляемым операциям. Автономный SOC — это не просто очередной инструмент в арсенале защитников, а фундаментально новая архитектура, построенная на триединстве больших данных, машинного обучения и автоматизации.
Если традиционный SOC полагается на скорость и экспертизу человека, то автономный стремится к непрерывному, масштабируемому и прогнозирующему реагированию. Эксперты попытались разобраться, как устроена эта система изнутри, какие технологические компоненты служат её ядром, и с какими вызовами — от «слепоты» алгоритмов до этических дилемм — сталкиваются компании на пути к её внедрению.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Теймур Хеирхабаров, директор департамента мониторинга, реагирования и исследования киберугроз, BI.ZONE.
- Алексей Леднёв, руководитель продуктовой экспертизы PT ESC, Positive Technologies.
- Александр Кузнецов, руководитель группы архитектуры Solar JSOC, ГК «Солар».
- Николай Гончаров, директор департамента мониторинга кибербезопасности, Security Vision.
- Демид Балашов, руководитель по развитию продуктов кибербезопасности, «МегаФон ПроБизнес».
- Владимир Зуев, технический директор центра мониторинга и реагирования на кибератаки RED Security SOC, RED Security.
- Юрий Наместников, руководитель Security Operations, Yandex Cloud.
Ведущий и модератор эфира — Алексей Лукацкий, Chief Evangelist Officer, Positive Technologies.
Что такое автономный SOC?
Алексей Лукацкий рассказал, что в 2005 году, когда в России принимали законы о персональных данных, некорректно перевели термин «autonomous» как автоматизированный. Это повлекло за собой много проблем в рамках законодательства о персональных данных. Сейчас, говоря об автономных SOC, многие считают, что это SOC с большим количеством автоматизации. Где проходит та грань между автономным и глубоко автоматизированным SOC?
Алексей Лукацкий, Chief Evangelist Officer, Positive Technologies
Александр Кузнецов объяснил, что автономность исключает участие человека практически во всех процессах. В любом процессе SOC можно выделить два шага: принять решение и реализовать его. Реализация может быть полностью автоматизированной. Ключевой признак автономности — передача функций по принятию решений и их исполнению от человека к системе.
Демид Балашов добавил, что идеально, когда участие человека сведено к нулю — с момента запуска и неограниченное количество циклов. Можно рассматривать три уровня: операционный, качественный, эволюционный.
Теймур Хеирхабаров напомнил, что мониторинг и реагирование — это только часть процессов SOC. Например, есть разработка контента. Сейчас уже можно решать эту задачу, когда модели даётся описание угрозы, по которому она выдаёт правило корреляции. В автономном SOC рассматривается в том числе автоматизация этого процесса. В качестве критерия автономности можно учитывать долю правил, которые были созданы полностью автоматически без участия аналитика и дают приемлемое качество обнаружения.
Есть ещё взаимодействие с заказчиками, общение в комментариях — здесь тоже можно автоматизировать обработку сообщений и ответы на обращения. Любые процессы SOC можно автоматизировать. Одна из основных метрик автономности — объём реализуемых полностью автоматических действий без участия человека. Важно в этих действиях учитывать процент ошибки.
Чего нельзя доверить машине? Автономность не предполагает полную изоляцию от человека. Он остаётся в роли контролирующего звена. Остаются задачи, в которых автоматизация не работает — там, где требуется творческое мышление и интуиция (реагирование и расследование крупномасштабных инцидентов), коммуникации и кризисное управление, понимание контекста. Любой SOC начинается с подключения источников. ИИ сам не проведёт инвентаризацию инфраструктуры, не определит, какие системы нужно подключать, — здесь необходимо участие человека.
Теймур Хеирхабаров, директор департамента мониторинга, реагирования и исследования киберугроз, BI.ZONE
Может ли SOAR (Security Orchestration, Automation and Response — система оркестрации, автоматизации и реагирования на инциденты безопасности) сделать SOC автономным? Николай Гончаров считает, что SOAR — базовая технология, которая позволяет вести автоматизацию и приблизить работу SOC к автономности. Но внедрение конкретного решения не даст такого результата, это комплексная задача. Нужен специалист, способный грамотно внедрить эти процессы и настроить автоматизацию, обеспечивающую автономность. Полностью исключить человека из работы SOC нельзя в ближайшем времени, роль стратегического планирования и управления остаётся за человеком.
Владимир Зуев предлагает исходить из того, какие действия можно отдать ИИ. Это могут быть рутинные задачи, например, писать корреляционные правила. ИИ можно включить в подготовку отчётности. Он исключён из процесса принятия решений, но за счёт управления большим объёмом данных способен находить отклонения, которые человек может пропустить.
В первом опросе зрители поделились, на каком уровне автономности сейчас находится их SOC:
- Частичная автоматизация (отдельные скрипты, SOAR-сценарии) — 41 %.
- Нет SOC, но тема интересна — 27 %.
- Работают полностью вручную, автоматизации почти нет — 17 %.
- SOC самостоятельно расследует и реагирует без участия аналитика большую часть типовых инцидентов — 11 %.
- Большинство инцидентов закрываются автоматически, но решения утверждает человек — 4 %.
Рисунок 2. Где сейчас находится ваш SOC по уровню автономности?
Модели построения автономного SOC
Александр Кузнецов привёл пример зарубежной классификации, которая больше подходит для западных производителей и пока слабо развита на российском рынке.
Первый подход: в основе используется существующий в организации SIEM, к нему облачно или по схеме SaaS подключается AI-платформа, которая анализирует данные, забирает определённые сработки или подозрения на инциденты и возвращает. Данные есть в сыром и нормализованном виде, можно делать срезы и формировать датасеты, чтобы дальше с ними работать. Вторая модель — полноценные AI-платформы. Третья — эмуляция действий аналитиков, фактически наблюдение за тем, как человек осуществляет расследование, реагирование.
Что компания может применять внутри инфраструктуры? Поверх SIEM забирать данные и работать с ними. Для провайдеров такой вариант тоже, скорее всего, подойдёт, так как они могут подключать свою облачную платформу по такой схеме. Если есть возможность строиться с нуля или серьёзно модернизировать свои SOC, стоит внедрять AI-платформы.
Александр Кузнецов, руководитель группы архитектуры Solar JSOC, ГК «Солар»
Алексей Леднёв добавил, что SIEM изначально задумывался для хранения и обработки данных, нецелесообразно от него отказываться в SOC. Но когда его создавали, не было такого количества данных. Сейчас переходят к модели, когда строят Data Lake, а SIEM используют больше для обнаружения (корреляционная логика, ИИ). Про эмуляцию аналитика можно сказать, что это, по сути, AI-агенты, которые дают уйти от чётких алгоритмов к вариативности выбора.
Какие задачи вы поручаете ML?
Теймур Хеирхабаров объяснил, что классическое машинное обучение — это классификация, поиск закономерностей в большом объёме структурированных данных, поиск выбросов, выявление аномалий. ML оперирует статистикой и требует предварительного обучения на огромном объёме данных. Его задачи — найти аномалию, классифицировать объекты, но не принимать решения.
Задачи генеративного ИИ — объяснение, дополнение контекстом, рассуждения и принятие решения на их основе. Это не только ассистенты. AI-агент может использоваться как объект, который решает задачу на основании рассуждений. При этом ML и GenAI друг друга не исключают, они должны работать в связке.
Алексей Леднёв добавил, что LLM — отличная технология, но она пока не даёт большой скорости. Это значит, что предварительная работа ML важна, особенно в части детектирования. Нужно всё использовать по назначению и не пытаться все задачи решить с помощью LLM. ML используем для детектирования и улучшения его качества, а LLM помогает в принятии решений.
Алексей Леднёв, руководитель продуктовой экспертизы PT ESC, Positive Technologies
Николай Гончаров: «Мы используем ИИ как наставника для нового сотрудника, который помогает адаптироваться, понять, что было в инциденте: анализ больших данных, ложноположительных срабатываний, поиск сложных инцидентов, выдача рекомендаций и ответов на основе успешного опыта коллег, зафиксированного в истории инцидентов».
Владимир Зуев использует ML для конвертации корреляционных правил: поскольку приходится работать с несколькими вендорами SIEM, нужно проверять и тестировать, насколько корректно модель может переписывать правила из одного синтаксиса в другой, сохраняя при этом логику, которая используется в управлении корреляционной базой.
Юрий Наместников считает, что ИИ помогает ускорить процесс принятия решений, а также в общении с заказчиками. Это экономит время аналитикам, разработчикам. ИИ-агент помогает SOC работой с TI (Threat Intelligence, данные о киберугрозах). Применяя LLM, внутри нужно отдавать возможность аналитикам автоматизировать свою работу, потому что именно они хорошо знают, какие процессы как работают, какие из них наиболее рутинные. LLM неплохо умеет анализировать доступы, определять критичные или некритичные сущности. В каждой задаче модели могут давать разные результаты.
Алексей Лукацкий озвучил вопрос из чата: приведите конкретный пример, как LLM используется для закрытия подозрений (конкретный промпт).
Алексей Леднёв: «Привести конкретный промпт нельзя, так как это комплексные и динамичные инструкции. Если говорить упрощённо, мы применяем следующий сценарий для закрытия ложных инцидентов: система агрегирует всю доступную информацию по событию, формирует обогащённый контекст и передаёт его языковой модели для итоговой оценки легитимности активности».
Во втором опросе зрители отвели, что сегодня важнее для их SOC? (мультивыбор):
- Сократить время реагирования (MTTR) — 35 %.
- Сохранить контроль и прозрачность решений — 35 %.
- Уменьшить количество ложных срабатываний — 32 %.
- Повысить точность детектов за счёт ML — 32 %.
- Снизить нагрузку на аналитиков — 23 %.
Рисунок 3. Что сегодня важнее для вашего SOC? (мультивыбор)
Что является ядром автономного SOC?
Владимир Зуев считает, что в первую очередь стоит смотреть на инструменты оркестрации (SOAR), если нужна автономность в части интерпретации и обработки событий. Они сейчас используются не только как инструмент обеспечения жизненного цикла самих подозрений на инциденты. Бывают случаи, когда их применяют в качестве репозитория корреляционного контента, библиотеки индикаторов и дополнительных знаний по проактивному поиску угроз.
Владимир Зуев, технический директор центра мониторинга и реагирования на кибератаки RED Security SOC, RED Security
Демид Балашов уверен, что автономность — это эволюционный путь, не требующий коренной перестройки SOC. Она органично вырастает из существующего инструментария, используя уже накопленные данные и отработанные процедуры реагирования.
Николай Гончаров считает, что SOAR является ядром — руками и нервной системой, которая может дотянуться до любого решения и обеспечивает их взаимодействие. SOAR — это некое центральное звено, но все технологии должны присутствовать в платформе. Сейчас происходит слияние этих решений в единую технологическую систему с возможностью применения той или иной технологии.
Александр Кузнецов не поддержал коллег. По своему опыту он видит, что в SOAR не всегда бывает всё хорошо с точки зрения данных — как в инхаус, так и у провайдеров. В качестве ядра Александр предложил единую подсистему хранения — данные нужны, чтобы создавать модели и с ними работать, их значимость становится первостепенной при построении автономности. Инструментарий напрямую зависит от того, какие задачи возлагаются на SOC — обнаружение, реагирование, оценка анализа защищённости, — но везде в основе будут данные.
Юрий Наместников подчеркнул, что чем больше AI-система имеет различных слоёв безопасности, тем лучше она работает. Когда требуется добиться автономности SOC, чтобы рутину делала машина, не нужно ограничиваться главными компонентами, нужно строить многослойную защиту.
Юрий Наместников, руководитель Security Operations, Yandex Cloud
Алексей Леднёв поддержал: для безопасности нужны данные во всех аспектах. Есть различные сенсоры, системы — эти данные нужно где-то хранить, анализировать, особенно если говорить про поведенческую аналитику с использованием ИИ. Чем больше данных, тем выше шанс успеха, поэтому всё работает вокруг ядра с данными.
Теймур Хеирхабаров считает, что нельзя назвать ни SIEM, ни SOAR ядром SOC. Это единая экосистема обработки данных и оркестрации реагирования, если смотреть с точки зрения функций. Первостепенную роль какому-то одному компоненту отдавать нельзя.
В третьем опросе выяснилось, какой компонент, по мнению зрителей, станет ядром автономного SOC:
- SIEM со встроенным ML — 22 %.
- Единая data-платформа и Threat Intelligence — 22 %.
- UEBA / поведенческая аналитика — 21 %.
- SOAR как оркестратор действий — 18 %.
- LLM / GenAI-агенты — 17 %.
Рисунок 4. Какой компонент, по-вашему, станет ядром автономного SOC?
Как обеспечить качество датасета?
Николай Гончаров призывает постоянно обновлять свою систему и получать новые обновления от производителя. В любом случае данные нужно обогащать. Это можно делать собственной экспертизой, когда есть команда, которая позволит постоянно поддерживать датасет в актуальном состоянии.
У каждого клиента, кто использует ИИ-модель, она становится уникальной. Её можно дообогатить некоторыми данными, которые используются в TI-платформах. Если процесс обогащения внутри компании не выстроен, то нужно идти за обогащением к вендору. Параллельно в процессе использования модель дообучается на данных компании. Задача вендора — качественно выполнить обновление, чтобы не потерять уже накопленные с опытом данные и добавить к ним новые.
Николай Гончаров, директор департамента мониторинга кибербезопасности, Security Vision
Александр Кузнецов предупредил: если вы получаете модель, обученную на сторонних данных, это проблема. Дальше её нужно либо дообучать на своих данных, но тогда вы лишаетесь возможности получить новую модель от производителя, либо потребуется ведение двух веток разработки — собственной и вендорской, — что создаст огромную операционную нагрузку. Бывает, даже внутри не хватает данных, чтобы создавать или дообучать модели. В настоящий момент поможет только ручная верификация данных для подготовки выверенных датасетов, чтобы на них учить и создавать модели.
Кто несёт ответственность за действия автономного SOC?
Николай Гончаров напомнил, какие функции невозможно отдать автономному SOC — функции критичности прогнозирования и управления всей системой SOC. В каждом SOC должен быть ответственный человек, который отдал право принятия решения системе. Если он видит, что автономная система делает что-то не так или решение пошло не по тому пути, нужно перехватить управление на себя.
По мнению Демида Балашова, автономный SOC не существует в вакууме. Его действия, особенно в контуре критической инфраструктуры (КИИ), всегда ограничены внешними регуляторными и управленческими системами. Любое решение, несущее потенциальные риски, подпадает под внешний контроль, что изначально исключает возможность полной, стопроцентной автономности.
Демид Балашов, руководитель по развитию продуктов кибербезопасности, МегаФон ПроБизнес
Александр Кузнецов заметил, что когда руководитель делегирует какую-то задачу, он передаёт функции, полномочия, но не ответственность. Он рассказал, как это решается в компании «Солар»: при переходе в полностью автоматический режим работы некоторых систем вводится понятие цифрового мандата. Есть ответственное лицо, которое этот мандат даёт системе. В данном случае этот человек будет нести ответственность за действия, которые раньше должен был выполнять он, а теперь делает за него машина. Ответственность с человека не исчезает.
Теймур Хеирхабаров считает, что ответственность должен нести не аналитик, а руководитель или CISO, который принял решение купить и использовать автономную систему. Если говорить про средство защиты с точки зрения детекта, то должен отвечать вендор. Сам пользователь не может влиять на детект, но может менять настройки, поэтому получается коллективная ответственность, но за качество самих правил отвечает вендор.
В четвёртом опросе зрители поделились, что им мешает доверять ИИ в SOC? (мультивыбор):
- Недостаток качественных данных для обучения — 84 %.
- Недостаток прозрачности решений — 62 %.
- Риск ложного блокирования бизнес-сервисов — 47 %.
- Отсутствие доверия у команды — 46 %.
- Требования регуляторов и комплаенса — 23 %.
Рисунок 5. Что мешает доверять ИИ в SOC? (мультивыбор)
Прогнозы экспертов
Теймур Хеирхабаров: «Рынок уменьшится, объём заказчиков, использующих коммерческие SOC, снизится. Это позволит частично компенсировать недостаток кадров и квалифицированных людей. Коммерческие SOC перестроятся, они станут оркестраторами платформ автономных SOC заказчиков, будут заниматься расследованием и реагированием, доведением точности платформ до определённого уровня ложных срабатываний. В России для этого потребуется до 10 лет».
Алексей Леднёв: «Качественный инхаус-SOC, который покрывает все области — редкость, так как это долго и дорого, нужны специалисты, железо. Если говорить о прогнозировании использования полностью автономного SOC, потребуется более 10 лет, когда человек станет совсем не нужен».
Александр Кузнецов: «Для MSSP и MDR это хороший буст. За счёт оптимизации они могут расширить спектр своих услуг на большее число компаний. Сейчас их услуги потребляют средние компании или некоторые крупные, не создавшие свой SOC. С автоматизированными услугами он может зайти в любой рынок. Будет актуален вопрос, зачем иметь свой SOC, если эту услугу можно достаточно дёшево купить. В инхаус это будет оставаться только в очень крупных высокотехнологичных компаниях. Есть ряд задач SOC, которые нужно переводить в автономный режим».
Николай Гончаров: «Через 2–3 года можно будет наблюдать активное внедрение автономного SOC. Кардинальные изменения можно будет увидеть к 2030 году в области применения ИИ в SOC. Сейчас есть паттерн, который мешает внутренне осознать возможность передачи управления — факт доверия. Это кардинальное изменение произойдёт у нового поколения людей».
Демид Балашов: «Автоматизация не ведёт к исчезновению специалистов, а меняет их роль в рамках сервисной цепочки. Для провайдеров MSSP (Managed Security Service Provider, «безопасность как сервис» — прим. ред.) это шанс преодолеть ограничения, связанные с необходимостью участия человека в каждом процессе. Автономность позволяет трансформировать услугу в стандартизированный продукт, что резко повышает её масштабируемость без пропорционального роста затрат. Это открывает возможности для выхода на новые сегменты клиентов и снижения порога входа, одновременно развивая саму услугу. Даже частичная автоматизация и сокращение ручного труда способны дать мощный импульс для развития SOC в целом».
Владимир Зуев: «Драйвером этого процесса будут либо крупные вендоры, либо MSSP-провайдеры. Здесь нужно для себя определить, что мы говорим о появлении автономного SOC — это будет MVP (Minimum Viable Product, ранняя версия продукта с ограниченным набором функций — прим. ред.), который запустится у конкретного провайдера, или это станет коммодити (стандартизированные решения со сходными характеристиками — прим. ред.), которые можно тиражировать на рынок, что поменяет всю парадигму мониторинга и реагирования. Это эволюционный процесс, ему нет смысла препятствовать. Нужен только грамотный подход к нему сейчас».
Юрий Наместников: «Ключевым моментом в развитии автономного SOC являются данные. MSSP-провайдер как раз имеет необходимость создания качественных AI и ML-систем. Произойдёт качественный сдвиг, MSSP-провайдер будет двигателем прогресса, такие системы будут появляться и активно внедряться у заказчиков. Всё будет зависеть от того, как развиваются технологии. Через 1–2 года часть компаний автоматизируют 90 % рутинных задач. Для компаний, использующих формат On-Premise (использование собственной инфраструктуры и ресурсов для размещения ПО — прим. ред.), этот процесс затянется».
Финальный опрос показал, как изменилось мнение зрителей об Autonomous SOC после эфира: убедились, что это необходимая эволюция — 37 %, уже движутся в этом направлении — 22 %, планируют начать тестирование в 2026 году — 12 %, пока сомневаются в реализуемости — 12 %.
Рисунок 6. Как изменилось ваше мнение об Autonomous SOC после эфира?
Выводы
Развитие автономного SOC рисует картину закономерной и сложной эволюции в области кибербезопасности. Становится ясно, что путь к автономности — это не гонка за полным исключением человека, а стратегическая перестройка ролей и процессов. Человек не исчезает из контура управления, но переходит от рутинного оперативного вмешательства к роли архитектора, контролёра и стратега, несущего ответственность за действия доверенных ему систем.
Ключевым выводом является то, что технология — не панацея, а инструмент, эффективность которого целиком зависит от фундамента. Этим фундаментом выступают данные. Без качественных, релевантных и постоянно обновляемых датасетов ни машинное обучение, ни генеративный ИИ не смогут выйти за рамки экспериментальных проектов. Для построения будущего, где решения принимают алгоритмы, как никогда важна человеческая экспертиза — для подготовки данных, валидации результатов и тонкой настройки моделей.
Прогнозы экспертов сходятся в одном: автономность станет драйвером доступности и масштабируемости сервисов безопасности. Это может кардинально изменить рынок, позволив MSSP-провайдерам предлагать высококлассные услуги мониторинга и реагирования более широкому кругу компаний, делая кибербезопасность не роскошью для избранных, а стандартом для всех.
Однако главный барьер на этом пути — не технологический, а психологический и организационный. Вопрос доверия к «чёрному ящику», риски ложных срабатываний и предписания регуляторов требуют прозрачности и объяснимости решений, которые ИИ пока не может гарантировать в полной мере. Таким образом, автономный SOC — это не конечная точка, а непрерывный путь, где баланс между доверием к алгоритмам и человеческим контролем будет определяющим фактором успеха на долгие годы.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
