Риски поставщиков и цепочки поставок: кто что требует

Поставщики стали одним из самых распространённых путей проникновения в организации: от компрометации программных обновлений до взлома провайдеров управляемых услуг. Стандарты отреагировали, одни сильнее других. ControlMapping отслеживает это по двум темам: управление рисками поставщиков (оценка и управление отдельными поставщиками) и риски цепочки поставок (программа, построенная вокруг них).

Управление рисками поставщиков

Полные подробности и обоснование каждой связи: Управление рисками поставщиков по фреймворкам →

Риски цепочки поставок как программа

Полные подробности и обоснование каждой связи: Управление рисками цепочки поставок по фреймворкам →

Где стандарты совпадают

Большинство стандартов требует одного и того же жизненного цикла: знать, кто ваши поставщики, оценивать их до начала работы, включать требования безопасности в контракты, отслеживать их и безопасно завершать отношения. ISO 27001 охватывает это в A.5.19–A.5.22; PCI DSS требует перечня поставщиков услуг, письменных соглашений, due diligence, ежегодного мониторинга и документально закреплённого распределения обязанностей (12.8.1–12.8.5); SOC 2 ожидает, что риски поставщиков будут оцениваться и управляться (CC9.2); CIS Controls требуют инвентаризации, классификации, контрактных требований, оценки, мониторинга и безопасного вывода из эксплуатации (Control 15). Выстройте этот жизненный цикл один раз, и один и тот же процесс будет служить большинству этих стандартов.

Где они расходятся

• GDPR фокусируется на процессорах: письменные договоры с условиями, указанными в статье 28, и использование только тех процессоров, которые дают достаточные гарантии. Речь идёт о персональных данных, а не о поставщиках в целом.
• HIPAA требует соглашений с деловыми партнёрами (§164.308(b)(1), §164.314(a)) со всеми, кто обрабатывает ePHI от вашего имени.
• NIS2 рассматривает безопасность цепочки поставок как самостоятельную меру (статья 21(2)(d)), а Имплементационный регламент требует политики безопасности цепочки поставок, критериев отбора поставщиков и контрактных требований к безопасности (пункты 5.1 и 5.2), с учётом собственных практик безопасности поставщиков и их уязвимостей.
• NIST CSF 2.0 идёт дальше всех: десять подкатегорий функции «Управлять» посвящены управлению рисками кибербезопасности цепочки поставок, от создания программы до управления поставщиками на всём протяжении жизненного цикла.
• CMMC Level 2 не содержит практики для поставщиков; передача требований субподрядчикам осуществляется через пункты контрактов. Essential Eight вопросы поставщиков не затрагивает.

Как выглядит хорошая программа

1. Единый реестр поставщиков с указанием того, к чему каждый поставщик имеет доступ и насколько он критичен.
2. Многоуровневый due diligence: больше проверок для поставщиков с доступом к чувствительным данным или системам, меньше для остальных. Принимайте их отчёт SOC 2 или сертификат ISO, если он охватывает нужную услугу, и читайте область его действия.
3. Требования в контрактах: обязательства по безопасности, уведомление вас о нарушениях, права на аудит и возврат или удаление данных при расторжении (условия статьи 28 GDPR, если затрагиваются персональные данные).
4. Мониторинг, соразмерный уровню поставщика: ежегодные проверки для критичных поставщиков, как того требует PCI DSS от поставщиков услуг.
5. Отключение: отозвать доступ, вернуть или удалить данные и подтвердить это.

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

Вопросы

Что NIS2 требует в отношении безопасности цепочки поставок?

Статья 21(2)(d) требует безопасности цепочки поставок, включая аспекты безопасности во взаимодействии с прямыми поставщиками и поставщиками услуг. Имплементационный регламент устанавливает политику безопасности цепочки поставок, критерии выбора поставщиков и требования к контрактам (пункты 5.1 и 5.2).

Требует ли CMMC Level 2 управления рисками поставщиков?

Не как отдельная программа. CMMC Level 2 наследует SP 800-171 Rev 2, который сосредоточен на защите CUI в собственных системах организации; передача требований субподрядчикам осуществляется через пункты контрактов.