インシデント対応計画をゼロから構築する

サイバー攻撃は予告なく襲いかかってきます。ある朝、アラートが鳴り、誰かがサポートチケットを開き、経営陣に報告が回る頃には、被害はすでに拡大しているのです。侵害を数時間で封じ込められる企業と、数ヶ月も復旧作業に追われる企業との違いは、技術力の優劣ではありません。それは「準備」の有無です。具体的には、問題が発生する前に計画が立てられていたかどうか、ということです。

インシデント対応計画（IRP）とは、セキュリティインシデントを検知し、封じ込め、復旧するための、文書化され、テスト済みの手順のことです。堅苦しい響きに聞こえるかもしれませんが、実際には、午前2時に発生した事態に対して、秩序ある対応ができるか、それとも組織的な混乱に陥るかの分かれ目となります。

実際に「インシデント」とみなされるものとは

すべてのアラートがインシデントというわけではありません。ログインの失敗は「ノイズ」ですが、ファイルサーバーを暗号化するランサムウェアはそうではありません。この区別は、誰がどのくらいの速さで対応に当たるかを決定する上で重要です。

何かが起こる前に定義しておくべき一般的なカテゴリ：

• データ漏洩：機密データまたは規制対象データへの不正アクセス
• マルウェア感染：ランサムウェア、スパイウェア、ワイパー、トロイの木馬
• サービス拒否：システムの機能を低下させたり、停止させたりする攻撃
• 内部脅威：従業員や契約業者による悪意のある、あるいは不注意による行為
• サプライチェーンの侵害：ベンダーのソフトウェアを介して侵入する攻撃（SolarWindsがその典型例）
• 不正アクセス：認証情報の盗用、権限の昇格、横方向の移動

クリックされたものの何もインストールされなかったフィッシングメールと、Cobalt Strikeのビーコンをインストールしてしまったフィッシングメールとは異なります。対策計画では、これら両方のケースに対応し、どちらがどちらであるかをチームに迅速に伝える必要があります。

なぜほとんどの計画は実際にはうまくいかないのか

インシデント対応マニュアルを策定している組織は数多くあります。しかし、実際に誰かが読んだことのあるマニュアルを持っている組織は、その数よりはるかに少ないのです。さらに、実際のシナリオに近い状況でそのマニュアルを検証したことがある組織は、さらに少ないのです。

よくある問題だ。文書は3年前のものだし、すでに会社を辞めた人の連絡先が記載されているし、すでに置き換えられたツールが前提とされているし、実際の対応チームにはこの文書を見たことのある者が一人もいない。結局のところ、ポリシー文書があることと、実務用のプレイブックがあることの間には、大きな隔たりがあるのだ。前者は監査人を満足させるためのものだ。後者は、午前3時に本番環境がダウンし、侵害されたサーバーをオフラインにする権限を持つ者が誰なのか誰も分からないような状況で実際に使うものなのだ。

6つの段階と、それらが実践において意味すること

NIST SP 800-61のフレームワークでは、インシデント対応を6つのフェーズに分類しています。SANSも同様の論理を採用していますが、名称は異なります。いずれにせよ、その構造は変わりません。

準備

インシデント発生前のすべての準備。こここそが、真の作業が行われる場です。インシデントの定義、対応チームの編成と訓練、ログ記録およびアラート発報インフラの構築、テーブルトップ演習の実施などです。そのなかで、常に見落とされがちなのが「事前の行動承認」です。インシデント発生中、サーバーを隔離するために法的な承認を待っている余裕などありません。エスカレーションなしに、誰が何を即座に実行できるかを、あらかじめ決めておく必要があります。

識別

何かが起こった。問題は、それが具体的に何なのかということだ。この段階では、アラートを確定したインシデントへと転換し、SIEMやEDRツール間でシグナルを関連付け、影響範囲を特定し、タイムラインを構築する。ここでのスピードは、準備段階で設定したログの品質に直結している。質の低いログは、原因の特定を遅らせる。原因の特定が遅れれば、選択肢も狭まってしまう。

封じ込め

