Оценка внешней поверхности атаки: методология, приоритизация находок и выбор подрядчика

Что охватывает оценка внешней поверхности атаки

Оценка внешней поверхности атаки — это санкционированный и структурированный анализ всего, что организация выставляет в интернет. Сюда входят домены и поддомены, веб-приложения, API, порталы входа и сетевые сервисы за ними. Цель — найти уязвимые точки раньше злоумышленника, понять, какие из них действительно важны, и превратить результат в план устранения с приоритетами. В статье разобраны границы работ, методы, эталонные стандарты, компромиссы и вопросы к подрядчику. Именно от них зависит, даст ли оценка полезные доказательства или только длинный отчёт.

NIST SP 800-115, Техническое руководство по тестированию и оценке информационной безопасности, задаёт рамку, которая хорошо подходит для внешнего периметра. Документ призван помочь организациям планировать и проводить технические тесты и проверки безопасности, анализировать находки и разрабатывать стратегии устранения. Среди целей прямо названы поиск уязвимостей в системе или сети и проверка соответствия политике или иным требованиям. Обе цели применимы к внешнему периметру. Первая отвечает на вопрос, что можно эксплуатировать. Вторая — совпадает ли реально открытое с тем, что по политике должно быть открыто.

Запросы на эту тему обычно объединяют два вопроса. Первый — из чего на самом деле состоит оценка. Второй — как сравнивать услуги по оценке внешней поверхности атаки и внешнему тестированию на проникновение. Ниже мы сначала полностью отвечаем на первый вопрос и только затем переходим к рекомендациям по выбору подрядчика.

По темеПроцесс управления уязвимостями: как выстроить его на практике

Методология: планирование, тестирование, анализ и устранение

NIST SP 800-115 опубликован в сентябре 2008 года и заменил SP 800-42 2003 года. Несмотря на возраст, его логика остаётся рабочей: планирование, проведение, анализ, устранение. Руководство прямо говорит, что не описывает исчерпывающую программу тестирования. Оно даёт обзор ключевых технических методов, преимуществ и ограничений каждого из них, а также рекомендации по применению. Это полезная оптика: ни один метод в отдельности, будь то сканирование уязвимостей или тестирование на проникновение, не покрывает весь внешний периметр.

Этап планирования для внешней оценки включает письменное разрешение, границы охвата, подтверждение владения активами, окна тестирования, контакты для эскалации и условия остановки работ. Ключевые слова руководства — тестирование на проникновение, оценка рисков, оценка безопасности, сканирование уязвимостей — показывают спектр доступных методов. Обоснованный план фиксирует, какой метод где применяется и почему.

Анализ и устранение имеют смысл, только если каждая находка привязана к владельцу и конкретному исправлению. SP 800-115 соотносится с семействами контролей «Оценка, авторизация и мониторинг», «Оценка рисков», «Приобретение систем и услуг», «Защита систем и коммуникаций» и «Целостность систем и информации». Это сигнал, что результаты должны питать процессы управления, а не только очередь заявок.

Обнаружение активов: построение внешнего реестра

Практичный первый шаг — до любого тестирования сверить то, что организация считает открытым, с тем, что открыто на самом деле. Типичные источники для такой сверки: записи DNS, сертификаты, облачные учётные записи, данные регистраторов, маркетинговые сайты и ресурсы у сторонних хостингов. Расхождения между этими источниками сами по себе информативны.

Подтверждение владения — требование безопасности и законности. Найденные активы, принадлежащие третьим лицам, например хостинг-провайдерам или SaaS-сервисам, нельзя тестировать без разрешения этих лиц. Результаты обнаружения стоит разделить на категории: подтверждено и входит в охват; принадлежит организации, но исключено; владелец неизвестен; актив третьей стороны.

Сам реестр — уже находка. Забытые тестовые стенды, заброшенные поддомены и устаревшие порталы могут оказаться одними из самых значимых результатов, если они находятся вне процессов обновления и мониторинга. Поэтому реестр следует передавать заказчику как отдельный артефакт, а не только как приложение к отчёту.

Уровень HTTP: что проверяется при внешнем анализе

По описанию MDN, HTTP — протокол прикладного уровня с классической клиент-серверной моделью. Он не хранит состояние, хотя cookie добавляют состояние в часть взаимодействий. Протокол расширяем за счёт методов и заголовков. Поэтому веб-экспозиция обычно занимает центральное место во внешней оценке: каждая доступная HTTP-точка раскрывает своё поведение через заголовки, коды ответа, перенаправления и cookie.

