View a markdown version of this page

カスタム検出ルールの仕組み - Amazon GuardDuty
データソースとシグナルモード結果の集約編集されたイベントフィールド

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

カスタム検出ルールの仕組み

まず、GuardDuty が提供するルールを参照して、環境に関連するアクティビティを検出するルールを特定します。次に、各ルールを、アクティビティが予期しないアカウントと関連付けます。ルールと アカウントの関連付けの詳細については、「」を参照してくださいカスタム検出ルールの管理。

データソースとシグナル

ルールを関連付けると、GuardDuty はルールが依存するデータソースをモニタリングし、一致するイベントについて受信ログを評価します。カスタム検出ルール は、 AWS CloudTrail 管理イベントとランタイムモニタリングイベントをサポートしています。観察されたアクティビティがルールと一致すると、GuardDuty はシグナルを生成します。シグナルは、ルールが検出したアクティビティの単一の観測された出現を表します。

各データソースには独自の要件があります。

AWS CloudTrail 管理イベント

GuardDuty は、GuardDuty が有効になっているすべてのアカウントでこれらのイベントを分析します。追加のセットアップは必要ありません。

Runtime Monitoring イベント

Runtime Monitoring ルールは、GuardDuty セキュリティエージェントがリソースで観察するプロセス、ファイル、ネットワークアクティビティを評価します。Runtime Monitoring ルールは、次の両方の要件を満たすリソースでのみアクティビティを照合できます。

  • Runtime Monitoring は、Fargate のリソースタイプ Amazon EKS、Amazon EC2、または Amazon ECS で有効になっています。詳細については、「GuardDuty Runtime Monitoring」を参照してください。

  • GuardDuty セキュリティエージェントは、そのプラットフォームのルールの最小エージェントバージョン以上のリソースで実行されます。

各 Runtime Monitoring ルールには、実行できる各プラットフォームで必要な最小エージェントバージョンが記載されています。これらの要件を表示するには、 GetCustomDetectionRuleオペレーションを呼び出します。

リソースのエージェントがルールの最小バージョンよりも古い場合、ルールはそのリソースのアクティビティと一致しません。この場合、GuardDuty はエラーを報告しないため、Runtime Monitoring ルールを有効にするリソースでエージェントを最新の状態に保ちます。エージェントのバージョンについては、「」を参照してくださいGuardDuty セキュリティエージェントのリリースバージョン。

モード

すべての関連付けは、次の 2 つのモードのいずれかで実行されます。

  • ライブ – ルールが一致すると、GuardDuty は結果を生成します。

  • ドライラン – GuardDuty は、ルールが一致するが結果を生成しない頻度をカウントする Amazon CloudWatch メトリクスを出力します。ドライランを使用して、ルールが結果を作成したり自動レスポンスをトリガーしたりする前に、ルールが一致する頻度を測定します。ドライランの関連付けは作成から 14 日後に期限切れになり、ライブの関連付けは期限切れになりません。

詳細については、「ドライラン」および「ライブ」を参照してください。

結果の集約

各検出結果はTactic:Service/Technique、 Persistence:IAM/AccountManipulationまたは などの形式に従いますPersistence:Runtime/SuspiciousCommand。GuardDuty がシグナルを結果にグループ化する方法は、次のリストで説明するように、シグナルを生成したデータソースによって異なります。

  • AWS CloudTrail ルール – GuardDuty は、同じ戦術、サービス、手法を共有するシグナルを 1 つの検出結果に集約します。GuardDuty が同じプリンシパルから同じアクティビティを繰り返し観察する場合、1 つの検出結果に複数のシグナルを含めることができます。

  • Runtime Monitoring ルール – GuardDuty は、同じルール、リソース、およびプロセスの詳細を共有するシグナルを 1 つの検出結果に集約します。各検出結果は、インスタンス、タスク、コンテナなど、1 つのリソースを対象としています。GuardDuty が比較するプロセスの詳細は、検出結果タイプによって異なります。たとえば、ファイル変更の検出結果は、ファイルオペレーションとプロセスを実行したユーザーも比較します。再一致は、新しい結果を作成する代わりに、既存の結果を更新します。ルールが同じリソースとプロセスに対して同じ検出結果タイプを生成しても、異なるルールの検出結果は分離されたままになります。

検出結果の構造とフィールドの詳細については、「」を参照してくださいカスタム検出ルールの検出結果の詳細。

編集されたイベントフィールド

AWS CloudTrail ルールは、 がイベントに記録するフィールドを評価します。 AWS CloudTrail 編集は GuardDuty のアップストリームで行われます。 AWS サービスは、発行するイベントのフィールドの値を編集できます。この秘匿化は、潜在的な機密データを保護します。フィールドが編集されると、 はフィールドが存在した AWS CloudTrail が、その値は記録しません。

イベントを発行するサービスは、編集するフィールドを決定します。サービスでは、そのフィールドが機密情報を伝達できる場合にフィールドを編集します。編集は、特定の値ではなく フィールドに適用されます。したがって、特定のリクエストの値が機密でなくても、サービスはフィールドを編集します。、 CLI、または AWS SDK AWS のどちらを使用するかに関係なく、すべてのリクエスト AWS マネジメントコンソールのこれらのフィールドを編集します。

GuardDuty は、イベントにない値を評価できません。ルールの検出ロジックが秘匿化されたフィールドに依存している場合、ルールは一致しません。その後、GuardDuty は、アクティビティが発生してもシグナルも検出結果も生成しません。イベント名、サービス、呼び出し元の ID など、サービスが編集しないフィールドのみを検査する場合、 AWS ルールは影響を受けません。

秘匿化では、ルールを 1 つのリクエストに一致させることもできますが、同じ効果を持つ別のリクエストに一致させることはできません。API オペレーションが同じ変更に対して複数のフィールドを受け入れる場合、1 つのフィールドが秘匿化され、もう 1 つのフィールドが秘匿化されないことがあります。ルールが一致するかどうかは、リクエストが使用したフィールドによって異なります。

注記

カスタム検出ルールは検出機能であり、完全な監査レコードではありません。アカウントで特定の API コールが発生したかどうかを確認するには、 でイベントを確認します AWS CloudTrail。詳細については、「イベント履歴を含む AWS CloudTrail イベントの表示」を参照してください。