短期的な封じ込めは迅速かつ大雑把な手段です。感染したホストを隔離し、攻撃元のIPアドレスをブロックし、侵害されたアカウントを無効化します。一方、長期的な封じ込めはより緻密な対応を要します。一時的な修正、システムの設定変更、特定の挙動に対する監視の強化などが挙げられます。常に直面する決断の一つは、「直ちに接続を切断するか、それともまず攻撃者の動きを観察するか」ということです。接続を切断すれば被害を最小限に抑えられますが、監視を続けることで被害の全容を把握できます。どちらの選択肢にも正当な根拠があります。この判断については、プレッシャーの下でその場しのぎで決めるのではなく、事前に話し合っておくべきです。

根絶

脅威を完全に排除します。攻撃の標的となった箇所にパッチを適用し、マルウェアや持続化メカニズムを削除し、認証情報を更新し、侵害されたシステムをクリーンなイメージから再構築します。この手順を省略したり、急いで済ませたりすると、2週間後には同じ攻撃経路を通じて組織が再び侵害されることになります。こうした事例は、公表されているよりもはるかに頻繁に発生しています。

回復

サービスを優先順位に従って復旧させてください。システムを再接続する前に、システムに問題がないことを確認してください。再発の兆候がないか注意深く監視してください。また、通知義務も履行してください。GDPRでは、個人データ漏洩が発生した場合、72時間以内に監督当局へ通知することが義務付けられています。復旧作業が進行中であっても、この期限は停止されることはありません。

得られた教訓

多くのチームは疲れ果てているため、この段階を省略しがちです。しかし、それこそが、この段階が重要である理由なのです。事後検証は2週間以内に行うべきです。何が起きたか、何がうまくいったか、何がうまくいかなかったか、どのような課題が明らかになったか、どのような変更を行うか、そしてその期限はいつか。それらを文書化し、計画を更新します。そして、実際に変更を実行に移す必要があります。そうでなければ、単なる会議に終わってしまいます。

計画を実行可能にするツール

IRPには、何をすべきかが記載されています。ツールこそが、プレッシャーのかかる状況下でも迅速にそれを実行に移すためのものです。

• SIEM：大規模なログ相関分析のためのSplunk、Microsoft Sentinel、IBM QRadar
• EDR：CrowdStrike Falcon、SentinelOne、Microsoft Defender（行動分析による検知およびエンドポイントの隔離）
• SOAR：Palo Alto XSOAR、プレイブックを自動実行するSplunk SOAR
• 脅威インテリジェンス：MISP、Recorded Futureによる攻撃者のTTPに関する背景情報
• フォレンジック：調査および証拠保全のためのヴェロキラプトル、Magnet AXIOM、Volatility

ツールそのものよりも、プレッシャーのかかる状況下でそれをうまく使いこなせるかどうかの方が重要です。400ものダッシュボードがあるものの、ランブックが1つもないSplunkインスタンスは、誰の役にも立ちません。

知っておくべき規制の整合性

業界や地域によっては、IRPは単なる選択肢ではなく、法的要件となります。主な枠組み：

• NIST SP 800-61 Rev. 2：米国連邦政府および大半の企業環境における基準
• ISO/IEC 27035：インシデント管理に関する国際規格
• GDPR第33条：EUの個人データに関する72時間以内の違反通知
• NIS2指令：EU全域における重要サービス事業者のインシデント報告要件
• DORA：2025年1月から施行されるEUの金融セクターのレジリエンス要件。これには、明確なIRテストの実施義務が含まれている。
• PCI DSS v4.0：決済業界における文書化および年次テストの要件

現在、組織を不意を突いているのがNIS2と DORAです。これらはいずれも、文書化、テストの頻度、報告の期限に関して、要件を大幅に引き上げています。

検討に値するプロバイダー

IR体制を完全に社内で構築している組織もあります。しかし、多くの組織には、特にシミュレーションやテストにおいて、それを適切に実施するための十分な人員や経験が備わっていません。その一例を以下に挙げます：

DXC Technologyは、IRプログラムの策定から実施までを包括的に支援しています。具体的には、計画の策定、机上演習、および管理型検知・対応（MDR）などです。特に、エネルギー、医療、金融サービスといった規制の厳しい分野において強みを発揮しており、エネルギー分野のソフトウェアソリューションを含め、プロジェクトの初期段階からコンプライアンスへの適合が組み込まれています。