MDN описывает механизмы, важные для безопасности. Content Security Policy определяет, какие ресурсы может загружать страница, и помогает обнаруживать и смягчать межсайтовый скриптинг и атаки с внедрением данных. CORS управляет реакцией сайта на межсайтовые запросы. CORP позволяет включить защиту от отдельных запросов из других источников для смягчения спекулятивных атак по побочным каналам. Permissions Policy ограничивает доступ кода сайта к API. Коды ответа сгруппированы в пять классов: информационные, успешные, перенаправления, ошибки клиента и ошибки сервера. Хорошая оценка проверяет согласованность этих механизмов на всех хостах, а не только на главном сайте.

Среди инструментов MDN называет HTTP Observatory — проект, созданный, чтобы помочь разработчикам, системным администраторам и специалистам по безопасности безопасно настраивать сайты. Также упоминаются curl и сетевой монитор Firefox. Пассивный анализ конфигурации малорискован и подходит как базовая линия. Однако он не заменяет санкционированное тестирование приложений.

Приоритизация находок: CWE Top 25 и OWASP Top 10

Список CWE Top 25 за 2025 год выделяет самые серьёзные и распространённые слабости, стоящие за 39 080 записями CVE в наборе данных этого года. MITRE отмечает, что такие слабости часто легко найти и эксплуатировать. Они могут вести к уязвимостям, позволяющим полностью захватить систему, похитить данные или нарушить работу приложений. Для внешней оценки это способ привязать каждую находку к классу первопричины.

CWE также публикует список 2025 CWE Top 10 KEV Weaknesses, который ранжирует активно эксплуатируемые слабости по каталогу KEV агентства CISA. Есть и список «On the Cusp» из 15 дополнительных слабостей, едва не вошедших в Top 25. MITRE указывает, что слабости вроде внедрения команд привлекают внимание противников, и это помогает расставлять приоритеты. Практический вывод: находка, относящаяся к активно эксплуатируемому классу, заслуживает более быстрой обработки, чем теоретический недочёт конфигурации.

Актуальная версия OWASP Top 10 — 2025, предыдущие — 2021 и 2017. Это документ для повышения осведомлённости, отражающий широкий консенсус о самых критичных рисках веб-приложений. Он удобен как общий словарь для отчётов и разговора с руководством. Но это не чек-лист тестирования: эту роль выполняют WSTG и ASVS.

Глубина тестирования: OWASP WSTG и ASVS

OWASP Web Security Testing Guide позиционируется как ведущий ресурс по тестированию безопасности для разработчиков веб-приложений и специалистов по безопасности. Текущий выпуск — v4.2, версия 5.0 находится в разработке. У флагманского проекта 184 участника. Если спросить подрядчика, какую версию WSTG и какие области тестирования он применил, методика становится проверяемой.

OWASP ASVS даёт основу для тестирования технических контролей безопасности веб-приложений и список требований для безопасной разработки. Главная цель проекта — нормализовать разброс охвата и строгости проверок, доступных на рынке, с помощью коммерчески применимого открытого стандарта. Последняя стабильная версия — 5.0.0. Это ровно проблема закупки: две «оценки веба» могут радикально отличаться по глубине.

ASVS рекомендует версионированные идентификаторы требований, например v5.0.0-1.2.5, поскольку номера могут меняться между версиями. Стоит требовать, чтобы отчёт ссылался на требования именно в этом формате. Списки требований доступны в CSV, JSON и других форматах. Это позволяет отслеживать находки и повторные проверки программно.

По темеПовторная проверка после пентеста: методология и практические рекомендации

Компромиссы: непрерывный мониторинг или разовая оценка

Рынок предлагает непрерывное управление внешней поверхностью атаки (EASM) и периодические санкционированные оценки. Автоматическое обнаружение и сканирование дают ширину охвата и частоту. Ручное тестирование даёт глубину, понимание бизнес-логики и подтверждение реальной эксплуатируемости. Акцент NIST SP 800-115 на преимуществах и ограничениях каждого метода поддерживает их сочетание, а не выбор одного.

Автоматика производит ложноположительные и ложноотрицательные результаты, и отчёт без ручной верификации переносит эту нагрузку на заказчика. Активное тестирование боевых систем несёт операционный риск. Его нужно ограничивать окнами, лимитами нагрузки и заранее согласованными условиями остановки. Пассивные методы безопаснее, но видят меньше.

Бюджет всегда выбирает между широким поверхностным и узким глубоким охватом. Решение зависит от числа внешних активов и их критичности. Разумная схема: регулярное автоматизированное обнаружение по всему периметру плюс ручная оценка наиболее критичных приложений и интерфейсов.

Операционные последствия и управление

