サプライチェーン攻撃への対応ガイド｜マルウェア感染時の影響範囲特定と連携対応

サプライチェーン攻撃の脅威

サプライチェーン攻撃とは

サプライチェーン攻撃とは、標的組織を直接攻撃するのではなく、その組織が利用するソフトウェア、ハードウェア、サービスを提供するサプライヤーを経由して攻撃する手法です。信頼された経路を悪用するため、従来のセキュリティ対策では検知が困難という特徴があります。

マルウェアがサプライチェーンを通じて拡散するルートは複数存在します。それぞれの攻撃経路を理解することで、適切な防御と対応が可能になります。

攻撃経路	説明	具体例
ソフトウェアサプライチェーン	正規ソフトウェアの開発・配布過程にマルウェアを混入	SolarWinds Orion、3CX Desktop App
オープンソース依存関係	広く使用されるOSSライブラリの脆弱性や悪意あるパッケージ	Log4j（Log4Shell）、event-stream
ハードウェアサプライチェーン	機器の製造・輸送過程での改ざん	ファームウェア改ざん、不正チップ混入
サービスプロバイダー経由	MSP、クラウドサービス等の侵害を通じた攻撃	Kaseya VSA攻撃
アップデート機構の悪用	正規のアップデート配信システムを侵害	NotPetya（M.E.Doc経由）

サプライチェーン攻撃は、セキュリティ対策を講じている組織でさえ被害に遭う可能性があるため、特に警戒が必要です。

重大事例から学ぶ

過去の重大なサプライチェーン攻撃事例を理解することで、攻撃者の手法と対応のポイントを把握できます。

SolarWinds事件（2020年）

ネットワーク監視ソフトウェアOrionのビルドプロセスに攻撃者が侵入し、正規アップデートにバックドア（SUNBURST）を混入しました。18,000以上の組織に配布され、米国政府機関を含む多くの組織が影響を受けました。検知まで約9か月を要し、国家支援型攻撃グループの関与が指摘されています。この事件は、署名済みの正規ソフトウェアでも信頼できない可能性を示しました。

Kaseya VSA攻撃（2021年）

IT管理ソフトウェアKaseya VSAの脆弱性を悪用し、REvil/Sodinokibiランサムウェアが配布されました。MSP（マネージドサービスプロバイダー）を経由して、その顧客企業にも被害が拡大し、最終的に1,500以上の企業が影響を受けたとされています。サービスプロバイダー経由の攻撃の破壊力を示した事例です。

Log4j脆弱性（2021年）

Javaの広く使用されるログ出力ライブラリLog4jに重大な脆弱性（CVE-2021-44228、Log4Shell）が発見されました。このライブラリは数百万のシステムで使用されており、影響範囲の特定が極めて困難でした。自組織での直接利用だけでなく、他のソフトウェアが内部で利用しているケースも多く、SBOM（Software Bill of Materials）の重要性が再認識されました。

3CX攻撃（2023年）

VoIPソフトウェア3CX Desktop Appが侵害され、トロイの木馬化されたバージョンが公式サイトから配布されました。北朝鮮関連グループの関与が指摘され、情報窃取を目的としていました。正規の署名がなされた公式ソフトウェアが攻撃に使用された点で、SolarWinds事件と類似しています。

なぜ対応が困難なのか

サプライチェーン攻撃への対応が困難な理由はいくつかあります。

第一に、信頼された経路からの侵入という点です。ファイアウォールやエンドポイント保護は、信頼されたソフトウェアからの通信を許可する設定になっていることが多く、正規ソフトウェアに混入したマルウェアは検知されにくい傾向があります。

第二に、影響範囲の特定が困難です。自組織が直接利用しているソフトウェアだけでなく、それが依存する他のコンポーネント、さらにその先の依存関係まで確認する必要があります。大規模な組織では、使用しているソフトウェアの全体像を把握すること自体が困難です。

第三に、複数組織間の連携が必要となります。サプライチェーン攻撃の対応には、被害を受けた組織だけでなく、ソフトウェアベンダー、他の利用組織、場合によっては法執行機関との連携が必要です。情報共有の範囲や方法について、事前の取り決めがないと対応が遅れます。

マルウェア感染対策の観点からも、サプライチェーンリスクへの対応は重要な課題となっています。

サプライチェーン攻撃の検知

検知の課題

サプライチェーン攻撃は、従来のセキュリティ対策では検知が困難です。その理由を理解することで、より効果的な検知アプローチを設計できます。

