На проверке Как построить SOC с нуля: команда, роли, инструменты и первые 90 дней

[Сергей Попов]

По данным Mandiant M-Trends 2025, медианное время нахождения злоумышленника в сети - 11 дней. Исторический минимум. И при этом 57% организаций узнают об инциденте от внешней стороны, а не от собственного мониторинга. Чувствуете иронию?

За два запуска SOC с нуля - on-prem для производственного холдинга и гибрид для финтех-компании - я наблюдал одну и ту же картину: руководство ожидает «мониторинг и реагирование через квартал», а первые реальные инциденты всплывают на второй неделе после включения SIEM, когда ни одного плейбука ещё нет. Разница между SOC, который работает, и SOC «для галочки» - не бюджет на SIEM, а план на первые 90 дней.

Структура SOC в компании: выбор модели до первого найма​

Решение о модели определяет бюджет, сроки выхода на боевой режим и кадровую стратегию. Ошибка на этом этапе - это 6-12 месяцев потерянного времени и деньги, ушедшие в пустоту.

Критерий	On-Prem	Гибрид	MSSP/MDR
Бюджет первого года	30-50 млн руб. (CAPEX) + 20-40 млн руб. (OPEX)	10-25 млн руб.	5-15 млн руб.
Выход на режим 24/7	12-18 месяцев	3-6 месяцев	1-3 месяца
Контроль над данными	Полный	Частичный (данные L1 у провайдера)	Минимальный
Кастомизация детекта	Максимальная	Средняя	Ограниченная типовыми сценариями
Совместимость с КИИ (ФЗ-187)	Да	Частично (зависит от категории объекта)	Нет для объектов 1-2 категории
Главный риск	Кадровый голод, выгорание ключевых людей	Конфликт зон ответственности	Полная зависимость от провайдера

Для субъектов КИИ по ФЗ-187 обмен информацией с ГосСОПКА (НКЦКИ) обязателен - сроки уведомления от 3 до 24 часов в зависимости от категории объекта. Это сразу ограничивает выбор: чистый MSSP допустим, только если провайдер аккредитован для работы с данными соответствующей категории КИИ.

Когда гибрид выигрывает​

Гибрид - самый частый выбор для компаний с ИТ-штатом от 200 до 1000 человек. Схема простая: первую линию (L1, мониторинг 24/7) берёт внешний провайдер (BI.ZONE TDR, Solar JSOC, Kaspersky MDR или Innostage SOC), вторую и третью линии оставляют внутри.

Главный плюс - круглосуточное покрытие закрывается за 2-3 месяца, пока внутренняя команда набирает экспертизу. На российском рынке это решает критичную проблему: найти 8-10 аналитиков для трёхсменного графика за пределами Москвы и Питера - задача, которая легко растягивается на год.

Роли и команда SOC: минимальный состав для запуска​

Трёхлинейная модель L1/L2/L3 в режиме 24/7 требует минимум 8-10 человек. На старте для большинства организаций - нереалистично. Практический подход: начинать с трёх ключевых ролей, покрывающих рабочие часы (8/5), и расширяться постепенно.

SOC команда безопасности: три роли для старта​

1. Руководитель SOC / SOC Manager. Владеет стратегией, бюджетом, взаимодействием с бизнесом. Определяет приоритеты мониторинга, формирует SLA, защищает бюджет перед руководством. Без этого человека аналитики не знают, что считать инцидентом, а что - шумом. Ориентир по ЗП: 250-400 тыс. руб./мес (Москва, 2025).

2. Аналитик SOC (L1/L2). Дежурный мониторинг, триаж алертов, первичное расследование. На старте совмещает функции обеих линий. Ориентир: 100-200 тыс. руб./мес в зависимости от региона и опыта.

3. SIEM-инженер / Detection Engineer. Подключает источники логов, пишет и тюнит корреляционные правила, настраивает интеграции между компонентами стека. Ориентир: 200-350 тыс. руб./мес.

Ошибка, которую я видел дважды: нанять трёх L1-аналитиков без тимлида. Результат - три человека смотрят в дашборд и закрывают алерты как «ложноположительные», потому что никто не объяснил критерии эскалации. Руководитель SOC должен быть первым наймом, даже если пока команда - это он один.

Порядок найма по неделям​

Неделя	Действие	Результат
1-2	Назначить / нанять руководителя SOC	Владелец процесса, бюджета и SLA
3-4	Нанять SIEM-инженера	Начало развёртывания стека и подключения источников
5-8	Нанять 1-2 аналитиков L1/L2	Готовность к мониторингу в режиме 8/5
9-12	Расширить до 3-4 аналитиков	Переход к расширенному графику (16/5 или 12/7)
13+	Рассмотреть L3 / Threat Hunter	Проактивный поиск угроз

