SolarWinds襲ったサプライチェーン攻撃

2020年12月、ネットワーク管理製品の SolarWinds Orion プラットフォームを狙ったサプライチェーン攻撃が発覚しました(*1)。国内外で大きく報道されたこの攻撃では、多くの米国の政府機関や民間企業のネットワークが被害を受けたとされています。

2021年5月にニュースで話題となったメルカリのデータ流出に影響を与えたとされる、コードカバレッジツール「Codecov」への不正アクセスも、サプライチェーン攻撃の一種と言えます（*2）。

米CISAとNISTの資料

2021年4月26日、米国の政府機関であるCISAとNISTは、

ソフトウェアサプライチェーン攻撃の概要と対策をまとめた資料

「Defending Against Software Supply Chain Attacks」

（訳：ソフトウェアサプライチェーン攻撃に備える）

を、ウェブ上に公開しました。

この資料では、ソフトウェアサプライチェーンにおけるリスクの概要が説明されているほか、

ユーザーとベンダーがNISTのフレームワークである「C-SCRM」と「SSDF」を利用して、リスクを特定・評価・緩和する方法について紹介されています。

この記事でお伝えすること

本ブログ記事では、この米CISAとNISTの資料の要点をピックアップしながら、

□ソフトウェアサプライチェーン攻撃とは何か？

□ ユーザーはどう対策すべきか？

□ ベンダーはどう対策すべきか？

を≪前編≫・≪中編≫・≪後編≫の3回に分けて考えていきます。

今回の記事は

≪中編≫として、

【ユーザー】に推奨される行動

について見ていきます。

（オリジナルの資料における6~11ページ目に相当する内容です）

≪前編≫≪後編≫はこちら

≪前編≫ソフトウェアサプライチェーン攻撃とは何か

ソフトウェアサプライチェーン攻撃とは何か | 米CISA/NISTの資料から（1/3）

≪後編≫【ベンダーの対策編】

ソフトウェアサプライチェーン攻撃とは何か【ベンダーの対策編】 | 米CISA/NISTの資料から（3/3）

注

*資料を引用・要約した部分における太字は、ブログ筆者の手によるものです。読みやすさを向上させる観点で太字としました。

顧客への推奨事項

攻撃発生後の対応には限界あり

資料の”Recommendations”（推奨事項）の章の冒頭では、

ネットワーク防衛担当者は攻撃が起こる前に業界のベストプラクティスを遵守する必要があります。

（6ページ）

と指摘されています。

理由については、次のように述べられています。

脅威アクターがソフトウェアサプライチェーンを侵害した後の影響を速やかに緩和するための、ネットワーク防衛者の能力には限界があります。なぜなら、組織がソフトウェアサプライチェーン全体を制御していることは稀であり、サプライチェーン内のすべての組織に迅速な緩和策を講じるよう強制する権限を持っていないためです。

（6ページ）

C-SCRMアプローチを利用する

ソフトウェアを入手する組織は、

リスクマネジメント・プログラムの文脈でソフトウェアなどの利用を考えるべき

（7ページ）

であり、

リスクマネジメント・プログラムは、

運用可能なセキュリティ・エンジニアリング・フレームワーク(*3)、および、組織、ミッション/事業、システム階層全体における正式なC-SCRMを利用すべき

（7ページ）

と述べられています。

なお、C-SCRMとは、NISTが提唱する枠組みである「サイバー・サプライチェーンリスクマネジメント」のことです。NISTは別の資料で、C-SCRMを「ICT/OT製品・サービスのサプライチェーンにおける分散・相互接続という特性に関連するリスクを特定・評価・緩和するプロセス」と表現しています(*4)。

そして、ソフトウェアに対して適用可能なC-SCRMアプローチを確立する上で、NISTが提唱する8つのカギが提唱されています。

1 C-SCRMを組織全体で活用する

2 正式なC-SCRMプログラムを確立する

3 重要なコンポーネントとサプライヤーを把握し、管理する

4 組織のサプライチェーンを理解する

5 主要サプライヤーと密接に協力する

6 主要サプライヤーに回復力（レジリエンス）強化と改善の活動に参加してもらう

7 サプライヤーとの関係全体の評価・監視を行う

8 ライフサイクル全体の計画を立てる

（7ページ）

これら8つは、この先で述べられる「ソフトウェアの脆弱性の予防・緩和・対応に役立つ」とされています。

リスクマネジメント・プログラムの具体例

上に述べたリスクマネジメント・プログラムの具体例についても触れられています。

（【】内は筆者による注釈です）

【組織の主要ミッション・事業を明確にする】

組織の主要なミッションあるいは事業のプロセスを特定する（組織が提供する主力サービスは何か？　どんな事業で収益を得ている？）

 