正規ソフトウェアによる攻撃という特性上、署名検証やホワイトリスト方式のセキュリティ対策をすり抜けることがあります。SolarWindsやZCXの事例では、正規の電子署名がなされた状態でマルウェアが配布されました。

署名済みコードの悪用により、コード署名は「このコードは改ざんされていない」ことを保証しますが、「このコードが安全である」ことは保証しません。ビルドプロセス自体が侵害されれば、悪意あるコードにも正規の署名がなされます。

長期的な潜伏も検知を困難にする要因です。SolarWinds事件では、侵入から検知まで約9か月を要しました。攻撃者は検知を避けるため、慎重に行動し、正規の通信に紛れて活動します。

検知アプローチ

サプライチェーン攻撃を検知するためには、従来のシグネチャベース検知だけでなく、複合的なアプローチが必要です。

検知手法	概要	有効性	限界
振る舞い検知（EDR/XDR）	正規ソフトウェアの異常な動作を検知	高	正常な動作との区別が困難な場合あり
ネットワーク異常検知（NDR）	C2通信、データ流出の兆候を検知	高	暗号化通信の分析が困難
ソフトウェア整合性監視	ファイルハッシュの変化を検知	中	正規アップデートとの区別が必要
脅威インテリジェンス連携	既知のIOCとの照合	中	未知の攻撃には効果なし
SBOM照合	脆弱性のあるコンポーネント特定	高	SBOMの整備が前提

振る舞い検知は、サプライチェーン攻撃の検知において特に重要です。正規ソフトウェアであっても、通常と異なる動作（未知のIPへの通信、異常なプロセス生成、予期しないファイルアクセスなど）を行えば検知可能です。ファイルレスマルウェアへの対策としても、振る舞い検知は有効です。

ネットワーク異常検知では、C2（コマンド&コントロール）サーバーとの通信パターンを検知します。SolarWinds事件では、特定のドメインへの通信が攻撃の兆候として特定されました。

アラートトリアージ

サプライチェーン攻撃を示唆するアラートを受け取った場合、迅速かつ正確なトリアージが重要です。

優先順位の判断

影響を受けたソフトウェアの重要度、アクセスできるデータの機密性、ネットワーク上の位置付けを考慮し、対応の優先順位を決定します。クリティカルなシステムや機密データにアクセス可能なソフトウェアは、最優先で調査します。

誤検知との区別

正規のソフトウェアアップデートや設定変更によるアラートと、実際の攻撃を区別する必要があります。変更管理記録との照合、ベンダーからの公式情報の確認、脅威インテリジェンスとの照合を行います。

関連IOCの確認

セキュリティベンダーやISACから公開されるIOC（Indicators of Compromise：侵害の痕跡）と自組織のログを照合します。ハッシュ値、IPアドレス、ドメイン、特定のファイルパターンなどが対象となります。

影響範囲の特定

ソフトウェア依存関係の把握

サプライチェーン攻撃の影響範囲を特定するためには、自組織で使用しているソフトウェアとその依存関係を把握している必要があります。ここで重要になるのがSBOM（Software Bill of Materials）です。

SBOMとは、ソフトウェアを構成するコンポーネントの一覧表です。製造業における部品表（BOM）のソフトウェア版と考えると分かりやすいでしょう。SBOMには、使用しているライブラリ、そのバージョン、ライセンス情報などが含まれます。

SBOMの活用メリット

脆弱性が公表された際に、影響を受けるシステムを迅速に特定できます。Log4j脆弱性の際、SBOMを整備していた組織は数時間で影響範囲を特定できた一方、整備していない組織は数週間を要したケースもありました。また、サプライヤーから受け取るソフトウェアのコンポーネントを把握し、リスク評価に活用できます。

SBOMの作成方法

開発しているソフトウェアについては、ビルドプロセスでSBOMを自動生成するツール（Syft、CycloneDX、SPDX対応ツールなど）を使用します。購入・利用しているソフトウェアについては、ベンダーにSBOMの提供を依頼します。米国では政府調達においてSBOM提出が義務化されつつあり、今後はベンダーからのSBOM提供が一般的になると予想されます。

SBOMの管理と運用

作成したSBOMは、資産管理システムと連携して管理します。脆弱性データベース（NVD、JVNなど）と定期的に照合し、影響を受けるコンポーネントを特定します。専用の脆弱性管理ツール（Dependency-Track、Snykなど）を活用することで、継続的な監視が可能になります。

