AWS Security Incident Response: インシデント対応ライフサイクルを加速するためのお客様の取り組み

本ブログは 2025 年 7 月 24 日に公開された AWS Blog “AWS Security Incident Response: The customer’s journey to accelerating the incident response lifecycle” を翻訳したものです。

2025 年 8 月 1 日: この記事は、AWS WAF と AWS Shield への誤った言及を削除するために再公開されました。

効果的なセキュリティインシデント対応プログラムを構築し、維持するうえで、組織が直面する課題は増え続けています。IBM と Morning Consult の調査によると、セキュリティチームは 2 つの大きな課題に直面しています。1 つは、リソースの制約とアラート疲れにより、50% を超えるセキュリティアラートが未対応のままになっていることです。もう 1 つは、誤検知 (フォールスポジティブ) が調査時間の 30% を占め、真陽性 (トゥルーポジティブ) と判定された脅威への対応が遅れていることです。

調査レポート「2024 IBM Cost of a Data Breach Report」によると、組織がセキュリティイベントを特定して封じ込めるまでに、平均 258 日を要していました。同レポートでは、SOC (セキュリティオペレーションセンター) チームの半数近くが、調査時点までの 2 年間で検出と対応にかかる時間が長くなったと報告しています。さらに 80% が、手動での脅威調査が対応時間に大きく影響していると回答しています。

こうした課題がある一方で、「2024 IBM Security Services Benchmark Report」によると、成熟したインシデント対応能力を持つ組織では、平均解決時間 (MTTR) が 50% 短縮され、インシデントあたり最大 58% のコスト削減を実現しています。これらの改善は、脅威の検出と封じ込めを加速する自動化されたワークフロー、統合ツール、効率化されたコミュニケーションプロセスの導入によってもたらされています。

この記事では、実環境を想定したシナリオを通じて、AWS Security Incident Response がインシデント対応ライフサイクルのあらゆるステップを加速し、すぐに効果をもたらす仕組みを紹介します。また、Amazon GuardDuty、AWS Security Hub、AWS Systems Manager といった他の AWS ネイティブサービスとの統合方法や、サードパーティーによる脅威の検出結果を取り込み、自動化されたモニタリング、トリアージ、封じ込めの機能に組み込む方法についても説明します。

AWS Security Incident Response による支援

AWS Security Incident Response は、2024 年 12 月にリリースされた Tier 1 サービスです。お客様向けに専用に構築された AWS ネイティブのセキュリティインシデント対応ソリューションであり、検出と対応 (GuardDuty と Security Hub)、管理とガバナンス (Systems Manager) の分野の他の AWS サービスと組み合わせることで、より大きな効果を発揮します。また、AWS Security Incident Response は、サービス固有のパートナースペシャライゼーションプログラムを通じて AWS パートナーとも統合されています。詳細については、AWS Security Incident Response のドキュメントを参照してください。

AWS Security Incident Response は、セキュリティイベントの発生前、発生中、発生後を通じて効率的なインシデント管理機能を提供し、セキュリティポスチャを強化することで、既存のサービスを補完します。

主な課題

AWS Security Incident Response は、次の 3 つの一般的な課題に対応します。

• アラート疲れ: 自動化されたモニタリングとインテリジェントなトリアージにより、アラート疲れを軽減し、セキュリティ調査を加速できます。誤検知が減ることで、セキュリティチームの燃え尽きの防止にも役立ちます。
• アクセスとコミュニケーションの分断: AWS マネジメントコンソールのアクセス許可管理を簡素化し、インシデント対応チームのコミュニケーションを一元化することで、アクセスの分断に関する問題を解決できます。
• セキュリティスキルのギャップ: 認証情報の侵害、データ流出、ランサムウェアなどのインシデントに対応する AWS のセキュリティエキスパートに 24 時間 365 日アクセスできるため、クラウドセキュリティに関するスキルのギャップを埋めることができます。AWS Security Incident Response サービスを利用することで、セキュリティチームは目の前のセキュリティ課題に対処しながら、戦略的かつ長期的な備えと運用の改善にも引き続き注力できます。

サービスの統合

