インシデント対応の舞台裏シリーズ：サプライチェーン攻撃編

もしもインシデントが発生したら、どのような対応が必要でしょうか？
「まず何をすべきか？」、「誰に連絡すべきか？」、「被害を最小限に抑えるには？」と、突発的な状況で冷静な判断が求められますが、実際に直面すると戸惑うことも少なくありません。天災と同じように、インシデント対応の具体的な行動を事前にイメージすることは意外に難しいものです。

本シリーズでは、実際に起こり得るインシデントをモデルケースとして取り上げ、「どのような対応が求められ、どのように解決へ導くのか」を舞台裏まで詳しく解説します。現場で役立つ実践的な知識を、具体的なシナリオとともにお届けしますので、ご参考になれば幸いです。

連載第4回となる今回は、企業が日常的に信頼を寄せるベンダーが起点となって、標的企業のシステムへ侵入する「サプライチェーン攻撃（supply chain attack）」を取り上げます。ある中堅製造業A社をモデルケースに、サプライチェーン攻撃の発覚から収束、事後対応まで時系列に沿ってどのようにインシデント対応を行うかご紹介します。また、IT担当者が何に悩み、経営層がどう判断し、ラックのサイバー救急センターがどのように支援したか、「自社でも起こり得る」という視点でぜひ最後までご一読ください。

※ 本記事に登場する企業・組織・人物はすべて架空のものです。実在する企業・団体・個人とは一切関係ありません。

異変の発覚：信頼できるはずのアップデートが引き金に

月曜日の午後3時すぎ、従業員約500名を抱える中堅製造業A社の社内PCに、「システムアップデートを適用しています」というポップアップが一斉に表示されました。長年利用してきた、生産・在庫管理ソフトウェアの自動更新です。営業部のC氏は「いつものアップデートか。」と気に留めることなく作業を続け、数分後にソフトウェアが再起動すると、そのまま業務を再開しました。

異変が表面化したのは翌火曜日の朝でした。出社したIT担当のB氏は、社内のセキュリティ監視システム（SIEM：Security Information and Event Management）のダッシュボードに、前夜から溜まり続けた大量のアラートが表示されていることに気付きます。

アラートは、「社内の複数の端末が、深夜0時ごろから外部の見覚えのないIPアドレスへ繰り返し接続を試みています」といった内容で、タイムスタンプを遡ると、最初の不審な通信が記録されたのは前日の午後3時半ごろ。ちょうどアップデート直後でした。「アップデートと関係しているのか？でも、あれは正規のベンダーからの更新のはずだ......。」と、B氏の頭に嫌な予感が走りました。

まず感染している可能性のある端末の一覧をSIEMのログから抽出すると、被疑端末は30台を超えていました。これは一人では手に負えないと直感したB氏は、即座に上司である情報システム部長のD氏へ電話しました。

B氏から「感染の可能性がある端末が30台以上あり、夜通し外部と通信していました。」と報告を受けたD氏の表情は一変しました。「今すぐ代表に第一報を入れろ。私もすぐ向かう。」と、D氏は電話を切るなり情報システム室へ急ぎ、代表取締役E氏への第一報が入れられたのは、午前8時45分のことでした。

初動対応と混乱：何をすべきか分からない現場

代表取締役E氏からの第一声は、「うちのセキュリティ対策は万全だったはずだ。どこから侵入されたんだ？」と、動揺と困惑が入り混じったものでした。一方、情報システム部門ではB氏を中心に状況確認が続いていましたが、調査を進めるほど新たな疑問が増え、全体像は見えてきません。

B氏は、生産・在庫管理ソフトウェアのベンダーサポート窓口へ連絡しました。「昨日のアップデート後から不審な通信が大量に発生しています。更新ファイルに問題はありませんか？」と問い合わせたところ、「現時点では問題のある報告は受けていません。最新版をご利用であれば問題ありません。」という回答でした。ベンダー側でもまだ状況を把握できていなかったのです。

