AWSは、ID管理・ストレージ・ネットワーク・DNSログを横断してシグナルを関連付けることで、セキュリティチームが多段階のクラウド攻撃を特定する方法を明らかにしました。
単一のセキュリティアラートは、何か異常が発生したことを示すにすぎません。しかし、攻撃者が一つの行動だけで止まることはほとんどありません。
盗まれた認証情報は、クラウドリソースの探索、権限昇格、アカウント間の横移動、機密データへのアクセス、そして環境外へのデータ送信に悪用される可能性があります。
これらのイベントを相関分析することで、防御側は個別のアラートを一つずつ処理するのではなく、攻撃の全体像を把握できるようになります。
たとえば、あるIDが未知のIPアドレスからGetCallerIdentityを呼び出したとします。その数分後、同じIDがAWSの複数サービスにわたって多数のList、Describe、Getアクションを実行し、その中にはAccessDeniedと記録された失敗リクエストも含まれることがあります。
その後、新規登録されたドメインへの大量のアウトバウンドデータ転送が発生すれば、データ流出の可能性を示唆します。
Amazon GuardDutyは、AWS CloudTrail、Amazon S3データイベント、VPCフローログ、DNSログ、ランタイムデータなど、さまざまなソースを用いてこうしたシグナルの多くを検出できます。
GuardDuty Extended Threat Detectionは、認証情報の侵害に続くデータ窃取など、一部の活動を自動的に相関付けて重大度の高い攻撃シーケンスとしてまとめることができます。
さらに、タイムライン、MITRE ATT&CKへのマッピング、修復ガイダンスも提供します。
AWSによると、自動検出サービスは多くの顧客環境に共通するパターンを識別するとのことです。
しかし、これらのサービスは、どのS3バケットに機密データが格納されているか、どのIAMロールがそこにアクセスすべきか、どのロール引き受け経路が承認されているか、あるいは本番環境の変更がいつ許可されるかまでは把握していません。
こうしたビジネスコンテキストがあってこそ、一見正常に見えるクラウド上の活動を意味のあるアラートに変えることができます。
セキュリティチームは、CloudTrail、VPCフローログ、Route 53 Resolverのクエリログを用いて、Amazon CloudWatch Logs Insights上で独自の相関分析ルールを構築できます。
一例として、想定外のIAMプリンシパルによる機密S3バケットからの大量読み取りの検出が挙げられます。
チームは大量のGetObjectイベントを特定し、そのプリンシパルを承認済み読み取り者リストと照合したうえで、同じ送信元が異常に大きなアウトバウンドネットワークトラフィックを発生させていないかを確認できます。
監視対象のS3バケットについては、CloudTrailのデータイベントを有効化しておく必要があります。管理イベントだけではGetObjectの活動は記録されないためです。
AWSが推奨しているのは、通常時のアクセス状況を時間をかけてベースライン化し、一般的な活動量を上回る水準にアラートの閾値を設定することで、誤検知を減らすという方法です。
AWSは、サービス横断の相関分析における主要なキーとしてIDを追跡することを推奨しています。また、自動化された活動は数分以内に発生する一方、手動での偵察活動は数時間から数日かけて展開されることがあるため、アナリストは攻撃ごとに適切な時間枠を設定して分析すべきだとしています。
組織は、AWS Lambda、Amazon EventBridge Scheduler、Amazon SNS、AWS Security Hubを用いて検出ロジックを自動化できます。
Lambda関数は、想定外の大量S3アクセスについてCloudTrailログを照会し、EC2に紐づくロールをそのプライベートIPアドレスにマッピングし、VPCフローログで大規模な外部転送がないかを確認したうえで、両方のシグナルが一致した場合にアラートを送信できます。
より大規模な環境では、AWSはAmazon Security Lakeを通じてテレメトリを一元化するか、Amazon Athenaを使って長期保存されたレコードを照会することを提案しています。データはOpen Cybersecurity Schema Frameworkを用いて正規化することも可能です。
ANY.RUNのブラウザ内データ検査で、より迅速な検知・調査・対応を実現-> ANY.RUNでSOCを強化
翻訳元: https://cyberpress.org/detecting-multi-stage-aws-attacks/
