マルウェアインシデントレスポンス手順書

この記事で分かること

効果的なインシデントレスポンス（IR）手順書は、マルウェア感染時の混乱を防ぎ、迅速かつ適切な対応を可能にします。「準備なき組織は、パニックに陥る」という格言通り、事前に策定された手順書の有無が、被害の規模を大きく左右します。2024年の調査では、IR手順書を整備している組織は、平均対応時間を65%短縮し、被害額を70%削減したというデータがあります。本記事では、CSIRT体制の構築から、検知・分析・封じ込め・根絶・復旧の各フェーズでの具体的な手順、そして手順書の継続的な改善方法まで、実践的なプレイブック作成ガイドを提供します。この手順書をテンプレートとして、自組織に適したIR体制を構築してください。

---

IR手順書の構成要素｜必須項目と体制構築

インシデントレスポンス手順書（IRプレイブック）は、単なる技術文書ではなく、組織全体でサイバーインシデントに対処するための戦略的なツールです。効果的な手順書には、明確な体制、役割分担、そして具体的なアクションプランが不可欠です。

インシデント対応体制

まず、インシデント発生時に誰が何をするのかを明確に定義します。CSIRT（Computer Security Incident Response Team）の組織構成は、組織の規模によって異なりますが、最低限の役割を定義しておく必要があります。

CSIRT組織構成

効果的なインシデント対応には、少なくとも以下の4つの役割が必要です：①インシデントマネージャー（全体統括と意思決定を担当、対応の優先順位付けと経営層への報告を実施）、②技術リーダー（技術的な分析と対応を指揮、マルウェア解析やシステム復旧の技術判断を実施）、③コミュニケーション担当（内部・外部との連絡調整を担当、ステークホルダーへの情報共有とエスカレーションを管理）、④記録担当（すべてのアクションとログを記録、証拠保全と事後分析のためのドキュメント作成を実施）。小規模組織では、一人が複数の役割を兼務することもありますが、役割自体は明確に定義してください。大規模組織では、さらに法務担当、広報担当、フォレンジック専門家等を追加します。

エスカレーションフロー

インシデントの深刻度に応じた、明確なエスカレーション基準と報告フローを定義します。一般的な4段階構成は以下の通りです：Level 1（担当者レベル）：軽微なインシデント、既知の対処法で解決可能、15分以内に判断→Level 2（チームリーダー）：複数システムへの影響、対応に専門知識が必要、30分以内に判断→Level 3（部門長/CISO）：事業への影響、外部支援が必要、1時間以内に判断→Level 4（経営層/CEO）：重大な事業影響、法的対応が必要、即座に報告。重要なのは、15分以内に判断できない場合は自動的に上位レベルにエスカレーションするルールを設けることです。判断を保留したまま時間が経過することが、最も被害を拡大させます。

外部連携体制

自組織だけで対応できない高度なインシデントに備え、外部専門家との連携体制を事前に構築しておきます。連携先は以下の通りです：①セキュリティベンダー（EDR/XDRの運用サポート、脅威インテリジェンス提供）、②フォレンジック業者（マルウェア解析、証拠保全、法的調査）、③法執行機関（警察サイバー犯罪対策課、都道府県警察本部）、④JPCERT/CC（インシデント情報の共有、技術支援）、⑤業界ISAC（金融ISAC、J-CSIP等の業界別情報共有組織）、⑥法律事務所（サイバー法務専門の弁護士）。これらの組織とは、インシデント発生前に契約や情報共有協定を締結し、緊急連絡先と対応可能時間を確認しておいてください。特に夜間・休日対応が可能かどうかは重要なポイントです。

インシデント対応体制図（RACI）

フェーズ/活動	インシデントマネージャー	技術リーダー	コミュニケーション担当	記録担当	経営層	外部専門家
初動検知	A	R	I	R	I	-
影響評価	A	R	C	R	I	C
封じ込め判断	A	R	C	R	I	C
技術対応実施	A	R	I	R	I	R
経営層報告	R	C	R	C	A	-
外部通知	A	I	R	C	A	C
復旧作業	A	R	I	R	I	R
事後分析	A	R	C	R	C	C

凡例: R=実行責任者（Responsible）、A=説明責任者（Accountable）、C=相談先（Consulted）、I=報告先（Informed）

役割と責任（RACI）

RACI マトリクスを用いて、各フェーズでの役割を明確化します。

各フェーズでの責任分担

インシデント対応は、一般的に以下の6つのフェーズに分かれます：①準備（Preparation）、②検知（Detection）、③分析（Analysis）、④封じ込め（Containment）、⑤根絶（Eradication）、⑥復旧（Recovery）、⑦事後対応（Post-Incident Activity）。NISTのインシデント対応ライフサイクルでは、これを「準備→検知と分析→封じ込め・根絶・復旧→事後活動」の4段階に集約していますが、本手順書では、実務上の明確化のため7段階で定義します。

準備フェーズ

インシデント発生前の準備活動です。責任者は通常CISO または セキュリティマネージャーで、以下を実施します：①IR手順書の策定と維持管理、②CSIRTメンバーの選定と訓練、③必要なツール・システムの導入、④外部専門家との契約締結、⑤定期的な訓練と演習の実施。この段階での準備が不十分だと、実際のインシデント発生時に適切な対応ができません。

検知・分析フェーズ

インシデントを発見し、その性質と影響を評価する段階です。技術リーダーが主導し、以下を実施します：①セキュリティアラートのトリアージ、②初期情報の収集、③影響範囲の特定、④インシデント分類（マルウェア種類、深刻度）、⑤経営層への初期報告。この段階でのスピードと正確性が、その後の対応の質を左右します。

封じ込め・根絶・復旧フェーズ

被害の拡大を防ぎ、マルウェアを除去し、正常な状態に戻す段階です。インシデントマネージャーが全体を統括し、技術リーダーが実務を指揮します。この段階では、ビジネスへの影響と技術的な完全性のバランスを取る判断が求められるため、経営層の承認が必要な場合があります。

意思決定権限

インシデント対応では、迅速な意思決定が求められます。以下の権限委譲ルールを明確にしてください。

意思決定マトリクス

決定事項	担当者レベル	チームリーダー	部門長/CISO	経営層
単一端末の隔離	◎	○	○	-
セグメント全体の隔離	-	◎	○	△
主要サービスの停止	-	△	◎	○
全社システムの停止	-	-	△	◎
法執行機関への通報	-	-	◎	○
外部への情報公開	-	-	△	◎
データ復元の実施	-	◎	○	△
身代金交渉の判断	-	-	-	◎

凡例: ◎=主決定者、○=承認者、△=相談先、-=関与なし

外部委託範囲

すべてを内製で対応することは困難です。以下の領域については、外部委託を検討してください。

24時間監視（SOC）