По данным Hack The Box, 84% специалистов по кибербезопасности сообщают о стрессе и выгорании. Для удержания аналитиков на практике работает простая вещь: 2 часа в неделю на обучение (лабы, разбор инцидентов, CTF) и участие в тюнинге правил детектирования. Аналитик, который видит, как его правило поймало реальный инцидент, остаётся в команде дольше, чем тот, кто весь день закрывает ложноположительные. Проверено.

Инструменты для SOC: сравнение стеков и внедрение SIEM​

Выбор стека зависит от бюджета, требований к сертификации и доступной экспертизы. Ниже - сравнение SIEM-платформ на российском рынке.

Сравнение SIEM-платформ: trade-off таблица​

Критерий	MaxPatrol SIEM (PT)	KUMA (Kaspersky)	Elastic SIEM + Wazuh
Преимущества	Интеграция с PT-стеком (VM, NAD, Sandbox), встроенный asset management, сертификация ФСТЭК	Нативная интеграция с Kaspersky EDR/KES, единая консоль	Бесплатное ядро, огромное комьюнити, гибкость кастомизации
Ограничения	Высокая стоимость лицензии, привязка к PT-стеку	Относительно молодой продукт, меньше публичных правил	Нет сертификации ФСТЭК, требует экспертизы для production
Когда использовать	КИИ с требованиями ФСТЭК, организации с PT-стеком	Компании с Kaspersky EDR/KES в инфраструктуре	Средний бизнес без бюджета на коммерческий SIEM
Когда НЕ использовать	Бюджет менее 10 млн руб./год на SIEM	Нет продуктов Kaspersky в инфраструктуре	Объекты КИИ 1-2 категории

R-Vision SIEM - ещё один вариант, сильный интеграцией с R-Vision IRP/SOAR. Подходит организациям, которые уже используют R-Vision для управления инцидентами.

Минимальный стек для старта​

За рамками SIEM потребуются:

• EDR: Kaspersky EDR Expert, PT EDR или CrowdStrike Falcon (для организаций без требований КИИ)
• Ticketing/IRP: TheHive (open source), R-Vision IRP или встроенный модуль SIEM
• SOAR: на старте не нужен. Автоматизацию запускать после 60 дней ручной работы - когда понятны реальные паттерны алертов и типовые действия реагирования. Раньше - будете автоматизировать хаос

Требования к окружению для развёртывания SIEM​

Компонент	Минимум	Рекомендуется
SIEM-сервер	32 ГБ RAM, 8 vCPU, 1 ТБ SSD	64 ГБ RAM, 16 vCPU, 4 ТБ SSD (RAID-10)
Поток событий	до 3 000 EPS	до 10 000 EPS
ОС	RHEL/CentOS 8+, Ubuntu 22.04 LTS	Согласно требованиям вендора SIEM
Сеть	Syslog (UDP/TCP 514), WEC/WMI для Windows	Отдельный VLAN для SOC-инфраструктуры
Хранение	30 дней онлайн	90+ дней онлайн, 365 дней в cold storage

Первые 90 дней SOC: пошаговый план запуска​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Пример Sigma-правила для обнаружения дампа LSASS (T1003.001, Credential Access):

title: Potential LSASS Memory Access
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1038'
  condition: selection
level: high

Sigma-правила - стандарт для кроссплатформенного детектирования. Конвертация в формат конкретного SIEM выполняется через sigma-cli convert - для MaxPatrol SIEM, KUMA, Elastic и QRadar существуют готовые бэкенды. На практике конвертация редко работает 1:1 - почти всегда приходится допиливать под конкретные имена полей и формат логов.

Плейбуки для пяти приоритетных сценариев - каждый содержит: триггер (какой алерт), шаги валидации (что проверить), действия по сдерживанию (что заблокировать), критерии эскалации (когда звонить CISO), целевой SLA:

1. Подозрительная аутентификация - brute-force, нетипичное время или геолокация
2. Подозрительное вложение - алерт от почтового шлюза или песочницы
3. Запуск PowerShell с обфускацией (T1059.001) - -enc, -nop, base64
4. Нетипичное RDP-подключение (T1021.001) - новый source IP, нерабочее время
5. Очистка журналов событий (T1070.001) - Event ID 1102 в Security Log

Дни 61-90: оптимизация и переход в боевой режим​

Цель фазы: снизить false positive rate ниже 70%, установить baseline MTTD/MTTR, формализовать SLA.

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

Конкретные действия:

• Whitelist-менеджмент: исключения для легитимных сервисных учёток, плановых задач, административных скриптов. Каждое исключение документируется с обоснованием и сроком пересмотра (иначе через полгода whitelist превращается в дыру размером с ворота)
• Baseline сетевого трафика: согласно NIST CSF DE.AE-01 - «базовый уровень сетевых операций и ожидаемых потоков данных установлен и управляется». Без baseline детектировать аномалии невозможно - вы просто не знаете, что «нормально»
• SLA по времени реагирования: критичный инцидент - реакция за 15 минут, высокий - 1 час, средний - 4 часа, низкий - 8 часов
• Первый Threat Hunting-спринт: гипотеза + данные + вывод. Начальная гипотеза: «есть ли в инфраструктуре неучтённые RDP-соединения (T1021.001) за последние 30 дней?»

