Пентест для подготовки к аудиту: как собрать доказательства, которые выдержат проверку

Представим гипотетическую ситуацию. Компания продаёт B2B-платформу с клиентским порталом и публичным API. Крупный заказчик готовится к собственному аудиту поставщиков и просит показать, как проверены меры защиты, заявленные в анкете безопасности: разграничение доступа между арендаторами, вход через единый вход (SSO) и журналирование административных действий. У компании есть отчёт о пентесте, но ему больше года. Он описывает версию портала до перехода на SSO, а новый биллинговый API в нём не упоминается вовсе. Две находки высокой критичности помечены в трекере как «исправлено», но повторной проверки никто не проводил.

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

Что пентест может дать аудиту и чего не может

Доказательство, а не заключение

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

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

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

Двойное назначение технического тестирования

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

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

От заявленных мер защиты к согласованной области

Карта «мера защиты — система — проверка»

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

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

Подтверждение владения обнаруженной поверхностью атаки

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

Assume-breach: с какой точки начинается тест

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

Роли стандартов в аудиторском пакете

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

NIST SP 800-115 как каркас планирования

Руководство даёт структуру работ: планирование, проведение тестов, анализ находок и стратегии устранения, а также сравнение технических приёмов с их преимуществами и ограничениями. Оно прямо говорит, что не является полной программой тестирования, поэтому организации нужна собственная программа. Обзор техник в нём появился раньше многих современных облачных и API-архитектур. Поэтому разумно использовать его как каркас планирования и отчётности, а конкретные процедуры брать из поддерживаемых материалов OWASP.

WSTG и ASVS: процедура и мерило

OWASP Web Security Testing Guide (WSTG) описывает, как проводить тестирование веб-приложений. OWASP Application Security Verification Standard (ASVS) задаёт, что именно проверяется: это основа для тестирования технических мер защиты веб-приложений и одновременно список требований безопасной разработки. Одна из заявленных целей ASVS — выровнять разброс охвата и строгости проверок, доступных на рынке. Требования ASVS публикуются в машиночитаемых форматах, включая CSV и JSON, поэтому их удобно загрузить в трекер и вести покрытие и находки по идентификаторам. Для обоих документов в отчёте нужно указывать конкретную версию, которая фактически использовалась.

OWASP Top 10, CWE Top 25 и KEV: приоритеты, а не процедура

OWASP Top 10 — документ для повышения осведомлённости, отражающий широкий консенсус о наиболее критичных рисках веб-приложений. Он помогает объяснить риски руководству, но это перечень рисков, а не процедура тестирования. Поэтому утверждение «тест покрывает OWASP Top 10» — более слабое доказательство, чем тест, привязанный к требованиям ASVS и проведённый по WSTG.

MITRE CWE Top 25 ежегодно выделяет самые серьёзные и распространённые слабости, которые часто легко найти и эксплуатировать. Связанный список CWE Top 10 KEV Weaknesses ранжирует активно эксплуатируемые слабости по каталогу CISA Known Exploited Vulnerabilities. Сам MITRE называет понимание эксплуатируемости и приоритизацию рисков среди задач, для которых полезен Top 25. Если отчёт показывает, что тест сосредоточился на классах слабостей из активной эксплуатации, аудитор видит область, выбранную по риску, а не произвольно. Предупреждения CISA Secure by Design о межсайтовом скриптинге, внедрении команд ОС, обходе каталогов и переполнении буфера указывают на те же классы.

CSF 2.0: связь с целевыми результатами

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

Как сделать находки прослеживаемыми

Что должно быть в каждой находке

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

• воспроизводимое описание с датой, условиями и использованной ролью;
• затронутый актив и его версию или окружение;
• сопоставление с идентификатором CWE;
• ссылку на версионированное требование ASVS или иное нарушенное требование;
• обоснование критичности;
• связь с мерой защиты, заявленной аудитору, если такая мера есть.

Отдельно стоит фиксировать, из какой версии WSTG взяты тестовые сценарии и какие классы слабостей сознательно исключены из области и почему. Исключение без объяснения выглядит как пробел, исключение с обоснованием — как осознанное решение. Находки из классов, входящих в список CWE Top 10 KEV, имеет смысл отмечать для приоритетного устранения.

Конфигурация HTTP или подтверждённая эксплуатация

Многие меры защиты веб-систем наблюдаемы на уровне HTTP. MDN описывает HTTP как протокол без сохранения состояния: cookie добавляют состояние в часть взаимодействий, а HTTP-аутентификация проверяет подлинность клиента. Поэтому управление сессиями и аутентификация — естественные цели тестирования. Среди механизмов, которые передаются заголовками ответа, MDN называет Content Security Policy, CORS, CORP и Permissions Policy, а для проверки настроек указывает на свой инструмент HTTP Observatory.

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

Версии в ссылках на требования