社内で24時間365日の監視体制を維持するのは、人員とコストの面で困難な場合が多いです。MSSP（Managed Security Service Provider）にSOC業務を委託することで、夜間・休日も含めた継続的な監視が可能になります。委託範囲は、①セキュリティアラートの監視とトリアージ、②初期分析とエスカレーション判断、③定型的な初動対応（アカウント無効化等）、④月次レポートの作成、等が一般的です。

高度なフォレンジック分析

マルウェアの詳細解析、メモリフォレンジック、法的証拠の保全等、高度な専門知識が必要な作業は、専門のフォレンジック業者に委託します。特に、訴訟や法執行機関への協力が必要な場合、法的に有効な証拠収集には専門家の関与が不可欠です。

インシデント対応支援

重大なインシデント（ランサムウェア、APT攻撃等）発生時は、セキュリティベンダーのインシデント対応チーム（DFIR：Digital Forensics and Incident Response）に支援を依頼します。彼らは、最新の脅威情報と対応経験を持ち、迅速な対応をサポートしてくれます。

必要リソース

効果的なインシデント対応には、適切なリソースの確保が不可欠です。

人的リソース

専任メンバー

最低でも、セキュリティ専任担当者を2名配置することを推奨します。1名のみの場合、休暇や病欠時に対応できなくなるリスクがあります。大規模組織（従業員1000名以上）では、5-10名のセキュリティチームを構成し、24時間オンコール体制を敷くことが理想的です。

兼任メンバー

IT部門の既存メンバーが、通常業務と兼任でCSIRT活動に参加する体制も有効です。ただし、インシデント発生時には、通常業務から一時的に離れてCSIRT活動に専念できる承認を、事前に経営層から取得しておいてください。

スキル要件

CSIRTメンバーには、以下のスキルセットが求められます：①ネットワーク技術（TCP/IP、ファイアウォール、IDS/IPS）、②OS知識（Windows、Linux）とシステム管理、③マルウェア解析の基礎知識、④ログ分析とSIEM運用、⑤フォレンジックの基礎、⑥コミュニケーション能力（非技術者への説明）。すべてのスキルを一人で持つ必要はなく、チーム全体でカバーできれば十分です。

ツール・システム

インシデント対応に必要な技術ツールを整備します。

必須ツール一覧

ツールカテゴリ	具体例	用途	優先度
EDR/XDR	CrowdStrike、SentinelOne、Microsoft Defender	エンドポイント監視・対応	高
SIEM	Splunk、QRadar、Azure Sentinel	ログ集約・分析	高
ネットワーク監視	Wireshark、Zeek、Darktrace	通信分析	中
脅威インテリジェンス	MISP、AlienVault OTX、VirusTotal	IOC管理・共有	中
フォレンジックツール	FTK Imager、Autopsy、Volatility	証拠収集・解析	中
インシデント管理	TheHive、ServiceNow、JIRA	チケット管理・記録	高
コミュニケーション	Slack、Teams、専用ホットライン	チーム連携	高
サンドボックス	Cuckoo、Any.Run、Joe Sandbox	マルウェア解析	低

予算確保

IR体制の構築と維持には、適切な予算配分が必要です。

初期投資

ツール導入、外部専門家との契約、トレーニング費用等で、中小企業（従業員100名規模）で年間500-1000万円、大企業（従業員1000名以上）で年間3000-5000万円程度が目安です。ただし、サイバー保険の加入により、インシデント発生時のコストを補填できるため、保険料（年間数十万円から数百万円）も予算に含めてください。

運用コスト

ツールのライセンス費用、MSSP委託費、定期訓練費用、脅威インテリジェンスフィード購読料等、継続的なコストが発生します。これらは年間で初期投資の30-50%程度を見込んでください。

インシデント対応コスト

実際にインシデントが発生した場合の対応コストとして、年間で初期投資と同程度の予算を予備費として確保しておくことを推奨します。重大インシデント1件で数百万円から数千万円のコストが発生する可能性があるためです。

---

検知・分析フェーズ｜初動調査と影響評価

インシデント対応の最初のステップは、セキュリティインシデントを検知し、その性質と影響範囲を正確に評価することです。この段階でのスピードと正確性が、その後の対応の質を決定します。

アラートトリアージ

セキュリティツールは日々大量のアラートを生成します。すべてに対応することは不可能なため、優先順位を付けて対応する「トリアージ」が不可欠です。

優先度判定基準

アラートを以下の4段階で分類し、対応の優先順位を決定します。Critical（緊急）：ランサムウェア検知、大規模感染、C&Cサーバーへの通信確認、重要データへの不正アクセス → 即座に対応開始（目標：5分以内）。High（高）：単体端末での既知マルウェア検知、不審な外部通信、権限昇格の試み → 1時間以内に対応開始。Medium（中）：マルウェアの疑い、異常なログイン試行、ポリシー違反 → 当日中に対応開始（営業時間内8時間以内）。Low（低）：誤検知の可能性が高い、既知の無害な活動 → 翌営業日までに確認。この基準を文書化し、SOCやCSIRTメンバー全員が同じ判断基準で行動できるようにしてください。

初期情報収集

アラートを受けた時点で、以下の情報を5W1H（誰が、何を、いつ、どこで、なぜ、どのように）の形式で整理します：①発生時刻（Timestamp）、②影響システム（ホスト名、IPアドレス、OS）、③症状（検知されたマルウェア名、不審な挙動）、④検知方法（EDR、SIEM、ユーザー報告）、⑤影響ユーザー（氏名、部門、役職）、⑥現在の状況（隔離済み、感染拡大中等）。専用の「インシデント票」テンプレートを用意し、この情報を漏れなく記録してください。初期の記録が不完全だと、後の分析や事後報告で困難に直面します。

False Positive（誤検知）判定

セキュリティツールのアラートの約60-70%は誤検知と言われています。貴重なリソースを誤検知対応に浪費しないため、以下の方法で迅速に判定します：①過去の誤検知パターンとの照合：同じアラートが過去に誤検知と判定されていないか確認、②ホワイトリストとの比較：検知されたファイルハッシュやドメインが、既知の正規ソフトウェアでないか確認、③複数ソースでのクロスチェック：EDRだけでなく、SIEM、ネットワーク監視等、複数のツールで同様の挙動が検知されているか確認、④VirusTotalでの検証：不審なファイルのハッシュをVirusTotalで検索し、複数のアンチウイルスエンジンでの検出状況を確認。これらの確認は、15分以内に完了することを目標としてください。

インシデント分類と対応時間

深刻度	影響範囲	具体例	初動開始	初期報告	エスカレーション
Critical	組織全体	ランサムウェア全社展開、基幹システム侵害	5分以内	15分以内	即座にCEO
High	複数システム	部門サーバー感染、C&C通信検知	30分以内	1時間以内	1時間以内にCISO
Medium	単一システム	個別PC感染、疑わしい活動	4時間以内	当日中	当日中にチームリーダー
Low	影響なし/軽微	誤検知の可能性高、ポリシー違反	翌営業日	翌営業日	週次レポート

