SOC (Security Operations Center): что это, функции, модели

SOC (Security Operations Center, центр мониторинга информационной безопасности) — это команда специалистов и набор технологий, которые круглосуточно отслеживают, обнаруживают и расследуют киберугрозы в инфраструктуре организации и реагируют на инциденты. SOC объединяет людей, процессы и инструменты — SIEM, SOAR, TIP — в единую функцию непрерывного мониторинга, которая работает постоянно, а не разово, в отличие от аудита или разовой проверки защищённости.

Ключевое слово в расшифровке — «operations», операционная деятельность. SOC не проектирует архитектуру безопасности и не пишет политики с нуля — этим занимаются архитекторы ИБ и служба комплаенса. Его задача уже практическая: смотреть на поток событий из систем, которые уже развёрнуты в компании, и решать по каждому подозрительному сигналу — это шум или начало атаки, а если атака, то что с ней делать прямо сейчас.

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

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

Конкретные задачи, которые решает SOC:

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

SOC закрывает шесть смежных функций — мониторинг, обнаружение инцидентов, реагирование, threat hunting, threat intelligence и форензику, — которые вместе образуют цикл от первого сигнала до разбора причин произошедшего. Не каждая функция обязательно закрыта отдельным человеком: в небольшом SOC один аналитик может совмещать несколько ролей, в крупном — за каждой стоит отдельная команда.

Классическая структура SOC — трёхуровневая эскалация аналитиков (L1 → L2 → L3), дополненная отдельными ролями threat hunter и инцидент-менеджера: чем выше уровень, тем меньше по объёму, но сложнее по содержанию поток задач, которые до него доходят. В небольших командах уровни объединяются в одного-двух человек, в крупных SOC каждый уровень — отдельная группа со своими метриками.

↔ таблицу можно прокрутить вбок

Деление на уровни — общепринятая отраслевая практика, а не нормативное требование: конкретный состав ролей и их названия отличаются от компании к компании и зависят от размера SOC, отрасли и модели работы (раздел ниже).

Технологическое ядро SOC — четыре класса продуктов: SIEM для сбора и корреляции событий, SOAR/IRP для автоматизации реагирования, Threat Intelligence для контекста об угрозах и EDR/XDR для видимости на конечных точках, — которые вместе закрывают весь цикл от сигнала до реагирования. Ни один из классов не заменяет SOC целиком: это инструменты, которыми пользуется команда, а не сама команда.

Помимо этих четырёх классов, в стек SOC входят источники данных, которые сами по себе не являются «продуктом SOC», но питают его событиями: журналы сетевого оборудования и межсетевых экранов, средства анализа сетевого трафика, системы контроля привилегированного доступа. Их выбор и настройка — предмет отдельного проекта по каждому классу, а не часть определения SOC.

Функцию SOC можно реализовать тремя способами — собственным (in-house) центром, гибридной моделью или полным аутсорсом (SOC as a Service у MSSP), — и выбор между ними определяется не размером компании как таковым, а объёмом инфраструктуры для мониторинга и готовностью держать штат аналитиков в режиме 24/7.

Модели не исключают друг друга во времени: типичный путь роста — начать с SOC as a Service, чтобы закрыть базовый мониторинг без длительного найма, и постепенно наращивать собственную команду до гибридной или полностью in-house модели по мере роста инфраструктуры и зрелости процессов.

Термин «SOC» в российском законодательстве напрямую не используется, но функция, которую он описывает, прямо связана с двумя регуляторными контурами — взаимодействием с ГосСОПКА для субъектов КИИ по 187-ФЗ и управлением инцидентами защиты информации по ГОСТ Р 57580.1 для организаций, поднадзорных Банку России.

Для субъектов критической информационной инфраструктуры (КИИ) закон обязывает не «иметь SOC» дословно, а информировать о компьютерных инцидентах и содействовать ГосСОПКА — государственной системе обнаружения, предупреждения и ликвидации последствий компьютерных атак. На практике эту обязанность выполняет именно центр мониторинга: собственный, аккредитованный как корпоративный центр ГосСОПКА, ведомственный центр или коммерческий провайдер, работающий по соглашению с НКЦКИ.

SOC в этом контексте — не альтернатива ГосСОПКА, а операционная функция внутри организации, через которую она выполняет обязанность перед государственной системой.

Для банков и других организаций, поднадзорных Банку России, действует другая связка. ГОСТ Р 57580.1 включает управление инцидентами защиты информации в базовый состав организационных и технических мер, дифференцированный по уровням защиты. Стандарт задаёт, что процесс обнаружения и реагирования на инциденты должен существовать и соответствовать назначенному уровню — но не предписывает конкретную организационную форму: закрыть это требование можно и штатным SOC, и гибридной схемой, и внешним провайдером с нужным набором компетенций.

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

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