Threat Stackテレメトリによるセキュリティの強化
Threat StackがF5 Distributed Cloud App Infrastructure Protection（AIP）になりました。ぜひDistributed Cloud AIPをお試しください。
Threat Stackの深く継続的なテレメトリには、多くの価値があります。広い範囲から収集することで、お客様は、包括的なセキュリティ データに基づいて、自社のクラウド環境で何が起こっているかを完全に知ることができます。もちろん、お客様がこのデータを常に詳しく調べているわけではありません。しかし、本当に必要なとき、すなわち侵害発生後やコンプライアンスの演習時に、当社の詳細なテレメトリにより、フォレンジック調査を迅速に行い、監査者向けのアーティファクトを容易に作成することが可能になります。
しかし、このテレメトリはどのようなもので、どのような将来のユース ケースを想定して設計されているのでしょうか。この記事では、１つ目の問いに答え、2つ目については、当社が目指している目標について、いくつかのヒントを示します。
次の例では、一般的な攻撃者の手法をシミュレーションしています。EC2インスタンス メタデータ サービスを使用して環境で情報を収集し、深く掘り下げています。最初のステップとして、この例では、攻撃者が既に盗難したSSHキーを持っているものと仮定します。次に何が起こるかを見てみましょう。
調査とThreat Stackテレメトリ
Threat Stackで疑わしいEC2 Instance Metadata Communicationという高深刻度のアラートが表示されて、調査が開始されます。
情報ボタンを押すと、このアラートに関連するすべてのテレメトリが表示されます。
付記：ユーザーはさまざまな方法でそれぞれの環境に合わせてアラートをカスタマイズできます。実際には、ここで見られるダウンストリーム動作の多くが、アラートの対象となり得ます。しかし説明を進めるために、ここでは、Threat Stackが記録する生のテレメトリに着目します。
このアラートからThreat StackのEvent Search機能にアクセスすると、この環境の過去3日間のアクティビティが全画面で表示されます。ここではagent_idを使用して、アラートをトリガーしたEC2インスタンスに注目し、SSHログイン アクティビティを探します。
UIを使用してタイムフレームを制限します。また、ここでは次のThreat Stack Event Searchクエリを使用します。
event_type = "login" AND agent_id = "436dd34c-f795-11ea-a752-21e3e3eb7c50"
アラートと同様に、Threat Stackのイベントで、基本的なテレメトリをすべて表示できます。
ログイン イベントを探し出したので、タイムスタンプを指定して検索ウィンドウをさらに絞り込むことができます。
ここで、クエリを使用して、より短い時間枠を調べる方法を示します（「エージェントベースのユーザー アクティビティの追跡方法」でこれらの手法を説明された、Threat Stackのセキュリティ アナリスト責任者Ethan Hansenに感謝いたします）。
agent_id = "436dd34c-f795-11ea-a752-21e3e3eb7c50" AND event_time >= 1600362902289 AND event_time <= 1600362992764
ログイン直後のユーザー アクションを見てみると、ユーザー「ubuntu」（Ubuntu AMIのデフォルトのAWS）が先に進み、権限を「root」に昇格したことがわかります。次に、時間枠を少し広げて、この攻撃者の足取りをさかのぼって調べます。
ここでは、多くのことが起こっています。最初に、攻撃者はサーバー上の認証情報ファイルを探しています。Linuxコマンドの実行は成功しますが、対応するファイルのOPENイベントがないので、認証情報ファイルは存在しないことがわかります。（Threat Stackは、FIMイベントのすべてのCRUD操作を監視します。）このEC2インスタンスではIAMロールを使用しているため、デフォルトの認証情報ファイルは存在しません。一般的にはこれはベスト プラクティスです。ただし、EC2にIAMロールを使用した場合の不十分なセキュリティが攻撃者に有利に働く可能性があることを後で説明します。
攻撃者は、このインスタンスに関連付けられたロールがあるはずだと考え、curl https://169.254.169.254/latest/meta-data/iam/infoを使用して、ロールの対象を確認します。攻撃者の次のステップは、AWS Command Line Interface（awscli）をインストールすることなので、ロール名は有望に見えたはずです。
調査を進めると、攻撃者がaws ec2 describe-instancesコマンドを発行したことがわかります。
Threat Stackが収集するAWS CloudTrailイベント ストリーム全体を確認すると、このロールが動作したかどうかがわかります。
このクエリの骨格は以下のとおりです。
event_type = "cloudtrail" AND userType = "AssumedRole"
「arnRole」がassumed-role/ec2VpcRole/i-08c9216f243e53fd4に設定されているので、このEC2インスタンス（インスタンスID i-08c9216f243e53fd4）が成功したことがわかります。そこで攻撃者は、どのようなロールがあり、どのようなSSHキーが関連付けられているかなど、環境内の他のEC2インスタンスの情報を収集します。
さらに調査を続け、ログイン イベントを探すと、疑わしい候補が見つかります。
基本のクエリは次のとおりです。
event_type = "login" AND event_time > 1600362961
ここで私は「agent_id」の値を取得し、次のクエリで、同じタイムスタンプとともに使用します。
簡潔にするため、この後のイベントは省略しますが、ここでは同じ動作が観察されます。つまり、権限がrootに昇格され、awscliがインストールされます。次に、メタデータ サービスの呼び出しをスキップし、awscliを使用してS3を探っています。
攻撃者はまず、このロールがS3でアクセスできるすべてのバケットをリストアップしようとしています。Threat StackのCloudTrailイベントを見ると、このインスタンスがこのロールを引き受けたかどうかを確認できます。
ここでは、assumed-role/myS3Reader/i-03128a5b8b894002aのarnRoleの値を見ることで、EC2インスタンスがS3にアクセスできることを確認できます。私はAWSの推奨に従って、S3バケットへの「すべてのパブリック アクセスをブロック」していることに注目してください。しかし、このインスタンスはプライベートVPC上にあるため、EC2インスタンスが固有のIAMロールを使用できる場合、この設定では保護されません。
その後のaws s3コマンドを見ると、さまざまなバケットを調べることができますが（詳細は省略）、攻撃者は最終的にターゲットを見つけています。
これで、次のようにいくつかの機密データがコピーされ、秘密は漏洩してしまいます：aws s3 cp s3://omg-my-cookies/secret-data.txt secret-data-copy.txt
今後リリース予定の異常検知：MLベースのインサイトを活用したフルスタックのテレメトリ
Threat Stackは、複数のランタイム システムのテレメトリを継続的に収集します。この例では、私たちはSSHログイン イベント、Linux Auditイベント、AWS CloudTrailイベントのみを使用しましたが、Threat Stackは、コンテナ、Kubernetes、Windowsサーバー、AWS Fargateなど、クラウド スタック全体にこの可視性を拡張します。
Threat Stackが保持する詳細なイベント データに基づいて、セキュリティ アナリストは、ログの収集や取得を省略し、フォレンジック調査（通常は、ここでシミュレーションした単純な例とは異なり、より入り組んでいます）にすぐに取りかかることができます。一方、豊富なデータを当社のモデルに取り込むことは、お客様にとって異常検知能力の向上を意味するため、当社では、機械学習でこのデータを活用する新たな方法も模索しています。
Threat Stackのリリース予定のML機能が幅広いセキュリティとコンプライアンスのユース ケースをどのように支援するかについては、Threat Stackのソフトウェア エンジニアMina Botrosによる「Apache SparkとAmazon EMRを使用したThreat Stackのデータ パイプラインの最適化」をご覧ください。また、近日中に予定されているThreat StackのML技術リリースの詳細情報もご確認ください。
Threat StackがF5 Distributed Cloud App Infrastructure Protection（AIP）になりました。ぜひDistributed Cloud AIPをお試しください。