PHP脆弱性問題『Cyber Attack／日常生活への攻撃』Cyber Incident Management for PHP Vulnerability

第五話 再開ボタン

第五話　再開ボタン

　午前九時。

　会議室のモニターには、停止中のサービスと、対策作業の進捗が表示されていた。

　前日から、新たに確認された事象がいくつかある。

　しかし、いずれも、公開されている攻撃プログラムによるものだと断定できる段階にはなかった。

　修正プログラムを適用したシステムもある。

　設定の見直しを進めているシステムもある。

　そして、現在の構成を確認できず、対策の判断そのものが遅れているシステムもあった。

「佐伯さん」

　会議に参加していた事業部門の責任者が尋ねた。

「修正プログラムは、もう適用したんですよね。それなら、そろそろ再開できるのではありませんか」

　佐伯は、モニターから視線を外した。

「適用できたシステムについては、修正が正しく反映されているか、確認を進めています。ただ、それだけで安全性を確認できたことにはなりません」

「修正プログラムを入れたのに、ですか？」

「はい」

　責任者は、納得できないという表情を浮かべた。

「修正プログラムというのは、問題を直すためのものですよね」

「そのとおりです。ただし、何を修正するためのものなのか、そこを区別する必要があります」

　佐伯は、画面を切り替えた。

　　　　　＊

「たとえば、あるソフトウェアに、外部から送られたデータを適切に処理できない脆弱性があったとします」

　佐伯は説明を始めた。

「攻撃者は、その弱点を利用するように作られたデータを送り込み、想定されていない処理を実行させようとする。修正プログラムは、その問題が起きないように、ソフトウェアの処理を直すものです」

「つまり、穴を塞ぐわけですね」

「そうです。修正が正しく適用され、その脆弱性が解消されていれば、その弱点を利用する攻撃は防げるはずです」

　佐伯は、そこで一度、言葉を切った。

「ただし、修正プログラムを適用したという記録だけで、すべての安全性が証明されるわけではありません」

「どういうことです？」

「まず、修正が対象のシステムに正しく適用されているか。次に、修正されたソフトウェアが、実際にサービスで使われているか。そして、関連する設定や、別のシステムとの接続に問題がないか。確認すべき点は、システムの構成によって異なります」

　若手の調査担当者が口を開いた。

「更新作業が成功したという表示が出ても、それだけでは足りないんですね」

「そういうことだ」

　佐伯はうなずいた。

「更新作業が成功したことと、必要な修正が正しく反映され、期待どおりに動いていることは、別々に確認しなければならない」

　事業部門の責任者は、資料を見つめた。

「では、修正が終わったシステムでも、停止を続けることがあるわけですか」

「あります。安全性の確認が必要な場合もありますし、再開すると別の業務に影響が出る場合もあります」

「それでは、いつまでも再開できないのでは？」

「確認が終われば、再開できるものもあります。ただ、確認が終わっていないものまで、同じ扱いにはできません」

　　　　　＊

　佐伯は、次の画面を表示した。

　そこには、前日に検出された不審なアクセスの記録が並んでいた。

「もうひとつ、区別していただきたいことがあります」

　佐伯は言った。

「不審なアクセスがあったことと、攻撃が成功したことは同じではありません」

「アクセスがあったのに、成功していない場合があるんですか」

「あります。攻撃者が脆弱性を狙ったとしても、修正済みであれば、その手口が成立しないことがあります。防御機能によって遮断される場合もあります。逆に、アクセスが成功したように見えても、それだけでシステム内部への侵入や、情報の窃取まで確認できたことにはなりません」

　若手が記録を確認した。

「ということは、アクセスの記録だけでは、何が起きたのかを最後まで判断できないんですね」

「そうだ。アクセスの前後に何が起きたのか、システムがどう応答したのか、関連する記録に不審な動きがないか。必要な情報を集めて、判断する」

「もし、記録が残っていなかったら？」

　別の担当者が尋ねた。

「確認できる範囲が限られます」

　佐伯は答えた。

