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

Условная ситуация. Небольшая B2B-компания готовится подписать первый крупный корпоративный контракт, и служба безопасности клиента просит «свежий отчёт о тестировании на проникновение». У руководителя разработки на столе три коммерческих предложения. Первое обещает за две недели «проверить приложение на OWASP Top 10». Второе называется red team и почти ничего не говорит о границах работ. Третье перечисляет требования ASVS с номерами версий, оговаривает исключения и включает повторную проверку после исправлений. Все три продаются как услуги наступательной безопасности, и на первый взгляд их легко сравнить по цене и срокам.

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

Что на самом деле покупают под названием «наступательная безопасность»

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

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

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

Наконец, наступательная работа не заменяет безопасной разработки. Инициатива CISA Secure by Design исходит из того, что бремя кибербезопасности слишком часто перекладывается на клиентов и небольшие организации, а производители технологий должны принимать ответственность за безопасность продукта на уровне руководства. Консалтинговый проект приносит больше всего пользы, когда поддерживает эту ответственность: не просто перечисляет ошибки, а объясняет, почему они возникли, и помогает закрыть целые классы дефектов.

Какой вопрос задаёт проект: форматы работ и что они доказывают

Дорогая ошибка при закупке — сравнивать форматы, которые отвечают на разные вопросы. Удобнее начинать не с названия услуги, а с того, какое доказательство вам нужно получить.

Сканирование уязвимостей

Сканирование даёт широкий и повторяемый охват. Оно быстро проходит по множеству активов и сообщает о потенциальных проблемах: устаревших версиях, опасных настройках, известных уязвимостях. Но без дополнительной проверки оно может не показать последствия именно в вашем окружении и может дать ложные срабатывания. Сканирование хорошо подходит для регулярной гигиены и контроля изменений и плохо — для ответа на вопрос «что реально может сделать атакующий».

Тестирование на проникновение

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

Проверка по требованиям ASVS

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

Red team и assume breach

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

Отдельный вариант — оценка в модели assume breach. Она начинается с заранее согласованного состояния компрометации: например, у тестировщика есть учётная запись рядового сотрудника или доступ к одной рабочей станции. Это экономит время и позволяет сосредоточиться на горизонтальном перемещении и эскалации привилегий. Но результат такого проекта не доказывает, что исходный доступ можно было получить извне: это допущение, а не находка. О том, как выбирать стартовую точку и критерии успеха, мы подробно писали в материале об оценке в модели assume breach.

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

Если вопрос звучит как «что из нашего вообще видно из интернета», нужна разведка поверхности атаки: поиск доменов, сервисов, облачных ресурсов, забытых тестовых стендов. Здесь есть важная оговорка. Найденный актив ещё не означает разрешения его тестировать: прежде чем переходить к активным проверкам, нужно подтвердить, что он действительно принадлежит заказчику и что заказчик вправе разрешить работу с ним. Как выстроить такую проверку и расставить приоритеты по находкам, разобрано в статье про оценку внешней поверхности атаки.

Стандарты как общий язык заказчика и подрядчика

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

OWASP WSTG: каталог проверок

OWASP Web Security Testing Guide — по сути, общий каталог тестов для веб-приложений. В этой статье WSTG приводится как версионированный ориентир на примере выпуска 4.2, без утверждения о текущем статусе проекта. Сопоставление методологии с категориями WSTG показывает планируемый охват и исключения для применимой веб-части; фактическое выполнение подтверждают записи о тестах и их результатах. В договоре стоит закрепить выбранный выпуск.

OWASP ASVS: проверяемые требования с версией

ASVS создавался, чтобы выровнять разброс в охвате и строгости проверок безопасности веб-приложений на рынке. В статье используется версия 5.0.0 без утверждения, что она остаётся текущей. Сам стандарт рекомендует ссылаться на требования с префиксом версии, например v5.0.0-1.2.5, потому что нумерация может меняться между выпусками. Для закупки это практичная деталь: версионный идентификатор делает находку прослеживаемой, а повторную проверку — воспроизводимой, даже если её выполняет другой подрядчик.

OWASP Top 10: словарь для руководства

OWASP Top 10 (выпуск 2025 года, предыдущие — 2021 и 2017) задуман как документ для повышения осведомлённости и первый шаг к безопасной разработке. Это удобный язык для разговора с руководством, но не план тестирования. Формулировка «протестировать OWASP Top 10» намного уже и хуже поддаётся проверке, чем охват, привязанный к конкретным тестам WSTG и требованиям ASVS.

NIST SP 800-115: каркас процесса

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

