現在のデジタル環境において、サプライチェーンの保護はサイバーセキュリティ防御と密接に関連しています。組織がニーズを満たすために外部ベンダーやサードパーティ製ソフトウェアに依存する度合いが高まるにつれ、組織の壁の外側でまったく新しいリスク群に直面しています。そして、こうしたサプライチェーンリスクは、ソフトウェア設計から展開済みソフトウェア製品に至るまで、企業内のあらゆる要素に影響を及ぼし得る。
本ブログでは、サプライチェーンリスク管理の概念とサイバーセキュリティにおけるその役割について学ぶ。また、一般的なリスクの特定方法、効果的な評価手法の開発方法、堅牢なセキュリティ戦略の確立方法についても議論する。さらに、サプライチェーンのセキュリティを確保するために組織が活用できる主要なフレームワーク、業界固有のユースケース、その他のベストプラクティスについても議論します。
サプライチェーンリスク管理とは
サプライチェーンリスク管理（SCRM）とは、組織が外部パートナー、ベンダー、サービスプロバイダーに関連するリスクを認識、評価、最小化するための一連の行動とプロセスです。製品やサービスを提供するデジタル要素も含まれます。
サプライチェーンリスク管理は、組織環境に入る前に様々な構成要素の脆弱性をスキャンします。また、後で発生する可能性のある潜在的な問題を検出するための監視体制を確立します。このアプローチは、外部世界と内部システムの接触点すべてにおけるセキュリティを目指しています。
SCRMを効果的にするには、セキュリティ、IT、調達、法務、ビジネスチームがすべて連携する必要があります。この部門横断的なアプローチにより、ベンダー関係の選定から契約管理、定期的なセキュリティレビューに至るまでの、セキュリティリスクの全範囲を確実にカバーします。
サプライチェーンリスク管理が重要な理由とは？
組織が外部ベンダーやサードパーティライブラリへの依存度を高める現代において、サプライチェーンリスク管理の重要性は増しています。今日、ほとんどの企業は、事業運営を支援する数十から数百ものサードパーティと関係を持っています。あらゆる関係にはセキュリティリスクが伴い、組織のセキュリティ態勢を変える可能性があります。
現代のソフトウェアアプリケーションの多くは、様々なソースからのコンポーネントで構成されています。ビジネスアプリケーションのコードには通常、数十ものサードパーティライブラリやフレームワークが含まれています。これらのコンポーネントのいずれかにセキュリティ脆弱性が存在する場合、アプリケーション全体が侵害される可能性があります。この依存関係の問題は、クラウドサービス、マネージドプロバイダー、ハードウェアサプライヤーにも適用されます。
サプライチェーンリスクの一般的な種類
サプライチェーンリスクは、侵害されたソフトウェア、サービス攻撃、内部関係者、サードパーティアクセスなどの形で発生し、それぞれ独自の検出および保護方法が必要です。最も一般的なタイプは次のとおりです。
コードインジェクション攻撃
コードインジェクション攻撃では、攻撃者が開発中または配布中に正当なソフトウェアに悪意のあるコードを挿入します。これは、攻撃者がソースコードリポジトリ、ビルドシステム、または更新サーバーへのアクセス権を取得した場合に発生する可能性があります。よく知られている例としては、SolarWinds 攻撃が挙げられます。この攻撃では、バックドア用のコードがソフトウェアアップデートに挿入され、何千もの顧客に配信されました。
侵害されたソフトウェア
もう 1 つの重大なリスクは、侵害されたソフトウェアコンポーネントに起因します。オープンソースライブラリは開発を加速させ、多くの開発者に広く利用されていますが、脆弱性や悪意のあるコードを内包している可能性もあります。こうした欠陥のある部品がアプリケーションに組み込まれると、セキュリティ上の欠陥も引き継がれます。
ベンダーのセキュリティ侵害
ベンダーのセキュリティ侵害は、組織のシステムやデータにアクセス権を持つサプライヤーがセキュリティインシデントを経験した場合にリスクをもたらします。ネットワークや機密情報へのアクセス権を持つ者が侵害されると、攻撃者はこの関係を悪用し、顧客環境へ横方向に移動することが可能になります。
ハードウェア改ざん
ファームウェアのサプライチェーン攻撃は、ハードウェアコンポーネントに組み込まれたソフトウェアを侵害するものです。これには、ファームウェア更新への悪意のあるコードの注入、デバイスドライバーの侵害、ブートプロセスの操作などが含まれます。
更新メカニズムの悪用
更新メカニズムの悪用は、正規のソフトウェア更新の配信に利用されるチャネルを標的とします。攻撃者は、信頼されている配布経路を侵害し、信頼できるベンダーからのものに見せかけたマルウェアを配信します。
サプライチェーンリスク管理の主要な構成要素
サプライチェーンリスク管理には、組み合わせて使用することで効果を発揮する主要な構成要素があります。これらは、サードパーティベンダーとそのコンポーネントがもたらすリスクを発見、監視、管理するための包括的なエコシステムを形成します。
ベンダーリスク評価と管理
ベンダーリスク評価はサプライチェーンセキュリティの基盤を築きます。このプロセスでは、新規および既存のサプライヤーに対し、システムやデータへのアクセス権限を付与する前に、そのセキュリティ慣行を評価します。適切な評価では、技術的制御とセキュリティポリシー、過去のインシデントの検証、および全体的なセキュリティ成熟度を審査します。評価時には、ベンダーを客観的に比較できる標準化された質問票と採点システムを組織が用意すべきである。
SCAとソフトウェア部品表（SBOM）
SCAツールはアプリケーションコードをスキャンし、使用されているすべてのサードパーティ製コンポーネントを特定するとともに、それらに既知の脆弱性がないかを調査する。これらのツールは、すべてのソフトウェア依存関係を包括的にリスト化し、コンポーネント内で脆弱性が検出された場合にチームに通知します。SCAは通常、アプリケーション内の全コンポーネントとそのバージョン、構成、存在する可能性のある脆弱性を明示するソフトウェア部品表（SBOM）を出力します。
サプライチェーン攻撃に対するインシデント対応計画
サプライチェーン攻撃には、一般的なインシデント対応計画では対応できない特有の要素が含まれます。このため、組織は信頼できるサプライヤー経由で侵入する侵害に特化した行動計画を策定する必要があります。こうした計画では、デバイスの隔離、関連ベンダーへの連絡、侵害範囲の把握、被害の軽減に焦点を当てるべきです。対応チームは、侵害されたベンダーへのアクセスを遮断するタイミングと方法、インシデント終了後のサービス復旧に関する明確な指示を必要とします。
サプライチェーンリスクの特定と評価方法とは？
サプライチェーンリスクを認識・分析する体系的なアプローチが存在し、技術リソースとビジネスプロセスの分析を組み合わせる。しかし組織は、潜在的な問題が業務に影響を及ぼす前に明らかにする明確な方法を持たねばならない。
組織全体で使用される全てのサードパーティコード、依存関係、コンテナ、クラウドサービスの包括的なソフトウェア部品表（SBOM）を構築することが、デジタルサプライチェーンリスク特定のはじまりである。これは自動化されたインベントリとして構築され、各アプリケーションで使用されているコンポーネント、バージョン情報、既知の脆弱性、業務への重要度を詳細に記録すべきである。
セキュリティチームはスキャンツールをCI/CDパイプラインに統合し、開発チームやITチームと連携して、依存関係、API、マイクロサービスが漏れなく管理されるようにしなければならない。
サプライチェーンリスクを軽減する手法
サプライチェーンのセキュリティリスクを軽減するために組織が導入できる効果的な戦略は数多くあります。これらの手法を組み合わせることで、外部脅威に対する多層的な防御基盤を構築できる。
ベンダーに対するセキュリティ要件
ベンダー契約に明確なセキュリティ要件を規定することは、サプライチェーンセキュリティの強固な基盤となる。最低限のセキュリティ対策、コンプライアンス認証、侵害通知の期限、監査権限などを要件に含めるべきである。法的契約では、セキュリティを交渉の余地のない事項とし、組織がベンダーに対して基準を適用し、セキュリティ上の過失について責任を問えるようにすべきです。要件は具体的かつ測定可能であり、違反に対する罰則が定められている必要があります。
コードの完全性検証
コードの完全性を検証することで、環境に入ってくるソフトウェアが改ざんされていないことを保証します。これには、デジタル署名の検証、ハッシュ出力が正しいことの確認、および入力コードの由来の追跡が含まれます。組織は、インストール前にソフトウェアの更新、サードパーティのライブラリ、およびアプリケーションコンポーネントの整合性を検証する自動化ツールを導入する必要があります。これにより、サプライチェーンへの悪意のあるコードの挿入を防ぐだけでなく、正規のソフトウェアの不正な変更も検出することができます。
最小権限アクセス
サードパーティの統合ポイントには、その機能に必要な最小限の API 権限とシステムアクセス権のみを設定する必要があります。この封じ込めアプローチにより、侵害の被害範囲が限定され、侵害されたコンポーネントが、必要な範囲を超えて重要なシステムにアクセスすることを防ぎます。
依存関係の冗長性
重要なパッケージやライブラリに冗長なソースを実装することで、組織は、単一の侵害されたリポジトリやコンテナレジストリが引き起こす可能性のある被害を制限することができます。この戦略により、特定のパッケージでセキュリティ問題が発見された場合、代替依存関係への迅速な切り替えが可能になります。主要な依存関係に対して複数の検証済みソースを維持するには追加の開発リソースが必要となるため、重要度の低いコンポーネントでは、セキュリティ上の費用対効果が努力に見合わない場合があります。
セキュリティテスト
サードパーティ製品・サービスに対する継続的なセキュリティテスト（ペネトレーションテスト、脆弱性スキャン、提供ソフトウェアのコードレビューなど）は、ベンダーのセキュリティに関する主張を検証する手段となる。最も高いリスクはベンダーシステムと内部ネットワークの接続点に生じることが多いため、テストはこれらの統合ポイントを標的とすべきである。&
サプライチェーンリスク管理フレームワークと標準>
確立された複数のフレームワークと標準は、組織がサプライチェーンセキュリティへの構造化されたアプローチを構築するのに役立ちます。
米国国立標準技術研究所（NIST）サイバーセキュリティフレームワーク
米国国立標準技術研究所（NIST）サイバーセキュリティフレームワークには、サプライチェーンリスク管理に関する具体的なガイダンスが含まれています。NIST特別刊行物800-161は、サプライチェーンリスクの特定、評価、対応に関する詳細な手順を提供します。このフレームワークは階層的アプローチを採用しており、組織がリスクレベルとリソース制約に応じてセキュリティ対策を調整するのに役立ちます。
ISO/IEC 27036
ISO/IEC 27036は、特にサプライヤー関係における情報セキュリティに焦点を当てています。この国際規格は、調達プロセスおよび継続的なベンダー管理におけるセキュリティのガイドラインを提供します。組織が、選定から契約終了までのサプライヤーのライフサイクル全体を通じてセキュリティ要件を取り入れるのに役立ちます。
サイバーセキュリティ成熟度モデル認証（CMMC）
サイバーセキュリティ成熟度モデル認証（CMMC）フレームワークには、防衛関連請負業者向けのサプライチェーン要件が含まれています。これは、サプライヤーが取り扱う情報の機密性に基づいて実施すべき具体的な管理策を定めています。防衛分野向けに設計されていますが、多くの組織が自社のサプライチェーン要件のモデルとしてCMMCを活用しています。
ソフトウェア保証コード優秀性フォーラム（SAFECode）
ソフトウェア保証フォーラム・エクセレンス・イン・コード（SAFECode）は、サプライチェーンにおけるセキュアなソフトウェア開発のためのベストプラクティスを提供します。この業界主導の取り組みは、ソフトウェア開発の初期段階からセキュリティを組み込む実践的な手法に焦点を当てています。
サプライチェーンリスク管理に関連する課題
効果的なサプライチェーンリスク管理の実施には、いくつかの大きな課題があります。外部依存関係を十分に保護するためには、組織はこれらの課題の層を一つずつ取り除いていく必要があります。
可視性の限界
組織がサプライチェーンを把握する能力は不完全です。多くのベンダーは自社のサプライヤーを通じて調達するため、追跡が困難な複数の依存関係階層が生じます。セキュリティチームは、オープンソース依存関係やサードパーティ間の関係性によってもたらされる潜在的なリスクに気付いていない可能性があります。これにより透明性が低下し、脅威ポイントの全体像を把握することが困難になります。
リソース制約
サプライチェーンセキュリティを効果的に実施するには多大なリソースが必要です。セキュリティチームは、ベンダー審査の徹底性と、その実施に充てられる時間・予算とのバランスを考慮しなければなりません。その結果、組織はセキュリティ対策を主要な依存関係や主要なコードリポジトリに集中させがちであり、ソフトウェアサプライチェーンにおいて依然として重大なセキュリティリスクとなり得る小規模なコンポーネントやマイクロサービスは軽視されがちです。
セキュリティと業務効率の対立
サプライチェーンの厳格な管理は、ビジネスを停滞させ、重要な取り組みを遅らせる可能性があります。セキュリティレビューは調達プロセスを遅延させ、ベンダーの迅速なオンボーディングを必要とする事業部門との間で大きな緊張を生む可能性があります。組織はセキュリティ要件とビジネス要件を天秤にかける必要があります。一方で、セキュリティへの過度な注力は競争力を損なうボトルネックを生み出し、スピードを優先しすぎると耐え難いリスクを生み出す可能性があります。
レガシーシステム
多くの組織では、現代的なセキュリティ機能を持たないレガシーシステムが依然として使用されている。これらのレガシーアプリケーションは、ベンダーがサポートを終了した古いコンポーネントを使用しており、既知の脆弱性を抱えている可能性がある。問題は、これらのシステムを置き換えるには費用がかかり、業務に支障をきたす点だ。レガシーコンポーネントは最終的に置き換える計画を立てるべきだが、それまでの間、セキュリティチームはこれらを緩和する戦略を必要とする。
一貫したセキュリティ基準
異なるベンダー間で一貫したセキュリティを実現することはほぼ不可能である。業界が異なり、法令やセキュリティ成熟度レベルも異なるからだ。クラウドサービスプロバイダーとハードウェアメーカーでは異なる場合があります。セキュリティ保証を犠牲にすることなく、こうした差異を考慮できるほど柔軟な評価手法を構築することが組織の課題です。
サプライチェーンリスク管理のベストプラクティス
効果的なサプライチェーンセキュリティは、一貫したアプローチに加え、記録、ポリシー、組織的な取り組みに依存します。以下のベストプラクティスは、組織がサプライチェーンの脅威に対する強固な防御策を構築するのに役立ちます。
ベンダーセキュリティ評価プロトコル
標準化されたテストプロセスは、すべてのベンダーが同じ方法で評価されることを確認するために作成されます。これには、セキュリティ質問票、文書レビュー、サプライヤーのリスクレベルに応じた検証手順などのプロトコルを含める必要があります。組織はリスクベースのアプローチを構築し、どのレベルでどのチェックを実施すべきかを定義する必要があります。つまり、低リスクおよび中リスクベンダーには基本的なチェックを、重要サプライヤーには詳細なレビューを実施します。
定期的なセキュリティ監査
ランダム監査では、サプライヤーが宣言したセキュリティ対策を実践しているかを検証します。例として自動コードスキャン、動的APIテスト、重要依存関係のリポジトリアクセス監査などが挙げられます。監査ではCI/CDパイプライン、コンテナレジストリ、パッケージリポジトリの完全性を確認し、適切なセキュリティ対策が実装されていることを保証する必要があります。
契約におけるセキュリティ要件
ベンダー向けの詳細なセキュリティ要件を契約に明記することで、強制力のある義務を創出します。こうした条項には、セキュリティ対策の最低基準、侵害通知の期限、監査権限、および不遵守の結果を詳細に規定すべきです。法務部門はセキュリティ部門と連携し、技術的に正確な文言を交渉すべきである。要件はデータ保護、アクセス制御、脆弱性管理、インシデント対応を網羅する必要がある。契約には、サイバーセキュリティ違反に対する契約解除権も明記すべきである。
コード署名と検証
ソフトウェアの全コンポーネントにコード署名を使用することで、作成後のコード改変を防止できる。企業はベンダーに対し、検証方法を伴うデジタル署名付きコードの提供を要求すべきです。更新プログラムや新規コンポーネントのインストール前には、内部システムで署名を検証する必要があります。この手順によりコードの完全性と真正性が確保されます。署名されていない、または不適切な署名のあるコードはすべて警告を発し、インストールを禁止すべきです。
セキュリティ意識の文化
全チームにわたる従業員の意識向上とサプライヤーとの連携は、サプライチェーンセキュリティにおける人的側面を強化します。これには、セキュリティ基準に関する従業員のトレーニング、開発者へのコンポーネント起源の検証指示、ベンダーセキュリティのリスクに関する事業部門への注意喚起が含まれます。スタッフは、新たなサプライチェーン脅威や攻撃手法について定期的に情報を更新すべきです。
代表的なサプライチェーン攻撃
以下のセキュリティインシデントは、二つの主要なサプライチェーン攻撃において顕著な特徴を示しています。
SolarWinds攻撃
侵害発生から1カ月も経たないうちに、複数のコンピュータセキュリティベンダーや政府サイバーセキュリティ機関は、SolarWinds攻撃（2020年12月に発見）がこれまでに確認された、あるいは試みられた中で最も洗練されたサプライチェーン侵害の一つであると結論付けました。
ハッカーは同社の開発環境に侵入し、Orionネットワーク監視プログラムにマルウェアを仕込みました。この改ざんされたソフトウェアの更新版はデジタル署名され、推定18,000の顧客に配布された。インストール後、マルウェア（SUNBURSTと命名）はバックドアを作成し、攻撃者に影響を受けたネットワークへの侵入経路を提供した。この攻撃は数か月間発見されず、複数の米国政府機関、マイクロソフト、FireEye、そして数多くのフォーチュン500企業を含む、貴重なターゲットを攻撃しました。
NotPetya攻撃
2017年6月のNotPetya攻撃は、税務申告に使用されるウクライナの会計ソフトウェアであるM.E.Docの更新から始まりました。ハッカーはソフトウェアの更新サーバーへの侵入経路を見つけ、本物の更新を装って端末破壊型マルウェアをアップロードした。
ウクライナの組織のみを攻撃対象として設計されていたが、自己複製型マルウェアはネットワーク接続を介して瞬く間に世界中に拡散した。海運大手マースク、製薬会社メルク、配送サービスフェデックスは深刻な業務混乱を経験した。例えばマースクは45,000台のコンピューターと4,000台のサーバーを交換せざるを得ず、被害額は3億ドルを超えた。
組織が外部ベンダーやソフトウェア依存関係を通じて攻撃を受けるケースが増えるにつれ、サプライチェーンセキュリティは極めて重要になっています。現代のサプライチェーンの複雑さは、攻撃者がより積極的に悪用しようとするセキュリティホールを生み出すことがよくあります。組織は、構造化されたリスク管理アプローチが整備されている場合に限り、ある程度、こうしたサイバー脅威から身を守ることができます。
サプライチェーンのセキュリティは、技術的な制御、ベンダー評価プロセス、組織の意識の混合に帰着します。組織は、セキュリティ要件やビジネスニーズを損なうことなく、外部依存関係を可視化する必要があります。サプライチェーン攻撃は日々高度化しており、セキュリティチームは効果的に検知するために次世代ツールを必要とします。
FAQs
サプライチェーンリスク管理とは、組織の業務で使用される外部ベンダー、サプライヤー、およびサードパーティ製コンポーネントから生じるセキュリティリスクを特定、評価、軽減するプロセスです。
企業は、ベンダー評価、セキュリティ質問票、コードスキャンツール、およびサプライヤー活動の継続的な監視を通じてサプライチェーンリスクを特定できます。
テクノロジーは、複雑なサプライチェーン全体で脆弱なコンポーネントや異常な動作を特定する自動スキャン、継続的モニタリング、脅威検知ツールを通じて支援します。
サプライチェーンリスク管理戦略とは、ベンダー選定方針、セキュリティ要件、評価手法、外部依存性に対するインシデント対応計画を含む体系的な計画です。
金融サービス、医療、政府、重要インフラ、テクノロジー分野は、貴重なデータと重要な機能を扱うため、最も高いサプライチェーンリスクに直面しています。
はい、ISO/IEC 27036、NISTサイバーセキュリティフレームワーク、ISO 28000シリーズなどの規格がサプライチェーンセキュリティ管理の指針を提供しています。
