攻撃者は日々その能力を高め、絶えず戦術を進化させています。実際、インシデントやデータ漏洩の件数は増えてきており、たとえば ITRC の発表によると 2021 年のデータ漏洩の件数は現時点ですでに 2020 年の件数を上回っています。このような状況では、事が起きてから対応するのではなく、事前の備えが重要です。ホストベースのウイルス対策やファイアウォール、セキュア Web ゲートウェイなど従来の保護機能の多くは、何かインシデントが発生した場合に防御するというものです。インシデントを想定した対応計画やポリシーが必要とされていますが、企業のサイバーセキュリティ対策ではその点が見落とされがちです。
サイバーセキュリティ インシデントへの対応方針をポリシーとして定義し、インシデントへの対処手順を計画として策定しておけば、インシデントに見舞われても最小限のコストとダウンタイムで解決できるようになります。
これは企業としての対応力が問われる事態に陥ったときに特に重要になります。その例としては猛威を振るっているランサムウェアへの感染、サプライチェーンの侵害、重大なデータ漏洩などがあります。重大なインシデントが発生したときに対処手順や責任者が明確になっていないとどうなるかは簡単に想像がつきます。そこで策定しておきたいのがインシデント対応計画（IRP）です。
IRP は企業のインシデント対応の枠組みとなるドキュメントであり、秩序だったやり方でインシデントに対応する方法を定めています。通常業務に復帰することを最終目標として、同じ方法で実行できる一連のアクションを策定することで運用コストとミスを最小限に抑えます。
IRP は企業が行うインシデント対応（IR）のあらゆる領域をカバーする必要があり、策定の際は以下の項目を検討しなければなりません。
- インシデントの重大度や分類など、インシデントの定義を行う。そうすることで、発生した事案を素早く正確に分類できるようになります。インシデントの定義は枠組みの中核となる部分であり、これに基づいてインシデント対応プロセスのその他のさまざまな要素が決定されます。
- IR プロセスを定め、IR の実施方法を概要レベルと詳細レベルで示す。
- インシデント対応チームのメンバーの役割と責任を定める。これらのメンバーがプロセス全体を最初から最後まで支援します。
- エスカレーションパスと報告経路を決定する。企業が準拠している規制や枠組みによって決まるものもあります。規制されたデータを取り扱っている企業はこれが特に重要になります。
- 影響を受けたシステムから収集する必要がある情報の一覧を作成する（ネットワークログ、ホストベースのアーティファクト、ファイルサンプルなど）。
- インシデント発生時に支援を求めたり緊急対応を依頼したりすることができる適切な連絡先一覧とスタッフの割り当てを作成する。
- 必要に応じて、インシデント対応の重要な局面を支援できるベンダーと協力関係を結び、IRP において一定の役割を担ってもらう。
このすべての領域をカバーすることで、それだけ見ればその企業の IR についてあらゆることが分かるドキュメントを作成できます。IR に必要なドキュメントは IRP だけではありませんが、問題が発生したときに役立つ中心的なドキュメントになります。IRP を補足するために IR プレイブックなどの追加のドキュメントを使用して特定の処理手順に関する詳細を示すことができます。
計画が必要な理由
IRP が本当に必要なのかまだ疑っている方も多いかもしれません。確かに、計画やポリシーを策定しなくても IR のあらゆる側面を実施することができます。IRP を策定することなく、セキュリティチームが独自の裁量でインシデントを調査し、感染したホストを封じ込め、修復を行ってはならないというわけではありません。これはインシデント対応のアドホックアプローチと呼ばれており、小規模な企業では有効な場合があります。
しかし、アドホックな IR の最大のリスクは正式なプロセスがない点にあります。この方法は完全に個人に依存しています。正式なプロセスがないということは、その状況で最善だと思ったアクションを誰でも自由に行えるということです。妥当性が認められるアクションが実施されるとは限りません。このようなアプローチでは往々にして文書化が行われず、コミュニケーションも不足して、同じアクションが繰り返されることになります。重大な事態が発生しているときに 2 人のインシデント対応担当者がたまたま同じインシデントに取り組み、同じアーティファクトを調査し、同じアクションを実施して封じ込め、貴重な時間を無駄遣いするといったことが起きかねません。またインシデントは昼夜を問わずいつ発生するか分からないことを考えると、これはさらに重要になってきます。すべての手順を文書化して間違いが発生しにくいようにしておけば、日曜日の午前 3 時に駆けつけた担当者もずいぶん助かることでしょう。
IRP における各部署の役割
インシデントは多方面に影響をもたらすので、さまざまなチームがプロセスに従って復旧と封じ込めにあたる必要があります。たとえば IT チームは通常、システムを復元し、バックアップからの復旧をモニタリングします。また法務部は想定される侵害に応じた法規制の影響を評価します。各部署の一般的な役割は次のように分類できます。
計画はテストが必要
IRP を策定するもう 1 つの利点は、テストとトレーニングを IR プロセスで実施できるようになることです。新人アナリストや経験の浅いアナリストは IRP を参照することでインシデント発生時にすべきことを把握できます。IR の実施方法を明確に示した IRP があれば IR チームの新しいメンバーもすぐに業務に馴染むことができます。インシデントが発生したときは IRP の手順を参照しながら対応することでミスが発生しにくくなります。
トレーニング演習も、策定した計画に基づいて実施します。具体的には、机上演習、パープルチーム演習、レッドチーム演習、ペネトレーションテストなどです。演習時のアナリストのアクションと IRP で規定された実施すべき事柄を比較することでフィードバックを提供できます。ライブテストを実施しないと気付かないような問題点がプロセスに潜んでいることもあります。たとえばコミュニケーションプロセスに欠陥があることが演習を通じて明らかになることがあります。また演習を行うとプロセスの習熟が進みます。この体験はドキュメントを読んだだけでは得られません。こうした演習は実際のインシデントに近い状況を再現することを目的としています。たとえば Cisco Talos インシデント対応チーム（CTIR）が提供している机上演習
により、自社の IR 計画に潜む欠陥や改善点を発見できます。最後に、実際にインシデント対応を行った場合はインシデント後の活動として得られた教訓をまとめ、事後評価を実施して、その結果を IRP に反映させる必要があります。そうすることで、IRP の IR 機能が最新の状態に保たれます。
IRP の策定を始める
IRP を策定するには数多くの考慮事項を検討する必要がありますが、CTIR ではそのための支援を行っています。たとえば事業活動が停止するようなインシデントに備えて事業継続に重点を置いた対応計画を作成することができます。また IR プラクティスを導入してまだ日が浅いというケースでは、まずは定型的な計画を策定し、チームの成長に合わせて内容を充実させていくこともできます。ただし、これにはさまざまな要因が関係しており、実施計画を策定する前に次のような手順を行う必要があります。
- 資産の洗い出しを行って、IRP で保護する必要があるデータとシステムを特定する。ビジネスのあらゆる要素を同時に復旧するのは無理なので、優先順位を付ける必要があります。これは資産、プロセス、資産に保存されているデータの重要度に基づいて行います。
- 環境内に存在するデータの種類を特定する。規制されたデータに重点を置きます。PII（個人識別情報）と PHI（個人健康情報）には厳格な報告要件と保護要件があり、違反すると厳罰が科されます。
- 緊急時の対応を支援してもらう外部ベンダーが決まっている場合は、そのベンダーの対応プロセスと連絡方法を把握する。電話番号や電子メールなどの連絡先情報を対応計画に含めます。またそうした外部ベンダーに要請を行う権限がある責任者も決定します。
- 従業員と面談し、緊急対応時に期待される役割と責任を理解していることを確認する。
- ワークフォースの継続性計画を策定して IRP に含める。インシデントは定休日も営業時間も関係なく発生します。つまり、スタッフのローテーションや指揮系統などのプロセスは、継続的な運用に対応できるようにしておかなければなりません。従業員は休憩や睡眠を取る必要があるため、復旧に対応するスタッフを把握しておくことが重要です。
- バックアップを使用して重要なシステムを稼働できるようにしておく。そうすることで、システムがダウンした場合は迅速な復元手順で再稼働できるようになります。バックアップ手順を定期的にテストし、また BCP の一環としてもテストを行います。IR 計画には運用の復旧に関係する適切なリファレンスとプロセスを含めます。
- バックアップと復旧の手順を実行する作業プロセスを定め、IRP が発動されたときに慌てることなく対応できるようにする。
- フォレンジックの証拠を収集する作業プロセスを定める。多くの IR ベンダーでは調査のためにその証拠が必要になります。
策定を終えたら
策定した IRP は定期的にレビューまたは更新していますか？IR プロセスは机上演習、レッドチーム演習、ペネトレーションテストなどでテストしましたか？重大なインシデントの後に事後評価のプロセスや得られた教訓をまとめるプロセスを実施していますか？答えが「いいえ」であれば、CTIR が提供している IRP レビューおよび更新サービスをご検討ください。
プロセスをレビューして更新することは非常に重要です。IRP は生きたドキュメントであり、企業とともに成長し、絶え間なく変化する脅威の状況に対応していく必要があるからです。今日のダイナミックな IT 環境では埃をかぶった IRP は役に立ちません。定期的にテストと更新を行って IRP の価値を維持し続ける必要があります。
- CTIR は、ほぼすべての業界の数え切れないほどのお客様のために IRP を策定してきました。中には、それまで IR 計画やポリシーを策定したことがなく、IR を正式に導入するプロセスを開始したいと希望されている新しい企業もありました。CTIR は、IR の最も重要な考慮事項を盛り込んだ計画をそのお客様と協力して作り上げました。計画には、柔軟に変更できる余地を残し、社内のプロセスとテクノロジーを反映させました。
- 規制されたデータを扱う業界のサービスプロバイダーのお客様からご相談を受けたこともあります。すでに IRP はあるものの情報不足で詳細なガイダンスが欠けていると感じておいででした。CTIR はより良い IRP を策定するためにまず既存の IR 関連ドキュメントを確認し、元の IRP を基盤にしてより包括的な計画を作り上げました。
まとめ
サイバーセキュリティ部門は、インシデントの検出、対応、復旧を行って企業が損害を被らないようにしています。セキュリティ担当者の優れた対応によって早い段階で攻撃を阻止または検出し、機密性の高いシステムを守ることができれば理想的なのですが、いつもそのように上手くいくとは限りません。サイバーセキュリティ部門にはあらゆる攻撃を阻止することが期待されていますが、攻撃が一度でも成功すればインシデントは発生してしまいます。
したがって、すべての攻撃を阻止できない可能性があることを前提として受け入れる必要があります。100% 効果的な防御システムを作り上げることはできません。攻撃者が弱点を見つけて防御を回避するかもしれませんし、悪意のある内部関係者が正当なアクセス権を使用してシステムを攻撃するかもしれません。完璧なセキュリティ防御は存在しないことを謙虚に認める必要があります。
インシデントに備えて計画を立てておくことは、サイバーセキュリティ対策の重要な部分となっています。インシデント計画は実行性があり、即座に実施できるものであればよく、複雑なものを目指す必要はありません。
Cisco Talos インシデント対応チームは、インシデントへの対応、侵害からの復旧、インシデント対応計画の策定において豊富な経験を持っています。お客様にはさまざまなサービスを提供しており、専門知識を活かした計画の策定もその 1 つです。またリアルなシナリオに基づく机上演習も提供しています。演習サービスをご利用いただくことで、インシデントが実際に発生する前に計画をテストして弱点を特定することができます。
Talos インシデント対応チームのアナリストは緊急時だけでなく、インシデントに備えて対応を強化したい場合にもご相談に応じます。「備えあれば憂いなし」という人生訓は企業のサイバーセキュリティ対策にも当てはまります。
本稿は 2021 年 11 月 04 日に Talos Group
Authors