その頃、情報システム部門も状況確認に追われ、社内へ明確な対応指示を出せないでいました。そのため現場では、何をすべきか分からないまま混乱が広がり始めていました。

「今すぐPCの電源を切ったほうがいいか？」
「とりあえずウイルス対策ソフトでスキャンしてみよう。」
「再起動したら直るのでは？」

現場では、それぞれの判断で対応を進める動きも出始めます。さらに、「業務を続けていいの？個人情報は漏えいしていないの？」といった社員からの問い合わせが、情報システム部門に殺到していました。

B氏は板挟みになっていました。端末の電源を落とせば、証拠になり得るログや揮発性メモリの情報が失われる可能性があります。しかし稼働を続ければ、感染が拡大するかもしれません。何を優先すべきか、何をしてはいけないのか判断できないまま、午前10時を過ぎていました。状況を見たD氏は、自分たちの力では限界だと判断しました。かつてセキュリティセミナーで名前を目にしていた、ラックのサイバー救急センターを思い出し、B氏とともに窓口へ連絡を取ることを決めました。

サイバー救急センターへの依頼：専門家の介入

午前11時50分、D氏は、B氏とともにインシデントの状況をわかる範囲でタイムテーブルに整理したうえで、サイバー救急センター「サイバー119」の、24時間365日対応窓口へ電話をかけました。受付後まもなく、担当のインシデントハンドラー^※から折り返しの電話が入りました。

※ サイバー攻撃や情報漏えいなどのセキュリティインシデントが発生した際に、被害を最小限に抑え、迅速な復旧を指揮する専門家。

担当者は落ち着いた口調で状況を丁寧にヒアリングしていきました。

「最初にアラートが出た時刻はいつですか？」
「影響を受けていると思われる端末は何台ですか？」
「直前にシステムの変更や更新はありましたか？」
「インシデント発覚後、社内でどのような対応を行いましたか？」

B氏とD氏が交互に回答していくうちに、頭の中がだんだんと整理されていくのを感じました。

ヒアリングを終えると、インシデントハンドラーはすぐに初動対応を指示しました。「まずは、対象端末を業務ネットワークから隔離してください。そのうえで、ログや設定情報を可能な限りそのままの状態で確保し、追加の変更操作はいったん控えてください。ウイルス対策ソフトの通常のリアルタイム検知は前提として、現時点では手動スキャンや駆除、削除操作は行わないでください。端末の電源を落としたり、検知ファイルを削除したりすると、重要な証跡が失われる可能性があります。検知されたものがある場合は、削除ではなく隔離状態を維持してください。」

B氏は「実は、すでに数名の社員がウイルス対策ソフトのスキャンを実行してしまっています。」と正直に伝えました。インシデントハンドラーの「承知しました。今後の操作については、こちらの指示に従って進めてください。」と落ち着いたその一言で、B氏はようやく冷静さを取り戻しました。その後、D氏とB氏は速やかに契約手続きを進め、本格的なインシデント対応が始まりました。

後日、D氏は当時をこう振り返ります。「LAC IRR（LAC Incident Response Retainer）という事前契約サービスがあることを、対応が終わった後に初めて知りました。インシデントかもしれないと疑った段階からすぐに相談できていれば、最初の判断に迷っていた時間を大きく減らせたはずです。」

フォレンジック調査と全容解明

解析が進むにつれ、インシデントの全容が見え始めます。最初の手掛かりは、不審な通信の発信元プロセス名でした。通常は更新時だけ動作するはずの生産・在庫管理ソフトウェアのプロセスが、アップデート完了後も断続的に外部の特定IPアドレスと通信を続けていたのです。

次に、アップデートファイルを解析した結果、正規の更新パッケージの中に、本来含まれるはずのない不審なモジュールが混在していることが判明しました。このモジュールは、起動後に外部のC2サーバ（Command and Control Server：攻撃者が感染端末を遠隔操作するための指令サーバ）へ接続し、攻撃者からの命令を待ち受ける機能を持っていました。

