インシデントハンドリング（⑩報告・共有）

ー 報告・共有 ー

はじめに

　インシデントハンドリングにおける「報告・共有」フェーズは、主に復旧までの対応が完了した後に実施される重要なフェーズです。この活動の目的は、対応の全体像を整理して関係者や外部機関に適切に伝えることで、組織への信頼を維持しつつ、再発防止とレジリエンスの向上を図ることにあります。
　ここで求められるのは、影響範囲や原因、対応経緯、是正措置などの事実関係を、時系列の流れを意識して整理し、関係者に対して透明性と責任をもって伝えることです。対応の過程を時系列で明確にすることは、インシデントの発生から復旧までの全体像を関係者が正しく理解するうえで有効であり、ハンドリングの完了とともに、次の改善活動（Check/Act）へと活かすための教訓としても活用されます。
　各種ガイドラインでも、本フェーズの重要性は一貫して強調されています。NIST SP 800-61 Rev.2では、インシデント対応の最終フェーズとして、報告書の作成と外部関係者への通知が定められています。また、CSIRTハンドブックでは、情報開示に関するポリシー整備や、関係機関・組織との連携体制の重要性が詳述されています。さらに、ISO/IEC 27035においても、報告・共有は単なる事後処理にとどまらず、組織全体の知見を蓄積・活用するためのものと位置付けられています。
　本稿では、この「報告・共有」フェーズにおいて、何を、誰に、どのように伝えるべきかという観点から、具体的に考えます。

図１　報告・共有フェーズの位置付け

具体的な実施例

　本フェーズで報告・共有すべき情報やその手段は、インシデントの性質や影響範囲、さらには関係者の立場によって大きく異なります。
　以下に、主なステークホルダー別に整理した報告・共有の実施例を示します。

１．経営層への報告

• 目的：
  経営判断に必要な全体像の把握
• 主な内容：
  インシデントの概要（発生日・発見日・復旧状況）、業務・サービスへの影響、原因と再発防止策の方向性、外部への報告状況（規制当局・報道対応など）
• ポイント：
  技術的詳細よりも「何が起きて、どのように対処し、何がリスクとして残っているのか」を要約する（1枚資料＋口頭ブリーフィング形式などが有効）

２．規制当局への報告

• 目的：
  法令・ガイドラインに基づく義務への対応
• 主な内容：
  個人情報漏洩や社会的インフラ障害等に関する報告義務に基づく定型フォーマット（例：件名、影響件数、原因、対応状況、再発防止策）
• ポイント：
  報告期限・提出手段（メール・ポータル）・報告対象の判断基準などを事前に整理する。インシデント発生日や初動時点での速報と、調査完了後の確報を区別することも多い。

３．法執行機関への連携

• 目的：
  刑事事件としての対応や捜査協力
• 主な内容：
  攻撃経路、通信ログ、マルウェア解析結果など、証拠性を意識した技術的情報
• ポイント：
  エビデンスの収集・保全はインシデント対応の初期からの準備が必要。報告書とは別に「時系列に整理された対応記録（例：インシデントタイムライン）」が重視される。

４．業界ISAC・他組織への共有

• 目的：
  脅威情報の共有による相互防御力の強化
• 主な内容：
  IoC（Indicators of Compromise）、攻撃手口の特徴、関連する脅威インテリジェンス情報
• ポイント：
  匿名化や非識別化処理を行ったうえで共有する場合もある。フォーマット（STIX/TAXII等）に対応した自動共有基盤を用いる場合もあり、日常的な体制整備が必要。
  　本フェーズを効果的かつ効率的に進めるためには、「誰に・何を・どのように」伝えるのかを事前に明らかにしておくことが必要です。報告先ごとに内容の粒度、伝達手段、適切なタイミングを調整することで、透明性を確保しながら信頼関係を維持し、再発防止や組織の対応力向上に活かすことができます。

まとめ

　インシデント対応の一連の流れにおいて、「報告・共有」フェーズは復旧後に行われる活動とされていますが、事後処理としてだけではなく、対応内容を正確に整理し、透明性をもって関係者と情報を共有することで、信頼を維持し、改善に活かす役割を持ちます。
　本フェーズでは、関係者に何をどのように伝えるかを明確にし、対応内容を時系列で整理することが求められます。記録と調査を連携させた準備を行うことで、報告の有効性を高めることができます。
　また、各種ガイドラインでも、報告と共有は単なる義務ではなく、組織のナレッジを蓄積・活用するプロセスと位置づけられており、インシデント対応能力の継続的な改善にも寄与するものとされています。
　本フェーズを戦略的に実施することは、対応の総括と再発防止の原点であり、組織全体のセキュリティ体制を着実に強化する上で重要です。

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい方や、正確性を重視される方は、以下の一次資料をご参照ください。

• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide
• ISO/IEC 27035-1 Information technology — Security techniques — Information security incident management Part 1: Principles of incident management
• CISA: Cybersecurity Incident & Vulnerability Response Playbooks Nov. 2021
• CMU: Handbook for Computer Security Incident Response Teams (CSIRTs)

脚注

インシデントハンドリング（⑨復旧）

ー 復旧 ー

はじめに

　復旧は、インシデントによって影響を受けたシステムや業務を通常の運用状態に戻すためのフェーズであり、組織のレジリエンスを確保・強化する上で極めて重要なものです。
　前回の「根絶フェーズ」では、攻撃者の活動やマルウェアなどの脅威を完全に除去する作業について取り上げました。しかし、根絶が完了しても、直ちに本番稼働へ移行することはできません。復旧フェーズでは、インシデントにより停止または隔離されたシステムの再構築、データの整合性確認、通信経路や設定の見直し、ユーザへのサービス再開に向けた対応など、多岐にわたる作業が求められます。
　さらに、復旧作業においては、単なる復元ではなく、同種のインシデントが再発しないよう対策が施されていることを確認する必要があります。例えば、設定変更やパッチ適用、アクセス制御の強化などが確実に行われているか、システムが正しく動作するかといった観点からの検証が求められます。これらの検証を経て初めて、業務を「通常運用」に戻す判断が下されます。
　本稿では、復旧フェーズにおける具体的な実施例や考慮事項について整理します。復旧は、技術的な作業のみならず、業務部門との連携や、経営層への報告、再発防止の観点からの検証など、組織横断的な対応が求められる局面でもあります。

図１　復旧フェーズの位置付け

具体的な実施例

　ここからは、復旧フェーズにおいて実際に行われる具体的な管理策について考えます。復旧フェーズは、直前の根絶フェーズで脅威の完全除去が確認されたことを前提として実施されます。
　すなわち、マルウェアや不正な設定、バックドアなどが除去され、システムが信頼可能な状態に回復していることが前提となるため、復旧では、安全かつ安定した業務再開を実現するための準備と検証が求められます。

１．ログ監査と試験運用

　復旧対象システムについては、直近のログやネットワークトラフィックを再確認し、根絶が不十分であった痕跡が残っていないか最終的なチェックを実施します。その後、本番環境への復帰に先立ち、限定されたユーザや機能で一時的に試験環境による運用を行い、システムの動作や通信状況に異常がないことを確認します。

２．通信経路とサービス再開の段階的実施

　外部公開サービスについては、ファイアウォール、WAF、リバースプロキシなどの制御機能を活用しながら、段階的に通信を再開します。一方、内部業務システムでは、業務の優先順位や部門の利用状況に応じて、利用可能範囲を段階的に広げることで、業務への影響をできる限り抑えつつ復旧します。

３．関係者間の調整と承認プロセス

　復旧の実施に際して、システムオーナー、業務部門、CSIRT、情報システム部門などの関係者間で復旧計画や作業内容に関する合意を形成する必要があります。さらに、本番環境への復帰については、所定の承認フローに基づき、必要に応じて経営層からの承認を得ることで、正式な再開判断を行います。

　このように、復旧フェーズは単なるシステムの復元だけではなく、業務再開を見据えた包括的な調整と検証が必要です。技術面と組織面の両方に配慮した対応を計画的に実施することが、確実な復旧と再発防止には不可欠です。

４．その他の留意点

　復旧作業の性質上、「できるだけ早く元に戻す」ことが優先されがちですが、再感染や設定不備のリスクを回避するためには、慎重な対応が求められます。試験運用中に生じる軽微な不具合や予期しない挙動を「些細な問題」と見なしてしまうと、根絶が不完全であった場合の再燃リスクを見逃す可能性があります。対応内容と判断の記録を残し、後日のレビューに備えることも復旧フェーズにおいて重要な活動の一部です。

　下記は、復旧を急ぐことで想定される失敗例です：

失敗例	原因	教訓
早期復旧後に再感染	根絶フェーズが不完全、試験運用不足	検証と監査を丁寧に行うべき
設定ミスによる業務停止	手順ミスや変更管理の徹底不足	設定変更にはWチェックと記録が必要
関係部門との調整不足	復旧作業が技術部門中心で進行	利用部門との連携・説明が不可欠

　次のようなチェックリストを事前に準備しておくことで、復旧を間違いなく進めることが可能になります。

　最終チェックリスト（抜粋）：

• [ ] 根絶フェーズの完了記録があり、確認済みである
• [ ] システムの正常動作が一時的な試験運用で確認されている
• [ ] 通信経路やアクセス制御に過剰な例外設定がない
• [ ] 復旧時の変更点が文書化され、レビューされている
• [ ] 業務部門との合意形成および復旧完了の承認が取得されている

まとめ

　本稿では、インシデントハンドリングにおける復旧フェーズの意義と実務的な内容について考察しました。復旧フェーズは、単にシステムの再起動やデータの復元作業だけではなく、業務継続性の確保と将来の再発防止を両立させるための重要なプロセスです。
　前段の根絶フェーズで脅威が排除されていることを前提に、復旧フェーズではシステムの健全性を確認し、安全な状態で本番運用に戻すための検証や承認プロセスが求められます。特に、限定的な試験運用による挙動確認や、関係者間の合意形成、復旧変更点の文書化といったプロセスは、単なる技術的管理策を超えた組織的な取り組みです。
　また、復旧を急ぐあまり、確認や調整を疎かにすることは、結果として再発や業務中断のリスクを高めてしまいます。そのため、慎重かつ計画的に対応を進めるとともに、対応内容を記録し、次回に活かす体制づくりが求められます。
　インシデントハンドリング全体において、復旧フェーズは“終わり”ではなく“次への備え”に直結します。適切な復旧対応により単なる復元ではなく、組織の対応力と信頼性を改善することも考えるべきです。

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい方や、正確性を重視される方は、以下の一次資料をご参照ください。

• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide
• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
• CISA: Cybersecurity Incident & Vulnerability Response Playbooks Nov. 2021
• CMU: Handbook for Computer Security Incident Response Teams (CSIRTs)

脚注

インシデントハンドリング（⑧根絶）

ー 根絶 ー

はじめに

　前回の記事「インシデントハンドリング（⑦持続的封じ込め）」では、攻撃者の活動範囲を制限し、被害の拡大を防ぐための恒久的な封じ込めについて考察しました。封じ込めによって、組織内の影響範囲が一定の範囲に抑えられたとしても、根本的な脅威要因が残存している限り、再侵入や再発のリスクが残ります。
　そのため、次のステップとして「根絶（Eradication）」が実施されます。根絶フェーズでは、攻撃者が残した痕跡やマルウェア、バックドア、悪意ある設定変更などを完全に除去し、攻撃者が初期アクセスに利用した手段（経路）を特定し、無効化し、修復することにより、脅威の再発を防止します。このプロセスは、インシデント対応の中でも最も「脅威そのもの」に対処し、完全に取り除くことを目的とするフェーズであり、技術的な分析力と精緻な対応計画が求められます。
　本稿では、各種ガイドラインを参考にし、「根絶」フェーズの目的と具体的な実施内容に関し考えます。

図１　根絶フェーズの位置付け

具体的な実施例

　ここからは、根絶フェーズにおいて実施する具体的な管理策について考えます。ここで実施する管理策は、マルウェア駆除などの対処療法的なものではなく、攻撃者の痕跡を分析・追跡し、再侵入のリスクを根本的に排除するためのものです。

１．マルウェアの完全除去

　攻撃者が展開したマルウェアや関連ファイルが組織内に残存していると、再侵入や横展開のリスクが継続するため、下記管理策により、それらを全て特定し、除去します。

管理策例：

• フォレンジックツールを用いたディスクスキャンとメモリ解析により、マルウェア本体や関連ファイルを特定し完全に削除
• 永続化機構（レジストリ、スケジューラ等）の削除

２．バックドアおよびC2通信の遮断

　攻撃者が外部のC2サーバから組織内の端末を操作し続けることが可能な状態が続くと、被害が長期化したり再侵入されるリスクが高まるため、下記管理策によりその通信経路を完全に遮断します。

管理策例：

• 通信ログからC2サーバへのOutbound通信を検知
• ファイアウォールやACLにより通信を恒久的に遮断

３．資格情報の無効化・再発行

　攻撃中に悪用されたアカウントをそのまま放置しておくと、攻撃者が再度侵入する足掛かりとなるリスクがあるため、下記管理策により、資格情報の悪用を防止し、認証基盤の健全性を回復します。

管理策例：

• 侵害アカウントを即時停止
• 特権アカウントを棚卸し、パスワードを再設定または再作成

４．初期アクセス手段の除去

　攻撃者が最初に侵入に成功した経路を放置しておくと、同じ手口による再侵入が容易に発生するため、下記管理策により、その侵入口を特定し、再利用を完全に防止します。

管理策例：

• 脆弱性の特定とパッチ適用
• セキュリティポリシー逸脱（過剰権限設定など）の是正

５．被害端末の再構築（必要に応じて）

侵害を受けた端末をそのまま使用し続けると、攻撃者による操作の痕跡やマルウェアが見過ごされる可能性があるため、下記管理策により、安全な状態に再構築します。

管理策例：

• OSの再インストールまたはゴールドイメージ（trusted baseline image：事前に構成された安全な標準OSイメージ）による復元
• バックアップデータが改ざん・汚染されていないことを確認したうえで、安全な状態にリストア

　上記の各管理策は、単なる被害の収束ではなく、「脅威を排除しきった」と言える状態を目指す必要があります。そのためには、初期アクセスから永続化手段、横展開の痕跡まで、体系的な分析と根絶作業が求められます。

まとめ

　本稿では、インシデントハンドリングにおける「根絶」フェーズの役割とその具体的な実施例について考察しました。封じ込めによって影響範囲を一時的に制御できたとしても、攻撃者が残した痕跡や初期アクセス手段がそのままでは、再侵入や再被害のリスクが残存します。したがって、根絶フェーズでは、攻撃者が残した痕跡を徹底的に分析・除去し、組織内の環境を安全な状態へ戻すことが求められ、その対象は、マルウェア本体のみならず、永続化設定、バックドア、外部通信経路、不正に使用された資格情報、初期アクセス経路など多岐にわたります。
　なお、本フェーズで実施される管理策は、長期的封じ込めフェーズの内容と一部重複しますが、その目的（「脅威の遮断」ではなく「脅威の排除」）と深さ（部分的制御ではなく徹底的な排除）において明確に区別されます。
　NISTやCISAなどの各種ガイドラインにおいても、根絶は「信頼できる状態の回復」に不可欠なフェーズとされており、再発防止の観点からも非常に重要です。正確なログ分析と脅威インテリジェンスを活用しながら、技術的・組織的な管理策を組み合わせて対応することが求められます。
　次のフェーズである「復旧（Recovery）」へと進むためには、この根絶フェーズにおいて「何を排除したか」と「セキュアである根拠」を明確にし、ステークホルダー間で合意を得ることが、確実な対応の前提となります。

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい方や、正確性を重視される方は、以下の一次資料をご参照ください。

• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide
• NIST SP 800-184: Guide for Cybersecurity Event Recovery
• CISA: Cybersecurity Incident & Vulnerability Response Playbooks Nov. 2021
• CMU: Handbook for Computer Security Incident Response Teams (CSIRTs)

脚注

インシデントハンドリング（⑦持続的封じ込め）

ー 持続的封じ込め ー

はじめに

　インシデントハンドリングにおける「持続的封じ込め（長期的封じ込め：Long-term Containment）」フェーズでは、短期的な緊急対応が完了した後に実施される持続的な対処を行います。このフェーズでは、残存するリスクの排除、被害の再拡大防止、業務復旧のための慎重かつ計画的な措置が求められます。直前のフェーズである「優先順位決定（トリアージ）」では、影響範囲や重要度に応じた対応の優先度が整理されましたが、持続的封じ込めでは、この判断結果を元に、対象システム・サービスに対して恒久的な管理策を講じます。
　このフェーズは、緊急的な「封じ込め」ではなく、持続的な監視と管理策の実施により、再侵入させないことを目的とします。そのため、テクニカルな分析に加え、対象となる業務システムや関係部門との調整、場合によっては経営層への説明なども発生します。
　本稿では、「持続的封じ込め」フェーズにおける具体的な実施例について考えます。

図１　持続的封じ込めフェーズの位置付け

具体的な実施例

　ここからは、「持続的封じ込め」フェーズにおいて実際に行われる管理策（主に技術的管理策）について考えます。これらの管理策は、短期的な封じ込めで得られた知見や、トリアージでの優先順位付けに基づき、再侵入や再発を防止するための継続的な措置として行われます。

１．恒久的な通信遮断の実施

　一時的なブロック対応で止めていた不審な通信について、FirewallやACLなどを用いて恒久的な遮断ルールを適用します。場合によっては、ネットワークセグメントの再設計や隔離ネットワークの構築が必要になることもあります。これは、攻撃者の通信経路を物理的・論理的に排除する重要な管理策です。

２．アクセス制御の見直しと再構成

　不正アクセスに利用されたアカウントや権限に対しては、使用停止・再発行・権限縮小などの措置を行い、パスワードポリシーの強化や多要素認証の導入を並行して進めます。加えて、Active DirectoryやIAMの設定全体を見直し、不要な権限を排除します。

３．マルウェアの残存痕跡の徹底排除

　ファイルレスマルウェアやスケジュールタスク、レジストリへの埋め込みなど、揮発性・非揮発性メモリ領域に残存する異常な振る舞いの痕跡を分析し、該当箇所を確実に除去します。再起動後に復活するような常駐型の攻撃についても考慮が必要です。

４．ログ監視体制の強化と再設計

　インシデント前には収集対象外だったシステムやアプリケーションも含め、ログ収集範囲の拡大と保管期間の見直しを行います。また、SIEMやEDR製品を活用し、再感染の兆候や不審な振る舞いのリアルタイム検知を可能にする体制を整備します。

　これらの管理策は個別に実施されるものの、互いに補完し合いながら全体としての封じ込め効果を高めるものです。また、実施の過程では必ずログの記録と証跡の確保を行い、後続フェーズでの報告や改善活動（Check/Act）に活かすことが重要です。

まとめ

　「持続的封じ込め」フェーズは、インシデントハンドリングにおいて初動対応の次のステップとして、復旧に向けた前提条件を整える重要なステップであり、根絶や復旧フェーズと密接に関係しながら、継続的な監視と対策を通してインシデントの再発・拡大を防止する役割を担います。
　このフェーズで実施する内容は、応急処置ではなく、恒久的にセキュアな状態を維持し、再侵入リスクを排除することにあります。前フェーズのトリアージや短期的封じ込めで得られた知見を元に、恒久的な技術的管理策の実施や継続的な監視体制の再構築などが行われます。
　本稿では、持続的封じ込めにおいて必要となる考え方と代表的な管理策について考察しましたが、実際のインシデント対応では、個別の状況に応じた柔軟な対応が求められます。特に、高度化する攻撃手法に対応するには、常に最新の脅威情報を踏まえた監視設計や、継続的な改善活動（Check/Act）との連携が欠かせません。
　次のフェーズとなる「根絶」「復旧」に進むにあたっては、この持続的封じ込めで行った対策が確実に機能しているかどうかを判断基準とし、関係者間での合意の元にセキュアな状態への移行を図ることが求められます

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい方や、正確性を重視される方は、以下の一次資料をご参照ください。

• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide
• NIST SP 800-92: Guide to Computer Security Log Management
• NIST SP 800-184: Guide for Cybersecurity Event Recovery
• CISA: Cybersecurity Incident & Vulnerability Response Playbooks Nov. 2021
• CMU: Handbook for Computer Security Incident Response Teams (CSIRTs)

脚注

インシデントハンドリング（⑥優先順位決定）

ー トリアージ：優先順位決定 ー

はじめに

