サプライチェーン攻撃に備えるためのENISAからの提言
本来の攻撃対象を直接攻撃するのではなく、攻撃対象が使用しているソフトウェアなどのサプライヤー（供給元）を介して攻撃する、いわゆる「サプライチェーン攻撃」というものがあります。サプライチェーン攻撃自体はさほど新しいものではないのですが、最近の「SolarWinds」や「Kaseya」のインシデントなどをきっかけに、その脅威が改めて認識されるようになってきています。
そのような中、欧州ネットワーク情報セキュリティ機関（ENISA：The European Union Agency for Cybersecurity）は、2020年1月から2021年7月初旬までに発見されたサプライチェーン攻撃、計24件を分析した結果を「Threat Landscape for Supply Chain Attacks」として公開しました。その中でENISAはサプライチェーン攻撃が2020年と比べて2021年には4倍に増えるだろうと予測しています。
報告書の中心は24件の攻撃についての分析結果で、具体的にSolarWindsやKaseyaのインシデントなどについても解説しています。
報告書全体の主要な点として挙げられているのは以下の通り。
- セキュリティコミュニティは攻撃の約50％を有名なAPTグループによるものとしている
- 分析対象の攻撃の約42％はまだ特定のグループによるものとは見なされていない
- 顧客に対する攻撃の約62％は顧客のサプライヤーに対する信頼を悪用している
- 62％のケースでは、マルウェアが攻撃手法として採用されている
- 標的となった資産について考えると、インシデントの66％において攻撃者は標的となった顧客をさらに危険にさらすためにサプライヤーのコードに焦点を当てている
- サブライチェーン攻撃の約58％がデータ（主に個人情報や知的財産を含む顧客データ）へのアクセスを目的としており、約16％が人へのアクセスを目的としている
- 全ての攻撃がサプライチェーン攻撃とされるわけではないが、その性質上、これらの攻撃の多くは将来的に新たなサプライチェーン攻撃につながる可能性がある
- 組織はサプライチェーン攻撃を念頭に置いてサイバーセキュリティの手法を更新し、全てのサプライヤーを保護とセキュリティ検証に組み込む必要がある
しかし、今回の報告書で最も注目すべきは第7章にまとめられた、サプライチェーン攻撃に備えるための提言です。報告書では顧客向けとサプライヤー向けに分けて紹介しており、いずれも基本的に欧州に限定されない一般的な内容となっています。
[顧客向け]
サプライチェーンのサイバーセキュリティリスクを管理するために顧客がすべきことは以下の通り。
- サプライヤーとサービスプロバイダーの種類を特定して文書化する
- さまざまな種類のサプライヤーとサービスのリスク基準を定義する（例えば、重要なサプライヤーと顧客の依存関係、重要なソフトウェアの依存関係、単一障害点など）
- サプライチェーンのリスクを自組織の事業継続の影響評価と要件に基づいて評価する
- グッドプラクティスに基づいてリスク処理のための手段を定義する
- 組織内外の情報源およびサプライヤーのパフォーマンスモニタリングとレビューから得られた知見に基づいて、サプライチェーンのリスクと脅威を監視する
- 担当者にリスクを認識させる
サプライヤーとの関係を管理するために顧客がすべきことは以下の通り。
- 生産やサポートが終了した製品またはコンポーネントを含む、製品またはサービスのライフサイクル全体にわたってサプライヤーを管理する
- サプライヤーと共有している、またはサプライヤーがアクセスできる資産と情報を分類し、そのアクセスと取り扱いに関する適切な手順を定義する
- 組織の資産の保護・情報の共有・監査権・事業継続性・人事考課・インシデントの処理に関するサプライヤーの義務を責任・通知義務・手順の観点から定義する
- 取得する製品とサービスのセキュリティ要件を定義する
- これら全ての義務と要件を契約に盛り込み、下請けのルールと潜在的に連なる要件について合意する
- サービスのパフォーマンスを監視し、決められた通りのセキュリティ監査を実施して同意済みのサイバーセキュリティ要件の遵守を検証する。これにはインシデント・脆弱性・パッチ・セキュリティ要件などの取り扱いが含まれる
- サプライヤーとサービスプロバイダーから隠し機能またはバックドアが故意に含まれていないことの保証を受ける
- 規制および法的要件が考慮されていることを保証する
- ツールや技術の変更など、サプライヤーとの契約における変更を管理するプロセスを定義する
[サプライヤー向け]
製品とサービスのセキュアな開発のためにサプライヤーがすべきことは以下の通り。
- 製品・コンポーネント・サービスの設計・開発・製造・提供に使用されるインフラストラクチャがサイバーセキュリティプラクティスに従っていることを保証する
- 一般的に受け入れられている製品開発プロセスと整合性のある製品開発・保守・サポートプロセスを実施する
- 一般的に受け入れられているセキュリティプラクティスに合致しているセキュアエンジニアリングプロセスを実施する
- 製品のカテゴリとリスクに基づいて技術的要件の適用性を検討する
- ISO/IEC 27001、IEC 62443-4-1、IEC 62443-4-2などの既知の規格（またはクラウドサービスに対する「CSA Cloud Controls Matrix（CCM）」などの特定の規格）に対する適合性証明書を顧客に提供し、製品の一部に使用されているオープンソースソフトウェアの完全性と出所を可能な限り確保して証明する
- 不具合の数または外部で確認された脆弱性や外部から報告されたセキュリティ問題のような品質目標を定義し、それらを全体的な品質を向上させる手段として使用する
- ソフトウェアのコードまたはコンポーネントの出所、およびソフトウェア開発プロセスに存在する組織内外のソフトウェアコンポーネント・ツール・サービスに適用される管理について、正確かつ最新のデータを維持する
- 上記の措置が達成されていることを保証するために定期的な監査を行う
脆弱性管理のためのグッドプラクティスとしてサプライヤーが実施すべきことは以下の通り。
- 使用されているサードパーティ製コンポーネントを含む、組織内外の情報源から報告されたセキュリティ脆弱性の監視
- 脆弱性スコアリングシステム（例えばCVSS）を使用した脆弱性のリスク分析
- 特定された脆弱性をリスクに応じて処理するためのポリシーの維持
- 顧客への情報提供プロセス
- 運用上も、安全上も、法律上も、そしてサイバーセキュリティ要件としても問題がないこと、かつ内蔵されていないサードパーティ製コンポーネントとパッチに互換性があることを保証するためのパッチの検証とテスト
- セキュアなパッチ配信のためのプロセスおよび顧客へのパッチに関する文書化
- 報告・開示プロセスを含む脆弱性開示プログラムへの参加
上記の提言に加え、主に顧客に向けたパッチ管理のグッドプラクティスとして以下を挙げています。
- パッチに関連する情報を含む資産のインベントリを維持する
- 関連する技術的な脆弱性を特定するために情報リソースを使用する
- 特定された脆弱性のリスクを評価し、文書化されて実施された保守ポリシーを利用できるようにする
- 正規の提供元からのみパッチを受け取り、インストール前にテストする
- パッチが利用できない、または適用できない場合には、代替手段を適用する
- ロールバック手順と効果的なバックアップおよび復元プロセスを適用する
また、個々の顧客やサプライヤーではなく、業界レベルで可能な取り組みもあり、その例としてGoogleの「Supply chain Levels for Software Artifacts（SLSA：サルサ）」を紹介しています。
ほかにも、サプライチェーン攻撃に特化したものではありませんが、サイバーセキュリティへの脅威から身を守るための一般的な提言として、MITREの「D3FEND」を紹介しています。
このように多くの提言がなされていますが、これらの提言の全てを忠実に守ったからといって、必ずしもサプライチェーン攻撃を防げる、または被害を軽減できるわけではありません。例えば、ハードウェアコンポーネントの隠し機能や文書化されていないアクセス機能（バックドア）は一般的な認証（検査済証）や標準的な侵入テストでは完全に特定することができないでしょうし、ゼロデイ脆弱性であればなおのこと困難でしょう。そのため、報告書では国や欧州レベルのアクションが必要かもしれないとし、さらに、サプライチェーン攻撃は高度な能力を持つ国家機関によって支援されている可能性があることから、各国の関連当局の支援が必要となるかもしれないともしています。
今回紹介した提言はいずれも「至極もっとも」な内容ではありますが、その全てを満たすのは現実的にはなかなか難しく、「理想主義」だと感じる人も多いでしょう。それでも、サプライチェーン攻撃への備えを検討する際の参考には間違いなくなるはずです。とにかく「完璧」を目指すのではなく、まずはできるところから手を付けてみてください。