↓ ↑ページトップへ
表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
0/400
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。
PHP脆弱性問題『Cyber Attack/日常生活への攻撃』Cyber Incident Management for PHP Vulnerability  作者: 東曌


この作品ページにはなろうチアーズプログラム参加に伴う広告が設置されています。詳細はこちら

PR
6/8

第六話 解析できても、安全とは限らない 改訂版

第六話 解析できても、安全とは限らない



 午前八時十二分。


 佐伯の端末に、新しい監視データが表示された。


 アクセス記録の増加を示すグラフが、画面の右端で大きく跳ね上がっている。


「また増えました」


 若手の調査担当者が言った。


「どのくらいだ」


「対象システムの一つで、直近の集計が一分間に三百件近くです」


 佐伯は、画面を確認した。


 三百件。


 一分間に三百件なら、一時間で一万八千件になる。


 同じペースが二十四時間続けば、四十三万件を超える。


 もちろん、記録されたアクセスが、すべて攻撃に成功したことを意味するわけではない。正当なアクセスや、自動的な接続確認などが混じる場合もある。攻撃を試みたアクセスでも、防御機能によって遮断されていることがある。


 それでも、調査しなければならない記録は増え続けていた。


「まず、自動検出の結果を確認しよう。すべてを同じ扱いにするな」


「はい」


 若手は、監視システムの画面を開いた。


 アクセスの時刻、送信元、対象となった機能、応答の内容。システムが検出した特徴に応じて、記録が分類されている。


 その中には、公開されている攻撃プログラムの特徴と似たものもあった。


「このグループは、既知の攻撃パターンと一致しています」


「一致しているのは、どの部分だ?」


「送られてきたデータの特徴です。ただ、実際に脆弱性を利用できたかどうかまでは、ここだけではわかりません」


「そうだ。検出結果と、攻撃の成否を混同しないように」


 佐伯は、該当する記録を詳しく調べることにした。


 攻撃の形に似たデータが送られてきた。


 それは確認できた。


 しかし、そのデータをシステムがどう処理したのか。


 修正プログラムが機能したのか。


 その後、予期しない動作が発生していないか。


 そこまで確認して、初めて判断に近づくことができる。


     *


 午前九時。


 調査チームの会議室には、複数の画面が並んでいた。


 アクセスの急増を示すグラフ。


 自動検出された不審な記録。


 修正プログラムの適用状況。


 そして、調査が終わっていないシステムの一覧。


「自動検出で、攻撃らしいアクセスを分類できるんですよね」


 若手が尋ねた。


「できる範囲はある。ただし、検出できたことと、何が起きたのかを完全に理解できたことは違う」


 佐伯は説明した。


「既知の攻撃パターンに一致するものは、比較的分類しやすい。一方で、データを少し変えたものや、別の方法で同じ弱点を狙うものは、検出のされ方が違う場合もある」


「では、すべてを自動で判断するのは難しいんですね」


「そうだ。自動化は、大量の記録を整理するために重要だ。しかし、システムへの影響や、侵入の有無を判断するには、前後の記録や実際の動作も確認する必要がある」


 若手は、画面を切り替えた。


「こちらは、アクセスが遮断された記録です」


「遮断されたことは確認できているな」


「はい。ただ、同じ時間帯に、別のアクセスもあります」


「では、そのアクセスとの関係を調べよう。遮断された記録だけ見て、システム全体が安全だとは判断できない」


 佐伯は、調査対象を整理した。


 大量のログを、端から端まで人間が読み続けるわけではない。


 自動検出で候補を絞り込み、関連する記録をまとめ、優先順位をつけて調べる。


 それでも、何を優先して調べるべきかを決めるには、システムの構成や、攻撃の特徴についての知識が必要だった。


 そして、記録そのものが不足していれば、調査できる範囲にも限界がある。


     *


 午前十時。


 事業部門の責任者が、調査チームを訪ねてきた。


「攻撃の状況は、わかってきましたか」


「一部のアクセスについては、特徴を分類できています。ただ、全体の状況を把握できたわけではありません」


「アクセスが三百件もあるということは、それだけ侵入されているんですか」


「いいえ。アクセス件数と、侵入に成功した件数は別です」


 佐伯は、画面を見せた。


「たとえば、攻撃者が弱点を狙うデータを送ってきても、修正プログラムが正しく機能していれば、攻撃が成立しない場合があります。防御機能が遮断することもあります」


「それなら、修正プログラムを適用したシステムは、もう大丈夫なのでは?」


「その脆弱性については、防御できている可能性があります。しかし、適用が正しいことと、ほかの問題がないことは、別に確認しなければなりません」


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


