日常茶飯事の「サプライチェーン攻撃」のカオスな実態とは？「セキュリティのアレ」の3人が事例から解き明かす：ITmedia Security Week 2024 秋

2024年11月27日、「ITmedia Security Week 2024 秋」の「クラウドセキュリティ」ゾーンで、ポッドキャスト「セキュリティのアレ」に出演する根岸征史氏、辻伸弘氏、piyokango氏が「繋ぐ楔と断ち切る楔」と題してパネルディスカッションに登壇した。

[宮田健，＠IT]

　楔（くさび）は2つのものを固定することもできれば、割ることもできる。いや応なく“つながる”ことがネットの強みでもあり、弱みでもある。セキュリティの文脈において、“くさび”をどう定義付けるべきだろうか。「サプライチェーン攻撃」とも表現される、目の前にある大きな課題を通じ、3人の鼎談（ていだん）から“くさび”の姿を形作っていこう。

左からSBテクノロジー 辻伸弘氏、piyokango 氏、インターネットイニシアティブ 根岸征史氏

「サプライチェーン攻撃」には3つの種類がある

　最近報道されるサイバー攻撃の多くが、「サプライチェーン攻撃」に関連する。辻氏らは今回のテーマとなるサプライチェーン攻撃を「経済活動における流れの過程を狙ったサイバー攻撃」と説明した上で、これらを3つの種類に分類する。

　1つ目は「ソフトウェア」に関連するサプライチェーンだ。ソフトウェアの開発や提供の工程、そしてアップデートサーバや開発者のPCを侵害し、正規のソフトウェアを汚染して標的となる組織に配布するといった攻撃手法を採る。「ソフトウェアサプライチェーン攻撃」といわれるが、これが「サプライチェーン攻撃」と表現されることも多い。

サプライチェーン攻撃の3つの姿

　2つ目は「サービス」に関連するサプライチェーン攻撃だ。マネージドサービスプロバイダー（MSP）やクラウドサービス事業者のシステムを侵害し、MSPや事業者の顧客に攻撃する。MSPを踏み台にしたり、クラウドサービスが止まったりすることで事業に影響を受けてしまう。

　3つ目は「ビジネス」に関するサプライチェーン攻撃だ。特定組織の支店や子会社、取引／委託先などを侵害し、それらを経由して関連する組織を攻撃する。委託先に情報を預けるようなビジネスの場合、委託先から情報が漏えいしてしまう。この「ビジネス」と2つ目の「サービス」は形が似ているが、「考えるリスクが別なので分けて考えたい」と根岸氏は話す。

　3人は各種「サプライチェーン攻撃」について、事例を基にリスクや考えるべきポイントを紹介する

事例1：ソフトウェアサプライチェーン攻撃では“つながり”の“つながり”も狙われる

　1つ目の「ソフトウェアサプライチェーン」の事例は、“サプライチェーンのサプライチェーン”が侵害された「3CX」の事例だ。3CXはオープンプラットフォームのオフィス用電話システムで、海外では約60万社が利用する大手のベンダーだ。

　今回の事例は、3CXの正規のインストーラーが改ざんされた状態で3CX利用者に配布されてしまい、多くのエンドユーザーにマルウェアが混入されたというものだ。ソフトウェアの正式なアップデータが侵害されたことにより、既存のセキュリティ施策が有効に機能しなかったことが大きな問題となった。

3CXにおけるソフトウェアサプライチェーン攻撃の事例

　辻氏は「この原因が興味深かった」と述べる。きっかけは、3CXの従業員が個人的に使っていた金融関係のソフトウェアにマルウェアが混入したことだった。これにより、従業員端末に残っていた、3CX開発環境へのアクセスを許す認証が奪われた。攻撃者はターゲットを3CXに切り替え、奪った認証情報から社内に侵入。3CXの開発環境を侵害し、アップデートを通じてさらに感染を拡大させた。

　「おそらく、たまたま攻撃が成功した端末の中に3CXの従業員のものがあった。結果として、2つのサプライチェーンが結ばれた事例だ」（辻氏）

