" Cyber Crisis Management " 最高情報責任者・黒木 厳の責任 " UN POUR TOUS, TOUS POUR UN."

Cyber Incident Management for PHP Vulnerability 第一話 改訂版

今回のお話は、PHP問題のお話です。

自社のサーバーを管理しているつもりでも、実際には委託先が管理し、その先にも別の事業者がいる。 これが現代のサイバーセキュリティの難しさです。

今回のPHP問題なら、

・自社はウェブサイトの運営を外部に委託している。

・委託先は、別の会社のホスティングサービスを利用している。

・サーバーの管理者と、PHPで動くアプリケーションの管理者が違う。

・脆弱性が公表されても、誰が、どの環境を、いつ更新するのか、すぐにはわからない。

・契約書に責任分担が書かれていても、緊急時に連絡が取れるとは限らない。

しかも、委託先に任せたからといって、委託元の責任がすべてなくなるわけではありません。

一方で、委託元が技術的な作業をすべて自分で実施できるわけでもない。

ここに、黒木の仕事があります。

黒木は、脆弱性そのものを消せるわけでも、すべての委託先を直接動かせるわけでもない。

できるのは、事実を把握し、リスクを説明し、対応状況を確認し、経営が判断できる状態をつくること。

そして会議が方針を決めても、委託先の回答が遅れたり、契約範囲が曖昧だったりすれば、すべてが一度に解決するわけではありません。

それでは、本文をご確認ください。

---

第1話　PHP問題――緊急警報

午後十時十二分。

サイバーナイト株式会社の最高情報責任者、黒木厳のスマートフォンが震えた。

社内の緊急連絡用チャンネルに、セキュリティ担当者からメッセージが届いていた。

《PHPに重大な脆弱性。修正版の公開に備え、影響を受けるサーバーの確認を急いでください》

黒木は、画面を見つめた。

PHP。

ウェブサイトやウェブサービスの裏側で動く処理を記述するために、広く使われているプログラミング言語だ。会員情報の照会、商品の検索、問い合わせフォームの処理など、利用者の目には見えない部分で働いている。

そのPHPに、重大な脆弱性が見つかった。

脆弱性とは、ソフトウェアに存在するセキュリティ上の弱点のことだ。

問題の深刻さは、弱点があるという事実だけではない。その弱点を攻撃者に悪用された場合、条件によっては、外部からサーバー上で不正なプログラムを実行されるおそれがある。

会社のウェブサイトが改ざんされるかもしれない。

顧客情報を扱うシステムに被害が及ぶかもしれない。

そして、事業そのものが止まる可能性もある。

黒木はニュースサイトを開いた。

首相のXへの投稿が紹介されていた。修正版の適用に備えること、対応が難しい場合にはウェブサイトの一時停止も選択肢になることを呼びかけている。

政府からも警戒が促されていた。

黒木は投稿を読み終えると、スマートフォンを机に置いた。

「警告は出た。では、うちは何をすればいい？」

問いかけた相手はいなかった。

いや、答えを出すべき人間は、自分だった。

　　　　　＊

午後十時二十分。

黒木は、情報システム部門、セキュリティ担当、ウェブサイト運用担当者を集め、緊急のオンライン会議を開いた。

「最初に確認する。今回の脆弱性を狙った攻撃を、すでに検知しているか？」

セキュリティ担当者が答えた。

「現時点では、攻撃を受けたと判断できる情報は確認されていません。ただし、ログの確認は継続中です」

「つまり、被害がないと確認できたわけではない？」

「はい。現時点で、攻撃の痕跡を確認できていないということです」

黒木はうなずいた。

「その違いを、全員が理解しておいてほしい」

今回の問題には、二つの段階がある。

ひとつは、脆弱性が存在するシステムを見つけ、修正や暫定的な防御を行うこと。

もうひとつは、すでに攻撃された疑いがあれば、証拠を保全し、被害の範囲を調べ、被害拡大を防ぐことだ。

前者は脆弱性管理を中心とした予防対応。後者はサイバーインシデントへの緊急対応となる。

もちろん、両者は完全に切り離せるものではない。

予防対応を進めながら、攻撃の痕跡がないかを調べる必要がある。もし不審な挙動が見つかれば、ただちに対応の段階を引き上げなければならない。

「CSIRTには連絡したか？」

CSIRTとは、サイバーセキュリティ上の問題が起きたとき、情報を集め、関係部署と連携し、対応を指揮・支援するための専門チームだ。

「招集を進めています」

「では、脆弱性管理とインシデント対応の両方を視野に入れて進めよう。攻撃が確認されていないからといって、何もしなくていいわけじゃない」

黒木は画面に資料を共有した。

「まず、影響を受けるシステムを特定する。PHPを使っているシステムはどれだ。バージョンはいくつだ。誰が管理している？」

セキュリティ担当者が答えた。

「社内のサーバー台帳を確認しています」

「外部に委託しているシステムは？」

「それは別途、各部門に確認が必要です」

黒木は資料から目を上げた。

「別途、というのは、今すぐ一覧を出せないということか？」

「……はい」

　　　　　＊

午後十時三十分。

最初の調査結果が画面に表示された。

社内で管理している主要システムの一部は、PHPを使用していないことが確認できた。しかし、PHPを使っているシステムについても、すべてのバージョンが判明したわけではなかった。

さらに、社内のサーバー台帳には、外部の事業者が管理する環境が十分に記載されていなかった。

「契約先の一覧は？」

黒木が尋ねた。

情報システム部門の責任者が答えた。

「調達部門が契約台帳を管理しています」

「その台帳で、どのサーバーがPHPを使っているかまでわかるのか？」

「いいえ。契約先や契約内容が中心です」

