Пентест для SOC 2: охват, методика и доказательства для аудитора

Условная сцена: B2B-сервис расчёта зарплат для средних компаний проходит первый SOC 2 Type 2. За месяц до конца периода наблюдения крупный потенциальный клиент присылает анкету безопасности, и в ней есть пункт: «Приложите отчёт о тестировании на проникновение систем, входящих в границу вашего отчёта SOC 2». Отчёт у компании есть. Его заказали полгода назад по минимальной цене: подрядчик просканировал маркетинговый сайт и тестовую среду, приложил сорок страниц вывода сканера и выдал «чистое» заключение. Служба безопасности клиента задаёт три вопроса: тестировался ли production-API, через который идут платёжные ведомости; проверялась ли изоляция между клиентами; исправлено ли и перепроверено ли то, что нашли. Честный ответ на все три — нет.

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

Что SOC 2 говорит о пентесте и чего не говорит

SOC 2 — это не сертификация. Организация может получить отчёт SOC 2 по итогам экспертизы (examination), которую проводит независимый аудитор-CPA; отчёт касается мер контроля сервисной организации, относящихся к безопасности, доступности, целостности обработки, конфиденциальности или приватности. Основа — критерии доверия AICPA (Trust Services Criteria) редакции 2017 года с пересмотренными в 2022 году ориентирами (points of focus). Type 1 и Type 2 — типы отчёта, а не уровни зрелости: упрощённо, первый описывает дизайн мер контроля на дату, второй — ещё и их работу в течение периода.

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

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

Охват пентеста по границе системы SOC 2

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

Что перечислить в документе об охвате

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

Отдельный вопрос — среда. Иногда тестировать production рискованно, и работы переносят в staging. Это допустимое решение, но результаты не переносятся на production автоматически: другие конфигурации, флаги функций, секреты, сетевые правила и объёмы данных меняют картину. Если тест идёт в staging, зафиксируйте известные отличия от production и решите вместе с аудитором, какие проверки всё же нужно подтвердить в боевой среде, например внешнюю конфигурацию и заголовки.

Разрешения, правила взаимодействия и чужие платформы

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

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

Позиции атакующего и изоляция арендаторов

Охват определяется не только списком активов, но и тем, с каких позиций ведётся тест. Обычно рассматривают внешнего неаутентифицированного пользователя, аутентифицированного пользователя на каждом значимом уровне привилегий и, для мультиарендных продуктов, пользователя одного арендатора, который пытается добраться до данных другого. Для читателей отчёта SOC 2 последняя позиция часто важнее всего: корпоративного клиента прежде всего волнует, чтобы его ведомости не увидел соседний клиент. Как спроектировать такие проверки для облачного продукта, подробнее разобрано в материале о пентесте для SaaS-компаний.

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

Методология: NIST SP 800-115 и OWASP WSTG

Три фазы оценки по NIST

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

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

Рабочая методика для веб-приложений и API

Для веб-приложений и API детальнее работает OWASP Web Security Testing Guide — флагманский проект OWASP, описывающий тестирование конфигурации, идентификации, аутентификации, авторизации, управления сессиями, валидации ввода, бизнес-логики и клиентской части. Подрядчик должен назвать версию, по которой работает, — например, 4.2, — и показать, как его план тестов с ней соотносится.

Смысл в проверяемости. Закрытый чек-лист подрядчика никто вне его компании изучить не может. Названная и версионированная методика позволяет аудитору, клиенту и вашей команде понять, какие классы проверок были выполнены, а какие сознательно пропущены.

Глубина покрытия: OWASP Top 10, ASVS и классы слабостей CWE

OWASP Top 10 — документ для повышения осведомлённости о наиболее критичных рисках веб-приложений, отражающий широкий консенсус специалистов; OWASP публикует редакции 2025, 2021 и 2017 годов, и в отчёте стоит указывать, по какой из них велась работа. Для пентеста SOC 2 это нижняя граница, а не потолок. Отчёт, который заявляет лишь «покрытие OWASP Top 10», описывает минимальный набор тем, а не глубину проверки.

OWASP ASVS решает другую задачу: он задаёт проверяемые требования к безопасности приложений и выравнивает разброс в строгости проверок на рынке. У каждого требования есть идентификатор, который OWASP рекомендует указывать вместе с версией стандарта, в формате вида v5.0.0-1.2.5: версия, затем глава, раздел и номер требования. Требования публикуются и в машиночитаемых форматах. Для SOC 2 это удобно: находку, привязанную к версионированному требованию, можно сравнить с прошлогодней, отследить в тикетах и проверить без толкований. Оговорка: сопоставление с ASVS уместно там, где требование действительно применимо, и само по себе не доказывает соответствие приложения стандарту.

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

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

Уровень HTTP: сессии, cookie и браузерные политики

Значительная часть веб-тестирования происходит на уровне HTTP. Сам протокол не хранит состояние между запросами: с точки зрения HTTP каждый запрос самодостаточен. Но это не значит, что сессий на сервере быть не может. Обычная схема — сервер хранит данные сессии у себя, а клиенту через заголовок Set-Cookie выдаёт идентификатор, который браузер возвращает в последующих запросах. Альтернатива — самодостаточные подписанные токены, в которых состояние переносит клиент. Обе схемы законны, и у каждой свои точки отказа: предсказуемые или неотзываемые идентификаторы, отсутствие атрибутов Secure, HttpOnly и SameSite, сессия, которая переживает выход из системы или смену пароля, токен, который сервер не проверяет должным образом. Поэтому создание, хранение, завершение и отзыв сессий — центральная область проверки, как и механизмы аутентификации перед доступом к защищённым ресурсам.

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

