Оценка рисков третьих сторон: как проверить безопасность поставщика и SaaS

Анкета от поставщика пришла через три дня. Двести с лишним вопросов, почти везде «да»: шифрование есть, многофакторная аутентификация есть, «регулярные пентесты проводятся». К анкете приложено резюме отчёта о тестировании на две страницы. Отдел закупок доволен: формально всё готово, можно подписывать.

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

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

Что на самом деле проверяет оценка рисков третьих сторон

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

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

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

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

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

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

Есть и следующее звено цепочки. CISA называет открытое ПО частью фундамента цифровой инфраструктуры, а руководство агентства по безопасности памяти предлагает производителям учитывать эту проблему и во внешних зависимостях. У вашего поставщика есть свои поставщики — хостинг, библиотеки, подрядчики поддержки. Оценка, которая останавливается на первом звене, видит лишь часть картины. Систематически эту тему разбирает NIST SP 800-161 Rev. 1, посвящённый практикам управления рисками кибербезопасности в цепочке поставок для систем и организаций. Подробнее о проверке зависимостей, сборки и происхождения компонентов — в материале об оценке безопасности цепочки поставок ПО.

На какие документы опираться и для чего нужен каждый

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

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

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

Для веб-приложений и SaaS OWASP предлагает три слоя разного назначения. OWASP Top 10 — документ для повышения осведомлённости о наиболее критичных рисках; существуют выпуски 2017, 2021 и 2025 годов, и в записях важно указывать, на какой из них вы ссылаетесь. Стандарт ASVS (версия 5.0.0) задаёт проверяемые требования к мерам защиты и прямо ставит целью выровнять охват и строгость проверок на рынке. Руководство WSTG описывает, как именно тестировать; в этом примере используется WSTG 4.2, а в каждом отчёте нужно фиксировать версию, которой действительно пользовались.

Материалы CISA добавляют позицию покупателя. Руководство Secure by Demand предназначено для переговоров о закупке ПО с поставщиками и реселлерами; отдельная версия адресована владельцам и операторам операционных технологий. CISA вместе с австралийским ASD's ACSC выпустило также руководство по выбору безопасных и проверяемых технологий. Это не стандарты соответствия, а наборы вопросов, которые помогают превратить абстрактную «безопасность» в конкретные пункты переговоров.

Уровни поставщиков и лестница доказательств

Как ранжировать поставщиков

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

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

Лестница доказательств

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

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

Как спланировать техническую часть и не выйти за чужие границы

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

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

Разрешение на тестирование

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

Что можно увидеть без вмешательства

Часть сигналов доступна при обычном легитимном использовании продукта. MDN описывает механизмы безопасности HTTP: Content Security Policy, которая помогает обнаруживать и смягчать межсайтовый скриптинг и внедрение данных, CORS, Cross-Origin Resource Policy, Permissions Policy, атрибуты cookie. Взгляд на заголовки, которые возвращает приложение поставщика в ходе обычной работы с ним, — дешёвый индикатор аккуратности конфигурации. Именно индикатор: отсутствие заголовка не доказывает уязвимость, а его наличие не доказывает защищённость. И это не замена разрешённому тестированию: перебор адресов, подбор параметров и сканирование уже являются вмешательством.

Какие технические доказательства запросить у поставщика

Версионированные требования вместо «мы следуем OWASP»

ASVS делает заявления точными. У каждого требования есть числовой идентификатор, а поскольку идентификаторы могут меняться между версиями, OWASP рекомендует версионированную запись, например v5.0.0-1.2.5 — пятое требование раздела о предотвращении инъекций в главе о кодировании и санитизации версии 5.0.0. Если попросить поставщика указать охват тестирования в виде таких идентификаторов, расплывчатое «мы следуем лучшим практикам OWASP» исчезает. Требования ASVS публикуются в машиночитаемых форматах, включая CSV и JSON, поэтому анкету можно строить и обрабатывать программно и сравнивать ответы разных поставщиков.

Вопросы о классах слабостей

Вопрос «у вас безопасно?» почти бесполезен. Вопрос «какие классы слабостей вы исключили архитектурно и как это проверяете?» даёт материал для оценки. MITRE позиционирует CWE Top 25 как обратную связь для жизненного цикла разработки и архитектурного планирования, нацеленную на устранение целых классов дефектов вроде ошибок памяти и инъекций. Оповещения CISA Secure by Design посвящены устранению межсайтового скриптинга, внедрения команд ОС, обхода каталогов и переполнения буфера. Хороший ответ поставщика звучит конкретно: шаблонизатор с автоматическим экранированием по умолчанию, отказ от вызова оболочки ОС с пользовательскими данными, запрет произвольных путей к файлам, язык с безопасной работой с памятью для новых компонентов — и способ, которым всё это контролируется в сборке и ревью.

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

Защита по умолчанию и её цена

CISA настаивает, что продукты должны быть безопасны «из коробки», а базовые защитные функции, такие как многофакторная аутентификация, журналирование и единый вход, не должны продаваться за доплату. Это легко проверить по прайс-листу. Если журналы аудита и единый вход доступны только на корпоративном тарифе, а вы покупаете базовый, вы покупаете продукт без возможности расследовать инцидент.

Ваша сторона интеграции

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

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

Как читать отчёт о пентесте поставщика

Независимый отчёт добавляет наблюдения о проведённом тесте, тогда как анкета фиксирует заявления; уверенность в выводе зависит от рамок, доступа, метода, компетентности и даты каждого доказательства. Ссылка на WSTG или SP 800-115 и сопоставление с ASVS помогают, но сами по себе глубину не доказывают. Читать нужно не титульный лист, а рамки, даты, находки и судьбу этих находок.

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

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

Анкета, отчёт или собственный тест: где компромисс

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

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

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

Наконец, любая отдельная оценка — снимок. Продукты меняются, перечень CWE Top 25 обновляется, стандарты выходят в новых версиях. Программа без повторных оценок постепенно расходится с реальным риском, даже если при первой проверке всё было сделано правильно.

Непрерывная программа управления рисками поставщиков

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

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

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

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

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

Договор и закупка: где у заказчика реальный рычаг

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

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

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

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

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

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

Решение по итогам оценки и что делает его обоснованным

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

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

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