NIST Cybersecurity Framework 2.0 помогает организациям лучше понимать киберриски и улучшать управление ими. Для этого фреймворк предлагает профили, краткие руководства и информативные ссылки, связывающие ресурсы NIST между собой. Если перенести результаты внешней оценки в профиль CSF, руководство увидит экспозицию как управляемый риск, а не как технический список.

Устранение первопричин важнее точечных исправлений. Инициатива CISA Secure by Design призывает встраивать безопасность в проектирование. Серия её предупреждений посвящена устранению целых классов уязвимостей: межсайтового скриптинга, внедрения команд ОС и обхода каталогов. MITRE отмечает, что понимание первопричин даёт обратную связь в жизненный цикл разработки и помогает устранять целые классы дефектов. Если внешняя оценка находит повторяющийся класс, это сигнал для поставщика продукта или собственной команды разработки.

Рабочий процесс устранения должен включать владельца, срок и повторную проверку, а обнаружение активов — повторяться после изменений инфраструктуры. CISA также публикует обзор уязвимостей за FY24–FY25 с рекомендациями по приоритизации. Его цель — помочь закрыть пробелы в экспозиции и исправить предотвратимые программные ошибки.

Как выбрать услугу оценки внешней поверхности атаки

Руководство CISA Secure by Demand рассчитано на любых заказчиков ПО в ходе закупочных переговоров. Та же логика применима к услугам: требуйте доказательств, а не обещаний. CISA указывает, что продукты должны быть безопасными «из коробки», а MFA, журналирование и SSO должны предоставляться без доплаты. Это полезно проверить и для продуктов, которые оценка обнаружит на вашем периметре. Более 200 производителей ПО подписали обязательство Secure by Design и взяли на себя семь ключевых целей; их отчёты о прогрессе публикуются.

Вопросы, которые стоит задать подрядчику перед подписанием договора; ответы лучше получить письменно, чтобы потом сверить их с фактически выполненной работой:

Тревожные признаки: отчёт — это неотредактированный вывод сканера; владение активами не проверяется; обещается гарантированно полный охват; повторная проверка не предусмотрена.

• Как оформляются письменное разрешение и правила проведения работ, кто вправе остановить тестирование.
• Как подтверждается владение каждым активом и что происходит с активами третьих лиц.
• Какие стандарты и версии применяются: NIST SP 800-115, WSTG v4.2, ASVS 5.0.0 с версионированными идентификаторами.
• Как находки сопоставляются с CWE и как учитываются активно эксплуатируемые классы слабостей.
• Какова доля ручной работы по сравнению с автоматикой и как верифицируются результаты сканеров.
• Включена ли повторная проверка и предоставляются ли результаты в машиночитаемом формате.
• Как хранятся и уничтожаются данные, собранные в ходе оценки.

Практическая схема принятия решений

Ниже — последовательность решений, объединяющая рассмотренные стандарты. Она не заменяет экспертизу, но делает выбор объяснимым для руководства и аудиторов.

Повторяйте цикл с периодичностью, соответствующей скорости изменений вашей инфраструктуры. После крупных релизов, миграций и поглощений внеплановая оценка обычно оправдана.

• Шаг 1: определите цель — поиск уязвимостей, проверка соответствия политике или и то и другое.
• Шаг 2: получите письменное разрешение и зафиксируйте границы, окна и условия остановки.
• Шаг 3: постройте и подтвердите реестр внешних активов с владельцами.
• Шаг 4: выполните базовый анализ конфигурации HTTP на всех хостах.
• Шаг 5: для критичных приложений проведите ручное тестирование по WSTG и ASVS.
• Шаг 6: сопоставьте находки с CWE, поднимите в приоритете активно эксплуатируемые классы.
• Шаг 7: отразите результаты в профиле CSF 2.0, назначьте владельцев, сроки и повторные проверки.

Вывод: как сделать оценку внешней поверхности атаки основой решений

Качественная оценка внешней поверхности атаки начинается с разрешения и реестра активов, опирается на проверяемые стандарты и заканчивается приоритизированным планом устранения с повторной проверкой. NIST SP 800-115 задаёт процесс, MDN описывает механизмы HTTP, OWASP WSTG и ASVS определяют глубину, CWE Top 25 и OWASP Top 10 помогают расставить приоритеты, а CSF 2.0 переводит результат на язык управления рисками.

При выборе услуги сравнивайте не обещания, а методику: версии стандартов, долю ручной верификации, порядок подтверждения владения и формат результатов. Такой подход превращает оценку внешнего периметра из разового отчёта в повторяемый процесс снижения риска.

По темеПостоянная программа пентестов: ресурсы, сроки и ответственность