EDRアラートを受けたとき、端末、ユーザー、プロセス、通信、隔離要否、記録の残し方をどう確認するか。初心者でも初動で迷わない判断基準とチェックリストを整理する。
EDRアラートは「感染確定」ではなく初動判断の入口
EDRアラートが届くと、画面上の重大度や検知名だけで判断したくなる。しかし実務では、アラート名だけで「侵害された」「誤検知だ」と決めるのは危険だ。最初に見るべきなのは、端末、ユーザー、プロセス、通信、時刻、隔離状態、そして同じ時間帯に起きた周辺ログである。
EDRは端末上の兆候を知らせる仕組みであり、アラートは調査の出発点だ。重要なのは、攻撃手順を再現することではなく、業務影響を抑えながら証跡を残し、隔離やエスカレーションの判断を速くすることにある。
この記事では、セキュリティ初心者、情シス、開発者、SaaS管理者がEDRアラートを受けたときに、最初の30分で何を確認し、何を記録し、どこから専門チームへ渡すべきかを整理する。ログ全体の読み方は セキュリティログの読み方 で、比較の基礎は EDRとアンチウイルスの違い で確認できる。
この記事は、防御・確認・記録を目的にした初動ガイドです。特定製品の検知名、攻撃コマンド、悪用手順は扱いません。実務では、自社のインシデント対応規程、証跡保全方針、委託先SOCの運用手順を優先してください。
読者別に見る影響
EDRアラートは、担当者ごとに見るべき観点が違う。すべてを一人で判断しようとせず、役割ごとに「何を確定させるか」を分けると初動が安定する。
| 読者 | 最初に知りたいこと | 典型的な次の行動 |
|---|---|---|
| 情シス担当者 | どの端末、どのユーザー、業務影響はあるか | 利用者確認、端末隔離の要否判断、チケット起票 |
| SOC / CSIRT | 検知の根拠、同時刻の関連ログ、影響範囲 | タイムライン化、追加ログ確認、エスカレーション |
| 開発者 | 開発端末やCI/CD、シークレットに影響があるか | リポジトリ、トークン、ビルド環境の確認 |
| SaaS管理者 | 端末起点でSaaS操作や外部共有が発生していないか | IdP、SaaS監査ログ、OAuthアプリの確認 |
| 一般利用者 | 端末を使い続けてよいか、何を報告するか | 指示があるまで再起動・削除・自己判断を避ける |
アラートの重大度が低くても、管理者端末、開発端末、経理端末、顧客情報を扱う端末なら優先度は上がる。逆に、重大度が高く見えても、既知の管理ツールや検証環境の操作で説明できる場合は、証拠を残して誤検知として扱えることもある。
まず確認すること：8項目チェックリスト
最初の確認では、詳細な原因究明よりも「端末を隔離すべきか」「影響範囲を広げる兆候があるか」「誰へ渡すべきか」を決める。
| 確認項目 | 見る内容 | 見落とすと起きること |
|---|---|---|
| 端末 | ホスト名、資産番号、利用者、重要度、ネットワーク位置 | 重要端末を通常端末と同じ優先度で扱ってしまう |
| ユーザー | ログインユーザー、権限、最近の認証ログ | 端末アラートとアカウント侵害を切り離してしまう |
| 検知時刻 | JST/UTC、初回検知、直前直後の操作 | 他ログとの前後関係を誤る |
| プロセス | 親子関係、実行パス、署名、起動元 | 正規ツールの悪用や不審な親プロセスを見落とす |
| ファイル | ファイル名、ハッシュ、隔離状態、作成元 | 同一ファイルが他端末にあるか確認できない |
| 通信 | 宛先ドメイン/IP、通信可否、プロキシ/DNSログ | 外部通信の有無を判断できない |
| 端末操作 | EDR隔離、ユーザー操作、再起動、削除の有無 | 証跡が失われ、後続調査が難しくなる |
| 周辺ログ | IdP、SaaS監査ログ、VPN、メール、プロキシ | 端末だけの問題として過小評価する |
この段階では、検知名を検索して断定するより、端末とユーザーの文脈をそろえる。たとえば、開発者端末でEDRアラートが出たなら、GitHub、CI/CD、シークレット管理、SaaS管理権限も確認対象に入る。
スクリーンショットは状況共有には便利だが、調査記録としては不足しやすい。アラートID、端末ID、ユーザー、時刻、検知名、実施した操作、未確認事項をテキストで残す。
初動対応：やること、やらないこと、記録すること
EDRアラート対応で危険なのは、急いで端末を初期化したり、利用者に自己判断でファイル削除を依頼したりすることだ。被害拡大を抑える対応と、証跡を守る対応を分けて考える。
やること
- アラートID、端末、ユーザー、検知時刻、重大度、検知内容をチケットへ記録する。
- 利用者に「再起動、初期化、ファイル削除、USB接続、社外持ち出し」を避けるよう伝える。
- 業務影響が許容でき、規程上問題なければ、ネットワーク隔離やEDRの隔離機能を検討する。
- 同じユーザーのサインインログ、SaaS監査ログ、VPNログ、メールログを確認する。
- 同じファイルハッシュ、検知名、プロセス、宛先通信が他端末で出ていないか確認する。
- 判断に迷う場合は、CSIRT、SOC、委託先、法務・広報窓口へ早めにエスカレーションする。
やらないこと
- 検知名だけで「侵害確定」「誤検知確定」と断定しない。
- 利用者に不審ファイルやログを個人チャットへ転送させない。
- 証跡保全方針が決まる前に端末を初期化しない。
- 機密情報、Cookie、トークン、完全な個人情報を調査メモへ貼り付けない。
- 攻撃の再現やPoC確認を本番端末で行わない。
記録すること
| 記録項目 | 例 |
|---|---|
| 事実 | 10:14 JSTに端末AでEDRアラート、検知名、対象プロセス、隔離状態 |
| 根拠 | EDRアラートID、IdPサインインログ、プロキシログ、SaaS監査ログ |
| 実施済み対応 | 利用者連絡、ネットワーク隔離、同一ハッシュ検索、関係者共有 |
| 未確認事項 | 外部通信成功有無、別端末での同一兆候、SaaS上の権限変更 |
| 次の判断 | 隔離継続、端末回収、アカウント一時停止、専門調査依頼 |
記録の考え方は Incident Timeline と Evidence Preservation に近い。あとから別担当者が読んでも、何を根拠に判断したか追える状態にする。
エスカレーション判断：優先度が上がる条件
EDRアラートは、単体の重大度だけでなく、端末の役割、権限、同時発生ログ、外部通信、事業影響を合わせて判断する。
| 優先度を上げる条件 | 理由 |
|---|---|
| 管理者権限を持つユーザーや端末で発生した | 認証情報、SaaS、クラウド、端末管理へ波及しやすい |
| 同じ兆候が複数端末で出ている | 単一端末ではなく横展開や共通ツールの問題かもしれない |
| 外部通信、認証成功、権限変更が同時間帯にある | 端末アラートだけでなくアカウント・SaaS側の影響が疑われる |
| セキュリティ設定、ログ設定、バックアップに関係する操作がある | 証跡や復旧手段が弱められている可能性がある |
| 顧客情報、決済、設計情報、ソースコードへアクセスできる端末である | 情報漏えい時の影響説明が必要になりやすい |
| EDRエージェント停止、ログ欠落、時刻不整合がある | 調査の前提が崩れており、過小評価しやすい |
この条件に当てはまる場合は、一次対応者だけで完結させない。NIST SP 800-61 Rev. 3 は、インシデント対応を準備、検知、対応、復旧の活動に組み込む考え方を示している。実務でも、EDRアラートを「端末担当だけの作業」に閉じず、リスク管理、証跡、報告判断へつなげる必要がある。
よくある誤解
「EDRが隔離したからもう安全」
隔離は重要だが、調査の終点ではない。隔離前に外部通信やSaaS操作があったか、同じユーザーで別端末のサインインがないか、同じファイルやプロセスが他端末で観測されていないかを確認する。
「アラート名が難しいので専門家に丸投げする」
解析そのものは専門家に渡してよい。ただし、端末名、ユーザー、時刻、隔離状態、業務影響、関連ログの有無は現場側でそろえられる。ここが欠けると、専門家も優先度を決めにくい。
「利用者に聞けば分かる」
利用者確認は大切だが、記憶や自己申告だけに頼らない。本人が正規操作だと思っていても、フィッシング、OAuth同意、偽アップデート、正規ツールの悪用などは気づきにくい。ログと利用者確認を合わせて見る。
「EDRとアンチウイルスは同じ」
重なる部分はあるが、EDRは端末上の振る舞い、プロセス、調査、封じ込めまで扱う文脈で使われることが多い。違いは EDRとアンチウイルスの違い で整理している。
関連用語・関連ページ
EDRアラートを扱うときは、次のページを合わせて読むと判断が速くなる。
| 目的 | 内部リンク |
|---|---|
| 用語を確認する | EDR、XDR、SIEM、SOC、IOC、IOA、Containment |
| ログの読み方を学ぶ | セキュリティログの読み方、SIEMとログ管理、アクセスログ解析ミニCTF |
| 実務テンプレートを使う | 漏えい疑い初動テンプレート、ランサムウェア初動テンプレート |
| 仕組みを比較する | EDRとアンチウイルスの違い、SIEMとSOARの違い |
| 体系的に学ぶ | NIST CSF、インシデント対応 |
まとめ：最初の30分は「隔離判断」と「証跡整理」に集中する
EDRアラートを受けたら、まず端末、ユーザー、時刻、プロセス、ファイル、通信、隔離状態、周辺ログをそろえる。アラート名だけで断定せず、通常時との差分と同時間帯のログを見て、隔離、利用者連絡、エスカレーション、証跡保全を判断する。
初心者が最初に目指すべきことは、解析の専門用語を全部覚えることではない。端末を止めるべきか、誰に渡すべきか、何を記録すべきかを迷わず説明できる状態にすることだ。次に手を動かすなら アクセスログ解析ミニCTF でログの読み取りを練習し、実務の報告・記録は 漏えい疑い初動テンプレート に落とし込むとよい。
公式情報・参考情報
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management — インシデント対応をリスク管理、検知、対応、復旧へ組み込む考え方を確認できる。
- NIST Cybersecurity Framework — 検知、対応、復旧を含むセキュリティ運用の枠組みを確認できる。
- CISA Cybersecurity Performance Goals — 重要な検知・対応・ログ運用の考え方を確認できる。
- MITRE ATT&CK Enterprise Matrix — EDRやSIEMで見える兆候を、防御側の共通語として整理するために使える。