Для специализированных работ этих документов недостаточно. Например, при оценке операционных технологий стоит опираться на отраслевые материалы, в том числе на руководство CISA для владельцев и операторов OT о том, что учитывать при выборе цифровых продуктов, и привлекать отдельную квалифицированную экспертизу.

Где искать в первую очередь: классы слабостей и их первопричины

Опытный консультант не просто перебирает тесты. Он понимает, какие классы слабостей заслуживают особого внимания в вашем стеке, и умеет объяснить находку через её первопричину.

Здесь помогает MITRE CWE Top 25 за 2025 год — рейтинг серьёзных слабостей, стоящих за опубликованными уязвимостями. Важно правильно его читать: CWE классифицирует типы слабостей, а не вероятность эксплуатации в конкретной системе. Высокое место в списке не означает, что такая ошибка у вас есть или что её непременно используют. Для заказчика ценность списка в другом: по нему удобно проверять, объясняет ли отчёт первопричины или только симптомы.

MITRE публикует и связанный список CWE Top 10 KEV Weaknesses, где слабости ранжированы по данным каталога CISA Known Exploited Vulnerabilities, то есть по уязвимостям с зафиксированной эксплуатацией. Это полезный ориентир для приоритизации: он показывает классы слабостей, представленные в каталоге уязвимостей с подтверждённой эксплуатацией. Но сам рейтинг не определяет вероятность эксплуатации конкретной системы.

Материалы CISA Secure by Design указывают в ту же сторону: среди них есть предупреждения о межсайтовом скриптинге, внедрении команд ОС и обходе каталогов, а совместное предупреждение CISA и ФБР посвящено переполнению буфера. ASVS, в свою очередь, содержит требования о защите от внедрения команд ОС. Когда класс слабостей одновременно фигурирует у MITRE, CISA и OWASP и при этом релевантен вашему стеку, его стоит явно назвать в охвате, а не надеяться, что подрядчик проверит его по умолчанию.

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

HTTP-механика, которую консультант должен объяснять разработчикам

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

Два механизма часто становятся источником ошибок конфигурации. Content Security Policy может ограничивать загрузку ресурсов и, при настроенной отчётности, сообщать о нарушениях политики; это дополнительный уровень защиты, а не замена корректному экранированию. CORS определяет, может ли скрипт в браузере прочитать ответ от другого источника, и не является механизмом серверной авторизации. Слишком широкая политика CORS опасна, когда браузер отправляет пригодные учётные данные и политика делает чувствительный ответ читаемым для чужого сайта; строгая политика всё равно не защищает API от прямых запросов. Похожая тонкость есть у заголовка Cross-Origin-Resource-Policy: он может не дать странице получить тело некоторых ответов в режиме no-cors, но не обязательно предотвращает отправку самого запроса. Консультант, который путает эти механизмы с контролем доступа, будет давать ошибочные рекомендации.

Компромиссы, которыми управляет заказчик

Глубина против широты

Узкий и глубокий тест одного критичного приложения может найти цепочки, которые пропустит широкое сканирование. Широкое сканирование, в свою очередь, может найти забытые активы вне границ глубокого теста. SP 800-115 недаром подчёркивает сильные стороны и ограничения каждой техники: ни один метод не даёт полной уверенности, и выбор между ними — управленческое решение.

Реализм против безопасности

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

Разовая проверка против непрерывной уверенности

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

Поиск ошибок против устранения причин

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

Разрешение, правила безопасности и обращение с данными

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

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

Отдельно договаривайтесь о данных. В ходе теста подрядчик может столкнуться с персональными данными, секретами и токенами, даже если их получение не является целью. Разумная практика — собирать в журналы и доказательства минимум необходимого, маскировать секреты, ограничивать доступ к материалам, защищать их целостность и заранее определить срок хранения и порядок удаления. И не стоит считать, что тестовая учётная запись «только на чтение» автоматически безопасна: если через неё видны чужие документы или конфигурации, это уже существенный доступ.

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

Как превратить находки в операционные изменения

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

Приоритет исправления разумно определять не только по метке критичности, но и по эксплуатируемости и доступности извне. Уязвимость средней критичности в публичном API может требовать внимания раньше, чем критичная находка на изолированном внутреннем стенде. Сопоставление с CWE Top 10 KEV Weaknesses и рекомендациями CISA даёт один из входов для приоритизации наряду с возможным ущербом, действующими мерами и применимыми обязательствами.

Некоторые находки указывают не на ошибку конфигурации, а на решение по продукту. Материалы Secure by Design призывают производителей делать базовые функции безопасности, такие как многофакторная аутентификация и журналирование, доступными по умолчанию, а не платным дополнением. Если тест выявляет пробелы именно здесь, исправлять их должна продуктовая команда, а не только администраторы.