影響を受けたシステムの特定

サプライチェーン攻撃に関する情報を受けた際、自組織への影響を迅速に特定するためのプロセスを確立しておく必要があります。

特定ステップ	内容	使用する情報/ツール
1. 該当ソフトウェアの確認	影響を受けたソフトウェアを自組織で使用しているか確認	資産管理台帳、SBOM
2. バージョンの確認	使用バージョンが影響範囲内か確認	構成管理データベース、SBOM
3. 依存関係の確認	他のソフトウェアが内部で使用していないか確認	SBOM、依存関係スキャンツール
4. 使用箇所の特定	該当ソフトウェアがどのシステムで稼働しているか特定	構成管理、ネットワークスキャン
5. 侵害の痕跡確認	IOCに基づき、実際に侵害されているか調査	ログ分析、EDR/XDR

特に、自組織が直接インストールしたソフトウェアだけでなく、他のソフトウェアの依存関係として含まれているケースを見落とさないことが重要です。Log4jの事例では、この依存関係の把握に多くの組織が苦労しました。

根本原因分析の際にも、影響範囲の正確な特定が重要な基盤となります。

取引先・顧客への影響確認

サプライチェーン攻撃では、自組織だけでなく、取引先や顧客にも影響が及ぶ可能性があります。

自社が攻撃を受けた場合、自社製品・サービスを利用している顧客に影響が波及していないか確認します。顧客システムへのアクセス権限を持つサービスを提供している場合は、そのアクセスが悪用されていないかも調査対象となります。

自社製品が悪用された場合、自社が提供するソフトウェア・サービスがサプライチェーン攻撃の経路となった場合は、全ての顧客に影響通知を行う必要があります。被害の有無に関わらず、予防的な対策を案内します。

ステークホルダーコミュニケーションのプロセスに従い、適切なタイミングと内容で通知を行います。

封じ込めと根絶

即時対応

サプライチェーン攻撃の影響が確認された場合、被害の拡大を防ぐための即時対応を実施します。

影響を受けたソフトウェアの無効化

影響を受けたソフトウェアの動作を停止します。ただし、業務への影響を考慮し、完全停止が困難な場合は、ネットワーク分離や機能制限での対応も検討します。無効化の判断は、攻撃の深刻度と業務影響を比較して行います。

ネットワークセグメンテーション

影響を受けたシステムをネットワーク的に分離し、横展開を防止します。ファイアウォールルールの追加、VLANの分離、マイクロセグメンテーションの適用などの手法を用います。

外部通信の監視強化

C2サーバーとの通信をブロックし、データ流出を防止します。公開されているIOC（IPアドレス、ドメイン）をファイアウォールやプロキシでブロックします。同時に、アウトバウンド通信の監視を強化し、未知のC2との通信も検知できる体制を整えます。

即時対応のアクションリストは以下の通りです。

1. 影響を受けたシステムの特定と一覧化
2. ネットワーク分離の実施
3. 既知のIOCに基づく通信ブロック
4. ログの保全と分析開始
5. 関係者への初動報告
6. ベンダーからの公式情報の確認

長期的対応

即時対応で被害拡大を防いだ後、根本的な問題解決に向けた長期的対応を実施します。

パッチ/アップデートの適用では、ベンダーから修正パッチやセキュアなバージョンがリリースされたら、速やかに適用します。ただし、本番環境への適用前には、テスト環境での検証を行い、副作用がないことを確認します。

代替ソフトウェアへの移行については、ベンダーの対応が不十分な場合や、同様の攻撃リスクが高い場合は、代替ソフトウェアへの移行を検討します。中長期的なリスク低減のために必要な判断です。

クリーンなバージョンへの入れ替えでは、侵害されたソフトウェアをアンインストールし、クリーンなバージョンを再インストールします。その際、侵害中に変更された設定や追加されたファイルがないかも確認します。

ランサムウェア対応プレイブックと同様に、段階的な復旧アプローチを取ることが重要です。

残存リスクの評価

封じ込めと根絶の後も、残存リスクを評価し、継続的な監視体制を維持します。

バックドアの残存可能性について検討が必要です。攻撃者は、主要な攻撃手段が検知された場合に備えて、複数のバックドアを設置していることがあります。影響を受けたシステムだけでなく、そこからアクセス可能だった他のシステムも調査対象とします。

