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

Риск третьих сторон не заканчивается подписанным контрактом или заполненной анкетой. "От начала до конца" означает рассматривать риск поставщика как жизненный цикл: с момента, когда вы рассматриваете поставщика, на протяжении всего взаимодействия и до момента прекращения сотрудничества и отзыва доступа. Большинство взломов, связанных с поставщиками, происходят потому, что организации управляют рисками только на одном этапе (обычно при подключении) и забывают об остальном.

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

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

1. Проверка знаний и выбор — перед подписанием чего-либо оцените позицию безопасности поставщика. Это включает проверку отчетов SOC 2, сертификатов ISO 27001, резюме тестов на проникновение и их собственного списка подподрядчиков (риск четвёртых сторон скрывается здесь).
2. Подключение и контрактация — определение условий обработки данных, сроков уведомления об утечках, пунктов о праве на аудит и объема доступа непосредственно в контракте, а не просто в побочной анкете.
3. Постоянный мониторинг — непрерывные или периодические проверки: сканирование поверхности атак, сервисы оценки безопасности (BitSight, SecurityScorecard), проверка темпа выпуска патчей и переоценка при смене подпроцессоров или инцидентов.
4. Завершение работы и прекращение — отзыв API-ключей, доступа VPN, общих учетных данных и подтверждение удаления или возврата данных согласно контракту.

Большинство программ сильны на этапах 1 и 2 и слабы на этапах 3 и 4. Поставщик, оцененный как низкорискованный в 2022 году, может запускать непропатченное ПО в 2024 году, но никто не проверил, потому что анкета была одноразовым барьером.

Почему этап постоянного мониторинга — это место, где программы дают сбой

Анкеты при подключении — это снимок. Они показывают, как выглядела безопасность поставщика в день заполнения формы. Поверхность атак меняется еженедельно. Открытое S3-хранилище поставщика, просроченный сертификат TLS, недавно раскрытая CVE в используемом ими ПО — ничего этого не отображается в одноточечном анкетировании SIG или CAIQ.

Программы управления от начала до конца решают эту проблему с помощью:

• Ярусности — не каждый поставщик требует одинакового внимания. Обработчик заработной платы с доступом к PII получает более глубокую и частую проверку, чем поставщик офисных принадлежностей. Распределяйте по ярусам в зависимости от чувствительности данных и доступа к системам, а не по стоимости контракта.
• Автоматизированный мониторинг поверхности атак — инструменты, которые постоянно сканируют общедоступную инфраструктуру поставщика на открытые порты, просроченные сертификаты, утекшие учетные данные на сайтах paste и открытое облачное хранилище.
• Переоценка на основе триггеров — повторная проверка поставщика сразу после публичного раскрытия взлома, слияния/поглощения или значительного изменения продукта, а не ожидание цикла ежегодного обновления.

Проблема доступа, которую никто не отслеживает хорошо

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

Управление риском от начала до конца требует инвентаря доступа, связанного со статусом жизненного цикла поставщика, а не просто со списком ИТ-активов. Когда взаимодействие с поставщиком заканчивается, кому-то нужен контрольный список: отзыв записей SSO/SAML, ротация общих API-ключей, удаление из разрешенных списков брандмауэров и VPC, подтверждение сертификатов уничтожения данных. Пропуск этого этапа — это то, как бывшие поставщики становятся начальным вектором доступа в инцидентах через годы после окончания контракта.

Практическая схема для применения на этой неделе

Если вы строите или проверяете программу управления риском третьих сторон, сначала проверьте эти пробелы:

• Есть ли документированная модель ярусности, или каждый поставщик получает одну и ту же анкету независимо от уровня доступа?
• У вас есть постоянный мониторинг или только проверка при обновлении?
• Есть ли официальный контрольный список завершения работы, который включает отзыв учетных данных и подтверждение данных?
• Охватывает ли ваш план реагирования на инциденты инциденты, происходящие от третьих сторон, включая того, кто кого уведомляет и в какие сроки?
• Отслеживаете ли вы четвёртые стороны (поставщиков ваших поставщиков), или видимость заканчивается на прямом контракте?

Такие фреймворки, как NIST SP 800-161 и ISO 27036, обеспечивают структуру, но настоящая дисциплина исходит из рассмотрения риска поставщика как непрерывного процесса, за который отвечает конкретная команда, а не ежегодный флажок соответствия требованиям.

Для получения дополнительной информации ознакомьтесь с сегментами Korra Studio по фреймворкам риска поставщика, управлению жизненным циклом контроля доступа и планированию реагирования на инциденты в Blue Team.