【使用（予定）ソフトウェアの洗い出し】

組織の現在および将来のソフトウェアライセンスのインベントリ（目録）を保持する

 

【サプライヤーのサポート体制の確認】

各ソフトウェアライセンスをサプライヤーがどのようにサポートしているかについて調査し、記録する（例：パッチは提供されているか？　サプライヤーは製品について定期的にEメールで最新情報を配信しているか？）

 

【ソフトウェアの組織での役割】

ソフトウェア（現在使用中あるいは将来購入するもの）は組織の重要プロセスをどう支えているのか、あるいは、重要プロセスにどう関係しているかを理解する

 

【脆弱性への対処プラン】

脆弱性が公開されたソフトウェアにどのように対処する計画であるかを記録する

【予防】悪意ある/脆弱なソフトウェアを入手しないために

資料内では、顧客側に推奨するソフトウェア取得時のデューデリジェンスや契約行為を5つ（うち1つは9項目に分岐）紹介しています。

このブログでは上記5項目は後回しにして、まずは概要を掴むため、資料で紹介されている「簡単な手順」を紹介します。

まずは具体例から

1.ソフトウェアの供給元/ベンダーに以下の項目を質問する（ベンダーのウェブサイトを確認するのも可）

・安全なソフトウェア開発習慣を取り入れたソフトウェア開発ライフサイクルを利用しているか

・脆弱性を盛んに特定・公表すると同時に、脆弱性対応プログラムを維持しているか

・パッチ管理機能は利用可能か

・自社プロダクトの供給元リストを作成・維持・利用しているか

 

2.購入予定のソフトウェアごとに、ソフトウェアコンポーネントのインベントリ（目録）を依頼する

・もしベンダーがコンポーネント・インベントリを提供できない場合、競合プロダクトの中から選ぶ際にそのことを差別化要因として利用することを検討する

・購入後、その情報を自社のソフトウェア・インベントリに組み込む

（8ページ）

 

推奨されるデューデリジェンスや契約行為

ここで、先に述べた「顧客側に推奨するソフトウェア取得時のデューデリジェンスや契約行為」の5項目を見てみましょう。

・自組織内で適用されているのと同じポリシーをサプライヤーにも適用する

 

・全サプライヤー向けのセキュリティ要件やセキュリティコントロール一式を確立する。これらは、サプライヤーの重要性とICTに付与される権限に応じて異なる

 

・サプライヤー認定を利用して、サプライヤーが以下の要件を満たしているか確認する：

…ソフトウェア開発ライフサイクル（SDLC）を使用し、ライフサイクルの全段階を通じて安全なソフトウェア開発習慣を取り入れている

…ソースコードやコンパイルされたコードに既知の弱点や脆弱性がないか調べており、どの程度の厳密さを適用するか明示している。特定のレベルの開発者テストおよび評価を要求してもよい（静的コード解析、脅威モデルおよび脆弱性解析、サードパーティによるプロセスの検証、手動でのコードレビュー、ペネトレーションテスト、動的コード解析など）

…脆弱性を積極的に特定し、公表している

…製品の脆弱性対応プログラムを保持している

…取得するコードにプロアクティブな脆弱性緩和技術を使用している

…パッチ管理機能を有効にしている

…製品をサードパーティ機関による査定に出している

…共通脆弱性識別子（CVE）作成に参加している（サプライヤーがCVE 採番機関［CNA］として参加しているかどうかを含む）

…製品およびサービスの承認済みサプライヤーリストを作成・保持・使用している

 

・ベンダーやサードパーティが開発した納入済みソフトウェアのコンポーネントやその他の属性を明示したソフトウェアコンポーネント・インベントリ（ソフトウェアの部品表など）を要求する

 

・ベンダーの製品・サービスを購入する組織が使用するものと同等のサプライチェーンセキュリティ要件を、ベンダーに確実に実施させる

（8ページ）

先の具体例が、これら5項目を反映したものであることがお分かりかと思います

また、このセクションの最後では、次のようにも述べてられています。

組織は、通常の入手・デプロイのプロセスの一環として、一般的なコード認証や、その他メカニズムを使用することにより、ソフトウェアおよびファームウェアの完全性を確認することができる場合があります。この機会が得られない場合、組織は、デジタル署名またはチェックサム検証のためのデータを取得しつつ、上記のような認証メカニズム（訳註：一般的なコード認証など）がベンダーの通常業務において適用されたことの証明をベンダーから取得すべきです。顧客は、市販のソフトウェア/ファームウェアのタンパーシール（tamper seal）を適用することで、継続的な完全性管理を（独立して、または製造業者や販売業者と協力して）採用することができます。これにより、継続的で自動的な完全性チェックが可能になります。組織は完全性管理を、より広範な接続準拠ポリシーの一部とすることができます。