データ漏洩の有無についても確認します。攻撃者がすでにデータを窃取している可能性があります。ネットワークログ、エンドポイントログを分析し、大量のデータ転送や不審な外部通信がなかったか確認します。

継続的なモニタリングとして、インシデント収束後も一定期間（最低1-3か月）は、監視を強化します。攻撃者が再侵入を試みたり、残存したバックドアを活用したりする可能性があるためです。

関係者間の連携

社内連携

サプライチェーン攻撃への対応には、組織内の複数部門の連携が不可欠です。

IT部門は、技術的な調査、封じ込め、復旧を担当します。影響を受けたシステムの特定、ログ分析、対策の実施が主な役割です。

セキュリティ部門（CSIRT/SOC）は、全体の指揮とコーディネーションを担当します。脅威インテリジェンスの収集、対応方針の決定、外部機関との連携を行います。

調達部門は、影響を受けたベンダーとの連絡、契約上の対応、代替調達の検討を担当します。ベンダーからの情報入手と自社へのフィードバックが重要な役割です。

法務部門は、契約上の責任関係、規制当局への報告義務、訴訟リスクの評価を担当します。ベンダーへの損害賠償請求の可能性も検討します。

経営層への報告は、経営層向けサイバーリスクの観点から、事業インパクトと対応状況を適切に伝えます。

取引先・ベンダーとの連携

サプライチェーン攻撃では、ベンダーや取引先との連携が特に重要です。

連携先	共有すべき情報	注意点
ソフトウェアベンダー	検知した攻撃の詳細、影響範囲、IOC	公式チャネルで連絡、NDAの確認
影響を受けた取引先	攻撃概要、推奨対策、連絡窓口	風評リスクに配慮した情報管理
サプライチェーン上流	侵入経路として利用された可能性	責任関係を明確にした上での情報共有
サプライチェーン下流	自社経由での影響波及の可能性	顧客への影響を最優先で確認

情報共有のプロトコルについては、事前にベンダーや主要取引先との間で、インシデント発生時の情報共有ルールを合意しておくことが望ましいです。どのレベルの情報をどのタイミングで共有するか、連絡先は誰か、NDAの適用範囲は何かなどを明確にします。

共同対応の枠組みとして、大規模なサプライチェーン攻撃では、複数の組織が共同で対応にあたることがあります。対応の重複を避け、情報を効率的に共有するための調整役（コーディネーター）を決めることが有効です。

業界・公的機関との連携

組織単独での対応に限界がある場合、業界団体や公的機関との連携が有効です。

ISAC（情報共有分析センター）

業界ごとに設置されているISACを通じて、同業他社との情報共有が可能です。金融ISAC、電力ISAC、ICT-ISACなど、業界に応じたISACに参加することで、脅威情報の早期入手と対応のノウハウ共有が期待できます。

JPCERT/CC

日本のCSIRTの中核組織として、インシデント対応の支援、脅威情報の提供、国際連携を行っています。サプライチェーン攻撃に関する情報共有や対応支援を受けることができます。

IPA（情報処理推進機構）

サイバーセキュリティに関する情報提供、注意喚起を行っています。脆弱性情報の公開、対策情報の提供などを通じて、対応を支援しています。

業界標準・フレームワークへの準拠も、サプライチェーンセキュリティの強化に役立ちます。

再発防止と体制強化

サプライチェーンセキュリティの強化

インシデント対応後は、同様の攻撃を防ぐための体制強化に取り組みます。

ベンダーリスク評価

取引するベンダーのセキュリティ体制を評価するプロセスを確立します。評価項目には、セキュリティ認証の取得状況、インシデント対応体制、脆弱性管理プロセス、従業員教育などが含まれます。重要度の高いベンダーには、定期的な監査や第三者評価の結果提出を求めることも検討します。

セキュリティ要件の契約明記

ベンダーとの契約に、セキュリティ要件を明記します。インシデント発生時の通知義務、SBOMの提供、脆弱性対応の期限、監査受け入れなどを契約条項として盛り込みます。これにより、ベンダーのセキュリティ対策レベルを一定以上に保つことができます。

定期的な監査

重要ベンダーに対しては、定期的なセキュリティ監査を実施します。自社で実施する場合と、第三者機関に委託する場合があります。監査結果に基づき、改善を要求し、フォローアップを行います。

技術的対策

