Гал Шафир о том, почему SOC 2030 года будет работать как команда разработчиков
- Гал Шафир считает, что SOC отказывается от модели единого SIEM: данные распределяются между конвейерами, хранилищами и движками обнаружения.
- По отчёту SANS SOC Report 2026, ИИ используют 79% SOC, но лишь 36% встроили его в чётко определённые рабочие процессы.
- Шафир предлагает управлять всем стеком SecOps как кодом; по его прогнозу, SOC 2030 года будут ставить цели, а инженеры — проверять и утверждать изменения систем.
Почему это важно: Шафир считает, что управление стеком как программным обеспечением позволит менять его так же быстро, как меняются бизнес и угрозы.
Два десятилетия SIEM и был центром мониторинга безопасности (SOC). Одна платформа принимала данные, разбирала их, хранила, нормализовала, обогащала, запускала правила обнаружения и обеспечивала расследования. Если у вас был SIEM, у вас был SOC.
Эта модель рушится. Гал Шафир, сооснователь и генеральный директор Fig Security, много лет занимался SIEM в Google SecOps. Сегодня он видит, что большинство крупных команд безопасности уже разбирают эту модель на части.
«Эпоха, в центре которой стоял SIEM, заканчивается, — говорит Шафир. — Команды разделяют стек на компоненты, каждый из которых хорошо делает что-то одно. Конвейеры отвечают за приём и фильтрацию данных. Один SIEM даёт бесплатный приём и отличный контент для определённых журналов, другой выполняет собственные, критически важные правила обнаружения. Рядом с ними находится озеро данных или объектное хранилище для хранения и поиска угроз, а поверх всего этого работают федеративные движки обнаружения. SIEM никуда не делся — это по-прежнему полноценный компонент. Просто он больше не является всем SOC».
Схема Fig Security, показывающая, как, по прогнозу компании, будет разделяться инструментарий операций безопасности. — Источник: Fig Security
Стек становится дешевле, лучше — и гораздо сложнее в проектировании
Преимущества реальны. Каждый компонент выполняет свою задачу эффективнее, данные попадают туда, где их дешевле всего хранить, а команды перестают переплачивать за обработку всего в одном месте.
Шафир сравнивает это с тем, что произошло с инфраструктурой приложений.
«Приложения перешли от архитектуры «клиент-сервер» к Kubernetes и микросервисам. Всё стало масштабируемее, эффективнее и дешевле. Но и гораздо фрагментированнее, и для управления этим возникла целая новая дисциплина. DevOps-инженеры смогли всё наладить, потому что получили инструменты: CI/CD, инфраструктуру как код, наблюдаемость. SecOps сейчас проходит через такое же разделение —, но без этих инструментов».
Каждый новый компонент добавляет конфигурации, схемы и зависимости, которые меняются по собственному графику. Одно правило обнаружения теперь зависит от источника, конвейера, парсера, схемы, сопоставления полей и самого правила, и всем этим часто владеют разные команды в разных продуктах. Каждый продукт описывает только свой участок. Ни один из них не показывает весь поток целиком.
ИИ повышает ставки. Агенты появляются по всему стеку: агенты-аналитики в SIEM, агенты для поиска угроз в озере данных, агенты красной команды, проверяющие телеметрию и конвейеры. Все они работают на одной и той же фрагментированной основе данных. Согласно отчёту SANS SOC Report 2026, 79% SOC используют инструменты ИИ или машинного обучения, но лишь 36% встроили их в чётко определённые рабочие процессы SOC.
«ИИ никогда не сомневается во входных данных, — говорит Шафир. — У вас могут быть лучшие агенты в мире, и они скажут, что всё в порядке, потому что оповещение, которое им следовало расследовать, так и не сработало. Где-то выше по потоку переименовали поле, правило ищет то, чего в данных больше нет, и никто об этом не знает».
Организации нанимают инженеров, а не новых аналитиков
Люди меняются так же быстро, как и стек. ИИ берёт на себя всё больше работы по сортировке и расследованию, которая раньше определяла SOC. Организации не переучивают аналитиков в инженеров, чтобы закрыть этот разрыв. Они отказываются от найма на аналитическую работу, которую теперь может выполнять ИИ, и нанимают инженеров, чтобы получать больше обнаружения и реагирования от инфраструктуры, которая становится всё сложнее.
Большинство команд находятся в начале этого перехода. В SOC Maturity Report 2026 от SOC-CMM — сравнительном исследовании примерно 200 SOC — говорится, что «в большинстве SOC по-прежнему больше аналитиков, чем инженеров». Тот же отчёт ожидает перемен: «По мере того как SOC движутся к более высокому уровню автоматизации — с ИИ и без него, — инженерия будет играть всё более важную роль в SOC будущего».
«Все, с кем мы общаемся, сейчас нанимают инженеров, — говорит Шафир. — Инженеров конвейеров, инженеров обнаружения, инженеров SIEM. Все они обслуживают единый поток, который должен обеспечивать обнаружение и реагирование, и проектировать этот поток с каждым кварталом всё сложнее».
Схема Fig Security, показывающая, какое место, по прогнозу компании, займут ИИ-агенты в стеке операций безопасности. — Источник: Fig Security
Четыре вида изменений — и все ускоряются
Шафир называет четыре фактора давления, из-за которых объём инженерной работы растёт с каждым годом:
- Угрозы развиваются быстрее. Злоумышленники тоже используют ИИ, поэтому окно между появлением новой техники и правилом, которое её обнаруживает, продолжает сокращаться.
- Настройка обходится дороже. Когда ИИ обрабатывает каждое оповещение, «шумное» или сломанное правило — это уже не просто усталость аналитиков. «Обработка мусора всегда стоила вам времени аналитиков, — говорит Шафир. — Теперь она стоит вам ещё и расходов на ИИ».
- Бизнес меняется быстрее. Команды по всей компании выпускают внутренние приложения, многие из которых написаны методом вайб-кодинга, и каждое из них нужно мониторить.
- Данные меняются быстрее. Вендоры обновляют форматы журналов, подключаются новые источники, конвейеры перестраиваются ради экономии. Каждое изменение может незаметно сломать правила обнаружения ниже по потоку, пока SOC по-прежнему считает, что защищён, — так возникает дрейф (Drift).
«Команды застряли между двумя плохими вариантами, — говорит Шафир. — Двигаться медленно, чтобы ничего не сломать, или двигаться быстро и рисковать пробелами, которые никто не найдёт до инцидента. Ни один из них не поспевает за скоростью изменений».
SecOps как код — единственный способ масштабироваться
Ответ Шафира — управлять операциями безопасности так же, как DevOps управляет облачной инфраструктурой.
Обнаружение как код (Detection as Code, DaC) было правильным первым шагом, считает он, но оно охватывает лишь последнее звено цепочки.
«Размещение правил в GitHub защищает то звено, которое само по себе ломается редко. Дрейф происходит выше по потоку. SecOps как код означает, что каждый уровень — от источников и конвейеров до парсеров и правил обнаружения — определяется, версионируется, тестируется, развёртывается и откатывается как единая система. Terraform версионировал не один сервер. Он версионировал всю среду».
В SecOps есть особенность, с которой команды разработчиков не сталкиваются.
«В разработке ПО входные данные принадлежат вам, — говорит Шафир. — В SecOps входные данные — это журналы, которыми владеет кто-то другой, и они могут измениться без предупреждения. Поэтому тестирование должно означать доказательство того, что правило по-прежнему срабатывает на данных в их сегодняшнем виде».
В результате получается команда совсем другого типа.
«SOC превращается в команду разработчиков, — говорит Шафир. — От инженеров SecOps потребовали перенять DevOps-мышление, так и не дав им DevOps-инструментов. Именно этот разрыв нам нужно закрыть».
Без контроля над всем стеком ничего не работает
Всё это невозможно без полного контроля и прозрачности каждой части стека. Именно этот уровень и создаёт Fig.
Fig подключается к любой инфраструктуре SecOps через API с доступом только на чтение и отображает каждый поток данных, обнаружения и реагирования — от каждого источника через конвейеры и парсеры до зависящих от него правил и рабочих процессов — во всех SIEM, конвейерах и озёрах данных. Построение карты детерминировано, без участия ИИ, поэтому карта отражает истинное положение дел. Инженеры строят свою работу на её основе. Они проектируют изменения с полным контекстом собственной среды, тестируют каждое изменение до выхода в продакшн через CI/CD с контролем версий и откатом и постоянно проверяют, что развёрнутое вчера по-прежнему работает сегодня. Та же карта даёт ИИ точную картину среды, без которой ему нельзя доверять.
«Нам всё равно, чей логотип на коробке, — говорит Шафир. — Создайте сами или купите, замените в следующем году — неважно. У инженеров должно быть одно место для управления всем стеком. Их задача — проектировать результаты в сфере безопасности, а не вручную менять конфигурации в десятке инструментов от десятка вендоров. Именно это мы имеем в виду, называя себя операционной системой для SecOps».
Каким будет SOC 2030 года
В SOC 2030 года компонентов не станет меньше. Их станет больше: больше конвейеров, больше уровней хранения, больше движков обнаружения и агентов, созданных или купленных почти для каждого уровня. Не изменится, по словам Шафира, одно: весь стек будет вести инженер-человек.
Сама работа поднимется на уровень выше. Команды будут ставить цели по покрытию, затратам и реагированию, а системы — предлагать изменения для их достижения, например перенаправление данных в более дешёвое хранилище или новые правила обнаружения на основе уже собираемых командой данных, причём каждое изменение будет заранее протестировано. Инженеры проверяют и утверждают, и каждое изменение — от человека или агента — проходит одни и те же проверки.
«Инженеры должны заниматься безопасностью, а не битами и байтами, обеспечивающими работу инфраструктуры, — говорит Шафир. — В 2030 году победят не те SOC, у которых больше всего инструментов или агентов. Победят те, кто управляет своим стеком как ПО и может менять его так же быстро, как меняются бизнес и угрозы».
Источник: SOC-CMM®, SOC Maturity Report 2026 (май 2026 г.), распространяется по лицензии CC BY-SA 4.0.
Полный текст статьи читайте на TheNextWeb.ru
