手口が使われたと考えられています。中には、より広範な副次的被害を出す可能性のあったインシデントもありました。社などの組織が開発したアプリケーションは、世界中の多くの企業顧客に導入されています。社に影響があったと推定されています。した企業顧客のうち、別の組織のサプライチェーンの一部を担っていた企業は一体何社あったでしょうか。社の侵害の影響を受けていたことや、その影響がどの程度だったかについて、はっきり把握できていた企業は一体何社あったでしょうか。有名なサービスプロバイダーで発生したインシデントは、広範囲に影響を及ぼす可能性があります。直接の取引先の先にも取引関係がある可能性を考えると、検出はいっそう困難なものとなるかもしれません。直接の取引先の先の取引関係は、効果的なサプライチェーンのリスク管理を実現するうえで大きな障害となるのでしょうか。簡単な解決策や回避策はありません。サプライチェーンへの影響力が極めて大きく、すべての関連機関の監視を管理できるだけのリソースを備えた組織(米国連邦政府のような組織)でもない限り、そんなものは存在しないのです。サプライチェーン攻撃は、以前は国家の支援を受けたグループによって実行されることがほとんどでした。今では、さまざまなサイバー犯罪者が実行するようになっています。セキュリティ研究者が注目するこの変化の結果は明白です。攻撃件数が増加し、標的が増え(多様化し)、被害者も増えています。通常の更新プロセスを通じてプッシュされるソフトウェアのコアコンポーネントの改ざんなどが行われるようになっています。サプライチェーン攻撃の発生件数が急増しているため、かつては敬遠されていたこうした手口への対応は、サプライチェーンのリスク管理に欠かせないものとなっています。熟練のセキュリティチームでさえ、組織で使用されるソフトウェアのコード監査を実施することを考えるとうんざりするはずです。基幹業務アプリケーションの徹底的なコード監査を実施するのに必要なスキルセットを備えたサイバーセキュリティのゼネラリストはごくわずかです。した人材は、通常、組織の資産ではなく製品の監査に専念しています。内部コード監査を実施するうえで直面する課題の中には、内部リソースでは簡単に克服できないものもあります。そのため、リスクが黙認されたり、コード監査のための外部機関に頼ったりすることになります。次のような課題があります。組織のアプリケーションが記述されているプログラミング言語は何か。組織内に、当該プログラミング言語を扱った経験が豊富で、セキュリティ上の懸念事項を特定できる人材は存在するか。アプリケーションはオープンソースか、クローズドソース(独自仕様)か。クローズドソースの場合、コードを監査することはできるか。監査が必要なアプリケーションはいくつ存在するか。ソフトウェアインベントリは利用可能か、依存関係は把握できているか。発見された脆弱性への対応プロセスは存在するか。メーカーに支援を求められるか、それともアプリケーションを置き換える必要があるか。何事もないことを祈りつつ、最悪の事態に備えるサプライチェーンのインシデントシナリオの概要を理解し、サプライチェーンのリスク管理の課題を詳細に検討すれば、サプライチェーンのリスクを軽減するには予防だけでは不十分であることがわかります。これは、さほど驚くべきことではありません。年の間に予防から検出へ、さらに対応および復旧へと移り変わってきています。予防は重要ですが、サプライチェーンリスクに備えるにあたっては、対応についても検討する必要があります。組織とサプライチェーンの関係を橋のようなものと考えてみましょう。アプリケーションなどの技術コンポーネントで構成されています。チェックポイントを確立し、橋の上で何が起きているか監視し、建設計画中に議論を経て描き出した想定どおりの状態を維持していかなければなりません。そのために、橋の両端にいる組織は協力し合う必要があります。橋の片側でセキュリティイベントが発生すれば、どちらの組織も責任を負う可能性があります。問題が両者の境界を超えて拡大する可能性すらあるのです。ここで重要となるのが、サプライチェーンのインシデント対応に備えておくことです。インシデントへの対応策は、組織の既存のインシデント対応能力とドキュメントに基づいたものがよいでしょう。新しいものを作成する前に、すでに把握し実践されていることを活用するというわけです。サプライチェーンで発生したインシデントに対応する際、一般的なインシデント対応策の中でも重視すべきものがいくつかあります。従来型の社内インシデントの場合、インシデント対応チームはインシデントの特性を早急に把握しようとします。範囲、影響を受けるシステムとユーザー、予想されるビジネスへの影響やシビラティ(重大度)の分類、機密データが攻撃者によって侵害されたかどうかといったことです。した情報があれば、それを指針としてインシデント対応の取り組みに道筋をつけることができます。インシデントがベンダーの環境で発生した場合、情報共有を促進する関係が確立されていない限り、必要な情報を直接入手することはできません。インシデント情報を共有するという考え方は、ベンダーとビジネスの関係を構築する最初の時点から醸成する必要があります。既存のセキュリティ対策についてベンダーの関係者と話し合う場を設け、データの処理や保護についての期待値を設定することから始めます。話し合いの重要ポイントは次のとおりです。インシデント通知の要件。ベンダーが報告する必要があるインシデントの種類と重大度を定め、報告期間を決めます。インシデント発生時、ベンダーがセキュリティツールとログへのアクセスを組織に許可するかどうか。ほとんどのベンダーはこの要求を丁重に断りますが、特定の状況では受け入れることもあります(ベンダーが何らかの形で組織の傘下にある場合など)。その他の関連するインシデントデータがどのように共有されるかを努めて把握するようにしましょう。ベンダーは、対応プロセスの重要なタイミングでインシデントアンケートに回答するつもりがあるか。重要な質問を数問まとめた小規模なアンケートを作成して配布すれば、インシデントが発生して混乱している最中でも、簡単に有益なコミュニケーションを取れるようになる可能性があります。インシデント対応のプロセスで、関連情報を交換するのに最適なタイミングを決めておきましょう。インシデント発生時に両組織がやり取りする際の連絡窓口は誰か。誰に連絡するか、どうやって連絡を取りはじめるかが事前にわかっていれば、あらゆるインシデントに伴うストレスがいくらか軽減されます。した内容については、契約更新時など一定の頻度で既存のベンダーと話し合うようにするとよいでしょう。両方の組織がインシデント情報の共有に関する取り決めのステータスを評価し、必要に応じて調整する機会になります。サプライチェーンを構成する組織とのオープンなコミュニケーションラインを維持しておけば、優れた社内インシデント対応策の発見も促進されます。これは、「橋」のどちら側の組織にも有益です。「私のお気に入り」ではお気に入りのものがいろいろ挙げられていますが、資産管理はその中には含まれていません。言え、コード監査と同じく、資産管理はセキュリティチームにとって気の進まないものです。資産管理ソフトウェアの開発者が何と言おうとも、それさえやっておけば問題なく資産を追跡して管理できる方法など存在しません。それでもやはり、実行しないわけにはいきません。サプライチェーン攻撃が盛んな現代においては、実効性が重要となります。資産管理は、そのすべてによってもたらされるリスクの軽減に役立ちますが、追加策をいくつか紹介したいと思います。これにより、インシデント対応の一環として、資産管理が有効な役割を果たすようになります。アプリケーションのインベントリを作成し、ビジネスユースケースと関連するアクセス認証を文書化します。プロバイダーのセキュリティ担当者の連絡先を文書化し、インシデント対応時に迅速に連絡できるようにします。インシデントの封じ込めの一環として、各種アプリケーション、システム、ネットワークセグメントを意図的にシャットダウンした場合の影響を把握します。同様に、特定のベンダーのアクセスを遮断した場合のビジネスへの影響も把握します。復旧プロセスと関連する依存関係を文書化し、それらの資産を安全かつ有効な方法でオンラインに復帰させられるようにします。一部の関連情報は、ディザスタリカバリと事業継続計画に記載されている場合もありますが、資産の強制シャットダウンに関する詳細については、通常はこうしたリソースでは取り上げられません。組織のサプライチェーン構造を確認し、ベンダーとの間のデータフローとアクセスフローを明らかにします。どのベンダーがどのデータを持っているかを事前に把握しておけば、インシデントの重大度分類や通知要件を合理化できます。これにより、ベンダーからインシデント通知が発行された際、組織は一歩先んじることができます。この過程で、不適切なデータフローやアクセスフローを変更または削除することも可能です。テストとトレーニングテストとトレーニングは、重要な検証業務です。セキュリティチームは、ポリシー、手順、計画、コントロール、ツール、システムについて一日中話し合っていることもあります。実際にインシデントが発生した際、こうした保護機能についてテストやトレーニングを行っていなければ、せっかくの話し合いも無意味になってしまいます。サプライチェーンの侵害をテーマにした机上演習を開催し、重要なベンダーを招待します。机上演習は、組織の包括的なセキュリティ機能をテストする業界標準の手法であり、インシデント対応の準備には特に有効です。重要なベンダーの担当者を招待すれば、対応チームを調整し、連絡手段を確立する機会になります。すべての出席者間で通知に関する期待値を共有することもできます。外部のセキュリティプロバイダーと契約し、ベンダーが侵害された状況を想定してパープルチームの演習を実施します。レッドチームの担当者には重要ベンダー並みのアカウント権限とリモートアクセスを付与し、ベンダーアカウントが侵害された場合の結果をシミュレートします。ブルーチームの担当者が確実にレッドチームのアクションを検出できるようにします。関連するフォレンジックデータをツールから抽出し、インシデント対応者が確認できるようにします。資産および脆弱性管理プロセスをサポートする脆弱性スキャンアプリケーションを購入して展開します。ハードウェアとソフトウェアの両方の脆弱性に対処できる脆弱性修復サイクルを構築します。脆弱性スキャンレポートは、インシデント対応時には参考資料としても使用できます。テストやトレーニング中に、管理制御(計画、ポリシー、手順、担当者)または技術的制御(セキュリティコントロール、ツール)のギャップが特定されることもあります。その場合は、テスト終了後に適切なチャネルを通じて対処する必要があります。