「記録がないことは、攻撃がなかった証拠にはなりません。ただし、記録がないからといって、攻撃が成功したと断定することもできない」

　会議室が静かになった。

　何が起きたのか、確認できていること。

　何が起きた可能性があるのか、調査中のこと。

　そして、記録が不足しているために判断できないこと。

　それらを混ぜてしまえば、誤った判断につながる。

　技術者が報告すべきなのは、安心させるための言葉でも、恐怖をあおるための言葉でもない。

　確認できた事実だった。

　　　　　＊

「では、修正プログラムを適用したあとに、別の攻撃を受ける可能性もあるということですか」

　事業部門の責任者が尋ねた。

「はい」

　佐伯は答えた。

「今回修正した脆弱性とは別の弱点を狙われる可能性があります。関連するシステムに修正が適用されていなければ、そこが問題になることもあります」

「でも、修正プログラムを入れれば、少なくとも今回の攻撃は防げるのでは？」

「今回の攻撃が、どの脆弱性を利用しているのか。適用した修正が、その攻撃に有効なのか。まず、そこを確認する必要があります」

　佐伯は、資料の一部を指さした。

「今回、公開されているプログラムと似た特徴を持つアクセスが確認されています。しかし、すべての事象が同じ手口によるものだとは、まだ断定できません」

「つまり、修正プログラムが攻撃に負けたということではない？」

「そうです。攻撃らしいアクセスがあったからといって、修正が破られたとは限りません。反対に、修正を適用したというだけで、すべての攻撃を防げるとも限らない」

　佐伯は、モニターに表示されたシステム一覧を見た。

「それに、すでに侵入されていた場合は、別の問題が残ります。脆弱性を修正しても、侵入後に設置された不正なプログラムや、盗まれた認証情報などが自動的に消えるわけではありません。必要に応じて、侵入の有無や影響を調査しなければなりません」

　責任者は、ようやく事情を理解し始めたようだった。

「穴を塞ぐ作業と、すでに誰かが入っていないか調べる作業は、別なんですね」

「はい。どちらも重要です」

　　　　　＊

　午前十一時。

　会議は、再開の判断に移った。

　停止中のサービスは、すべて同じ状態ではなかった。

　必要な修正を適用し、動作確認を進めているもの。

　対策は実施したものの、関連するシステムの確認が残っているもの。

　管理情報が不十分で、影響の有無を判断できていないもの。

　すでに不審なアクセスが確認され、追加の調査が必要なもの。

「すべてのサービスを、同じ日に再開する必要はないと思います」

　佐伯が提案した。

「安全性を確認できたものから、個別に判断することはできます。代替手段を用意できるなら、それも検討すべきです」

「一部だけ再開すると、利用者が混乱しませんか」

　事業部門の責任者が尋ねた。

「案内は必要です。ただ、一部のサービスに問題が残っているからといって、必要な確認が終わったサービスまで、一律に停止し続けるべきかどうかは、別に判断できます」

　上司が続けた。

「もちろん、再開によって別のシステムに危険が及ばないかも確認しなければならない。サービスごとに影響範囲が違う以上、再開の条件も同じではありません」

　経営側の担当者は、資料をめくった。

「では、再開できるサービスと、できないサービスが並ぶことになるんですね」

「そうなります」

　佐伯は答えた。

「ただし、再開できると判断した範囲についても、何を確認したのか、何が未確認なのかを明確にしておく必要があります」

「それでも、利用者は納得しないでしょう。なぜ、こちらは使えて、あちらは使えないのかと」

「その理由を説明することも、必要だと思います」

　佐伯は、そう答えるしかなかった。

　　　　　＊

　午後一時。

　再開候補となっていたサービスについて、追加の報告が届いた。

　修正プログラムの適用は確認できた。

　しかし、外部サービスとの接続試験で、想定していない動作が見つかったという。

　その動作が、今回の脆弱性と関係しているのかは、まだわからない。

　担当者は、再開を延期する判断を求めてきた。

「修正はできているのに、ですか」

　事業部門の責任者が、思わず声を上げた。

