По данным Mandiant M-Trends 2025, 57% организаций узнают о компрометации от внешней стороны. Не от собственного SOC. Не от SIEM за десятки миллионов. Не от EDR с ИИ-начинкой. Медианное время присутствия атакующего в сети - 11 дней. За эти 11 дней он успевает получить доступ к домену, выгрузить данные и подготовить шифрование. А SIEM всё это время генерирует алерты, которые никто не разбирает - потому что нет процесса триажа, нет ответственного за эскалацию, нет метрик, по которым руководство видело бы проблему.
Это не про плохие инструменты. Это про отсутствие зрелости программы кибербезопасности - состояния, при котором люди, процессы и технологии работают как связанная система, а не как набор закупок из прошлогоднего бюджета.
Карта темы: от оценки до стратегии
| # | Подтема | Подробнее |
|---|---|---|
| 1 | Модели зрелости: CMMC, C2M2, SSE-CMM, BSIMM | Модели зрелости ИБ: выбор фреймворка и self-assessment |
| 2 | Зрелость процессов vs бюджеты | Как выстроить защиту без карго-культа |
| 3 | Governance: оргструктура, RACI, reporting | Governance ИБ для зрелой программы |
| 4 | Метрики безопасности | Что реально измерять security-команде |
| 5 | ROI кибербезопасности | Как измерить эффективность ИБ-инвестиций |
| 6 | Roadmap повышения зрелости | Пошаговый план перехода между уровнями |
| 7 | ИБ-стратегия как фикция | Типичные провалы и как их находить на пентесте |
| 8 | Red team для бизнеса | Фреймворк ROI и шаблон питча для CFO |
| 9 | MITRE ATT&CK + ISO 27001 | Как объединить фреймворки для реальной защиты |
| 10 | Security awareness | Как пентестер выстраивает культуру кибербезопасности |
| 11 | Захват домена AD мимо SOC | От учётки стажёра до Domain Admin |
Что такое зрелость программы кибербезопасности и почему она важнее бюджета
Модель зрелости кибербезопасности - структурированный фреймворк для оценки того, насколько системно организация управляет киберрисками. Не "есть ли у нас антивирус", а "существует ли воспроизводимый процесс, который обнаруживает инцидент, эскалирует его, устраняет последствия и извлекает уроки - без зависимости от конкретного человека".Уровни зрелости в разных моделях называются по-разному, но суть одна - "crawl / walk / run":
| Уровень | Характеристика | Что происходит на практике |
|---|---|---|
| 1 - Ad hoc | Процессы отсутствуют или хаотичны | Реакция на инцидент зависит от того, кто из инженеров сегодня не в отпуске |
| 2 - Documented | Процессы описаны, но выполняются не всегда | Runbook есть, но последний раз его открывали при написании |
| 3 - Managed | Процессы выполняются, измеряются, контролируются | MTTD и MTTR считаются, SLA по эскалации соблюдается |
| 4 - Optimized | Процессы постоянно улучшаются на основе данных | Alert fatigue отслеживается, корреляционные правила тюнятся по метрикам false positive rate |
По данным IBM X-Force Threat Intelligence Index 2025, рост атак с использованием валидных учётных данных (T1078 - Valid Accounts) составил 71% год к году. Технология аутентификации тут не спасает - атакующий входит с легитимным паролем. Спасает процесс: мониторинг аномалий поведения, инвентаризация сервисных учёток (CIS Control 5 - Account Management), своевременная деактивация dormant accounts. Всё это - вопросы процессной зрелости, а не бюджета на очередной продукт.
Подробный разбор того, как зрелость процессов соотносится с бюджетами и почему закупка инструмента без процесса порождает карго-культ: Зрелость процессов информационной безопасности vs бюджеты: как выстроить защиту без карго-культа.
4 модели зрелости, которые реально используют: NIST CSF, CMMC, C2M2 и CIS Controls
Выбор фреймворка - одно из первых стратегических решений. И тут часто включается инерция: конкурент внедрил NIST CSF - значит, и нам надо. Или регулятор потребовал CMMC для работы с DoD. Никто не оценивает, насколько модель подходит под размер, отрасль и текущее состояние организации.NIST Cybersecurity Framework 2.0
Самый универсальный фреймворк из четвёрки. Шесть функций - Govern, Identify, Protect, Detect, Respond, Recover - покрывают весь жизненный цикл управления киберрисками. Версия 2.0 (2024) добавила функцию Govern, которая явно выделяет стратегическое управление и supply chain risk management. Четыре Implementation Tier - от Partial (реактивный подход) до Adaptive (проактивный, с обратной связью) - дают понятную шкалу зрелости.Сильная сторона: гибкость - применим к организации любого размера и отрасли. Слабая: нет предписывающих контролей. Фреймворк говорит "что оценивать", но не "как именно делать". Для команды, которая впервые берётся за зрелость, это может быть проблемой - сидишь с красивой моделью и не знаешь, с какого конца начать.
CMMC 2.0
Обязателен для подрядчиков Министерства обороны США. Три уровня вместо пяти в первой версии. Ключевое отличие - требование сторонней сертификации через C3PAO (CMMC Third-Party Assessment Organization). Организация обязана продемонстрировать реализацию всех практик конкретного уровня - POA&M (Plan of Actions and Milestones) не принимается.Сильная сторона: чёткая верифицируемость - не "мы считаем, что соответствуем", а "нас проверили и подтвердили". Слабая: заточен под защиту CUI и FCI, для организаций вне оборонной сферы требует серьёзной адаптации.
C2M2 (Cybersecurity Capability Maturity Model)
Разработан Министерством энергетики США совместно с экспертами из энергетического сектора. 350+ практик, 10 доменов, три уровня MIL (Maturity Indicator Level). Работает как для IT, так и для OT-сред. Инструмент самооценки бесплатен и доступен на сайте DOE. По данным DOE, более 3 500 организаций запросили PDF-версию инструмента, HTML-версия используется ежедневно.Сильная сторона: самооценку можно провести за один день - буквально за рабочую смену получить картину. Слабая: изначально ориентирован на энергетику, для других отраслей придётся адаптировать контекст.
CIS Controls v8.1
18 контролей с разделением на три группы реализации (IG1, IG2, IG3). IG1 - 56 safeguards, базовая кибергигиена. IG2 добавляет 74 safeguard для организаций с более сложной инфраструктурой. IG3 - ещё 23, для крупных организаций с критически важными данными. Преимущество CIS - предписывающий характер: контроли говорят "сделай конкретно это", а не "подумай о рисках". Для тех, кто устал от абстракций - самое оно.| Фреймворк | Уровни | Фокус | Для кого |
|---|---|---|---|
| NIST CSF 2.0 | 4 Tier | Универсальный risk-based подход | Любая отрасль, любой размер |
| CMMC 2.0 | 3 уровня | Защита CUI/FCI, сертификация | Подрядчики DoD |
| C2M2 v2.1 | 3 MIL | IT + OT, самооценка | Энергетика, критическая инфраструктура |
| CIS Controls v8.1 | 3 IG | Предписывающие контроли | Малый и средний бизнес, тактический подход |
Отдельно стоит упомянуть OWASP SAMM - модель зрелости безопасности ПО. Если ваша компания разрабатывает софт, SAMM оценивает процессы Governance, Design, Implementation, Verification и Operations в контексте SDLC.
Подробный разбор каждой модели с критериями выбора и методикой self-assessment: Модели зрелости информационной безопасности: CMMC, C2M2, SSE-CMM и BSIMM - выбор фреймворка и self-assessment.
Оценка зрелости ИБ: 4 шага, которые работают на практике
Оценка - не разовое мероприятие для аудита, а отправная точка для стратегии. Проблема большинства организаций знакомая: оценку провели формально, результат положили в ящик, никакого action plan не появилось. Через год - повторили. Результат тот же.
Шаг 1 - Выбор фреймворка. Используйте таблицу выше. Нет регуляторных требований - начинайте с NIST CSF 2.0 как самого гибкого. Нужна тактическая конкретика - CIS Controls.
Шаг 2 - Кросс-функциональная самооценка. Оценку нельзя проводить силами одного ИБ-отдела. Нужны представители IT-ops, разработки, HR (для оценки awareness), юридической службы (compliance). 360-градусный обзор безопасности по NIST CSF Profiles или CIS Controls Self Assessment Tool вскрывает расхождения между тем, что ИБ-отдел считает внедрённым, и тем, что реально работает в продуктиве. Эти расхождения бывают впечатляющими.
Шаг 3 - Gap-анализ и приоритизация. Сопоставьте текущее состояние с целевым уровнем зрелости. Определите разрывы. Приоритизируйте по трём критериям: бизнес-импакт риска, срочность (регуляторная или операционная), стоимость устранения. Задач всегда будет больше, чем ресурсов - это нормально. Стратегическая приоритизация и есть признак зрелости.
Шаг 4 - Реализация и мониторинг. Внедряйте улучшения итерационно. Каждая закрытая задача - повод пересмотреть приоритеты и начать следующий цикл. Безопасность не бывает "завершённой". NIST CSF 2.0 явно описывает этот подход в семишаговом процессе использования фреймворка.
Пошаговый roadmap с конкретными действиями для перехода между уровнями зрелости мы детально разобрали в Roadmap повышения зрелости ИБ: пошаговый план перехода между уровнями.
Governance ИБ: без оргструктуры процессы не заработают
Можно написать десять политик и купить три SIEM, но если не определено, кто отвечает за триаж алертов на L2, кому эскалировать инцидент в нерабочее время и как security-метрики попадают на стол CFO - программа безопасности остаётся набором документов. Красивых, согласованных, подписанных - и бесполезных.Governance - каркас, на который крепятся все процессы:
- Организационная структура - кому подчиняется CISO (CEO, CTO, CRO?), есть ли выделенный security committee на уровне совета директоров. На практике подчинение CISO -> CTO создаёт конфликт интересов: CTO хочет быстрее, CISO хочет безопаснее, и побеждает тот, кто ближе к бюджету.
- Матрица RACI (Responsible, Accountable, Consulted, Informed) - для каждого процесса: кто делает, кто отвечает за результат, кого привлечь, кого проинформировать. Без неё инцидент в 3 ночи разбирает тот, кто первый увидел алерт в Telegram - а не тот, кто должен.
- Reporting chain - как и с какой периодичностью результаты security-программы доводятся до руководства. Тут критична связка с метриками и ROI.
Подробнее об организационной структуре ИБ, ролевой модели и правильном reporting: Governance информационной безопасности: оргструктура, роли, RACI и reporting для зрелой ИБ-программы.
Метрики ИБ: что измерять, чтобы не обманывать себя
Типичная ситуация: SOC отчитывается цифрой "обработано 15 000 алертов за месяц". Руководство довольно. Безопасность "работает".А теперь вопрос: сколько из этих 15 000 были реальными инцидентами? Какой процент эскалирован в SLA? Сколько пропущено? Тишина.
Метрики зрелой программы делятся на три класса:
- Операционные: MTTD (Mean Time to Detect), MTTR (Mean Time to Respond), false positive rate, coverage ratio - доля критических активов под мониторингом
- Стратегические: уровень зрелости по выбранной модели, процент покрытия контролей (CIS safeguards, NIST subcategories), compliance gap score
- Бизнес-ориентированные: ROI security-инвестиций, стоимость инцидента (реальная vs ожидаемая), cyber risk quantification в финансовых терминах
CIS Controls прямо привязывают safeguards к измеримым результатам: CIS-1 (Inventory and Control of Enterprise Assets) требует активного обнаружения и инвентаризации - процент неинвентаризированных активов становится метрикой. CIS-5 (Account Management) требует деактивации dormant accounts - время жизни неактивной учётки становится KPI. Учётка жива 180 дней без логина? Это не метрика - это приглашение для атакующего.
Мы детально разобрали, какие метрики стоит внедрять на каждом уровне зрелости: Метрики информационной безопасности: что реально измерять security-команде.
ROI кибербезопасности: как перестать оправдываться и начать доказывать ценность
CISO, который приходит к CFO с запросом "нам нужен ещё один EDR за 20 млн рублей, потому что угрозы растут" - проиграл до начала разговора. Бизнес не оперирует угрозами. Бизнес оперирует финансовыми рисками, упущенной выручкой и compliance-штрафами.
Модели зрелости дают CISO инструмент для перевода security-языка на бизнес-язык. Логика:
- Текущий уровень зрелости - X (по результатам самооценки)
- При уровне X остаточный киберриск составляет Y рублей в год (cyber risk quantification)
- Переход на уровень X+1 стоит Z рублей и снижает остаточный риск до Y-d(delta)
- ROI = d / Z
Как правильно считать ROI ИБ-инвестиций и структурировать разговор с бизнесом: ROI кибербезопасности: как измерить эффективность ИБ-инвестиций и обосновать бюджет перед бизнесом.
Отдельный кейс - обоснование наступательных операций (red team / purple team) для бизнеса. Если CFO не понимает, зачем платить людям за то, чтобы они "ломали" собственную компанию, нужен конкретный фреймворк ROI и шаблон питча: Обоснование red team для бизнеса: фреймворк ROI и шаблон питча для CFO.
Почему СЗИ не работают без процессов: анатомия типичного провала
Сценарий, который я видел в десятках компаний. Организация закупает SIEM (Splunk, Elastic, MaxPatrol SIEM - неважно), интегрирует источники логов, настраивает базовые корреляционные правила. Первый месяц - энтузиазм: видим алерты, видим аномалии. Третий месяц - alert fatigue: 500 алертов в день, из них 490 - false positives. Аналитики SOC начинают игнорировать целые категории. Шестой месяц - SIEM превращается в дорогое хранилище логов, которое никто не смотрит.Что пошло не так? Не SIEM.
Нет тюнинга правил. На 2-м уровне зрелости правила корреляции пишутся один раз и не пересматриваются. На 4-м - существует процесс регулярного review false positive rate с обратной связью от аналитиков L1/L2.
Нет триажа. На 2-м уровне аналитик сам решает, что важно. На 4-м - есть severity matrix, SLA на разбор по каждому уровню, автоматическая эскалация по таймауту.
Нет ответственного за outcomes. Инструмент купили, но никто не отвечает за то, чтобы MTTD снижалось квартал к кварталу. Купили - и забыли, как абонемент в спортзал.
IBM X-Force фиксирует, что 70% атак затрагивают критическую инфраструктуру. Генерация фишинговых писем с помощью GenAI ускорилась в 11,4 раза - объём атак растёт, а процессы их обработки остаются на уровне "аналитик посмотрит, когда будет время".
Этот же паттерн - инструмент есть, процесс сломан - характерен не только для SIEM. EDR без правил реагирования на алерты, DLP без классификации данных (CIS Control 3 - Data Protection), vulnerability scanner без процесса patch management - всё это технологии, которые простаивают из-за организационной незрелости.
Как ИБ-стратегия компании превращается в фикцию и как пентест вскрывает эти провалы: Как ИБ-стратегия компании превращается в фикцию: разбор типичных провалов и как их находить на пентесте.
Пентест как индикатор зрелости: SOC за миллионы vs атакующий с Kerberoasting
Оценка зрелости по фреймворку - внутренний взгляд. Пентест - внешняя валидация. Расхождение между ними часто шокирует.
Организация оценивает себя на Tier 3 по NIST CSF (Repeatable). SOC работает 24/7, SIEM настроен, EDR развёрнут на 95% эндпоинтов. Пентестер получает учётку стажёра - и через цепочку T1110 - Brute Force -> T1003.001 - LSASS Memory -> T1021.002 - SMB/Windows Admin Shares добирается до Domain Admin. SOC не видит ни одного шага. Корреляционные правила не покрывают lateral movement через SMB с валидными учётными данными, а аномалия объёма аутентификаций фильтруется как known good от "обычного сканирования IT-отдела".
Этот разрыв между заявленной и реальной зрелостью - самый дорогой самообман в кибербезопасности. APT-группировки и операторы ransomware-as-a-service регулярно используют легитимные учётные данные и living-off-the-land техники, которые проходят мимо незрелых процессов мониторинга. По документам - Tier 3. На практике - Tier 1 с красивой отчётностью.
Детальный разбор того, как атакующий проходит путь от стажёра до Domain Admin мимо SOC: Захват домена Active Directory: от учётки стажёра до Domain Admin мимо SOC за миллионы.
Объединение фреймворков: как MITRE ATT&CK дополняет ISO 27001
Частая ошибка - рассматривать MITRE ATT&CK и ISO 27001 / NIST CSF как конкурентов. Они решают разные задачи и отлично работают в связке.ISO 27001 / NIST CSF - управленческие фреймворки. Отвечают на вопрос "какие контроли должны быть внедрены" и формируют структуру security-программы.
MITRE ATT&CK - тактический фреймворк. Отвечает на вопрос "от каких конкретных техник мы защищаемся" и позволяет приоритизировать контроли по реальным угрозам.
Связка работает так: ISO 27001 требует контроля доступа (Annex A). MITRE ATT&CK конкретизирует: T1078 - Valid Accounts - атакующий использует легитимные учётки; T1053.005 - Scheduled Task - закрепляется через планировщик. Теперь контроль доступа ISO 27001 - не абстрактное требование, а конкретный набор мер: инвентаризация сервисных учёток, мониторинг создания scheduled tasks, аудит Kerberos-тикетов.
Зрелая организация маппит контроли ISO 27001 / NIST CSF на техники MITRE ATT&CK и оценивает coverage - какой процент релевантных техник покрыт detection-правилами. Это уже метрика уровня 3-4. И тут начинается самое интересное: оказывается, что 80% правил покрывают 20% техник, а lateral movement и credential access - слепые зоны.
Как правильно объединить фреймворки и не делать двойную работу: MITRE ATT&CK и ISO 27001: как объединить фреймворки для реальной защиты инфраструктуры.
Security awareness: почему обученный сотрудник ценнее второго файрвола
По данным CrowdStrike, вредоносное использование GenAI для социальной инженерии удвоилось в 2024 году. Техника T1566.001 - Spearphishing Attachment остаётся одним из основных векторов initial access. Технологические меры (email gateway, sandbox) фильтруют массовые кампании, но целевой фишинг с качественным претекстом проходит через любой фильтр. Всегда проходил и будет проходить.Awareness-программа на 1-м уровне зрелости - ежегодная рассылка PDF с правилами. Бухгалтер открывает, ставит галочку "ознакомлен", закрывает. На следующий день кликает по "счёту от контрагента" в письме.
На 4-м уровне - непрерывный процесс: симуляция фишинга с адаптивной сложностью, измерение click rate по подразделениям, интеграция результатов в систему оценки рисков, обратная связь от red team по итогам социальной инженерии на реальных проектах.
NIST SP 800-53 выделяет отдельное семейство контролей AT (Awareness and Training), требуя не просто наличия программы, но её согласованности с общей стратегией управления рисками. CIS Control 14 (Security Awareness and Skills Training) добавляет конкретику: обучение должно быть ролевым - то, что знает разработчик, отличается от того, что знает бухгалтер.
Как выстроить awareness-программу, которая меняет поведение, а не просто ставит галочку: Security awareness программа: как пентестер выстраивает культуру кибербезопасности в компании.
Roadmap: от хаоса к зрелости за конкретные шаги
Переход между уровнями зрелости - не проект на квартал. Это стратегическая программа на годы. Типичный таймлайн:Уровень 1 -> 2 (6-12 месяцев): документирование ключевых процессов (incident response, access control, change management), назначение ответственных, базовая инвентаризация активов (CIS-1) и ПО (CIS-2). Звучит скучно, но без этого дальше ехать некуда.
Уровень 2 -> 3 (12-18 месяцев): внедрение метрик, SLA на процессы, регулярный аудит выполнения. Развёртывание SIEM с настроенными правилами корреляции. Запуск vulnerability management с измеримыми KPI (time-to-patch, coverage). Тут начинается самое болезненное - процессы, которые "были описаны", теперь надо реально выполнять.
Уровень 3 -> 4 (18-24+ месяца): непрерывное улучшение на основе данных. Автоматизация рутинных операций (SOAR). Интеграция threat intelligence в процессы detection. Red team / purple team как регулярная практика.
Критический фактор - executive sponsorship. Без поддержки C-level программа зрелости умирает на уровне 2, потому что для перехода на 3-й нужны бюджет, организационные изменения и межфункциональная координация, которые невозможны без мандата сверху. Я видел, как программы зрелости разбивались именно об это - CISO знает что делать, но у него нет полномочий заставить IT-ops поменять процесс.
Конкретный пошаговый план перехода между уровнями, с чеклистами и критериями готовности: Roadmap повышения зрелости ИБ: пошаговый план перехода между уровнями.
Стратегия кибербезопасности компании: 6 стадий от compliance до автоматизации
Зрелость security-программы - не только про технические процессы SOC. Это эволюция всей организации в отношении к киберрискам. По одной из распространённых моделей зрелости риск-автоматизации прогрессия выглядит так:- Initial - безопасность = compliance checkbox. Организация формально соответствует требованиям, но не управляет реальными рисками
- Developing - команда ИБ идентифицирует риски, руководство начинает финансировать risk automation
- Defined - стратегическое планирование, формальные процессы оценки рисков. Методы ещё ручные
- Managed - регулярная отчётность на уровне executives. Risk-aware культура. Определены KPI и KRI
- Optimizing - решения принимаются на основе данных. IRM-платформа (Integrated Risk Management) масштабирует оценки
- Dynamic - автоматизированное решение управляет контролями, человек валидирует данные. Cybersecurity posture корректируется динамически
Куда движется управление зрелостью: тренды ближайших 12 месяцев
Три направления, которые меняют подход к оценке зрелости программ кибербезопасности прямо сейчас.Cyber Risk Quantification (CRQ) вместо качественных оценок. Вместо "уровень 3 из 4" бизнес хочет слышать "переход на следующий уровень снижает ожидаемый годовой убыток на 40 млн рублей при инвестиции в 15 млн". Модели зрелости всё теснее интегрируются с CRQ-платформами, превращая абстрактные уровни в финансовые показатели. И это правильный вектор - пока мы говорим на языке «уровней», бизнес нас не слышит.
Supply chain risk management как обязательный домен. NIST CSF 2.0 уже включил supply chain в функцию Govern. Утечка данных колумбийской финтех-компании Addi (34,5 млн записей, март 2026, по данным HIBP) показывает масштаб рисков: зрелость одной организации может быть нивелирована уязвимостями в цепочке поставок. Вы выстроили Tier 4, а ваш подрядчик сидит на Tier 1 - и через него заходят к вам.
AI-driven threat landscape требует адаптивных процессов. Когда генерация фишинговых писем ускоряется в 11 раз (IBM X-Force), статические процессы assessment раз в год перестают работать. Зрелая организация переходит к continuous assessment - постоянной переоценке рисков в ответ на изменение угроз.
Первый шаг: что сделать сегодня
Если ваша организация ещё не проводила формальную оценку зрелости - начните с бесплатного инструмента самооценки C2M2 (доступен на сайте DOE) или CIS Controls Self Assessment Tool. Результат даст базовую линию, от которой строится вся дальнейшая работа. Один день - и у вас есть точка отсчёта. Без неё любые улучшения - стрельба вслепую.За 15 лет в ИБ я видел один паттерн, который повторяется с пугающей точностью: компания тратит 70-80% security-бюджета на инструменты и 20-30% на людей, а на процессы - ничего. Потом удивляется, что SOC с SIEM за десятки миллионов не поймал атакующего, который три недели жил в домене.
Проблема не в инструментах. Splunk, Elastic, CrowdStrike, PT MaxPatrol - все они делают то, что обещают. Инструмент без процесса - как хирургический стол без хирурга. Все компоненты на месте, но никто не оперирует.
Самые защищённые организации, которые я видел изнутри, не были самыми богатыми. Посредственные бюджеты, вторые-третьи по рынку решения. Зато у них был процесс триажа, где L1-аналитик знал: алерт этого типа - 15 минут на разбор, нет ответа - автоматическая эскалация на L2. Была severity matrix, согласованная с бизнесом. MTTD измерялось и снижалось квартал к кварталу. CISO раз в месяц показывал CFO три цифры вместо 40-страничной презентации.
Мне кажется, индустрия в ближайшие два года пройдёт болезненную коррекцию. Организации, которые вложились в инструменты без процессов, столкнутся с атаками, которые эти инструменты не остановят - не из-за технических ограничений, а из-за организационных. И тогда вопрос зрелости перестанет быть темой для конференций и станет темой для совета директоров. Вопрос - дождётесь ли вы этого инцидента или начнёте строить процессы сейчас.
Вложения
Последнее редактирование модератором:
