インシデントレスポンス実践ガイド【2026年版】

セキュリティ設計・運用
2026.03.18

※本記事にはアフィリエイトリンクが含まれます。詳しくはプライバシーポリシー・広告掲載についてをご覧ください。

【PR開示】本記事にはアフィリエイトリンクが含まれる場合があります。

「自社がサイバー攻撃を受けた」——そのとき、あなたの組織はどう動きますか？パニックで無計画に対応した結果、証拠を消滅させてしまったり、攻撃者を刺激して被害を拡大させてしまう事例は後を絶ちません。本記事では、米国国立標準技術研究所（NIST）が定めるSP 800-61（Computer Security Incident Handling Guide）とSANS Instituteのインシデントハンドリング手順をもとに、実践的なインシデントレスポンス（IR）の全フェーズを解説します。

インシデントレスポンスとは何か

インシデントレスポンス（IR: Incident Response）とは、サイバーセキュリティインシデント（不正アクセス・マルウェア感染・データ侵害・DDoS等）を組織的・計画的に検知・封じ込め・復旧するための一連のプロセスです。場当たり的な対応では証拠が消え、法的・規制上の問題も生じます。

NISTは、IRを「準備（Preparation）→検知と分析（Detection & Analysis）→封じ込め（Containment）→根絶（Eradication）→復旧（Recovery）→事後対応（Post-Incident Activity）」の6フェーズに整理しています。この構造はSANSの「PICERL」モデルとほぼ同一であり、業界標準として世界中で採用されています。

NISTインシデントレスポンス6フェーズ: 準備・検知・封じ込め・根絶・復旧・教訓の循環サイクル図
NIST SP 800-61に基づくインシデントレスポンス6フェーズ

フェーズ1: 準備（Preparation）

インシデントが発生する前に整備しておくべき体制・ツール・手順です。準備なきインシデント対応は混乱を招きます。

インシデントレスポンスチーム（CSIRT）の編成

  • CSIRT（Computer Security Incident Response Team）を事前に組織する
  • 役割分担を明確化: インシデントリーダー・技術担当（フォレンジック）・広報担当・法務連携担当
  • エスカレーション先（経営層・外部セキュリティベンダー・JPCERT/CC）の連絡先リストを整備
  • インシデント対応手順書（Playbook）を事前に作成・訓練する

準備すべきツールキット

# ログ収集・分析
- SIEM（Splunk / Elastic SIEM / Microsoft Sentinel）
- EDR（CrowdStrike Falcon / Microsoft Defender for Endpoint）
- syslog集約サーバ

# フォレンジックツール
- Volatility（メモリフォレンジック）
- Autopsy / FTK Lite（ディスクフォレンジック）
- Wireshark / tcpdump（ネットワーク解析）
- strings, file, sha256sum（基本解析）

# 封じ込めツール
- ネットワーク隔離用スイッチ設定手順
- Firewall/WAFの緊急遮断コマンド集

フェーズ2: 検知と分析（Detection & Analysis）

インシデントを早期に検知するための仕組みと、発見後の初動分析手順です。平均的なインシデント検出時間は依然として数十日〜数百日と長く、早期検知体制の整備が重要です。

異常検知の主要シグナル

  • EDRによる不審プロセス検知・権限昇格アラート
  • SIEMルールによる異常ログイン（時間外・海外IP・大量失敗）
  • ネットワークトラフィックの急増・不審な外部通信（C2通信の兆候）
  • ファイル整合性監視（FIM）による重要ファイルの改ざん検知
  • ユーザーからの「端末が重い」「見知らぬプロセスがある」という報告

初動分析コマンド例（Linux/Windows）

# ===== Linux 初動分析 =====

# 実行中プロセスと接続の確認
ps aux --sort=-%cpu | head -20
netstat -tulnp 2>/dev/null || ss -tulnp
lsof -i -n -P | grep ESTABLISHED

# ログイン履歴・不審なアカウント確認
last | head -30
cat /etc/passwd | awk -F: '$3==0 {print}'  # UID=0のアカウント一覧
grep -i "accepted|failed|invalid" /var/log/auth.log | tail -50

# ファイルシステム改ざん確認（最近24時間以内に変更されたファイル）
find /etc /bin /usr/bin /tmp /var/tmp -mtime -1 -type f 2>/dev/null

# スケジュールタスク確認
crontab -l; ls -la /etc/cron* /var/spool/cron/

# ===== Windows 初動分析（PowerShell）=====

# 実行中プロセスとネットワーク接続
Get-Process | Sort-Object CPU -Descending | Select-Object -First 20
Get-NetTCPConnection -State Established | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess

# イベントログ確認（失敗ログイン・権限昇格）
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625,4672,4720} -MaxEvents 50

# 自動起動エントリ確認
Get-ScheduledTask | Where-Object {$_.State -ne 'Disabled'}
reg query HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun

インシデントの分類とトリアージ

検知したインシデントは重大度（Severity）に応じてトリアージします。NISTは以下の分類を推奨しています：

重大度例対応時間目標
Criticalランサムウェア感染・重要データ侵害即時（15分以内）
High標的型攻撃・権限昇格成功1時間以内
Mediumフィッシング成功・マルウェア検知4時間以内
Lowポートスキャン・試行的な攻撃24時間以内

フェーズ3: 封じ込め（Containment）

インシデントの拡大を防ぐための隔離・遮断処置です。「証拠を保全しながら被害を止める」ことが最重要原則です。

短期的封じ込め（Short-Term Containment）

# ネットワーク隔離（Linux）
# 感染ホストのネットワークを即時遮断（ただし証拠収集後に実施）
ip link set eth0 down
# または特定IPのみブロック
iptables -A INPUT -s <攻撃者IP> -j DROP
iptables -A OUTPUT -d <C2サーバIP> -j DROP

# Firewall側での緊急遮断（例：iptables）
iptables -I FORWARD -i eth0 -o eth1 -j DROP  # 全転送をブロック

# Windows: ホストFW有効化
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
# 特定IPをブロック
New-NetFirewallRule -DisplayName "Block-Attacker" -Direction Inbound -RemoteAddress <IP> -Action Block

証拠保全（重要：封じ込め前に実施）

# メモリダンプ取得（Linuxの場合）
# LiME（Linux Memory Extractor）を使用
sudo insmod lime.ko "path=/external/mem_$(hostname)_$(date +%Y%m%d_%H%M%S).lime format=lime"

# ネットワークキャプチャ開始
tcpdump -i any -w /external/capture_$(date +%Y%m%d_%H%M%S).pcap &

# 重要ログのバックアップ
cp -a /var/log/ /external/logs_backup/
journalctl --since "24 hours ago" > /external/journal_$(date +%Y%m%d).log

# ファイルハッシュの記録（改ざん検証用）
find /etc /bin /usr/bin -type f -exec sha256sum {} ; > /external/hash_baseline.txt

フェーズ4: 根絶（Eradication）

攻撃者のツール・バックドア・侵害された認証情報を完全に除去するフェーズです。不完全な根絶は再感染の原因となります。

根絶チェックリスト

  • マルウェア・バックドア・Webシェルの特定と完全削除
  • 侵害されたアカウントのパスワードリセット・MFA再設定（全管理者アカウント含む）
  • 攻撃者が使用したSSHキー・APIキー・証明書の失効と再発行
  • 悪用された脆弱性へのパッチ適用
  • C2（Command & Control）サーバとの通信をDNS・Firewallレベルでブロック
  • 永続化メカニズム（crontab・スタートアップ・レジストリ）の確認と除去
# Webシェル検索（Webサーバの場合）
find /var/www -name "*.php" -newer /var/www/index.php -mtime -30 | xargs grep -l "eval|base64_decode|system|passthru" 2>/dev/null

# 不審なcrontabエントリの確認
for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== $user ==="; crontab -u $user -l 2>/dev/null
done

# 不審なSSH authorized_keysの確認
find /home /root -name "authorized_keys" -exec cat {} ; 2>/dev/null

フェーズ5: 復旧（Recovery）

業務システムを安全な状態で再稼働させるフェーズです。「クリーンな状態を確認してから本番復旧」が原則で、焦って元に戻すと再感染します。