攻撃者は金融系ソフトウェアのサプライチェーン攻撃を実施。そのとき、たまたま3CXの開発者が被害に遭い、そこからさらに3CXのサプライチェーン攻撃に“つなげた”

　攻撃者から見ればラッキーな事例だが、個人がサプライチェーン攻撃を媒介してしまったのは不運としか言いようがない。「珍しい事例。業務と無関係のソフトウェアが穴になるというのは想定しにくい」と根岸氏。辻氏は端末にインストールできるアプリを制限するなどの対処を述べ、「やりたいけど、なかなかできない」という現状も指摘する。社内で利用できるアプリのホワイトリスト化などが想定できるが、「今回のような事例では、正規のアップデートパスを通り、開発企業の正規な署名も入っている。そうなると、EDR（Endpoint Detection and Response）で検知して対応するのが最後の“とりで”になる」と根岸氏は指摘する。

　しかし、そこにも大きな落とし穴がある。実は、この3CXにおけるマルウェア混入に関してはEDRによる検知ができていたという。関連するフォーラムでは3CXに関連し、EDRが不正な挙動を検知したという報告が上がっていたが、正規のアップデートであることから「誤検知ではないか」と結論付けられてしまったという記録が残っている。結果として、それはまさにEDRが不正を検知した瞬間だったが、人の先入観によってスルーされた形だ。後日、セキュリティベンダーによって本件は明るみに出る。

　「EDRが宝の持ち腐れになりかねない。この事例から、運用面の課題も大きいということが一番気になった」（根岸氏）

　加えて、piyokango氏は「個人端末を開発に使うようなBYOD（Bring Your Own Device）の場合、見直す余地があったのではないか」と指摘する。端末の制御がしっかりできていれば防げたのかもしれず、その点を意識する必要がある。加えて、セキュリティベンダーを含め、情報共有の仕組みがあれば、自分が気付けなくても誰かが気付くことができる。さまざまな観点の発見がある事例だ。

事例2：サービスサプライチェーン攻撃で考えるべきリスク、責任分界点

　2つ目は、「サービスサプライチェーン」に関する攻撃事例を追う。攻撃者によってクラウドサービスが狙われた場合、その被害はクラウドサービス事業者にとどまらず、それを利用する顧客企業、さらにはその顧客が持つエンドユーザーにまで被害は拡大する。この3者の関係を基に、自分たちにどの程度のリスクが存在するかをもう一度考えてみよう。

クラウドサービスが狙われたときの影響範囲は？

　根岸氏はサービスを狙うサプライチェーン攻撃に関して、2つの事例を取り上げる。まずは2023年6月に発生した、エムケイシステムが提供する「社労夢」のランサムウェア被害だ。エムケイシステムが侵害を受けた結果、サービス停止は1カ月ほど続き、サービスを利用する社会保険労務士だけでなく、労務士のエンドユーザーとなる企業にも影響が発生した。

• 当社サーバーへの不正アクセスに関する調査結果のご報告 | 社労夢｜社労士業務のクラウドシステム

　もう一つは、Oktaのサポート管理システムへの不正アクセスだ。この不正アクセスから、Oktaを利用する企業の認証トークンが盗まれ、顧客企業の管理コンソールへの侵入を許してしまう。これにより、Oktaを利用するCloudflareが侵入されていたことが判明した。

• CloudflareがOktaのさらなるセキュリティ侵害を軽減した方法

　クラウドサービスが狙われ、利用者が影響を受けるのは、多くのSaaSやメールサービスも同様だ。攻撃者の狙いはさまざまで、単にたまたま狙えたから狙ったというものもあれば「もしかしたら、守りの堅い会社を直接ではなく、クラウド経由で攻撃するという意図があったのかも」（根岸氏）という考え方もできる。

　「その場合、自分たちの守りだけしっかりすればいいというわけではない。サプライチェーンのどこかに弱点が残り、そこを狙われることも考えなくてはならない」（根岸氏）