影響範囲の特定

初期トリアージで真のインシデントと判定したら、次に影響範囲を特定します。

感染端末の洗い出し

横展開の追跡

最初に検知された端末（Patient Zero）だけでなく、そこから横展開（Lateral Movement）した可能性のある他の端末を特定します。以下の観点で調査してください：①同一セグメント内の端末：ネットワーク共有やSMB通信で感染拡大、②認証情報を共有する端末：同じアカウントでログインした端末、③時系列での不審な通信：Patient Zeroと通信した端末のリスト、④同じIOC（Indicators of Compromise）が検出された端末：同じマルウェアハッシュ、C&Cサーバー通信等。EDRやSIEMのクエリ機能を使用して、これらの情報を迅速に収集してください。

タイムライン分析

感染の初期侵入時点（Initial Compromise）から現在までの時系列を再構築します。これにより、感染の進行度と、どの時点のバックアップが安全かを判断できます。具体的には、①最初の不審な活動の時刻、②マルウェアのダウンロード・実行時刻、③権限昇格の試行時刻、④横展開の開始時刻、⑤データ持ち出しやファイル暗号化の時刻、を特定します。

IOCベースの検索

特定されたマルウェアのIOC（ファイルハッシュ、レジストリキー、C&Cドメイン、IPアドレス等）を使用して、全社システムを検索します。自動化スクリプトを用意しておくことで、数千台規模でも数時間以内に検索を完了できます。

データ侵害の評価

マルウェア感染だけでなく、データの窃取や改変が発生していないかを評価します。

データ侵害チェックポイント

• 大量の外部転送（Data Exfiltration）の痕跡はないか
• 機密ファイルへの不正アクセスログはないか
• データベースからの異常なクエリ実行はないか
• クラウドストレージへの大量アップロードはないか
• 暗号化や削除されたファイルはないか

これらの確認には、DLP（Data Loss Prevention）ツール、ネットワークトラフィック分析、ファイルサーバーのアクセスログ等を使用します。

業務影響度分析

技術的な影響だけでなく、ビジネスへの影響を評価します。

事業継続性の評価

感染したシステムが停止した場合の業務への影響を評価します。事前に策定したBIA（Business Impact Analysis）を参照し、以下を確認してください：①重要業務プロセスへの影響、②顧客サービスへの影響、③法的・規制上の義務への影響、④財務的損失の推定。この評価結果が、封じ込め戦略（即座に隔離するか、代替手段を用意してから隔離するか）の判断材料となります。

顧客・取引先への影響

顧客データや取引先との連携システムが侵害された場合、迅速な通知が必要になる可能性があります。個人情報保護法では、個人データの漏洩等が発生した場合、個人情報保護委員会への報告と本人への通知が義務付けられているため、法務部門と連携して対応してください。

評判リスクの評価

インシデントが報道された場合の企業イメージへの影響を評価します。特に、上場企業や金融機関では、株価への影響や信用失墜のリスクを考慮する必要があります。広報部門と連携し、メディア対応の準備を並行して進めてください。

証拠収集

法的措置や事後分析のため、適切に証拠を収集・保全します。

揮発性データ取得

システムの電源を切ると失われる、メモリ上のデータを優先的に取得します。

メモリダンプの取得

感染端末のメモリ（RAM）の内容を、そのままファイルに保存します。ファイルレスマルウェアや、メモリ上でのみ動作する攻撃ツールの痕跡は、メモリダンプからしか発見できません。取得には、FTK Imager、DumpIt、WinPmem等のツールを使用します。大容量（16GBのRAMなら16GBのファイル）になるため、事前に十分な保存領域を確保してください。

実行中のプロセス情報

現在実行中のプロセスリスト、ネットワーク接続、開いているファイル等を記録します。Windowsの場合、PowerShellで`Get-Process`、`netstat -ano`、`Get-WmiObject`等のコマンドを使用して情報を取得し、テキストファイルに保存してください。

レジストリの取得

Windowsレジストリには、自動起動設定やマルウェアの痕跡が多く残されています。reg exportコマンドや、FTK Imagerを使用して、レジストリ全体をバックアップしてください。

ディスクイメージ作成

ハードディスク全体のビット単位のコピー（フォレンジックイメージ）を作成します。

証拠収集チェックリスト

証拠種別	取得方法	優先度	揮発性	保存先
メモリダンプ	FTK Imager、DumpIt	最高	高	外付けHDD
ディスクイメージ	dd、FTK Imager	高	低	外付けHDD
ネットワーク通信	パケットキャプチャ（PCAP）	高	高	ネットワークストレージ
システムログ	イベントログ、Syslog	中	中	ログサーバー
アプリケーションログ	Webサーバー、DBログ	中	低	ログサーバー
ユーザーファイル	コピー作成	中	低	隔離ストレージ
設定ファイル	バックアップ	低	低	バックアップサーバー
スクリーンショット	画面キャプチャ	低	中	ドキュメント管理

ログ収集と保全

各種システムログを収集し、改ざん防止のため適切に保全します。

収集対象ログ

以下のログを優先的に収集してください：①Windowsイベントログ（セキュリティ、システム、アプリケーション）、②EDR/アンチウイルスログ、③ファイアウォール・IDS/IPSログ、④プロキシ・DNSクエリログ、⑤認証ログ（Active Directory、VPN、クラウドサービス）、⑥Webサーバー・アプリケーションログ、⑦データベースアクセスログ。これらは最低でも過去3ヶ月分、可能であれば6ヶ月分を収集してください。

ハッシュ値の記録

収集した証拠ファイルのSHA-256ハッシュ値を記録します。これにより、後から証拠が改ざんされていないことを証明できます。専用のツール（md5deep、sha256sum等）を使用するか、PowerShellの`Get-FileHash`コマンドで計算できます。ハッシュ値は、証拠ファイルとは別の安全な場所に保管してください。

チェーン・オブ・カストディ

証拠の取扱履歴（誰が、いつ、何をしたか）を記録します。法的手続きで証拠として使用する場合、適切な管理記録がないと証拠能力が認められない可能性があります。専用の「証拠管理台帳」を作成し、証拠の移動、コピー、分析等のすべての操作を記録してください。

---

封じ込め・根絶フェーズ｜被害拡大防止と駆除

影響範囲が特定できたら、次に被害の拡大を防ぎ、マルウェアを除去します。このフェーズは、「短期封じ込め」と「長期封じ込め」、そして「根絶」の3つのステップに分かれます。

短期封じ込め

まず、被害の拡大を緊急に食い止めます。

即時遮断措置

感染端末を即座にネットワークから隔離します。以下の手順を5分以内に実施してください：①物理的なLANケーブルの切断またはWi-Fi無効化、②ファイアウォールでの該当IPアドレスのブロック、③感染ユーザーのアカウント無効化（Active DirectoryまたはIDaaSで実施）、④VPN接続の強制切断、⑤EDRの隔離機能による自動遮断。これらの操作を自動化するスクリプトを事前に準備しておくことで、ワンクリックで実行可能になります。例えば、PowerShellスクリプトで、特定のホスト名を引数として渡すと、ADでのアカウント無効化、ファイアウォールルール追加、EDRでの隔離を一括実行できるようにしておきます。

感染拡大の阻止

Patient Zeroからの横展開を防ぐため、周辺システムも予防的に隔離します：①同一ネットワークセグメント内の端末を、別の隔離セグメントに移動、②ファイアウォールで該当セグメントへの通信を制限、③C&CサーバーのドメインをDNSシンクホール（ブラックホール）に設定し、全社的に通信をブロック、④マルウェアのハッシュ値をEDRに配布し、他端末での実行を自動ブロック。これらの措置により、仮に他にも感染端末があった場合でも、被害の拡大を防げます。

データ保護

ランサムウェアの場合、暗号化される前にデータを保護します：①重要データを外付けHDDやテープにオフライン退避、②バックアップシステムをネットワークから切断（バックアップが暗号化されるのを防ぐ）、③クラウドストレージの同期を一時停止（OneDrive、Dropbox等）、④データベースをリードオンリーモードに設定。ただし、これらの措置は業務への影響が大きいため、インシデントマネージャーまたは部門長の承認を得てから実施してください。

長期封じ込め

短期的な緊急措置の後、より恒久的な封じ込め策を実施します。

代替システムへの切替

感染したシステムを隔離したまま、代替手段で業務を継続します。

バックアップシステムの起動

事前に準備したDR（Disaster Recovery）サイトやクラウド上のバックアップシステムに切り替えます。BCP/DR計画に基づき、以下を実施してください：①バックアップサーバーの起動と動作確認、②DNSレコードの変更による通信の切り替え、③ユーザーへの新しいアクセス先の通知、④制限された機能での暫定運用開始。完全な機能ではなくても、最低限の業務継続が可能な状態を目指します。

手作業への一時切り替え

システムが使用できない間、紙ベースやExcelでの手作業に切り替えます。事前に「システム停止時の業務マニュアル」を準備しておき、各部門に配布してください。復旧後に、手作業で処理したデータをシステムに入力し直す手順も文書化しておきます。

外部サービスの利用

メールシステムが使えない場合、一時的に外部のWebメール（Gmail、Outlook.com等）を使用する、ファイル共有が必要な場合、Google DriveやDropbox等のクラウドサービスを緊急利用する等、柔軟に対応してください。ただし、セキュリティリスクがあるため、機密情報の取り扱いには注意が必要です。

セグメンテーション強化

既存のネットワークセグメンテーションが不十分だった場合、この機会に強化します。

推奨セグメント構成

セグメント	配置システム	アクセス制御	監視レベル
インターネットDMZ	公開Webサーバー、メールゲートウェイ	インターネットから80/443のみ許可	高
内部サーバーゾーン	業務サーバー、DB、ファイルサーバー	認証済みクライアントのみ許可	高
クライアントゾーン	従業員PC、モバイル	サーバーゾーンへの最小権限アクセス	中
管理ネットワーク	管理用端末、バックアップシステム	管理者のみアクセス可、他セグメントから隔離	最高
ゲストネットワーク	訪問者、BYOD	インターネットのみ、内部ネットワーク不可	低
IoT/OTゾーン	IoT機器、制御システム	専用セグメント、他ゾーンと完全分離	中

監視体制の強化

感染の再発や残存マルウェアの活動を検知するため、監視を強化します。

アラート閾値の引き下げ

通常時は誤検知を減らすために閾値を高めに設定していますが、インシデント対応期間中は閾値を50%程度に引き下げ、些細な異常も検知できるようにします。これにより、アラート数は増加しますが、見逃しのリスクを低減できます。

ハンティングの実施

受動的な監視だけでなく、能動的に脅威を探索する「脅威ハンティング」を実施します。セキュリティアナリストが、既知の攻撃パターンや異常な振る舞いを手がかりに、ログやネットワークトラフィックから隠れた脅威を探し出します。

外部SOCとの連携

社内リソースだけでは24時間監視が困難な場合、外部のSOC（Security Operations Center）サービスと連携します。彼らは専門的な脅威分析能力と24時間体制を持っており、迅速な異常検知が可能です。

マルウェア根絶

封じ込めが完了したら、マルウェアを完全に除去します。

駆除作業の実施

隔離された端末から、マルウェアを駆除します。詳細な手順は、マルウェア駆除ガイドを参照してください。

複数ツールでの駆除

単一のツールだけでなく、複数の駆除ツールを組み合わせて使用します。推奨する組み合わせは、①Malwarebytes（汎用マルウェア対策）、②ESET Online Scanner（異なるエンジンでのクロスチェック）、③専門駆除ツール（ランサムウェア復号ツール、ルートキット対策ツール等）、④Windows Defender（最終確認）。各ツールをセーフモードで実行し、検出されたマルウェアがゼロになるまで繰り返します。

手動での残存確認

駆除ツールだけでは完全に除去できない場合があります。以下を手動で確認してください：①レジストリのRun/RunOnceキーに不審なエントリがないか、②タスクスケジューラに不正なタスクがないか、③スタートアップフォルダに不審なファイルがないか、④サービス一覧に不明なサービスがないか、⑤Tempフォルダに実行ファイルが残っていないか。

IOCベースの検証

特定されたIOC（ファイルハッシュ、レジストリキー、ミューテックス名等）が、システム上に残存していないことを確認します。PowerShellスクリプトやEDRのクエリ機能で、自動的にチェックできます。

システムの再構築

駆除では不十分と判断した場合、または確実性を優先する場合は、OSのクリーンインストールを実施します。

再構築の判断基準

• ルートキットやファイルレスマルウェアなど、駆除が困難な種類
• 複数回の駆除試行でも完全に除去できない
• 重要なシステム（サーバー、経営層の端末等）で確実性が求められる
• システムファイルの改変が疑われる
• 感染期間が長期（数ヶ月以上）で、被害の全容が不明

再構築の手順は、復旧・再発防止ガイドを参照してください。

脆弱性の修正

マルウェアが悪用した脆弱性を修正しないと、再感染のリスクが残ります。

パッチ適用

マルウェアが悪用した脆弱性（CVE番号が特定されている場合）のパッチを、最優先で適用します。例えば、EternalBlueを悪用したWannaCryの場合、MS17-010パッチを全システムに適用します。また、悪用された脆弱性以外にも、すべての未適用パッチを一斉に適用し、セキュリティレベルを全体的に引き上げてください。

設定の修正

脆弱な設定が侵入を許した場合、設定を強化します：①弱いパスワードポリシーの強化（最小12文字、複雑性要件）、②不要なサービスの無効化（SMBv1、Telnet等）、③ファイアウォールルールの厳格化、④共有フォルダの権限見直し（Everyoneの削除）、⑤RDPやVPNへのアクセス制限。

アーキテクチャの見直し

根本的な脆弱性がアーキテクチャに起因する場合、大規模な見直しが必要です：①フラットなネットワークからセグメント化への移行、②境界防御からゼロトラストモデルへの移行、③クラウド移行によるセキュリティレベル向上、④多要素認証（MFA）の全社展開。

---

復旧・事後対応フェーズ｜正常化と改善活動

マルウェアの根絶が完了したら、システムを正常な状態に復旧し、事後分析を実施して再発防止策を立案します。

システム復旧

段階的かつ慎重にシステムを復旧していきます。

復旧優先順位

すべてのシステムを一斉に復旧するのではなく、事業への影響度に基づいて優先順位を付けます。一般的な復旧順序は以下の通りです：Tier 1（最優先）：認証基盤（Active Directory、Azure AD）、DNS、NTPサーバー → これらがないと他のシステムが機能しない。Tier 2（高優先度）：メールシステム、ファイルサーバー、VPN → 業務コミュニケーションと基本的なデータアクセスに必要。Tier 3（中優先度）：業務アプリケーション（ERP、CRM、会計システム等） → 業務プロセスの実行に必要。Tier 4（低優先度）：個別端末、開発環境、テストシステム → 業務への直接的な影響は限定的。各Tierの復旧には、事前に設定したRTO（Recovery Time Objective：目標復旧時間）に基づいて時間管理を実施してください。

段階的復旧

いきなり全ユーザーに公開するのではなく、段階的に復旧します。推奨する段階は以下の通りです：第1段階（パイロット運用）：全ユーザーの10%（ITリテラシーが高く、問題発生時に適切に報告できるメンバー）で24時間運用し、問題がないことを確認。第2段階（限定公開）：問題がなければ、ユーザーを50%に拡大して48時間運用。第3段階（全面復旧）：引き続き問題がなければ、全ユーザーに公開。ただし、復旧後72時間は監視を強化。各段階で、以下を確認してください：①システムの正常動作（機能テスト）、②パフォーマンスの正常性（応答時間、リソース使用率）、③セキュリティアラートの有無（再感染の兆候）、④ユーザーからの問い合わせ状況（操作上の問題）。

監視強化期間

復旧後の72時間は、24時間監視体制を維持します。この期間は、残存マルウェアが活動を再開したり、見逃していた感染端末が発見されたりする可能性が高いためです。監視項目は、①セキュリティアラートの発生状況、②C&Cサーバーへの通信の有無、③異常なプロセス起動、④大量のファイルアクセスや暗号化の兆候、⑤ネットワークトラフィックの異常。アラート閾値を通常の50%に設定し、些細な異常も検知できるようにしてください。問題が発見された場合は、即座に該当システムを再度隔離し、追加調査を実施します。

復旧優先順位マトリクス

Tier	システム分類	復旧目標時間	依存関係	復旧手法	検証項目
1	認証基盤（AD、AAD）	12時間	なし	バックアップ復元	ログイン成功、グループポリシー適用
1	DNS、DHCP	6時間	なし	再構築	名前解決、IPアドレス配布
2	メールシステム	24時間	認証基盤	バックアップ復元	送受信テスト、アドレス帳同期
2	ファイルサーバー	24時間	認証基盤	バックアップ復元	アクセス権限、ファイル整合性
3	基幹システム（ERP）	48時間	認証、DB	バックアップ復元	業務フロー実行、データ整合性
3	Webアプリケーション	48時間	認証、DB	再デプロイ	機能テスト、API連携
4	個別端末	1週間	認証	再イメージング	アプリ動作、設定復元
4	開発環境	2週間	認証	再構築	ビルド成功、デプロイ可能

事後分析（AAR）

インシデント対応が完了したら、After Action Review（事後検証）を実施します。

タイムライン分析

インシデントの全容を時系列で整理します。

完全なタイムラインの作成

初期侵入から完全復旧まで、すべての重要なイベントを時系列で並べます。以下の情報を含めてください：①初期侵入の日時と方法（フィッシングメール開封、脆弱性悪用等）、②マルウェアのダウンロード・実行、③権限昇格、④横展開、⑤データ持ち出し/暗号化、⑥検知時刻、⑦対応開始時刻、⑧各対応アクションの実施時刻、⑨復旧完了時刻。このタイムラインは、対応の適切性を評価し、改善点を見つけるための重要な資料となります。

潜伏期間の分析

初期侵入から検知までの時間（Dwell Time）を算出します。2024年の平均Dwell Timeは約16日とされていますが、これを短縮することが被害の最小化につながります。自組織のDwell Timeが長かった場合、検知能力の向上（EDRの導入、ログ監視の強化等）が必要です。

対応時間の分析

検知から封じ込めまでの時間、封じ込めから根絶までの時間、根絶から復旧までの時間を計測します。これらの時間が目標値（MTTD：Mean Time To Detect、MTTR：Mean Time To Respond）を超えている場合、プロセスの改善やツールの追加が必要です。

対応の評価

インシデント対応の良かった点と悪かった点を評価します。

評価フレームワーク

評価項目	評価基準	実績	評価	改善策
検知速度	MTTD < 1時間	3時間	△	SIEM相関ルール追加
初動対応	15分以内に隔離	10分	◎	継続
影響範囲特定	4時間以内	8時間	△	EDRクエリの自動化
コミュニケーション	30分以内に経営層報告	45分	△	報告テンプレート改善
証拠保全	全手順実施	一部未実施	×	チェックリスト遵守の徹底
根絶確認	IOC残存なし	1端末で残存発見	△	検証手順の強化
復旧時間	RTO達成	RTO+12時間	△	バックアップ高速化
事後分析	1週間以内に完了	2週間	△	分析工数の確保

改善点の抽出

事後分析で発見された問題点から、具体的な改善策を立案します。

技術的改善

技術面での脆弱性や不足していたツールを特定します：①検知能力の向上（EDR/XDRの導入、SIEM相関ルールの追加）、②防御能力の強化（多要素認証の展開、セグメンテーション実装）、③対応能力の向上（自動化スクリプトの作成、プレイブックの改善）、④復旧能力の強化（バックアップ頻度の増加、DR環境の整備）。

プロセス改善

対応プロセスでの問題点を改善します：①エスカレーションフローの見直し（意思決定の遅延があった場合）、②コミュニケーションプロトコルの改善（情報共有の遅れや混乱があった場合）、③チェックリストの更新（実施漏れがあった作業を追加）、④役割分担の明確化（責任の所在が不明確だった部分を明文化）。

人的改善

人員のスキルや体制の問題を改善します：①追加トレーニングの実施（対応で困難を感じた領域）、②人員増強の検討（リソース不足で対応が遅延した場合）、③外部専門家との契約見直し（支援が不十分だった場合）、④24時間対応体制の構築（夜間・休日発生への対応が不十分だった場合）。

報告書作成

インシデントの記録と、関係者への報告を実施します。