「では、契約先はわかっても、そこで何が動いているかは別に調べなければならない？」

「そのとおりです」

黒木は短く息を吐いた。

契約書が存在することと、システムの実態を把握していることは違う。

サーバーを借りている会社。ウェブサイトを制作した会社。保守を担当している会社。それぞれが異なる場合もある。

契約を更新していても、担当者が異動していれば、詳しい構成を知る人間が社内にいないことだってある。

「調達部門に連絡してくれ。契約台帳を出してもらう。それから、各事業部門にも確認する。自分たちで直接契約しているウェブサービスがあれば、すべて報告してもらおう」

「承知しました」

「それと、外部事業者からの公式発表も集めてくれ。修正版の提供時期、適用方法、暫定措置。事業者ごとに違う可能性がある」

黒木は続けた。

「わからない項目は、空欄のままにしないで『未確認』と書くこと。確認できていないものを、安全だと扱うのは禁止だ」

　　　　　＊

午後十時四十分。

黒木のもとに、セキュリティ担当者から追加報告が届いた。

《現時点で、侵入を示す明確な痕跡は確認できていません。対象システムの特定とログの確認を継続します》

黒木は、その報告を読み、ひとつだけ質問を返した。

《ログは、必要な期間分が保存されているか》

攻撃の痕跡を調べるには、記録が必要だ。

いつ、どこから、どのようなアクセスがあったのか。通常とは異なる処理が実行されていないか。ファイルが書き換えられていないか。

もし不審な挙動が見つかれば、ログを保全し、影響範囲を調査しなければならない。

ただし、ログが残っているからといって、必ず侵入の有無を判定できるわけではない。記録されない処理もあれば、保存期間が短い場合もある。

「調査中」と「異常なし」は違う。

黒木は、その点を何度でも確認するつもりだった。

　　　　　＊

午後十一時。

PHPの修正版が公開されたとの連絡が入った。

会議の参加者が、次々と対応状況を確認し始めた。

「修正版が出たなら、すぐに更新すればいいのでは？」

ウェブサイト運用担当者が言った。

「更新できる環境なら、それが基本だ。ただし、対象のサーバーとバージョンを確認し、適切な修正版を適用する必要がある。外部の事業者が管理している場合は、作業の分担も確認しなければならない」

黒木は、そう答えた。

「それから、更新できない場合の対策も調べる。WAFの設定変更などで一時的にリスクを下げられる場合はあるが、それで修正そのものが不要になるわけではない。必要なら、サービスの一時停止も検討する」

「停止の判断は、誰が？」

「影響を整理したうえで、権限と責任の所在を明確にして決める。技術的に止められるかどうかだけでなく、止めた場合に何が起きるかも調べる」

サイバーセキュリティの問題は、技術者に任せておけば終わるものではない。

止めれば、顧客や取引先に影響が出るかもしれない。

止めなければ、攻撃を受けたときに被害が拡大するかもしれない。

その両方を理解したうえで、組織として決断しなければならない。

黒木は、再びスマートフォンを見た。

首相の投稿は、さらに多くの人に共有されていた。

警告を出すことには意味がある。

しかし、警告を受け取った会社が、自社のシステムを把握していなければ、何を更新すればいいのかさえ、すぐにはわからない。

「準備をしろ、と言われてから準備を始める。それ自体は仕方がない」

黒木はつぶやいた。

「だが、何を使っているのかもわからない状態は、今回だけの問題じゃない」

　　　　　＊

午後十一時二十分。

ようやく、サイバーナイト株式会社の一部ウェブサービスについて、契約先が判明した。

ブロッサムネット株式会社。

同社は、サイバーナイトの一部ウェブサービスをホスティングしている事業者だった。

黒木は、担当窓口への緊急連絡を指示した。

確認事項は四つ。

一、今回の脆弱性の影響を受けるサーバーがあるか。

二、修正版を適用できるか。できる場合、いつ実施できるか。

三、適用までの間に取れる暫定措置はあるか。

四、サイバーナイト側で設定変更やサービス停止を行う必要があるか。

「ブロッサムネットに連絡がついたら、対象サーバーを特定してくれ。こちらの台帳と突き合わせる。作業を任せる場合も、何を、いつ、どこまで実施したのか、記録を残してもらうんだ」

「承知しました」

黒木は、調査表を見た。

確認済み。

調査中。

未確認。

その三つの欄に、少しずつ情報が埋まっていく。

だが、まだ空欄は残っていた。

サイバーナイトが攻撃を受けたという証拠は、現時点では確認されていない。

だからといって、すべてのシステムが安全だと断言できるわけでもない。

黒木は、会議の参加者に告げた。

「今回の対応は、まず脆弱性管理として進める。同時に、攻撃の痕跡がないかを調べる。不審な挙動が見つかったら、CSIRTを中心にインシデント対応へ移行する」

そして、最後にこう付け加えた。

「何も起きていないことを確認するのも、仕事のうちだ。ただし、確認できていないことを、何も起きていないと言い換えてはいけない」

午前零時を過ぎても、調査は続いていた。

ウェブサイトは動いている。

だが、動いていることと、安全であることは同じではない。

黒木は、ブロッサムネットからの回答を待ちながら、調査表の空欄を見つめていた。

PHPの問題は、技術者だけの問題ではなかった。

会社が何を契約し、何を外部に預け、誰がその状態を把握しているのか。

そして、警告を受け取ったとき、誰が判断し、誰が動くのか。

それを明らかにすることもまた、サイバーインシデントマネジメントの仕事だった。

黒木は、まだ知らなかった。

今回の調査で、契約台帳にもサーバー台帳にも、すぐには見つからないシステムが、もうひとつ浮かび上がってくることを。