Overview
サプライチェーンリスクとは、組織が利用する製品・サービス・ソフトウェアの供給網(サプライチェーン)に起因するセキュリティリスクの総称です。現代の組織は多数のベンダー、サプライヤー、オープンソースコンポーネントに依存しており、これらのいずれかが侵害されると、最終的な利用者である組織にも深刻な影響が及びます。SCRM(Supply Chain Risk Management)は、このようなリスクを識別・評価・軽減するための体系的な取り組みです。
米国NISTは、NIST SP 800-161「Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations」において、サイバーセキュリティサプライチェーンリスク管理(C-SCRM)のフレームワークを提供しています。C-SCRMは、ICT(情報通信技術)およびOT(制御技術)のサプライチェーンにおけるリスクを体系的に管理するための実践ガイダンスであり、政府機関だけでなく民間企業にも広く適用されています。
サプライチェーンリスクは、ソフトウェアサプライチェーンとハードウェアサプライチェーンの両面で増大しています。ソフトウェア面では、オープンソースコンポーネントの脆弱性やビルドパイプラインの侵害が、ハードウェア面では、製造過程での改ざんや偽造部品の混入が主要なリスクとなっています。2020年のSolarWinds事件は、ソフトウェアサプライチェーン攻撃の深刻さを世界に知らしめた象徴的な事例です。
Details
サプライチェーンセキュリティの全体像
サプライチェーンセキュリティは、製品やサービスが最終利用者に届くまでの全プロセスにおけるセキュリティを確保する活動です。これには、原材料の調達、製造、流通、導入、保守、廃棄までのライフサイクル全体が含まれます。特にICT分野では、ソフトウェアの開発・配布プロセス、ハードウェアの設計・製造プロセス、クラウドサービスの提供プロセスなどが対象となります。
サプライチェーン攻撃の特徴は、直接的な防御が困難であることです。攻撃者は、セキュリティが堅固な最終ターゲットを直接攻撃するのではなく、そのサプライチェーン上の脆弱なリンクを経由して侵入します。このため、自組織のセキュリティだけでなく、サプライチェーン全体のセキュリティを管理する必要があります。
C-SCRM(NIST SP 800-161)
NIST SP 800-161は、サイバーセキュリティサプライチェーンリスク管理のための包括的なガイドラインです。同ガイドラインでは、C-SCRMを組織のリスク管理フレームワーク(NIST SP 800-37)と統合し、3つのレベル(組織レベル、ミッション/ビジネスプロセスレベル、情報システムレベル)でサプライチェーンリスクを管理することを推奨しています。
C-SCRMの主要な活動には、サプライヤーの評価・選定、契約におけるセキュリティ要件の明確化、継続的なサプライヤー監視、インシデント対応計画の策定、サプライチェーンの可視化とマッピングが含まれます。2022年に改訂されたRev.1では、ソフトウェアサプライチェーンリスクへの対応が強化されています。
ベンダー評価とデューデリジェンス
ベンダー評価は、サプライチェーンリスク管理の中核的な活動です。サプライヤーのセキュリティ態勢を評価するために、セキュリティ質問票(SIG、CAIQ等)、第三者監査報告書(SOC 2、ISO 27001認証等)、ペネトレーションテスト結果、セキュリティ成熟度評価などを活用します。
評価は初回の選定時だけでなく、契約期間中も定期的に実施する必要があります。サプライヤーのリスクレベルに応じて評価頻度と深度を調整し、重要なサプライヤーについてはより厳格で頻繁な評価を行います。また、サプライヤーのサプライヤー(n次サプライヤー)のリスクも考慮する必要があります。
ソフトウェアサプライチェーンリスク
ソフトウェアサプライチェーン攻撃は、近年最も急速に増加しているサイバー脅威の一つです。攻撃手法には、ソフトウェアの開発環境やビルドパイプラインの侵害、正規のソフトウェアアップデートへのマルウェア混入、オープンソースリポジトリへの悪意あるパッケージの公開(タイポスクワッティング等)、依存関係の悪用(Dependency Confusion等)があります。
対策として、SBOM(Software Bill of Materials:ソフトウェア部品表)の活用、ソフトウェアの署名検証、ビルドパイプラインのセキュリティ強化(SLSA等のフレームワーク)、依存関係の定期的な脆弱性スキャンなどが推奨されています。
ハードウェアサプライチェーンリスク
ハードウェアサプライチェーンリスクには、製造過程での悪意あるハードウェアコンポーネントの挿入、偽造部品の使用、ファームウェアの改ざんなどが含まれます。特に、半導体チップやネットワーク機器などの重要なハードウェアコンポーネントについては、製造元の信頼性と製造プロセスの透明性が重要な評価基準となります。
ハードウェアサプライチェーンリスクの検知は、ソフトウェアに比べてはるかに困難であり、物理的な検査、X線検査、電子顕微鏡による分析など、専門的な検査手法が必要となる場合があります。このため、信頼できるサプライヤーからの調達と、正規の流通チャネルの使用が最も効果的なリスク軽減策となります。
Security Measures
- 01サプライチェーンの可視化とマッピングの実施:自組織が依存するすべてのサプライヤー、ソフトウェアコンポーネント、クラウドサービスを包括的に棚卸しし、サプライチェーンの全体像を可視化してください。重要度に基づいてサプライヤーを分類し、クリティカルなサプライヤーには特に重点的なリスク管理を適用します。
- 02ベンダーセキュリティ評価プログラムの確立:新規サプライヤーの選定時および既存サプライヤーの定期評価に使用する標準的な評価フレームワークを確立してください。評価項目には、セキュリティポリシー、アクセス管理、インシデント対応能力、事業継続計画、データ保護措置、第三者認証の取得状況を含めます。
- 03SBOMの導入とソフトウェア構成分析の自動化:組織が使用するすべてのソフトウェアについてSBOM(ソフトウェア部品表)を作成・管理し、含まれるオープンソースコンポーネントの脆弱性を継続的にスキャンしてください。新たな脆弱性が公開された際に影響範囲を迅速に特定できる仕組みを構築します。
- 04契約におけるセキュリティ要件の明確化:サプライヤーとの契約に、セキュリティ要件、インシデント通知義務、監査権限、データ保護条項、下請け制限を明記してください。特にインシデント発生時の通知期限(例:24時間以内)と協力義務を明確に規定することが重要です。
- 05ソフトウェア更新の検証プロセスの整備:ソフトウェアアップデートの適用前に、デジタル署名の検証、ハッシュ値の確認、テスト環境での動作検証を実施してください。自動更新の設定を見直し、重要なシステムについてはステージング環境でのテストを経てから本番環境に適用するプロセスを確立します。
- 06サプライチェーンインシデント対応計画の策定:サプライヤーのセキュリティ侵害が発生した場合の対応計画を事前に策定してください。影響範囲の特定、代替サプライヤーへの切り替え、顧客への通知、規制当局への報告など、具体的な手順とタイムラインを定義し、定期的な訓練を実施します。
Incidents
📋 SolarWinds Orionサプライチェーン攻撃(2020年)
2020年、IT管理ソフトウェアSolarWinds Orionのビルドプロセスが侵害され、正規のソフトウェアアップデートに「SUNBURST」と呼ばれるバックドアが仕込まれた状態で約18,000の顧客組織に配布されました。被害者には米国政府機関、Fortune 500企業、セキュリティ企業が含まれていました。
攻撃者は、SolarWindsの開発パイプラインに数か月前から潜入し、ビルドプロセスに悪意あるコードを注入する高度な手法を使用しました。この事件は、ソフトウェアサプライチェーンセキュリティの重要性を世界的に認識させ、米国大統領令14028の発令やSBOM義務化の議論につながりました。
📋 Kaseya VSAを経由したランサムウェア攻撃(2021年)
2021年7月、IT管理ツールKaseya VSAの脆弱性が悪用され、マネージドサービスプロバイダー(MSP)を経由して最大1,500の下流組織がREvilランサムウェアの被害を受けました。攻撃者は、Kaseyaのソフトウェアを経由して、MSPが管理する多数の企業のシステムに一斉にランサムウェアを展開しました。
この攻撃は、サプライチェーンの多層構造を悪用した典型的な事例であり、1つのソフトウェアベンダーの侵害が数百の組織に連鎖的に影響を及ぼすカスケード効果の危険性を示しました。MSPを利用する組織は、MSP自体のセキュリティ態勢を評価することの重要性を再認識しました。
📋 オープンソースパッケージを悪用した依存関係攻撃(2021年〜)
npm、PyPI、RubyGemsなどのオープンソースパッケージリポジトリにおいて、正規パッケージに類似した名前の悪意あるパッケージが公開される「タイポスクワッティング」攻撃が多発しています。また、企業の内部パッケージ名を推測し、公開リポジトリに同名のパッケージを公開する「Dependency Confusion」攻撃も確認されています。
2021年には、セキュリティ研究者がDependency Confusion手法を用いて、Apple、Microsoft、Teslaなど35以上の大手テック企業の内部システムでコード実行に成功したことが報告されました。この事例は、ソフトウェアの依存関係管理とパッケージの信頼性検証の重要性を広く認識させました。