　加えて、これが全てサービス事業者のみの責任になるのかという点も考える必要がある。例えば今回であれば、管理コンソールが多要素認証などで強化されなかったことも報告されているという。

　「どこまで自分たちでカバーすべきかという責任分解点は考える必要がある。特にクラウドサービスの利用には『自分たちだけで全てを閉じることができない』という難しさがある。『自分たちだけ守っていればいい』という時代はもう終わった。その上で、サービスを選定するときや『このサービスを使おう』となったとき、『オンプレミスからクラウドに切り替えよう』となったときに、利用サービスが侵害されて停止するなどのリスクを事前に考えるのも大事だ。これらの事件が『自社で起きたとしたら……』と考えるきっかけになれば」（根岸氏）

事例3：ビジネスサプライチェーン攻撃はカオスな状況、逆にチャンスとなる

　3つ目の「ビジネスサプライチェーン」への攻撃については、piyokango氏が数字を基にして全体の傾向を考える。2024年に公表されたインシデントを集計したところ、「業務委託先が起因となるインシデント」と発表されているのは208件。その中で業務委託先として個社名が明記されているのは16組織あった。つまり、16の組織を攻撃したことで、それが208社に波及したと考えることができる。

ビジネスを狙うサプライチェーン攻撃の波及を数字データで見る

　piyokango氏はさらに、この中身をチェックする。すると、そこには偏りがあったという。委託元が10件を超えている組織の数は16からさらに減り、わずか5組織が全体の88％を占めることが分かった。その5組織のうち、4つの組織がランサムウェア攻撃であることが公表されている。つまり、業務委託先が被害に遭い、加えてそれがランサムウェア攻撃だった場合、情報流出や業務停止の可能性があり、影響が広範囲に及んだり、深刻化したりする恐れがある。

　piyokango氏はこの集計／分析結果に続き、委託元・委託先それぞれにおける対策の要点を紹介する。

　委託元としては、委託先に対してセキュリティ要件をどこまで求めるか、求めることができるのかを考える必要がある。要求レベルを高めることは簡単だが、それはコストに跳ね返るだけでなく、委託先の数も絞られてしまう。また、委託元がコントロールできる範囲は限定され、事案が発生したときに対応が後手に回ることも想定しなければならない。

　「公表されている事例からも、伝言ゲームになる部分も多く、かつては『ウチは大丈夫か？』と聞いていたが、『あなたたちは大丈夫か？』みたいなことになり得る」（辻氏）

対策をどう検討するか？

　業務委託先においても、平時からの備え、体制をどう維持するかが課題となる。いつ攻撃を受けるかは誰も予測できず、とはいえ平時から潤沢なセキュリティ体制を保つのも難しい。加えて、多くの顧客、エンドユーザーを抱えることになるので、インシデントが起きたときに、1社で対応できるレベルではなくなる可能性がある。例えばトラブル時のプレスリリース作成を始め、情報をどう統制していくかという課題があるという。「顧客のある一社から強烈なプッシュを受け、ちょっと細かい情報を出したとする。すると、それが大きく拡散され、その情報を直接受けていない他の顧客は疑心暗鬼になってしまう」（piyokango氏）

　このカオスな状況の中でも、それを“チャンス”に変えることもできるかもしれない。辻氏は「サービスを提供する企業が数社存在するならば、委託先は『ウチは、もしインシデントが発生してもこういうセキュリティの仕組みを入れています』といったアピールができれば、それがブランドになる。安心して情報を預けられる施策を持っているならば、今こそそれをアピールするチャンスとなるはずだ」と強調する。根岸氏も「そういう方向を目指すべきだ。どこかがやらないとそうはならないから、ぜひ対策を」と同意した。

---

　サプライチェーン攻撃対策は、簡単に答えを出せるものではない。辻氏は「たくさんの“つながり”がある中、自分たちはその“つながり”の中のどこにいるのか。『自分たちだったらどうするか』を考え、今よりも想定の範囲を広げ、どうコントロールしていくかを考えるきっかけになれば。一緒に考えていきましょう」と締めくくった。