NIST CSF 2.0
для SOC

CSF определяет четыре Tier'а (уровня) — они описывают не «насколько защищены», а насколько зрелы и риск-ориентированы процессы. По всему документу для каждой функции дана лестница в этих терминах. Цель — не доползти до Tier 4 везде (это дорого и не всегда оправдано), а осознанно выбрать целевой уровень под риск-аппетит и закрыть разрыв.

Govern отвечает на вопрос «как организация принимает и контролирует решения о киберриске». Для SOC это управленческая надстройка: чем мы занимаемся в порядке приоритета, кто за что отвечает, как мы отчитываемся наверх и как риск цепочки поставок влияет на нашу работу.

Официальные категории

Зона ответственности SOC

SOC здесь не «владелец», а поставщик данных и исполнитель политик. Руководитель SOC переводит технические факты на язык риска для менеджмента и обратно — приоритеты менеджмента в use-case'ы и SLA.

Практическое внедрение

1. Сформулировать устав SOC: миссия, scope мониторинга, зоны ответственности, что вне scope.
2. Описать иерархию ролей L1/L2/L3 + дежурный инженер + руководитель, с матрицей полномочий (кто вправе изолировать хост, кто — отключить сервис).
3. Утвердить политику эскалации и SLA по критичности инцидента (привязать к риск-аппетиту из GV.RM).
4. Завести регламент отчётности: набор метрик наверх + периодичность (операционные — еженедельно, управленческие — ежемесячно/квартально).
5. Включить поставщиков в модель угроз (GV.SC): мониторинг доступов подрядчиков, контроль MSSP, требования к логированию у третьих сторон.

Метрики функции

Лестница зрелости

Identify — фундамент. Это понимание того, что у вас есть, что из этого критично и какие риски этому угрожают. Для SOC слепые зоны инвентаризации напрямую превращаются в слепые зоны детектирования: актив, которого нет в CMDB, не покрыт логами, не мониторится, не эскалируется.

Официальные категории

Зона ответственности SOC

SOC — потребитель и одновременно валидатор инвентаризации. Через данные мониторинга SOC обнаруживает теневые активы (то, что генерирует трафик/логи, но отсутствует в CMDB) и возвращает их в учёт.

Практическое внедрение

1. Связать CMDB ↔ источники логов: каждый критичный актив обязан иметь поставку телеметрии в SIEM. Расхождение = задача.
2. Построить карту поверхности атаки: внешние сервисы, точки входа, потоки данных, доверительные связи.
3. Приоритизировать активы по критичности для бизнеса (из GV.OC) — это потом задаёт уровни алертов и SLA.
4. Наладить обратную связь по теневым активам: SOC видит неучтённый источник → заводит в CMDB.
5. Привязать vulnerability management: уязвимости критичных активов → приоритет в детектировании эксплуатации.

Метрики функции

Лестница зрелости

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

Официальные категории

Зона ответственности SOC

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

Практическое внедрение

1. Согласовать с IT hardening-baseline и требовать, чтобы отклонения логировались (config drift = событие).
2. Обеспечить телеметрию identity (IdP, аутентификация, привилегированные операции) — основа детектов по компрометации учёток.
3. Заложить наблюдаемость сегментации: межсегментный трафик должен проходить через точки контроля с логами.
4. Поставлять в обучение (PR.AT) реальные TTP из своих инцидентов — обучение на актуальных угрозах эффективнее абстрактного.
5. Мониторить состояние защитных контролей (агент жив? DLP-политика применена? MFA не обойдена?) — деградация контроля = алерт.

Метрики функции

Лестница зрелости

Detect — сердце SOC. Это способность своевременно находить события и аномалии и понимать их значимость. Большая часть инженерной работы SOC (use-case'ы, корреляция, покрытие по матрице угроз, охота) ложится именно сюда.

Официальные категории

Зона ответственности SOC

Это прямая и основная зона. SOC владеет конвейером детектирования целиком: сбор телеметрии → нормализация → корреляция → детекты → триаж → алерт. Здесь же — detection engineering как дисциплина и threat hunting как проактивный слой.

Практическое внедрение

1. Построить каталог use-case'ов, привязанный к матрице техник противника (покрытие по тактикам/техникам — измеримая величина).
2. Внедрить detection engineering как процесс: версионирование правил, тестирование, ревью, метрика качества (precision/recall детекта).
3. Наладить цикл снижения ложных срабатываний: каждый FP → разбор → тюнинг правила или подавление с обоснованием (не «выключить»).
4. Запустить threat hunting по гипотезам (TI-driven и поведенческий) — находки превращать в новые детекты.
5. Интегрировать threat intelligence: IoC и TTP актуализируют детекты; приоритет — по релевантным группировкам.
6. Измерять покрытие и пробелы: какие техники не детектируются вообще — это backlog инженерии.

Метрики функции

Лестница зрелости

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

Официальные категории

Зона ответственности SOC

Прямая зона. SOC владеет триажем, анализом и первичной локализацией. Граница ответственности — там, где требуются решения бизнеса (остановка сервиса, юридические нотификации): SOC готовит факты и рекомендации, решение принимается на уровне Govern.

Практическое внедрение

1. Описать плейбуки на типовые сценарии (фишинг, компрометация учётки, вредонос, латеральное движение, эксфильтрация) — пошагово, с ролями и точками эскалации.
2. Внедрить классификацию инцидентов по критичности и привязать к ней SLA реагирования (из GV.RM).
3. Автоматизировать рутину через оркестрацию (SOAR-класс): обогащение, типовые ответные действия, нотификации.
4. Стандартизировать сбор и сохранность артефактов (chain of custody) для возможной форензики и юридических последствий.
5. Прописать матрицу коммуникаций: кого, когда и в каком объёме уведомлять (внутри и наружу, включая регуляторные сроки).
6. Закрепить полномочия на containment: что L1/L2/L3 вправе делать без согласования, что требует эскалации.

Метрики функции

Лестница зрелости

Recover — про восстановление работоспособности после инцидента и коммуникацию в ходе восстановления. Для SOC это в основном про координацию, валидацию «чисто ли» и, главное, цикл извлечения уроков, который замыкает колесо обратно на Identify и Detect.

Официальные категории

Зона ответственности SOC

Восстановлением сервисов обычно владеет IT, но SOC валидирует «чистоту» восстановленной среды (нет ли остаточного присутствия, бэкдоров, закрепления) и ведёт пост-инцидентный разбор, превращая выводы в задачи для Detect и Identify.

Практическое внедрение

1. Закрепить за SOC валидацию восстановления: прежде чем объявить «чисто», подтвердить отсутствие персистентности и повторной компрометации.
2. Сделать post-incident review (lessons learned) обязательным этапом по значимым инцидентам — с фиксированным шаблоном.
3. Превращать выводы разбора в конкретные задачи: новый детект (→ Detect), пробел в инвентаризации (→ Identify), слабый контроль (→ Protect). Это и есть замыкание колеса.
4. Координировать коммуникацию восстановления: статусы для стейкхолдеров, согласованность сообщений.
5. Вести базу знаний инцидентов: разборы накапливаются и переиспользуются (питает обучение L1/L2/L3).

Метрики функции

Лестница зрелости

Внедрять колесо целиком и сразу — путь к выгоранию. Ниже — фазовый порядок, в котором функции усиливают друг друга: сначала фундамент (Govern + Identify), затем ядро (Detect + Respond), потом замыкание и адаптация.

Метрики делятся на операционные (для управления SOC изнутри) и управленческие (для отчётности в Govern). Не путайте аудитории: руководству не нужен FP-rate отдельного правила, а инженеру детектирования — квартальный тренд риска.

CSF — общеорганизационный фреймворк, и SOC владеет не всем. Чёткое разграничение снимает конфликты «это не наша зона» во время инцидента. Ниже — где SOC владеет (R/A), где участвует (C), где информируется (I).

Отметьте утверждения, которые верны прямо сейчас, без «почти» и «в планах». Доля закрытых пунктов по функции грубо соответствует Tier'у: <25% — Tier 1, до 50% — Tier 2, до 80% — Tier 3, выше — приближение к Tier 4.

Govern

• Существует утверждённый устав SOC с зафиксированным scope.
• Роли L1/L2/L3 и полномочия на containment описаны и известны команде.
• SLA привязаны к риск-аппетиту, а не взяты «с потолка».
• Есть регулярная отчётность наверх с фиксированным набором метрик.

Identify

• Каждый критичный актив имеет подтверждённую поставку телеметрии.
• Критичность активов размечена и используется в приоритетах алертов.
• Теневые активы регулярно отлавливаются и возвращаются в учёт.

Protect

• Hardening-baseline согласован, а его нарушения логируются.
• Identity-телеметрия покрывает аутентификацию и привилегированные операции.
• Здоровье защитных агентов мониторится, деградация = алерт.

Detect

• Есть каталог use-case'ов с измеримым покрытием техник противника.
• Detection engineering — процесс с версиями, тестами и ревью.
• Каждый ложноположительный разбирается и ведёт к тюнингу.
• Threat hunting ведётся регулярно по гипотезам.

Respond

• Плейбуки покрывают основные сценарии и известны дежурным.
• Рутинные действия реагирования автоматизированы.
• Артефакты сохраняются с соблюдением целостности.
• Матрица коммуникаций определяет, кого и когда уведомлять.

Recover

• SOC валидирует чистоту среды перед объявлением «восстановлено».
• Пост-инцидентный разбор обязателен по значимым инцидентам.
• Выводы разборов стабильно превращаются в задачи (новые детекты и пр.).