経営層向けサマリー

技術的な詳細よりも、ビジネスへの影響と今後の対策に焦点を当てた報告書を作成します。

経営層向け報告書の構成

1. エグゼクティブサマリー（1ページ）

   • インシデントの概要
   • 事業への影響（金額換算）
   • 対応結果（封じ込め成功、データ漏洩なし等）
   • 今後の対策（投資が必要な項目）

2. インシデント概要（1-2ページ）

   • 発生日時と検知日時
   • 攻撃の種類と手法
   • 被害システムと影響範囲
   • 対応の時系列サマリー

3. 事業への影響（1ページ）

   • ダウンタイムと業務への影響
   • 財務的損失（売上機会損失、対応コスト、復旧コスト）
   • 顧客・取引先への影響
   • 評判への影響

4. 根本原因と再発防止策（1-2ページ）

   • なぜ感染したのか（脆弱性、プロセスの不備）
   • 必要な対策（技術、プロセス、人材）
   • 投資計画と優先順位
   • 期待される効果

5. 今後のアクションプラン（1ページ）

   • 短期施策（1-3ヶ月）
   • 中期施策（3-12ヶ月）
   • 長期施策（1-3年）
   • 承認を求める事項

技術詳細レポート

技術者向けに、詳細な分析結果と対応手順を記録します。

マルウェア解析結果

検出されたマルウェアの詳細情報を記載します：①マルウェアファミリー名、②ファイルハッシュ（MD5、SHA-1、SHA-256）、③C&Cサーバーのドメイン/IPアドレス、④使用されたポート、⑤感染手法、⑥悪用された脆弱性（CVE番号）、⑦攻撃者の戦術・技術・手順（TTPs：Tactics, Techniques, and Procedures）をMITRE ATT&CKフレームワークで分類。この情報は、脅威インテリジェンスとして、JPCERT/CCや業界ISACと共有することも検討してください。

対応ログ

実施したすべてのアクションを時系列で記録します：①実施日時、②実施者、③実施内容、④結果、⑤次のアクション。この記録は、事後分析だけでなく、法的手続きで証拠として使用される可能性があるため、正確かつ詳細に記載してください。

教訓と推奨事項

今後同様のインシデントが発生した場合に役立つ教訓を記載します：①効果的だった対策、②不十分だった対策、③次回への改善提案、④他部門への推奨事項。この情報をインシデント対応ナレッジベースとして蓄積し、組織全体で共有してください。

外部向け報告

必要に応じて、外部機関への報告を実施します。

報告が必要なケース

報告先	報告条件	報告期限	報告内容
個人情報保護委員会	個人データ漏洩の可能性	速やかに（概ね3-5日以内）	漏洩の経緯、影響人数、対応状況
警察（サイバー犯罪対策課）	重大な被害、犯罪性が高い	任意（推奨）	被害状況、攻撃手法、証拠
業界監督官庁	業界特有の報告義務	業界規制による	業界ガイドラインに準拠
取引先・顧客	取引先データの漏洩の可能性	契約に基づく	影響範囲、対策、問い合わせ先
サイバー保険会社	保険適用を受ける場合	契約に基づく（通常48時間以内）	被害状況、対応コスト

---

手順書の維持管理｜継続的改善プロセス

IR手順書は、一度作成すれば終わりではありません。組織の変化、脅威の進化、教訓の蓄積に応じて、継続的に更新していく必要があります。

定期見直し

定期的なレビューサイクルを確立します。

四半期レビュー

3ヶ月ごとに手順書をレビューし、必要に応じて更新します。レビュー会議は2時間以内で完結させ、以下の観点で確認してください：①直近のインシデント対応事例からの教訓反映、②新たな脅威（最新のマルウェアトレンド、攻撃手法）への対応追加、③導入した新しいツールの操作手順追加、④組織変更に伴う体制・連絡先の更新、⑤チェックリストの追加・修正。レビューには、CSIRT全メンバーが参加し、実務担当者の意見を積極的に取り入れてください。机上のプロセスではなく、実際に使える手順書を目指します。

年次大規模改定

年に1度は、手順書全体を包括的に見直します。以下の作業を実施してください：①組織変更（部署統廃合、人員配置変更）の反映、②システム更新（クラウド移行、新システム導入）に伴う手順変更、③法規制変更（個人情報保護法改正、業界ガイドライン更新）への対応、④業界ベストプラクティスの取り込み、⑤外部専門家によるレビュー。外部専門家（セキュリティコンサルタント、監査法人等）に手順書をレビューしてもらうことで、客観的な評価と改善提案を得られます。また、他組織の事例や業界標準（NIST SP 800-61、JPCERT/CCガイドライン等）と比較し、不足している要素を追加してください。

随時更新

定期レビューを待たずに、必要に応じて即座に更新します。更新が必要なケースは以下の通りです：①重大インシデント発生後：対応で判明した問題点を48時間以内に暫定更新し、事後分析完了後（1週間以内）に正式改定、②緊急連絡先の変更：担当者の異動や退職があれば即日更新、③重大な脆弱性の公開：ゼロデイ攻撃等、緊急対応が必要な脅威が公開された場合、対応手順を追加、④ツールの大幅アップデート：操作方法が大きく変わった場合、スクリーンショット付きの手順を更新。更新履歴は、手順書の冒頭に「改訂履歴」として記載し、バージョン管理を徹底してください。

訓練と検証

手順書が実際に機能するかを、訓練を通じて検証します。

机上演習（年4回）

テーブルトップエクササイズ

実際にシステムを操作せず、想定シナリオに基づいて対応を議論する訓練です。四半期に1回、2時間程度で実施します。進行方法は以下の通りです：①シナリオの提示（例：「ランサムウェアに感染した」「C&Cサーバーへの通信を検知した」）、②各メンバーが手順書に基づいて、自分が取るべきアクションを発表、③グループディスカッションで、対応の適切性を議論、④発見された問題点を記録し、手順書を更新。この訓練により、手順書の不備（記載漏れ、曖昧な表現、実行不可能な手順等）を発見できます。

訓練シナリオの多様化

毎回同じシナリオではなく、多様な攻撃パターンで訓練します：①ランサムウェア攻撃、②標的型攻撃（APT）、③内部不正によるデータ持ち出し、④DDoS攻撃、⑤サプライチェーン攻撃、⑥複合攻撃（DDoS + ランサムウェア等）。また、夜間や休日に発生したケース、キーパーソンが不在のケース等、困難な状況も想定してください。

参加者の拡大

CSIRT メンバーだけでなく、経営層、広報部門、法務部門、業務部門のキーパーソンも参加させることで、全社的な対応能力を向上させます。特に経営層の参加は、インシデント対応の重要性を認識してもらう良い機会となります。

実機訓練（年2回）

半年に1回は、実際のシステムを使用した訓練を実施します。

実機訓練の実施内容