「ベンダー側のソフトウェア開発環境、または配布インフラが何らかの形で侵害された可能性が高いと考えられます。」とのインシデントハンドラーからの報告に、D氏は言葉を失いました。「自社の落ち度ではなかったのか。しかし、被害を受けていることに変わりはない。」

その後は被害範囲の特定へと調査が移ります。アップデートを受け取った全端末のリストアップ、マルウェアが実際に活動した端末と起動しなかった端末の仕分け、外部へ送出されたデータの範囲の推定。これらをログの突き合わせとフォレンジック解析によって絞り込んでいきました。

最終的に明らかになった事実は、以下のとおりでした。

調査項目	判明した内容
マルウェアが活動した端末数	30台超（アップデートを受け取った端末の一部）
C2サーバへの通信が確認された期間	最初のアップデート実施から約16時間
外部へ送出された可能性のあるデータ	一部業務ファイル（送出の可能性あり・範囲を特定中）
基幹システム・機密情報へのアクセス	痕跡なし（調査時点）

調査の途中、代表取締役のE氏からは「いつ社員や取引先に説明すればいいか」「プレスリリースを出すべきか」という問いが続きました。インシデントハンドラーは「まずは、顧客情報などが被害範囲に含まれていたのかについて確認してください。被害範囲の確定と並行して、公表のタイミングと内容についても一緒に整理しましょう。」と伝え、伴走しながら支援を続けました。

封じ込めと根絶：インシデントの収束へ

被害範囲の確定後、ラックからA社に向けて封じ込め（Containment）の具体的な手順がアドバイスとして提示されました。実際の作業はIT担当のB氏および外部の運用サポート事業者が担いました。

封じ込めフェーズ

• マルウェアが活動していた端末を、スイッチのVLAN設定変更によってネットワークから隔離する（B氏のチームが実施）
• マルウェアが通信に使っていたC2サーバに関連するIPアドレスおよびドメインを、ファイアウォールのブロックリストに追加する（運用サポート事業者が実施）
• 問題の生産・在庫管理ソフトウェアの自動更新機能をいったん無効化し、全社的に新規アップデートの適用を一時停止する（B氏のチームが実施）

根絶フェーズ

根絶（Eradication）フェーズでは、問題のあるバージョンのソフトウェアを全端末からアンインストールし、悪意あるモジュールが設置したバックドアや常駐化の仕組みを除去するための具体的な手順がラックから提示されました。B氏はその手順に従い、一台一台の作業を進めていきました。

---

後にB氏は、「まるでパズルを解くようでした。どの端末を、どの順番で、どう処置すれば安全なのか。ラックのインシデントハンドラーは都度の疑問にも丁寧に応えてくれて、安心して作業を進めることができました。」と語ります。

この時期、ベンダー側でも自社システムの異常が確認され、更新配布システムの停止と内部調査が開始されました。A社はベンダーから「問題のある更新ファイルの配布は停止した。」という連絡を受け、マルウェア入りアップデートが新たに展開されるリスクはなくなりました。ラックからのアドバイスに基づき、A社はベンダーへの状況確認の際に収集すべき情報のリストも整理しました。

復旧と事後対応

封じ込めと根絶が完了した後、A社は段階的なシステム復旧に着手しました。ラックは、クリーンな状態が確認できた端末から順に業務へ復帰させる方針を提示し、基幹業務に必要な端末を優先的に復旧しました。その後、対象を段階的に拡大していきました。各端末のクリーンアップ確認から業務復帰までには、封じ込め開始からおよそ15営業日を要しました。復旧作業中も、インシデントハンドラーが作業進捗を確認し、新たな懸念が生じるたびに対応策をアドバイスしました。

対外対応については、法務・広報部門と連携しながら対応方針を策定しました。フォレンジック調査の結果、業務ファイルの一部が外部へ送信された可能性があることを受け、E氏は「影響を受けた可能性のある取引先には、正直に伝える必要がある。」と判断しました。インシデントハンドラーは、説明内容の整理や情報開示の進め方を支援しました。