　インシデントハンドリングにおいて「優先順位決定（Prioritization）」は、すでに対応が必要と判断された複数のインシデント候補に対し、どれに対し優先的に対応すべきかを明確にするフェーズです。この判断は、限られたリソースを有効活用し、封じ込めや根絶といった後続の対応をより効果的に進めるための重要なフェーズです。
　対応の優先度は、前フェーズである「影響度分析（Impact Analysis）」の結果に基づいて判断されます。つまり、影響範囲・深刻度・復旧の容易さなどの定量、又は定性的な評価結果を踏まえ、複数のインシデントの中から対応順を決定します。
　例えば、基幹システムに影響を与えるインシデントや、進行中で被害が拡大し続けているインシデント、外部への情報漏洩が懸念されるケースなどは、早急な対応が求められます。また、業種・業態によっても重視される観点は異なり、法規制・契約義務・組織の社会的な評判の失墜などの影響も考慮しなければなりません。
　このような優先順位決定においては、主観的な判断に頼るのではなく、一定の基準に基づいた客観的かつ再現性のある評価が求められます。NIST SP 800-61などの代表的なガイドラインでは、インシデントの深刻度や業務影響度に基づくスコアリングモデルやマトリクスの活用が推奨されています。これにより、関係部門との合意形成や経営層への報告がスムーズになり、組織として一貫性のある判断ができるようになります。
　本稿では、「優先順位決定」フェーズにフォーカスし、その評価手法について整理します。

図１　優先順位決定フェーズの位置付け

具体的な実施例

　ここからは、優先順位決定フェーズで活用可能な評価基準や手法に関し、具体的に考えます。

１．評価マトリクスによる優先順位付け

　影響度（例えば、業務インパクトや影響ユーザー数）と緊急度（例えば、進行状況、公的・法的報告義務、再発・波及リスク）の2軸による評価マトリクスを用いることで、インシデントの優先順位を客観的かつ一貫性をもって判断することができます。

緊急度 \ 影響度	低	中	高
低	優先度：低	優先度：中	優先度：中
中	優先度：中	優先度：中	優先度：高
高	優先度：中	優先度：高	優先度：最優先

　このマトリクスは、現場での判断基準を半定量化し、部門間の合意形成を効率化するために有効です。さらに、優先度ごとの対応時間のSLA（例：最優先＝1時間以内、優先度高＝4時間以内など）などの対応方針を予め定めることで、現場での対応を標準化することが可能です。

２．スコアリングモデルの活用

　多様な評価要素を考慮したい場合には、次のように複数の観点で評価項目を洗い出しておきそれぞれにスコアリングを割り当てておくことで、合計点に基づいた優先度の分類が可能になります。なお、各指標に対するスコアの重み付けは、組織の方針や業種・業態に応じて調整されます。

評価項目	点数例
業務への影響度	1～5点
顧客への影響（契約上の義務、ユーザー数など）	1～5点
インシデントの進行状況	1～3点
公的・法的報告義務の有無	0 or 3点
再発・波及リスク	1～3点

　例えば、合計が12点以上なら「最優先」、8～11点なら「優先度高」、それ未満であれば「優先度中、低」としてランク付けします。このように半定量的な基準を設けることで、現場で判断する時の目安となり、組織内での対応を標準化できます。

３．経営層との連携と事業リスクの考慮

　インシデントによっては、技術的な深刻度が必ずしも高くないにもかかわらず、社会的信用や顧客との契約上の義務というような事業リスクの観点から、迅速な対応が求められるケースがあります。例えば、製造業の現場では、広報部門や法務部門を交えた緊急会議を速やかに開催し、事業継続計画（BCP）との整合性を踏まえて、優先度の再評価が実施されるようなケースもあります。
　このように、優先順位の決定は単に技術的な評価だけではなく、事業リスクや社会的な評判（レピュテーションリスク）などの観点も含め、総合的に判断する必要があります。

まとめ

　本稿では、インシデントハンドリングにおける「優先順位決定」フェーズについて、その目的と判断基準、さらに具体的な実施例を交えて考察しました。
　このフェーズは、影響度分析の結果を踏まえ、複数のインシデント候補の中から、どの対応を優先すべきかを判断するプロセスです。限られたリソースを適切に配分し、封じ込め・根絶・復旧といった後続フェーズを効率よく実施するためには、戦略的かつ一貫した優先順位の設定が必要です。
　実務上、評価マトリクスやスコアリングモデルを活用し、判断を半定量化することで、作業を標準化し、部門間や経営層との合意形成を効率化できます。また、単に技術的な観点だけではなく、「社会的な信用」、「法的、契約上の義務」、「事業継続」のような事業リスクも考慮することで、より総合的な意思決定が可能になります。
　このように、優先順位決定フェーズは、インシデント対応の質とスピードを左右する重要な指針であり、組織全体でその基準を明確にし記録しておくことで、組織としてのリスク管理姿勢を示すことが可能になり、説明責任やガバナンス強化といった観点からも、デューデリジェンスの一環として機能します。

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい方や、正確性を重視される方は、以下の一次資料をご参照ください。

• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide
• NIST SP 800-184: Guide for Cybersecurity Event Recovery
• CISA: Cybersecurity Incident & Vulnerability Response Playbooks Nov. 2021
• CISA: Federal Incident Notification Guidelines

脚注

インシデントハンドリング（⑤影響度分析）

ー トリアージ：影響度分析 ー

はじめに

