Купить SIEM и получить SOC не получится. Центр мониторинга ИБ требует карты критичных активов и угроз, качественной телеметрии, сценариев, которые помогают обнаруживать угрозы, аналитиков, регламентов и полномочий, чтобы реагировать на инциденты. Без такой связки SIEM превращается в дорогой склад журналов и очередь тревог.
Логика внедрения проста: активы и угрозы, источники событий, SIEM, контроль конечных устройств и сети, сценарии обнаружения, команда, реагирование, автоматизация и только затем 24/7. ГОСТ Р 59547-2021 описывает мониторинг ИБ, но не регулирует, как реагировать на инциденты. Как управлять инцидентами, разъясняет серия ГОСТ Р 59709–59712-2022.
Архитектура SOC: от активов до реагирования
Первый слой SOC составляют активы. Компания должна знать критичные серверы, рабочие станции, учетные записи, облачные ресурсы и бизнес-системы. Для каждого актива определяют владельца, критичность и основные угрозы. Иначе SOC одинаково внимательно следит за тестовым сервером и системой, которая парализует бизнес, если её остановить.
Следом подключают источники событий. В SIEM обычно передают журналы аутентификации, каталогов пользователей, межсетевых экранов, удаленного доступа, серверов, облачных сервисов, почты, EDR и ключевых приложений. Собирать все подряд невыгодно. Каждый поток должен либо участвовать в сценарии, который помогает обнаруживать угрозы, либо помогать расследовать инцидент.
Прежде чем закупать SIEM, стоит измерить поток событий. Часто используют EPS, то есть число событий в секунду, хотя поставщик может учитывать также объем данных за сутки или другие параметры. Например, коммерческая версия RuSIEM лицензируется по EPS. В документации MaxPatrol SIEM производительность конфигураций также привязана к потоку событий. Конкретный минимальный тариф лучше запрашивать у поставщика под собственную нагрузку, а не переносить цифру из чужого проекта.
SIEM дополняют EDR, который контролирует конечные устройства, и NDR, который анализирует сеть. Дополнительные данные дают почтовая защита, средства, которые контролируют уязвимости, и облачная инфраструктура. Набор средств выбирают под реальные угрозы, а не ради количества продуктов.
После того как источники подключены, создают сценарии, которые помогают обнаруживать угрозы. Лучше качественно отработать несколько десятков опасных ситуаций, чем загрузить сотни правил и получить поток ложных тревог. Приоритеты обычно включают компрометацию привилегированных учетных записей, необычные входы, подозрительные процессы, перемещение между узлами и крупную передачу данных.
Каждый сценарий должен заканчиваться понятным действием. Аналитик должен знать, как проверить тревогу, когда эскалировать случай и кто вправе заблокировать учетную запись или изолировать компьютер. SOAR подключают после того, как отладят ручной процесс, иначе автоматизация лишь ускорит ошибку.
Зрелость SOC лучше оценивать по результату. Полезны среднее время обнаружения MTTD, среднее время реагирования MTTR, доля ложных срабатываний FPR и нагрузка на аналитика. Рост числа журналов и правил сам по себе не говорит о росте качества.
Сколько людей действительно нужно для SOC 24/7 и сколько он стоит
Один круглосуточный пост требует 168 часов работы в неделю. При 40-часовой неделе математический минимум составляет 4,2 штатной единицы. В расчет не входят отпуска, болезни, обучение, увольнения и передача смен. Поэтому для одного постоянно занятого места L1 разумно планировать 5–6 аналитиков.
| Роль | Состав | Комментарий |
|---|---|---|
| L1 | 5–6 человек | Один пост 24/7 с резервом |
| L2 | 2–5 человек | 2–3 при редких ночных эскалациях, 4–5 для устойчивой ротации |
| Инженер SIEM | 1–2 человека | Источники, правила, производительность, хранение |
| Руководитель SOC | 1 человек | Приоритеты, процессы и показатели |
Два или три специалиста L2 подходят только при редких ночных вызовах, когда L1 самостоятельно закрывает основную массу событий. Если ночью регулярно приходится расследовать сложные случаи, второй линии не хватит для полноценной ротации. Тогда нужны 4–5 специалистов или общая дежурная группа с командой, которая реагирует на инциденты.
ГОСТ Р 59547-2021 допускает совмещать функции, но это не отменяет сменную арифметику. Инженер SIEM может помогать со сценариями, а руководитель участвовать в расследованиях, однако один человек не закроет несколько круглосуточных постов. Резерв нужен и потому, что первая линия выгорает.
| Модель | Ориентир на первый год | Основные расходы |
|---|---|---|
| Пилотный SOC 8/5 | 8–20 млн рублей | SIEM, ограниченный набор источников, небольшая команда |
| Гибридный SOC | 15–35 млн рублей | Внешний L1 24/7, внутренняя L2, лицензии и интеграции |
| Собственный SOC 24/7 | 35–70 млн рублей | Штат, SIEM, инфраструктура, EDR/NDR, поддержка |
| Крупный распределенный SOC | 70–100 млн рублей и выше | Большой поток событий, несколько постов, резервирование |
Диапазоны являются расчетным ориентиром редакции, а не статистикой рынка. Для конкретной компании бюджет лучше считать снизу вверх: измерить EPS и объем хранения, определить число конечных устройств и сетевых сегментов, запросить цены лицензий, затем добавить инфраструктуру, внедрение, поддержку, обучение и фонд оплаты труда.
Регуляторику проверяют, прежде чем проектировать SOC. Для значимых объектов КИИ действует контур ГосСОПКА. Приказ ФСБ № 547 действует с 30 января 2026 года и заменил приказ № 282 от 2019 года. Приказ № 548 регулирует, как соответствующие субъекты непрерывно взаимодействуют с ГосСОПКА.
Для государственных информационных систем действует другая база. С 1 марта 2026 года приказ ФСТЭК № 117 заменил приказ № 17, а с 1 сентября 2026 года вступают в силу изменения по приказу № 137. Приказ № 21 относится к информационным системам персональных данных. Поэтому архитектуру SOC сверяют с типом системы и применимыми требованиями.
Практичнее начинать с пилота. Подключите критичные источники, запустите приоритетные сценарии, проверьте качество журналов, измерьте ложные тревоги и отработайте действия команды. После того как процессы стабилизируются, можно расширять источники, увеличивать штат, добавлять автоматизацию и переходить на 24/7.
Вопросы и ответы
Можно ли построить SOC без SIEM?
Небольшая компания может начать с EDR, журналов серверов и сетевых средств. По мере роста инфраструктуры SIEM обычно становится центральным элементом, но не заменяет команду и процессы.
Сколько сотрудников нужно для одного поста SOC 24/7?
Математический минимум составляет 4,2 ставки, но для отпусков, болезней, обучения и текучести практичнее планировать 5–6 сотрудников L1.
С чего начинать создание SOC?
Начинать лучше с инвентаризации критичных активов и определения основных угроз. После этого выбирают источники событий, которые помогут обнаруживать такие угрозы, и только затем проектируют SIEM, сценарии мониторинга и процессы реагирования.
Чем SIEM отличается от SOC?
SIEM представляет собой технологическую платформу для сбора, хранения и анализа событий. SOC включает SIEM, другие средства защиты, аналитиков, сценарии обнаружения, регламенты, процессы расследования и реагирования. Покупка SIEM сама по себе не создает SOC.
Зачем SOC нужны EDR и NDR, если уже есть SIEM?
SIEM анализирует полученные события, но сама не создает всю необходимую телеметрию. EDR дает подробные данные о действиях на рабочих станциях и серверах, а NDR помогает видеть подозрительную сетевую активность. Вместе такие средства сокращают слепые зоны при расследовании.
Что такое EPS и почему показатель влияет на стоимость SOC?
EPS показывает, сколько событий инфраструктура передает в SIEM за секунду. От потока событий зависят требования к производительности, хранению данных и, у некоторых поставщиков, стоимость лицензии. Поэтому EPS желательно измерить до закупки SIEM.
Нужно ли отправлять в SIEM все журналы инфраструктуры?
Нет. Избыточный сбор повышает стоимость хранения и нагрузку на аналитиков. Приоритет стоит отдавать источникам, которые участвуют в сценариях обнаружения или помогают расследовать инциденты.
Когда SOC нужен SOAR?
SOAR полезен после того, как команда отладила ручные процессы и понимает, какие действия повторяются регулярно. Тогда можно автоматизировать обогащение тревог, проверки и отдельные разрешенные действия. Автоматизировать плохо описанный процесс рискованно.
Какие метрики стоит отслеживать в SOC?
Полезно измерять среднее время обнаружения MTTD, среднее время реагирования MTTR, долю ложных срабатываний FPR и нагрузку на аналитиков. Такие показатели лучше отражают качество работы, чем простое число подключенных источников или правил.
Можно ли оставить L2 только в рабочее время?
Да, если L1 способен ночью самостоятельно закрывать основную массу тревог, а сложные эскалации происходят редко. При регулярных ночных расследованиях второй линии потребуется полноценная ротация из большего числа сотрудников или отдельная дежурная группа.
Что выгоднее: собственный или гибридный SOC?
Гибридная модель подходит компаниям, которым нужен мониторинг 24/7, но содержать большую сменную команду пока невыгодно. Внешний подрядчик может закрывать L1, а внутренние специалисты сохраняют расследования, принятие решений и знание бизнес-систем. Собственный SOC дает больше контроля, но требует большего постоянного бюджета.
Из чего складывается бюджет SOC?
В бюджет входят SIEM и другие средства защиты, вычислительная инфраструктура, хранение журналов, внедрение, интеграции, техническая поддержка, обучение и фонд оплаты труда. Для круглосуточного собственного SOC зарплаты команды часто становятся одной из крупнейших постоянных статей расходов.
Обязательно ли сразу запускать SOC в режиме 24/7?
Нет. Практичнее начать с пилота в ограниченном режиме, проверить источники данных, сценарии и нагрузку на аналитиков. Переход на 24/7 оправдан после того, как процессы работают стабильно и компания понимает реальную потребность в круглосуточном мониторинге.
Как ГосСОПКА влияет на архитектуру SOC для КИИ?
Для организаций, на которые распространяются соответствующие требования законодательства о КИИ, процессы SOC нужно увязать с установленным порядком информирования о компьютерных атаках и инцидентах и взаимодействия с ГосСОПКА. Конкретный набор обязанностей зависит от статуса организации и защищаемых объектов.
Одинаковы ли требования к SOC для КИИ, ГИС и систем персональных данных?
Нет. Для КИИ, государственных информационных систем и информационных систем персональных данных действуют разные нормативные требования. Поэтому до проектирования SOC нужно определить типы защищаемых систем и применимые нормы ФСБ, ФСТЭК и других регуляторов.
Заключение
SOC строят вокруг рисков и действий, а не вокруг интерфейса SIEM. Сначала компания определяет активы и угрозы, затем получает нужную телеметрию, создает сценарии, формирует команду и закрепляет порядок, как реагировать на инциденты. Если бюджета хватает на лицензию, но не на людей и процессы, собственный SOC 24/7 выбран преждевременно.
Материал носит информационный характер и не заменяет анализ нормативных требований для организации. При создании центра мониторинга ИБ учитывайте законодательство РФ и требования применимых регуляторов. Проверять сценарии обнаружения и реагирования следует только в собственной инфраструктуре или с разрешения владельца.