「攻撃者が別の脆弱性を狙っている可能性もあります。修正前に侵入されていた場合には、不正なプログラムや盗まれた認証情報が残っている可能性もあります」


「つまり、修正プログラムが効いているかどうかを調べるだけでは、足りない」


「はい。修正が対象の弱点に有効であることを確認する。そのうえで、システムの動作やアクセス記録を調べ、侵入や改変の兆候がないかを確認する。必要な確認は、システムごとに違います」


 責任者は、しばらく黙っていた。


「それで、いつ再開できるんですか」


 佐伯は、すぐには答えなかった。


「再開できる条件を満たしたサービスから、個別に判断することはできます。ただ、すべてのサービスについて、いま確実な日付を示すことはできません」


     *


 午前十一時三十分。


 調査チームは、アクセス記録の中から、優先して確認すべき事象を抽出していた。


 ある記録は、既知の攻撃パターンと一致していた。


 別の記録は、異常な応答を伴っていた。


 さらに別の記録は、アクセス自体に不審な特徴があったものの、攻撃だったと判断するには情報が不足していた。


「この異常な応答は、侵入に成功した証拠ですか」


 若手が尋ねた。


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


 佐伯は答えた。


「通常とは異なる応答があったことは確認できている。だが、その原因が攻撃によるものなのか、別の不具合なのか、追加の確認が必要だ」


「応答の前後に、何が起きたかを調べるんですね」


「そうだ。関連する記録を確認し、システム側の動作と照合する。もし侵入を示す兆候が見つかれば、影響範囲の調査に進む」


「見つからなかった場合は?」


「調査した範囲で、侵入を示す証拠が確認できなかった、と報告する。ただし、それが侵入が絶対になかったという意味になるとは限らない」


 若手は、記録に調査結果を追記した。


 確認できた事実。


 現時点での分析。


 まだ判断できないこと。


 それぞれを分けて記録する。


 その作業を続ける間にも、監視システムには新しいアクセスが届いていた。


 調査が終わった記録の後ろに、次の記録が積み重なっていく。


     *


 午後一時。


 佐伯は、修正プログラムを適用したシステムの確認結果をまとめていた。


 適用が確認できたもの。


 適用後の動作試験が終わったもの。


 関連するシステムの確認が残っているもの。


 過去のアクセス記録が不足し、侵入の有無について追加調査が必要なもの。


 それぞれの状態は違っていた。


「このシステムは、修正プログラムの適用が確認できています」


 若手が報告した。


「攻撃パターンに一致するアクセスも、遮断された記録があります」


「その後の動作は?」


「現時点では、侵入を示す明確な証拠は確認されていません。ただ、関連するシステムの確認が残っています」


「では、まだ全体の再開判断はできないな」


「はい」


 佐伯は、一覧表に記入した。


 修正プログラムが機能していることを確認できた部分は、前進している。


 しかし、そのシステムが接続している別のシステムまで、同じように確認できているとは限らない。


 サービスは、一つのプログラムだけで動いているわけではなかった。


 外部のサービス、認証の仕組み、データベース、管理用の機能。複数の要素が組み合わさって、一つのサービスを形作っている。


 利用者には、一つの画面に見える。


 だが、その画面の向こうには、確認すべき場所がいくつもあった。


     *


 午後三時。


 経営側との会議が開かれた。


「調査に時間がかかっている理由を、もう一度説明してもらえますか」


 責任者が尋ねた。


 佐伯は、用意した資料を表示した。


「まず、大量のアクセス記録を自動的に分類し、調査が必要なものを抽出しています。そのうえで、攻撃の特徴、システムの応答、前後の記録などを確認しています」


「すべてのアクセスを、一件ずつ調べているわけではないんですね」


「はい。自動検出を使って、優先順位をつけています。ただし、検出結果だけで、攻撃の成功や失敗をすべて判断できるわけではありません」


「では、解析が終われば、安全だと判断できるのですか」


「解析が終わった範囲について、判断できることは増えます。しかし、ログの解析だけで、安全性のすべてを証明できるわけではありません」


 佐伯は、続けた。


「修正プログラムが正しく適用されているか。実際に防御が機能しているか。侵入や改変の兆候がないか。関連するシステムにも問題が残っていないか。必要な確認を組み合わせて、再開を判断します」


「それでは、攻撃が続いている限り、調査も終わらないのではありませんか」


「監視は、再開後も続ける必要があります。ただし、攻撃があるという理由だけで、すべてのサービスを永久に止めるわけではありません。防御が機能し、必要な確認ができたサービスは、再開を検討できます」


「では、再開できないサービスは?」


「確認が足りない部分があるか、残るリスクを許容できると判断できていないということです。何が不足しているのかを明らかにして、調査を続ける必要があります」


 責任者は、資料を見つめた。


「利用者には、何と説明すればいいのでしょう」


「確認が進んでいることと、まだ再開できない理由を、分けて説明するべきだと思います。復旧時期を約束できないなら、そのことも正直に伝える必要があります」


     *


 午後五時。


 調査チームは、当日の進捗をまとめた。


 いくつかの攻撃パターンは分類できた。


 一部のアクセスについては、防御機能によって遮断されたことを確認できた。


 修正プログラムの適用状況を確認できたシステムも増えた。


 しかし、すべてのシステムについて、影響範囲の確認が終わったわけではなかった。


 さらに、新しいアクセス記録が増えていた。


「今日の解析結果は、まとまりました」


 若手が報告した。


「ありがとう。確認できたことと、残っている調査を分けて保存してくれ」


「はい」


 佐伯は、画面を見た。


 今日、調べた記録は、無駄ではなかった。


 攻撃の特徴を把握し、防御の働きを確認し、次に調べるべき箇所を絞り込めた。


 しかし、攻撃が続く以上、新しい記録は届き続ける。


 それらを調べることと、すでに確認したシステムの安全性を判断することは、別々の仕事として進めなければならなかった。


     *


 午後八時。


 帰宅途中の会社員が、スマートフォンで金融サービスを開いた。


 画面には、まだメンテナンスの表示が出ていた。


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


 いつまで使えないのだろう。


 自分の情報は、大丈夫なのだろうか。


 問い合わせ先を調べても、復旧時期は未定と書かれている。


 会社員には、攻撃ログも、修正プログラムも、侵入の調査も見えない。


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


 その不便が、現実だった。


 同じ頃、佐伯の端末には、新しいアクセス記録が届いていた。


 彼は、記録を保存し、監視システムの検出結果を確認した。


 攻撃の特徴に一致するものがある。


 しかし、それだけで、攻撃が成功したとは言えない。


 修正プログラムが機能している可能性もある。


 別の問題が起きている可能性もある。


 判断するには、追加の確認が必要だった。


 佐伯は、調査記録を開いた。


 大量のアクセスを分類する。


 攻撃の成否を確認する。


 修正プログラムが有効に働いているかを確かめる。


 侵入の兆候がないかを調べる。


 関連するシステムの状況を確認する。


 その作業を、一つずつ続ける。


 再開を急ぐ声は、当然だった。


 しかし、再開してから問題が見つかれば、その影響を受けるのは、画面の向こうにいる利用者だった。


 佐伯は、新しい記録を開いた。


 攻撃は、まだ続いていた。



【本文解説】



攻撃ログを解析することと、修正プログラムで防御できていると確認することは、別の作業です。


例えば、

1分間に約300件のアタックが記録されるなら、

単純計算で1時間に約18,000件。

24時間続けば約432,000件となります。


1分間に300件のアクセスが記録された場合


18,000件


1時間あたり


432,000件


24時間あたり


※300件/分が途切れず24時間続いた場合の計算です。実際の件数や攻撃の割合を示すものではありません。


ただし、ここで技術的に大切なのは、30万件、40万件のログを、技術者が一件ずつ手作業で読むわけではないという点。


通常は、監視システムで


大量のログから


・収集

・分類


し、既知の攻撃パターンや異常な挙動を検出します。

そのうえで、重要な記録を詳しく調べます。

それでも、今回の攻撃プログラムがどの脆弱性を狙っているのか、修正プログラムが実際に有効なのか、侵入がすでに起きていないかを確認するには、追加の調査が必要になります。


たとえば、次のような流れです。


大量のアクセスログ


1分間に約300件


・自動検出・分類


・攻撃の兆候、遮断状況、異常な応答を抽出


・技術者による詳細解析


・修正済みの脆弱性か、別の弱点か、侵入の痕跡か


・再開の判断


・防御の有効性、影響範囲、残るリスクを確認


そして、ログの解析が終わっても、それだけで防御できていると証明されたことにはなりません。

修正プログラムの適用状況、実際のシステムの動作、侵入の痕跡などを、別途確認する必要があります。


その結果、サイト復旧が遅れる。


攻撃者は、次々にアクセスを送り込める。

一方、防御側は、そのアクセスが何を意味するのかを見極め、必要な対策を取り、サービスを再開してもよいか判断しなければならない。


とても、難しい決断です。

評価をするにはログインしてください。
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
このエピソードに感想はまだ書かれていません。
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。