取引先に起因するリスク：Talos IR でサプライチェーン攻撃に備える
- サプライチェーン攻撃は、頻度が増すとともに巧妙化しており、組織が直接管理している領域の外までアタックサーフェス（攻撃対象領域）が広がっています。こうした状況を踏まえると、インシデントへの準備と対応については、サプライチェーンのリスク軽減戦略全体の中で検討する必要があります。
- サプライチェーン攻撃の一般的なリスクカテゴリは 3 つあります。SaaS アプリケーションに起因するリスク、サードパーティベンダーのアクセスに起因するリスク、ソフトウェア サプライチェーンに起因するリスクの 3 つです。カテゴリごとにシナリオを作成して、サプライチェーンにおけるデータフローとアクセスフローを示し、発生源ごとにインシデントの影響を理解するとよいでしょう。
- 組織がサプライチェーンリスクを評価しようとしても、ベンダーが行っている採用プロセスに関する情報や、直接の取引先ではないベンダーについての可視性は限られており、コードを効果的に監査する能力などにも限界があります。こうした限界が原因で、サプライチェーンリスクを効果的に管理するのが難しくなる場合があります。
- サプライチェーン インシデントへの対応手法は、詳細に文書化されたインシデント対応策に基づいて構築するとよいでしょう。組織は、サプライチェーン インシデントへの対応能力を高めるとともに、ベンダーとのコミュニケーションを拡大し、資産管理を強化することを検討する必要があります。また、インシデント対応についての徹底的なテストとトレーニングのプログラムを開発して採用することも検討すべきです。
バイオテロの専門家である Leonard A. Cole 氏はかつて、「人は友人の行動に責任を持てないが、その人の評価は交友関係で決まる」と語りました。
他にも尊敬に足る思想家たちが、言葉は違えど同じ主旨のことを言っています。個人的な交友関係や仕事上の関係が、社会的信用や会社の存続に直接影響を及ぼしかねないというものです。企業のセキュリティ対策（特に、組織のサプライチェーンを構成するベンダーやビジネスパートナーの選択）にこの知恵を応用してみると、サプライチェーン攻撃からの防御を目的としてインシデントの予防と対応に取り組むうえでどうバランスを取ればよいのか、さまざまな疑問が浮かんできます。
組織は、ベンダーやビジネスパートナーの行動にどの程度責任を負うのか、また取引先の行動によりどのような影響を受ける可能性があるのか。組織の資産と社会的信用を守るための予防的な戦略として、十分にベンダー選定を行っているか。あるいは、避けられない事態に備え、サプライチェーン インシデントへの対応能力を高める必要があるのか。
こうした疑問の数々に答えるには、一般的なサプライチェーンのリスクシナリオとリスク管理に関連する課題を把握することが重要です。また、サプライチェーンにおけるインシデントに対応するために採用できる具体的な手段を理解する必要もあります。
MITRE によると
、サプライチェーンの侵害とは「デバイスやソフトウェアなどの製品やそれらの配送メカニズムを、最終消費者が受け取る前に操作すること」です。これは、攻撃者が組織の重要なビジネスの供給経路において事業体や製品を侵害し、その組織の属する「社会集団」に侵入した結果とも言い換えられます。
攻撃者がサプライチェーンを利用した攻撃を好む具体的な理由はさまざまですが、その中にリソースの節約と高価値の標的への間接的なアクセスが含まれることは間違いありません。比較的脆弱な標的（サプライチェーン内のベンダーやパートナー）を侵害すれば、ずっと短期間で主要な標的に対する直接的で信頼できるアクセスを取得できます。であれば、わざわざカスタムマルウェアや複雑なソーシャルエンジニアリング攻撃をはじめとするサイバーキルチェーンの構築に何週間も費やそうとはしないでしょう。一番楽な道を選ぶはずです。
このため、組織のアタックサーフェスの概念には、保護された環境だけでなく、組織が所有または管理していない資産や事業体も含まれるようになりました。組織は、サプライチェーンで絶えず発生するインシデントへの対応に備える一方で、取引する企業の選定を慎重に行ってサプライチェーンのリスクをプロアクティブに抑制する必要があります。サプライチェーン インシデントへの対応を具体的に検討する前に、一般的なサプライチェーンのリスクシナリオと、サプライチェーンのリスク管理に関連する課題を理解しておくとよいでしょう。
サプライチェーンのリスクシナリオ
セキュリティインシデントに同じものは 2 つとありません。したがって、サプライチェーン攻撃を侵害の兆候（IOC）や攻撃者の戦術、手法、手順（TTP）によって分類しようとするのは、的外れとは言えないものの効率的ではないでしょう。ですが、ある組織とその取引先（ベンダーやビジネスパートナー）との間のアクセスおよびデータの共有関係に基づいて、サプライチェーンのリスクシナリオをおおまかにまとめることは可能です。このアプローチを使うと、サプライチェーンのリスクは、Software as a Service（SaaS）アプリケーションに起因するもの、サードパーティベンダーのアクセスに起因するもの、ソフトウェア サプライチェーンに起因するものに分類できます。
これらのシナリオは、相互排他的なものではありません。攻撃者のキルチェーンに、2 つまたは 3 つすべてのシナリオが同時に含まれる場合もあります。
SaaS アプリケーション
SaaS アプリケーションとは、サードパーティがクラウドでホストしているアプリケーションやサービスのことです。基本的なクラウドストレージだけでなく、生産性ツール（Microsoft 365 など）、ソーシャルメディアと通信、データのモニタリングと管理、ビジネス サービス アプリケーション、教育など多岐にわたります。
SaaS アプリケーションでは、ユーザーアクセスやデータ共有のフローは、組織からベンダーへの流れとなります。ユーザーは、自分のデータを SaaS プロバイダーのクラウドに送信または保存したうえで、SaaS アプリケーションにアクセスしてデータ操作を行います。この場合のサプライチェーンのリスクは、ベンダーのシステムが侵害を受けることに起因し、結果的に機密データの漏洩やユーザーのログイン情報の侵害につながります。
サードパーティベンダーのアクセス
提携事業者、パートナー、サードパーティベンダーは、世界中の無数の組織の運営にとって不可欠な存在です。サードパーティの専門企業に一切アウトソーシングすることなく、1 つの組織が単独で事業運営に必要な製品やサービスを効果的に生産することはほぼ不可能です。場合によっては、サービスを提供するためにサードパーティがその組織の環境にアクセスする必要もあります。
ある環境へのインバウンドアクセスが発生するたびに、リスクが生じることになります。ユーザーアクセスやデータ共有のフローは、サードパーティベンダーから組織への流れとなります。ベンダーの従業員は、システムとデータを管理またはモニタリングするため、組織の内部環境にアクセスします。この場合、サプライチェーンリスクが発生するのは、ベンダーで発生したセキュリティインシデントの影響が、そのベンダーの信頼できるアクセスを介して組織に及んだ場合です。もしくは、ベンダーが組織のシステムやデータを誤った方法で使用したり、悪用したりする場合にも発生します。
ソフトウェア サプライチェーン
組織のソフトウェア サプライチェーンは、組織が業務を維持するために必要なソフトウェアとアプリケーションで構成されています。組織が直接取引しているソフトウェアベンダーだけでなく、それらのベンダーが使用しているコンポーネント、ライブラリ、ツールを開発するあらゆるソフトウェアプロバイダーもソフトウェア サプライチェーンに含まれるということに注意が必要です。このため、組織のソフトウェア サプライチェーンを構成する企業によってもたらされる脅威は、SaaS アプリケーションやサードパーティベンダーのアクセスに起因する脅威に比べ、いっそう特定が難しいというのが通常です。
ここでは、サードパーティベンダーによって開発されたソフトウェアが組織の環境の一部となっており、ユーザーアクセスやデータ共有のフローは、サードパーティベンダーから組織への流れとなります。この場合のサプライチェーンリスクは、組織に広がる可能性のある侵害を受けたベンダーアプリケーションを組織がインストールした場合に発生します。
サプライチェーンのリスク管理の課題
ベンダーとサプライチェーンのリスク管理は、最近再び脚光を浴びるようになりました。おそらく、この 3 ～ 5 年間、世間の注目を集めるサプライチェーン侵害が次々と発生した影響でしょう。2017 年より前に公開されたサプライチェーン攻撃に関する記事をインターネットで検索すると、950 万件の結果が表示されます。特に関連性の高い検索結果の多くは、Target 社が被害を受けた 2013 年の悪名高いデータ侵害について直接的もしくは間接的に記述している記事です。一方、2016 年以降に公開された記事を同様に検索すると、3,970 万件の結果が表示されます。記事の内容は、さまざまな攻撃事例、準備対策、規制基準への言及などです。サプライチェーン攻撃に関連するコンテンツは、公開頻度も量も増加しており、サプライチェーンの脆弱性や脆弱性への対処に伴う複雑さについて組織が懸念を抱いていることを物語っています。検討が必要な事項には、次のようなものがあります。
- 知的財産やその他の機密データを含む組織データの分散化がこれまでになく進んでいる（サードパーティによってデータが処理、送信、保存されている）。
- 自組織のサプライチェーンに起因するリスクから自らを守るだけでなく、別の組織のサプライチェーンで発生したインシデントに不本意ながら巻き込まれてしまうという事態を避ける必要がある。
- 規制当局がニュースを注視しており、サプライチェーンのリスク管理要件を定める規制基準がますます増えてきている。
ベンダーとサプライチェーンのリスク管理プログラムについてインターネットを検索すれば、よくまとまったガイダンスが大量に見つかります。ベンダーのリスク管理を一から検討し直すよりも、サプライチェーンのリスク管理の課題を生む要因となっている複雑さに目を向けた方がよいでしょう。以下に挙げる要因は、最近のセキュリティ調査と業界ニュースに基づいており、上述したリスクシナリオにも関連しています。
ベンダーが採用する人材
人材面でのセキュリティは、長い間ベンダーリスクをめぐる懸念事項となってきました。データの所有者は、犯罪目的やその他の理由でデータを不正に管理したことのある人物によって自分のデータとシステムが扱われることのないようにしたいと考えるものです。ベンダーリスクアンケートには、「従業員に対し、採用条件として身元調査を義務付けていますか？」といった質問がよく出てきます。ベンダーがその質問に「はい」と答えたとしても、悪意のある内部関係者が存在するリスクはどの程度軽減されるものでしょうか。
フロリダ州タンパのソフトウェアエンジニア、Connor Tumbleson 氏のケースを見てみましょう。最近になって Tumbleson 氏は、見ず知らずの人物（あらゆる意図と目的からして「攻撃者」）が、リモート ソフトウェア エンジニアとしての仕事に就くために同氏の職務経歴を利用していたことに気付きました。インシデントの全容と、Tumbleson 氏が個人的に行った調査は同氏のブログで読むことができますが、この攻撃者の目論見をまとめると、次のようなものになります。
- 契約業務の求人サイトに、正規の専門職の職務経歴をもとにして不正なプロファイルを設定する。
- 不正なプロファイルを使用して仕事に応募する。
- 面接まで漕ぎつけたら、正規の人物と同様のスキルセットを備えていて、採用企業とのオンライン面接でなりすましをしてくれる人間を探す。
- 面接に合格して採用企業が内定を出せば、その仕事に就ける。
このシナリオの場合、提携する可能性がある事業者が従業員の身元調査に関する質問に「はい」と答えたとしても無意味だということになります。身元調査の少なくとも一部は、採用されている人物ではなく、組織が採用していると思っている人物についての調査結果だということになるからです。
さまざまな調査が示すように、組織内に潜む脅威は引き続き攻撃チェーンの重要な要素となっています。このため、セキュリティチームはサプライチェーン構成企業の採用プロセスを詳細に確認し、ベンダーの従業員と採用方法について徹底的に把握する必要があります。
取引先の提携ベンダー
サプライチェーンのリスク管理の対象といえば、通常は 1 次取引先までです。組織と直接的なやり取りのあるベンダーやサプライヤが主な対象となります。それより先のサプライチェーンは把握するのが難しく、2 次取引先の提携先となると、まったく把握できていない場合もあります。そのため、セキュリティチームには、ほぼ未知のリスク群を管理するという、とらえどころのない業務が課されることになります。
過去 10 年間に発生した有名なソフトウェア サプライチェーン インシデントの多くでは、最終的に攻撃を受けた企業の 1 次取引先が、攻撃者の初期アクセスのベクトルとなっていました。標的となった企業は、HVAC 請負業者のいずれかを通じて侵害を受けていたのです。Audi/Volkswagen 社のデータ侵害は、ベンダーの 1 社が顧客情報をセキュリティ保護されていないインターネットリポジトリに残したために発生しました。攻撃グループ Lapsus$ がライドシェアリング企業である Uber 社のシステムにアクセスした最近の事例では、同社の請負業者のアカウントを侵害する手口が使われたと考えられています。
中には、より広範な副次的被害を出す可能性のあったインシデントもありました。Mimecast 社、SolarWinds 社、Kaseya 社などの組織が開発したアプリケーションは、世界中の多くの企業顧客に導入されています。SolarWinds 社の侵害だけでも、18,000 社に影響があったと推定されています。そうした企業顧客のうち、別の組織のサプライチェーンの一部を担っていた企業は一体何社あったでしょうか。また、自社のサプライチェーンを構成する企業が SolarWinds 社の侵害の影響を受けていたことや、その影響がどの程度だったかについて、はっきり把握できていた企業は一体何社あったでしょうか。有名なサービスプロバイダーで発生したインシデントは、広範囲に影響を及ぼす可能性があります。直接の取引先の先にも取引関係がある可能性を考えると、検出はいっそう困難なものとなるかもしれません。
では、直接の取引先の先の取引関係は、効果的なサプライチェーンのリスク管理を実現するうえで大きな障害となるのでしょうか。もちろんそうですが、簡単な解決策や回避策はありません。サプライチェーンへの影響力が極めて大きく、すべての関連機関の監視を管理できるだけのリソースを備えた組織（米国連邦政府のような組織）でもない限り、そんなものは存在しないのです。
自社環境で実行されているコード
ソフトウェア サプライチェーン攻撃は、以前は国家の支援を受けたグループによって実行されることがほとんどでした。ですが今では、さまざまなサイバー犯罪者が実行するようになっています。セキュリティ研究者が注目するこの変化の結果は明白です。攻撃件数が増加し、標的が増え（多様化し）、被害者も増えています。ソフトウェア サプライチェーン攻撃に関連する攻撃者の TTP も多様化しました。開発者アカウントの窃取、認証証明書の窃取、通常の更新プロセスを通じてプッシュされるソフトウェアのコアコンポーネントの改ざんなどが行われるようになっています。ソフトウェア サプライチェーン攻撃の発生件数が急増しているため、かつては敬遠されていたこうした手口への対応は、サプライチェーンのリスク管理に欠かせないものとなっています。
熟練のセキュリティチームでさえ、組織で使用されるソフトウェアのコード監査を実施することを考えるとうんざりするはずです。基幹業務アプリケーションの徹底的なコード監査を実施するのに必要なスキルセットを備えたサイバーセキュリティのゼネラリストはごくわずかです。そうした人材は、通常、組織の資産ではなく製品の監査に専念しています。内部コード監査を実施するうえで直面する課題の中には、内部リソースでは簡単に克服できないものもあります。そのため、リスクが黙認されたり、コード監査のための外部機関に頼ったりすることになります。たとえば次のような課題があります。
- 組織のアプリケーションが記述されているプログラミング言語は何か。組織内に、当該プログラミング言語を扱った経験が豊富で、セキュリティ上の懸念事項を特定できる人材は存在するか。
- アプリケーションはオープンソースか、クローズドソース（独自仕様）か。クローズドソースの場合、コードを監査することはできるか。
- 監査が必要なアプリケーションはいくつ存在するか。ソフトウェアインベントリは利用可能か、依存関係は把握できているか。
- 発見された脆弱性への対応プロセスは存在するか。メーカーに支援を求められるか、それともアプリケーションを置き換える必要があるか。
何事もないことを祈りつつ、最悪の事態に備える
サプライチェーンのインシデントシナリオの概要を理解し、サプライチェーンのリスク管理の課題を詳細に検討すれば、サプライチェーンのリスクを軽減するには予防だけでは不十分であることがわかります。これは、さほど驚くべきことではありません。防御する側の基本戦略は、過去 10 年の間に予防から検出へ、さらに対応および復旧へと移り変わってきています。予防は重要ですが、サプライチェーンリスクに備えるにあたっては、対応についても検討する必要があります。
組織とサプライチェーンの関係を橋のようなものと考えてみましょう。この橋は、サイト間 VPN 接続や SaaS アプリケーションなどの技術コンポーネントで構成されています。橋にはメンテンナンスが必要ですし、セキュリティ チェックポイントを確立し、橋の上で何が起きているか監視し、建設計画中に議論を経て描き出した想定どおりの状態を維持していかなければなりません。そのために、橋の両端にいる組織は協力し合う必要があります。橋の片側でセキュリティイベントが発生すれば、どちらの組織も責任を負う可能性があります。さらには、問題が両者の境界を超えて拡大する可能性すらあるのです。ここで重要となるのが、サプライチェーンのインシデント対応に備えておくことです。
サプライチェーン インシデントへの対応策は、組織の既存のインシデント対応能力とドキュメントに基づいたものがよいでしょう。新しいものを作成する前に、すでに把握し実践されていることを活用するというわけです。ただし、サプライチェーンで発生したインシデントに対応する際、一般的なインシデント対応策の中でも重視すべきものがいくつかあります。
ベンダーとのコミュニケーションの拡大
従来型の社内インシデントの場合、インシデント対応チームはインシデントの特性を早急に把握しようとします。たとえば範囲、影響を受けるシステムとユーザー、予想されるビジネスへの影響やシビラティ（重大度）の分類、機密データが攻撃者によって侵害されたかどうかといったことです。こうした情報があれば、それを指針としてインシデント対応の取り組みに道筋をつけることができます。ですが、インシデントがベンダーの環境で発生した場合、情報共有を促進する関係が確立されていない限り、必要な情報を直接入手することはできません。
インシデント情報を共有するという考え方は、ベンダーとビジネスの関係を構築する最初の時点から醸成する必要があります。既存のセキュリティ対策についてベンダーの関係者と話し合う場を設け、データの処理や保護についての期待値を設定することから始めます。話し合いの重要ポイントは次のとおりです。
- インシデント通知の要件。ベンダーが報告する必要があるインシデントの種類と重大度を定め、報告期間を決めます。
- インシデント発生時、ベンダーがセキュリティツールとログへのアクセスを組織に許可するかどうか。ほとんどのベンダーはこの要求を丁重に断りますが、特定の状況では受け入れることもあります（ベンダーが何らかの形で組織の傘下にある場合など）。ツールとログへの直接アクセスが許可されない場合、IOC やその他の関連するインシデントデータがどのように共有されるかを努めて把握するようにしましょう。
- ベンダーは、対応プロセスの重要なタイミングでインシデントアンケートに回答するつもりがあるか。重要な質問を数問まとめた小規模なアンケートを作成して配布すれば、インシデントが発生して混乱している最中でも、簡単に有益なコミュニケーションを取れるようになる可能性があります。インシデント対応のプロセスで、関連情報を交換するのに最適なタイミングを決めておきましょう。
- インシデント発生時に両組織がやり取りする際の連絡窓口は誰か。誰に連絡するか、どうやって連絡を取りはじめるかが事前にわかっていれば、あらゆるインシデントに伴うストレスがいくらか軽減されます。
こうした内容については、契約更新時など一定の頻度で既存のベンダーと話し合うようにするとよいでしょう。両方の組織がインシデント情報の共有に関する取り決めのステータスを評価し、必要に応じて調整する機会になります。サプライチェーンを構成する組織とのオープンなコミュニケーションラインを維持しておけば、優れた社内インシデント対応策の発見も促進されます。これは、「橋」のどちら側の組織にも有益です。
資産管理の強化
作曲家のロジャースと作詞家のハマースタインが手がけたミュージカル『サウンド・オブ・ミュージック』の楽曲の 1 つ「私のお気に入り」ではお気に入りのものがいろいろ挙げられていますが、資産管理はその中には含まれていません。欠かせない対策の 1 つとは言え、コード監査と同じく、資産管理はセキュリティチームにとって気の進まないものです。資産管理ソフトウェアの開発者が何と言おうとも、それさえやっておけば問題なく資産を追跡して管理できる方法など存在しません。ただ、それでもやはり、実行しないわけにはいきません。特にサプライチェーン攻撃が盛んな現代においては、実効性が重要となります。
本記事では、サプライチェーンのリスクシナリオを 3 つ説明しました。資産管理は、そのすべてによってもたらされるリスクの軽減に役立ちますが、追加策をいくつか紹介したいと思います。これにより、インシデント対応の一環として、資産管理が有効な役割を果たすようになります。
- 組織が活用している SaaS アプリケーションのインベントリを作成し、ビジネスユースケースと関連するアクセス認証を文書化します。さらに一歩進んで、SaaS プロバイダーのセキュリティ担当者の連絡先を文書化し、インシデント対応時に迅速に連絡できるようにします。
- インシデントの封じ込めの一環として、各種アプリケーション、システム、ネットワークセグメントを意図的にシャットダウンした場合の影響を把握します。同様に、特定のベンダーのアクセスを遮断した場合のビジネスへの影響も把握します。復旧プロセスと関連する依存関係を文書化し、それらの資産を安全かつ有効な方法でオンラインに復帰させられるようにします。一部の関連情報は、ディザスタリカバリと事業継続計画に記載されている場合もありますが、資産の強制シャットダウンに関する詳細については、通常はこうしたリソースでは取り上げられません。
- 組織のサプライチェーン構造を確認し、ベンダーとの間のデータフローとアクセスフローを明らかにします。どのベンダーがどのデータを持っているかを事前に把握しておけば、インシデントの重大度分類や通知要件を合理化できます。これにより、ベンダーからインシデント通知が発行された際、組織は一歩先んじることができます。この過程で、不適切なデータフローやアクセスフローを変更または削除することも可能です。
テストとトレーニング
テストとトレーニングは、重要な検証業務です。セキュリティチームは、ポリシー、手順、計画、コントロール、ツール、システムについて一日中話し合っていることもあります。しかし、実際にインシデントが発生した際、こうした保護機能についてテストやトレーニングを行っていなければ、せっかくの話し合いも無意味になってしまいます。
- サプライチェーンの侵害をテーマにした机上演習を開催し、重要なベンダーを招待します。机上演習は、組織の包括的なセキュリティ機能をテストする業界標準の手法であり、インシデント対応の準備には特に有効です。重要なベンダーの担当者を招待すれば、対応チームを調整し、連絡手段を確立する機会になります。また、すべての出席者間で通知に関する期待値を共有することもできます。
- 外部のセキュリティプロバイダーと契約し、ベンダーが侵害された状況を想定してパープルチームの演習を実施します。レッドチームの担当者には重要ベンダー並みのアカウント権限とリモートアクセスを付与し、ベンダーアカウントが侵害された場合の結果をシミュレートします。ブルーチームの担当者が確実にレッドチームのアクションを検出できるようにします。また、関連するフォレンジックデータをツールから抽出し、インシデント対応者が確認できるようにします。
- 資産および脆弱性管理プロセスをサポートする脆弱性スキャンアプリケーションを購入して展開します。ハードウェアとソフトウェアの両方の脆弱性に対処できる脆弱性修復サイクルを構築します。脆弱性スキャンレポートは、インシデント対応時には参考資料としても使用できます。
テストやトレーニング中に、管理制御（計画、ポリシー、手順、担当者）または技術的制御（セキュリティコントロール、ツール）のギャップが特定されることもあります。その場合は、テスト終了後に適切なチャネルを通じて対処する必要があります。
本稿は 2022 年 11 月 08 日に Talos Group
Tags:
