【新連載】未来のサイバー防御を考える（第2回）

フォレンジック可観測性は、現在のネットワーク機器でどこまで実現しているのか

前回の記事では、英国国家サイバーセキュリティセンター（NCSC）が提唱する「フォレンジック可観測性（Forensic Observability）」という考え方を紹介しました。

それは単純に、「もっと多くのログを保存しよう」という話ではありませんでした。

重大なサイバー攻撃を受けたとき…

何が起きたのか
どのプロセスが動いたのか
どの設定が変更されたのか
攻撃者はどこまで到達したのか
そして、その機器を再び信用してよいのか

こうした事実を、攻撃後に可能な限り再構成できるよう、ネットワーク機器そのものを最初から設計しておく。

それがフォレンジック可観測性という考え方です。

ここで一つの疑問が生まれます。

現在販売され、世界中の企業で使用されているネットワーク機器は、この考え方をどこまで実現しているのか？…ということです。

今回はCisco、Fortinet、Palo Alto Networks、Juniper Networks、そしてNCSC自身が実例として取り上げているSophosの公開資料を調べてみました。

調べてみると、少し意外な姿が見えてきました。

NCSCが要求しているのは「ログ」だけではない

最初に確認しておきたいのが、NCSCの要求水準です。

2025年2月、英国NCSCは、米CISA、FBI、オーストラリアASD、カナダCCCS、ニュージーランドNCSCと共同で、ネットワーク機器メーカー向けのガイダンスを公開しました。

この文書は、ネットワーク機器に求める“最低限のフォレンジック可視性（minimum requirement for forensic visibility）”を示しています。

そこに書かれている要求は、かなり踏み込んでいます。

認証の成功・失敗だけでなく、プロセスの生成・終了、動的に読み込まれたライブラリ、重要ファイルの作成・変更・削除、DNS問い合わせ、ソフトウェア更新、設定変更、設定のバックアップやダウンロード、さらにはログを消去・ローテーション・操作しようとした行為まで、調査に必要な情報を記録できることを求めています。

さらに重要なのは、単に機器内部へログを残すだけではないことです。

NCSCは、機器固有の識別情報、正確な時刻、機械処理しやすい形式、そして安全な外部転送などを重視しています。

そして非常に興味深い考え方が「heartbeat」です。

何も異常が発生していない場合でも…

ソフトウェアのバージョン
設定情報のハッシュ
最後に再起動した日時
機器を識別する情報

…などを定期的に外部へ送信する。

つまり、「ログが来ていないから異常がない」のではなく、「機器が正常に存在し続けていること自体を確認できるようにする」という考え方です。

ここまで来ると、一般的なログ監視とは少し違った世界が見えてきます。

さらに踏み込むNCSC――「メモリを調べられるか」

NCSCの提言でもう一つ重要なのが、

Forensic data acquisition / フォレンジック・データ・アクイジション　です。

ネットワーク機器が侵害された場合、ディスクや内部ストレージに保存されたログだけを調べても、すべてが分かるとは限りません。

攻撃者がメモリ上だけでコードを実行していた場合や、侵害後にログを削除していた場合、重要な痕跡が失われている可能性があります。

さらに機器を再起動してしまえば、メモリ上に存在していた情報そのものが消えてしまうこともあります。

そこでNCSCは、権限を持った調査担当者が安全な方法で、稼働中の機器から揮発性データを取得できることを求めています。

対象となる情報は非常に広範囲です。

プロセスとその親子関係
プロセスの引数
メモリマップ
動的に読み込まれたモジュール
ファイルやソケットなどのハンドル情報
環境変数
プロセスメモリ
カーネルメモリ
ファイアウォールルール
現在のネットワーク接続
ARPテーブル
DHCPリース
ログイン中の管理セッション
一時ファイルシステム
そしてcrash dumpやcore dump

NCSCが求めているのは、ネットワーク機器そのものを、一つのデジタルフォレンジック対象として調査できる能力なのです。

この基準を頭に置いて、現在の製品を見てみましょう。

Cisco――すでにかなり深いところまで到達している

今回調査した中で、特に興味深かったメーカーの一つが Cisco です。

Cisco IOS XEには、従来からsyslog、設定変更履歴、Telemetryなど、多数の監視・診断機能があります。

しかし今回、それ以上に注目したのがCisco自身が公開している…

「Cisco IOS XE Software Forensic Data Collection Procedures」

…です。

Cisco IOS XE Software Forensic Data Collection Procedures

これは名前のとおり、IOS XE機器をフォレンジック調査するための正式な手順書です。

内容を見ると…

機器の設定と実行状態
システムイメージのハッシュ
デジタル署名されたイメージの検証
IOSdプロセスのランタイム整合性
そしてcore fileによるプラットフォームメモリ取得

…まで扱っています。

特に注目したいのがcore dumpです。

Ciscoは一定の条件下で、プラットフォームメモリの完全なコピーを取得する手順を正式に公開しています。

しかも、取得したcore fileやcrash information fileについてSHA-512による検証まで手順に含めています。

一方でCiscoは、core dumpの取得によってメモリ使用量が増加したり、通信へ一時的な影響が発生したり、操作によっては再起動につながる可能性についても警告しています。

つまり、「証拠を取れるか」だけではなく、「重要なネットワーク機器を動かしたまま、どこまで安全に証拠を取れるか」という問題があるのです。

Ciscoは少なくとも、この問題に対して具体的なフォレンジック取得手順を公開しているメーカーの一つと言えるでしょう。

Palo Alto Networks――設定変更を追跡する能力

Palo Alto Networks のPAN-OSも、インシデント調査に利用できるさまざまな情報を保持しています。

特に重要なのがConfiguration Logです。

管理者による設定変更を記録することで…

いつ、

誰が、

どこから、

どのような操作を行ったのか、

…といった情報を追跡できます。

これは攻撃者が管理者アカウントを奪取し、ファイアウォール設定を書き換えた場合などの調査で重要になります。

またPAN-OSには各種ログ転送、packet capture、Tech Support File、Stats Dump、core fileなど、障害解析や調査に利用できる機能も存在します。

ただし、ここで重要なのは、調査に使えるデータが存在することと、NCSCが求める統合されたフォレンジック取得機能を備えていることは同じではないという点です。

この違いは、今回の記事全体を通じて重要になります。

Fortinet――豊富な診断機能をフォレンジックから見直す

Fortinet のFortiGateにも、相当数の調査機能があります。

FortiGateは各種ログをFortiAnalyzerや外部syslogサーバーなどへ送信でき、機器内部にも条件に応じてログを保存できます。

さらに興味深いのが、execute tac report　です。

これは多数の診断コマンドを実行し、FortiGateの現在の状態について広範な情報を取得する仕組みです。Fortinet自身も、TAC reportを「現在のFortiGateの状態」に関する情報を取得するものとして説明しています。

Packet Captureについても、FortiOS 7.6では取得の開始・停止自体をSystem Event Logへ記録し、監査証跡を残す機能が確認できます。

これはフォレンジックという視点から見ると興味深い設計です。

一方、公開資料から確認できる範囲では、NCSCが要求している…

プロセス親子関係
メモリマップ
動的ライブラリ
環境変数
オープン中のファイルやソケット
プロセス・カーネルメモリ

…などを一つの標準的なフォレンジック取得インターフェースから収集する仕組みまでは確認できませんでした。

ここは慎重に扱う必要があります。

「Fortinetには存在しない」という意味ではありません。

非公開機能やサポート向け機能として存在する可能性もあるためです。

したがって現時点では、公開資料からは確認できなかったという評価に留めておきたいと思います。

Juniper Networks――障害解析機能がフォレンジックへつながる

Juniper Networks のJunos OSも興味深い存在です。

Junosではsyslogや設定変更履歴などを取得できます。

