“Структура команды ИБ на 15–30 человек, это поиск компромисса между глубиной специализации и постоянным риском превратиться в команду всезнаек и всёдел. Чтобы не стать узким местом и не потерять экспертизу, нужно делить обязанности по сферам влияния, а не по спискам задач. Здесь я покажу, как разделить GRC, архитектуру, операционную безопасность и Red Team так, чтобы они не дублировали друг друга, а усиливали”
.
От универсальной команды к специализации
Когда команда вырастает до 15-20 человек, попытка сохранить универсальный подход приводит к тому, что задачи по GRC, инженерным работам и расследованию инцидентов перемешиваются в общем бэклоге. Специалисты разрываются между проектами, экспертиза в конкретных областях не углубляется, а скорость реагирования на новые угрозы падает. Это стадия, когда формальное разделение обязанностей становится необходимостью.
Разделение должно строиться не просто по названию ролей, а по зонам ответственности и типам рабочих процессов. Это позволяет выделить специализированные подкоманды с чёткими целями и метриками, сохранив при этом возможность гибкого взаимодействия.
Структура команды: три ключевых блока
Для организации в 15–30 человек оптимальной является структура из трёх основных блоков, каждый из которых фокусируется на своём временном горизонте и типе работы.
GRC и Управление рисками: Эта группа работает на горизонте кварталов и лет. Их цель — обеспечить соответствие требованиям регуляторов (152-ФЗ, ФСТЭК), выстроить систему управления рисками, организовать аудиты и работу с внутренними политиками. Они переводят нормативные требования на язык технических спецификаций для архитекторов.
Архитектура и инженерная безопасность: Этот блок работает на горизонте месяцев. Он получает от GRC требования и проектирует решения: сегментацию сети, системы управления доступом, архитектуру SIEM, процессы мониторинга. Инженеры внедряют эти решения, настраивают технические средства защиты информации (СЗИ) и обеспечивают их корректную интеграцию в инфраструктуру.
Операционная безопасность (SOC) и Red Team: Этот блок работает в реальном времени и на горизонте недель. Он отвечает за ежедневный мониторинг, расследование инцидентов и проактивное тестирование защищённости. Здесь происходит ключевое разделение на Blue Team (защита, мониторинг, реагирование) и Red Team (моделирование угроз, тестирование на проникновение).
Детальное разделение обязанностей
Блок GRC и управления рисками (4–6 человек)
- Ведение реестра информационных активов и рисков в соответствии с методиками ФСТЭК.
- Разработка и актуализация организационно-распорядительных документов (Политика ИБ, регламенты).
- Организация и сопровождение аудитов на соответствие 152-ФЗ и внутренним требованиям.
- Взаимодействие с регуляторами и надзорными органами.
- Обучение и повышение осведомлённости сотрудников компании.
Ключевая сложность — избежать превращения этого блока в бюрократический аппарат, оторванный от реальности. Для этого его представители должны участвовать в технических рабочих группах, а отчёты по рискам — напрямую влиять на приоритеты для архитекторов и инженеров.
Блок архитектуры и инженерной безопасности (6–10 человек)
Это техническое ядро команды. Его можно разделить на две подроли:
- Архитекторы безопасности: Проектируют общие решения: сетевые экраны следующего поколения (NGFW), системы DLP, архитектуру с нулевым доверием (Zero Trust) для критических сервисов, безопасные CI/CD-конвейеры.
- Инженеры безопасности: Внедряют и сопровождают конкретные продукты — SIEM, IDS/IPS, EDR-системы. Настраивают корреляции, пишут скрипты для автоматизации рутинных задач, таких как сбор логов или проверка конфигураций.
Пример задачи: архитектор определяет, что для соответствия требованиям ФСТЭК по защите персональных данных необходимо сегментировать сеть и внедрить решение класса DLP. Инженер выбирает конкретный продукт из аттестованного реестра ФСТЭК, разворачивает его, настраивает политики анализа трафика и интеграцию с SIEM для генерации событий.
Блок операционной безопасности и Red Team (5–9 человек)
Наиболее динамичная часть команды. Здесь критически важно разделить функции защиты и нападения.
- SOC (Blue Team): (3–5 человек) Мониторинг событий безопасности, триаж оповещений от SIEM, расследование инцидентов первой линии, управление уязвимостями (патчинг).
- Red Team: (2–4 человека) Проведение регулярных тестов на проникновение (внешних и внутренних), моделирование целевых атак (APT), социальная инженерия, анализ защищённости веб-приложений и API. Red Team не занимается исправлением найденных уязвимостей — они передают отчёт команде архитектуры или разработки. Их цель — найти бреши до того, как это сделает реальный злоумышленник.
Практика, которую часто упускают: Red Team должна тестировать не только техническую инфраструктуру, но и процессы SOC. Например, как быстро и эффективно аналитики обнаружат смоделированную атаку и начнут расследование.
Взаимодействие между блоками и эскалация
Эффективная работа структуры невозможна без налаженных процессов взаимодействия.
- От GRC к Архитектуре: Требования регуляторов (например, новый приказ ФСТЭК) формализуются GRC в виде технического задания на доработку архитектуры.
- От Архитектуры к OpSec: Внедрённое новое средство защиты (например, EDR) передаётся под управление SOC с описанием ожидаемых событий и процедурами реагирования.
- От Red Team ко всем: Результаты тестов на проникновение передаются в виде приоритизированного списка уязвимостей. Критические уязвимости архитектурного уровня требуют перепроектирования, операционные — быстрого исправления инженерами или системными администраторами. Отчёт Red Team также является входными данными для GRC при оценке рисков.
- От SOC к GRC/Архитектуре: Статистика инцидентов и новые векторы атак, выявленные SOC, используются для актуализации модели угроз и, как следствие, для корректировки требований к архитектуре.
Типичные ошибки при построении структуры
- Смешение Red Team и Blue Team в одних руках. Это приводит к конфликту интересов: одна команда не может объективно оценивать эффективность собственной защиты. Разделение должно быть организационным и подотчётным разным руководителям.
- GRC как «бумажный тигр». Если требования этой команды не имеют приоритета у разработки и IT-инфраструктуры, вся работа становится формальностью. GRC должен иметь механизмы влияния через процессы управления рисками и бюджетом.
- Отсутствие карьеры внутри специализации. Инженер, который хочет развиваться в области анализа вредоносного ПО, должен иметь путь внутри OpSec, а не быть вынужденным переходить в архитекторы. Нужно создавать уровни seniority внутри каждого блока (junior, middle, senior, lead).
- Перекос в сторону реагирования. Когда SOC постоянно завален инцидентами, у команды не остаётся ресурсов на проактивные меры от архитекторов и Red Team. Это порочный круг, который разрывается только выделением отдельных ресурсов на проектные задачи.
Метрики успеха для каждого блока
Чтобы оценить эффективность структуры, для каждого блока нужны свои показатели.
| Блок | Ключевые метрики |
|---|---|
| GRC | Процент закрытых несоответствий по аудиту; время на согласование исключений из политик; охват обучением по ИБ. |
| Архитектура | Процент покрытия критических активов средствами защиты; время на развёртывание нового СЗИ; количество автоматизированных рутинных задач. |
| SOC (Blue Team) | Среднее время обнаружения (MTTD) и реагирования (MTTR) на инциденты; процент ложноположительных срабатываний; скорость закрытия уязвимостей. |
| Red Team | Количество найденных критических уязвимостей за период; среднее время на незаметное проникновение в сеть; процент успешно смоделированных сценариев атак из актуальной модели угроз. |
Важно, чтобы эти метрики не использовались для наказания, а служили точкой для обсуждения и улучшения процессов на регулярных кросс-функциональных встречах.