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

EDRとNDRの融合：パケットとエンドポイントの相関分析が切り拓く、次世代ゼロトラストの真実

ネットワークスペシャリストやインフラアーキテクトであれば、誰もが一度は「境界防御の崩壊」という現実に向き合ってきたはずだ。テレワークの普及、クラウドシフト、そして巧妙化するランサムウェアの侵入。もはや「社内ネットワークだから安全」という神話は完全に瓦解し、攻撃者は正当な認証情報を奪い、エンドポイントの隙を突き、巧妙に身を潜めている。

ここで問いたい。あなたの組織に導入されているEDR（Endpoint Detection and Response）とNDR（Network Detection and Response）は、別々にアラートを吐き出しているだけの「サイロ化されたお飾り」になっていないだろうか？

真のセキュリティインシデントを検知するには、エンドポイントのプロセスツリーと、ワイヤー上の生々しいパケットフローをリアルタイムで結びつける必要がある。今回は、Linuxカーネルの内部挙動、TLSハンドシェイクの暗号学的特性、そしてTCP/IPスタックのチューニングにまで踏み込み、EDRとNDRを完璧に連携させるアーキテクチャの核心を解き明かしていく。

—

1. なぜEDR単体では見えない脅威が存在するのか？

EDRは強力だ。プロセスの生成、メモリインジェクション、不審なAPIフックなど、OS内部の挙動をミリ秒単位で捉える。しかし、EDRにも致命的な盲点がある。

1. EDRエージェントの改ざん・無効化: 高度な持続的狙い（APT）グループやランサムウェアの多くは、まず最初にエンドポイント上のセキュリティ製品のサービス停止やドライバのアンインストールを図る。
2. 生きたオフザランド（LotL）と暗号化通信: 正規の管理ツール（PowerShellやWMI、SSH等）を悪用された場合、エンドポイントのログだけでは「正当な業務トラフィック」と「攻撃者のC2（Command and Control）通信」の境界線が曖昧になる。

ここでNDRの出番だ。NDRはエンドポイントのOSに依存しない。ルーター、スイッチ、あるいは仮想タップ（vtap）を通過するパケットやNetFlow/IPFIXをキャプチャし、ネットワークの「挙動（Anomalous Behavior）」を監視する。しかし、NDR単体では「どのユーザーの、どのプロセスの、どのスレッドがその通信を発したか」というコンテキスト（文脈）が欠落しがちである。

だからこそ、EDRの「誰が（Process/User）」と、NDRの「どこへ・何を（Flow/Payload）」を完全に相関させるアーキテクチャが必要なのだ。

—

2. パケットレベルの相関分析メカニズム

EDRとNDRの連携において、最も重要となるのが「コンテキストのエンリッチメント（付加）」である。ネットワーク上のパケットフロー（例えば、TLSハンドシェイクの Client Hello パケット）を見ただけでは、それが通常のブラウジングなのか、カスタムC2ツールによるものなのか判別がつかない。

ここで、NDRセンサーが捉えたセッションの4要素（送信元IP、送信元ポート、宛先IP、宛先ポート）とタイムスタンプを、EDRのエージェントがOS側で記録しているソケットのオープン履歴（netstat や eBPF によるネットワークトレース）と突き合わせる。

LinuxカーネルにおけるeBPFを活用したソケット追跡のイメージ

現代の高性能なEDR/NDRエージェントは、Linuxカーネルの kprobe や tracepoint、さらには eBPF（Extended Berkeley Packet Filter）を駆使して、ユーザースペースをバイパスせずにネットワーク活動を監視している。以下は、カーネル空間でソケット生成とプロセスID（PID）を紐付ける概念的なC言語（eBPFプログラム）の断片である。

// SPDX-License-Identifier: GPL-2.0
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_traceable.h>

// プロセスとネットワークフローの紐付け構造体
struct flow_context_t {
    __u32 pid;
    __u32 saddr;
    __u32 daddr;
    __u16 sport;
    __u16 dport;
};

SEC("kprobe/tcp_connect")
int BPF_KPROBE(tcp_connect, struct sock *sk)
{
    struct flow_context_t ctx = {};
    
    // 現在のプロセスのPIDを取得
    ctx.pid = bpf_get_current_pid_tgid() >> 32;
    
    // ソケット構造体からIPアドレスとポート情報を安全に読み出す
    // （実際のコードでは BPF_CORE_READ を使用してカーネルバージョン差異を吸収する）
    ctx.saddr = BPF_CORE_READ(sk, __sk_common.sk_rcv_saddr);
    ctx.daddr = BPF_CORE_READ(sk, __sk_common.sk_daddr);
    ctx.sport = BPF_CORE_READ(sk, __sk_common.sk_num);
    ctx.dport = __builtin_bswap16(BPF_CORE_READ(sk, __sk_common.sk_dport));

    // ユーザー空間のリングバッファへイベントを送信し、NDR側のフロー情報とマージする
    bpf_printk("TCP Connect detected: PID=%d, DPort=%d\n", ctx.pid, ctx.dport);
    
    return 0;
}

char LICENSE[] [] SEC("license") = "GPL";

この低レイヤーのフックにより、EDRは「どのプロセスがどの外部IPへコネクションを張ったか」を正確に把握し、NDR側へメタデータをリアルタイムでストリーミングする。

—

3. トランスポート層とTLSハンドシェイクの最適化・脅威解析

暗号化通信（TLS 1.3）の普及により、従来の「パケットの中身をすべて覗き見る（Deep Packet Inspection: DPI）」アプローチは限界を迎えている。TLS 1.3では Encrypted Extensions 以降のハンドシェイクが完全に暗号化され、攻撃者のペイロードを静的にスニッフィングすることは不可能になった。