訓練項目	実施内容	所要時間	参加者
検知訓練	テスト用マルウェア（EICAR）の検知	30分	CSIRT技術メンバー
隔離訓練	特定端末のネットワーク隔離を実施	30分	CSIRT全員
証拠収集訓練	メモリダンプ、ディスクイメージ作成	1時間	フォレンジック担当
コミュニケーション訓練	報告書作成、経営層への説明	1時間	コミュニケーション担当
復旧訓練	バックアップからの復元テスト	2時間	IT部門全員
エスカレーション訓練	実際の連絡フローを確認	30分	全関係者

レッドチーム演習

年に1回は、外部の専門家（レッドチーム）に実際の攻撃を模擬してもらい、組織の対応能力を総合的に評価します。

レッドチーム演習の実施

レッドチーム（攻撃側）が実際の攻撃者の戦術を使用して、組織への侵入を試みます。ブルーチーム（防御側：CSIRT）は、通常業務の中でこれを検知・対応します。レッドチーム演習の利点は、①リアルな攻撃パターンで訓練できる、②検知能力の実効性を評価できる、③対応手順の実践的な検証ができる、④組織全体の連携を確認できる、という4点です。演習後は、レッドチームから詳細なレポートを受け取り、発見された脆弱性や対応の問題点を改善してください。

Purple Team活動

レッドチームとブルーチームが協力して、防御能力を向上させる活動です。攻撃と防御を交互に実施し、その場で改善策を議論・実装します。これにより、訓練と改善のサイクルを高速化できます。

コストと効果

レッドチーム演習は、外部専門家への委託費用として100-500万円程度かかりますが、実際のインシデント対応で数千万円の被害を防げる可能性を考えれば、十分に投資価値があります。サイバー保険の割引が受けられる場合もあります。

訓練スケジュール（年間計画）

月	訓練種別	内容	参加者	所要時間
1月	机上演習	ランサムウェアシナリオ	CSIRT全員	2時間
3月	実機訓練	検知・隔離訓練	CSIRT技術メンバー	半日
4月	机上演習	標的型攻撃シナリオ	CSIRT + 経営層	2時間
6月	レッドチーム演習	総合的な侵入テスト	全社	2日間
7月	机上演習	内部不正シナリオ	CSIRT + 法務	2時間
9月	実機訓練	復旧訓練	CSIRT + IT部門	半日
10月	机上演習	DDoS攻撃シナリオ	CSIRT + インフラ	2時間
12月	年次総合演習	複合攻撃シナリオ	全関係者	1日

関連文書の整合性

IR手順書は、他のセキュリティ関連文書と整合性を保つ必要があります。

BCP/DRとの連携

IR手順書とBCP（事業継続計画）、DR（災害復旧計画）は、密接に関連しています。

移行ポイントの明確化

IR手順書での「復旧」フェーズが完了した時点で、BCPに基づく事業継続プロセスに移行します。この移行ポイント（誰が判断し、誰に引き継ぐか）を明確に定義してください。一般的には、技術的な復旧が完了し、システムが安定稼働を始めた時点で、インシデントマネージャーからBCP担当者に主導権が移ります。

代替手段の整合性

IR手順書で「感染システムの隔離」を実施した場合、BCPで定義された代替手段（バックアップシステム、手作業への切り替え等）が発動されます。両者の手順が矛盾しないよう、定期的に突き合わせてください。

RTOとの整合性

IR手順書での復旧時間が、BCPで定義されたRTO（Recovery Time Objective：目標復旧時間）を超えないよう設計します。もしIR手順書の復旧に2週間かかるのに、BCPのRTOが72時間だとすれば、矛盾が生じます。この場合、IR手順を効率化するか、RTOを見直す必要があります。

セキュリティポリシーとの整合

組織のセキュリティポリシーと、IR手順書の内容が整合していることを確認します。

確認すべき整合性

• インシデントの定義が一致しているか
• 報告義務と報告先が一致しているか
• データ分類と取り扱いルールが一致しているか
• アクセス権限の管理ポリシーと、緊急時の権限昇格ルールが整合しているか
• ログ保存期間が、証拠保全要件を満たしているか

他プレイブックとの統合

マルウェア以外のインシデント（DDoS攻撃、データ漏洩、内部不正等）に対しても、個別のプレイブックを作成している場合、それらと統合または連携させます。

共通部分の抽出

すべてのプレイブックに共通する部分（体制、連絡先、エスカレーションフロー、証拠保全手順等）は、「共通手順書」として分離し、各プレイブックから参照する形にします。これにより、冗長性を排除し、更新漏れを防げます。

クロスリファレンス

あるインシデントが別のインシデントに発展する可能性がある場合（例：DDoS攻撃が陽動で、実際はマルウェア感染が目的）、関連するプレイブックへの参照を記載します。「DDoS攻撃対応中に、マルウェア感染の兆候がないかも並行して確認すること。マルウェア検知時は『マルウェアインシデントレスポンス手順書』に従う」のように記載してください。

プレイブックライブラリ

すべてのプレイブックを、組織内の共有ドライブやイントラネットに集約し、いつでも参照できるようにします。また、プレイブック一覧表を作成し、どのインシデントにどのプレイブックを使用するかを明示してください。

---

よくある質問（FAQ）

Q: 中小企業でもIR手順書は必要ですか？

A: 絶対に必要です。むしろ人員が限られる中小企業こそ、手順書による効率化が重要になります。大企業のような100ページを超える詳細な手順書は不要ですが、最小構成として以下を含む10ページ程度の手順書を作成してください：①緊急連絡先リスト（社内担当者、外部支援先、顧問弁護士、サイバー保険会社等の連絡先と対応可能時間）、②初動対応チェックリスト（A4で1ページ、感染端末の隔離、証拠保全、経営層への報告等の基本手順）、③証拠保全手順（メモリダンプの取得方法、ログの保存先、写真撮影のポイント等）、④復旧優先順位（どのシステムから復旧するか、RTOの目安）、⑤外部支援先の情報（どのような状況で誰に連絡するか）。これだけでも、ないよりは遥かに有効です。最初は簡易版から始めて、インシデント対応の経験や訓練を通じて段階的に充実させていけば十分です。重要なのは、「完璧な手順書を作ってから運用を始める」のではなく、「最小限の手順書で始めて、継続的に改善していく」というアプローチです。

Q: IR手順書とBCPの違いは？

A: IR手順書はサイバーインシデントの技術的対応に特化しており、BCPは事業継続全般をカバーする包括的な計画です。具体的な違いは以下の通りです：①対象範囲：IR手順書はサイバーインシデント（マルウェア、不正アクセス、データ漏洩等）に限定、BCPは自然災害、システム障害、パンデミック等、あらゆる事業中断リスクをカバー、②焦点：IR手順書は技術的プロセス（検知→分析→封じ込め→根絶→復旧）に焦点、BCPは事業プロセス（代替手段→最小限の事業継続→完全復旧）に焦点、③実施者：IR手順書は主にCSIRTやIT部門が使用、BCPは経営層と各事業部門が使用、④期間：IR手順書は数時間から数日の短期対応、BCPは数週間から数ヶ月の中長期対応。両者は補完関係にあり、IR手順書の「復旧」フェーズで技術的な復旧が完了した後、BCPに移行して事業の完全正常化を目指すという流れが一般的です。理想的には、両方を整備し、移行ポイントを明確にしておくことが重要です。