Повторная проверка замыкает цикл. Версионные идентификаторы ASVS и ссылки на тесты WSTG позволяют тому же или другому подрядчику проверить исправление по тому же критерию. Списки требований ASVS публикуются в машиночитаемых форматах, включая CSV и JSON, поэтому охват удобно вести в собственных инструментах. Стоит помнить, что вывод повторного теста относится только к указанной области и условиям: если исправили один эндпоинт, это не доказывает, что соседние защищены. Подробнее о том, как доказывать, что исправления действительно работают, — в статье о проверке устранения уязвимостей после пентеста.

Если подрядчик предлагает анализ или отчётность с помощью ИИ, проверяйте это так же строго, как любой другой метод: как люди перепроверяют выводы, куда попадают данные клиента и кто имеет к ним доступ.

Как выбрать подрядчика: проверка методологии и отчёта

Раз ASVS создавался для того, чтобы выровнять неравномерный охват и строгость на рынке, первая проверка при закупке — прозрачность методологии. Попросите показать, как она соотносится с категориями WSTG для веб-работ, с требованиями ASVS там, где нужна проверка выбранных мер приложения, и с процессом, в котором есть планирование, выполнение, анализ результатов и выработка мер.

Второе — отчёт. Сильный отчёт указывает затронутые активы, описывает безопасное воспроизведение, объясняет последствия, называет класс слабости CWE, ссылается на требования с версией и даёт рекомендации, которые разработчик может выполнить. Описаний на сайте недостаточно: запросите обезличенный пример.

Третье — санкционирование и безопасность, о которых шла речь выше. Четвёртое — пользуйтесь существующими руководствами для покупателей. CISA публикует руководство Secure by Demand для заказчиков ПО, ведущих переговоры с поставщиками, и отдельное — для владельцев и операторов OT. Они помогают задавать всем поставщикам одинаковые вопросы. Более подробная схема сравнения предложений — в нашей статье о сравнении подрядчиков по пентесту.

Несколько вопросов быстро отделяют зрелого подрядчика:

• Какие категории WSTG и требования ASVS с версией входят в охват, а какие исключены?
• Как вы сопоставляете находки с классами CWE и что пишете о первопричине?
• Какое разрешение, условия остановки и экстренные контакты вы требуете до начала работ и от кого?
• Входит ли повторный тест и будут ли его результаты ссылаться на те же идентификаторы?
• Можете ли вы показать обезличенный пример отчёта и выдать результаты в машиночитаемом виде?
• Кто именно выполняет работу и как проверяется качество отчёта перед сдачей?

Рабочий цикл: от вопроса до повторной проверки

Формальные фазы SP 800-115 — планирование, выполнение и этап после выполнения — описывают сам процесс оценки. Заказчику полезно дополнить их практическим циклом, который начинается раньше теста и заканчивается позже. Это не требование стандарта, а авторская рабочая схема.

1. Сформулировать вопросРешить, какое доказательство нужно: обнаружения, охвата, доказательств по выбранным мерам защиты или устойчивости к атаке
2. Задать границы и разрешениеЗафиксировать активы, исключения, окна, обращение с данными, условия остановки и разрешение каждой стороны, вправе одобрять тестирование
3. Провести тестированиеВыполнить согласованные проверки и записать условия, при которых подтверждена каждая находка
4. Разобрать первопричиныГде применимо, связать находки с CWE и требованиями веб/API; назначить владельцев исправлений
5. Повторно проверитьПовторить исходный сценарий и релевантные варианты либо обосновать эквивалентную проверку; явно ограничить вывод

Первый шаг важнее, чем кажется. Проект с размытым вопросом рискует закончиться отчётом, по которому невозможно действовать. На втором шаге закрепляется набор ориентиров: для веб-приложения это выпуск WSTG и требования ASVS с версией, для разговора с руководством — OWASP Top 10, для приоритизации — CWE Top 25 и Top 10 KEV, для связи с управлением — профиль CSF 2.0. Для других типов систем набор будет другим.

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

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

Что делает наступательный консалтинг полезным

Наступательный консалтинг полезен, когда он санкционирован всеми, кто вправе его разрешить, опирается на понятные обеим сторонам ориентиры и связан с устранением первопричин. OWASP даёт каталог тестов и проверяемые требования, NIST SP 800-115 — каркас процесса, CWE — язык классов слабостей, а CISA смещает ответственность к безопасному проектированию и осознанным закупкам.

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