　インシデントハンドリングにおける「影響度分析（Impact Analysis）」は、検知されたインシデントが業務や情報資産に与える影響を多角的に評価し、次のトリアージフェーズで実施する対応優先度の判断に必要な材料を得るためのプロセスです。本稿では、このプロセスにおいて実施すべき評価項目や分析手法について整理します。

図１　影響度分析フェーズの位置付け

　まず、ISMSに基づく管理策の指針として広く活用されているISO/IEC 27002:2022の中から、本稿で取り上げる「影響度分析」に特に関連が深いと思われる「5.25 情報セキュリティイベントのアセスメントと決定（Assessment and decision on information security events）」について確認しておきます。

ISO/IEC 27002:2022 5.25 Assessment and decision on information security events から引用

Purpose：
To ensure effective categorization and prioritization of information security events.
管理目的：
情報セキュリティイベントの効果的な分類と優先順位付けを確実に行うため。

Control：
The organization should assess information security events and decide if they are to be categorized as information security incidents.
管理策：
組織は、情報セキュリティイベントを評価し、情報セキュリティインシデントに分類するか否かを決定することが望ましい。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　本管理策では、検知された情報セキュリティインシデントを正確に評価・分類し、その重要度や影響度に応じて適切な優先順位を決定することが求められています。これにより、セキュリティリスクを効率的に管理し、被害の拡大を未然に防止することが可能となります。
　特に、インシデント対応には限られたリソースしか割けないことが多いため、「対応すべきか否か」「どういう順番で対応すべきか」 を迅速かつ適切に判断する必要があります。これらの判断はトリアージと呼ばれますが、その判断材料として、インシデントがもたらす影響を多角的に捉える影響度分析が不可欠です。影響度分析の結果が、トリアージにおける合理的かつ戦略的な意思決定を支える基盤となります。

　影響度分析は、次のような様々な視点により実施されます：

• リスク・フレーミングやスレット・フレーミングによる事前準備
• MITRE ATT&CKによるTTPs（戦術・技術・手順）の分析
• CISAプレイブックにおける一連の問い（アタックベクター、脆弱性、永続化手法など）
• 被害範囲、脆弱性悪用状況、事業への影響、情報資産の損失、復旧の容易性などの具体的評価指標

　上記を踏まえ、ナレッジベースやSIEMによる相関分析の活用、過去の事例・アセット情報との照合、さらに攻撃者の戦術・技術・手順（TTPs）を明確に整理・記録することで、効果的なトリアージとその後のフェーズに役立つ情報が得られます。
　次項以降にて、上記観点に基づき、影響度分析フェーズで考慮すべき具体的な評価手法や考慮次項を考えます。

具体的な実施例

　ここでは、影響度分析フェーズにおいて実施すべき具体的な内容について考えます。影響度は時間の経過や対応の進展によって変化するため、インシデント対応の各段階で継続的に見直すことが必要です。そのためには、柔軟かつ継続的な情報収集体制とレビュー体制の整備・維持が求められます。
　加えて、影響度分析を効果的に進めるためには、単に項目ごとの評価を行うだけでなく、攻撃の全体像や進行状況を捉えた上で、仮説的に「どこに・どの程度の影響が及んでいるか」を見極める視点が求められます。MITRE ATT&CK™フレームワークを活用することで、攻撃者の戦術・技術・手順（TTPs）を把握し、被害拡大の恐れや今後のリスクを予測する手がかりとなります。

　また、CISAのインシデント対応プレイブックでは、攻撃の構造を理解するため、次のような観点で調査することが推奨されています：

• 初期アクセス手段（アタックベクター）は何か？
• 敵対者はどのように環境へアクセスし、どの脆弱性を悪用しているか？
• コマンド＆コントロールや永続化はどのように行われているか？
• 侵害されたアカウントの特性（権限レベルなど）は？
• 偵察、ラテラルムーブメント、データの外部持ち出しが行われたか？それはどのような手段で？

１．影響を受けた範囲の特定

　インシデントによる影響が及んだ範囲を正確に特定することは、影響度分析の基盤となる作業です。影響対象には、ネットワークセグメント、個別デバイス、ユーザーアカウント、さらには業務プロセス全体が含まれる可能性があります。特に、制御系システムや基幹業務システムが関与している場合には、事業継続性への影響も含めて慎重に評価する必要があります。
　これらの特定作業では、資産管理台帳やCMDB（構成管理データベース）などの既存の構成情報と突合し、影響範囲の正確性と網羅性を確保することが求められます。

２．脆弱性および悪用状況の確認

　インシデントに関連する既知または未知の脆弱性が存在し、それらが実際に悪用された形跡の有無を調査します。特に、攻撃者がどのような方法で脆弱性を突いて侵入や拡大を試みたかを把握することは、影響範囲の評価や封じ込め策の検討において重要です。
　さらに、攻撃が現在も進行中であるかどうかを確認することも重要です。例えば、C2通信の継続や追加ペイロードの展開*1というような兆候が認められる場合は、直ちに封じ込めなどの対応が必要です。

３．情報資産への影響

　攻撃によって組織の情報資産が受けた影響を評価します。影響の評価は、情報セキュリティの3要素（機密性、完全性、可用性）に基づいて行い、それぞれの観点でどのような損害が発生したのかを整理します。
　さらに、業務プロセスや顧客・取引先などの利害関係者にどのような影響が及んだかを特定し、それに伴う被害規模を定性的・定量的に評価します。たとえば、サービス停止件数や顧客対応の遅延による影響人数などを参考指標とします。

