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

第八話 「気をつけてください」では、蚊は防げない

第八話　「気をつけてください」では、蚊は防げない

「結局、利用者に気をつけてもらうしかないんですかね」

若手の調査担当者が、画面から目を離さずに言った。

佐伯は、手元の資料を閉じた。

「君、キャンプに行ったことはあるか？」

「え？　ありますけど」

「夏場のキャンプ場で、蚊が飛んでいたらどうする？」

「虫よけを使います。蚊取り線香も、場合によっては」

「そうだろうな。では、キャンプ場の管理人が、利用者にこう言ったらどうだ」

佐伯は、わざとらしく声を整えた。

「皆さん、蚊に刺されないよう、十分に気をつけてください」

若手は、少し考えた。

「……蚊取り線香くらい、用意してほしいですね」

「そういうことだ」

佐伯は、再び資料を開いた。

「危険があると分かっているなら、注意を呼びかけるだけでなく、危険を減らすための手段を用意する。それが管理する側の仕事だ」

「サイバーセキュリティも同じ、ということですか」

「同じだ。ただし、蚊取り線香を一本置けば済むほど単純ではないがな」

若手は苦笑した。

「パスワードを使い回さないでください。不審なメールを開かないでください。知らない相手からの連絡には注意してください。そういう注意喚起は、もちろん必要です」

佐伯は続けた。

「だが、利用者が何も間違ったことをしていなくても、システムの脆弱性を突かれることはある。正規の認証情報が盗まれることもある。外部サービスの問題が、自社のサービスに影響することもある」

「利用者が気をつけていても、防げない攻撃がある」

「そうだ。だから、利用者に注意を求めることと、サービスを提供する側が防御することを、混同してはいけない」

若手は、ノートを開いた。

「では、具体的には何をすればいいんでしょう」

「順番に考えよう」

佐伯は、ホワイトボードに三つの項目を書いた。

**事故の前。事故の最中。事故の後。**

「まず、事故の前だ。脆弱性を把握して、必要な修正を行う。外部サービスも含めて、どこに重要な情報があり、どこからアクセスできるのかを確認する。それから、認証情報が漏れた場合でも、簡単に重要な操作を実行できない仕組みを考える」

「多要素認証や、アクセス権限の制限ですね」

「そのとおり。必要な対策はシステムによって違う。大切なのは、対策を導入したという事実だけで安心しないことだ」

佐伯は、次の項目を指した。

「事故の最中。ここが重要だ」

「侵入を検知したとき、ですか」

「侵入したかどうか、確証が得られるまで何もしないのか。それとも、被害が広がる可能性を考えて、先に制限をかけるのか。状況によって判断は変わる」

「金融サービスなら、不正な注文が疑われる場合もありますね」

「そうだ。異常な注文を検知したなら、対象の取引や機能を一時的に制限する必要があるかもしれない。ただし、根拠なくサービス全体を止めれば、それ自体が利用者への損害につながることもある」

若手はうなずいた。

「つまり、止めるかどうかも、あらかじめ判断基準を決めておく必要がある」

「誰が判断するのかもな。夜中に異常が発生したとき、担当者が上司の返事を待ち続けるようでは困る。どの段階で誰に連絡し、誰が停止を決断するのか。そこまで決めておく」

「技術者が危険を見つけても、組織が動かなければ意味がないんですね」

「技術者の役割は、危険を分析し、根拠を示して報告することだ。経営側には、その報告を受けて事業上の判断をする責任がある。もちろん、危険を過小評価したり、都合の悪い報告を無視したりしていいわけではない」

佐伯は、三つ目の項目に丸をつけた。

「そして、事故の後だ」

「原因究明と復旧ですね」

「それだけじゃない。ログを保全し、どのアカウントが、いつ、何にアクセスし、どんな操作を行ったのかを調べる。影響を受けた範囲を確認して、利用者に必要な説明をする。再発を防ぐために、対策を見直す」

「修正パッチを適用すれば、それで終わりではない」

「よく分かってきたな」

佐伯は、ホワイトボードの三つの項目を眺めた。

「例えば、PHPの脆弱性が公表されたとする。修正パッチを適用すれば、少なくともその脆弱性への対処はできるかもしれない。だが、それ以前に侵入されていた可能性まで、自動的に消えるわけじゃない」

「脆弱性を修正することと、過去に侵入されたか調べることは、別の作業なんですね」

「そのとおりだ。修正したから安全だ、と判断する前に、必要な範囲で過去のアクセス履歴も確認しなければならない」

若手は、少し考えてから尋ねた。

「では、攻撃コードが公開されていた場合はどうですか。コードを公開した人物が、実際の攻撃者なんでしょうか」

「まだ、そうとは言えない」

佐伯は即答した。

「公開した人物と、そのコードを使った人物が同一とは限らない。コードが公開された時期と、実際の攻撃が発生した時期が近くても、それだけで因果関係が証明されるわけではない」

「ログや通信記録など、別の証拠が必要なんですね」

「そうだ。私たちが扱うのは、推測ではなく、証拠に基づく調査だ」

佐伯は、ホワイトボードの端に新しい言葉を書いた。

**能動的サイバー防御。**

若手が顔を上げた。

「最近、よく聞く言葉ですね」

「簡単に言えば、攻撃を受けてから対応するだけではなく、脅威の兆候を把握し、被害が起きる前に防ぐことを目指す考え方だ。ただし、企業が行うセキュリティ対策と、国が制度に基づいて行う能動的サイバー防御は、同じものではない」

「国が攻撃者のシステムに自由に侵入して、やり返すという意味ではないんですね」

「そういう単純な話ではない。国の対応には、法令上の権限や手続きが関わる。企業の対策も、法律や契約、関係機関との連携を踏まえて行う必要がある」

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

「それに、攻撃に使われたサーバーを止めれば解決する、とも限らない。第三者が侵害され、知らないうちに攻撃に利用されているサーバーかもしれないからな」

「攻撃者を止めようとして、別の被害を生む可能性もある」

「だからこそ、証拠と権限と判断手順が必要なんだ」

若手は、ノートに書き込んでいた手を止めた。

「結局、技術だけでは足りないんですね」

「技術は必要だ。だが、それを使って何を守るのか、異常が起きたときに誰が判断するのか、事故の後にどう説明するのか。そこまで決めて、初めて組織としての対策になる」

若手は、最初の質問を思い出したように言った。

「利用者に気をつけてもらうだけでは、どうにもならない」

「そうだ。注意喚起は必要だが、それを防御の代わりにしてはいけない」

佐伯は、ホワイトボードの三つの項目を指でなぞった。

事故の前。

事故の最中。

事故の後。

そのどこにも、利用者の注意だけで済ませられる場所はなかった。

「蚊取り線香を用意するのは、誰の仕事でしょうね」

若手が、ふと思いついたように尋ねた。

佐伯は少し笑った。

「管理する側の仕事だ。ただし、利用者にも、虫よけを使う自由と、自分を守る手段は必要だ」

「企業の責任と、利用者ができる対策。その両方ですね」

「そういうことだ」

佐伯は、調査記録に向き直った。

彼らがいま調べているのは、ひとつの脆弱性と、いくつものアクセス履歴だった。

まだ、攻撃の全体像は見えていない。

誰がコードを公開したのか。誰が実際に使ったのか。どの経路から侵入したのか。何が被害を受けたのか。

分からないことは、まだ多い。

だからこそ、分からないことを分かったふりで埋めてはいけない。

証拠を集め、危険を評価し、必要な対策を実行する。そして、判断した理由を記録に残す。

それが、佐伯たちの仕事だった。

「気をつけてください、と言うだけなら簡単です」

若手が、ノートを閉じながら言った。

「でも、何をどうすればいいのかを決めるのは、簡単じゃないですね」

「だから、私たちがいる」

佐伯は、再びログの解析を始めた。

蚊がいると知らせるだけでは、人は守れない。

必要なのは、蚊取り線香を用意し、その効果を確かめ、切れたときには交換することだ。

サイバーセキュリティも、同じだった。

**注意を呼びかけるだけで終わらせない。対策を実行し、効果を確かめ、改善を続ける。**

守るというのは、そういう仕事なのだ。