インシデント対応計画を策定する際のよくある 7 つの間違いとその回避方法
Cisco Talos は最近、欧州連合（EU）で来年発効予定の NIS2 の概要について取り上げました。これは、サイバーセキュリティとセキュリティインシデントの開示に関する新しい要件です。
この新ガイドラインの一環として、EU 域内で事業を行う組織は、最新の「インシデント処理」手順と「リスク分析および情報システムのセキュリティに関するポリシー」を整備することが求められます。
これを遵守するために、情報セキュリティポリシー、事業継続および危機管理計画に加えて、組織のインシデント対応計画を作成または更新することを Talos インシデント対応チーム（Talos IR）では推奨しています。インシデント対応計画は、各組織がサイバーセキュリティを実践するうえで非常に重要なドキュメントであり、NIS2 に準拠するために最初に更新する必要のあるドキュメントの 1 つと考えるべきです。
ここからは、インシデント対応計画を作成または更新する際に陥りやすい 7 つの落とし穴について概説します。よくある間違いを少しでも回避できれば、より迅速に計画を更新できるうえ、隙のない計画に仕上げられるので、もしインシデントが発生したらどうするかということではなく、インシデントの発生を想定した対応が可能になります。
パート II：インシデント対応計画を作成する際に避けるべき落とし穴
ドキュメント階層の定義に失敗する
インシデント対応計画を新規に作成したり更新したりする際にありがちな間違いは、組織内に存在するすべてのサイバーセキュリティ文書を考慮せずに、対応計画だけに注目してしまうことです。
「ドキュメント階層」という用語は複雑でわかりにくいと思えるかもしれませんが、概念はごくシンプルであり、組織内のすべてのドキュメントは特定の範囲を対象とし、目的を定め、対象読者を想定する必要があるということです。レゴブロックを積み重ねるようなものだと考えればよいでしょう。
ドキュメント B では、ドキュメント A ですでに提示されている内容は繰り返さず、プロセスの特定の部分についての詳細を記載することで、ドキュメント A で提示された情報を補うことができます。個々のドキュメントがドキュメント階層全体の中でどのように位置づけられているかを明確に把握することで情報の重複が避けられ、ドキュメントが必要以上に長くならないようにできるのです。焦点が明確で比較的短いドキュメントであれば、対象読者に読まれ、効果的に使用される可能性が高くなります。
サイバーセキュリティの文脈で、Talos IR は以下の構成要素からなるドキュメント階層を推奨しています。
インシデント対応計画では、インシデント処理プロセスに焦点を当てます。セキュリティポリシーまたはセキュリティ プリンシパル ステートメントに記載されている上位レベルの情報に基づいて作成される、第 2 レベルまたは第 3 レベルのドキュメントがインシデント対応計画です。その対象読者はセキュリティポリシーまたはセキュリティ プリンシパル ステートメントよりも絞られており、インシデント対応チームの編成と運営、インシデント対応プロセスの各段階で講じる措置と利用可能なリソース、エスカレーションの手順、情報伝達の流れに関する詳細が記載されています。インシデント対応計画に記載されている情報はすべてのサイバーセキュリティ インシデントに適用でき、次のレベルのドキュメント（詳しい手順を説明するシナリオベースの文書）を作成する基礎となります。
明確なドキュメント階層を定義し、その定義に従わないと、ハンドブックに記載したほうがよい個別のチェックリストタイプの情報をインシデント対応計画に詰め込み過ぎてしまう危険性があります。通常、ハンドブックはインシデント対応計画に基づいて構築され、ランサムウェア、不審な電子メール、異常なネットワークトラフィックなど、特定の種類のインシデントに対応するための手順を追ったガイダンスを提供します。もう 1 つのリスクは、インシデント対応計画で扱う範囲が広すぎることです。セキュリティポリシーの内容を転載し、一般的なサイバーハイジーンのアドバイスやエンドユーザートレーニングのトピックまで列挙すると、主な対象読者であるインシデント対応者がニーズに合った重要な情報を見つけるのは難しくなります。
内容がざっくりしすぎている
インシデント対応計画では、少なくともサイバーセキュリティ インシデントに関して「誰が、何を、いつ、どのように」という問いに答える必要があります。
わかりやすく説明すると次のようになります。
- 誰が – インシデント対応プロセスの一部である役割にはどのようなものがあるか、その役割のメンバーには（技術面、危機管理および調整の観点から）どのようなスキルセットや能力が必要か、インシデント対応のさまざまな段階でサポート役として他に誰が関与するのか。
- 何を – インシデント対応プロセスの各段階でどのような措置を講じるのか。インシデント対応計画はハンドブックではないため、ホスト上の疑わしい実行ファイルの調査といった詳細を記述する必要はありません。その代わり、一般的なトリアージプロセス、組織内で利用可能なデータソース、インシデントが絞り込まれた後に参照する可能性のあるハンドブックを記載しておく必要があります。
- いつ – インシデント発生時には一刻を争うため、インシデントが発生したときにいつでも実行できるよう、あらかじめ対応の順序を決めておくとよいでしょう。たとえばインシデントの優先順位の分類（これも対応計画に記載する必要があります）に基づいて、エスカレーションプロセスが開始される場合があります。優先順位の高いイベントが週末に発生した場合、直ちにマネージャに電話する必要があるのか、そうしたエスカレーションは通常の勤務時間外でも行えるのか、といった情報を記載しておきます。また、各措置について、役割を担う担当者を指定する必要もあります。
- どのように – インシデント対応計画には、インシデント発生時に技術的対応に通常使用されるツール（データ収集、検知機能、分析ツールを含む）およびインシデント中の通信手段（ネットワークの侵害が疑われる場合、どのような代替インフラを使用できるかなど）に関する大まかな情報を含める必要があります。ただし、インシデント対応計画では、チームが自由に使用できるツールキットとして、ツールの機能の概要のみを提示するようにします。ツールの使用手順の詳細は組織のハンドブックに追加します。
内容が細かすぎる
インシデント対応計画はハンドブックではありません。あくまでも基本的な情報を記載し、他のハンドブックで繰り返し言及せずにすむようにするものです。たとえばランサムウェアや分散型サービス妨害（DDoS）など特定の種類の攻撃にしか適用できない手順に関する情報は、インシデント対応計画には記載しないようにします。そうした情報まで記載するとドキュメントの範囲が狭まってしまうからです。
担当者が 1 人で作成する
公平に見ても、プロセスに関するドキュメントの作成に心からやりがいを感じる技術担当者はほとんどいません。このため、インシデント対応計画に携わる人物が、広範なチームからサポートを受けられるようにすることがより重要になります。
有意義なインシデント対応計画を作成する最も効果的な方法の 1 つは、会社の関係者（主要なビジネスアプリケーションの所有者など）を巻き込むことです。そうすることで関係者の理解が深まり、そのニーズと期待が対応計画に確実に反映されます。
最初の計画草案は、プロセスの知識があり、インシデント対応プロセスの実施を担当する少なくとも 2 人のチームメンバーがレビューするようにします。次のレベルのレビューは、中核であるインシデント対応チーム以外のチームが行います。たとえば、復旧中に重要な役割を果たすネットワーキングやストレージ管理などのチームです。法務、広報、人事などの技術系以外のチームには、レビュー用の最終草案の作成をサポートしてもらいます。NIS2 などの一部の規制では 24 時間以内のインシデント通知が必要となるため、後者のインプットは技術的なインプットと同じくらい貴重です。たとえば金曜日の午後に発生したインシデントは日曜日までに報告する必要がありますが、週末に法執行機関にインシデントの報告ができるのか、その場合は誰が連絡するのかを確認するのは法務チームの責任です。
インシデント対応計画をテストしていない
テストプロセスが不可欠であることは周知の事実ですが、すべてのプロセスが同じように作成されているわけではありません。バックアップの復旧手順やインシデント対応プロセスをどのくらいの頻度でテストしているでしょうか。
インシデント対応計画には通常、エスカレーションプロセス、トリアージプロセス、代替通信チャネルの有効化プロセスなど、いくつかのサブプロセスに関する記述が含まれています。対応計画は、実際のインシデント発生時に使用されてこそ意味があります。これらのサブプロセスに何らかのギャップがあるとしたら、それを特定する最善の方法はテストすることです。
インシデント対応計画をテストするには、まず、インシデント処理プロセス全体を主要なプロセスに分割します。次に、全体的な対応における各プロセスの重要度と、テストに要する労力のレベルに応じて、それらのプロセスをランク付けします。一番上のサブプロセスから始めて、下に向かって進めていきます。
たとえば「インシデント対応責任者がバックアップ管理チームに連絡し、バックアップの状況を確認する」という復旧対応について考えてみます。確認しておきたい内容としては次のようなものがあります。
- インシデント対応責任者はバックアップ管理チームにどのように連絡するのか。会社の通信手段がダウンしたり被害を受けたりした場合、その通信手段はオフラインで利用できるのか。
- インシデントが発生した時間帯にバックアップ管理チームは対応できるのか。週末や祝日にインシデントが発生した場合はどうするのか。
- バックアップ管理チームはどこを見ればバックアップの直近のテスト日を確認できるのか。バックアップの完全性を検証する際にバックアップ管理チームが従うべき手順があるか。そうした概要の作成にはどれくらいかかるのか。
- バックアップが分離されている場合、その完全性をチェックできるか。
- データ侵害の疑いがある場合に備えて、バックアップ管理チームはバックアップにアクセスできるすべてのアカウントのリストを持っているか。
- インシデント対応責任者は、インシデント発生時に送信されたすべての情報をどのように追跡し、より大規模なチームが利用できるようにするのか。
こうした状況で使用するツール、関与する人材、関連プロセスをテストするために、少なくとも年に 1 回は机上訓練を実施することを Talos IR では推奨しています。机上訓練とは、組織に合わせてカスタマイズされたシナリオの予行演習のことをいいます。環境に影響が及ばないよう、攻撃は紙の上でのみ行われ、担当チームがどのように対応するかを確認します。机上訓練は無害なので効果が薄いように思えるかもしれませんが、適切に行えば、インシデント対応計画を新たな視点で見ることができ、最新の情報が盛り込まれよくまとまっているドキュメントの有効性と改善が必要な部分、この両方に対する気づきが得られます。
内容を見直さない
インシデント対応計画は少なくとも年に 1 回、さらに環境内でソフトウェアまたはハードウェアに大きな変更があった場合にはその都度更新する必要があります。合併や買収など、組織の法的構造に変化が生じた場合も見直しが必要となります。重大なインシデントの終結時にインシデント対応計画を見直し、発生したインシデントに基づいて内容を調整するのも 1 つの手です。人事異動（チーム外や組織外へのメンバーの異動など）や IT 環境の変更があった場合も、定期的な見直しによって、対応計画が引き続き有効であることを確認できます。
IT に重点を置きすぎている
インシデント対応計画は、法務、コンプライアンス、人事、広報など、他の技術系以外のチームと協議して作成する必要があります。これらのチームと緊密に連携する必要がある具体的な例としては、従業員の個人データが影響を受けた場合、インシデントについて当局に通知する法的規制がある場合、または重大なインシデントについて公式声明を発表する必要がある場合などが挙げられます。
見落とされがちですが、インシデント対応計画の策定に加わるべきもう 1 つのチームは、サービスデスクチームです。サポート担当者はサイバーセキュリティ インシデントを適切にルーティングし、すぐにインシデント対応チームにエスカレーションできるでしょうか。影響を受けるユーザーが少ない場合でも、ランサムウェア、ワイパーマルウェア、ソーシャルエンジニアリングなどよくある攻撃について信頼性の高い兆候に気づけるようにトレーニングを受けているでしょうか。
インシデント処理の技術的な側面に重点を置きすぎると、不完全なドキュメントを作成してしまうことになりかねません。開発プロセスと最終ドキュメントの配布リストにサポートチームを加え、テストとトレーニング演習に参加してもらう必要があります。「子どもを育てるには村が必要」ということわざは、組織を守る場合にも当てはまります。
Talos IR は、NIS2 の要件を満たすための準備に関してお客様をサポートできます。次のサービスは、NIS2 指令の 1 つ以上の要件に対応しています。
- 準備：インシデント対応計画
、インシデント対応ハンドブック、インシデント対応準備アセスメント、ログ アーキテクチャ アセスメント - シミュレーション：パープルチーム
- トレーニング：机上訓練、サイバーレンジ
- ハンティング：侵害アセスメント、脅威ハンティング
- コア：緊急対応、Intel on Demand
NIS2 への準拠の達成をサポートする技術的対策を講じ手順を整備するには、新しいプロセスの作成とテックスタックの更新が必要になる場合があります。うかうかしていると時間はあっという間に過ぎてしまうので、まずは遵守する必要がある要件を確認し、来年中に達成するための実行可能な計画をまとめることから着手してはいかがでしょうか。
Tags:本稿は 2023 年 11 月 16 日に Talos Group
