# SEC 4. セキュリティイベントをどのように検出して調査するのですか。
ログとメトリクスからイベントをキャプチャして分析し、可視性を得ることができます。ワークロードを保護するため、セキュリティイベントと潜在的な脅威に対するアクションを実行します。
**Topics**
+ [SEC04-BP01 サービスとアプリケーションのログ記録を設定する](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 標準化した場所にログ、検出結果、メトリクスを取り込む](sec_detect_investigate_events_logs.md)
+ [SEC04-BP03 セキュリティアラートを相関付けて充実させる](sec_detect_investigate_events_security_alerts.md)
+ [SEC04-BP04 非準拠リソースの修復を開始する](sec_detect_investigate_events_noncompliant_resources.md)
# SEC04-BP01 サービスとアプリケーションのログ記録を設定する
サービスとアプリケーションのセキュリティイベントログを保持します。これは、監査、調査、運用のユースケースにおけるセキュリティの基本原則であり、ガバナンス、リスク、コンプライアンス (GRC) の標準、ポリシー、手順によって推進される共通のセキュリティ要件です。
**期待される成果:** 組織は、セキュリティインシデント対応など内部のプロセスまたは義務を遂行する必要があるときは、AWS サービスやアプリケーションからのセキュリティイベントログを確実にかつ一貫性をもって、タイムリーに取得できるようにしておく必要があります。運用側の成果を改善するためにログの一元化を検討してください。
**一般的なアンチパターン:**
+ ログが永久に保存される、またはすぐに削除される。
+ 誰でもログにアクセスできる。
+ ログガバナンスと使用について、手動プロセスのみに依存する。
+ 必要な場合に備えて、あらゆるタイプのログを保存する。
+ 必要な場合にのみログ整合性をチェックする。
**このベストプラクティスを活用するメリット:** セキュリティインシデントの根本原因分析 (RCA) のメカニズムを導入し、ガバナンス、リスク、コンプライアンスの義務における証拠の源とします。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
セキュリティ調査または要件に基づいた他のユースケース中、インシデントの全容とタイムラインを記録して理解するために関連ログをレビューできる必要があります。ログはまた、関心のある特定のアクションが発生したことを示すアラート生成にも必須です。クエリと取得のメカニズムを選択、有効化、保存、設定してアラートを発するのに不可欠です。
**実装手順**
+ **ログのソースを選択して使用します。**セキュリティ調査の前に、関連するログを取得し、過去にさかのぼって AWS アカウントでアクティビティを再構築する必要があります。ワークロードに関連するログソースを選択します。
ログソース選択条件は、ビジネスで必要なユースケースに基づいたものである必要があります。各 AWS アカウントに AWS CloudTrail または AWS Organizations 証跡を使って証跡を作成し、それらの Amazon S3 バケットを設定します。
AWS CloudTrail は、AWS のサービスアクティビティをキャプチャする AWS アカウントに対して API コールをトラッキングするログサービスです。これはデフォルトで有効になっており、管理イベントは 90 日間保持され、AWS マネジメントコンソール、AWS CLI、AWS のいずれかを使用して [CloudTrail イベント履歴から検索](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)することが可能です。データイベントをより長く保持し、確認できるようにするには、[CloudTrail 証跡を作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)して、これを Amazon S3 バケットと Amazon CloudWatch ロググループ (任意) に関連付けます。あるいは、[CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) を作成する方法もあります。この方法では、CloudTrail ログを最長 7 年間保持でき、SQL ベースのクエリ機能を利用できます。
AWS では、VPC を使用しているお客様には、[VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)と [Amazon Route 53 Resolverのクエリログ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)をそれぞれ使用してネットワークトラフィックと DNS ログを有効にし、それらを Amazon S3 バケットまたは CloudWatch ロググループにストリーミングすることを推奨しています。VPC、サブネット、またはネットワークインターフェイス向けに VPC フローログを作成できます。VPC フローログについては、コストを削減するためにどこでどのようにフローログを使用するかを選択できます。
AWS CloudTrail ログ、VPC フローログ、Route 53 Resolver のクエリログは、AWS でのセキュリティ調査をサポートする基本的なログ記録ソースです。[Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) を使用して、このログデータを収集、正規化し、Apache Parquet フォーマットと Open Cybersecurity Schema Framework (OCSF) で保存することもできます。これらはクエリに使用できます。Security Lake は、他の AWS ログ、およびサードパーティーソースからのログもサポートします。
AWS のサービスは、Elastic Load Balancing ログ、AWS WAF ログ、AWS Config レコーダーログ、Amazon GuardDuty の検出結果、Amazon Elastic Kubernetes Service (Amazon EKS) 監査ログ、Amazon EC2 インスタンスのオペレーティングシステムとアプリケーションログなど、基本のログソースではキャプチャされないログを生成できます。ログ記録とモニタリングオプションの一覧については、「[AWS セキュリティインシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html)」の「[付録 A: クラウド機能の定義 – ログ記録とイベント](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/logging-and-events.html)」を参照してください。
+ **各 AWS サービスとアプリケーションの調査ログ機能:** 各 AWS サービスとアプリケーションにはログストレージのさまざまなオプションが用意されており、それぞれ独自の保持機能とライフサイクル機能を備えています。最も一般的な 2 つのログストレージサービスは、Amazon Simple Storage Service (Amazon S3) と Amazon CloudWatch です。保持期間が長い場合、費用対効果と柔軟なライフサイクル機能のために Amazon S3 を使用することが推奨されます。ログ記録の主要な方法が Amazon CloudWatch Logs である場合、オプションとして、アクセス頻度の低いログを Amazon S3 にアーカイブすることを検討する必要があります。
+ **ログストレージを選ぶ:** どのログストレージを選ぶかは、使用しているクエリツール、保持機能、使いやすさ、コストなどが関わってきます。ログストレージの一般的な選択肢は、Amazon S3 バケットまたは CloudWatch Log ロググループです。
Amazon S3 バケットは、ライフサイクルポリシーがオプションで備わっている、費用対効果に優れ、耐久性の高いストレージを提供します。Amazon S3 バケットに保存されているログは、Amazon Athena などのサービスを使ってクエリすることができます。
CloudWatch ロググループは、CloudWatch Logs Insights により、耐久性の高いストレージとビルトインクエリ施設を提供します。
+ **適切なログ保持を特定する:** Amazon S3 バケットまたは CloudWatch ロググループを使ってログを保存するときは、各ログソースに対して適切なライフサイクルを選び、ストレージと取得コストを最適化する必要があります。顧客のログは通常 3 か月～1 年間で、すぐにクエリでき、最長 7 年間保持されます。可用性と保持の選択は、セキュリティ要件と、法令、規制、およびビジネス上の義務の組み合わせに合わせるべきです。
+ **適切な保持とライフサイクルポリシーを使って各 AWS サービスとアプリケーションのログを使用する:** 組織の各 AWS サービスまたはアプリケーションには、特定のログ記録の設定ガイダンスを確認します。
+ [AWS CloudTrail 証跡を設定する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [VPC フローログを設定する](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [Amazon GuardDuty Finding Export を設定する](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html)
+ [AWS Config 記録を設定する](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-config.html)
+ [AWS WAF Web ACL トラフィックを設定する](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)
+ [AWS Network Firewall ネットワークトラフィックログを設定する](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html)
+ [Elastic Load Balancing アクセスログを設定する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Amazon Route 53 リゾルバーのクエリログを設定する](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)
+ [Amazon RDS ログを設定する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html)
+ [Amazon EKS コントロールプレーンログを設定する](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ [Amazon EC2 インスタンスとオンプレミスサーバーに Amazon CloudWatch エージェントを設定する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ **ログのクエリメカニズムを選択して実装する:** ログのクエリについては、[CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) を CloudWatch ロググループに保存されたデータに、[Amazon Athena](https://aws.amazon.com/athena/) と [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) を Amazon S3 に保存されたデータに使用できます。また、セキュリティ情報とイベント管理 (SIEM) サービスなど、サードパーティーのクエリツールを使用することもできます。
ログクエリツールを選択するためのプロセスは、セキュリティオペレーションの人材、プロセス、およびテクノロジー側面を考慮する必要があります。オペレーション、ビジネス、セキュリティの要件を満たし、長期的にアクセスとメンテナンスが可能なツールを選択します。ログクエリツールは、スキャンするログの数がツールの制限内に収まっている場合、動作が最適であることに注意してください。コストや技術的な制約から、複数のクエリツールを所有することも珍しくありません。
例えば、過去 90 日間のデータにはサードパーティーのセキュリティ情報とイベント管理 (SIEM) ツールを使用しながらも、SIEM のログインジェストコストが原因で 90 日以前のデータをクエリする際は Athena を使用するとった場合です。どのような実装であっても、必要なツールの数を最小限に抑えることで、特にセキュリティイベントの調査時に、運用効率が最大となるアプローチであることを確認してください。
+ **アラートにログを使用する:** AWS は複数のセキュリティサービスでアラート機能を提供しています。
+ [AWS Config](https://aws.amazon.com/config/) は、AWS リソース構成のモニタリングと記録が行われ、目標の構成に対する評価と修復が自動化できます。
+ [Amazon GuardDuty](https://aws.amazon.com/guardduty/) は、悪意のあるアクティビティや不正な動作を継続的にモニタリングして AWS アカウントとワークロードを保護する脅威検知サービスです。GuardDuty は、AWS CloudTrail 管理およびデータイベント、DNS ログ、VPC フローログ、Amazon EKS 監査ログなどのソースから情報を取得して、集計、分析します。GuardDuty は、CloudTrail、VPC フローログ、DNS クエリログ、Amazon EKS から、独立したデータストリームを直接プルします。Amazon S3 バケットポリシーを管理したり、ログの収集と保存方法を変更したりする必要はありません。独自の調査やコンプライアンス目的で、これらのログを保持することは引き続き推奨されています。
+ [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) では、複数の AWS のサービスや任意のサードパーティー製品からのセキュリティアラートまたは検出結果の集約、整理、優先順位付けが一元的に行われ、セキュリティアラートとコンプライアンスステータスを包括的に把握できます。
また、これらのサービスの対象外となるセキュリティアラートや、自分の環境に関連する特定なアラートについては、カスタムアラート生成エンジンを使用することもできます。これらのアラートや検知の設定に関する詳細は、「AWS セキュリティインシデント対応ガイド」の「[検知](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html)」を参照してください。
## リソース
**関連するベストプラクティス:**
+ [SEC04-BP02 標準化した場所にログ、検出結果、メトリクスを取り込む](sec_detect_investigate_events_logs.md)
+ [SEC07-BP04 スケーラブルなデータのライフサイクル管理を定義する](sec_data_classification_lifecycle_management.md)
+ [SEC10-BP06 ツールを事前デプロイする](sec_incident_response_pre_deploy_tools.md)
**関連ドキュメント:**
+ [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [Amazon Security Lake の開始方法](https://aws.amazon.com/security-lake/getting-started/)
+ [Getting started: Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)
**関連動画:**
+ [AWS re:Invent 2022 - Introducing Amazon Security Lake](https://www.youtube.com/watch?v=V7XwbPPjXSY)
**関連する例:**
+ [Assisted Log Enabler for AWS](https://github.com/awslabs/assisted-log-enabler-for-aws/)
+ [AWS Security Hub CSPM Findings Historical Export](https://github.com/aws-samples/aws-security-hub-findings-historical-export)
# SEC04-BP02 標準化した場所にログ、検出結果、メトリクスを取り込む
セキュリティチームは、ログと検出結果に基づいて、不正なアクティビティや意図しない変更を示唆する可能性があるイベントを分析します。この分析の効率を高めるため、標準化した場所にセキュリティログや検出結果を集めてください。 重要なデータポイントを相関のために使えるようになり、ツールの統合を簡素化できます。
**期待される成果:** ログデータ、検出結果、メトリクスの収集、分析、視覚化に、標準化された方法を使用できます。セキュリティチームは、さまざまなシステムから集めたセキュリティデータを効率的に相関付けて分析し、視覚化して、潜在的なセキュリティイベントを発見し、異常を検知できます。セキュリティ情報とイベント管理 (SIEM) システムやその他のメカニズムを統合してログデータを照会および分析し、セキュリティイベントに対し適時の対応、追跡、エスカレーションを行います。
**一般的なアンチパターン:**
+ チームがそれぞれ独自にログやメトリクスのコレクションを所有および管理していて、それが組織のログ記録の戦略と矛盾している。
+ チームが収集したデータの表示と変更を制限するための十分なアクセス制御を実施していない。
+ チームがセキュリティログ、検出結果、メトリクスをデータ分類ポリシーに則って管理していない。
+ チームがデータ収集の設定時に、データ主権とローカリゼーションの要件を無視している。
**このベストプラクティスを活用するメリット:** 標準化されたログ記録ソリューションを使用してログデータやイベントを収集しクエリすることで、ログに含まれる情報からより良いインサイトを引き出すことができます。収集したログデータに対して自動ライフサイクルを設定することで、ログの保管にかかるコストを削減できます。収集されたログ情報に対して、データの機密性とチームが求めるアクセスパターンに応じて、きめ細かくアクセスを制御できます。ツールを統合して、データを相関付け、視覚化し、データからインサイトを引き出すことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
組織内で AWS の使用量が増えれば、分散したワークロードと環境の数が増えます。これらのワークロードと環境が各々、その中のアクティビティに関するデータを生成するため、そのデータを取り込んでローカルに保存することが、セキュリティ運用にとって課題となります。セキュリティチームは、セキュリティ情報とイベント管理 (SIEM) システムなどのツールを使用して、分散したソースからデータを収集し、相関付け、分析、対応のワークフローを実行します。そのためには、さまざまなデータソースにアクセスするための複雑な許可一式を管理する必要があり、抽出、変換、ロード (ETL) プロセスの運用における追加のオーバーヘッドも生じます。
こうした課題を解消するには、セキュリティログデータの関連ソースをすべて、ログアーカイブアカウントに集約することを検討します。詳細については「[複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/security-ou-and-accounts.html#log-archive-account)」を参照してください。これには、ワークロードのすべてのセキュリティ関連データと、[AWS CloudTrail](https://aws.amazon.com/cloudtrail/)、[AWS WAF](https://aws.amazon.com/waf/)、[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)、[Amazon Route 53](https://aws.amazon.com/route53/) などの AWS サービスによって生成されるログが含まれます。このデータを個別の AWS アカウント の標準化した場所に保存し、適切なクロスアカウントアクセス許可を設定しておくことには、利点がいくつかあります。ワークロードや環境が侵害された場合にその内部でのログの改ざん防止に役立ち、追加のツールの統合先を一元化できるだけでなく、データ保持とライフサイクルの設定モデルを簡素化できます。 データ主権、コンプライアンス範囲、その他の規制の影響を評価して、セキュリティデータの保管場所と保持期間を複数設ける必要があるかどうかを判断します。
ログと検出結果をすぐに取り込んで標準化できるようにするため、ログアーカイブアカウントの [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) を評価します。Security Lake で、CloudTrail、Route 53、[Amazon EKS](https://aws.amazon.com/eks/)、[VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)などの一般的なソースから自動的にデータを取り込むように設定できます。AWS Security Hub CSPM を Security Lake のデータソースとして設定することで、[Amazon GuardDuty](https://aws.amazon.com/guardduty/) や [Amazon Inspector](https://aws.amazon.com/inspector/) など他の AWS サービスの検出結果をログデータに関連付けることもできます。 サードパーティーのデータソース統合を利用したり、カスタムのデータソースを設定することもできます。すべての統合により、データが [Open Cybersecurity Schema Framework](https://github.com/ocsf) (OCSF) フォーマットに標準化され、[Amazon S3](https://aws.amazon.com/s3/) バケットに Parquet ファイルとして保存されるため、ETL 処理は不要になります。
セキュリティデータを標準化された場所に保存することで、高度な分析機能を使用できるようになります。AWS は、AWS 環境で動作するセキュリティ分析ツールを、ログアーカイブのアカウントとは別の[セキュリティツール用](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/security-ou-and-accounts.html#security-tooling-accounts)アカウントにデプロイすることを推奨しています。このアプローチなら、細かい統制を実装し、ログとログ管理プロセスの整合性と可用性を、ログにアクセスするツールとは別個に保護できます。 [Amazon Athena](https://aws.amazon.com/athena/) などのサービスを使用して、複数のデータソースを関連付けるオンデマンドクエリを実行することを検討します。[Quick](https://aws.amazon.com/quicksight/) などの視覚化ツールを組み込むこともできます。AI を活用したソリューションがますます普及し、検出結果を人間が読める要約や自然言語での対話に変換するなどの機能を提供しています。これらのソリューションは多くの場合、標準化したデータ保存場所をクエリ用に用意することで統合しやすくなります。
## 実装手順
1. **ログアーカイブアカウントとセキュリティツール用アカウントを作成する**
1. AWS Organizations を使用して、セキュリティ組織単位の下に[ログアーカイブアカウントとセキュリティツール用アカウントを作成](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create.html)します。AWS Control Tower を使用して組織を管理している場合、ログアーカイブアカウントとセキュリティツール用アカウントが自動的に作成されます。必要に応じて、これらのアカウントにアクセスして管理するためのロールとアクセス許可を設定します。
1. **セキュリティデータの標準化した保存場所を設定する**
1. セキュリティデータの標準化した保存場所の作成戦略を決定します。 これは、一般的なデータレイクアーキテクチャのアプローチ、サードパーティーのデータ製品、[Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/getting-started.html) などのオプションを使用して実行できます。AWS では、アカウント用に[オプトイン](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)している AWS リージョンからも、積極的に使用していない場合でもセキュリティデータを取得することを推奨しています。
1. **標準化した保存場所へのデータソースの公開を設定する**
1. セキュリティデータのソースを特定し、標準化された場所に公開するように設定します。ETL プロセスの開発が必要な形式ではなく、希望する形式でデータを自動的にエクスポートする方法を検討します。Amazon Security Lake を使用すると、サポートされている AWS ソースや統合されたサードパーティーシステムから[データを収集](https://docs.aws.amazon.com/security-lake/latest/userguide/source-management.html)できます。
1. **標準化した場所にアクセスするためのツールを設定する**
1. Amazon Athena、Quick、サードパーティーソリューションなどのツールを設定して、標準化された場所にアクセスできるようにします。 これらのツールをセキュリティツール用アカウント外で動作するように設定し、ログアーカイブアカウントへのクロスアカウントの読み取りアクセス権を適宜設定します。[Amazon Security Lake にサブスクライバーを作成](https://docs.aws.amazon.com/security-lake/latest/userguide/subscriber-management.html)し、これらのツールからデータにアクセスできるようにします。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP01 アカウントを使用してワークロードを分ける](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_multi_accounts.html)
+ [SEC07-BP04 データのライフサイクル管理を定義する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_lifecycle_management.html)
+ [SEC08-BP04 アクセスコントロールを適用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_rest_access_control.html)
+ [OPS08-BP02 ワークロードログを分析する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_workload_observability_analyze_workload_logs.html)
**関連ドキュメント:**
+ [AWS ホワイトペーパー: 複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS Prescriptive Guidance: AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html)
+ [AWS Prescriptive Guidance: Logging and monitoring guide for application owners](https://docs.aws.amazon.com/prescriptive-guidance/latest/logging-monitoring-for-application-owners/introduction.html)
**関連する例:**
+ [Amazon Athena と Quick を使用して分散ソースからのログデータを集約、検索、視覚化する](https://aws.amazon.com/blogs/security/aggregating-searching-and-visualizing-log-data-from-distributed-sources-with-amazon-athena-and-amazon-quicksight/)
+ [Amazon Security Lake の調査結果を Quick で視覚化する方法](https://aws.amazon.com/blogs/security/how-to-visualize-amazon-security-lake-findings-with-amazon-quicksight/)
+ [Generate AI powered insights for Amazon Security Lake using Amazon SageMaker AI Studio and Amazon Bedrock](https://aws.amazon.com/blogs/security/generate-ai-powered-insights-for-amazon-security-lake-using-amazon-sagemaker-studio-and-amazon-bedrock/)
+ [Identify cybersecurity anomalies in your Amazon Security Lake data using Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/identify-cybersecurity-anomalies-in-your-amazon-security-lake-data-using-amazon-sagemaker/)
+ [Ingest, transform, and deliver events published by Amazon Security Lake to Amazon OpenSearch Service](https://aws.amazon.com/blogs/big-data/ingest-transform-and-deliver-events-published-by-amazon-security-lake-to-amazon-opensearch-service/)
+ [CloudTrail Lake での自然言語クエリ生成による AWS CloudTrail ログ分析の簡素化](https://aws.amazon.com/blogs/aws/simplify-aws-cloudtrail-log-analysis-with-natural-language-query-generation-in-cloudtrail-lake-preview/)
**関連ツール:**
+ [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)
+ [Amazon Security Lake のパートナー](https://aws.amazon.com/security-lake/partners/)
+ [Open Cybersecurity Schema Framework (OCSF)](https://github.com/ocsf)
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [Amazon Bedrock](https://aws.amazon.com/bedrock/)
# SEC04-BP03 セキュリティアラートを相関付けて充実させる
予期しないアクティビティが検知されると、さまざまなソースがそれぞれのセキュリティアラートを発します。状況を完全に理解するには、それらをさらに関連付けて情報を強化 (エンリッチメント) しなくてはなりません。セキュリティアラートの関連付けとエンリッチメントを自動化すると、インシデントの特定と対応をより正確に行えるようになります。
**期待される成果:** アクティビティによってワークロードや環境内でさまざまなアラートが生成されると、自動メカニズムがデータを関連付け、補足情報によってそのデータを強化します。この前処理のおかげで、イベントについて詳しく把握できるようになり、調査員はイベントの重要度や、正式な対応を必要とするインシデントであるかどうかを判断できます。これにより、監視チームと調査チームの負担が軽減します。
**一般的なアンチパターン:**
+ 職務分掌の要件で別途義務付けられているわけでもないのに、さまざまなグループの人員がさまざまなシステムによって生成された検出結果やアラートを調査している。
+ 組織はセキュリティ検出結果と警告データをすべて標準の保存先に集めているが、相関付けやエンリッチメントは調査員が手作業で行う必要がある。
+ 検出結果の報告と重要度の決定は、脅威検出システムのインテリジェンスのみに頼っている。
**このベストプラクティスを活用するメリット:** アラートの関連付けや強化を自動化すると、調査担当者に求められる認知的な負担や手作業によるデータ準備を、全体的に減らすことができます。これにより、イベントがインシデントを示唆しているかどうかを判断し、正式な対応に着手するまでにかかる時間を短縮できます。また、文脈が補足されることで、イベントの実際の重大度を正確に評価できます。実際の重大度は、1 つのアラートが示す重大度よりも高い場合や低い場合が考えられます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
セキュリティアラートは、次のような AWS 内のさまざまなソースが生成する可能性があります。
+ [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/)、[AWS Identity and Access Management 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) などのサービス。
+ [Amazon OpenSearch Service のセキュリティ分析](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/security-analytics.html)など、AWS サービス、インフラストラクチャ、アプリケーションログの自動分析から発せられたアラート。
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch)、[Amazon EventBridge](https://aws.amazon.com/eventbridge/)、[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) などのソースからの、請求アクティビティの変化に反応したアラート。
+ 脅威インテリジェンスのフィードや AWS Partner Networkの[セキュリティパートナーソリューション](https://aws.amazon.com/security/partner-solutions/)など、サードパーティーのソース。
+ [AWS Trust & Safety](https://repost.aws/knowledge-center/aws-abuse-report)、または顧客や従業員などその他のソースからの連絡。
+ [Threat Technique Catalog by AWS (TTC)](https://aws.amazon.com/blogs/security/aws-cirt-announces-the-launch-of-the-threat-technique-catalog-for-aws/) を使用して、侵害インジケータ (IoC) 識別による脅威アクターの行動の特定と相関を支援します。TTC は、MITRE ATT&CK フレームワークの拡張であり、AWS リソースを対象とするすべての既知の脅威アクターの動作と手法を分類します。
アラートには、最も基本的な形式で、誰が (*プリンシパル*または*アイデンティティ*)、何を *(*実行された*アクション*)、何に (影響を受ける*リソース*) 対して行っているか、という情報が含まれます。これらのソースごとに、相関付けの土台として、アイデンティティ、アクション、リソースの識別子間のマッピングを作成する方法があるかどうかを確認してください。例えば、アラートソースをセキュリティ情報とイベント管理 (SIEM) ツールと統合して相関付けを自動で行う、独自のデータパイプラインを構築して処理する、またはその両方を組み合わせるという形が考えられます。
ユーザーに代わって関連付けを行うサービスの代表的な例が [Amazon Detective](https://aws.amazon.com/detective) です。Detective は、AWS やサードパーティーのさまざまなソースからのアラートを継続的に取り込み、さまざまな形式のインテリジェンスを使用してそれらの関係を視覚的にグラフ化して調査に役立てます。
アラートの初期の重要度は優先順位付けに役立ちますが、実際の重要度はアラートが発生した文脈によって決まります。例えば、[Amazon GuardDuty](https://aws.amazon.com/guardduty/) が、ワークロード内の Amazon EC2 インスタンスが想定されていないドメイン名をクエリしたとしてアラートを発したとします。GuardDuty は、このアラートそれ自体には、重要度を「低」と判定しています。ただし、アラートの発生前後の他のアクティビティと自動で相関付けた結果、数百の EC2 インスタンスが同じアイデンティティによってデプロイされていて、全体的な運用コストが増加していることが判明しました。この場合、これの関連付けられたイベントのコンテキストを新しいセキュリティアラートとして公開し、重要度を「高」に調整する可能性があります。これを受けて、その後のアクションが迅速化します。
### 実装手順
1. セキュリティアラート情報のソースを特定します。これらのシステムからのアラートがアイデンティティ、アクション、リソースをどのように表すかを理解して、どこで相関付けることができるかを判断してください。
1. さまざまなソースからのアラートを取りまとめるメカニズムを確立します。この用途では、Security Hub CSPM、EventBridge、CloudWatch などのサービスを利用することを検討します。
1. データの相関付けとエンリッチメントのためのソースを特定します。ソースの例には、[AWS CloudTrail](https://aws.amazon.com/cloudtrail/)、[VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)、[Route 53 Resolver ログ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)、インフラストラクチャ、およびアプリケーションログなどがあります。[Amazon Security Lake](https://aws.amazon.com/security-lake/) との統合により、これらのログのすべてまたは一部が消費される可能性があります。
1. アラートをデータの相関付けやエンリッチメントのソースと統合して、セキュリティイベントのより詳細な文脈を作成し、重要度を設定します。
1. Amazon Detective、SIEM ツール、その他のサードパーティーソリューションでは、一定レベルの取り込み、相関付け、エンリッチメントを自動的に実行できます。
1. AWS サービスを使用して独自に構築することもできます。例えば、AWS Lambda 関数を呼び出して Amazon Athena クエリを AWS CloudTrail や Amazon Security Lake に対して実行し、結果を EventBridge にパブリッシュできます。
## リソース
**関連するベストプラクティス:**
+ [SEC10-BP03 フォレンジック機能を備える](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html)
+ [OPS08-BP04 実践的なアラートを作成する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_workload_observability_create_alerts.html)
+ [REL06-BP03 通知を送信する (リアルタイム処理とアラーム)](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_monitor_aws_resources_notification_monitor.html)
**関連ドキュメント:**
+ [AWS セキュリティインシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**関連する例:**
+ [How to enrich AWS Security Hub CSPM findings with account metadata](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/)
**関連ツール:**
+ [Amazon Detective](https://aws.amazon.com/detective/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [Amazon Athena](https://aws.amazon.com/athena/)
# SEC04-BP04 非準拠リソースの修復を開始する
発見的統制は、構成要件に準拠していないリソースについて警告する場合があります。プログラムで定義された修復を手動または自動で開始して、該当するリソースを修正し、潜在的な影響を最小限に抑えることができます。プログラムで修復手順を定義しておくと、迅速に一貫した対応をすることができます。
自動化によってセキュリティの運用を強化できますが、自動化の実装と管理は慎重に行う必要があります。 適切な監視と統制のメカニズムを導入して、自動対応が効果的かつ正確であり、組織の方針やリスクアペタイトに合致していることを検証します。
**期待される成果:** リソース構成の標準を定義し、リソースが非準拠であることが検出された場合の修復手順も定義します。可能な場合は、修復手順をプログラムで定義して、手動または自動で開始できるようにしておきます。検知システムが導入されていて、このシステムが非準拠リソースを検知して、セキュリティ担当者が監視している一元管理ツールにアラートを発行します。これらのツールは、プログラムによる修復の手動実行または自動実行に対応しています。自動修復については、適切な監視と統制のメカニズムが導入され、その使用が管理されています。
**一般的なアンチパターン:**
+ 自動化を実装しているが、修復アクションを徹底的にテストおよび検証できていない。正当な事業運営が中断されたり、システムが不安定になったりといった、意図しない結果が生じる可能性があります。
+ 自動化によって応答時間と手続きは改善されたが、適切な監視や、必要に応じて人間が介入して判断できるメカニズムが欠如している。
+ 修復だけに頼り、インシデント対応および復旧プログラムという広い枠組みの中に修復を組み込んでいない。
**このベストプラクティスを活用するメリット:** 自動修復は、手動プロセスよりも迅速に構成ミスに対応できるため、潜在的なビジネスへの影響が最小限に抑えられ、意図しない使用の可能性が低くなります。修復をプログラムで定義しておけば、一貫して適用されるため、人為的ミスのリスクが軽減されます。また、自動化により大量のアラートを同時に処理することもできます。これは、大規模な運用環境では特に重要です。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
「[SEC01-BP03 管理目標を特定および検証する:](sec_securely_operate_control_objectives.md)」で説明したように、 [AWS Config](https://aws.amazon.com/config/) や [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) などのサービスは、アカウント内のリソースの構成が要件に準拠しているかどうかを監視するのに役立ちます。非準拠のリソースが検出された場合、AWS Security Hub CSPM などのサービスは、アラートの適切なルーティングと修復に役立ちます。これらのソリューションは、セキュリティ調査員が問題を監視して是正措置を講じるための中心的な場所となります。
AWS Security Hub CSPM に加えて、AWS は [Security Hub Advanced](https://aws.amazon.com/security-hub/) を導入しました。re:Invent 2025 で発表されたこのサービスは、組織が最も重要なセキュリティ問題を優先し、クラウド環境を保護するために大規模に対応する方法を変革します。拡張 Security Hub は、高度な分析を使用して、クラウド環境全体のセキュリティシグナルを自動的に関連付け、強化、優先順位付けするようになりました。Security Hub は、[Amazon GuardDuty](https://aws.amazon.com/guardduty/)、[Amazon Inspector](https://aws.amazon.com/inspector/)、[Amazon Macie](https://aws.amazon.com/macie/)、および [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/cspm/features/) とシームレスに統合されます。Security Hub の相関的な検出結果は、各リソースで見つかった脆弱性に基づいて想定される攻撃パスを含む、露出検出結果と呼ばれるまったく新しい検出結果になる可能性があります。
非準拠リソースの中には、状況が独特で修復には人間の判断が必要となる場合がありますが、プログラムで定義できる標準的な対応で間に合う状況もあります。例えば、VPC セキュリティグループが誤って設定されている場合、標準的な対応として、許可されていないルールを削除して所有者に通知することができます。応答は、[AWS Lambda](https://aws.amazon.com/pm/lambda) 関数や [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) ドキュメントで定義するか、任意の他のコード環境で定義できます。是正措置を行うために必要最低限のアクセス許可しか持たない IAM ロールを使用して、その環境を AWS に対して認証できるようにしてください。
必要な修復手順を定義したら、その修復を開始する希望の方法を決定できます。AWS Config は[修復を自動で開始](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)できます。Security Hub CSPM を使用している場合は、この目的で[カスタムアクション](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cwe-custom-actions.html)を使用し、検出結果の情報を [Amazon EventBridge](https://aws.amazon.com/eventbridge/) に公開できます。それを受けて、EventBridge ルールで修復を開始できます。Security Hub CSPM で修正を設定し、自動または手動で実行できます。
プログラムによる修復では、実行されたアクションとその結果について包括的なログ記録と監査を行うことをお勧めします。 これらのログを確認および分析して、自動化プロセスの有効性を評価し、改善すべき部分を特定します。ログは [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) に記録し、修復結果は Security Hub CSPM に[検出結果メモ](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html)として記録します。
手始めに、[AWS での自動化されたセキュリティ対応](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)を検討してください。よくあるセキュリティの構成ミスを解決する修復機能が事前に組み込まれています。
### 実装手順
1. アラートを分析して優先順位を付けます。
1. さまざまな AWS サービスから届くセキュリティアラートを Security Hub CSPM に統合して、可視化、優先順位付け、修復を一元的に行います。
1. 修復手順を考案します。
1. Systems Manager や AWS Lambda などのサービスを使用して、プログラムによる修復を実行します。
1. 修復の開始方法を設定します。
1. Systems Manager を使用して、検出結果を EventBridge に公開するカスタムアクションを定義します。これらのアクションを手動または自動で開始するように設定します。
1. また、[Amazon Simple Notification Service (SNS)](https://aws.amazon.com/sns/) を使用して、関連するステークホルダー (セキュリティチームやインシデント対応チームなど) に通知やアラートを送信し、必要に応じて手動による介入やエスカレーションを行うこともできます。
1. 修復ログを確認して分析し、有効性と改善点を検討します。
1. ログ出力を CloudWatch Logs に送信します。結果を Security Hub CSPM に検出結果メモとして記録します。
## リソース
**関連するベストプラクティス:**
+ [SEC06-BP03 手動管理とインタラクティブアクセスを削減する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html)
**関連ドキュメント:**
+ [AWS Security Incident Response Guide - Detection](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/detection.html)
**関連する例:**
+ [ での自動化されたセキュリティ対応AWS](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)
+ [Monitor EC2 instance key pairs using AWS Config](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-ec2-instance-key-pairs-using-aws-config.html)
+ [Create AWS Config custom rules by using AWS CloudFormation Guard policies](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-aws-config-custom-rules-by-using-aws-cloudformation-guard-policies.html)
+ [Automatically remediate unencrypted Amazon RDS DB instances and clusters](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automatically-remediate-unencrypted-amazon-rds-db-instances-and-clusters.html)
**関連ツール:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [ での自動化されたセキュリティ対応AWS](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)