（8~9ページ）

【緩和】デプロイ済みのものによる害を緩和するために

まずは具体例

この章でも「簡単な手順」が提示されていますので、まずはこちらを紹介します。

（【】内は筆者による注釈）

1.【脆弱性管理プログラムの導入】

文書化された脆弱性管理プログラムを導入する

・ベンダーの指示に従い、パッチを自動的にチェックおよびインストールするようソフトウェアを設定する

・脆弱性と緩和策について連絡を受けられるよう、連絡先情報と合わせ、ソフトウェアのライセンスをベンダーに登録する

・ベンダーの指示に従い、ソフトウェア、OS、ファームウェアを堅牢にする

 

2.【接続制限】

ベンダーがソフトウェアの通信先と通信元のURL、IPレンジ、ポートを指定している場合は、そのパラメータの範囲外で通信が行われないようにファイアウォールのルールを設定することを検討する

 

3.【セグメンテーション】

実行可能な場合は、基本的なネットワーク・セグメンテーションを適用して、企業内の異なる部分同士を分離する（例：ゲストユーザー用の別のネットワークを維持する、組織内の異なる機能を持った分野で使用されるネットワークを分離する、など）

 

4.【インベントリからの逸脱有無、未承認ソフト削除・隔離】

エンドポイントやサーバを監視し、ソフトウェアのインベントリから原因不明の逸脱がないか確認し、未承認のソフトウェアを削除または隔離する

（10ページ）

脆弱性管理プログラムを開発・実施する

この章の冒頭では、

C-SCRMに従った行動を取っても、悪意のあるコンテンツや脆弱性が組織の企業環境に入り込んでしまうことがあるため、脆弱なソフトウェアコンポーネントを緩和するための別の手段を講じる必要があります

（9ページ）

と指摘されています。

その中心となるのが、上の「簡単な手順」で登場した脆弱性管理プログラムを開発・実施することです。

脆弱性管理プログラムには、必要に応じて

ソフトウェアのパッチを供給・適用するプロセスとツールを含めるべき

（9ページ）

とされています。

攻撃対象を縮小する構成管理

また、構成管理によってソフトウェア攻撃の対象（アタック・サーフェス）を減らすことができると述べられています。

ここでいう構成管理には以下の4つが含まれるといいます。

・構成を変更管理の下に置く

・セキュリティインパクト分析を実施する

・メーカーが提供するガイドラインを実施することで、ソフトウェア、OS、ファームウェアを堅牢にする

・情報システムコンポーネントのインベントリを維持する

（9ページ）

重要なデータを把握し、データの流れの基準を定める

構成管理と並行して、組織は重要なデータを特定し、そのデータがプロセスやシステム間でどのように流れるかの基準を定める必要があります。防御者は、機械学習や人工知能などに基づいた分析を導入することで、データの流れの異常を特定することができます。これは、脅威アクターによる脆弱性の悪用を示す初期の指標となることがあります。

（9ページ）

構成設定の監視によるハード/ソフト/ファームウェアの完全性維持

すべての組織は、ハードウェア、ソフトウェア、ファームウェアの完全性を維持することに集中するため、構成設定（configuration settings）を監視する必要があります。

例えば、監視により、TPM（Trusted Platform Module）の設定に対する不正な変更（どのTPM機能を有効にするかなど）を特定することができます。同様に組織は、ベンダーまたはユーザが定義した堅牢な状態を確立する設定と、その設定に対する不正な変更の有無を監視する必要があります。

（9~10ページ）

リスク軽減を可能にする接続制限　その手段や実現可能性

さらに、ソフトウェアの導入ごとに、外部および内部からの接続を承認済みのリストに記載されているものだけに制限することで、リスクを軽減することができます。予想されるソフトウェアの動作（ソフトウェアパッケージが定期的に通信するベンダーの URL や IP レンジ、ポートなど）を利用して、セキュリティエンジニアリングは、予想外の動作を防止・検出するための情報制御（ファイアウォール、侵入検知・防止など）を実行することができます。ただし、ベンダーの多くは非常に動的な環境を持ち、ベンダーのリソースをホストするためにクラウドサービスプロバイダを利用しているため、静的な URL や IP レンジに基づいて接続を制限することは、実現可能性や効果が低い場合があります。多くの理由から、組織は通常の動作の基準を定めるために、アイデンティティベースやオブジェクトベースのアプローチの適用を検討する必要があります。また、機械学習や人工知能を利用して異常を識別し、異常な情報の流れを拒否することも検討すべきです。

（10ページ）

セグメンテーション、マイクロセグメンテーション