ここでNDRとEDR連携の真価が発揮される。NDRは暗号化の中身を見るのではなく、「暗号化される前のメタデータ（JA3/JA4フィンガープリンティング）」と「暗号化通信の挙動・タイミング」を分析する。

JA4+フィンガープリンティングによるクライアント識別

TLSの初期ハンドシェイク（Client Hello）において、クライアントが提示する暗号スイートの順序、拡張機能、サポートする楕円曲線などは、使用するライブラリ（OpenSSL, Go crypto, あるいは特定のマルウェアカスタムTLSスタック）によって固有のパターンを持つ。

EDRがエンドポイント上で「未知のバイナリの実行」を検知した瞬間、NDR側でそのプロセスが外部へ発出したTLSトラフィックの JA4ハッシュ を照合する。もし既知のC2フレームワーク（例: Cobalt StrikeのデフォルトTLSプロファイル）と一致していれば、瞬時に高信頼度のインシデント判定を下すことができる。

—

4. 高パフォーマンスインフラにおけるRTT削減とTCPバッファチューニング

セキュリティセンサー（EDR/NDR）をインライン、あるいは高スループットなパケットミラーリング環境に配置する場合、忘れてはならないのが「セキュリティソリューション自体がボトルネックになってはならない」という鉄則だ。

特に10GbE〜100GbEを超える現代のエンタープライズネットワークにおいて、パケット解析エンジンやログ転送パイプラインが悲鳴を上げると、パケットロスが発生し、肝心な攻撃の瞬間のフローデータが欠落する。

ここでは、NDRセンサーやSIEMフォワーダーが稼働するLinuxノードにおいて、極限のパフォーマンスを引き出すためのカーネルパラメータチューニングの実際の設定例を示す。

/etc/sysctl.conf によるネットワーク・TCPスタックの極限チューニング

# ==========================================
# 高スループット・低遅延セキュリティセンサー向けチューニング
# ==========================================

# TCPソケットの最大受信/送信バッファサイズを拡大（巨大なパケットバーストに対応）
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.rmem_default = 33554432
net.core.wmem_default = 33554432

# TCP自動チューニングバッファの最小値、デフォルト値、最大値（バイト単位）
# RTT（Round Trip Time）が大きいWAN環境やクラウド間のフロー解析でスループットを維持
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432

# ネットワークデバイスの受信キューの最大長を拡張し、パケットドロップを防止
net.core.netdev_max_backlog = 250000

# TCPタイムスタンプを有効化し、RTTの正確な計測とPAWS（Protect Against Wrapped Sequences）を有効化
net.ipv4.tcp_timestamps = 1

# 輻輳制御アルゴリズムに BBR (Bottleneck Bandwidth and RRT) を採用
# 従来のLoss-based（CUBIC等）から脱却し、パケットロスに惑わされない高速なデータ転送を実現
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

このチューニングを適用することで、EDRから送出される膨大なイベントログや、NDRが処理するNetFlow/IPFIXのストリームがパケットロスなく中央の相関分析エンジン（SIEM/XDRプラットフォーム）へと到達する。セキュリティの強固さは、強靭な基盤インフラストラクチャの上にのみ成り立つ。

—

5. 重大なネットワーク脆弱性の回避と実戦的アーキテクチャ設計

EDRとNDRの連携を組織に実装する際、インフラアーキテクトが陥りがちな罠がいくつか存在する。最後に、現場で直面する重大なリスクと、その回避策を提示する。

罠1: 暗号化トラフィックの復号（SSL/TLS Decryption）の盲信とプライバシー侵害

「すべての通信をファイアウォールやNDRで復号して中身を検査する」というアプローチは、ゼロトラストの思想（エンドツーエンドの信頼）に反するだけでなく、プライバシー保護規制（GDPRや個人情報保護法）に抵触するリスクがある。

  • 回避策: パスワードや機密データが含まれるHTTPS通信を無理に復号・保存するのではなく、前述した 「メタデータ解析（JA4+, SNI, ホスト名, 通信タイミング, フローのバイト数非対称性）」 をEDRのプロセス情報と掛け合わせることで、復号せずとも十分に悪意ある通信を特定する設計にする。

罠2: ログとフローのタイムシンクロナイゼーションの欠如

EDRが記録するタイムスタンプと、NDRがキャプチャするパケットのタイムスタンプが数秒ずれているだけで、相関分析エンジンはそれらを「別個の事象」とみなしてしまう。

  • 回避策: すべてのエンドポイント、NDRセンサー、分析基盤の間で、高精度なNTP（PTP: Precision Time Protocolの導入が望ましい）による時刻同期を徹底し、ミリ秒単位でのイベント順序の整合性を担保する。

—

まとめ

EDRによる「ミクロの視点（OS内部の挙動）」と、NDRによる「マクロの視点（ネットワーク上のフロー）」の融合は、もはや「あれば望ましい機能」ではなく、高度化するランサムウェアやサプライチェーン攻撃に対抗するための「必須の生存戦略」である。

プロトコルの挙動を愛し、カーネルの奥底でうごめくパケットの流れに目を凝らす我々エンジニアこそが、真にレジリエントなエンタープライズセキュリティの防壁を築き上げなければならない。設計図を描くだけでなく、実際にパケットを流し、バッファをチューニングし、プロセスとフローの点と点を繋ぎ合わせる――その泥臭い技術の積み重ねの先にしか、ゼロトラストの完成形は存在しないのだ。

スポンサーリンク

コメント

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