４．情報の損失・流出の有無

　インシデントに伴い、情報が暗号化、削除、あるいは外部に持ち出された可能性の有無を調査します。特にランサムウェアなどによりファイルが暗号化されている場合や、明らかな削除・改ざんの痕跡が見られる場合は、損失の有無および範囲の特定が優先事項となります。
　また、外部流出が懸念されるケースでは、ダークWebの監視やフォレンジックツールを活用して、流出の有無と範囲をより正確に把握し、損失規模を見積もります。

５．復旧可能性と所要時間の見積もり

　インシデントにより被害を受けたシステムやサービスについて、復旧の可否とその所要時間を見積もります。バックアップの有無や整合性、冗長構成の状況などを確認し、回復可能性の有無を確認します。
　さらに、業務への重要度や業務停止による影響の大きさを踏まえ、復旧の緊急度や必要性を整理し、これらの評価結果をトリアージフェーズにおける優先順位決定のための材料として提供します。

６．経営層・関係部門との連携

　分析結果に基づく重要な判断を行う際には、経営層や関係部門との緊密な連携が不可欠です。特に、法的対応や公表の要否、外部ステークホルダーへの説明責任が伴うケースでは、適切な合意形成と判断の透明性が求められます。
　判断そのものはトリアージフェーズで行いますが、本フェーズで得られた分析結果は、経営判断に資する形態で、定性的および定量的に整理し、報告することが望まれます。

７．分析精度と運用基盤の確保

　影響度を客観的かつ一貫して評価するために、事前に評価基準（例：「高」「中」「低」）を定義し、関係者間で共有しておくことも有効です。例えば、業務停止時間、影響を受けたユーザー数、データの機密性などに基づいて分類基準を定めておくことで、評価結果のばらつきを抑えることができます。
　なお、影響度を評価する際には、リスク分析の考え方が参考になります。リスク分析については過去の記事で考察しています。

blg8.hatenablog.com

　さらに、本フェーズにおいては、分析に必要なインプットと、得られたアウトプットの整理も重要です。主なインプットとしては、SIEMログ、資産管理台帳、脅威インテリジェンス、ユーザー行動記録などがあり、これらを元に生成される評価結果（例：影響範囲マトリクスや被害サマリ）は、経営判断や封じ込め計画の立案において活用されます。

まとめ

　本稿では、インシデントハンドリングにおける「影響度分析」フェーズについて、その目的、実施すべき具体的な内容、および実務上の考慮事項について考えてみました。
　影響度分析は、単に被害の有無を確認する作業ではなく、どの業務や情報資産がどの程度の影響を受けたのかを定性的、又は定量的に評価するものであり、その評価結果は後続のトリアージ（優先順位決定）に向けた重要な判断材料として活用されます。限られたリソースの中で、どのインシデントから優先的に対応すべきかを判断するためには、影響度分析で得られた情報が不可欠です。影響範囲、損失の有無、復旧難易度などを多角的に評価することにより、次フェーズであるトリアージにおいて、より戦略的かつ合理的な優先順位判断を行うための基礎データを提供することが可能になります。
　また、影響度分析は一度限りの作業ではなく、インシデントの進行状況や新たな情報に応じて随時見直しを行うべき動的な作業です。SIEMや脅威インテリジェンスなどの活用により、リアルタイムな情報収集と分析のサイクルを確立することが、影響度評価の精度を高める鍵となります。
　次のフェーズであるトリアージにおいては、本稿で整理した評価観点をもとに、組織としての判断基準に照らして優先順位を定め、迅速かつ適切な対応に結びつけることが求められます。影響度分析とトリアージは連続したプロセスであり、前者の質が後者の妥当性を大きく左右します。
　したがって、インシデントハンドリング全体の精度を向上させるためには、影響度分析を組織的に実施し、その結果を確実に次工程へとつなぐ体制整備も必要です。

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい方や、正確性を重視される方は、以下の一次資料をご参照ください。

• ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls
• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide
• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
• NIST SP 800-184: Guide for Cybersecurity Event Recovery
• CISA: Cybersecurity Incident & Vulnerability Response Playbooks Nov. 2021
• FIRST Computer Security Incident Response Team (CSIRT) Services Framework v2.1

脚注

*1:追加ペイロードの展開とは、初期侵入後に攻撃者がさらなるマルウェアやスクリプト（例：情報窃取ツールやランサムウェア本体）を投入する行為を指し、攻撃が進行している兆候とみなされます。

インシデントハンドリング（④適格性判断）

ー トリアージ：適格性判断 ー

はじめに

　インシデントハンドリングにおける「適格性判断（Triage: Relevance Assessment）」フェーズは、検知されたセキュリティイベントを本当に「インシデント」として対応すべきかを見極めるステップです。全ての検知イベントが対応の対象とは限らず、誤検知や正当なアクティビティに起因するものをインシデントと誤認すれば、不要な対応コストや人的リソースの浪費・疲弊、対応遅延といったリスクを招きかねません。一方で、軽微に見える事象の背後に深刻な侵害が潜んでいるケースもあり、見落としによる被害拡大も念頭に置く必要があります。
　そのため、CSIRTをはじめとした対応チームにおいては、組織のセキュリティポリシーや対応基準、外部脅威情報、業務との整合性というような複数の観点から、情報の信頼性やイベントの深刻度を評価し、「本当に対処すべきか？」を客観的かつ再現性のある手順で判断する必要があります。
　本フェーズは、インシデントハンドリングの中で最初に行う判断フェーズであり、後続の優先順位付けや封じ込め策の正確性・迅速性に直結します。本稿では、この「適格性判断」フェーズにフォーカスし、その目的、判断基準、考慮事項などを整理します。