意図的なネットワーク・セグメンテーションを利用することで、ソフトウェアの脆弱性やそれを利用した攻撃の影響を軽減し、インシデント対応や復旧を補助することができます。セグメンテーションにより、脆弱性や攻撃を顧客企業の一部に限定することができます。またこのような対策は、ホストベースのファイアウォールやエージェントを用いて、エンドポイントベースのマイクロセグメンテーションを実装することによっても実行することができます。マイクロセグメンテーションは、「ゼロトラスト」アーキテクチャの一部として実施することも、単独で実施することも可能です。

（10ページ）

複数ベンダー使用などの「異種混交技術」

また、組織は異種混交技術（例えば、異なるネットワークセグメントをカバーするために複数のベンダを使用する）を使用することにより、回復力を高め、単一の製品・サービスの脆弱性による企業全体のリスクを低減することができます（次のセクションを参照）。

（10ページ）

【復旧】ソフトウェアが悪用された際に立ち直る力をつける

このセクションの冒頭（10ページ）では、組織としてソフトウェアに関する緊急事態計画を確保しておくことが重要であると指摘されています。

ここでいう緊急事態計画には、

ソフトウェアの代替サプライヤーを予め見つけ、関係を構築すること

フェイルオーバー（予備）プロセスの確立

が含まれるとされています。

また、フェイルオーバープロセスで重要なのは、ソフトウェアが組織でどう利用されているかをよく理解しておくことだとされています。

フェイルオーバープロセスを確立するには、各ソフトウェアが組織内でどのように使用されているか（ソフトウェアがサポートするミッションや事業、ソフトウェアが属するプロセス、それらのプロセスが中断された場合に予想される業務または事業への影響）をしっかり理解している必要があります。このように理解することで、組織は様々なミッションや事業のプロセスの重要性と、それに関連するソフトウェアの依存関係を評価することができます。その結果、組織はフェイルオーバーの選択肢を特定することができます。

また、ソフトウェアの重要度を理解することで、組織はリソースをどの程度、回復力措置（resilience measure）に費やすべきかについて、リスクに基づいた判断を下すことができます。組織が回復力を高めるための行動を決定する際には、ソフトウェアサプライチェーンの被害に対する戦略 (playbook) の作成を検討する必要があります。

（10〜11ページ）

具体例

1　使用している重要ソフトウェアの代替サプライヤーを予め見つけ、関係を築いておく

・可能であれば、重要なソフトウェアが利用できなくなったり、そうしたソフトウェアのリスクが高まったりした場合に新しいサプライヤーに切り替える計画を整えておく

 

2　ソフトウェアが重要な事業やミッションをどのようにサポートしているかを理解し、その理解を特定のソフトウェアの機能が利用できなくなった場合のフェイルオーバープロセスや次善の策の特定に活かす

・重要ソフトウェアに対しては文章化されたフェイルオーバープロセスを用意する

・定期的に机上演習やウォークスルーを実施し、組織が確実にフェイルオーバープロセスの手順を理解できている状態にする

・可能であれば、フェイルオーバープロセスをベンダーやその他の外部関係者と調和させる

（11ページ）

まとめ

ここまで、【ユーザーに推奨される行動】について見てきました。

分量が多くなってしまいましたが、少しでも参考になれば幸いです。

参考までに以下、資料のリンクを掲載しました。

お時間のある方は、ぜひ英語原文もご参照ください。

引用・参考資料

CISA : Defending Against Software Supply Chain Attacks
(Publication: April 2021)

*掲載サイト: https://www.cisa.gov/publication/software-supply-chain-attacks

*PDF : https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508.pdf

注

*1) 12月は、SolarWinds社がインシデントを公表した時期であり、後に同社が発表したところによると攻撃プロセス自体は2019年9月から始まっていたという（以下サイト参照）。

SolarWinds 公式サイト：New Findings From Our Investigation of SUNBURST (2021年1月11日付)

https://orangematter.solarwinds.com/2021/01/11/new-findings-from-our-investigation-of-sunburst/

*2)

・メルカリ公式サイト：「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について
https://about.mercari.com/press/news/articles/20210521_incident_report/

・infosecurity : “Codecov Supply Chain Attack May Hit Thousands: Report”
（訳：「Codecov」のサプライチェーン攻撃　影響は数千のネットワークに及ぶ可能性）
https://www.infosecurity-magazine.com/news/codecov-supply-chain-attack-may/

*3)NIST(RON ROSS, MICHAEL McEVILLEY, JANET CARRIER OREN)
: Systems Security Engineering – Considerations for a Multidisciplinary Approach in the
Engineering of Trustworthy Secure Systems

*PDF : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1.pdf

*4)NIST : Cyber Supply Chain Risk Management

https://csrc.nist.gov/projects/cyber-supply-chain-risk-management