AWS Security Incident Response は、AWS のセキュリティサービスを補完し、それらと統合することで、包括的なインシデント対応機能を提供します。このサービスは、次のものとシームレスに連携します。

• 検出サービス: GuardDuty、Security Hub
• 管理ツール: Systems Manager
• サードパーティーソリューション: Security Hub の統合機能と AWS Security Incident Response パートナースペシャライゼーションプログラムを通じて連携

訳注: 本記事で説明している AWS Security Hub は、翻訳時点 (2026 年 10 月) では AWS Security Hub CSPM に名称が変更されており、同じ名前の新しい AWS Security Hub が別途提供されています。AWS Security Incident Response は、サードパーティーの検出結果を AWS Security Hub CSPM 経由で取り込みます。参照: 「ほぼリアルタイムの分析とリスクの優先順位付けが可能な AWS Security Hub が一般公開されました」、「ステップ 4: 既存のツールと統合する – AWS Security Incident Response ユーザーガイド」

この統合により、組織のクラウドジャーニー全体を通じて、セキュリティイベントにかかる時間、コスト、影響を最小限に抑える効率的なインシデント対応機能を構築できます。また、人員の追加、トレーニング、ツールのメンテナンスへの投資の削減にも役立ちます。

独自の機能

AWS Security Incident Response サービスでは、次のものが提供されます。

• AWS Security Incident Response Engineering (SIRE) チームの専門知識
• API とコンソールを通じて利用できるツール
• セキュリティインシデントに対処するための効率化されたプロセス

前提条件

この記事で説明する機能を実装する前に、次の条件を満たしていることを確認してください。

• 適切な AWS Identity and Access Management (IAM) のアクセス許可を設定済みであること
• インシデント対応チームの連絡先を設定済みであること
• 通知チャネルを設定済みであること
• (オプション) アカウントと AWS リージョンで GuardDuty を有効化済みであること
• (オプション) アカウントとリージョンで Security Hub を有効化済みであること
• (オプション) 自動アクションに必要な AWS CloudFormation StackSets をデプロイ済みであること

これらの前提条件を満たしておくことで、このサービスの自動検出、トリアージ、対応の機能を最大限に活用できます。

このサービスは、独自のサービスインフラストラクチャ内で自動化されたモニタリングと分析の機能を提供しており、GuardDuty と Security Hub の検出結果を自動的にトリアージできます。

AWS アカウントで自動封じ込めアクションを実行するには、まず必要な CloudFormation StackSets をデプロイし、適切な IAM アクセス許可を設定する必要があります。これにより、このサービスの検出機能を活用しつつ、環境内で実行される自動アクションを完全に制御できます。この自動化は、既知の CIDR 範囲 (ネットワークを定義する特定の IP アドレス範囲) や IP アドレスなど、お客様が設定する変数に基づいてカスタマイズできます。また、GuardDuty の抑制ルールを実装して、誤検知やアラートの量を減らすこともできます。その結果、このサービスは、既存のセキュリティインシデント対応プログラムやツールを補完する強力な手段となります。

AWS Security Incident Response のセットアップ

クラウド管理者は、AWSSecurityIncidentResponseFullAccess のアクセス許可を使用して、サービス内にインシデント対応チームを設定済みです。このサービスは、チームに追加された個人、パートナーまたはマネージドセキュリティサービスプロバイダー (MSSP)、その他の連絡先に通知を送信します。これにより、迅速にエスカレーションして必要な関係者にアラートを送り、イベントに対応できます。

ベストプラクティスとして、チームは AWS Security Incident Response のケース内の情報へのアクセスと管理に必要な最小限の権限を設定します。これにより、セキュリティとコンプライアンスの要件を満たしつつ、チームメンバーがケースの詳細、検出結果、調査データに適切なレベルでアクセスできるようになります。AWS Security Incident Response には、ケースごとに誰がどのアクションを実行できるかを制限できるよう、CreateCaseComment (調査にメモを追加する) や GetCase (ケースのメタデータを取得する) など、複数の API アクションが用意されています。開発環境とテスト環境向けには、ロールベースのアクセス制御に使用できる AWSSecurityIncidentResponseCaseFullAccess や AWSSecurityIncidentResponseReadOnlyAccess などのロールベースのポリシーが AWS から提供されています (図 1 を参照)。本番環境では、セキュリティ要件に基づき、最小権限の原則に従ったカスタム IAM ポリシーを作成することをお勧めします。

