復旧

復旧とは、システムを既知の安全な状態に復元し、復元前にバックアップが安全であるかまたはインシデントの影響を受けていないことを検証し、復元後にシステムが適切に動作していることを検証し、セキュリティイベントに関連する脆弱性に対処するプロセスです。

復旧の順序は、組織の要件によって異なります。復旧プロセスの一環として、ビジネスへの影響分析を実行して、少なくとも以下を決定する必要があります。

• ビジネスまたは依存関係の優先順位

• 復元プラン

• 認証と認可

「NIST SP 800-61 コンピュータセキュリティインシデント処理ガイド」には、次に示すような、システムを復旧するためのいくつかのステップが記載されています。

• クリーンバックアップからシステムを復元します。

  • バックアップがシステムへの復元前に評価されていることを確認し、感染がないことを確認し、セキュリティイベントの再発を防止します。

    バックアップは、ディザスタリカバリテストの一環として定期的に評価して、バックアップメカニズムが適切に動作していること、データの整合性が復旧ポイントの目的を満たしていることを確認する必要があります。

  • 可能であれば、根本原因分析の一環として特定された最初のイベントのタイムスタンプより前のバックアップを使用します。

• 自動化を使用した信頼できるソースからの再デプロイなど、システムをゼロから再構築します (場合によっては新しい AWS アカウントで)。

• 侵害されたファイルをクリーンバージョンに置き換えます。

  これを行う際には、細心の注意が必要です。復旧するファイルの安全性が既知であり、インシデントの影響を受けていないことを確認する必要があります。

• パッチをインストールします。

• パスワードを変更します。

  • 悪用された可能性のある IAM プリンシパルのパスワードが含まれます。

  • 可能であれば、最小特権戦略の一環として、IAM プリンシパルとフェデレーションのロールを使用することをお勧めします。

• ネットワーク境界のセキュリティを強化します (ファイアウォールルールセット、境界ルーターのアクセスコントロールリスト)。

リソースを復旧したら、学んだ教訓を取り入れてインシデント対応ポリシー、手順、ガイドを更新することが重要です。

要約すると、既知の安全な運用への復帰を容易にする復旧プロセスを実装することが欠かせません。復旧には時間がかかる場合があり、封じ込め戦略と密接に連携してビジネスへの影響と再感染のリスクのバランスを取ることが必要です。復旧手順には、リソースとサービス、IAM プリンシパルを復元し、アカウントのセキュリティレビューを実行して残余リスクを評価する手順を含める必要があります。