図１　適格性判断フェーズの位置付け

具体的な実施例

１．適格性判断のための評価基準

　適格性判断フェーズでは、検知されたセキュリティイベントに対して初期分析を行った結果から、インシデントとして正式に対応すべきかどうかを判断するための評価基準を活用します。

　適格性判断を行う際には、以下のような観点に基づいて総合的に評価を行う必要があります：

• セキュリティポリシーやプレイブックに基づく定義との照合
• 攻撃の兆候となる技術的痕跡の有無（不審な通信や異常プロセスなど）
• 正当な業務活動や過去の正常パターンとの整合性
• 外部の脅威インテリジェンスやMITRE ATT&CKとの整合性
• 検知内容に対する信頼性の高い裏付けの有無（ログ、アーティファクトなど）

　次項では、上記観点を踏まえた適格性判断の具体的な実施例を紹介します。

２．実施例

例1）未知の外部IP宛てのアウトバウンド通信

• イベント内容：
  平日日中に、社内端末から未知の海外IPアドレス（ポートTCP/4444）への継続的な通信が確認された
• 確認の観点：
  • セキュリティポリシーでは、業務上不要な外部IPへの通信は禁止されている
  • 当該IPは複数の脅威インテリジェンスフィードでC2サーバーとして登録されていた
  • 通信元端末のユーザーに確認したところ、該当時間帯にはPC操作を行っていないとの証言が得られた
• 判断結果：
  インシデントと判断し、直ちに当該端末をネットワークから隔離

例2）大量のファイルアクセス

• イベント内容：
  深夜に1台のファイルサーバーに対して、複数のファイルアクセス（read/write）が集中していたとSIEMからアラートが発報された
• 確認の観点：
  • 当該端末は定例のバックアップスクリプト実行対象であった
  • アクセス元のプロセスログは予定されたスケジューラー経由の正常な実行と一致している
  • 過去のログとの比較においても同様のアクセスパターンが毎週観測されていた
• 判断結果：
  正常な業務オペレーションとして判断し、インシデントとして対応しない

例3）PowerShell実行

• イベント内容：
  EDRが、社内端末で難読化されたPowerShellスクリプトの実行を検知した
• 確認の観点：
  • 深夜1時（ユーザーの勤務時間外）に実行されていた
  • スクリプト内容の一部にC2との接続コードが含まれていた
  • 当該端末には最近USB接続された記録があり、リムーバブルメディア経由での侵害が疑われた
• 判断結果：
  不正なスクリプト実行と判断し、直ちに当該端末をネットワークから隔離

　このように、適格性判断では「何が起きたか」だけでなく、「なぜそれが起きたか」、「それが妥当なイベントか」、「どのような証拠があるか」など、初期分析結果のコンテキストを見極める必要があります。判断ミスは、過剰対応や見落としのいずれにもなり得るため、標準化された判断基準やプレイブックの整備が重要です。

まとめ

　適格性判断フェーズには、インシデントハンドリングの中でも特に迅速な判断と正確性が求められます。本フェーズの目的は、全ての検知イベントに無条件で対応するのではなく、業務上の正当な挙動や誤検知を適切に除外し、真に対応が必要となるインシデントのみを迅速に特定することにあります。
　迅速かつ適切な判断を行うためには、セキュリティポリシーやプレイブックに基づいた基準、攻撃の兆候となる技術的痕跡、業務運用との整合性、脅威インテリジェンスとの一致、信頼性のある証拠の有無など、複数の視点からの評価が不可欠です。これらを組み合わせた総合的な判断により、対応の適切性と効率性が大きく向上します。
　「具体的な実施例」で示したように、一見目立たない通信や単純な挙動の背後に深刻な侵害が潜んでいるケースもあれば、一見不審に見えるアクティビティが業務の一環として正当である場合もあります。このような個々の判断を属人化させず、再現性と客観性を持たせるためには、明確な判断基準とそれを支える仕組み（ログ分析基盤、脅威情報の統合、EDR活用など）の整備が必要になります。
　適格性判断の結果は、後続フェーズ（優先順位付け、封じ込め、根絶）に直接影響します。したがって、本フェーズを単なる確認作業ではなく、戦略的意思決定の出発点と捉え、組織的なナレッジと標準手順として確立していくことが求められます。

参考資料

　本稿は、以下のガイドラインを参考にしています。より詳細な情報を得たい方や、正確性を重視される方は、以下の一次資料をご参照ください。

• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide
• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
• NIST SP 800-92: Guide to Computer Security Log Management
• ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls
• ISO/IEC 27035-1 Information technology — Security techniques — Information security incident management Part 1: Principles of incident management
• CISA: Cybersecurity Incident & Vulnerability Response Playbooks Nov. 2021
• MITRE ATT&CK Framework

脚注