SRX Seriesではchange-logによって設定変更を記録する仕組みが標準化されています。

さらに注目したいのがcore fileです。

Junos OSでは内部プロセスがcore fileを生成した場合、coreだけでなく、関連するコンテキスト情報も保存します。

その中には設定情報とsystem logも含まれます。

さらにJunos OS Evolvedでは、特定の関連プロセスについて、一方が停止してcoreを生成した際に、もう一方についてlive coreを生成する仕組みもあります。

これは本来、障害解析を目的とした機能でしょう。

しかしフォレンジックという視点から見ると、「異常が発生した瞬間の状態を、後から調査できる形で残す」という考え方に非常に近いものがあります。

従来トラブルシューティングのために開発されてきた機能が、サイバーインシデント調査という新しい視点から再評価される可能性があります。

では、日本メーカーの製品はどうなのか

ここまで海外メーカーを中心に見てきました。

しかし、日本の企業や自治体、組織では、日本メーカーのルータやネットワーク機器も広く利用されています。

そこで当然、もう一つの疑問が生まれます。

日本メーカーの製品は、NCSCが示したフォレンジック可観測性という基準から見ると、どこまで到達しているのでしょうか。

今回は、公開資料から具体的な機能を確認できた NEC のUNIVERGE IXシリーズを見てみます。

UNIVERGE IXでは、機能ごとにイベントログを取得でき…

リアルタイム表示
装置内部への保存
SYSLOGサーバーへの転送
Webブラウザからの取得

という複数の方法が用意されています。

また、logging packet によって、指定したインターフェースで送受信されるパケットをダンプ出力する機能もあります。

再起動についても記録できます。

NECの公式資料では、再起動が発生したことだけでなく、コマンドによる再起動など、その理由を確認する方法が説明されています。

ここまでを見ると、日本メーカーの製品にも…

ログ
外部SYSLOG
packet dump
再起動履歴

…など、インシデント調査に利用できる「部品」はすでに存在しています。

しかし、非常に興味深い点があります。

NECの資料によれば…

logging buffered で取得するイベントログは、揮発性メモリへ保存されます。

これは通常の障害解析では問題にならない場合もあります。

しかしフォレンジックという観点では意味が変わってきます。

もし侵害が疑われるネットワーク機器を、「とりあえず再起動してみよう」と再起動してしまったらどうなるでしょうか。

揮発性メモリにしか存在しない情報は失われる可能性があります。

つまりここでも、「運用・障害解析のためのログ」と「侵害後の証拠保全」は必ずしも同じではないという問題が浮かび上がります。

これはNEC製品だけの問題を指摘しているのではありません。

むしろNCSCの提言が、これまでネットワーク機器に求められてきたログ・診断機能とは異なる要求をメーカーへ突きつけている、と考えるべきでしょう。

今後、日本メーカーについても同じ基準で継続して調査する価値があると考えます。

「海外メーカー対日本メーカー」ではない

ここで誤解しないようにしておきたいことがあります。

今回の記事は、海外メーカーは進んでいて、日本メーカーは遅れているという比較を目的としているわけではありません。

実際、海外メーカーについてもNCSCの要求項目をすべて一体化した仕組みが標準搭載されているとは限りません。

逆に、日本メーカーにもログ、packet dump、外部転送、診断情報など、その構成要素はすでに存在しています。

重要なのは国籍ではありません。

NCSCが提示した新しい物差しを使って、世界のネットワーク機器産業全体が、侵害後の調査能力をどこまで備えているのかを見ることです。

この視点で考えると、現在のネットワーク機器の姿が少し違って見えてきます。

「機能がない」のではなく「バラバラに存在している」

今回の調査で最も強く感じたことがあります。

それは、現在のネットワーク機器には、フォレンジック可観測性に必要な技術が存在しないわけではないということです。

むしろ逆です。

syslog
Telemetry
設定履歴
Packet Capture
プロセス情報
crash dump
core dump
診断レポート
設定バックアップ

