# SEC10-BP02 インシデント管理計画を作成する
<a name="sec_incident_response_develop_management_plans"></a>

 インシデントへの応答、インシデント時の伝達、インシデントからの復旧に役立つ計画を作成します。たとえば、ワークロードと組織にとって起こる可能性が最も高いシナリオで、インシデント応答計画を作成してみましょう。内部および外部に伝達およびエスカレーションする方法を含めます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 インシデント管理計画は、セキュリティインシデントの潜在的な影響への対応、復旧、軽減に不可欠です。インシデント管理計画は、セキュリティインシデントをタイムリーに特定し、修復、対応するための体系的なプロセスです。

 クラウドには、オンプレミス環境と同じオペレーション上のロールと要件があります。インシデント管理計画を作成する際は、ビジネス成果とコンプライアンス要件と最も合致する対応および復旧戦略を組み込むことが重要です。例えば、米国の FedRAMP 準拠のワークロードを AWS で運用している場合は、 [『NIST SP 800-61 Computer Security Handling Guide』を遵守することが役に立ちます](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf)。同様に、ヨーロッパの PII (個人を特定できる情報) データを含むワークロードを運用しているときは、 [EU 一般データ保護規則 (GDPR) で義務付けられているようにデータレジデンシー関連の問題に対してどのように防御、対応するかといったシナリオを考慮します](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en)。

 AWS で運用するワークロードについてインシデント管理計画を策定する際は、 [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)から始め、インシデント対応に向けた多層防御アプローチを構築することを目指します。このモデルでは、AWS はクラウドのセキュリティを管理します。クラウド内のセキュリティについてはお客様の責任です。つまり、お客様はコントロールを保持するとともに、実装しようとするセキュリティコントロールに責任を持つということです。『 [AWS Security Incident Response Guide』(AWS セキュリティインシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) には、クラウド中心のインシデント管理計画を策定するための重要なコンセプトと基本的なガイダンスが記載されています。

 効果的なインシデント管理計画は、クラウド運用の目標に沿って継続的に繰り返し、最新の状態に保つ必要があります。インシデント管理計画を作成して進化させるにあたり、以下に記載の実装計画を使用することを検討してください。 
+  **インシデント対応の教育とトレーニング: ** 定義されたベースラインからの逸脱 (間違ったデプロイ、設定ミスなど) が発生した場合は、対応と調査が必要になる可能性があります。これを適切に行うために、自社の AWS 環境内でセキュリティインシデント対応に使用できるコントロールと機能を理解するとともに、インシデント対応に関与するクラウドチームの準備を整え、教育とトレーニングを行うプロセスを把握する必要があります。 
  +  [プレイブック](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) および [ランブック](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) は、インシデントへの対応方法のトレーニングで一貫性を確保するのに効果的なメカニズムです。まず、インシデント対応中に頻繁に実行する手順の最初のリストを作成し、継続的に繰り返しながら新しい手順の学習や採用を行います。
  +  スケジュールされた [ゲームデーをとおして、プレイブックとランブックを広めます](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)。ゲームデーの期間中、制御された環境でインシデント対応をシミュレーションします。それにより、チームは対応方法を思い出し、インシデント対応に関与する各チームがワークフローを熟知していることを検証できます。シミュレーションされたイベントの結果をレビューし、改善点を特定し、さらにトレーニングや追加ツールが必要か判断します。
  +  セキュリティは全員の任務と見なす必要があります。普段、ワークロードを運用するすべてのスタッフを関与させることで、インシデント管理プロセスの集合知を構築します。これにはビジネスのすべての側面、つまり、運用、テスト、開発、セキュリティ、ビジネスオペレーション、ビジネスリーダーが含まれます。 
+  **インシデント管理計画をドキュメント化する: ** アクティブなインシデントの記録、対応、進捗に関するコミュニケーション、通知の提供のためのツールとプロセスをドキュメント化します。インシデント管理計画の目標は、通常のオペレーションができるだけ迅速に復旧され、ビジネスへの影響が最小限に抑えられ、すべての関係者に情報が提供されることを検証することです。インシデントの例としては、ネットワーク接続の損失やパフォーマンス低下、応答しないプロセスまたは API、スケジュール済みだが実行されないタスク (パッチ適用の失敗など)、アプリケーションデータまたはサービスの利用不可、セキュリティイベントに起因する計画外のサービス中断、認証情報の漏洩、設定ミスによるエラーがあります (ただし、これらに限定されません)。 
  +  インシデント解決に責任を持つ主な所有者 (ワークロード所有者など) を特定します。誰がインシデントを管理するか、またどのようにコミュニケーションを取るかについて、明確なガイダンスを用意します。外部ベンダーなど複数の当事者をインシデント解決プロセスに関与させる場合は、インシデント解決で求められる、さまざまなチームやスタッフの役割と責任を記述した *責任分担 (RACI) マトリックス*を作成することを検討します。

     RACI マトリックスには以下を記述します。 
    +  **R: ** *Responsible * - 作業を行いタスクを完了する実行責任者。
    +  **A: ** *Accountable * - 指定されたタスクの正常な完了に対して最終的な権限を持つ説明責任者またはステークホルダー。
    +  **C: ** *Consulted * - 意見を求められる相談先。一般的には対象分野の専門家。
    +  **I: ** *Informed * - 進捗について通知を受ける情報提供先。多くの場合、タスクの完了や成果物についてのみ通知される。
+  **インシデントを分類する: ** インシデントを定義し、重大度と影響度のスコアに基づき分類することで、インシデントをトリアージして解決するための体系的なアプローチが可能となります。次の推奨事項は、インシデントを数値化するための *影響と解決の緊急マトリックス* を説明するものです。例えば、影響度: 低、緊急度: 低のインシデントは、重大度: 低のインシデントと見なされます。 
  +  **高 (H): ** ビジネスは多大な影響を受けます。AWS リソースに関連するアプリケーションのクリティカルな機能は使用できません。本番システムに影響を及ぼすほとんどのクリティカルイベントのために用意されています。インシデントの影響は急速に拡大し、修復には時間的制約があります。 
  +  **中 (M): ** AWS リソースに関連するビジネスサービスまたはアプリケーションは、適度に影響を受けますが、パフォーマンスが低下した状態で機能します。サービスレベル目標 (SLO) に寄与するアプリケーションは、サービスレベルアグリーメント (SLA) の範囲内で影響を受けます。システムは、能力が低下した状態で機能することができ、財務的影響および評判上の影響はあまりありません。 
  +  **低 (L): ** AWS リソースに関連するビジネスサービスまたはアプリケーションの非クリティカルな機能が影響を受けます。システムは、能力が低下した状態で機能することができ、財務的影響および評判上の影響は最小限にとどまります。 
+  **セキュリティコントロールを標準化する: ** セキュリティコントロールを標準化する目的は、オペレーションの結果に関する一貫性、トレーサビリティ、再現性を実現することです。インシデント対応に欠かせない重要なアクティビティについて標準化を推進します。以下に例を挙げます。 
  +  **アイデンティティとアクセスの管理: ** データへのアクセスを制御し、人間とマシンアイデンティティの両方の権限を管理するためのメカニズムを確立します。シングルサインオンとロールベースの権限を含むフェデレーテッドセキュリティを使用して、貴社独自のアイデンティティとアクセスの管理をクラウドに拡張し、アクセス管理を最適化します。アクセス管理を標準化するためのベストプラクティスの推奨事項と改善計画については、 [セキュリティの柱に関するホワイトペーパーの「ID とアクセス管理」のセクション](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) を参照してください
  +  **脆弱性管理: ** AWS 環境で、攻撃者がシステムを侵害、悪用するために用いる可能性のある脆弱性を特定するためのメカニズムを確立します。予防的コントロールと発見的コントロールの両方をセキュリティメカニズムとして実装し、セキュリティインシデントの潜在的な影響に対応し、その影響を緩和します。脅威のモデル化などのプロセスを、インフラストラクチャ構築およびアプリケーションデリバリーライフサイクルの一環として標準化します。
  +  **構成管理: ** 標準構成を定義し、AWS クラウド にリソースをデプロイする手順を自動化します。インフラストラクチャとリソースの両方のプロビジョニングを標準化すると、間違ったデプロイによる設定ミスや意図しない人的な設定ミスのリスクの軽減に役立ちます。このコントロールを実装するためのガイダンスと改善計画については、『運用上の優秀性の柱』のホワイトペーパーの [「設計原則」のセクション](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) を参照してください。
  +  **監査コントロールのためのログ記録と監視: ** リソースの障害、パフォーマンス低下、セキュリティの問題を監視するためのメカニズムを実装します。これらのコントロールを標準化すると、システムで発生したアクティビティの監査証跡が提供され、問題のタイムリーなトリアージと修復に役立ちます。SEC04 [(「セキュリティイベントは、どのように検出して調査するのですか?」) のベストプラクティスは、](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) このコントロールを実装するためのガイダンスを提供しています。
+  **オートメーションを使用する: ** オートメーションにより、インシデントのタイムリーで大規模な解決が可能となります。AWS は、インシデント対応戦略の枠組みの中で自動化を行うサービスを複数提供しています。オートメーションと人の介入との適切なバランスを見つけることに重点を置きます。プレイブックとランブックでインシデント対応を構築しながら、繰り返し可能なステップを自動化します。AWS Systems Manager Incident Manager などの AWS サービスを使用して [IT インシデントの解決を迅速化します](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/)。デベロッパーツールを [使用して、](https://aws.amazon.com/devops/) バージョン管理を提供し、[Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) と Infrastructure as Code (IaC) のデプロイを自動化し、人間の介入を排除します。該当する場合は、Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、AWS Config、Amazon Macie などのマネージドサービスを使用して検出とコンプライアンス評価を自動化します。Amazon DevOps Guru などの機械学習を使用して検出機能を最適化し、異常な動作パターンの問題が発生する前に検出します。
+  **根本原因分析と、教訓から得られたアクションを実施します。** 過去のインシデント対応レビューの一環として、教訓を取り込むためのメカニズムを実装します。インシデントの根本原因により、より大規模な検出、設計上の欠陥、設定ミス、再発の可能性が明らかになった場合、問題として分類されます。そのような場合、問題を分析および解決して、通常のオペレーションの中断を最小限に抑えます。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Security Incident Response Guide (AWS セキュリティインシデント対応ガイド)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST: Computer Security Incident Handling Guide ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

 **関連動画:** 
+  [AWS のインシデント対応とフォレンジックの自動化 ](https://youtu.be/f_EcwmmXkXk)
+ [ ランブック、インシデントレポート、インシデント対応の DIY ガイド ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS 環境のセキュリティインシデントの準備と対応 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **関連サンプル:** 
+  [ラボ : Jupyter を使用したインシデント対応プレイブック - AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) 
+ [ ラボ: Incident Response with AWS Console and CLI (AWS コンソールと CLI を使用したインシデント対応) ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)