CIS Control 17. インシデント対応の管理

Center for Internet Security (CIS) は Critical Security Controls（CSCs）を提供しており、組織がサイバーセキュリティを改善するのに役立ちます。CIS CSC 17 では インシデント対応と管理 を扱います。（CIS コントロールの初期バージョンでは、CIS コントロール におけるセキュリティインシデントの取り扱いは Control 19 でカバーされていました。）

CIS CSC 17 は、攻撃やその他のセキュリティインシデントに対応するための計画をどのように策定するかに焦点を当てており、関連する各種タスクの担当者に対して明確な役割を定義することの重要性などが含まれます。

これらの推奨事項は、対応能力の向上に役立ちます。 ただし、企業はより良いセキュリティ計画とインシデント対応のために、Council of Registered Security Testers (CREST) Cybersecurity Incident Response Guide を活用することもできます。

インシデント対応と管理統制の「保護策」を掘り下げる前に、まず「インシデント」として該当し得るものを理解することが重要です。

セキュリティイベントとセキュリティインシデント：違いは？

セキュリティイベントとセキュリティインシデントは、情報セキュリティの言葉では別のものです。セキュリティインシデントは通常、適切なタイミングで対応されなかったセキュリティイベントから発生します。たとえば、GPO やセキュリティグループのように、アクセス制御の構成に不適切な変更が加えられることはセキュリティイベントです。ハッカーがその構成変更を悪用して情報システムからデータを盗み出すと、それがセキュリティインシデントになります。インシデントはイベントよりもはるかに頻度が低い一方で、被害ははるかに大きくなり得ます。単純に言えば、インシデントとは、損害につながる結果を伴うイベントです。

効果的なインシデント対応管理（incident response management）を行うには、指定されたチームが、指定要員や復旧能力を含む、すべての既知のセキュリティインシデントに対する詳細な対応計画を作成すべきです。しっかりした計画があると、データの完全性のようなセキュリティ上の課題への対応に役立つだけでなく、データ保護の要件やその他の規制への準拠（compliance）にもつながります。

以下は、CIS のインシデント対応コントロール（incident response control）の9つの保護策です。

17.1 インシデント対応の管理担当者を指定する

この保護策では、インシデント対応と復旧の取り組みを調整し、記録することを含め、インシデント処理プロセスを管理するために、一次窓口とバックアップを指定することを推奨しています。この指定は、毎年見直すとともに、セキュリティに重大な影響を与えるような重要な変更があった場合にも見直すべきです。

主要となる連絡窓口（key contact）は、社内の従業員であっても、第三者ベンダーであっても構いません。どちらのアプローチにも利点と欠点があります。主要な管理担当者として従業員を置けば、対応管理が組織の内側で行われることを確保できますが、組織の規模によっては、その取り組みが1人の従業員には負担過大になる可能性があります。セキュリティ管理に特化した第三者であれば、セキュリティインシデントをより適切に処理できる場合があります。リスク評価やインシデント対応のために第三者を指定するのであれば、当該保護策では、監督を提供するために組織内に少なくとも1名の人員を置くことを推奨しています。

17.2. セキュリティインシデント報告のための連絡先情報を確立し、維持する

セキュリティインシデントに関する情報を受け取るべきすべての関係者について、正確な連絡先情報を維持することが重要です。これらの関係者の連絡先は、容易に確認でき、迅速にアクセスできる状態にしておく必要があります。リストは優先度に基づいて並べ替えることができます。

このリストには通常、対応管理に責任を負う担当者や、重要な意思決定を行う権限を持つ担当者が含まれます。インシデント対応チームは、法執行機関、パートナーとなるベンダー、サイバー保険の提供者、または一般の人々に対して情報提供が必要になる場合もあります。

インシデント発生時に、関係者へ速やかに連絡して情報を通知できる仕組みを用意しておく必要があります。インシデント通知プロセスを自動化することも有効です。

通知がすべての関係者に確実に届くよう、連絡先情報は年1回以上、必要に応じてより頻繁に更新する必要があります。

17.3. 事故（インシデント）を報告するための企業全体のプロセスを確立し、維持する

前の保護策は 誰に インシデントに関する情報を伝えるべきかを扱っています。 この保護策は どのように インシデントを報告すべきか、つまり報告の期限、報告のための仕組み、報告すべき情報（インシデントの種類、時間、脅威レベル、影響を受けたシステムやソフトウェア、監査ログなど）を含めて明確にします。

文書化された報告ワークフローがあることで、インシデントを知った人が、適切な担当者へタイムリーかつ効果的に連絡しやすくなります。このプロセスは全従業員が利用できるようにし、またセキュリティに影響を与える可能性のある重大な変更が発生した場合はもちろん、毎年見直しを行う必要があります。

17.4. インシデント対応プロセスを確立し、維持する

