Про Exposure Management я уже писал не раз. Сразу надо сказать, что, когда упоминаются решения класса CTEM или EAP, это всего лишь верхушка айсберга, часть, связанная с автоматизацией. Но на самом деле управление площадью атаки – это процесс, который должен быть внедрен и оценен. Та же история и с управлением уязвимостями, которое часто воспринимается через призму конкретных продуктов, которые всего лишь упрощают реализацию процесса, а не подменяют его.
Итак, управление площадью атаки. Как можно оценить свой уровень зрелости в этой части управления ИБ? Можно сказать: «У меня ничего нет; отстаньте от меня.». А можно попробовать есть слона по частям, разбив внедрение процесса на стадии, что оценивать будет гораздо проще. Я на досуге набросал легонькую модель зрелости для управления площадью атаки, чтобы вы могли себя быстро оценить. Итак:
Уровень №1 «Слепая зона»
Площадь атаки и слабости, ее расширяющие, существуют, но компания о них не имеет системного представления. То есть ИБ реагирует постфактум: после инцидентов, аудитов или жалоб. Индикаторы (чек-лист):
❌ Нет полного списка активов (что именно защищаем – неизвестно).
❌ Уязвимости ищутся нерегулярно и вручную.
❌ Сканирование запускается «когда вспомнили».
❌ DevOps не получает обратной связи по безопасности.
❌ Риски не приоритизируются – все выглядит одинаково критичным.
Быстрый тест. Задайте себе вопрос: «У вас есть актуальный список всех сервисов и хостов, доступных из интернета?» Если ответа нет – вы на первом уровне.
Уровень №2 «Точечная видимость»
Представление о площади атаки есть, но уязвимости не связаны с реальными рисками (недопустимыми событиями). То есть компания видит уязвимости, но не понимает, какие из них реально опасны. Индикаторы этого уровня зрелости:
✅ Есть базовый реестр активов (частичный).
✅ Периодически проводится сканирование уязвимостей.
❌ Приоритизация основана только на CVSS.
❌ Нет связи уязвимостей с бизнес-критичностью.
❌ Исправления идут «по очереди», а не по уровню риска.
Быстрый тест. Задайте себе вопрос: «Почему именно эту уязвимость вы исправляете первой?» Если ответ: «Потому что CVSS 9.8», вы на втором уровне.
Уровень №3 «Контекстная приоритизация»
Площадь атаки оценивается с учетом контекста и возможности атаки («атакуемость», хотя такого слова и нет, но почему бы мне его и не придумать). Иными словами, компания начинает думать как атакующий, а не как аудитор. Индикаторы:
✅ Активы классифицированы по критичности.
✅ Учитывается доступность извне.
✅ Используется информация о доступности проэксплуатировать слабое место (PoC, трендовые уязвимости, KEV, TI).
✅ DevOps получает приоритетные задачи, а не «100500 уязвимостей».
❌ Контроль выполнения – в основном ручной.
Быстрый тест. Задайте себе вопрос: «Может ли эта уязвимость быть реально использована в нашей архитектуре?». Если вопрос задается регулярно – вы на третьем уровне.
Уровень №4 «Встроенный процесс»
Управление площадью атаки встроено в ИТ- и DevOps-процессы. В этом случае ИБ не тормозит разработку, а становится ее частью. Индикаторы этого уровня:
✅ Слабые места обнаруживаются автоматически и регулярно.
✅ Приоритизация учитывает бизнес-критичность, доступность, атакуемость, существующие компенсирующие меры.
✅ Результаты интегрированы в backlog DevOps.
✅ Есть SLA/SLO на устранение критичных уязвимостей (в широком смысле).
❌ Проактивное моделирование атак применяется ограниченно.
Быстрый тест. Задайте себе вопрос: «Уязвимости превращаются в понятные задачи для DevOps без участия ИБ вручную?» Если да – вы на четвертом уровне.
Уровень №5 «Управление площадью атаки как риском»
Компания управляет не уязвимостями, а путями атаки и данный процесс становится инструментом управления бизнес-риском. Его индикаторы:
✅ Анализируются цепочки атак, а не отдельные CVE.
✅ Приоритеты определяются по реальному ущербу.
✅ Используются BAS / purple-team-подходы или аналогичные практики.
✅ Решения могут быть: «исправить», «закрыть доступ», «принять риск» (осознанно).
✅ Руководство понимает текущее состояние площади атаки в терминах риска.
Быстрый тест. Задайте себе вопрос: «Какие 3 пути атаки на наш бизнес сейчас самые опасные?» Если на это есть внятный ответ – вы на пятом уровне.
Если совсем кратко, то 5 уровней зрелости процесса управления площадью атаки выглядят так:
- Что у нас вообще есть?
- Какие CVE у нас есть?
- Какие из них реально опасны?
- Как быстро мы их устраняем?
- Что реально угрожает бизнесу?
Эта «модель зрелости» достаточно проста, но показывает поэтапность решения задачи, связанной с оценкой площади атаки и легкость оценки своего текущего уровня, задавая себе достаточно простые вопросы.
Но как и в любой оценке зрелости, саму калькуляцию можно сделать немного иначе, более системно и предсказуемо – с четким перечнем вопросов, присущими им весами и правилами их выбора, с последующим суммированием всех весов.
Но об этом уже в следующей заметке…