…こうした技術の多くはすでに存在しています。

問題は、それぞれが…

監視機能
障害解析機能
メーカーサポート機能
ネットワーク診断機能

…として別々に発展してきたことです。

NCSCの提言は、それらを別の視点から一本につなごうとしているように見えます。

つまり、「これらすべてを、侵害後に事実を再構成するための証拠取得基盤として設計し直せないか」という問いです。

次に必要なのは「ボタン一つで証拠を保全できるネットワーク機器」かもしれない

ここからはネット探検ラボとしての考察になります。

将来のネットワーク機器には、現在の「Tech Support」のような機能とは別に、

Forensic Collection と呼べるような機能が標準搭載されるかもしれません。

重大な侵害が疑われたとき、権限を持った担当者が実行する。

すると、その時点の…

プロセス
ネットワーク接続
メモリ状態
設定
ログ
ルーティング情報
ファイアウォールルール
ARPやDHCP情報
ソフトウェアバージョン
設定ハッシュ
その他の揮発性情報

…などを可能な限り取得する。

そして、それらを時刻情報や完全性検証情報とともに、一つのフォレンジックパッケージとして出力する。

さらに、その証拠取得操作そのものも記録する。

もしここまで標準化されれば、ネットワーク機器のインシデントレスポンスは大きく変わるでしょう。

現在のように…

「このメーカーではどのコマンドを打てばよいのか」
「どの情報を先に取得すべきなのか」
「再起動してしまってよいのか」
「そのデータはどこに保存されているのか」
「メーカーのサポートがなければ解析できないのか」

…といった問題に、調査担当者が時間を費やす必要が減るからです。

これは決して空想だけの話ではありません。

Ciscoの公式フォレンジック手順を見るだけでも、システムイメージの検証、実行状態の取得、メモリ取得、取得ファイルのハッシュ検証といった構成要素はすでに現実のものとなっています。

そのために必要な部品の多くは、すでに存在しているのです。

NCSCが求めているのは「新技術」ではなく「再設計」なのかもしれない

第1回では、フォレンジック可観測性を「未来の設計思想」として考えました。

今回、実際のメーカー製品を調べてみて、その意味がさらに明確になってきました。

NCSCが求めているものは、すべてが未知の新技術というわけではありません。

ログもある
Telemetryもある
Packet Captureもある
core dumpもある
設定履歴もある

足りないのは、それらを、「侵害された機器から真実へたどり着くための仕組み」として統合する考え方なのではないでしょうか。

つまり今は、完成した技術が普及するのを待つ段階というより、ネットワーク機器メーカー、利用企業、SOC、インシデントレスポンス担当者が、「ネットワーク機器が侵害されたとき、何を証拠として取り出せるべきなのか」という共通基準を作り始めている段階なのだと思います。

ネットワーク機器は、「侵入を防ぐ装置」から、「侵入を検知する装置」へ。

そしてこれからは、「侵入された後でも、何が起きたのかを語ることのできる装置」へ。

フォレンジック可観測性という考え方は、その変化の入口にあるのかもしれません。

ネット探検ラボより

今回の調査では、海外・日本を問わず、現在のネットワーク機器がすでに多くの調査・診断機能を持っていることが分かりました。

同時に、それらを「フォレンジック」という目的から眺め直すと、まだ大きな余地が残されていることも見えてきました。

特に興味深いのは、Ciscoがすでに正式なフォレンジックデータ収集手順を公開していることです。

一方、日本メーカーの製品にも、ログ、SYSLOG転送、packet dump、再起動情報など、フォレンジック可観測性につながる技術はすでに存在しています。

つまりこれは、特定メーカーだけの話ではありません。

世界のネットワーク機器が「侵害されないための装置」から、「侵害されたとしても証拠を残せる装置」へ変わっていくのか。

ネット探検ラボでは今後も、NCSCの提言とメーカー各社の動きを追いながら、「未来のサイバー防御」を考えていきたいと思います。