EDR・XDR・NDR・EPP・NGAVの検知と対応
端末で不審なスクリプトが動き、外部への暗号化通信とファイルサーバへの接続が続いたとします。EPP・NGAV・EDR・NDR・XDRは、どの段階を防ぎ、何を観測し、どこから先は断定できないのでしょうか。この記事では一件の架空事案を最後まで追い、科目B（午後）の構成図・検知ログ・対応判断を読む力を養います。
読む順序は、五つの用語と配置→時系列→端末とネットワークの証拠→相関と判断→封じ込め・復旧→演習です。製品の名称と機能は一対一に固定されません。実際の能力は導入済みのライセンス、ポリシー、連携先、センサーの健全性で決まります。以下の組織、人物、IPアドレス、イベントID、ログはすべて教材用の架空例です。
1. 五つの用語を役割と観測場所で分ける
用語 | 役割・観測範囲・この事案での限界 |
|---|---|
EPP（Endpoint Protection Platform） | 端末に配る防御・管理の基盤。マルウェア対策、端末上の防御ポリシー、隔離などの機能構成は製品依存。実行前後の遮断を担うことが多いが、EPPがあるだけで全ての動作が阻止されたとはいえない。 |
NGAV（Next-Generation Antivirus） | 振る舞い、機械学習、クラウド判定などを使う次世代型のマルウェア対策という製品上の呼称。普遍的な規格名ではなく、EPPの一機能として実装されることが多い。未検知でも安全は証明されない。 |
EDR（Endpoint Detection and Response） | 端末のプロセス・親子関係・ファイル操作・接続などのテレメトリを収集し、調査や端末隔離などの対応に使う。防止機能を併せ持つ製品もある。収集対象外の操作やセンサー停止中の全履歴を保証しない。 |
NDR（Network Detection and Response） | ネットワーク上の通信をセンサーで観測し、通信先・頻度・量・プロトコル情報から異常を探す。管理外端末の通信も配置次第で観測できる。一方、端末内の親プロセスや暗号化された本文は通常それだけでは分からない。 |
XDR（Extended Detection and Response） | 端末、メール、認証、ネットワークなど、実際に連携した複数領域の検知を関連付け、調査や対応をまとめる仕組み。単一インシデントへの束ね方は製品と設定次第。未連携の情報を自動で得るわけではない。 |
EPPとNGAV、EDRは排他的な製品区分ではありません。一つのエージェントが三つの機能を持つこともあります。NDRをXDRに連携してもNDRの観測点は増えず、EDRをXDRに連携してもEDR未導入端末のプロセスは見えません。名称から結論を出さず、実際のデータ源・阻止点・操作権限を確認します。
機能の代表例。製品ごとの機能差を消した保証表ではない。
図の『得意な証拠』は典型例です。たとえばEDRにもマルウェア遮断があり、EPP製品にも詳しい調査画面があります。NDRにも遮断連携がある場合があります。導入設計の比較では、機能名よりも具体的なイベント項目とポリシーを比較します。
2. 架空の環境とセンサー配置
社員アリスのWindows端末WS-41は10.20.1.41。EPPの保護機能、NGAV判定、EDRセンサーを導入している。通信は社内ネットワークと境界FWを通る。
ファイルサーバFS-7は10.20.8.7。EDRを導入し、認証・共有ファイルのアクセスログも保管する。重要な業務データを扱うため、隔離すると業務停止の影響が大きい。
プリンタPR-60は10.20.8.60。管理上の制約によりEDRを入れていない。東西通信を観測するNDRセンサーの配置次第では、PR-60発の通信フローを捉えられる。
外部の203.0.113.90は不審な接続先の例。WS-41から外部への通信は境界を通る。社内VLAN間の通信は別の観測点が必要なため、NDRには境界と内部の二つの監視点を設定する。
メール基盤と認証基盤のイベントはXDRへ連携する。XDRは端末・NDRイベントと時刻や端末IDを突き合わせる。相関結果はSOC担当者が裏取りする。
- 1. 端末上の処理
- 2. 監視点を通る通信
- 3. 配信・サインイン記録
- 4. 端末イベントと処置
- 5. 通信イベント
- 6. メール・認証イベント
左の端末とメールから、中央のセンサーとログを経て、右のXDRとSOCへ渡す。
NDRセンサーに届くのは、ミラー、TAP、仮想ネットワークの転送などで渡した通信だけです。全ての東西通信が境界FWを通るわけではありません。SPANの取りこぼし、経路変更、非対称経路、クラウド直通、VPN終端の位置でも見える範囲が変わります。端末とセンサーの時刻同期も、事象を一つに結ぶための前提です。
3. 09:00から09:12までの事案を追う
09:00にアリスへメールMAIL-31が届き、09:04に添付ファイルを開きました。この教材では初期の防御判定をすり抜け、子プロセスが起動したと仮定します。09:05にEDRが警告し、09:06に外部との通信、09:08にファイルサーバへの接続、09:12にXDRのインシデントINC-42をSOCが確認します。
監視対象外の通信はNDRに出ず、未連携のイベントはXDRの相関対象にならない。
09:04の子プロセス起動はWS-41内部で起き、図では09:05に届くEDR警告の前提です。XDRのINC-42は09:12に作られた相関結果であり、攻撃の開始時刻ではありません。メール、EDR、NDR、サーバの時刻は発生時刻と取り込み時刻を分けて読みます。
時刻とデータ源 | 観測できた事実と、まだ言えないこと |
|---|---|
09:00 メール | MAIL-31がアリスのメールボックスへ配信された。開封・実行した証拠にはならない。配信先、Message-ID、添付ハッシュを後の端末記録と照合する。 |
09:04 EPP・NGAV | この例では当初ブロック記録がない。検査対象外、ポリシー、クラウド判定の遅延、回避などは未確認。無記録だけで安全とも無効化とも言えない。 |
09:05 EDR | WS-41でメール閲覧アプリからスクリプト実行プロセスが起動した。親子関係とコマンドラインは手掛かりだが、実際の悪意や実行結果は追加調査が必要。 |
09:06 NDR | 10.20.1.41から203.0.113.90:443へのTLS通信を観測。暗号化された本文、持ち出されたファイル名、送信者の意図はこのフローだけでは分からない。 |
09:08 NDR・FS-7 | WS-41からFS-7:445への通信と、FS-7側の認証イベントを別々に観測。通信成立とファイルの読出し・変更は同じ事実ではない。 |
09:12 XDR | MAIL-31、EDR警告E-74、NDR警告N-18をINC-42に関連付けた。関連付けの根拠を確認するまでは同一攻撃者・同一因果関係と断定しない。 |
4. EPP・NGAVとEDR：防いだ事実と端末上の証拠
EPP側で見るのは『検査が行われたか』『許可・検疫・ブロックのどれになったか』『処置は成功したか』です。ファイルハッシュの判定、振る舞い検知、クラウド照会、攻撃面の制限などは製品とポリシーによります。NGAVという名前でも、スクリプトや正規ツールを悪用する動作を全て止める保証はありません。
端末側のフィールド | 意味と読解上の注意 |
|---|---|
device_id / hostname | 資産を識別する値。名前の変更・再利用があるため、製品の端末ID、資産台帳、割当IPを時刻付きで結ぶ。 |
event_time / ingest_time | 端末で起きた時刻と管理基盤が受け取った時刻。センサーがオフラインなら順序がずれる。タイムゾーンもそろえる。 |
process_guid / pid | プロセスを追うためのID。PIDは再利用されるのでPIDだけで異なる時刻のイベントを結ばない。製品が持つ一意のプロセス識別子と起動時刻を優先する。 |
parent_guid / image / command_line | 親子関係、実行ファイル、引数を読む。コマンドラインに秘密情報が含まれ得るので閲覧権限と保存範囲を管理する。表示の切り詰めにも注意する。 |
hash / signer | 実行ファイルのハッシュと署名情報。署名済みの正規プログラムでも悪用され得る。ハッシュ一致だけでは実行成功や被害範囲は分からない。 |
action / result | 検知、ブロック要求、検疫要求、成功・失敗の違いを読む。『隔離を指示した』だけでは端末が通信不能になったとは限らない。 |
sensor_health / policy_version | センサーの接続状態、保護停止、イベント欠落、ポリシーの適用版を確認する。見えなかった理由を探すときの前提。 |
次のログは架空の簡略形式です。EDRがプロセス系列を観測し、EPPは初期ファイルをブロックしていません。`allow`はその時点で通した処置であり、安全性の認定ではありません。
09:04:11 EPP device=WS-41 file=invoice.zip action=allow
09:04:18 EDR id=E-74 device=WS-41 user=alice
image=powershell.exe parent=mailclient.exe
process_guid=P-441 parent_guid=P-402 action=alert
09:06:03 EDR device=WS-41 process_guid=P-441
remote=203.0.113.90:443 protocol=tcp`parent=mailclient.exe`だけでメール添付が原因とは決められません。メール配信・添付ハッシュ・一時ファイル作成・利用者操作・プロセスのコマンドラインを合わせます。WS-41上の通信イベントが同じ`process_guid=P-441`なら、このプロセスが接続を試みたという推論は強まります。ただし、TLS内の内容や外部側で受け取った事実までは分かりません。
EDRテレメトリは常に完全な監査記録とは限りません。対象OS、センサーの版、保持期間、収集の間引き、ログ量上限を調べます。『警告なし』よりも、センサーが正常に観測していたかを先に確認します。攻撃者による保護停止や除外設定の変更も、別の管理監査ログと突き合わせます。
5. NDR：通信から見える範囲と暗号化の壁
NDRは端末にエージェントを入れられない資産の通信にも有効ですが、観測点を通ったパケットだけが対象です。フロー記録なら送信元・宛先IP、ポート、プロトコル、通信時刻、方向、転送量などを使います。DNSやTLSの情報は、対象通信が監視点に届き、解析・記録機能が有効な場合に加わります。
ネットワーク側のフィールド | 読解と限界 |
|---|---|
src_ip:port / dst_ip:port | 五つ組の両端。NATやVPNを通る場合は変換前後の対応表を同時刻で確認する。IPだけで利用者やプロセスを確定しない。 |
start / duration / bytes_out / bytes_in | 通信の開始、継続、方向別バイト量。多量の送信は調査の優先材料だが、業務バックアップもあり得る。転送量はファイル内容や相手の受領確認ではない。 |
dns.query / answer | 平文DNSが観測できれば問い合わせ名と応答を追える。DoH・DoTなどでDNSが暗号化され、監視点から個別の問い合わせが読めない場合もある。 |
tls.sni / certificate | 取得可能なTLSメタデータ。SNIは常に見える保証がなく、ECHなどや観測点によって使えない。証明書情報も取得・記録した範囲に限る。 |
sensor_id / loss / direction | どの監視点で見たか、パケット欠落の有無、送受の方向。境界センサーだけでは同一セグメント内の東西通信を保証できない。 |
架空のNDRログでは、外部のTLSと内部SMBを別フローとして記録します。NDRの`alert=beacon-like`は周期性に基づく警告であり、C2と断定する判定ではありません。ソフトウェア更新や監視エージェントも周期的な接続を行います。
09:06:02 NDR id=N-18 sensor=EDGE-1
src=10.20.1.41:52514 dst=203.0.113.90:443/tcp
app=tls bytes_out=184320 bytes_in=4012
alert=beacon-like tls_decrypt=no
09:08:26 NDR sensor=EAST-2
src=10.20.1.41:53002 dst=10.20.8.7:445/tcp
app=smb bytes_out=9240 bytes_in=17844`bytes_out=184320`は観測点から見た外向き通信量であり、184320バイトの機密データ流出が確認できた意味ではありません。TLS復号をしていないこの例では本文を読めません。端末のファイルアクセス、プロセス、プロキシ、サーバ側の受領記録を使って目的と内容を絞ります。
FS-7への445番接続もファイルの読出し成功を示しません。接続失敗、認証失敗、共有一覧取得などがあり得ます。FS-7のログで成功した認証、共有へのアクセス、対象ファイル、操作種別を確認します。監査が有効でない対象は『読み出しなし』と断定せず、残る証拠の限界を明記します。
5-1. PR-60のような管理外端末
PR-60にEDRがなくても、NDRセンサーがPR-60の通信経路にあり、ミラーが正常なら宛先や通信量は観測できます。一方、PR-60内でどの実行ファイルが接続したかはNDRだけでは分かりません。DHCP、スイッチのMAC・ポート情報、資産台帳を時刻付きで照合し、機器を取り違えないようにします。
6. XDRで相関し、観測事実と推論を分ける
XDRの役割は、別領域の警告を一件の調査対象へまとめ、関連する証拠への導線を作ることです。この例ではMAIL-31の配信先、EDRのWS-41とアリス、NDRの10.20.1.41、FS-7への接続時刻を合わせます。ただし、IPはDHCPで変わり、アカウントは複数端末で使え、イベントは遅れて取り込まれます。相関の根拠と同一性の強さを見直します。
区分 | INC-42を読むときの判断 |
|---|---|
観測事実 | MAIL-31が配信された。WS-41のEDRにP-441が記録された。EDGE-1が外向きTLSを、EAST-2がFS-7向けSMBを観測した。FS-7の認証イベントは別途確認する。 |
妥当な推論 | 同じ端末と近い時刻なので一連の事象である可能性が高い。P-441と外向き接続が端末側でも結び付けば、端末起点の通信という判断が強まる。 |
未確認 | メール添付が初期侵入経路か、アリスの資格情報が盗まれたか、TLS本文に機密情報があったか、FS-7からファイルが持ち出されたかは、この相関だけでは決まらない。 |
追加取得 | メール添付ハッシュ、端末上のファイルとプロセス、FS-7の認証・監査、NAT・DHCP履歴、プロキシ、認証基盤、センサー稼働状況、外部通信の許可・遮断結果をそろえる。 |
XDRをSIEMと混同しないことも重要です。SIEMは幅広いログの収集・検索・相関を中心とすることが多く、XDRは複数の検知・対応製品を結び付けた調査と操作を中心とすることが多いものの、実製品の機能は重なります。どちらの名称かより、データの元、保持期間、検索可能な項目、対応操作と権限を確認します。
検知ルールを『外部TLSが一件あれば隔離』のように単純化すると誤検知が増えます。端末の異常な親子関係、未承認の接続先、短時間の反復、共有サーバへの異常アクセスを組み合わせ、端末や部署の通常運用と比べます。一方、閾値を厳しくし過ぎると低速な攻撃を見逃します。ルールの理由と例外を記録します。
6-1. 相関条件を設定値として読む
たとえば概念上のルールを『メール受信後15分以内に、同じ利用者の端末で不審な親子プロセスが起動し、その端末から未承認の外部宛先へ通信した』とします。15分は製品の既定値ではなく、この教材で設計した例です。ルールの入力項目と欠落時の扱いを確認しないと、検知性能を評価できません。
相関条件 | この事案での確認と落とし穴 |
|---|---|
メールと利用者 | MAIL-31の受信者アリスとEDRのuser=aliceを対応付ける。ただし代理操作、共有メールボックス、複数ログインがあれば利用者名だけでは端末を特定できない。 |
利用者と端末 | 認証記録とdevice_idから、09:04にアリスがWS-41を使っていたかを確認する。事後に端末名を変更していた場合は、名称より端末IDと時刻を優先する。 |
端末とIP | 09:06時点のDHCP割当でWS-41が10.20.1.41かを確認する。VPNやNATを経るなら変換前後も確認する。現在の割当だけで過去の通信と結ばない。 |
時間窓 | メールの配信時刻、端末の発生時刻、NDRの観測時刻をUTCなど同じ基準に直す。取り込み遅延でXDRの到着順が逆になっても、元の発生順序を維持する。 |
例外・欠落 | センサーが欠けた場合にルールを不成立にするか、部分一致で警告するかを決める。部分一致なら信頼度を下げて不足証拠を表示する。 |
このルールは一つの調査対象を選ぶための入口です。15分を超えて実行する遅延型攻撃や、外部通信を別端末へ中継する事案は拾えない可能性があります。定期的に過去事案と正常な管理作業で検証し、誤検知率、見逃し、調査時間、業務影響を見ながら閾値と例外を変更します。変更前後のルール版を記録すれば、同じログに対する判定差を説明できます。
6-2. 検知がなかった場合の調査
『XDRに何も出ていない』と報告されたら、まずメール・認証・EDR・NDRの元イベントをそれぞれ検索します。元イベントはあるがXDRにないなら、連携失敗、ライセンス、データ種別の無効化、フィルタ、相関閾値を調べます。元イベント自体がないなら、センサー停止、監視経路外、ログ保持期間、記録設定を調べます。
収集の健全性は検知ルールとは別に監視します。端末台帳に対するEDR導入率、最終チェックイン、ポリシー適用、NDRへのパケット到達と欠落、XDRの最終受信時刻を継続確認します。正常なテストイベントを流して端末→XDRまで到達した記録を残せば、『設定上は有効』より強い運用上の証拠になります。
保持期間が過ぎたログは後から復元できない場合があります。調査開始時に必要な元イベントを保全し、検索画面の要約だけでなくイベントIDと取得時刻を残します。
7. 運用上の例外・見落とし・誤検知
状況 | 調べ方と設計上の対処 |
|---|---|
管理者のPowerShell | 正規の運用でもスクリプト実行はある。実行元端末、承認済み変更、署名、利用者、対象時刻、接続先を比べる。『PowerShellだから悪意』とも『管理者だから安全』とも決めない。 |
バックアップのSMB通信 | FS-7の大量通信はバックアップかもしれない。ジョブ計画、実行アカウント、対象共有、実際のファイル操作と突き合わせる。アカウント流用の可能性も残す。 |
EPPの除外設定 | 業務ソフトの誤検知で除外する場合は対象パス・署名・期限・承認者を最小化する。広い除外はマルウェアの通路になる。変更ログを保存し、期限後に再評価する。 |
EDRセンサーの停止 | オフライン、古いエージェント、保護停止、更新失敗を別経路で通知する。EDRの無警告だけで侵害なしとは言わない。 |
NDRの観測欠落 | SPAN過負荷、非対称経路、暗号化、クラウド直通を確認する。内部セグメント、VPN、無線、仮想ネットワークのどこを観測するかを構成図に示す。 |
XDRの誤相関 | 同じ共有IPや短い時刻窓だけでは別端末の事象が混ざる。DHCP・NAT対応、device_id、process_guid、メールMessage-IDなどを使って関連性を検証する。 |
自動隔離を有効にする対象と条件も運用判断です。社員端末なら即時隔離が適切な場合でも、FS-7を同じ条件で自動隔離すると重要業務が止まります。緊急遮断を認める権限者、例外対象、代替のアクセス制限、事後承認と証拠保全を事前に定めます。例外を常設の監視除外にしないことが大切です。
8. 封じ込め、調査、復旧の順序
SOCは被害拡大を止めながら、後から検証できる証拠を残します。EDR端末隔離は有用ですが、実装によっては管理通信を残す場合があり、操作成功・端末からの応答・実際の通信遮断を分けて確認します。端末がオフラインなら隔離命令が保留され得ます。
- 1. 初期判断：対応 警告と資産重要度を照合／確認する証跡 イベント時刻・センサー状態
- 2. 封じ込め：対応 WS-41を隔離し接続を検証／確認する証跡 操作ID・端末応答・FW記録
- 3. 影響調査：対応 同種端末とFS-7を調査／確認する証跡 プロセス・認証・共有監査
- 4. 根絶：対応 侵入経路と権限を修正／確認する証跡 変更記録・再検査結果
- 5. 復旧：対応 信頼できる状態から再開／確認する証跡 機能試験・監視の正常化
各段階で残す証拠を定め、端末の遮断と業務サーバの停止を区別する。
最初に端末ID、時刻、イベント原本、アラート内容、センサー状態を保全する。必要ならメモリやディスクなど揮発・上書きされる証拠を優先し、取得者とハッシュを記録する。
WS-41をEDRで隔離する。操作要求IDだけで完了扱いにせず、端末側応答、FW・NDRの通信停止、管理通信以外の遮断状況を確認する。オフラインなら別経路のネットワーク遮断を検討する。
アリスの資格情報が盗まれた可能性を認証ログで評価する。必要な場合はセッション失効、アカウント制限、パスワードやトークンの更新を行う。端末隔離だけで既存セッションを無効にしたとは考えない。
MAIL-31の同報先、P-441やハッシュ、接続先、類似の親子関係を他端末で探す。FS-7では認証成功、共有・ファイル操作、権限変更を調べる。PR-60はNDRと機器管理ログで調べる。
悪性ファイルの削除だけで終えず、侵入経路、永続化、悪用された権限、脆弱な設定を修正する。信頼性が失われた端末は承認済みイメージから再構築し、必要なデータを検査して戻す。
業務責任者と合意した機能試験を行い、EPPポリシー・EDRセンサー・NDR観測・XDR連携の復旧を確認する。一定期間の同種警告、外向き通信、FS-7へのアクセスを監視し、再接続を承認する。
FS-7をすぐ再起動・再イメージすると証拠が失われる可能性があります。サーバの隔離は代替手段、業務影響、攻撃継続の切迫度を評価して決めます。逆に証拠保全を理由に侵害が拡大する状況なら、緊急封じ込めを優先し、その判断と失った証拠を記録します。
確認項目 | 復旧の判定基準の例 |
|---|---|
侵入経路 | MAIL-31の同報先を調べ、配信防止や利用者通知を終えた。元の実行経路を再現できないことと、監査上の未確認範囲を区別して記録した。 |
端末と認証 | WS-41を信頼できる状態に戻し、必要な資格情報とセッションを更新した。再参加前にセンサーの健全性とポリシー適用を確認した。 |
FS-7とデータ | 対象共有への不審な認証・操作を調べ、変更・削除があれば整合性を検証し、必要に応じて正しいバックアップから復元した。 |
検知網 | EDGE-1とEAST-2の観測点、イベント受信遅延、XDR連携を試験した。代表的な安全なテストイベントで警告の伝達と運用手順を確認した。 |
9. 科目B（午後）での解答の組み立て
設問で『EDRを導入しているのに侵害が起きた理由』を問われたら、製品名だけで説明しません。予防機能の未検知、ポリシー除外、センサーの未導入・停止、検知後の対応遅延を、与えられたログや構成から選びます。設問にない停止や回避を勝手に事実として書かないことが重要です。
最初に資産、ユーザー、IP、時刻、イベントIDを表に整理する。発生時刻とXDRへの取り込み時刻を混同しない。
どのセンサーがどの区間を見たかを構成図に書き込む。端末内の事実はEDR、通信の事実はNDR、メール・認証・ファイル操作は各基盤の記録で裏取りする。
『観測した』『推測した』『確認できない』を分ける。TLSフローから本文流出、SMBフローからファイル読出し成功を即断しない。
対策は予防・検知・封じ込め・復旧に分け、設定主体、確認ログ、成功判定まで書く。重要サーバの自動隔離は業務影響と承認者に触れる。
10. 短答演習：根拠と誤答の理由
演習1：NGAVに警告がない
条件：09:04のEPPログは`action=allow`で、NGAV警告は見つからない。質問：WS-41は安全だったと判断できるか。
解答：判断できない。許可はその時点の判定であり、EDRには子プロセス起動が残る。NGAVの検査対象、ポリシー、センサー状態と後続動作を確認する。誤答『許可＝安全』は予防の未検知や検査の欠落を無視している。
演習2：EDRの親子関係
条件：E-74は`parent=mailclient.exe`、`image=powershell.exe`を示す。質問：何を追加確認するか。
解答：MAIL-31の添付ハッシュと保存先、P-441のコマンドライン・署名・子プロセス・接続、利用者操作を照合する。誤答『メールが原因と確定』は親子関係だけで初期侵入経路を断定している。
演習3：NDRのTLS送信量
条件：N-18は`bytes_out=184320`、`tls_decrypt=no`を示す。質問：機密ファイルの流出を確定できるか。
解答：確定できない。通信量と宛先は分かるが本文の内容は分からない。端末のファイル操作、プロキシ、外部受領記録などで検証する。誤答『184320バイト流出』は転送量を機密データ量と取り違えている。
演習4：XDRのインシデント
条件：INC-42がMAIL-31、E-74、N-18を束ねた。質問：同一攻撃と断定する前に何を調べるか。
解答：相関キー、DHCP・NATの時刻付き対応、端末ID、発生時刻と取り込み時刻、元イベントを調べる。誤答『XDRがまとめたから確定』は誤相関の可能性を捨てている。
演習5：隔離要求の完了
条件：SOCがWS-41のEDR隔離ボタンを押し、操作IDが発行された。質問：封じ込め完了と記録してよいか。
解答：まだ早い。端末の応答と処置結果、管理通信以外の通信停止をFWやNDRでも確認する。オフラインなら命令は保留され得る。誤答『ボタンを押したから隔離済み』は要求と実効を混同している。
演習6：管理外のPR-60
条件：PR-60にはEDRがなく、EAST-2の観測点を通って外部へ通信した。質問：NDRだけで実行プロセスまで分かるか。
解答：分からない。NDRから通信先や量は調べられるが、端末内プロセスには別の機器ログや調査が必要。誤答『通信を見たから原因プロセスも分かる』は観測場所の違いを無視している。
11. 一次資料と確認先
製品機能は版や契約によって変わります。具体的なログ項目と遮断動作は導入製品の公式資料・設定画面で確認してください。次は本文で使った概念とネットワーク記録の一次資料です。
Microsoft Learn：Endpoint detection and response overview
Microsoft Learn：Defender for Endpoint の保護機能とEDR
この記事についてAIに深掘り質問する
ChatGPT、Claude、Perplexityにこの記事を参照させ、要点の確認や疑問点を自由に質問できます。
次におすすめの学習
編集・検証について
編集・検証：IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る