第四話 復旧しても、終わりではない
第四話 復旧しても、終わりではない
午前一時四十分。
サイバーナイト株式会社の会議室では、PHPの脆弱性への対応について、引き続き検討が行われていた。
最初の警報から、すでに数時間が経過している。
影響を受ける可能性のあるシステムは、少しずつ特定されてきた。管理先が判明したものもある。PHPのバージョンを確認できたものもある。
一方で、外部の事業者から回答を待っているものや、管理者そのものがわからないものも残っていた。
最高情報責任者の黒木厳は、更新された一覧を会議の画面に表示した。
「現時点の状況を説明します」
画面には、確認できた項目と、未確認の項目が分けて表示されていた。
「影響の有無を確認できたシステム、修正の可否を確認しているシステム、管理者や構成の特定が必要なシステムがあります。すべてを同じ状態として扱うことはできません」
会議の参加者たちは、画面を見つめた。
「攻撃の痕跡については、確認できた範囲では、明確なものは見つかっていません。ただし、調査が終わっていないシステムもあります。現時点で、すべてのシステムが攻撃を受けていないと断定することはできません」
黒木は、報告を続けた。
脆弱性への対応と、侵入の有無を調べることは別の作業である。
修正プログラムを適用すれば、対象となる脆弱性への対策を進められる。しかし、それだけで過去の不正アクセスの有無までわかるわけではない。
反対に、現時点で攻撃の痕跡が見つかっていないとしても、脆弱性を放置してよいということにはならない。
「したがって、修正作業、動作確認、ログの調査を、それぞれ区別して進める必要があります」
黒木は、説明を終えた。
その先の対応方針は、会議が判断することだった。
◾️ 復旧とは、何を意味するのか
会議では、システムの復旧状況についても話し合われた。
「修正が終われば、復旧したと考えてよいのでしょうか」
参加者の一人が尋ねた。
黒木は、画面に三つの項目を表示した。
・ 一つ目は、脆弱性への対策。
・ 二つ目は、システムの動作確認。
・ 三つ目は、不正アクセスの有無に関する調査。
「それぞれ、確認する内容が異なります」
脆弱性への対策とは、影響を受けるソフトウェアを修正したり、必要な防御策を実施したりすることだ。
動作確認とは、修正後にシステムが正常に動くかを確かめること。ログイン、検索、予約、データの登録など、システムが提供する機能に応じて確認すべき内容が変わる。
そして、ログの調査は、修正前に不審なアクセスや処理がなかったかを調べる作業である。
「修正が終わっても、動作確認が終わっていない場合があります。正常に動作していても、ログの調査が続いている場合もあります」
「では、復旧したシステムでも、まだ調査中ということがあるのですね」
「はい。何をもって復旧とするかは、システムの状態と、必要な確認内容を踏まえて判断する必要があります」
画面に表示されている「復旧」という言葉だけでは、実際に何が終わったのかはわからない。
修正済みなのか。
動作確認済みなのか。
サービスを再開しているのか。
それとも、調査を継続しているのか。
一つひとつを区別しなければ、組織内で情報を共有するときにも、利用者に状況を説明するときにも、誤解が生じる。
黒木は、報告書に各項目の状態を分けて記録するよう説明した。
◾️すべてのサイトが同時に戻るわけではない
夜が明けるころ、対応状況に少しずつ変化が現れ始めた。
修正方法を確認できたシステムでは、適用に向けた作業が進められていた。
別のシステムでは、管理する事業者との調整が続いていた。
そして、まだ管理者を特定できていないウェブサイトもあった。
同じPHPの問題であっても、システムごとに状況は異なる。
利用しているバージョンが違う。
サーバーの構成が違う。
プログラムを管理している会社が違う。
修正作業を行うための手順も、動作確認に必要な時間も違う。
あるサイトで修正が完了したからといって、別のサイトも同じ方法で直せるとは限らない。
「なぜ、すべて一斉に対応できないのでしょうか」
参加者が尋ねた。
「それぞれのシステムで、管理している環境やプログラムが異なるからです。どのシステムも同じ条件で動いているわけではありません」
黒木は説明した。
「一つの会社が管理しているように見えるサービスでも、サーバーの提供元、プログラムの開発元、保守を担当する会社が分かれている場合があります。実際の管理範囲と契約内容を確認しなければ、誰がどの作業を行うのか決められません」
外部に委託すること自体が問題なのではない。
外部の専門事業者に管理を任せることは、合理的な選択になり得る。
問題になるのは、自社が利用しているシステムについて、管理者や構成、連絡先、修正の手順を把握できていない場合だ。
緊急時になってから調べ始めれば、技術的な対応に取りかかるまでの時間が長くなる。
だからこそ、平時からシステムの一覧を整備し、契約情報と照合し、管理者や連絡先を明確にしておく必要がある。
ただし、一覧を一度作れば、それで終わりというわけでもない。
システムは更新される。契約先が変わる。担当者が異動する。新しいサービスが追加される。
管理情報も、実際のシステムに合わせて更新し続けなければならない。
◾️ 一時的な対策と、恒久的な修正
午後。
対応状況を確認する会議が、再び開かれた。
いくつかのシステムでは、必要な修正と動作確認が進んでいた。
一方で、すぐには修正できないものについては、外部からのアクセスを制限するなど、一時的な対策が検討されていた。
ここでも、区別しなければならないことがある。
一時的な対策は、修正が完了するまでの危険を減らすために行うものだ。
たとえば、特定の機能を停止する、アクセスできる範囲を制限する、適切な防御策を追加するといった方法がある。
しかし、それらが有効かどうかは、脆弱性の内容やシステムの構成によって異なる。
すべての攻撃を防げると保証されるわけではない。
また、恒久的な修正が必要な場合には、修正プログラムの適用や、開発元が案内する対応を進めなければならない。
「一時的な対策を実施したシステムについても、残っているリスクと、次に必要な作業を明確にする必要があります」
黒木は、会議に説明した。
「対策を実施したという記録だけではなく、何を防ぐための対策なのか、どこまで有効なのか、いつまでに次の作業を行うのかを確認する必要があります」
会議では、各システムの状況と事業への影響を踏まえ、継続、制限、一時停止などの対応方針が検討された。
黒木は技術的な状況を説明し、担当部署はそれぞれのシステムについて必要な情報を提供した。
そして、最終的な方針は会議で決められた。
◾️次の脆弱性に備える
対応が進むにつれて、今回の問題から見直すべき点も明らかになってきた。
まず、社内で利用しているシステムを把握すること。
次に、それぞれのシステムの管理者、保守会社、サーバーの管理先、ソフトウェアのバージョンを記録すること。
さらに、脆弱性が見つかったときに、誰へ連絡し、誰が修正し、誰が結果を確認するのかを明確にしておくこと。
そして、修正した日時、動作確認の結果、ログの調査状況などを記録し、必要な人が参照できるようにすること。
こうした準備は、今回のPHP問題だけに必要なものではない。
今後、別のソフトウェアに脆弱性が見つかった場合にも、同じように影響範囲を確認し、対策を検討する必要がある。
すべての脆弱性を事前に予測することはできない。
すべての攻撃を防げると保証することもできない。
しかし、問題が起きたときに、何が使われているのか、誰が管理しているのか、どこへ連絡すればよいのかを把握していれば、対応を始めるまでの時間を短くできる。
黒木は、更新されたシステム一覧を確認した。
確認済みの項目は増えていた。
しかし、すべての欄が埋まったわけではない。
まだ回答を待っているものがある。
まだ調査が続いているものがある。
そして、システムの管理状況そのものを見直さなければならない項目も残っていた。
それらは、今後の課題として記録された。
◾️ 午後の報告
午後の報告では、対応が進んだシステムと、引き続き確認が必要なシステムが区別されていた。
修正を適用し、動作確認を終えたもの。
一時的な対策を実施し、恒久的な修正を待っているもの。
管理者や構成の確認を続けているもの。
ログの調査が継続しているもの。
それぞれの状態が報告された。
すべてのサイトが復旧したわけではなかった。
また、現時点で明確な攻撃の痕跡が見つかっていないことと、すべてのシステムについて侵入がなかったと確認できたことは、別の話だった。
黒木は、報告の内容を確認した。
彼の役割は、わかっていることと、まだわかっていないことを整理し、技術的なリスクを説明することだった。
どのサービスを継続し、どのサービスを制限し、どのサービスを停止するのか。
その判断は、技術的な情報だけで決まるものではない。
事業への影響、利用者への責任、契約上の条件、復旧に必要な時間。
それらを踏まえた組織としての判断が必要になる。
会議では、報告された状況に基づき、引き続き対応を進めることが確認された。
黒木は、画面を閉じる前に、もう一度、一覧を見た。
まだ、確認の終わっていない項目がある。
だが、それは、何も進んでいないという意味ではなかった。
わからないことを明確にし、誰が確認するのかを決め、必要な情報を集める。
その積み重ねが、次の判断につながっていく。
【サイバー危機管理に、終わりはあるのか】
ソフトウェアに脆弱性が見つかることを、完全になくすことはできない。
システムが複雑になれば、利用するソフトウェアも、管理する会社も、連携するサービスも増えていく。
自社で開発したプログラムだけを確認すればよい時代ではない。
外部の事業者が提供するサーバーやサービスを利用し、その上で別の会社が開発したプログラムを動かすこともある。
契約書があっても、すべての技術情報がそこに記載されているとは限らない。
専門会社に任せていても、緊急時に必要な情報がすぐに手に入るとは限らない。
だからこそ、企業には、システムの構成を把握し、管理者と連絡先を明確にし、修正や調査の結果を記録する仕組みが必要になる。
そして、脆弱性への対応では、修正すること、正常に動作することを確認すること、過去に侵入されていないか調査することを、区別して考えなければならない。
サービスが再開したとしても、必要な調査が終わっているとは限らない。
反対に、調査が継続しているからといって、すべてのサービスを必ず停止しなければならないわけでもない。
それぞれの状況とリスクを確認し、組織として判断していく必要がある。
今回の問題で、すべての不確実性がなくなったわけではない。
それでも、確認できたことは増えた。
誰が管理しているのか。どのバージョンを使っているのか。どの修正が必要なのか。どこに、まだ確認できていない問題が残っているのか。
その一つひとつを明らかにすることで、次の対応は少しずつ進めやすくなる。
「問題を完全になくすことはできなくても、わからないことを放置する時間は短くできる。」
サイバー危機管理とは、そのための仕事でもある。
復旧は、終わりではない。
次の問題に備えるための、新しい始まりなのである。