На этом этапе SOAR-автоматизация начинает окупаться. Три кандидата на автоматизацию:

• Автообогащение индикаторов компрометации через TI-платформу (VirusTotal API, Kaspersky TIP)
• Автоматическая изоляция хоста при подтверждённом инциденте через API EDR
• Создание тикета в IRP при срабатывании правила уровня High/Critical

Метрики эффективности SOC с первого дня​

Без метрик SOC превращается в чёрную дыру для бюджета. Две метрики на старте - обязательный минимум:

• MTTD (Mean Time to Detect) - среднее время от начала вредоносной активности до обнаружения SOC. Целевое значение для первого года: менее 24 часов. Для контекста: глобальная медиана по Mandiant M-Trends 2025 - 11 дней. Если вы за год выйдете на сутки - это уже хороший результат
• MTTR (Mean Time to Respond) - среднее время от обнаружения до сдерживания/устранения. Целевое значение: менее 4 часов для критичных инцидентов

Дополнительные метрики для отчёта руководству:

Метрика	Что измеряет	Целевое значение (первый год)
False Positive Rate	Доля ложных срабатываний	Менее 70% (на старте будет 90%+)
Coverage Ratio (MITRE ATT&CK)	Доля покрытых техник	30-40% к 90-му дню
Escalation Rate	Доля алертов, эскалированных на L2/L3	15-25%
Source Coverage	Доля подключённых категорий источников	5+ категорий к 30-му дню

Оба показателя - MTTD и MTTR - должны снижаться месяц к месяцу. Если тренд стагнирует или растёт, SOC накапливает невидимый риск. Это первый сигнал, что что-то сломалось в процессе.

Чеклист готовности SOC к боевому режиму на 90-й день​

Этот чеклист передаётся руководству как формальный отчёт о готовности SOC. Формат - для включения в протокол совещания или приказ о вводе в эксплуатацию.

Блок A: люди и процессы

1. Назначен руководитель SOC с полномочиями на изоляцию хостов и блокировку учётных записей
2. Минимум 2 аналитика прошли onboarding и самостоятельно обрабатывают алерты
3. Определены SLA для трёх уровней критичности инцидентов (15 мин / 1 ч / 4 ч)
4. Написаны и протестированы плейбуки для 5 приоритетных сценариев
5. Настроена цепочка эскалации: аналитик - тимлид - CISO - руководство компании

Блок B: технологии

1. SIEM развёрнут и принимает логи от минимум 5 категорий источников (AD, DNS, NGFW, почта, EDR)
2. Активировано 15+ корреляционных правил с покрытием минимум 5 тактик MITRE ATT&CK
3. EDR установлен на 90%+ конечных точек
4. IRP/ticketing интегрирован с SIEM - алерты автоматически создают тикеты
5. Резервное копирование конфигурации SIEM выполняется ежедневно

Блок C: измерение

1. Дашборд с MTTD/MTTR обновляется ежедневно
2. False Positive Rate отслеживается; whitelist пересматривается еженедельно
3. Карта покрытия MITRE ATT&CK сформирована, план расширения покрытия утверждён
4. Первый Threat Hunting-спринт проведён и задокументирован

Блок D: комплаенс

1. Для КИИ: настроено взаимодействие с ГосСОПКА (НКЦКИ), протестирована отправка уведомления в сроки 3-24 часа
2. Политика реагирования на инциденты (IR-1 по NIST SP 800-53) разработана и утверждена приказом
3. Журнал учёта инцидентов ведётся в соответствии с требованиями аудита (AU-1 по NIST SP 800-53)
4. Программа обучения персонала SOC (AT-1) утверждена: минимум 2 часа в неделю на развитие компетенций

Большинство руководств по построению SOC фокусируются на выборе SIEM - какой купить, сколько EPS обработает, как настроить коннектор. За два проекта я пришёл к выводу, что технологии - последнее, что определяет эффективность SOC.

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

Второе - человек, который умеет разговаривать с бизнесом. Руководитель SOC, способный объяснить финансовому директору, почему 15 млн рублей в год на мониторинг дешевле одного простоя из-за шифровальщика, ценнее пяти L1-аналитиков.

Отдельная боль - ожидание, что SOC начнёт ловить APT на третьей неделе. Даже по данным Mandiant, организации с зрелым мониторингом в 57% случаев узнают об инциденте извне. Реалистичная цель на первые 90 дней - не «поймать APT», а «перестать быть слепым»: видеть аутентификацию, видеть запуск процессов, видеть сетевые аномалии. Если у вас другой стек детекции или опыт адаптации Sigma-правил под российские SIEM - на codeby.net есть тред, где обсуждаем конвертацию правил для MaxPatrol и KUMA.