スキルアップカレッジ サプライチェーンは攻撃者から見て何か
レッスン5：サプライチェーンは攻撃者から見て何か
このレッスンで学ぶこと
- サプライチェーン攻撃が攻撃者にとって成立する、経済合理性を理解する
- 攻撃者が着目する侵害面を、5つの分類で説明できる
- サプライチェーン攻撃が、なぜ自組織の対策だけでは防ぎきれないかを理解する
前回のレッスンでは、初期侵入の重心が、マルウェアの配送から正規の資格情報でのログインへ移ってきたことを見てきました。本レッスンでは、初期侵入のもう1つの重要な経路である、サプライチェーンを扱います。情報セキュリティ関連の入門コースでは、取引先の侵害とソフトウェアの更新という2つの切り口で、サプライチェーン攻撃の概要が紹介されています。本レッスンでは、その2つをさらに分解し、攻撃者が実際にどこに着目しているのかを、5つの侵害面に分けて見ていきます。
1つ落として多数に届く経済合理性
まず、なぜ攻撃者がサプライチェーンという経路をわざわざ選ぶのかという、動機の部分から考えます。
ある組織を直接狙う場合、攻撃者は、その組織の防御を1つずつ突破する必要があります。もし、その組織が強固な対策を取っていれば、侵入の難度は高くなります。ここで攻撃者が着目するのが、その組織が信頼して使っている、外部の製品やサービス、委託先です。
多くの組織は、業務に必要な機能の一部を、外部のソフトウェアやサービス、専門業者に頼っています。逆に言えば、その外部の側に侵入できれば、そこを信頼して使っている複数の組織へ、一気に接点を得られる可能性があります。1つの標的を個別に攻略するより、多数の標的に共通して使われている土台を攻略したほうが、投じた労力に対して得られる成果が大きくなります。これが、サプライチェーン攻撃を成立させる経済合理性です。
この発想は、レッスン3で見たランサムウェアの分業構造とも通じるものがあります。イニシャルアクセスブローカーが「侵入した状態」そのものを商品として扱っていたように、サプライチェーン攻撃では、「多数の組織への足がかりとなる土台」そのものが、攻撃者にとっての価値の源泉になります。標的を1つずつ選んで攻略するのではなく、標的の集合全体に通じる共通の弱点を探すという発想の転換が、サプライチェーン攻撃の本質です。
💡 ポイント 「自社は強固な対策を取っているから安心」という考え方だけでは、サプライチェーン攻撃への備えとして不十分です。攻撃者は、対策の強い正面から侵入しようとするのではなく、対策の外側にある、信頼された経路から回り込もうとするからです。
この経済合理性を、投資の考え方に置き換えて考えてみます。攻撃者にとって、侵入のための準備には、時間・技術・場合によっては金銭という、有限の資源がかかります。この資源を、標的1社ごとに個別に投じるのか、それとも多数の標的に共通する土台に対して1回だけ投じるのかという選択があったとき、後者のほうが、資源に対して得られる成果の比率、つまり採算が良くなります。標的の数が多ければ多いほど、この差は開いていきます。攻撃者が合理的に行動する主体であるという、レッスン1で確認した前提に立てば、サプライチェーンという経路が繰り返し選ばれ続けるのは、必然に近い結果だといえます。
さらに、サプライチェーンを経由した侵入には、もう1つの利点があります。標的となる組織自身の対策が、直接には及ばない場所から侵入が始まるという点です。組織がどれだけ自社のログを監視し、自社の端末を強化していても、侵入の起点が委託先や利用ソフトウェアの内部にある限り、その兆候を自社の監視だけで捉えることは難しくなります。この「見えない場所から始まる」という特性が、サプライチェーン攻撃を、通常の初期侵入よりも発見しづらいものにしています。
侵害面の分類
「サプライチェーン」とひとことで言っても、攻撃者が実際に着目する対象はさまざまです。ここでは、代表的な侵害面を5つに分けて整理します。
flowchart TD
S[攻撃者が着目する<br/>侵害面] --> A[マネージドサービス事業者]
S --> B[ID 基盤]
S --> C[ビルドと配信の経路]
S --> D[オープンソースの維持者]
S --> E[更新配信]マネージドサービス事業者
マネージドサービス事業者は、複数の顧客企業に代わって、システムの運用や監視を請け負う事業者です。この業態には、業務の性質上、顧客企業のシステムに対する広い権限でアクセスできる立場にあるという特徴があります。
攻撃者から見ると、1社のマネージドサービス事業者に侵入できれば、その事業者が管理している複数の顧客企業へ、まとめて接点を得られる可能性があります。顧客企業それぞれが個別に強固な対策を取っていたとしても、その対策の外側にある、委託先という共通の経路から回り込まれると、個々の対策の効果が薄れてしまいます。
この構図が厄介なのは、委託先へのアクセス権限が、業務上どうしても必要とされる点です。マネージドサービス事業者が顧客企業のシステムを遠隔で保守・監視するには、一定の権限を持ったアクセス経路が欠かせません。この経路そのものをなくしてしまえば、事業者は本来の業務を果たせなくなります。「便利で必要な経路」であることと、「攻撃者にとって価値の高い経路」であることが、表裏一体になっているのです。
ID 基盤
ID 基盤は、複数のサービスにまたがる利用者の認証を一手に引き受ける仕組みです。1度の認証で複数のサービスを使えるようにする、利便性の高い仕組みですが、裏を返せば、この基盤そのものに侵入できれば、そこに接続されている複数のサービスへの入り口を、まとめて手に入れられることを意味します。
ID 基盤は、レッスン4で扱った「正規の資格情報でのログイン」という手口とも密接に関係しています。ID 基盤が扱う認証情報そのものが攻撃者の標的になれば、個々のサービスがどれだけ堅牢であっても、認証という入り口そのものが崩れてしまいます。ID 基盤を狙う侵入は、レッスン4で見た個々の利用者のパスワードを狙う侵入よりも、さらに一段上流にある入り口を狙う行為だといえます。個々の利用者を1人ずつ攻略するのではなく、その全員の認証を束ねている土台そのものを攻略するという意味で、ID 基盤への侵入は、マネージドサービス事業者への侵入と同じ「1点突破で多数へ波及させる」発想の延長線上にあります。
ビルドと配信の経路
ビルドと配信の経路とは、ソフトウェアの開発元が、書かれたプログラムを実際に動く形に組み立て、利用者に届くパッケージとして作り上げる一連の工程を指します。この工程に攻撃者が入り込めれば、開発元が意図していないコードを、正規のソフトウェアの一部として紛れ込ませることができます。
この経路が狙われる怖さは、利用者の側からは、届いたソフトウェアが開発元の正規のものなのか、途中で細工されたものなのかを、見分けることが極めて難しい点にあります。開発元を信頼してソフトウェアを導入するという、通常であれば合理的な判断そのものが、攻撃の通り道として利用されてしまいます。
ビルドの経路には、人が書いたプログラムを、実際に動作する形式へと変換する工程や、複数の部品を1つにまとめ上げる工程など、いくつもの自動化された処理が連なっています。攻撃者がこの一連の処理のどこか1か所に細工を紛れ込ませることができれば、その後の工程を経て完成する製品全体に、その細工が反映されてしまいます。開発元自身が、意図しない細工が含まれていることに気づかないまま、正規の手続きを経て利用者にソフトウェアを届けてしまうことすらあります。
オープンソースの維持者
現代の多くのソフトウェアは、無償で公開されているソフトウェア部品を組み合わせて作られています。こうした部品の多くは、少数の開発者が有志で維持していることが少なくありません。
攻撃者は、こうした維持者の役割そのものを標的にすることがあります。維持者のアカウントを乗っ取ったり、維持者に近づいて信頼を得たうえで悪意あるコードの取り込みを働きかけたりする手口です。広く使われている部品の維持者という、比較的少人数で守られている立場に入り込めれば、その部品を利用する非常に多くのソフトウェアへ、間接的に影響を及ぼせます。
この侵害面が、ほかの4つと決定的に違うのは、狙われる相手が企業組織ではなく、多くの場合、個人あるいは少人数の有志であるという点です。企業であれば、規模に応じたセキュリティの体制を敷いていることが期待できますが、有志の維持者には、そうした体制を求めること自体が難しい場合があります。攻撃者は、防御の薄い個人を足がかりにして、その先に連なる無数の組織へ影響を広げるという、非対称な構図を利用しています。信頼を得るために、長期間にわたって地道な貢献を積み重ねたうえで、機が熟したところで悪意あるコードを紛れ込ませるという、時間をかけた手口も報告されています。
更新配信
更新配信は、すでに利用者の手元にあるソフトウェアに対して、修正や機能追加を届ける仕組みです。ビルドと配信の経路が「作る」段階であるのに対し、更新配信は「届ける」段階にあたります。
多くの利用者は、更新の通知が届けば、その中身を細かく検証せずに適用します。これは効率的な運用のためには合理的な習慣ですが、攻撃者にとっては、この習慣そのものが好都合です。更新配信の仕組みに侵入できれば、正規の更新であるという体裁を保ったまま、悪意あるコードを広範囲の利用者に一括して届けられます。
更新を速やかに適用することは、レッスン4で扱った「公表済みの脆弱性を放置しない」という原則そのものであり、通常であれば推奨される行動です。しかし、更新配信の経路自体が汚染されている場合、この推奨される行動が、そのまま被害を広げる行動に転じてしまいます。「更新はすぐに適用すべきだ」という原則と、「更新配信の経路も攻撃対象になりうる」という現実は、矛盾するものではなく、両方を同時に踏まえる必要がある事実です。
📝 補足 5つの侵害面はそれぞれ独立していますが、組み合わさって狙われることもあります。例えば、オープンソースの部品に紛れ込ませたコードが、開発元のビルドの経路を経て、更新配信という形で最終的な利用者に届く、という一連の流れです。攻撃者は、どこか1点を突破すればよいのではなく、この一連の流れ全体のどこが手薄かを見極めています。
対策の要点
本コースは、攻撃者の視点から脅威の構造を読み解くことに軸足を置いているため、対策の実務そのものには深く立ち入りません。ここでは要点だけを短く示します。委託先の選定基準やセキュリティ評価の設計、契約への条項の盛り込み方といった実務は、ベンダーマネジメント関連の実践コースが専門に扱う領域です。自組織が5つの侵害面のどこにどれだけ依存しているかを棚卸しし、依存の大きい経路から優先的に評価する、という順序で臨むのが現実的です。
講師の現場メモ②：委託先の先にあったもの
脅威リサーチの現場にいた頃、複数の企業でほぼ同時期に発生した障害を横断的に調べる機会がありました。最初に相談が来たのは、国内のある港湾で物流を担う企業からでした。コンテナの管理システムが動かなくなり、搬出入の作業が数日間止まっているという内容でした。
同じ時期、まったく別の業種の企業からも、似たような相談が相次いで寄せられました。業種はばらばらでしたが、共通点を探るうちに、これらの企業が同じIT運用の委託先を利用していたことがわかりました。調べを進めると、その委託先のシステムに侵入の痕跡が見つかりました。委託先が、複数の顧客企業のシステムに広い権限でアクセスできる立場にあったため、そこを起点に、複数の企業へほぼ同時に影響が広がっていたのです。
この案件で印象に残っているのは、被害に遭った企業それぞれの担当者が、口をそろえて「自社のシステムは問題なく守られていたはずだ」と話していたことです。実際、それぞれの企業が個別に行っていた対策は、決して手薄ではありませんでした。しかし、委託先という共通の経路を経由されたことで、個々の対策の効果が及ばない場所から侵入を許してしまいました。
この経験を通じて私が強く意識するようになったのは、「自社の対策の強さ」と「自社が実際に晒されているリスクの大きさ」は、必ずしも一致しないということです。委託先や利用しているソフトウェアという、自社の管理の外側にある要素まで含めて、初めてリスクの全体像が見えてきます。本コースでレッスン1から一貫して「攻撃者を主語にする」ことを強調しているのは、この経験のように、防御側の内側だけを見ていては気づけない構造があるからです。
もう1つ、この案件で記憶に残っているのは、被害に遭った企業どうしが、当初はまったく別の事案として個別に対応していたことです。業種も規模も異なる企業が、たまたま同じ時期に障害を報告してきたに過ぎないと、私自身も最初は考えていました。委託先という共通項に気づけたのは、複数の案件のログを横断的に突き合わせる作業を、根気強く続けた結果でした。1件ずつを個別の事案として処理していたら、この共通項には気づけなかったかもしれません。攻撃者が「1つ落として多数に届ける」発想で動く以上、防御側もまた、個々の事案を孤立させずに横断的に見る視点を持つ必要がある、と痛感した案件でした。
まとめ
このレッスンでは、以下のことを学びました。
- サプライチェーン攻撃は、1つの土台に侵入すれば多数の標的への接点を得られるという経済合理性に基づいている
- 攻撃者が着目する侵害面は、マネージドサービス事業者、ID 基盤、ビルドと配信の経路、オープンソースの維持者、更新配信の5つに整理できる
- これらの侵害面は組み合わさって狙われることがあり、自組織の対策だけでは防ぎきれない構造を持つ
次のレッスンでは、視点を変えて、生成 AI が攻撃者側にどのような影響を与えているかを見ていきます。
確認クイズ
このレッスンの理解度をチェックしましょう。