Ризик третіх сторін від початку до кінця: практичний глосарій

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

Що насправді охоплює від початку до кінця

Повна програма управління ризиком третіх сторін охоплює чотири окремі фази, кожна з яких має свої контролі:

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

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

Чому програми зазнають невдачі на етапі постійного моніторингу

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

Програми від початку до кінця вирішують це за допомогою:

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

Проблема доступу, яку ніхто добре не відслідковує

Ось прогалина, яка постійно з'являється в аналізі інцидентів: постачальники накопичують доступ з часом, і ніхто його не прибирає. Підрядник, якому потрібен доступ VPN на триденний проект, все ще має дійсні облікові дані вісімнадцять місяців пізніше. API ключ партнера інтеграції ніколи не був обмежений після початкового пілота.

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

Практична схема для застосування цього тижня

Якщо ви будуєте або перевіряєте програму управління ризиком третіх сторін, спочатку перевірте на ці прогалини:

• Чи є задокументована модель рівневої організації, або кожен постачальник отримує одну й ту ж анкету незалежно від рівня доступу?
• Чи у вас є постійний моніторинг, або тільки перегляд під час поновлення?
• Чи існує формальна контрольна списання при відключенні, яка включає скасування облікових даних та підтвердження даних?
• Чи ваш план реагування на інциденти явно охоплює інциденти, що походять від третіх сторін, включаючи, хто кого сповіщає та в якіій часовій рамці?
• Чи ви відслідковуєте четверті сторони (постачальників ваших постачальників), або видимість зупиняється на прямому контракті?

Схеми, такі як NIST SP 800-161 і ISO 27036, дають структуру для цього, але реальна дисципліна походить від рассматривания ризику постачальника як безперервного процесу, на який відповідає певна команда, а не поле для дотримання, заповнене один раз на рік.

Для більшої інформації про розробку цього, перевірте сегменти Korra Studio про основи управління ризиком постачальника, управління життєвим циклом контролю доступу та планування реагування на інциденти в Blue Team.