「修正そのものとは別に、接続先との動作を確認する必要があります」

　佐伯は答えた。

「この状態で再開して、利用者のデータが正しく処理されなかったり、別の障害が起きたりすれば、さらに問題が増える可能性があります」

「では、いつまで待てばいいんですか」

「確認が終わるまでです」

　その言葉を口にした佐伯自身も、それが相手の求めている答えではないことを理解していた。

　しかし、根拠のない日付を示すことはできなかった。

　安全性を確認するための作業に、確実な終了時刻を与えることは難しい。

　新しい問題が見つかれば、追加の調査が必要になる。

　確認が終わるまで待てば、利用者への影響は続く。

　確認を急げば、見落としが生じる可能性がある。

　どちらを選んでも、何らかの負担が生じる。

　　　　　＊

　午後三時。

　佐伯は、利用者向けのお知らせの案を確認していた。

『システムの安全性を確認するため、現在もサービスを停止しております。復旧時期は未定です』

　昨日と、ほとんど変わらない文章だった。

「これでは、何も進んでいないように見えますね」

　若手が言った。

「実際には、進んでいる」

　佐伯は答えた。

「修正を適用できたシステムもある。確認できた情報も増えた。ただ、まだ再開の判断に必要な確認が残っているんだ」

「その進展を、利用者に伝えられないんでしょうか」

「伝えられることは伝えたほうがいい。ただし、部分的な進展を、全体が安全になったかのように説明してはいけない」

　佐伯は、文章を読み返した。

　利用者が知りたいのは、専門的な調査の詳細ではない。

　いつ使えるようになるのか。

　自分の情報は安全なのか。

　代わりに利用できるサービスはあるのか。

　そうしたことだった。

　しかし、調査が終わっていない以上、答えられない質問もある。

　答えられないことを隠せば、後で説明の信頼性が失われる。

　正直に伝えれば、不安を招くかもしれない。

　それでも、わからないことを、わかったふりで埋めるわけにはいかなかった。

　　　　　＊

　午後六時。

　会議室のモニターには、最新の状況が表示されていた。

　修正を適用したシステムがある。

　安全性の確認を進めているシステムがある。

　調査が続いているシステムがある。

　そして、再開のめどが立っていないサービスも、まだ残っていた。

「今日の結論をまとめます」

　上司が言った。

「対策が進んだことは事実だ。しかし、攻撃の全容はわかっていない。すべてのシステムの安全性を確認できたわけでもない。したがって、全体の復旧時期は示せない」

　誰も反対しなかった。

　佐伯は、調査記録を保存した。

　修正プログラムは、必要な脆弱性を修正するためにある。

　それは確かな前進だった。

　しかし、修正プログラムは、すべての攻撃を消し去る魔法ではない。

　どのシステムに何が適用され、どこまで有効性を確認できたのか。すでに侵入されていないか。関連するシステムに問題が残っていないか。

　それらを確認して、初めて再開の判断に近づくことができる。

　そして、その作業が続いている間にも、攻撃が止まる保証はなかった。

　　　　　＊

　午後八時。

　会社員が、帰宅途中の電車でポイントサービスを開いた。

　画面には、まだ同じ表示が出ていた。

『ただいまメンテナンス中です』

　会社員は、ため息をついた。

　今日も使えなかった。

　明日なら使えるのだろうか。

　画面を閉じ、別のサイトを開いた。

　そちらも、メンテナンス中だった。

　会社員は、スマートフォンを握り直した。

　自分には、何が起きているのか、わからない。

　ただ、昨日まで使えていたものが、今日も使えない。

　それだけは、確かなことだった。

　その頃、佐伯の端末には、新しい調査依頼が届いていた。

　修正プログラムの適用状況を確認できていないシステムについて、追加の情報が必要だという。

　佐伯は、資料を開いた。

　再開ボタンを押すことは、難しくない。

　難しいのは、そのボタンを押してもよいと、根拠をもって判断することだった。

　そして、その判断を下せる日がいつ来るのか。

　まだ、誰にもわからなかった。