ASVS рекомендует указывать версию в идентификаторах требований: идентификатор без версии считается ссылкой на последнюю редакцию, а нумерация между версиями может меняться. Та же логика относится к WSTG, к разным изданиям OWASP Top 10 и к ежегодно обновляемому CWE Top 25. Формулировка «проверено по ASVS» без версии может стать неоднозначной к моменту, когда отчёт прочитает аудитор. Указывайте ту версию, по которой реально работали, а не самую новую на дату чтения отчёта.

Устранение, принятие риска и повторный тест

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

1. НаходкаВоспроизводимое описание, затронутый актив, идентификатор CWE и ссылка на требование с указанием версии
2. Владелец и решениеНазначен ответственный и выбрано исправление или формальное принятие риска со сроком пересмотра
3. ИсправлениеИзменение внесено и связано с номером находки в трекере и с версией системы
4. Повторный тестТот же сценарий повторён на исправленной версии, результат зафиксирован с датой
5. Пакет доказательствНаходка, решение и результат повторного теста собраны в один след для аудитора

Что считается закрытием

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

Сроки относительно полевой части аудита

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

Возраст и пределы исторических доказательств

Что устаревает в старом отчёте

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

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

Изменения, которые требуют новой проверки

Руководство CISA Safe Software Deployment подчёркивает важность надёжного тестирования и измерений в процессе развёртывания. Организациям с частыми релизами приходится объяснять, как уверенность в защите сохраняется между тестами. Это не значит, что каждый коммит требует платного пентеста. Новую ручную проверку оправдывают конкретные изменения, значимые для безопасности: новая схема аутентификации или авторизации, новый внешний интерфейс или API, изменение модели мультиарендности, перенос в другую среду, новая интеграция с доступом к чувствительным данным. Остальные изменения покрываются автоматическими проверками в конвейере и контролем конфигурации. Как сопоставлять изменения с областью тестирования, подробно разобрано в статье о пентесте, запускаемом изменениями.

Выбор техник и среды тестирования

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

Сканирование, ручной пентест и проверка конфигурации

Автоматическое сканирование охватывает много активов и легко повторяется. Ручной пентест исследует бизнес-логику, цепочки проблем и ошибки авторизации, которые сканер обычно не видит. Проверка конфигурации даёт дешёвое и повторяемое доказательство для наблюдаемых настроек. Доказательства сильнее, когда в отчёте сказано, какой подход применялся к какому активу. Покрытие OWASP Top 10 легко объяснить, а сопоставление с ASVS точнее, хотя требует больше усилий.

Продуктив или тестовая среда

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

Контролируемость самих работ

Разрешение и правила проведения работ

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

Условия остановки и обращение с данными

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

Решения покупателя перед заказом теста

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

Вопросы к подрядчику

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

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

Тревожные признаки в отчёте

Некоторые признаки снижают ценность отчёта для аудита, хотя сами по себе не доказывают, что тест был плохим: ссылка только на «OWASP Top 10» без версии и сопоставления с требованиями; отсутствие повторного теста; область в виде одного списка URL без ролей и учётных записей; размытое описание методики; обещания «соответствия» или «отсутствия уязвимостей»; сценарий assume-breach без описанной точки старта. Не принимайте без проверки заявления подрядчика о сертификациях, клиентах или результатах: запрашивайте доказательства и проверяйте их независимо.

Пять вопросов до выделения бюджета

• Что нужно продемонстрировать? Уточните у аудитора, какие системы и меры защиты должны покрывать доказательства и ожидается ли пентест или другой вид оценки.
• Что входит в область? Перечислите приложения, API, среды и роли пользователей и расставьте приоритеты с учётом CWE Top 25 и списка KEV.
• Какое мерило? Версионированные требования ASVS для проверки, WSTG для процедуры и NIST SP 800-115 для структуры планирования и отчётности.
• Какой набор техник? Для каждого актива выберите сканирование, ручное тестирование или проверку конфигурации и зафиксируйте причины.
• Как будет показано закрытие? Назначьте ответственных, настройте принятие рисков и запланируйте повторный тест до полевой части аудита.

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

Повторяемый процесс вместо разового отчёта

Ценность пентеста для аудита — в задокументированном воспроизводимом процессе, а не в разовом отчёте. Планирование по NIST SP 800-115, процедура по WSTG, проверка по версионированным требованиям ASVS, приоритеты по CWE Top 25 и списку KEV, явная область и её пределы, прослеживаемые находки, повторный тест и честное указание возраста доказательств — из этого складывается след, по которому аудитор может пройти.

Организация, которая готовится к аудиту впервые, может начать с узко очерченного теста самых рискованных систем с сопоставлением с ASVS и повторной проверкой. Более зрелая — встроить тестирование в профиль CSF 2.0, связать его с изменениями, значимыми для безопасности, и отслеживать, как меняются классы слабостей от теста к тесту. В обоих случаях пентест остаётся источником доказательств для аудита, а выводы о соответствии делает тот, кто проводит аудит.