対策	内容	実装難易度	効果
ゼロトラスト適用	全ての通信を検証、最小権限アクセス	高	高
ソフトウェア署名検証	実行前にコード署名を検証	中	中
SBOM運用の定着	全ソフトウェアのSBOM管理と脆弱性照合	中	高
依存関係の固定	ロックファイルで依存関係を固定	低	中
プライベートレジストリ	検証済みパッケージのみを使用	中	中
振る舞い監視強化	正規ソフトウェアの異常動作検知	中	高

ゼロトラストアーキテクチャの適用は、「信頼せず、常に検証する」という原則に基づき、ネットワーク内部の通信も含めて全てを検証します。サプライチェーン経由の攻撃に対しても、横展開を困難にする効果があります。

DevSecOps実践により、開発段階からサプライチェーンセキュリティを組み込むことも重要です。

よくある質問（FAQ）

Q: 自社が使用しているソフトウェアがサプライチェーン攻撃を受けた場合、何から始めるべきですか？

A: まず、影響を受けたソフトウェアのバージョンと使用箇所を特定してください。ベンダーからの公式情報を確認し、推奨される対応（パッチ適用、アンインストール等）を実施します。並行して、当該ソフトウェア経由での不審な通信や活動がないかログを確認し、横展開の痕跡がないか調査します。SBOMが整備されていると、この特定作業が大幅に効率化されます。脅威インテリジェンス情報（IOC）をセキュリティツールに反映し、継続的な監視体制を強化することも重要です。

Q: SBOMはどの程度の組織に必要ですか？小規模な組織でも整備すべきですか？

A: 規模に関わらず、ソフトウェアを利用する全ての組織にSBOMは有益です。小規模組織では、完璧なSBOM管理は困難かもしれませんが、重要システムで使用しているソフトウェアとそのバージョンのリストを維持するだけでも、脆弱性対応時に大きな助けになります。無料のSBOM生成ツールや、クラウドサービスを活用することで、コストを抑えながらSBOM管理を始めることができます。

Q: ベンダーにセキュリティ要件を要求する際、どのような項目を含めるべきですか？

A: 主な項目として、セキュリティ認証の取得（ISO 27001、SOC 2等）、脆弱性管理プロセス（発見から修正までの期間等）、インシデント発生時の通知義務（時間要件含む）、SBOMの提供、監査受け入れ、従業員のセキュリティ教育などがあります。ベンダーの規模や提供サービスの重要度に応じて、要求レベルを調整してください。重要ベンダーには厳格な要件を、その他のベンダーには基本要件を適用するなど、リスクベースのアプローチが現実的です。

Q: サプライチェーン攻撃を受けた場合、取引先への通知はどのタイミングで行うべきですか？

A: 取引先のシステムやデータに影響が及ぶ可能性がある場合は、詳細が判明する前でも速やかに第一報を出すことを推奨します。「調査中」の段階でも、影響の可能性と現在の対応状況を伝えることで、取引先側も予防的な対策を取れます。契約上の通知義務がある場合は、その期限に従ってください。情報を出し渋ると、後から「隠していた」と批判される可能性があります。

Q: オープンソースソフトウェアのサプライチェーンリスクにどう対処すべきですか？

A: オープンソースは現代のソフトウェア開発に不可欠ですが、リスク管理が必要です。主な対策として、依存関係スキャンツール（SCA）による脆弱性の継続監視、依存関係のバージョン固定（ロックファイルの活用）、信頼できるパッケージレジストリの利用、新規パッケージ導入時のセキュリティレビュー、使用パッケージのメンテナンス状況確認などがあります。また、クリティカルな依存関係については、メンテナンスが停止した場合の代替策も検討しておくと安心です。

まとめ

サプライチェーン攻撃は、信頼されたソフトウェアやサービスを経由するため、従来のセキュリティ対策だけでは防ぎきれない深刻な脅威です。SolarWinds、Log4j、3CXなどの事例が示すように、影響範囲は広大で、対応も複雑になります。

効果的な対応のためには、SBOMの整備による依存関係の把握、振る舞い検知を中心とした検知体制、ベンダーとの連携プロトコルの確立が重要です。また、インシデント発生後は、影響範囲の迅速な特定、封じ込め、関係者間の連携を通じて、被害の拡大を防ぎます。

マルウェア感染対策の一環として、サプライチェーンセキュリティの強化に継続的に取り組むことを推奨します。ベンダーリスク評価、契約へのセキュリティ要件明記、定期的な監査により、サプライチェーン全体のセキュリティレベルを向上させることができます。

---

---