境界防御は死んだ。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 通信のパケットサイズが、普段のファイル転送と微妙に違うのか?」
こうした泥臭い疑問を持てる人間が、真のセキュリティエンジニアだ。まずは今すぐ、お前の環境のフローデータを見てみろ。そこには、お前たちがまだ気づいていない「何か」が確実に流れているはずだ。
現場からは以上だ。何か詰まったら、いつでも聞かせてくれ。
コメント