# 検出
<a name="detection"></a>

 アラートは、検出フェーズの主要コンポーネントです。対象の AWS アカウントの脅威アクティビティに基づいて、インシデント対応プロセスの開始通知を生成します。

 精度の高いアラートの生成は難しく、インシデントが発生したか、進行中か、または将来発生するかを常に確実に判断できるわけではありません。いくつかの理由を次に示します。
+  検出メカニズムは、ベースラインからの逸脱、既知のパターン、内部または外部エンティティからの通知に基づいています。
+  それぞれがセキュリティインシデントの*手段*と*アクター*であるテクノロジーと人員の予測不可能な性質が原因で、ベースラインは時間の経過に伴って変化します。不正なパターンは、脅威アクターの新しいまたは変更された*戦術*、*技術*、*手順* (TTP) を通じて発生します。
+  人員、テクノロジー、プロセスへの変更は、インシデント対応プロセスにすぐには組み込まれません。調査の進行中に発見されるものもあります。

# アラートのソース
<a name="alert-sources"></a>

 アラートを定義するには、次のソースの使用を検討してください。
+ **検出結果** – [Amazon GuardDuty](https://aws.amazon.com/guardduty/)、[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)、[Amazon Macie](https://aws.amazon.com/macie/)、[Amazon Inspector](https://aws.amazon.com/inspector/)、[AWS Config](https://aws.amazon.com/config/)、[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)、[Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html) などの AWS サービスでは、アラートの作成に使用できる検出結果が生成されます。
+ **ログ** – Amazon S3 バケットと CloudWatch ロググループに保存されている AWS サービス、インフラストラクチャ、アプリケーションログを解析し、相関させることでアラートを生成できます。
+ **請求アクティビティ** – 請求アクティビティの突然の変更は、セキュリティイベントを示している可能性があります。これは「[AWS の予想請求額をモニターリングする請求アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)」ドキュメントに従ってモニタリングします。
+ **サイバー脅威インテリジェンス** – サードパーティーのサイバー脅威インテリジェンスフィードをサブスクライブする場合、その情報を他のログおよびモニタリングツールと関連付けて、イベントの潜在的な指標を特定できます。
+ **パートナーツール** – AWS Partner Network (APN) のパートナーは、セキュリティ目標の達成に役立つ最上位の製品を提供しています。インシデント対応では、エンドポイントの検出と対応 (EDR) または SIEM を使用するパートナー製品は、インシデント対応目標をサポートします。詳細については、「[Security Partner Solutions](https://aws.amazon.com/security/partner-solutions/)」と「[Security Solutions in the AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security)」を参照してください。
+ **AWS の信頼と安全** – 不正または悪意のあるアクティビティを特定した場合、サポート からお客様に連絡することがあります。
+ **1 回限りの問い合わせ** – お客様、開発者、または組織内の他のスタッフが異常に気付く可能性があるため、セキュリティチームへの連絡方法を周知させ、適切に公開することが重要です。一般的な選択肢には、チケットシステム、連絡先メールアドレス、ウェブフォームなどがあります。一般ユーザーと連携する組織の場合、一般向けのセキュリティに関する問い合わせ手段が必要になる場合もあります。

 調査中に使用できるクラウド機能の詳細については、本書の「[付録 A: クラウド機能の定義](appendix-a-cloud-capability-definitions.md)」を参照してください。

# セキュリティコントロールエンジニアリングの一環としての検出
<a name="detection-as-security-control-engineering"></a>

 検出メカニズムは、セキュリティコントロールの開発に欠かせないものです。*ディレクティブ*コントロールと*予防的*コントロールを定義したら、関連する*検出*コントロールと*対応*コントロールを構築する必要があります。例えば、ある組織が AWS アカウントのルートユーザーに関連するディレクティブコントロールを確立したとします。このコントロールは、具体的な、明確に定義されたアクティビティにのみ使用する必要があります。これを、AWS 組織のサービスコントロールポリシー (SCP) を使用して実装された予防的コントロールに関連付けます。ルートユーザーのアクティビティが予想ベースラインを超えた場合、EventBridge ルールと SNS トピックを使用して実装された検出コントロールが、セキュリティオペレーションセンター (SOC) に警告します。対応コントロールが、SOC に適切なプレイブックを選択させ、分析を実行させ、インシデントの解決まで作業に当たらせます。

 セキュリティコントロールは、AWS で実行されているワークロードの脅威モデリングによって定義するのが最も適切です。検出コントロールの重要度は、特定のワークロードに対するビジネスインパクト分析 (BIA) を確認して設定されます。検出コントロールによって生成されたアラートは、そのままの状態で処理されるものではなく、初期の重要度に基づいて分析中に調整されます。アラートの初期の重要度は優先順位付けに役立ちますが、実際の重要度はアラートが発生した文脈によって決まります。例えば、ある組織が、ワークロードの一部である EC2 インスタンスに使用される検出コントロールのコンポーネントとして Amazon GuardDuty を使用しているとします。検出結果 `Impact:EC2/SuspiciousDomainRequest.Reputation` が生成され、ワークロード内のリストされた Amazon EC2 インスタンスが悪意が疑われるドメイン名をクエリしていることが通知されました。このアラートはデフォルトでは重要度が低く設定されていましたが、分析フェーズが進むにつれて、不正なアクターによって数百もの `p4d.24xlarge` タイプの EC2 インスタンスがデプロイされ、組織の運用コストが大幅に増加していることが判明しました。この時点で、インシデント対応チームは、このアラートの重要度を*高*に調整し、緊急性を高め、さらなるアクションを迅速に行うことを決定します。GuardDuty の検出結果の重要度は変更できないことに注意してください。

# 検出コントロールの実装
<a name="detective-control-implementations"></a>

 検出コントロールは、特定のイベントに対してアラートをどのように利用するかを決定するのに役立つため、検出コントロールの実装方法を理解することが重要です。技術上、検出コントロールには主に 2 つの実装方法があります。
+  **動作検出**は、一般的に機械学習 (ML) または人工知能 (AI) と呼ばれる数学モデルに依存します。検出は推論によって行われるため、アラートは必ずしも実際のイベントを反映しているとは限りません。
+  **ルールベースの検出**は決定論的で、お客様はアラートの対象となるアクティビティの正確で確実なパラメータを設定できます。

 侵入検知システム (IDS) などの検出システムの最新の実装には、通常、両方のメカニズムが使用されます。以下に、GuardDuty を使用したルールベースの検出と動作検出の例を示します。
+  検出結果 `Exfiltration:IAMUser/AnomalousBehavior` が生成されると、「アカウント内で異常な API リクエストが観察されました」という通知が表示されます。さらに詳しく見ると、「ML モデルはアカウント内のすべての API リクエストを評価し、攻撃者が使用する手法に関連付けられる異常なイベントを識別しました」と表示されます。これは、この検出結果が動作的な性質であることを示しています。
+  検出結果 `Impact:S3/MaliciousIPCaller` について、GuardDuty は CloudTrail の Amazon S3 サービスからの API コールを分析し、`SourceIPAddress`のログ要素を、脅威インテリジェンスフィードを含むパブリック IP アドレスのテーブルと比較しています。エントリに直接一致するものが見つかると、検出結果が生成されます。

 脅威モデル内のすべてのアクティビティに対してルールベースのアラートを実装することができない場合もあるため、動作アラートとルールベースのアラートの両方を実装することをお勧めします。

# 人員ベースの検出
<a name="people-based-detection"></a>

 これまではテクノロジーベースの検出について説明してきました。もう 1 つの重要な検出の情報源は、お客様の組織内外の人々です。*内部の人間*は従業員または請負業者として定義でき、*外部の人間*はセキュリティ研究者、法執行機関、ニュース、ソーシャルメディアなどのエンティティです。

 テクノロジーベースの検出は体系的に設定できますが、人員ベースの検出には、メール、チケット、郵便、ニュース投稿、電話、対面でのやり取りなど、さまざまな形式があります。テクノロジーベースの検出の通知はほぼリアルタイムで配信されることが予想されますが、人員ベースの検出の場合、時間軸についての期待はされません。セキュリティへの多層防御アプローチでは、セキュリティ文化が人員ベースの検出メカニズムを組み込み、それを促進して強化することが不可欠です。

# 概要
<a name="detection-summary"></a>

 検出では、ルールベースと動作主導のアラートを組み合わせることが重要です。さらに、社内外のスタッフがセキュリティ上の問題に関するチケットを送信できるメカニズムを用意する必要があります。人はセキュリティイベントの最も価値ある情報源の 1 つとなる可能性があるため、懸念をエスカレーションするプロセスを設けることが重要です。検出コントロールの構築を開始するには、環境の脅威モデルを使用する必要があります。脅威モデルは、環境に最も関連性の高い脅威に基づいてアラートを作成することに役立ちます。最後に、MITRE ATT&CK などのフレームワークを使用して、脅威アクターの戦術、技術、手順 (TTP) を理解できます。MITRE ATT&CK フレームワークは、さまざまな検出メカニズム間の共通言語として使用するのに役立ちます。