復旧手順

  • 感染前の信頼できるバックアップからのリストア（バックアップも感染していないか確認）
  • クリーンな環境での動作確認（監視強化状態で段階的に本番適用）
  • 認証情報の全面更新（パスワード・APIキー・証明書）
  • EDR・ログ監視の強化設定で再感染を即時検知できる状態を確保
  • 外部連携先（取引先・パートナー）への影響確認と通知

フェーズ6: 事後対応と教訓（Post-Incident Activity）

インシデント終息後に行う振り返りと改善活動です。ポストモーテム（Post-Mortem）を実施し、同じ攻撃を受けないための改善を行います。

インシデントレポートの必須項目

  • タイムライン: 最初の侵害から検知・封じ込め・復旧までの全時系列
  • 根本原因分析（RCA）: 何が侵害の入口となったか（脆弱性・設定ミス・人的ミス）
  • 影響範囲: 影響を受けたシステム・データ・ユーザー数・業務停止時間
  • 対応の有効性評価: 検知時間・封じ込め時間・復旧時間のKPI計測
  • 改善アクション: 再発防止策とそのオーナー・期限を明記

報告義務（日本の法令）

個人情報を含むデータ侵害が発生した場合、個人情報保護法（改正2022年）により個人情報保護委員会への報告義務（速報: 3〜5日以内、確報: 30日以内）が課せられます。また、重要インフラ事業者にはサイバーセキュリティ基本法に基づく報告義務もあります。JPCERT/CCへの報告も推奨されています。

インシデントレスポンス自動化: SOARの活用

SOAR（Security Orchestration, Automation and Response）は、インシデント対応の一部を自動化するプラットフォームです。2026年はAI連携による自律対応が進んでいます。

  • Splunk SOAR（旧Phantom）: Playbook自動実行によるIP遮断・チケット作成の自動化
  • Microsoft Sentinel + Logic Apps: Azureエコシステムとの統合自動対応
  • Palo Alto XSOAR: 200以上の統合連携で横断的な自動対応が可能

おすすめセキュリティ対策ツール

インシデントレスポンスの土台となる、エンドポイント保護の導入から始めましょう。

🛡️ まず今日から始めるなら：エンドポイント保護ソフトの導入
EDR機能付きのエンドポイント保護があれば、インシデント発生時の初動分析と証拠収集が大幅に効率化されます。

  • — 誤検知が少なく軽量。中小企業に人気のコスパ重視セキュリティソフト
  • — 日本語サポートが充実。国産ソフトで中小企業導入実績多数
  • — 世界最大手のセキュリティベンダー。VPN機能も含む総合対策

✅ おすすめのセキュリティソフト

※ アフィリエイトリンクを含みます。料金・詳細は各公式サイトでご確認ください。

まとめ：インシデントレスポンスの要点

  • インシデントレスポンスはNIST SP 800-61の「準備→検知→封じ込め→根絶→復旧→教訓」の6フェーズで体系化
  • 準備フェーズが最重要：CSIRTの編成・Playbook作成・ツールの事前整備が対応速度を決定する
  • 封じ込め前に必ずメモリダンプ・ログ・ネットワークキャプチャで証拠保全を実施
  • 根絶は不完全では再感染する：バックドア・永続化メカニズム・侵害済み認証情報を徹底除去
  • 個人情報を含む侵害は改正個人情報保護法により3〜5日以内の報告義務あり
  • SOARによる自動化で検知から初動対応までの時間を短縮することが2026年のベストプラクティス

インシデントレスポンスの能力は「事前の準備」と「定期的な訓練（TTX: Tabletop Exercise）」によって決まります。実際のインシデントが起きる前に、自社のPlaybookを整備し、年1回以上の机上演習を実施することを強くお勧めします。

関連記事: ゼロトラストアーキテクチャとは？2026年版導入ガイド / サプライチェーン攻撃の実態と対策: SolarWinds事件から学ぶ

参考資料: NIST SP 800-61r2 Computer Security Incident Handling Guide / JPCERT/CC インシデントレスポンス支援 / IPA 情報セキュリティ10大脅威 2026

コメント

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