本文の内容は、2022年7月11日にMichael Isbitskiが投稿したブログ(https://sysdig.com/blog/detecting-suspicious-activity-on-aws-using-cloud-logs/)を元に日本語に翻訳・再構成した内容となっております。
私たちはAWS re:Inforce 2022に参加し、Falcoの詳細とFargateサーバーレスコンピュートの複雑さについて議論する予定です。
AWSは、大きなスペクトルのサービスとコンピュートを提供しています。クラウドにおける「責任共有」モデルは、組織の責任とクラウドプロバイダーの責任という単純化された構造を提示します。一般的には、アイデンティティとアクセス管理（IAM）、アプリケーション、およびデータが境界線を形成しますが、組織が消費する所定のクラウドサービスによって境界線は曖昧になります。これは、AWSのShared Responsibility Modelを含む、すべてのクラウドプロバイダーに当てはまります。
ブース404にお立ち寄りいただくか、フォームにご記入いただければ、私たちのエキスパートがお客様の組織の脅威や攻撃について話し合う時間を確保します。
デプロイミス、設定ミス、脆弱なAMIやコンテナイメージの使用、AWSサービス設定へのその他の変更は、組織にセキュリティ問題を引き起こし、セキュリティ事故や侵害の可能性にさらします。ランサムウェア攻撃、権限昇格、システム侵害、データ漏洩、悪意のある暗号化、その他の悪影響に関する話には事欠きません。
クラウドへの攻撃のメカニズムをより深く掘り下げたい方は、ガイドをお読みください。クラウドやコンテナ環境でリスクの高いイベントを検出することは、しばしば干し草の山から針を見つけるようなものだと表現されます。AWSはいくつかのネイティブツールを提供していますが、そのうちのいくつかは追加コストがかかります。多くの組織がデータの過負荷に苦しんでおり、セキュリティプログラムの有効性とセキュリティイベントへの迅速な対応能力に直接影響を与えています。
CloudTrailでカバーできるのでは？
CloudTrailは、AWSのほとんどのサービスを支える、ユビキタスでフルマネージドのロギングサービスです。ユーザーID、マシンID、その他のAWSサービスによって実行されたすべてのアクションは、イベントとして記録されます。最新のイベント履歴は、CloudTrailに保存され、自動的に表示されます。しかし、より長い保持期間のために、組織は Trail（AWS S3汎用ストレージを使用）または Lake（他のAWSマネージドストレージを使用）を構成する必要があります。これらは覚えておくべき重要な違いです。CloudTrailはデフォルトで有効であり、最近のイベント履歴は当然ですが、ほとんどの組織はコンプライアンスを満たすため、拡張監査証跡を維持するため、またはデジタルフォレンジックとインシデントレスポンス（DFIR）などのセキュリティユースケースをサポートするために拡張リテンションを必要とします。場合によっては、ログに負荷がかかりすぎてクラウドの費用がかさむのを避けるために、この追加ステップを軽視したり、意図的にスキップしたりすることがあります。
CloudTrailのベストプラクティスは以下の通りです：
- すべての組織のAWSアカウントとリージョンに対してCloudTrailを構成する。
- CloudTrailのログファイルを暗号化する。
- CloudTrailのログファイルの整合性検証を有効にする。
AWSにおけるオーガナイゼーションのアーキテクチャーと様々なAWSサービスの利用が増加すると、イベントの量とそれぞれのログサイズが指数関数的に増加する可能性があります。この現実は、組織がより高度な自動化を採用し、マイクロサービス・アーキテクチャーを採用し、APIベースの設計を行う場合に特に顕著です。マシンのコミュニケーション量が急増し、コンテナ型やサーバーレス型のコンピュートのサポートがより短命になりつつあるためです。従来のデータセンター環境に存在したいくつかの問題は、利用可能なディスク容量によるストレージの厳しい制限など、クラウドではそれほど問題ではなくなりましたが、新しい問題がそれに取って代わりました。膨大な量のログデータは、ほとんどの組織のITチームやセキュリティ・チームをあっという間に圧倒してしまいます。
どのイベントが実際の脅威なのか、どのように判断するのでしょうか？
組織は、多くの場合、複数の標準、フレームワーク、ベストプラクティス、および規制要件に依存して、独自のセキュアなデフォルトを作成しています。設計、開発、ビルド、配布の段階で設定を検証し、実施するために、さまざまなアプローチやツールが使用され、さらに、本番環境でも継続的に使用されます。一般的なセキュリティ活動には、IaCスキャン、イメージ・セキュリティ・スキャン、インフラストラクチャー・スキャン、クラウド・ポスチャー評価、ランタイム・プロファイリング、ランタイム検知・対応などがあります。本番環境で発生した事象の実際のセキュリティリスクを判断するには、組織の環境にとって何が「正常」であるべきかを知るための適切なベースラインが必要です。既知の脆弱性（CVE-ID など）、設定ミス、脅威要因（TI フィードに定義された脅威な ど）は確かに手始めではあるものの、アプリケーションの活動、データアクセス、及びアイデンティティの 行動は、各組織にとって固有のものとなります。
コンテキストは、多くのセキュリティ上の意思決定において重要ですが、クラウドやコンテナの実稼働環境における検出と対応において、非常に重要になります。
一般的な環境におけるイベントやログは、潜在的に危険なものである可能性がありますが、組織独自の環境やアーキテクチャーでは予期されるものである可能性もあります。例えば、AWS S3バケットの作成や削除が行われるのは普通のことかもしれませんが、これは特権ユーザー（マシンIDではない）によって開始され、コンテナ化されたワークロードから発生したものではない場合にのみ当てはまるはずです。このような活動は、組織のオンプレミスデータセンターやVPNなど、信頼できるIPアドレス範囲からのAWS CLIまたは適切なAPIコールによってのみ期待されるかもしれません。
CloudTrailはAWS環境内のすべてのイベントをキャプチャーしますが、CloudTrailには安全なイベントと危険なイベントの概念がありません。また、CloudTrailには固有のアラート機能がありません。アラート、脅威検知、フォレンジック、インシデントレスポンス、脅威ハンティングなどのセキュリティユースケースをサポートするために、実務者はCloudTrailを中心にエンジニアリングを行う必要があります。
ストリーム検知は脅威の検知にどのように役立つのでしょうか？
組織は、クラウド環境における設定ミスを検出するために、さまざまなアプローチを試みていますが、それぞれに潜在的な落とし穴があります。- クラウドセキュリティポスチャー管理（CSPM） – APIポーリングなどのスキャンプロセスを一定の間隔で使用し、AWSアカウント内のすべてのサービス設定を繰り返し確認します。これらのスナップショットを収集して分析し、不一致を発見するには時間がかかります。ポーリングの間隔は、場合によっては24時間から36時間程度になることもあります。スナップショットが取得された後に攻撃者がテナントの改ざんや悪用に成功した場合、CSPMは次のポーリング間隔までそのイベントを検出しません。
- ネイティブのクラウドプロバイダー構成分析 – CSPMと同様に、これらのオプションでは、多くの場合、ポーリング間隔によるスナップショット方式が採用されています。例えば、AWS Security Hubは12時間のレイテンシーがあり、企業にとって大きなリスクとなる可能性があります。
- SIEMへの取り込みとアラート – SIEMにログファイルをエクスポートすると、ログの保存と分析にさらなる処理時間と費用がかかる可能性があります。SIEM は、クラウドやコンテナのイベントだけでなく、メールフィッシングやランサムウェア攻撃など、さまざまなイベントに対して意味のあるシグナルを生成できることを期待して、すでにデータに過負荷をかけている可能性があります。このアプローチでは、すべてのイベントが疑わしいとみなされる可能性があるため、暴露の窓と同じようにアラートの過負荷に悩まされる可能性もあります。クラウドとコンテナのデータを大規模に取り込むと、ほとんどの場合、MTTD と MTTR が遅くなるという問題が悪化します。
- 手動ログファイル分析または脅威ハンティング – その名が示すように、検知は、セキュリティアナリストの専門知識と、イベントのノイズから意味のある信号を発掘する能力のみに基づいています。
効果的なクラウドの検出および対応機能は、脅威を示すイベントがCloudTrailに表示された時点で、実用的なアラートを発する必要があります。また、このような検知機能は、セキュリティ予算に影響を与えるようなコストや、不必要な露出の窓を作るような遅延を追加するものであってはなりません。テレメトリー収集のためのSysdigと統一された脅威検知エンジンとしてのFalcoの組み合わせは、ストリーム検知のアプローチを強化することができます。Falcoは、柔軟なセキュリティルールのセットに対してリアルタイムですべてのCloudTrailエントリーを評価することができます。これらのルールは、他のアプローチに内在する遅延なしに、組織のサイバーセキュリティの目標をサポートするために、警告を発したり、適切な対応措置を取ったりすることができます。
FINRAのセキュリティのユースケースと、クラウドセキュリティとコンテナセキュリティの課題に対してSysdigの技術でどのように対処したかについて、SysdigとFINRAの共同インタビューをご覧ください。
