SEC04-BP02 標準化した場所にログ、検出結果、メトリクスを取り込む - セキュリティの柱
実装のガイダンス実装手順リソース

SEC04-BP02 標準化した場所にログ、検出結果、メトリクスを取り込む

セキュリティチームは、ログと検出結果に基づいて、不正なアクティビティや意図しない変更を示唆する可能性があるイベントを分析します。この分析の効率を高めるため、標準化した場所にセキュリティログや検出結果を集めてください。 重要なデータポイントを相関のために使えるようになり、ツールの統合を簡素化できます。

期待される成果: ログデータ、検出結果、メトリクスの収集、分析、視覚化に、標準化された方法を使用できます。セキュリティチームは、さまざまなシステムから集めたセキュリティデータを効率的に相関付けて分析し、視覚化して、潜在的なセキュリティイベントを発見し、異常を検知できます。セキュリティ情報とイベント管理 (SIEM) システムやその他のメカニズムを統合してログデータを照会および分析し、セキュリティイベントに対し適時の対応、追跡、エスカレーションを行います。

一般的なアンチパターン:

  • チームがそれぞれ独自にログやメトリクスのコレクションを所有および管理していて、それが組織のログ記録の戦略と矛盾している。

  • チームが収集したデータの表示と変更を制限するための十分なアクセス制御を実施していない。

  • チームがセキュリティログ、検出結果、メトリクスをデータ分類ポリシーに則って管理していない。

  • チームがデータ収集の設定時に、データ主権とローカリゼーションの要件を無視している。

このベストプラクティスを活用するメリット: 標準化されたログ記録ソリューションを使用してログデータやイベントを収集しクエリすることで、ログに含まれる情報からより良いインサイトを引き出すことができます。収集したログデータに対して自動ライフサイクルを設定することで、ログの保管にかかるコストを削減できます。収集されたログ情報に対して、データの機密性とチームが求めるアクセスパターンに応じて、きめ細かくアクセスを制御できます。ツールを統合して、データを相関付け、視覚化し、データからインサイトを引き出すことができます。

このベストプラクティスを活用しない場合のリスクレベル: 中

実装のガイダンス

組織内で AWS の使用量が増えれば、分散したワークロードと環境の数が増えます。これらのワークロードと環境が各々、その中のアクティビティに関するデータを生成するため、そのデータを取り込んでローカルに保存することが、セキュリティ運用にとって課題となります。セキュリティチームは、セキュリティ情報とイベント管理 (SIEM) システムなどのツールを使用して、分散したソースからデータを収集し、相関付け、分析、対応のワークフローを実行します。そのためには、さまざまなデータソースにアクセスするための複雑な許可一式を管理する必要があり、抽出、変換、ロード (ETL) プロセスの運用における追加のオーバーヘッドも生じます。

こうした課題を解消するには、セキュリティログデータの関連ソースをすべて、ログアーカイブアカウントに集約することを検討します。詳細については「複数のアカウントで AWS 環境を構成する」を参照してください。これには、ワークロードのすべてのセキュリティ関連データと、AWS CloudTrail、AWS WAF、Elastic Load Balancing、Amazon Route 53 などの AWS サービスによって生成されるログが含まれます。このデータを個別の AWS アカウントの標準化した場所に保存し、適切なクロスアカウントアクセス許可を設定しておくことには、利点がいくつかあります。ワークロードや環境が侵害された場合にその内部でのログの改ざん防止に役立ち、追加のツールの統合先を一元化できるだけでなく、データ保持とライフサイクルの設定モデルを簡素化できます。 データ主権、コンプライアンス範囲、その他の規制の影響を評価して、セキュリティデータの保管場所と保持期間を複数設ける必要があるかどうかを判断します。

ログと検出結果をすぐに取り込んで標準化できるようにするため、ログアーカイブアカウントの Amazon Security Lake を評価します。Security Lake で、CloudTrail、Route 53、Amazon EKS、VPC フローログなどの一般的なソースから自動的にデータを取り込むように設定できます。AWS Security Hub を Security Lake のデータソースとして設定することで、Amazon GuardDuty や Amazon Inspector など他の AWS サービスの検出結果をログデータに関連付けることもできます。 サードパーティーのデータソース統合を利用したり、カスタムのデータソースを設定することもできます。すべての統合により、データが Open Cybersecurity Schema Framework (OCSF) フォーマットに標準化され、Amazon S3 バケットに Parquet ファイルとして保存されるため、ETL 処理は不要になります。

セキュリティデータを標準化された場所に保存することで、高度な分析機能を使用できるようになります。AWS は、AWS 環境で動作するセキュリティ分析ツールを、ログアーカイブのアカウントとは別のセキュリティツール用アカウントにデプロイすることを推奨しています。 このアプローチなら、細かい統制を実装し、ログとログ管理プロセスの整合性と可用性を、ログにアクセスするツールとは別個に保護できます。 Amazon Athena などのサービスを使用して、複数のデータソースを関連付けるオンデマンドクエリを実行することを検討します。Amazon QuickSight などの視覚化ツールを組み込むこともできます。AI を活用したソリューションがますます普及し、検出結果を人間が読める要約や自然言語での対話に変換するなどの機能を提供しています。 これらのソリューションは多くの場合、標準化したデータ保存場所をクエリ用に用意することで統合しやすくなります。

実装手順

  1. ログアーカイブアカウントとセキュリティツール用アカウントを作成する

    1. AWS Organizations を使用して、セキュリティ組織単位の下にログアーカイブアカウントとセキュリティツール用アカウントを作成します。AWS Control Tower を使用して組織を管理している場合、ログアーカイブアカウントとセキュリティツール用アカウントが自動的に作成されます。必要に応じて、これらのアカウントにアクセスして管理するためのロールとアクセス許可を設定します。

  2. セキュリティデータの標準化した保存場所を設定する

    1. セキュリティデータの標準化した保存場所の作成戦略を決定します。 これは、一般的なデータレイクアーキテクチャのアプローチ、サードパーティーのデータ製品、Amazon Security Lake などのオプションを使用して実行できます。AWS では、アカウント用にオプトインしている AWS リージョンからも、積極的に使用していない場合でもセキュリティデータを取得することを推奨しています。

  3. 標準化した保存場所へのデータソースの公開を設定する

    1. セキュリティデータのソースを特定し、標準化された場所に公開するように設定します。ETL プロセスの開発が必要な形式ではなく、希望する形式でデータを自動的にエクスポートする方法を検討します。Amazon Security Lake を使用すると、サポートされている AWS ソースや統合されたサードパーティーシステムからデータを収集できます。

  4. 標準化した場所にアクセスするためのツールを設定する

    1. Amazon Athena、Amazon QuickSight、サードパーティーソリューションなどのツールを設定して、標準化した場所にアクセスできるようにします。 これらのツールをセキュリティツール用アカウント外で動作するように設定し、ログアーカイブアカウントへのクロスアカウントの読み取りアクセス権を適宜設定します。Amazon Security Lake にサブスクライバーを作成し、これらのツールからデータにアクセスできるようにします。

リソース

関連するベストプラクティス:

関連ドキュメント:

関連する例:

関連ツール: