Skip to content

Latest commit

 

History

History
49 lines (36 loc) · 13.5 KB

ja.Playbook_Development_Guide.md

File metadata and controls

49 lines (36 loc) · 13.5 KB

プレイブック開発ガイド

このドキュメントは、情報提供のみを目的として提供されています。 本書は、このドキュメントの発行日時点におけるAmazon ウェブサービス (AWS) の現在の製品提供および慣行を表しており、これらは予告なしに変更される場合があります。 お客様は、本書に記載されている情報、および AWS 製品またはサービスの使用について独自に評価する責任を負うものとします。各製品またはサービスは、明示または黙示を問わず、いかなる種類の保証もなく「現状のまま」提供されます。 このドキュメントは、AWS、その関連会社、サプライヤー、またはライセンサーからの保証、表明、契約上の約束、条件、または保証を作成するものではありません。 お客様に対する AWS の責任と責任は、AWS 契約によって管理され、このドキュメントは AWS とお客様との間のいかなる契約の一部でもなく、変更もありません。

© 2021 Amazon ウェブサービス, Inc. またはその関連会社。 すべての権利予約。 この作品はクリエイティブ・コモンズ表示 4.0 国際ライセンスの下に提供されています。

この AWS コンテンツは、http://aws.amazon.com/agreement で提供される AWS カスタマーアグリーメントの条件、またはお客様とアマゾンウェブサービス株式会社、Amazon ウェブサービス EMEA SARL、またはその両方との間のその他の書面による契約に従って提供されます。

コードとしてのプレイブック:

  • プレイブックは、git リポジトリにマークダウン形式で保存する必要があります。
  • git リポジトリにアクセスできないプレイブックと共有するために、各 Playbook の印刷フレンドリーな自己完結型バージョンを作成します。
  • インシデント対応チームのメンバーは、git プロジェクトをブランチし、PC、VDI、ラップトップなどのローカル環境にクローンすることを許可することをお勧めします。
  • ブランチに改善が加えられたら、それらをレビューし、承認し、マスターにマージして提出してください。
  • git プロジェクトはドキュメントとコードをホストします。
  • プレイブックのガバナンスと展開を促進するために CD/CI パイプラインの使用を検討する。

プレイブックの構造:

  1. Threat: プレイブックによって対処された脅威を記述します
  2. Endgame: _ [*AWS クラウド導入フレームワーク (CAF) *] (https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf)_ および業界で受け入れられているセキュリティパターン (脆弱性評価や影響分析など) のセキュリティの観点に基づいて、プレイブックの望ましい結果について説明します。
  3. 応答手順: * [NIST 800-61r2-コンピュータセキュリティインシデント対応ガイド] (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) * に基づいて、イベントに応答するための手順を時系列順に説明します。 図 A を参照してください。
  4. シミュレーション [コード]: レスポンスを開始するアラートをトリガーするのに必要なインジケーターを生成するステップバイステップの手順を提供します。
  5. インシデントの分類、処理、および検出: [MITRE ATT&CK エンタープライズタクティクス] (https://attack.mitre.org/tactics/enterprise/) ごとにプレイブックを分類し、プレイブックの実行に必要なツールを列挙し、アラートを生成する検出に使用されるインジケータ（別名：所見）を列挙し、ログを生成します。指標を生成し、分析を容易にするために必要な情報源、および関係するチーム。
  6. インシデント処理プロセス: 対応の各分野について従うべき規範的ガイダンス。 これらは実行時順ではなく、3を通りながら参考用です。 レスポンスステップ。 応答プロセス全体を通して、実行されたすべてのアクションを文書化し、収集されたすべての証拠を既知のリポジトリにまとめ、インシデント対応チーム RACI に基づく適切な資格を持つことが重要です。 また、インシデント対応チームのメンバーが専門分野内のタスクに集中できるように、集中的なオーケストレーション機能を使用して、応答中に適切なコミュニケーションチャネルを用意することも不可欠です。 一元化されたオーケストレーション機能により、適切なコミュニケーションの流れを維持し、必要なすべてのアクティビティがビジネス知識と承認を得て実行されるようにします。
  7. 分析-アラートの検証: アラートの通知の内容は、ソース生成インジケータ (つまり「グラウンドトゥルス」) に対して直接検証する必要があります。 これは、少なくとも 2 つの理由で必要です。 まず、一般的に、重要なインシデントデータの意図しない変更を引き起こす可能性のあるインシデント対応チームに到達するまで、元の指標がさまざまなシステムを通過するにつれて変換されます。 次に、マシンまたはヒューマン構成エラーが原因で通知が生成された可能性があります。
  8. Analysis-アラートのトリアージ: アラートによって示されたインジケータに基づいて、解析を容易にするために、ビルドコンテキストの生成に使用されたログを検索します。
  9. Analysis-scope: 使用可能なアラート関連のログソースでエビデンスを検索して、アクターがイベントのライフサイクルを通じて実行したアクティビティを特定します。
  10. 分析-影響: アクターのアクティビティとその範囲によって影響を受けるワークロードとコンポーネントを特定します。 ビジネスへの影響を判断し、次のステップに優先順位を付けるために、より大きなインシデント対応チームと話し合う仮説を策定する。
  11. 封じ込め: 分析フェーズの進行中または終了時に、インシデントの封じ込め戦略を決定します。 適切な戦略は、範囲と影響に依存し、ワークロードの所有者によって承認されます。 封じ込めアクティビティは、インシデント対応中の影響を受けるワークロードの脅威モデリングおよび実際のコンテキストに合わせる必要があります。 封じ込めアクションの結果として、ダウンタイムやデータ破壊などの潜在的な担保効果を最小限に抑えるために、いくつかの異なる封じ込めオプションまたは補完的な封じ込めオプションを用意する必要があります。 このフェーズでは、証拠収集時の注意が守られなければなりません。 CloudTrail ログ、VPC フローログ、GuardDuty ログなど、分析中にフォレンジックスデータの集約が開始されますが、EC2 インスタンスのスナップショット、RDS データベースのバックアップ、Lambda トリガーなどのその他のアクティビティを防ぐためにサービスが再構成されるため、スナップショットとバックアップに最適な時間です。除去。
  12. 撲滅と回復: 敵によってプロビジョニングされたリソースは無効化されるか、完全に削除され、影響を受けるすべてのリソースの脆弱性と構成の問題が特定されます。 ワークロード所有者の承認後、すべてのリソースが適切に再構成され、セキュリティ更新が適用され、同一または類似のエクスプロイトによる成功の可能性が低減されます。 ワークロードのセキュリティポスチャの再評価が完了しました。 構成の変更とセキュリティ更新が適用された後、ワークロードのセキュリティ体制がビジネスに許容できないレベルのリスクをもたらす場合は、中長期的なアーキテクチャ変更に関する推奨事項を作成し、責任チームおよび責任チームによる評価のために提出する必要があります。
  13. インシデント後のアクティビティ: 以前のすべてのフェーズが完了した後、インシデントの詳細な分析が「学んだ教訓」セッションの形で実行されます。 インシデント対応タイムラインは、次のセキュリティインシデントの準備を強化するために必要な変更に焦点を当てて公開され、議論されます。 このフェーズでは、インシデント対応チームは、影響を受けるワークロードだけでなく、企業が所有するすべてのワークロードについて、ディレクティブ、予防、検出、および応答の制御（図 B を参照）を強化することに重点を置いています。

! [画像] (/images/nist_life_cycle.png)

図 A-インシデント対応ライフサイクル

! [画像] (/images/image-caf-sec.png)

図 B-AWS クラウド導入フレームワークのセキュリティ観点

開発プロセス:

  1. プレイブックが対処する脅威を選択し、1 で説明してください。 脅威セクション。 Playbook 読者がそれを理解するのに役立つ参考文献を必要なだけ多く提供してください。
  2. Playbook テンプレートのセクション 2 を確認します。 エンドゲームのセクション と変更を加えるか、そのまま維持する。 これらは、[CAF のセキュリティ観点] (https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf)、[AWS Well-Architected Framework のセキュリティ柱] (https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf)、[Amazon] など、AWS のセキュリティと業界パターンに基づいています。ウェブサービス:セキュリティプロセスの概要] (https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf)、[AWS セキュリティインシデント対応ガイド] (https://d1.awsstatic.com/whitepapers/aws_security_incident_response.pdf)、[NIST Special Publication 800-61r2 Computer Security Incident Handling Guide] (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)。
  3. セクション ```5 に記入してください。 インシデントの分類、処理、および検出を適切な情報で指定します。 後でこのセクションに戻ることができます。プレイブックの他のセクションを作成する過程で、新しいインジケータ、使用したいかもしれない他のツールなどを発見してしまった場合。
  4. 脅威の指標をトリガーする手順を定義します。 プロセス、AWS リソース、IAM プリンシパル、必要なポリシー、AWS CLI コマンド、AWS SDK ベースのコードなど、必要なコードを文書化します。できれば、シェルスクリプトまたはサポートされている言語コードプログラムにラップしてください。 CloudWatch Insights や Athena などの分析ツールを使用して、シミュレーションアクティビティによって生成されるさまざまなログを示すスクリーンショットを追加します。
  5. セクション 3 の下で応答ステップを開発する。 応答ステップ セクションでは、各ステップが属する NIST IR ライフサイクルフェーズを強調しています。 ステップは、影響を受けるワークロードの脅威モデルに合わせて時系列順に列挙する必要があります。 プレイブックの中で、時系列順は不変ではなく、イベントのコンテキストに応じて変更できることを明確にしてください。 影響を受けるワークロードをさらに損傷する可能性のあるアクションのリスクを最小限に抑えるために、確立された実行順序からの逸脱は、以前に承認された審査プロセスを経る必要があります。
  6. セクション 6 の NIST IR ライフサイクルの各フェーズをサポートする AWS CLI コマンドと Athena クエリを作成します。 インシデント処理プロセス。 一連のクエリとコマンドは、一般的な観点と、スクリーンショットの形式で文書化された出力から、各フェーズの要件を満たす必要があります。 コマンドは、インシデントレスポンダーのエンタイトルメントと同等または同等のロールを使用して、影響を受けるアカウントに対して実行されます。 クエリは、Athena の関連するログリポジトリに対して、少なくとも CloudTrail および VPC フローログで実行されます。 分析に必要なログが Athena を通じて利用できない場合は、SIEM やビッグデータソリューションなどの利用可能な分析ツールを使用してください。