サードパーティリスク全体管理：実践用語集

サードパーティリスクは署名済みの契約書や完成した質問票で終わりません。「エンドツーエンド」とは、ベンダーリスクをライフサイクルとして扱うことです。つまり、サプライヤーの検討を始めた時点から、関係全体を通じて、アクセス権を取り消すまでの全過程です。ベンダーに関連するほとんどの侵害は、組織が1つのフェーズ（通常はオンボーディング）のみでリスク管理を行い、残りの部分を忘れるために発生します。

エンドツーエンドが実際にカバーする範囲

完全なサードパーティリスク管理プログラムは4つの異なるフェーズに及び、各フェーズには独自のコントロールがあります。

1. デューデリジェンスと選定 - 契約に署名する前に、ベンダーのセキュリティ態勢を評価します。SOC 2レポート、ISO 27001認証、ペネトレーションテスト概要、その独自のサブコントラクター一覧（フォースパーティリスクはここに隠れています）の確認が含まれます。
2. オンボーディングと契約締結 - データ処理条件、侵害通知のタイムライン、監査権条項、アクセススコープを契約自体に定義します。単なるサイド質問票ではなく。
3. 継続的監視 - 継続的または定期的なチェック：攻撃面スキャン、セキュリティレーティングサービス（BitSight、SecurityScorecard）、パッチ適用の頻度確認、サブプロセッサの変更やインシデント発生時の再評価。
4. オフボーディングと終了 - APIキー、VPNアクセス、共有認証情報を取り消し、契約に従ってデータ削除または返却を確認します。

ほとんどのプログラムはステップ1と2では優れていますが、ステップ3と4では弱いです。2022年に低リスクと評価されたベンダーが2024年には未パッチのソフトウェアを実行していることもあり、質問票は1回限りのゲートであったため誰も確認していません。

継続フェーズでプログラムが失敗する理由

オンボーディング質問票はスナップショットです。ベンダーがフォームに記入した日時点でのセキュリティ状況を示しています。攻撃面は毎週変わります。ベンダーの露出したS3バケット、期限切れのTLS証明書、実行中のソフトウェアに新たに公開されたCVE。これらのいずれもポイントインタイム型のSIGまたはCAIQ質問票には表示されません。

エンドツーエンドプログラムはこれを以下で解決します。

• ティアリング - すべてのベンダーに同じレベルの精査が必要なわけではありません。個人識別情報にアクセスできる給与計算プロセッサは、オフィス用品ベンダーよりも深く、より頻繁なレビューが必要です。契約金額ではなく、データ感度とシステムアクセスでティアリングしてください。
• 自動化された攻撃面監視 - ベンダーの公開インフラを継続的にスキャンして、開いているポート、期限切れ証明書、貼り付けサイトでの流出認証情報、露出したクラウドストレージを検出するツール。
• トリガーベースの再評価 - 公開された侵害、買収、大幅な製品変更の直後にベンダーを再レビューします。年次更新サイクルを待たずに。

誰も適切に追跡しないアクセス問題

インシデント事後分析で常に明らかになるギャップがあります。ベンダーは時間とともにアクセスを蓄積し、誰もそれを削減しません。3か月のプロジェクトでVPNアクセスが必要だったコントラクターが、18か月後にも有効な認証情報を保持しています。統合パートナーのAPIキーは初期パイロット後に範囲を制限されることがありません。

エンドツーエンドのリスク管理には、ITアセットリストではなく、ベンダーライフサイクルステータスに紐付けられたアクセスインベントリが必要です。ベンダー関係が終了した場合、誰かがチェックリストを確認する必要があります。SSO/SAMLエントリを取り消し、共有APIキーをローテーション、ファイアウォールとVPCのアローリストから削除、データ破棄証明書を確認します。このステップをスキップすることで、契約終了から何年も経った後に、元ベンダーがインシデントの初期アクセスベクトルになります。

今週から適用できる実践的フレームワーク

サードパーティリスク管理プログラムを構築または監査している場合は、最初にこれらのギャップを確認してください。

• 文書化されたティアリングモデルはあるか、それともすべてのベンダーがアクセスレベルに関係なく同じ質問票を受け取るか。
• 継続的な監視はあるか、それとも更新時のレビューのみか。
• 認証情報取り消しとデータ確認を含む公式なオフボーディングチェックリストはあるか。
• インシデント対応計画は明確にサードパーティ発信のインシデントをカバーしているか。誰が誰に何のタイムフレーム内で通知するかを含めて。
• フォースパーティ（ベンダーのベンダー）を追跡しているか、それとも直接契約でのみ可視性があるか。

NIST SP 800-161やISO 27036などのフレームワークはこれに構造を提供しますが、実際の規律は年に1回のコンプライアンスチェックボックスではなく、継続的なプロセスとして、特定のチームが所有するベンダーリスクを扱うことから来ます。

これをさらに詳しく知るには、Korra StudioのBlue Team内でのベンダーリスクフレームワーク、アクセス制御ライフサイクル管理、インシデント対応計画に関するセグメントをご確認ください。