あわせて、法務部門は個人情報保護委員会への報告要否や、監督官庁への届出の必要性を確認し、必要な手続きを進めました。フォレンジック収束後、ラックは詳細なフォレンジック報告書を提出しました。報告書の内容は以下の通りです。

• 攻撃の全体的な流れと侵入経路の詳細
• 確認された被害の範囲と技術的根拠
• 攻撃のタイムライン
• 今後の再発防止に向けた具体的な推奨事項

「次に何をすべきかが明確になりました。この報告書は、社内の体制強化を見直す議論にも役立っています。」とD氏は語ります。E氏は取締役会で今回のインシデントを報告し、セキュリティ投資の優先順位を見直す方針を決定しました。

この事例から学ぶこと

A社のインシデントが示す教訓は、業種や規模を問わず、あらゆる企業に当てはまります。以下の5点を整理します。

教訓① サプライチェーンリスクは「自社の外」にある脅威

自社のセキュリティ対策がどれほど堅牢でも、利用しているソフトウェアや取引先・委託先に脆弱性があれば、そこが攻撃の起点になります。「信頼できるベンダーからの正規更新」であっても、盲目的に信頼することには一定のリスクが伴います。

教訓② 正規アップデートを前提にした検知・監視体制の重要性

業務に関わるソフトウェアのアップデートでは、本番環境への適用前に検証環境で動作確認する手順を整えておくことが有効です。ただし、今回のようにベンダーの公式アップデートとして配布されたファイルに悪意あるモジュールが混入していた場合、事前テストだけで異常に気付くことは容易ではありません。

そのため、更新前の検証に加えて、アップデート後の端末上での不審なプロセス挙動や外部通信先を監視できる体制が重要です。EDRを導入していれば、ファイルの検知だけでなく、通常とは異なるプロセスの起動や通信を把握しやすくなり、早期の検知、影響範囲の特定、封じ込めにつなげることができます。

なお、SBOMは、利用しているソフトウェアやコンポーネントに脆弱性が見つかった場合の影響範囲把握には有効です。一方で、開発環境や配布経路が侵害され、正規アップデート自体が改ざんされた場合には、SBOMだけで対応することは困難です。EDRやSIEMによる挙動監視と組み合わせて活用することが重要です。

教訓③ 初動対応は「隔離」と「証跡保全」が鍵

インシデント発生時には、まず感染が疑われる端末をネットワークから隔離し、被害の拡大を防ぐことが重要です。そのうえで、ログや設定情報などの証跡を可能な限りそのままの状態で保全し、不要な再起動、設定変更、手動スキャン、駆除・削除といった追加操作は控える必要があります。

「まず隔離し、証跡を保全し、追加の変更操作を控える」という初動の原則を社内全体に周知しておくとともに、マニュアルの整備と定期的なトレーニングを行うことが重要です。

教訓④ 独力での対応に限界を感じたら迷わず専門家へ

初動の混乱、ベンダーへの対応、社内調整、経営層への報告が同時に押し寄せる中で、専門家への相談を遅らせることは状況を悪化させます。「自社で解決できるか」の判断に時間をかけるより、早期に専門家へ相談することが被害最小化の鍵となります。

教訓⑤ 「疑いの段階」での相談が被害を狭める

今回のA社は「明らかにおかしい」と確信してから連絡しましたが、LAC IRRによる事前契約があれば、「インシデントかもしれない」という段階からインシデントハンドラーへ相談できます。対応開始が早まることで、証跡の保全精度も高まり、被害範囲をより狭められる可能性があります。

インシデント対応に備えるには

サプライチェーン攻撃は、自社だけの対策では防ぎきれない脅威です。しかし、被害を最小化するための備えは今すぐ始めることができます。

