Cyber Incident Management for PHP Vulnerability 第四話 改訂版
第4話 復旧しても、終わりではない
午前八時三十分。
サイバーナイト株式会社の会議室には、経営陣と関係部門の責任者が集まっていた。
夜を徹した確認作業は、まだ終わっていない。
ブロッサムネット株式会社からは、一部のホスティング環境について修正版の適用予定が届いていた。社内で管理するシステムについても、担当者が利用状況とPHPのバージョンを確認している。
しかし、外部の制作会社が管理するウェブサイトなど、すべての環境を把握できたわけではなかった。
最高情報責任者の黒木厳は、会議資料を画面に映した。
「現時点での状況をご説明します」
黒木は、確認できた事実から話し始めた。
「まず、PHPの脆弱性に対する予防対応を進めています。対象環境の確認、修正版の適用、適用までの暫定防御を並行して進めています。また、不審なアクセスや不正な処理がなかったか、ログの調査も継続しています」
経営陣の一人が尋ねた。
「攻撃を受けた形跡はあったのか？」
「現時点で、攻撃による被害を示す明確な痕跡は確認されていません。ただし、調査が完了していないシステムもあります。したがって、全社的に被害がなかったと断定できる段階ではありません」
黒木は、確認済みの項目と未確認の項目を分けて示した。
「こちらが、対応状況です。確認済みのもの、対応中のもの、外部事業者からの回答を待っているものを、それぞれ分けています」
「つまり、まだ全容はわかっていないということか」
「はい。現時点で把握できている範囲と、まだ把握できていない範囲があります」
黒木は、そこで説明を止めた。
未確認のものを、確認済みとは言わない。
それが、今回の報告で守るべき原則だった。
＊
午前八時四十五分。
会議では、ウェブサービスを継続するか、一時停止するかが議題になった。
取引先が日常的に利用するサービスを停止すれば、受発注などの業務に影響が出る。一方、脆弱性の影響を受ける可能性があり、十分な防御ができない状態で運用を続けることにもリスクがある。
事業部門の責任者が説明した。
「停止した場合、取引先に代替手段を案内する必要があります。受発注の処理にも遅れが出る可能性があります」
セキュリティ担当者は、技術面から補足した。
「対象となる環境を特定でき、暫定防御が有効に機能することを確認できれば、運用を継続できる可能性があります。ただし、暫定防御は修正版の適用に代わるものではありません」
別の役員が尋ねた。
「それぞれの選択肢について、リスクを比較できるか？」
黒木が答えた。
「はい。技術面で確認できている事項と、確認できていない事項を整理しています。運用を継続する場合のセキュリティ上のリスク、停止する場合の業務への影響、修正版を適用するまでの暫定措置について、資料にまとめています」
「技術的に、どちらが安全なのか？」
「対象環境や防御策によって異なります。影響を受ける可能性が高く、有効な防御を確認できない環境では、停止を含めた対応が必要になる可能性があります。一方、対象範囲を確認し、適切な防御と更新計画を確保できる環境では、継続運用が可能な場合もあります」
黒木は、結論を代わりに出そうとはしなかった。
彼が説明すべきなのは、会議が判断するための材料だった。
技術的に何がわかっているのか。
何がまだわかっていないのか。
選択肢ごとに、どのようなリスクがあるのか。
それらを明確にすることが、彼の役割だった。
＊
午前九時十分。
参加者からの質問が一巡すると、議長が発言した。
「各部門の説明を踏まえ、対応方針を決定したい」
会議では、対象環境ごとの対応状況、暫定防御の確認状況、更新作業の予定、業務への影響が検討された。
そのうえで、会議としての方針がまとめられた。
対象環境を確認できたシステムについては、担当する事業者や社内担当者と連携し、修正版の適用を進める。
修正版の適用まで時間を要するシステムについては、暫定防御の有効性を確認し、リスクを継続的に評価する。
脆弱性の影響を受ける可能性があり、十分な防御を確認できないシステムについては、個別にリスクと業務への影響を検討し、一時停止を含めた措置を判断する。
攻撃の痕跡については、予防対応とは別にログ調査を続ける。
そして、対象システム、担当者、対応期限、確認方法を記録し、未確認の項目を放置しない。
議長が確認した。
「この方針で進めることに、異議はありますか？」
参加者から意見が出され、必要な修正が加えられた。
最終的に、会議としての対応方針が決定された。
黒木は、決定事項を確認した。
「承知しました。決定された方針に沿って、関係部門と外部事業者との連携を進めます。対応状況については、確認できた事実に基づいて報告します」
彼は、会議の結論を自分の判断として語らなかった。
それは、組織として決めた方針だった。
＊
午前十時二十分。
各担当者が、決定された方針に基づいて作業を進めていた。
ブロッサムネットからは、対象環境ごとの確認結果が順次届いていた。社内担当者は、修正版の適用状況を確認し、外部の制作会社にも問い合わせを続けている。
更新作業が完了したと報告されたシステムについては、実際に適用されたバージョンを確認する。
さらに、ウェブサイトやアプリケーションが正常に動作するかを確認する。
単に「更新しました」という連絡を受け取るだけでは、完了とはしない。
黒木は、セキュリティ担当者からの報告を受けた。
「一部の環境では、修正版の適用と動作確認が完了しました。ほかの環境については、作業中のものと、外部事業者からの回答を待っているものがあります」
「確認できた範囲と、未完了の範囲を分けて報告してください」
「はい」
「ログ調査の状況も、別にまとめてください。修正版を適用したことと、過去に攻撃を受けていないことは、別の問題です」
担当者は、うなずいた。
脆弱性への対処が進んだからといって、過去のアクセスまで自動的に安全だと証明されるわけではない。
更新作業と、侵入の痕跡を調べる作業。
二つを混同しないことが必要だった。
＊
午後一時。
中間報告が更新された。
修正版の適用と動作確認が完了したシステム。
暫定防御を実施し、更新作業を待っているシステム。
対象環境の確認を継続しているシステム。
外部事業者との連絡や管理責任者の確認が必要なシステム。
それぞれの状況が整理されていた。
ただし、すべての調査が完了したわけではなかった。
黒木は、経営陣に説明した。
「対応は進んでいますが、未完了の項目が残っています。完了したものについては、実施記録と確認結果を保存します。未完了のものについては、担当者と期限を明確にし、継続して確認します」
役員が尋ねた。
「今回、実際の被害はあったのか？」
「現時点では、被害を示す明確な痕跡は確認されていません。ただし、ログ調査が完了していない環境があります。調査が完了するまでは、被害がなかったと断定できません」
「わかった。引き続き報告してほしい」
黒木は、うなずいた。
危機管理では、経営陣が安心できる言葉を並べることより、事実を正確に伝えることが重要だった。
＊
午後三時。
対応状況の確認会議が開かれた。
修正版の適用が完了したシステムでは、適用結果と動作確認の記録がそろい始めていた。
一方、外部事業者からの回答が得られていないシステムも残っていた。
議長は、黒木に尋ねた。
「今回の対応で、会社として改善すべき点は何だと考えるか？」
黒木は、資料を開いた。
「今回、確認に時間がかかった理由の一つは、システムの管理情報が分散していたことです。契約先は把握できても、実際にどのシステムが動いているのか、どのバージョンを使用しているのか、誰が管理しているのかを、すぐに確認できないケースがありました」
「対策は？」
「システム台帳と契約台帳を関連付け、利用技術、管理責任者、委託先、緊急連絡先を確認できるようにする必要があります。また、脆弱性情報を受け取った際に、影響するシステムを速やかに特定できる手順も整備する必要があります」
黒木は、続けた。
「ただし、台帳を作るだけでは不十分です。システムの追加や変更があった際に情報を更新し、定期的に実態と照合する運用が必要です」
議長は、参加者に向き直った。
「改善策についても、会議として検討したい。担当部門と期限を含めて整理しよう」
黒木は、その議論を見守った。
自分が説明した内容を、会社としてどのような改善策にするか。
それを決めるのは、会議だった。
＊
午後五時。
黒木は、自席で最後の報告資料を確認していた。
修正版の適用状況。
動作確認の結果。
ログ調査の進捗。
未完了の項目と、その担当者。
そして、再発防止に向けた改善案。
それぞれが別の項目として整理されていた。
今回の対応で、すべてが終わったわけではない。
技術的な対処が完了しても、ログ調査が残ることがある。
被害を示す痕跡が見つからなくても、調査の範囲や限界を確認する必要がある。
そして、今回の問題が収束したあとも、システム管理の仕組みを改善し続けなければならない。
黒木は、報告資料を保存した。
机の上には、会議で決まった対応方針と、これから検討される改善策の一覧が並んでいた。
彼は最高情報責任者として、技術的な状況を説明した。
わかっていることを伝えた。
わかっていないことも伝えた。
選択肢ごとのリスクを説明し、判断に必要な情報を提供した。
最終判断は、会議に委ねた。
そして、決定された方針が実行されるよう、関係部門との調整を続けた。
それが、今回の黒木の仕事だった。
サイバーインシデントマネジメントとは、誰か一人が正解を言い当てることではない。
技術的な事実を確かめ、リスクを共有し、組織として判断し、その結果を確認すること。
そして、対応が終わったあとも、次に備えることだった。
黒木は、未完了の項目に目を向けた。
まだ、確認を続けなければならないことがある。
彼は、報告書の表紙に記された日付を確認し、次の会議に向けて資料を整えた。
【サイバー危機管理に、終わりはあるのか】
今回の物語では、PHPの脆弱性をきっかけに、企業がどのように対応するのかを描きました。
ところで、脆弱性を修正すれば、それで問題は解決するのでしょうか。
残念ながら、そう簡単ではありません。
現代の企業は、自社だけですべてのシステムを管理しているわけではないからです。
ウェブサイトの制作を外部の会社に依頼し、その会社が別の事業者のサーバーを利用している。サーバーを管理する会社と、そこで動くアプリケーションを管理する会社が異なることもあります。
つまり、自分たちが使っているシステムであっても、実際に誰が何を管理しているのか、すぐにはわからない場合があるのです。
脆弱性が発見されたとき、必要なのは修正版を適用することだけではありません。
まず、影響を受けるシステムを特定する。
誰が管理しているのかを確認する。
誰が修正し、いつまでに対応するのかを決める。
そして、本当に修正されたのかを確認する。
さらに、不正なアクセスがなかったかも調べなければなりません。
ここで難しいのは、外部に委託しているからといって、すべてを任せきりにはできないことです。一方で、委託元の企業が、委託先の技術的な作業をすべて直接行えるわけでもありません。
契約書に責任分担が書かれていても、緊急時に担当者と連絡が取れるとは限りません。そもそも、自社が利用しているシステムを、すべて把握できているとは限らないのです。
だからこそ、サイバー危機管理では、技術的な知識だけでなく、契約、組織、連絡体制、経営判断が重要になります。
本作の主人公、黒木厳は、最高情報責任者です。しかし、彼一人ですべてを決定するわけではありません。
黒木の役割は、確認できた事実と、まだ確認できていないことを区別し、技術的なリスクと業務への影響を説明すること。そして、経営陣が適切な判断をできるようにすることです。
最終判断は、会議に委ねられます。
それは責任を避けるためではありません。技術上の問題と、事業上の影響を総合的に考え、組織として決定するためです。
では、すべての問題を解決できる日は来るのでしょうか。
おそらく、来ません。
新しい脆弱性は発見されます。システムは更新され、委託先も変わります。昨日まで安全だった環境が、明日も安全であるとは限りません。
サイバー危機管理とは、すべての問題が起きないように保証することではありません。
問題が起きたとき、何が起きているのかを把握し、必要な人に連絡し、リスクを説明し、組織として判断し、対応の結果を確かめること。そして、次に同じ問題が起きたとき、今回よりも早く、適切に動けるようにすることです。
「問題を完全になくすことはできなくても、わからないことを放置する時間は短くできる。」
今回の物語で描きたかったのは、そんなサイバー危機管理の現実です。
