- Регистрация
- 23 Август 2023
- Сообщения
- 3 710
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 243
Offline
Как перейти от отчётов по уязвимостям к проактивному управлению угрозами периметра с приоритизацией по бизнес-контексту
Привет, Хабр! Я Айдар Фатыхов, менеджер продуктов в Innostage.
Хочу разобрать практическую задачу, с которой регулярно сталкиваются ИБ-команды крупных компаний: защита самой горячей точки в инфраструктуре – внешнего сетевого периметра.
Отчёты по уязвимостям растут, поверхность атаки постоянно меняется и увеличивается, рук для закрытия рисков постоянно не хватает и ясного ответа, что закрывать в первую очередь по внешнему периметру нет.
И вроде бы внедряются технические средства, различные сканеры, межсетевые экраны, WAF и другие средства, но во многих случаях проблема не в отсутствии инструментов, а в разрыве между выявленными уязвимостями и бизнес-ценностью активов, фрагментированной работой с данными разных средств защиты, и в отсутствии правильного сведения в единую картину данных от внешних и внутренних сканеров.
Дальше разберу, как подойти к этой задаче с помощью фреймворка CTEM: связать результаты обнаружения с контекстом и телеметрией, получить управляемые приоритеты и доводить устранение до подтверждённого результата через повторную проверку.
Почему именно периметр?
Перед тем, как переходить к методологии, важно зафиксировать, почему внешний периметр почти всегда оказывается в фокусе.
Периметр меняется быстрее всего. Появляются новые сервисы, конфигурации правятся, порты открываются и закрываются, где-то всплывают временные стенды и пилоты. И значительная часть рисков возникает именно на стыке изменений и контроля.
По итогам 1-го полугодия 2025 года наши эксперты Innostage SOC CyberART зафиксировали рост OSINT-инцидентов на 50% почти до 10 тысяч. При этом более 70% таких инцидентов было связано с изменениями на периметре: открытие портов, смена конфигураций сервисов, появление новых ресурсов или изменения сведений о существующих. Это важный сигнал: периметр часто уязвим не только из-за конкретной уязвимости, а из-за неуправляемых изменений и слабого контроля того, что именно и как выставлено наружу.
Параллельно внешний контур испытывает постоянное давление. В 1 квартале 2025 года, по открытым данным, на сайты российских компаний пришлось 801,2 млн веб-атак, а сканирования в поисках уязвимостей выросли до 678 млн и составили 84% всех веб-атак. На практике это означает простую вещь: то, что доступно извне, будут регулярно проверять, и любое уязвимое место рано или поздно попадёт в поле зрения.
Если смотреть на это вместе, получается простая картина: внешний периметр одновременно быстро меняется, постоянно проверяется атакующими и регулярно становится точкой входа в реальных инцидентах. Значит, для него недостаточно периодических отчётов и разовых кампаний по устранению. Нужен непрерывный управляемый цикл, который успевает за изменениями, фокусирует команду на устранение самых приоритетных угроз и обеспечивает контроль их устранения. Именно под такую задачу подходит CTEM.
Что такое CTEM и почему он хорошо ложится на периметр?
Continuous Threat Exposure Management, CTEM — это методология для непрерывного выявления, оценки и устранения угроз в цифровых активах компании.
Gartner описывает CTEM как 5 последовательных шагов: Scoping, Discovery, Prioritization, Validation, Mobilization.
● Scoping - определение границ
● Discovery - сбор данных
● Prioritization - расстановка приоритетов
● Validation- подтверждение применимости и снижение доли ложных срабатываний (FP)
● Mobilization - доведение до изменений и контроль
Методология СТЕМ фокусируется на непрерывной работе с угрозами, а не на механическом устранении уязвимостей.
CTEM как процесс: что делать на каждом шаге
1. Scoping: определяем границы
Результат шага - прозрачная и актуальная картина того, что мы должны защитить: что входит в контур, к каким бизнес-системам относятся периметральные активы и кто отвечает за изменения. На этом этапе:
1) Определяется, какие типы активов включаем в область охвата, например: веб, домены, VPN, публичные API, почтовые компоненты;
2) Вводятся критерии критичности и формируется шкала скоринга;
3) Определяются владельцы сервисов;
4) Моделируются угрозы и выделяются основные бизнес-риски;
5) Задается периодичность цикла сканирования (например, еженедельно/раз в две недели) и правила обработки исключений
2. Discovery: собираем экспозицию
Результат шага - разносторонний взгляд на нашу инфраструктуру: сбор актуальных данных по внешнему и внутреннему сканированию, данные по разведке TI/OSINT, обогащение уязвимостей информацией из внешних аналитических систем. На этом этапе:
1) Актуализируются данные по активам, легитимно размещенным на периметре, актуализируется состав этих активов и собираются обновленные данные от сканеров уязвимостей;
2) Формируется перечень теневых активов (Shadow IT) - новые хосты, порты, сервисы. Уточняется легитимность их размещения на периметре Организации: появились ли они в результате ошибки или недосмотра ИТ команды, или, быть может, являются индикатором активности злоумышленника;
3) Выполняется сканирование теневых и легитимных активов на наличие уязвимостей;
4) Инфраструктура злоумышленника обогащается данными от киберразведки: определяются фишинговые домены и инфраструктура, нацеленные на организацию, fake-boss аккаунты, индикаторы компрометации, отраслевой контекст и APT.
3. Prioritization: анализируем и приоритизируем задачи
Результат шага - не отчёт об уязвимостях на десятки тысяч строк, а список первоочередных задач в рамках одной итерации, который реально выполнить. На данном шаге происходит приоритезация актуальных угроз по критичности бизнес-активов, с учетом данных от внешних и внутренних источников, данных киберразведки.
Практическая модель приоритизации в CTEM для внешнего периметра затрагивает три слоя.
Приоритет уязвимости = технический контекст + бизнес-контекст + телеметрия
1. Технический контекст уязвимости
● CVSS и тип уязвимости
● наличие рабочего эксплойта
● актуальность по TI и OSINT,
● эксплуатируется ли уязвимость сейчас
2. Бизнес-контекст уязвимости
● место выявления: внешний периметр, DMZ, внутренний сегмент, облако, инфраструктура подрядчика;
● доступность: напрямую из интернета, через VPN, только из внутренних сетей
● критичность: какой бизнес-сервис поддерживает уязвимый актив;
● наличие компенсирующих мер: ограничения доступа, изоляция, дополнительный контроль и т.д.
3. Телеметрия
● признаки подготовительной активности атакующих (сканирование, сбор сведений о сервисе);
● попытки эксплуатации уязвимости;
● повторяемость сигналов;
● связанные инциденты и алерты (если они есть).
Смысл подобных моделей в том, что одинаковая уязвимость с одинаковым CVSS может получать разный приоритет в зависимости от доступности сервиса, его критичности и текущей активности вокруг него.
4. Validation: подтверждаем применимость и снижаем долю FP
Цель - сэкономить время команды на анализе ложноположительных и спорных записей.
В этих целях оценивается для высокоприоритетных уязвимостей:
● достижимость уязвимости и доступность эксплойта;
● актуальность версии программного обеспечения, фактическая конфигурация актива;
● наличие условий для эксплуатации уязвимости и компенсирующих мер.
Опциональным шагом на данном этапе является использование BAS (Breach and Attack Simulation) для безопасного подтверждения отдельных сценариев эксплуатации уязвимости злоумышленником.
5. Mobilization: доводим до изменений и проверяем закрытие
Результат шага – сформированные рекомендации, выполненные изменения и подтверждение, что риск реально снижен:
● формирование детализированных рекомендаций по устранению угрозы с плейбуками;
● постановка задач в ITSM с определенным владельцем и зафиксированным сроком исполнения;
● контроль выполнения задач по анализу и устранению угроз, отслеживание SLA;
● повторная проверка, что угроза действительно устранена или закрыта компенсирующей мерой.
Минимальный набор классов инструментов для CTEM на периметре
Если CTEM в вашей компании работает успешно, у вас появляются три основных артефакта, обновляемые в непрерывном, цикличном режиме:
● актуальный перечень внешних активов и возможность контроля за появлением Shadow IT;
● управляемый бэклог задач с приоритетом по модели 3 слоёв;
● контроль закрытия: задача → изменение → повторная проверка.
Эти артефакты важны тем, что они делают процесс воспроизводимым. Приоритеты становятся объяснимыми и повторяемыми в разных командах и филиалах.
Метрики, которые показывают прогресс
Чтобы не скатиться в гонку за количеством строк в отчёте, полезно измерять не объём найденного, а управляемость и эффект.
Подходящие метрики:
- время закрытия топ угроз на периметре;
- доля задач, закрытых с повторной проверкой;
- скорость постановки на контроль новых внешних активов, найденных ASM.
Эти метрики показывают, что CTEM - не про то, чтобы выявлять больше угроз. Это про то, чтобы стабильно выбирать приоритеты и доводить устранение угроз до подтверждённого результата.
На внешнем периметре обычно не хватает не сканирования и не очередного отчёта. Не хватает связки трёх вещей в одном процессе: что реально доступно извне, что по этому периметру выявлено, и что по этому поводу видно в телеметрии. Пока эти части живут по-отдельности в разных источниках данных, приоритеты угроз получаются нестабильными, а закрытие превращается в формальную простановку статусов.
CTEM помогает собрать это в рабочую схему. Результат, к которому имеет смысл стремиться, выглядит так:
● есть актуальный список легитимных внешних сервисов с определенными владельцами и критичностью;
● есть короткий список уязвимых мест на итерацию обработки, где приоритет объясним провалидированными угрозами;
● есть контроль закрытия по факту через повторную проверку.
Если делать это непрерывно, объём выявленного перестаёт быть проблемой: вы понимаете, что закрываете сейчас, почему именно это, и какой эффект в итоге получите.
Привет, Хабр! Я Айдар Фатыхов, менеджер продуктов в Innostage.
Хочу разобрать практическую задачу, с которой регулярно сталкиваются ИБ-команды крупных компаний: защита самой горячей точки в инфраструктуре – внешнего сетевого периметра.
Отчёты по уязвимостям растут, поверхность атаки постоянно меняется и увеличивается, рук для закрытия рисков постоянно не хватает и ясного ответа, что закрывать в первую очередь по внешнему периметру нет.
И вроде бы внедряются технические средства, различные сканеры, межсетевые экраны, WAF и другие средства, но во многих случаях проблема не в отсутствии инструментов, а в разрыве между выявленными уязвимостями и бизнес-ценностью активов, фрагментированной работой с данными разных средств защиты, и в отсутствии правильного сведения в единую картину данных от внешних и внутренних сканеров.
Дальше разберу, как подойти к этой задаче с помощью фреймворка CTEM: связать результаты обнаружения с контекстом и телеметрией, получить управляемые приоритеты и доводить устранение до подтверждённого результата через повторную проверку.
Почему именно периметр?
Перед тем, как переходить к методологии, важно зафиксировать, почему внешний периметр почти всегда оказывается в фокусе.
Периметр меняется быстрее всего. Появляются новые сервисы, конфигурации правятся, порты открываются и закрываются, где-то всплывают временные стенды и пилоты. И значительная часть рисков возникает именно на стыке изменений и контроля.
По итогам 1-го полугодия 2025 года наши эксперты Innostage SOC CyberART зафиксировали рост OSINT-инцидентов на 50% почти до 10 тысяч. При этом более 70% таких инцидентов было связано с изменениями на периметре: открытие портов, смена конфигураций сервисов, появление новых ресурсов или изменения сведений о существующих. Это важный сигнал: периметр часто уязвим не только из-за конкретной уязвимости, а из-за неуправляемых изменений и слабого контроля того, что именно и как выставлено наружу.
Параллельно внешний контур испытывает постоянное давление. В 1 квартале 2025 года, по открытым данным, на сайты российских компаний пришлось 801,2 млн веб-атак, а сканирования в поисках уязвимостей выросли до 678 млн и составили 84% всех веб-атак. На практике это означает простую вещь: то, что доступно извне, будут регулярно проверять, и любое уязвимое место рано или поздно попадёт в поле зрения.
Если смотреть на это вместе, получается простая картина: внешний периметр одновременно быстро меняется, постоянно проверяется атакующими и регулярно становится точкой входа в реальных инцидентах. Значит, для него недостаточно периодических отчётов и разовых кампаний по устранению. Нужен непрерывный управляемый цикл, который успевает за изменениями, фокусирует команду на устранение самых приоритетных угроз и обеспечивает контроль их устранения. Именно под такую задачу подходит CTEM.
Что такое CTEM и почему он хорошо ложится на периметр?
Continuous Threat Exposure Management, CTEM — это методология для непрерывного выявления, оценки и устранения угроз в цифровых активах компании.
Gartner описывает CTEM как 5 последовательных шагов: Scoping, Discovery, Prioritization, Validation, Mobilization.
● Scoping - определение границ
● Discovery - сбор данных
● Prioritization - расстановка приоритетов
● Validation- подтверждение применимости и снижение доли ложных срабатываний (FP)
● Mobilization - доведение до изменений и контроль
Методология СТЕМ фокусируется на непрерывной работе с угрозами, а не на механическом устранении уязвимостей.
CTEM как процесс: что делать на каждом шаге
1. Scoping: определяем границы
Результат шага - прозрачная и актуальная картина того, что мы должны защитить: что входит в контур, к каким бизнес-системам относятся периметральные активы и кто отвечает за изменения. На этом этапе:
1) Определяется, какие типы активов включаем в область охвата, например: веб, домены, VPN, публичные API, почтовые компоненты;
2) Вводятся критерии критичности и формируется шкала скоринга;
3) Определяются владельцы сервисов;
4) Моделируются угрозы и выделяются основные бизнес-риски;
5) Задается периодичность цикла сканирования (например, еженедельно/раз в две недели) и правила обработки исключений
2. Discovery: собираем экспозицию
Результат шага - разносторонний взгляд на нашу инфраструктуру: сбор актуальных данных по внешнему и внутреннему сканированию, данные по разведке TI/OSINT, обогащение уязвимостей информацией из внешних аналитических систем. На этом этапе:
1) Актуализируются данные по активам, легитимно размещенным на периметре, актуализируется состав этих активов и собираются обновленные данные от сканеров уязвимостей;
2) Формируется перечень теневых активов (Shadow IT) - новые хосты, порты, сервисы. Уточняется легитимность их размещения на периметре Организации: появились ли они в результате ошибки или недосмотра ИТ команды, или, быть может, являются индикатором активности злоумышленника;
3) Выполняется сканирование теневых и легитимных активов на наличие уязвимостей;
4) Инфраструктура злоумышленника обогащается данными от киберразведки: определяются фишинговые домены и инфраструктура, нацеленные на организацию, fake-boss аккаунты, индикаторы компрометации, отраслевой контекст и APT.
3. Prioritization: анализируем и приоритизируем задачи
Результат шага - не отчёт об уязвимостях на десятки тысяч строк, а список первоочередных задач в рамках одной итерации, который реально выполнить. На данном шаге происходит приоритезация актуальных угроз по критичности бизнес-активов, с учетом данных от внешних и внутренних источников, данных киберразведки.
Практическая модель приоритизации в CTEM для внешнего периметра затрагивает три слоя.
Приоритет уязвимости = технический контекст + бизнес-контекст + телеметрия
1. Технический контекст уязвимости
● CVSS и тип уязвимости
● наличие рабочего эксплойта
● актуальность по TI и OSINT,
● эксплуатируется ли уязвимость сейчас
2. Бизнес-контекст уязвимости
● место выявления: внешний периметр, DMZ, внутренний сегмент, облако, инфраструктура подрядчика;
● доступность: напрямую из интернета, через VPN, только из внутренних сетей
● критичность: какой бизнес-сервис поддерживает уязвимый актив;
● наличие компенсирующих мер: ограничения доступа, изоляция, дополнительный контроль и т.д.
3. Телеметрия
● признаки подготовительной активности атакующих (сканирование, сбор сведений о сервисе);
● попытки эксплуатации уязвимости;
● повторяемость сигналов;
● связанные инциденты и алерты (если они есть).
Смысл подобных моделей в том, что одинаковая уязвимость с одинаковым CVSS может получать разный приоритет в зависимости от доступности сервиса, его критичности и текущей активности вокруг него.
4. Validation: подтверждаем применимость и снижаем долю FP
Цель - сэкономить время команды на анализе ложноположительных и спорных записей.
В этих целях оценивается для высокоприоритетных уязвимостей:
● достижимость уязвимости и доступность эксплойта;
● актуальность версии программного обеспечения, фактическая конфигурация актива;
● наличие условий для эксплуатации уязвимости и компенсирующих мер.
Опциональным шагом на данном этапе является использование BAS (Breach and Attack Simulation) для безопасного подтверждения отдельных сценариев эксплуатации уязвимости злоумышленником.
5. Mobilization: доводим до изменений и проверяем закрытие
Результат шага – сформированные рекомендации, выполненные изменения и подтверждение, что риск реально снижен:
● формирование детализированных рекомендаций по устранению угрозы с плейбуками;
● постановка задач в ITSM с определенным владельцем и зафиксированным сроком исполнения;
● контроль выполнения задач по анализу и устранению угроз, отслеживание SLA;
● повторная проверка, что угроза действительно устранена или закрыта компенсирующей мерой.
Минимальный набор классов инструментов для CTEM на периметре
Учёт активов, информационных систем и сервисов
Минимум: актив, владелец, среда (прод или тестовая), сетевой сегмент, критичность.
ASM для сканирования внешнего контура
Чтобы видеть, что реально выставлено наружу и потенциально доступно злоумышленнику, или создано им: домены, поддомены, публичные IP, сервисы, теневые активы.
VM для выявления уязвимостей и ошибок конфигурации
Чтобы получать результаты сканирования активов «изнутри».
Телеметрия периметра и SIEM
Логи WAF, межсетевых экранов, VPN, прокси плюс корреляция и хранение в SIEM.
TI и OSINT
Чтобы отделять множество второстепенных задач от тех, что актуальны с точки зрения эксплуатации злоумышленником прямо сейчас.
ITSM (IT Service Management, управление ИТ-услугами) или тикет-система
Чтобы задачи реально доходили до изменений и контроля закрытия.
Если CTEM в вашей компании работает успешно, у вас появляются три основных артефакта, обновляемые в непрерывном, цикличном режиме:
● актуальный перечень внешних активов и возможность контроля за появлением Shadow IT;
● управляемый бэклог задач с приоритетом по модели 3 слоёв;
● контроль закрытия: задача → изменение → повторная проверка.
Эти артефакты важны тем, что они делают процесс воспроизводимым. Приоритеты становятся объяснимыми и повторяемыми в разных командах и филиалах.
Метрики, которые показывают прогресс
Чтобы не скатиться в гонку за количеством строк в отчёте, полезно измерять не объём найденного, а управляемость и эффект.
Подходящие метрики:
- время закрытия топ угроз на периметре;
- доля задач, закрытых с повторной проверкой;
- скорость постановки на контроль новых внешних активов, найденных ASM.
Эти метрики показывают, что CTEM - не про то, чтобы выявлять больше угроз. Это про то, чтобы стабильно выбирать приоритеты и доводить устранение угроз до подтверждённого результата.
На внешнем периметре обычно не хватает не сканирования и не очередного отчёта. Не хватает связки трёх вещей в одном процессе: что реально доступно извне, что по этому периметру выявлено, и что по этому поводу видно в телеметрии. Пока эти части живут по-отдельности в разных источниках данных, приоритеты угроз получаются нестабильными, а закрытие превращается в формальную простановку статусов.
CTEM помогает собрать это в рабочую схему. Результат, к которому имеет смысл стремиться, выглядит так:
● есть актуальный список легитимных внешних сервисов с определенными владельцами и критичностью;
● есть короткий список уязвимых мест на итерацию обработки, где приоритет объясним провалидированными угрозами;
● есть контроль закрытия по факту через повторную проверку.
Если делать это непрерывно, объём выявленного перестаёт быть проблемой: вы понимаете, что закрываете сейчас, почему именно это, и какой эффект в итоге получите.