Secureworks（アトランタ）は、同社のTaegis XDRプラットフォームと併せて、IRリテーナーサービスを提供しています。同社のCounter Threat Unitは、継続的に脅威インテリジェンスを発行しており、その情報はプレイブックの更新に直接反映されるため、単一の環境で検知と対応を行いたいチームにとって有用です。

WithSecure（ヘルシンキ）は、欧州の規制要件に強く準拠しつつ、IRプログラムの構築においてコンサルティング型のアプローチを採用しています。純粋なマネージドサービスを求める組織よりも、初めてIR体制を構築する組織に適しています。

Trustwave（シカゴ）は、マネージド・セキュリティ・サービスと、過去10年間にわたり業界屈指の詳細な脅威レポートを数多く作成してきた社内レッドチーム「SpiderLabs」によるインシデント対応（IR）コンサルティングを組み合わせています。

Orange Cyberdefense（フランス）は、EU内の複数の管轄区域にわたる国境を越えたインシデント対応（IR）の調整を同時に実施しています。これは、異なる国々でNIS2およびGDPRの義務を並行して管理している多国籍企業にとって有用です。

毎回繰り返してしまうミス

入念に準備したチームでさえ、予測可能なミスを犯すものです。中でも特に繰り返し発生しやすいのは、次のようなものです：

• 計画を検証しないこと：シミュレーションによる負荷試験を一度も実施していない文書は、単なる当て推量に過ぎない
• 明確な連絡手順が定まっていない：誰が報道機関に対応し、誰が規制当局に連絡し、誰が顧客に通知するのか
• バックアップが問題ないと仮定し、検証を行わない
• 第三者を排除する：クラウドプロバイダー、SaaSベンダー、MSPは、事後報告を受けるのではなく、そのプロセスに参画する必要がある
• IRをIT部門だけの業務と見なすこと：重大なインシデントの発生時には、法務、広報、人事、そして経営陣のすべてがそれぞれの役割を担う

そして最大の落とし穴は、この計画を「一度きりのプロジェクト」として扱ってしまうことです。脅威は変化し、システムも変わり、人は去っていきます。積極的に維持管理されていないIRPは、実際に必要になる前にすでに時代遅れになってしまいます。

よくあるご質問

一から実用的なIRPを構築するには、どれくらいの時間がかかりますか？

基本的な計画案は4～6週間で作成可能です。プレイブック、検証済みの演習、ツールの統合を備えた成熟したプログラムを構築するには、現実的には3～6ヶ月かかります。

どのくらいの頻度で検査すべきですか？

少なくとも年1回。DORAやほとんどのエンタープライズ・フレームワークでは、現在、年2回の机上演習と、少なくとも年1回の本格的なシミュレーションの実施が推奨されています。重大なインシデントやシステムの大規模な変更が発生した後は、直ちにレビューを行ってください。

「テーブルトップ」と「レッドチーム演習」の違いは何ですか？

テーブルトップ演習は議論が中心であり、シナリオを順を追って検討するだけで、システムには一切触れません。レッドチーム演習では、実際のインフラストラクチャを標的として、攻撃者の手法を積極的にシミュレートします。どちらも価値があり、それぞれ異なる点を検証するものです。

インシデントが確認された際、まずどのような対応を取ればよいでしょうか？

対応チームを動員し、発生時刻と初期の兆候を記録した上で、事前に承認済みの封じ込め措置を開始してください。フォレンジック証拠が保全されるまでは、感染したシステムに手を加えてクリーンアップを行わないでください。その情報こそが、発生した事態の全容を明らかにするものです。

• について
• 最新記事

ミレーナ・バグダサリャン

コンテンツスペシャリスト（勤務先： PowerDMARCの

ミレーナは、IT、サイバーセキュリティ、バーチャルイベントなどに関する魅力的なコンテンツ制作に7年以上の経験を持つ、熟練したライター兼コンテンツ制作者です。ニューヨーク大学アブダビ校、UWCチャイナ校、カレッジ・オブ・ヨーロッパなどの名門校を卒業。

最新記事 by Milena Baghdasaryan(全て見る)

• インシデント対応計画を一から策定する - 2026年9月8日
• ハッカーが金融AIアシスタントを騙す新たな手口 - 2026年9月7日
• DNSセキュリティのベストプラクティス：包括的なセキュリティ強化チェックリスト - 2026年9月7日