Q: 手順書の訓練頻度はどの程度が適切？

A: 最低でも以下の頻度で訓練を実施することを推奨します：①机上演習（テーブルトップエクササイズ）：四半期に1回、各2時間程度。想定シナリオに基づいて対応を議論する形式で、CSIRTメンバー全員が参加します、②実機訓練（ハンズオントレーニング）：半年に1回、各半日程度。実際のシステムを使用して、隔離、証拠収集、復旧等の技術的な手順を実践します、③大規模演習（レッドチーム演習含む）：年1回、1-2日間。組織全体を巻き込んだ総合的な訓練で、経営層も参加します。これに加えて、④新入社員や異動者が CSIRTに加わった場合は追加でオンボーディング訓練を実施、⑤システムの大幅な変更（クラウド移行、新ツール導入等）があった場合も追加訓練を実施、してください。訓練なき手順書は「絵に描いた餅」です。特に初動対応（感染端末の隔離、証拠保全等）は、反復練習により15分かかっていた作業を5分に短縮できます。この時間短縮が、被害の拡大を防ぐ鍵となります。また、訓練を通じて手順書の不備や実行不可能な手順を発見できるため、訓練は手順書の品質向上にも不可欠です。

Q: プレイブックは公開すべき？社外秘にすべき？

A: 基本構造は公開しても問題ありませんが、詳細は社外秘とするのが原則です。具体的な公開範囲の判断基準は以下の通りです。公開可能な情報：①対応フェーズの概要（検知→分析→封じ込め→根絶→復旧の流れ）、②役割分担の概念（インシデントマネージャー、技術リーダー等の役割）、③一般的な対応手順（業界標準に基づく内容）、④使用しているツールのカテゴリ（EDR、SIEM等の種類）。社外秘とすべき情報：①具体的なツール名とバージョン（攻撃者に脆弱性を悪用される可能性）、②IPアドレス、ホスト名、システム構成（攻撃の標的になる）、③緊急連絡先と個人名（プライバシー保護）、④対応時間の詳細（弱点を把握される）、⑤監視の盲点や既知の脆弱性（悪用される）。ただし、取引先や業務委託先とは、事前にプレイブックを共有し、インシデント発生時の連携体制を構築することは重要です。NDA（秘密保持契約）を締結した上で、相互にプレイブックを共有し、合同訓練を実施することで、サプライチェーン全体のセキュリティレベルを向上できます。

Q: AI/自動化はどこまで活用すべき？

A: 定型的で判断を伴わない作業は積極的に自動化し、高度な判断が必要な部分は人間が実施するというのが基本方針です。自動化を推奨する領域は以下の通りです：①IOC（Indicators of Compromise）による自動遮断：既知のマルウェアハッシュ、C&Cサーバードメイン等が検出された場合、自動的に通信をブロックまたは端末を隔離、②ログ収集：インシデント発生時に、関連するすべてのログを自動的に収集・保存するスクリプト、③初期トリアージ：セキュリティアラートを自動的に分類し、優先度を判定するSIEMの相関ルール、④定型通知：インシデント発生時の初期通知を、事前に定義されたテンプレートに基づいて自動送信。一方、人間の判断が必須の領域は：①エスカレーション判断（Critical/High/Mediumの最終判定）、②ビジネス影響評価（システム停止による事業への影響の評価）、③広報対応（外部への情報公開の判断と内容）、④法的判断（法執行機関への通報、訴訟対応）、⑤最終的な復旧判断（システムを本番環境に戻すタイミング）。SOAR（Security Orchestration, Automation and Response）ツールを導入することで、インシデント対応の定型部分を大幅に自動化でき、対応時間を50%削減した事例も報告されています。ただし、自動化には誤作動のリスクもあるため、必ず人間による最終確認のステップを組み込んでください。完全自動化ではなく、「人間の判断を支援する自動化」を目指すことが重要です。

---

まとめ｜準備が成功を決める

効果的なインシデントレスポンス手順書は、組織をサイバー攻撃から守る最も重要なツールの一つです。手順書なしでインシデントに対応することは、地図なしで未知の土地を旅するようなものです。

IR手順書成功の5つの要素

1. 明確な体制：誰が何をするかを明確に定義し、エスカレーションフローを確立
2. 実践的な手順：机上の空論ではなく、実際に実行可能な具体的手順を記載
3. 継続的な訓練：定期的な訓練を通じて、手順を習熟し、不備を発見・改善
4. 柔軟な対応：手順書に固執せず、状況に応じて柔軟に判断できる余地を残す
5. 定期的な更新：組織や脅威の変化に応じて、継続的に手順書を更新

重要なのは、完璧な手順書を作ることではなく、「使える手順書」を維持し続けることです。最初は簡易版から始めて、インシデント対応の経験や訓練を通じて段階的に充実させていってください。

「準備なき組織は、パニックに陥る」という格言を胸に刻み、今日から IR手順書の整備を始めましょう。次のインシデントは、明日起こるかもしれません。

---

関連記事

• インシデント初動対応ガイド
• フォレンジック調査の実施
• マルウェア感染後の復旧と再発防止策
• マルウェア駆除の手順と注意点
• ランサムウェア対応プレイブック
• 中小企業向けインシデント対応体制構築ガイド
• インシデント対応計画
• 事業継続計画（BCP）と災害復旧（DR）
• マルウェア感染：包括的な対策ガイド（ピラーページ）
• マルウェアインシデント対応完全ガイド（サブピラー）

---

【重要なお知らせ】

• 本記事は一般的な情報提供を目的としており、個別の組織の状況に対する専門的助言ではありません
• インシデントレスポンス手順書は、各組織の規模、業種、システム構成、リスクプロファイルに応じてカスタマイズする必要があります
• 本手順書の内容を実装する際は、法務部門や顧問弁護士に相談し、法的リスクを確認してください
• 証拠保全や法執行機関との連携が必要な場合、専門のフォレンジック業者やサイバー法務に詳しい弁護士の支援を受けることを推奨します
• 実際にインシデントが発生した場合、警察（サイバー犯罪相談窓口：#9110）、JPCERT/CC（https://www.jpcert.or.jp/）、IPA（https://www.ipa.go.jp/security/）などの公的機関への相談も検討してください
• 記載内容は2025年1月時点の情報であり、サイバー攻撃の手法や対応技術は日々進化しているため、最新の脅威情報も併せてご確認ください
• 本手順書は、組織内での使用を目的としています。外部への提供や公開の際は、機密情報が含まれていないことを確認してください