この保護策では、役割と責任、コミュニケーションおよびセキュリティ計画、ならびにコンプライアンス要件を定義することで、インシデント対応のロードマップを作成する必要があります。割り当てられたタスクや明確な指示がない場合、実際には誰も対応していないにもかかわらず、関係者は別の誰かが特定のタスクを処理していると考えてしまう可能性があります。

対応プロセスは、事件に関連するサイバー脅威を監視・特定すること、事件の取り扱いにおける目的を定義すること、損害を防止する、または資産を復旧するために行動することなどを含め、概ねの手順を広く示す必要があります。 多くのインシデント対応チームでは jump kits を使用します。これには、プロトコルアナライザのようなデジタルフォレンジックソフトウェアに加え、コンピューター、バックアップデバイス、カメラ、携帯型プリンタなど、インシデントの調査・対応に必要なリソースが含まれます。

通常、最初のステップは、適切な対応手順を実施できるようにインシデントの性質を確認することです。明確な目的を念頭に置くことで、チームは脅威を遅らせるための取り組みを行えます。その後、文書化されたアクションプランに基づいて、インシデントを処理し、発生した損害を元に戻すための適切な手順を実行します。

このプロセスは年に1回、またセキュリティに影響を与え得る重要な変更があった場合には、その都度見直しを行う必要があります。

17.5. 重要な役割と責任の割り当て

前述の保護策で概説したとおり、インシデント対応者は対応手順における自分の役割を理解しておく必要があります。必要に応じて、さまざまな個人またはチームに主要な役割と責任を割り当てます。これには、セキュリティチーム（インシデント対応者）、システム管理者、法務担当者、公的広報（PR）および人事（HR）チームのメンバー、アナリストなどが含まれる場合があります。もちろん、サイバーセキュリティインシデントが発生した場合は、セキュリティおよびITチームが責任の大部分を担います。しかし、法務部門や人事部門のようなその他の重要な担当者も、自分たちの機能を理解しておくべきです。

役割とそれに対応する責任の一覧は、毎年見直し、必要に応じて更新し、また重要な変更が発生した場合にも見直しと修正を行うべきです。

17.6. 事故対応中のコミュニケーションの仕組みを定義する

インシデントの報告と評価において、コミュニケーションは非常に重要です。他の保護策では 何を 伝えるのか、 誰に 伝えるのかを説明していますが、本保護策では どのように 伝えるかを示します。電子メールや電話のような、あらかじめ定義されたコミュニケーション手段（チャネル）があるべきです。

また、バックアップ（代替）計画も定義しておくべきです。たとえば、重大なインシデントにより電子メールでの連絡が不可能になる場合があります。したがって、必要な関係者に連絡し、インシデント対応の状況に関する最新情報を提供するための別のコミュニケーション手段があるべきです。

17.7. 定期的にインシデント対応の演習を実施する

また、主要な担当者を対象に日常的なインシデント対応の演習とシナリオを実施することで、現実のインシデントに備えることも重要です。これらの演習では、コミュニケーションチャネル、ワークフロー、調査など、インシデント対応計画と手順のさまざまな側面をテストし、監査します。たとえば、組織における重要な情報の流れを妨げるネットワークインシデントへの対応を練習してください。これらの演習は少なくとも年に1回実施します。

チームは NIST Technical Guide to Security Testing and Assessment を使って演習の手順（ドリル）を作成できます。

17.8. インシデント後のレビューを実施する

すべてのインシデントの後、組織はインシデントそのものと自社の対応の両方を調査する必要があります。フォローアップすべき行動やミスを特定するために、この分析を実施し、インシデント後のレポートを作成する責任者を指名してください。

インシデント後のレポートでは、例えば次のような質問に答える必要があります。

• 一体何が起きたのでしょうか？
• 原因は何でしたか？
• 責任者はどのように対応しましたか？
• 対応にはどれくらいの時間がかかりましたか？
• 対応手順は適切でしたか？
• より良い対応は何だったのでしょうか？
• インシデントレポートに記載された情報は十分でしたか？
• 別のやり方として考えられたことは何でしょうか？
• 今後このようなインシデントを防ぐために、どのような対策が可能でしょうか？

17.9. セキュリティインシデントの閾値を確立し、維持する

このセーフガードは、組織がセキュリティインシデントとセキュリティイベントを区別するのに役立ちます。異なるインシデントとその影響を定義することで、組織はリソースを軽微な異常イベントだけでなく、重要なインシデントに確実に振り向けられます。さらに、インシデントの優先順位付けの仕組みを作ることにもつながり、対応者が「いつ反応すべきか」および「どのように対応すべきか」を把握できるようになります。

インシデントを特定し分類することで、今後の対応手順を標準化できます。組織は、インシデントに該当する新たな社内および社外の脅威を含めるように、閾値（基準値）を更新する必要があります。

まとめ

CIS CSC 17 の9つのセーフガードは、役割の割り当て、連絡先管理、シナリオ演習、インシデント分析とドキュメント化などを含む、健全なインシデント対応管理の実装を支援します。