До платного теста команда может провести предварительную проверку заголовков, например с помощью HTTP Observatory; трудозатраты и покрытие зависят от масштаба и конфигурации системы. Исправление очевидных проблем с заголовками может оставить больше времени оценки для областей, где автоматические инструменты менее надёжны: логики авторизации, изоляции арендаторов и злоупотребления бизнес-процессами. Методика таких проверок подробно разобрана в статье о тестировании безопасности бизнес-логики.

Сканер, чёрный, серый или белый ящик

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

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

Сроки стоит согласовать с аудитором и с графиком релизов. Тест сразу после существенной смены архитектуры, с запасом времени на исправление и ретест до того, как аудитор будет рассматривать доказательства, полезнее, чем тест в случайный момент периода. Если система быстро меняется, имеет смысл дополнять плановые работы точечными тестами изменений; этот подход описан в статье о пентесте, запускаемом изменениями.

От находки к доказательству: отчёт, устранение и ретест

В NIST SP 800-115 анализ находок и рекомендации по устранению входят в фазу пост-выполнения, а не являются необязательным приложением. Для SOC 2 отчёт должен позволять человеку, который не участвовал в работах, понять, что тестировалось, когда, с каких позиций, по какой методике и с каким результатом. У каждой находки — уровень серьёзности, затронутый компонент, классификация CWE там, где она применима, ссылка на версионированное требование ASVS там, где оно уместно, бизнес-влияние и рекомендации. Подтверждение должно быть воспроизводимым и соразмерным находке. При необходимости оно может включать защищённый proof of concept для проверки, но без секретов, лишних персональных данных и неконтролируемого распространения. В журналах и скриншотах токены, пароли и ключи нужно маскировать, персональные данные минимизировать, а сам отчёт хранить с ограниченным доступом и понятным сроком хранения.

Дальше начинается практический цикл, который NIST формально не расписывает, но без которого отчёт мало стоит для аудитора: исправление, перепроверка и запись остаточного риска.

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

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

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

Как выбрать подрядчика для пентеста SOC 2

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

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

К тревожным признакам относятся: нет формального процесса письменных разрешений; методику не называют или называют без версии; нет применимого сопоставления с CWE или требованиями и объяснения неприменимости; ретест не предусмотрен; образец отчёта — очевидный сырой вывод сканера. И самый явный: обещание «гарантировать прохождение SOC 2». Заключение формирует аудитор, и ни один тестировщик не может обещать его исход.

Если вы производитель ПО, пентест — удобный момент проверить продукт на соответствие идеям безопасности по умолчанию, которые продвигает CISA: многофакторная аутентификация, журналирование и единый вход должны быть доступны клиентам без доплаты. Включите в охват принудительность MFA для людей и её устойчивость к обходу, полноту и защищённость журналов, корректность настройки SSO. Учётные данные сервисов и рабочих нагрузок — ключи API, токены интеграций, сервисные аккаунты — проверяются отдельно: MFA к ним не применяется, и вопросы там другие — объём прав, ротация, хранение и отзыв.

Когда граница системы и вопросы аудитора понятны, их можно принести на обсуждение пентеста в Pentest.red: какие активы и роли включить, какие позиции выбрать, как оформить ретест. При этом сам SOC 2 — экспертизу и отчёт — проводит только независимая аудиторская фирма; пентест даёт ей материал, но не заменяет её работу.

Пентест как часть цикла управления рисками

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

На практике последовательность решений выглядит так. Сначала уточните у аудитора, будут ли и как использоваться результаты пентеста и к какому сроку. Затем определите охват по описанию системы: активы, среды, роли, арендаторы, исключения. Перед платным тестом наведите базовую гигиену — заголовки, CSP, CORS, очевидные ошибки конфигурации. Выберите позиции тестирования и запишите обоснование. Выбирайте подрядчика по названной методике с версией, сопоставлению с CWE и ASVS, ретесту и дисциплине разрешений. Проводите работы по письменным правилам взаимодействия. Исправляйте по первопричинам, перепроверяйте, документируйте остаточный риск и передавайте тренды CWE разработке. Наконец, соотнесите результаты с профилем CSF и запланируйте следующий цикл.

Эта последовательность — практическая рекомендация автора, а не требование SOC 2 или NIST. Её смысл в том, чтобы к разговору с подрядчиками вы приходили, зная, что вам нужно, зачем и как вы будете оценивать результат.

Вывод: повторяемый цикл доказательств

Пентест для SOC 2 полезен, когда достигает согласованных целей проекта и создаёт доказательства, которые аудитор может проследить от охвата к методике и от находки к принятому решению. В зависимости от цели это может сочетать поиск реальных слабостей с проверкой выбранных мер контроля или требований. Для этого есть всё необходимое: каркас фаз из NIST SP 800-115, рабочая методика OWASP WSTG, версионированные требования ASVS, классификация CWE для анализа трендов, понимание механизмов HTTP и дисциплина закупок в духе CISA.

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