5,300件以上のインシデント対応の実績を持つラックのサイバー救急センターでは、インシデント発生時に支援を行う「サイバー119」に加え、事前に契約しておくことでより迅速・優先的な支援が受けられる「LAC IRR（LAC Incident Response Retainer）」を提供しています。

LAC IRRでは、事前契約のお客様に対し、サービスレベル目標（SLO）に基づく優先・迅速な対応を提供します。また、「これはインシデントかもしれない」という早期の段階から、専門のインシデントハンドラーに相談できるため、初動判断の遅れを防げます。A社のように、「何をすべきか分からない」と判断に迷う時間は、被害拡大につながりかねません。インシデント発生時に迷わず適切な対応を取るためにも、平時からの備えを検討してみてはいかがでしょうか。

インシデント対応支援サービスのご案内

【スポット型】サイバー119

インシデント発生時に迅速に対応する、スポット契約型のサービスです。24時間365日受付し、専門のインシデントハンドラーがヒアリングから調査・対応支援まで行います。事前契約なしでもご利用いただけるため、インシデントが発生したらまずお電話ください。

【事前契約型】LAC IRR（LAC Incident Response Retainer）

有事の前に契約しておくことで、SLOに基づく迅速な優先対応が受けられる事前契約型のサービスです。インシデントの「疑い」の段階から専門のインシデントハンドラーへ相談できるため、初動対応の質と速度が大きく向上します。インシデント対応に備えたい企業の方はぜひご検討ください。

よくあるご質問（FAQ）

Q. サプライチェーンリスクへの対策は、どこから始めればよいですか？

A. まずは、自社が利用している外部サービス、ソフトウェア、委託先、取引先との接続状況を整理し、どこにリスクがあるのかを把握することが第一歩です。あわせて、取引先のセキュリティ対策状況やインシデント発生時の連絡体制を確認しておくことで、有事の対応を迅速化できます。自社だけで評価や整理を進めることが難しい場合は、ラックの「サプライチェーンリスク評価サービス」の活用もご検討ください。

Q. サプライチェーン攻撃はどのように検知できますか？

A. 完全な検知は難しいものの、EDR（Endpoint Detection and Response）による振る舞い検知、ネットワーク通信の異常監視、SIEMを活用したログの一元管理が有効です。また、SBOM（ソフトウェア部品表）を整備し、利用しているソフトウェアのコンポーネントを把握しておくことで、問題のある更新が配布された際の影響範囲を素早く特定できます。自社だけでの監視体制に限界を感じている場合は、JSOC マネージド・セキュリティ・サービスの活用も検討してください。

Q. 取引先がサイバー攻撃を受けた場合、自社はどう対応すべきですか？

A. まず、自社が当該取引先のソフトウェアやシステムを利用している場合は、関連するログを確認し、不審な通信や動作がないか確認します。取引先との接続を一時的に制限することも選択肢の一つです。取引先からの連絡を待つだけでなく、自社側での能動的な確認が重要です。不審な兆候があれば、迷わず専門家に相談することをお勧めします。

Q. LAC IRRとサイバー119の違いは何ですか？

A. サイバー119はインシデント発生後に都度契約するスポット型のサービスです。インシデントが起きたときにすぐ連絡して契約手続きを経てから支援が開始されます。一方、LAC IRRはインシデントが起きる前に契約しておく事前契約型のサービスです。事前契約により、インシデントの「疑い」段階からインシデントハンドラーへ相談でき、SLOに基づく優先・迅速な対応を受けられます。有事に備えたい場合はLAC IRRの事前契約が効果的です。

Q. インシデント発生後に端末の電源を切ってはいけないのですか？

A. 状況によります。電源オフにすると、揮発性メモリ上に残っているマルウェアの動作情報や通信内容などの重要な証拠が失われる可能性があります。ただし、感染拡大や重大な被害継続を防ぐために隔離が急務な場合は、専門家の判断のもとで電源オフや隔離を行うことがあります。自己判断で電源を切ったり再起動したりする前に、まず専門家へ相談することをお勧めします。