図 1: セキュリティインシデント対応のアクセス許可ポリシー

AWS Security Incident Response サービスの設定後、セキュリティチームは、図 2 に示すように、このサービスからの通知を受け取る E メール配信リストまたはエイリアスを確認します。また、今後は追加の通知メカニズムとして PagerDuty や Jira などのサービスを追加できるよう、Amazon EventBridge との統合を活用するタスクをバックログに登録しています。

図 2: コンソールを使用してインシデント対応チームのメンバーシップを管理する

不審なアクティビティの検出と対応

AWS Security Incident Response のセットアップから数日後の午前 2 時、このサービスは GuardDuty の検出結果を通じて、一連の不審なアクティビティを検出します。具体的には、IAM ユーザーの異常な動作 (図 3 に示すようなもの)、不明な IP アドレスからの通常とは異なる API コール、アカウントの通常のベースラインから逸脱した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの大量作成などです。このアクティビティのパターンは、GuardDuty 拡張脅威検出がモニタリングしている既知の脅威の動作と一致します。このサービスがなければ、セキュリティチームはアカウントとリージョンをまたいで、これらの個別の検出結果を手動で分析し、相関付ける必要があります。しかし、このサービスを使用すれば、不審なアクティビティのパターンが自動的に特定されます。

図 3: 不審と思われるアクティビティのパターン

異常な動作の 1 つは、身に覚えのない EC2 インスタンスの大量作成です。これらのインスタンスには SSH キー (リモートアクセスに使用される安全な認証情報) が設定され、インターネット接続を許可するセキュリティグループ設定 (ネットワークトラフィックを制御するファイアウォールルール) も適用されています。このシナリオ例を使用して、このサービスの自動化されたモニタリング、トリアージ、封じ込めの機能、アクセス管理、カスタム統合用の API アクション、コラボレーションツール、そして 24 時間 365 日対応の AWS セキュリティエキスパートがどのように連携し、AWS 環境全体のセキュリティインシデント対応の課題への対処を支援するのかを順を追って見ていきましょう。

Incident Response Timeline
    dateFormat HH:mm
    axisFormat %H:%M
    
    section Detection
    GuardDuty Alerts          :02:00, 15m
    Automated Analysis        :after Detection, 10m
    
    section Investigation
    Case Creation             :02:25, 5m
    Team Notification         :02:30, 5m
    Initial Assessment        :02:35, 25m
    
    section Response
    AWS SIRE Engagement       :03:00, 30m
    Resource Tagging          :03:30, 15m
    Containment Actions       :03:45, 30m
    
    section Resolution
    Threat Elimination        :04:15, 30m
    Service Restoration       :04:45, 45m
    Documentation             :05:30, 30m

初期検出が完了したら、次のフェーズでは、インシデントの全容を把握するために、セキュリティの検出結果を一元化して分析します。

セキュリティ検出結果の一元化: 体系的なアプローチ

GuardDuty を有効化したリージョンで、検出結果の生成が開始されます。

注: GuardDuty は、アカウントとリージョンで有効化されている必要があります。セットアップ手順については、GuardDuty のドキュメントを参照してください。

AWS Security Incident Response は GuardDuty と統合されているため、これらの検出結果は手作業なしで自動的にサービスに送信され、内部での処理、分析、自動トリアージが行われます。このサービスのプロアクティブな対応とアラートのトリアージ機能は、アカウントの過去のアクティビティに基づくベースライン、GuardDuty の具体的な検出結果タイプ、アカウント間の相関パターンなど、複数の要素を分析します。この例では、環境の通常のパターンから大きく逸脱した、異常な EC2 インスタンス作成アクティビティを特定しました。

このサービスが真陽性を特定すると、AWS Security Incident Response のケースが自動的に作成され (図 4 を参照)、先ほど設定したインシデント対応チームに通知が送信されます。大きなメリットは、このサービスが個別のイベントを相関付け、インスタンスの作成とセキュリティグループの変更を結び付けることで、潜在的なセキュリティイベントの全体像を描き出せる点です。

図 4: 自動化されたインシデント修復フロー

月次サービスレポートに記録されているとおり、このプロアクティブなモニタリングと分析は、アラート疲れを軽減し、SOC チームにインテリジェントなトリアージ機能を日々提供することで、目に見えるメリットをもたらします。このサービスの自動分析と相関付けの機能により、セキュリティイベントの発生時に迅速に対応するための土台が整うため、チームはアラートの手動調査に時間を費やすことなく、戦略的なセキュリティイニシアチブに集中できます。このサービスの機能は、次の 2 つの点で強固なセキュリティの維持に役立ちます。

• 設定したリージョン全体にわたる包括的なモニタリング。
• サードパーティーのセキュリティツールとの統合。この自動化されたアプローチにより、セキュリティイベントにかかる時間、コスト、影響が軽減されます。

調査が初期検出から詳細な分析へと進むなかで、GuardDuty との統合により、脅威のパターンに関する重要なインサイトが得られます。

検出からアクションへ: GuardDuty との統合

セキュリティチームが内部の検出メカニズムから得られた情報に対応するなかで、AWS Security Incident Response は、次の 3 つの主要なステップでセキュリティの検出結果を処理します。

• GuardDuty のアラートを分析して、実際のセキュリティ脅威を特定する
• GuardDuty 拡張脅威検出を使用して関連するイベントを相関付け、脅威のパターンを特定する
• 初期アクション (ログの削除や不正なアクセス手段の作成) から、データ窃取の試みが疑われる段階に至るまで、脅威のシーケンスを追跡する

今回のイベントでは、AWS CloudTrail ログの削除から始まり、続いて不正なアクセスキーが作成されました。脅威が進行するにつれて、このサービスは Amazon Simple Storage Service (Amazon S3) オブジェクトへの不審なアクセスパターン、データ流出が疑われる試み、さらに高度な回避手法と永続化メカニズムを特定しました。これらのシグナルはそれぞれ MITRE ATT&CK® の特定の戦術、技術、手順 (TTP) に直接対応しており、ランサムウェアの疑いがある脅威が体系的に進行していることを示しています。AWS Security Incident Response の検出結果と MITRE ATT&CK® フレームワークとの詳細なマッピングについては、「Mapping AWS security services to MITRE frameworks for threat detection and mitigation」を参照してください。

このサービスは相関付けと分析を支援し、CloudTrail 証跡の削除、新しいアクセスキーの作成、S3 オブジェクトを標的とした不審なアクションなどのパターンを評価します。GuardDuty の AI と機械学習 (AI/ML) の機能が一定期間にわたってこうした懸念すべきパターンを検出すると、このサービスはお客様に代わって AWS Security Incident Response のケースを自動的に作成して状況をエスカレーションします。これにより、追加のリソースが投入され、この状況に重点的に対処できるようになります。その後、前の手順で定義したインシデント対応チームに、トリアージ済みの新しいイベントが作成されたことが E メールやその他の方法 (図 5 を参照) で通知され、チームは調査を開始します。

メリットの 1 つは、影響を受けるアカウント全体のコミュニケーションをこのサービスが調整することです。複数のアラートに振り回されたり、断片的な情報をつなぎ合わせてランサムウェアインシデントの疑いがある事象の範囲を把握しようとしたりする必要はありません。GuardDuty 拡張脅威検出が脅威のシーケンスの包括的なビューを提供し、AWS Security Incident Response のケースがこれらのシグナルをトリアージするための一貫した単一のチャネルとなります。さらに、世界各地のチームがオンラインになって対応に加わる際の調整にも役立ちます。

図 5: インシデントアラートメッセージ

その他の例と詳細については、「Amazon GuardDuty Extended Threat Detection のご紹介: AI/ML 攻撃シーケンスを識別し、クラウドセキュリティを強化」を参照してください。

注: Security Hub のワークフローは、前述の GuardDuty のモニタリングとエスカレーションのプロセスと同様のため、ここでは簡潔さを優先して詳細を省略しています。両サービスは緊密に統合されており、同様の運用パターンを共有しています。GuardDuty の検出結果は、検出から 5 分以内に Security Hub に送信されます。Security Hub は、複数の AWS サービスとサードパーティーのパートナーからの検出結果を集約することで、セキュリティのカバレッジを強化します。

脅威のパターンが特定されたら、お客様のチームは次のフェーズに進み、専門知識と高度な調査機能を得るために AWS SIRE に協力を依頼します。

インシデント対応ケースを通じた AWS SIRE との連携

お客様のチームはイベントの調査を続けるなかで、追加の支援が必要だと判断します。アカウント内で必要な権限を持つユーザーが、AWS がサポートするケースを作成して支援を依頼します。

AWS Security Incident Response のケースでは、コンソール内でワンクリックでケースをエスカレーションするだけで AWS SIRE との直接的なコミュニケーションチャネルが確立され (図 6 を参照)、専門知識をすぐに利用できます。ケースがエスカレーションされると、AWS SIRE は 15 分以内に受領を確認し、インシデント対応ケースを通じて対応を開始します。そして、高度なツールと専門知識を活用し、ログ記録機能が限られている環境であっても、アカウント全体のパターンを分析します。この連携により、次のことが実現します。

• ブリッジコール (ビデオ会議) によるリアルタイムのコラボレーション
• 高度なアーティファクト分析とパターン認識
• 調査と封じ込めのための技術的なガイダンス
• セキュリティポスチャを改善するための推奨事項

図 6: AWS SIRE との連携

図 6 は、セルフマネージドのケースとしてリゾルバーを Self に設定した場合の、アカウントでの表示例です。

シナリオに戻ると、複数のアカウントで十分なログ記録が有効になっておらず、調査に利用できるデータが限られていることが判明します。AWS SIRE は専門的なツールを通じて追加のインサイトを提供できますが、セキュリティの可視性の確保、コンプライアンス要件への対応、徹底したインシデント調査のためには、アカウント全体で包括的なログ記録を維持することが引き続き重要です。AWS SIRE の機能は適切なログ記録の実践を補完するものであり、それに代わるものではありません。AWS SIRE は通常はお客様から見えないパターンやアクティビティを把握できるため、この機能はインシデントの範囲を理解するのに役立ちます。

コラボレーションは、AWS SIRE が独自のツールを使用して環境を分析し、手元のログで確認できる範囲を超えて異常なパターンを探すところから始まります。AWS SIRE はインシデント対応ケースを通じて、次の方法でインシデントの範囲を把握できるよう支援します。

• 調査結果を共有する
• 追加の調査の方向性を提案する
• 他の環境で見られた同様の EC2 インスタンス作成パターンを示す分析を共有する

AWS SIRE はインシデント対応ケースを使用してブリッジコールを設定し、AWS SIRE のチームとお客様のチームが集まってリアルタイムでコラボレーションできるようにします。この通話では、AWS SIRE がアーティファクトとサービスデータについて進行中の分析結果を共有し、何が起きたのか、なぜ起きたのか、今後同様の問題をどう防ぐのかを理解できるよう支援します。また、今後のセキュリティポスチャの改善に向けて、アカウント全体に適切なログ記録を実装するためのガイダンスも提供します。

インテリジェントなタグ付けによるインシデントの管理

AWS SIRE が分析を開始すると、お客様のチームはインシデントケース ID を使用して、リアルタイムでリソースにタグを付けていきます。この体系的なタグ付けは、アカウント全体で不審な EC2 インスタンスを追跡して管理するうえで非常に重要です。タグを使用することで、調査全体を通じて影響を受けたリソースを明確に記録しながら、隔離ポリシーを迅速に実装し、コストを追跡できます。

チームが採用したタグベースのアプローチは、影響を受けたリソースを追跡し、隔離ポリシーを実装するのに役立ちます。インシデントケース ID のタグを使用してインシデントに関連するリソースをすばやく特定し、対象を絞ったアクセス制御と封じ込め対策を適用しました。また、タグはインシデントに関連するコストの追跡にも役立つため、財務チームはイベントによる財務上の影響を正確に把握できます。

AWS Security Incident Response サービスと連携して作業を進めるなかで、インシデントケース ID をプライマリタグキーとして使用すると (図 7 を参照)、影響を受けたアカウント全体でリソースを一貫した方法で相関付けられることがわかりました。調査が必要な特定のリソースを AWS SIRE にすばやく伝えられるため、AWS SIRE と連携する際に特に役立ちます。封じ込め後も、これらのタグはインシデント後の分析を支え、インシデントから得た知見に基づいて対象を絞ったセキュリティコントロールを実装するのに引き続き役立ちます。

図 7: インシデントタグ

Systems Manager との統合による自動封じ込めのオプション

AWS SIRE と協力してインシデントの範囲を把握する一方で、Systems Manager を使用して脅威を自動的に封じ込めることもできます。チームは必要な CloudFormation StackSets を事前に組織全体へデプロイしているため、Systems Manager を通じて Amazon EC2 の封じ込めアクションを実行できます。

セットアッププロセスでは、特定の IAM ロールと Systems Manager の設定を含む CloudFormation StackSets をアカウント全体にデプロイする必要がありました。このインフラストラクチャにより、AWS Security Incident Response サービスはお客様に代わって封じ込めアクションを実行できます。これらのアクションは、元に戻す (undo) 機能を使う場合と同様に、必要に応じて取り消せるため、システムを以前の状態に復元できます。

事前にデプロイした CloudFormation StackSets を通じて承認されていれば、AWS Security Incident Response サービスは Systems Manager に封じ込め対策の実装を要求できます。封じ込めアクションを実行するには、お客様による明示的な承認と、事前に設定された適切な IAM アクセス許可が必要です。このサービスは、タグが付けられた不審なインスタンスのセキュリティグループとネットワークアクセスを変更してインスタンスを隔離すると同時に、フォレンジック分析に使用する証拠の完全性を維持できるよう、インスタンスの状態を保持します。

封じ込めプロセスは、次の 3 つのステップで行われます。

1. 隔離: 侵害されたインスタンスをセキュリティグループから削除する
2. 保全: 影響を受けたシステムのバックアップコピー (スナップショット) を作成する
3. 調査: Systems Manager を使用してシステム情報を収集する

これらのアクションは必要に応じて元に戻すことができるため、正当なワークロードに対する封じ込めの判断にも柔軟に対応できます。

自動化機能により、複数のインスタンスにわたる封じ込め手順が効率化され、影響を受けたリソースの封じ込めにかかる時間を短縮できます。このサービスは各アクションの詳細なログをインシデント対応ケースに記録するため、チームは封じ込め作業の状況を明確に把握できます。

この対応機能と AWS SIRE からのガイダンスを組み合わせることで、インシデントの拡大を数時間ではなく数分で封じ込めることができます。Systems Manager との統合により、調査用の証拠を保全しながら、封じ込めアクションを確実に実装できます (図 8 を参照)。

図 8: 封じ込めアクション用の Systems Manager ドキュメント

解決と教訓

インシデントが解決に向かうにつれて、チームは体系的なプロセスに沿って、封じ込めの確認、脅威の緩和、サービスの復旧を進めます。AWS Security Incident Response のケースを通じて AWS SIRE と連携しながら、影響を受けたリソースを保護し、通常の運用を安全に再開できるよう、構造化されたアプローチを実践します。直ちに実施する解決アクションは、主に次の 3 つのカテゴリに分類されます。

• Systems Manager による検証を通じた封じ込めの確認
  • セキュリティグループの変更が適用されていることを検証する
  • 影響を受けたインスタンスのネットワーク隔離を確認する
  • 自動封じ込めアクションが成功したことを検証する
  • Systems Manager のログで封じ込めアクションの完了を確認する
• 影響を受けたリソース全体で脅威が緩和されたことの検証
  • GuardDuty の検出結果を分析し、新たな不審なアクティビティがないことを確認する
  • タグ付けされたリソースを調べ、完全に封じ込められていることを確認する
  • 不正アクセスの試みが停止していることを検証する
  • 永続化メカニズムが削除されていることを確認する
  • 不正な IAM アクセスが残っていないかを確認する
• サービスの復旧とアクセス制御の正常化
  • 検証済みのベースラインに基づいて、正当なワークロードのアクセスを復元する
  • 更新されたセキュリティグループ設定を実装する
  • 影響を受けた IAM 認証情報とアクセスキーをリセットする
  • クリーンであることが検証されたリソースについて、通常のネットワーク接続を再確立する
  • インシデント後のステータスを反映するようにリソースタグを更新する

文書化とレポート作成

インシデントが解決に至ると、AWS Security Incident Response サービスは包括的なインシデントタイムラインを作成します。このドキュメントによってレポート作成プロセスが迅速化され、経営幹部、規制当局、サイバー保険会社向けに必要なレポートを、すべてインシデント対応ケース内からすばやく作成できます。

インシデント対応ケースには、GuardDuty 拡張脅威検出が初期段階の脅威のシーケンスを特定した時点から始まる、イベントの完全なタイムラインが記録されます。不審な EC2 インスタンスの作成が検出された瞬間から、観測された MITRE ATT&CK® の戦術、Systems Manager との統合を通じて実装された封じ込めアクション、そして最終的に効果が確認された解決手順に至るまで、インシデント対応の各ステップが文書化されます。

長期的な改善: このインシデント後の共同レビュープロセスを通じて、チームは次の取り組みを行います。

• AWS SIRE の推奨事項に基づいて、ログ記録を強化する
• 同様のインシデントを防ぐためにセキュリティコントロールを更新する
• 教訓に基づいてインシデント対応プロセスを改善する
• 対象を絞った改善によってセキュリティポスチャを強化する

まとめ

この例では、AWS Security Incident Response サービスが、自動化された検出、トリアージ、封じ込め、アクセス管理、連携した対応の機能によって、セキュリティ運用をどのように強化できるかを紹介しました。このサービスは AWS Security Hub や Amazon GuardDuty と統合されているため、セキュリティイベントを効率的に処理できます。さらに、オプションで AWS SIRE にエスカレーションすれば、貴重な専門知識と専門的なツールを活用でき、インシデント対応ライフサイクルのあらゆる段階を加速し、セキュリティポスチャを強化するのに役立ちます。

AWS Security Incident Response サービスは、包括的なセキュリティ運用戦略の重要な要素として、次のような測定可能なメリットをもたらします。

• 自動化された相関付けと機械学習により、誤検知を最小限に抑えながら優先度の高いセキュリティリスクを特定する継続的な脅威モニタリング
• 自動検出と連携した対応によるインシデント対応時間の短縮
• AWS SIRE との直接的なコラボレーションによる調査機能の強化
• 効率的かつ迅速な封じ込め
• レポート作成要件への迅速な対応を支援する、包括的なインシデントの記録と監査証跡
• インシデントあたり最大 58% のコスト削減

セキュリティインシデントへの備え、対応、復旧をより迅速かつ効率的に行うには、今すぐ AWS Security Incident Response のページにアクセスするか、AWS アカウントチームに連絡してディスカッションの日程を調整してください。

その他のリソース

セキュリティインシデント対応能力をさらに向上させるために、チームで活用できるその他の AWS リソースを紹介します。

イベント発生前

• AWS Customer Playbook Framework: セキュリティイベントから得られた AWS SIRE の教訓を活用した、一般公開されている対応フレームワーク
• Assisted Log Enabler: Amazon VPC フローログ、AWS CloudTrail、Amazon Elastic Kubernetes Service の監査ログと Authenticator ログ、Amazon Route 53 Resolver クエリログ、Amazon S3 サーバーアクセスログ、Elastic Load Balancing ログなどのログの有効化を支援するツール

イベント発生中

• Athena Security Analytics Bootstrap: Amazon Athena をすばやくセットアップし、S3 バケットにアーカイブされた AWS サービスログを調査したいお客様向けのツール

イベント発生前または発生後

• AWS CIRT announces the release of five publicly available workshops

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。