【実務・中級編】 エンドポイント検出と応答(EDR)とネットワーク検出と応答(NDR)の連携アーキテクチャ – サイバーセキュリティとプライバシー保護実践ガイド

境界防御は死んだ。EDRとNDRを「相関」させてインシデントを狩り尽くせ

「ネットワークは嘘をつかない」。これは私が駆け出しの頃、現場の師匠に叩き込まれた言葉だ。しかし、現代の高度な脅威、特にランサムウェアや標的型攻撃を前にしては、この言葉も半分しか正解ではない。エンドポイントで何が起きたかを知る EDR(Endpoint Detection and Response)と、ネットワークの深層でパケットが何を語っているかを知る NDR(Network Detection and Response)。この二つを分断させている限り、お前たちのインシデントレスポンスは「後追い」で終わる。

今日は、この二つの視点を融合させ、泥臭い実務の中でどうやって攻撃の兆候をあぶり出すか、その真髄を語ろう。

—

EDRとNDRの連携:なぜ「相関」が必要なのか

EDRは「プロセスの実行」や「ファイル操作」といった内部の真実を知っている。一方でNDRは、NetFlow や IPFIX といったフローデータから、C2サーバーへの不審な beacon 通信や、横展開(Lateral Movement)の予兆を捉える。

これらを連携させると、例えば「ある端末で powershell.exe が異常な実行をした」というEDRのアラートと、「その端末が外部の未知のIPへ断続的に小パケットを送信している」というNDRのフロー情報が紐付く。これが揃えば、それは単なる誤検知ではなく、確実に「感染」と断定できるわけだ。

通信の裏側を覗く:IPFIXの勘所

NDRが扱う IPFIX(RFC 7011)は、ただの「誰と誰が通信したか」の記録ではない。インフラエンジニアとして注目すべきは、octetDeltaCount(バイト数)や flowStartMilliseconds(開始時間)だけでなく、「通信の頻度とパターンの揺らぎ」だ。

例えば、攻撃者が行う C2 通信は、検知を避けるために意図的に間隔を空ける(Jitter)ことがある。NDR側でこの統計的な異常を捉え、それをEDRのプロセス情報とAPI経由でマッチングさせる。これが現代の防御の最前線だ。

実践:EDRからNDRへ、APIで「捜査」を自動化する

現場では、EDRのアラートを受け取った瞬間、その端末の過去1時間のネットワークログをNDRから引き出す自動化スクリプトが必要になる。以下は、PythonでNDRのAPIを叩き、対象のフローを抽出する際のイメージコードだ。

import requests

def fetch_network_logs(target_ip, start_time, end_time):
    # NDRの検索APIエンドポイント(実務ではここに認証トークンを付与する)
    api_url = "https://ndr-appliance.local/api/v1/flows"
    
    # 検索パラメーター:対象のIPと時間枠を絞り込む
    params = {
        "source_ip": target_ip,
        "start": start_time,
        "end": end_time,
        "limit": 100
    }
    
    try:
        response = requests.get(api_url, params=params, verify=True)
        response.raise_for_status()
        return response.json()
    except Exception as e:
        # ネットワーク機器のAPIはタイムアウトしやすいので例外処理は必須
        print(f"NDRログの取得に失敗: {e}")
        return None

# 使用例:EDRが検知したIPに対して即座に通信フローを分析する
log_data = fetch_network_logs("192.168.1.50", "2023-10-27T10:00:00Z", "2023-10-27T11:00:00Z")
print(log_data)

運用上のTips:なぜ相関分析は現場で「詰む」のか

多くのエンジニアがここで躓くのが、「ログの粒度」と「時刻の同期」だ。

1. 時刻同期(NTP)の徹底: EDRとNDRの時刻が数秒ズレているだけで、相関分析は瓦解する。PTP(Precision Time Protocol)を検討するか、少なくとも NTP の監視を徹底しろ。
2. プロトコルの正規化: HTTP ヘッダーの User-Agent や、TLS ハンドシェイク時の SNI(Server Name Indication)をNDRで記録させておけ。EDRが「何のプロセスが通信したか」を教えてくれても、NDRで「何のドメインに、どんなTLS暗号スイートで接続したか」が見えなければ、解析には時間がかかる。

最後に:ツールに頼り切るな

良いか、EDRとNDRは「優秀な助手」に過ぎない。最終的にインシデントの意図を読み解くのは、お前たち自身の「違和感」だ。

「なぜこのクライアントPCが、業務時間外に大量の DNS クエリを投げているのか?」
「なぜ SMB 通信のパケットサイズが、普段のファイル転送と微妙に違うのか?」

こうした泥臭い疑問を持てる人間が、真のセキュリティエンジニアだ。まずは今すぐ、お前の環境のフローデータを見てみろ。そこには、お前たちがまだ気づいていない「何か」が確実に流れているはずだ。

現場からは以上だ。何か詰まったら、いつでも聞かせてくれ。

コメント

タイトルとURLをコピーしました