CIS AWS Benchmark の モニタリング要件は GuardDuty + Sysdig でどこまでカバーできるのか？

はじめに

Kraken Hunter の村上です。

この記事はセキュリティチームの Sysdig 活用事例をテーマにした「Sysdigブログリレー」6日目の記事です。

先日、Sysdig Secure の脅威検知ポリシーに Amazon GuardDuty ポリシーが追加されました！

新しく追加された Amazon GuardDuty ポリシーを有効化すると、Amazon GuardDuty での検知を、Sysdig 上でも見ることができます。

Sysdig は元々 CloudTrail を使ったニアリアルタイムの脅威検知機能を備えています。
Sysdig が管理・提供する多数の検知ルールがあり、CloudTrail を Sysdig に連携する設定を行い、脅威検知ポリシー（検知ルールのセット）を有効化するだけで、簡単に脅威検知を始められます。

Amazon GuardDuty ポリシーと CloudTrail ベースの検知ポリシーの併用によって、AWS と Sysdig による脅威検知結果を合わせて見ることができるようになりました。

今回は、これらの脅威検知機能を使って、CIS Amazon Web Services Foundations Benchmark の Monitoring 要件への準拠を効率よく行えないか検討してみたので、ご紹介します。

CIS Benchmarks とは

CIS Benchmarks は Center of Internet Security (CIS) の定める、 OS やソフトウェア、クラウドの安全な設定を定めたフレームワークです。

クラウドの設定不備を防ぐための基準として、クラウドベンダーを横断したベストプラクティスとして利用できます。
https://www.cisecurity.org/cis-benchmarks

各クラウド別に具体的な設定ガイドラインがまとめられており、AWS の設定のベストプラクティスをまとめたものが、「CIS Amazon Web Services Foundations Benchmark」になります。
2024/09 現在、最新バージョンは v3.0.0 です。

簡略化のため、以下では「CIS Benchmark」はすべて「CIS Amazon Web Services Foundations Benchmark」の v3.0.0 を指すものとします。

Sysdig の CSPM 機能を使うと、CIS Benchmark に準拠しているかチェック可能です。
今回、セキュリティチームで運用している、とある AWS アカウントについてチェックをかけて設定修正をする中で、CIS Benchmark の Monitoring 要件の対応を検討しました。

CIS Benchmark の Monitoring のベストプラクティスに含まれるもの

CIS Benchmark の 4. Monitoring には、以下の項目が含まれています。

ログイン失敗や、意図しないバケット・ネットワーク公開に繋がりかねないリソース変更操作など、リスクのあるアクションがモニタリング設定対象としてピックアップされていることがわかります。

項目名末尾の『Manual』の意味

「Manual」は、ベストプラクティスに準拠しているかどうかのチェックを完全に自動化できないもの、「Automated」は自動チェックが可能なものです。

4.1〜4.15 のモニタリング要件は、対応方法が1つに定まらないため、自動でチェックができない Manual 扱いになっているようです。

自動チェック可能な 4.16 については、単に Security Hub を有効化するだけなので、以降は 4.1〜4.15 のみを見ていきます。

Sysdig で対応方法を見てみる

Sysdig による設定チェック結果の基本的な確認・対応の流れは、ブログリレー1日目の記事をご参照ください。

Sysdig で CIS Benchmark への準拠状況をチェックし、Remediation Guidelines を見てみると、CloudWatch にメトリクスフィルタやアラームを設定するためのコマンドが書かれています。

CIS Benchmarks のサイト から CIS Benchmark をダウンロードしてみると、同様の記載があったので、本家の記載を踏襲しているようです。

ただ、CIS Benchmark は必ず CloudWatch で設定するように推奨しているわけではなく、CloudTrail ログを外部の SIEM (Security Information and Event Management) に送ってモニタリングすることもできる、と記載されており、CloudWatch を使ったモニタリングはあくまで一例となっています。

CloudWatch でフィルタを設定しなくても、Amazon GuardDuty ポリシー + CloudTrail ベースの検知ポリシーで代用できないかどうかが気になったので、ドキュメントベースで調査してみました。

GuardDuty + Sysdig で CIS Benchmark のモニタリング要件をどこまでカバーできるのか

Amazon GuardDuty ポリシーのルールと CloudTrail ベースの検知ポリシーのルールでどこまで CIS Benchmark のモニタリング要件をカバーできそうか、まとめてみました。

なお、GuardDuty のルールについては、AWS 公式ドキュメントの中から、主に下記ページを参考に調査しました。
https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html

Sysdig は Sysdig UI 上でルールをチェックして記載しました。

いずれも、不定期にアップデートされていますので、実際に設定される際は最新のルールをご参照いただければと思います。

◯と記載した項目であっても、CloudWatch メトリクスフィルタでの設定を完全に再現しているわけではありませんが、目的に見合ったモニタリングができそうかという観点で判定しています。

各項目の判定理由などを詳しく見ていきます。

4.1 Ensure unauthorized API calls are monitored

悪意のあるアクティビティを検知し、セキュリティインシデントの可能性を素早く特定するためのコントロールです。

CIS Benchmark に記載の CloudWatch を使った例では、UnauthorizedOperation か AccessDenied となった API 呼び出しが 5分間に1回を超えたら、アラームを発報する設定のようです。（もう少し条件指定ありましたが割愛）

実際に運用するとなると、流石に閾値が低すぎてアラートが上がりまくりそうなので、上げた方が良さそうです。
（閾値の調整の必要性については、4.2 以降についても同様のため、以降は割愛します）

GuardDuty のドキュメント、Sysdig のルールには、アクセス失敗を検知しているようなルールの記載は見当たりませんでした。

アクセスが成功する前に検知する、ということはできないかもしれないものの、悪意のあるアクティビティを検知する、という Control の目的を広く捉えるなら、GuardDuty と Sysdig のルールには、アクセス元のIPが普段と異なる地域かどうかや、既知の攻撃者かどうか、偵察の疑いのあるAPI呼び出しアクティビティか、などがあるため、一定の効果はあると思われます。

4.2 Ensure management console sign-in without MFA is monitored

MFA 無しでのコンソールサインインをモニタリングするというコントロールです。

Sysdig 側にいくつかルールがあるため、これでカバーできそうです。

4.3 Ensure usage of ‘root’ account is monitored

特権ユーザーである root アカウントの使用をモニタリングせよというコントロールです。

GuardDuty では、Policy:IAMUser/RootCredentialUsage という検知ルールでカバーできそうでした。

4.4 Ensure IAM policy changes are monitored

CIS Benchmark の CloudWatch アラーム例では、IAM Policy の作成や更新、Group/Role/User へのアタッチやデタッチなどをモニタリングしていました。

GuardDuty の検知ルール PrivilegeEscalation:IAMUser/AnomalousBehavior (Medium)
で、一部のアクションは検知できそうです。

APIs in this category typically involve operations that change IAM policies, roles, and users, such as, AssociateIamInstanceProfile, AddUserToGroup, or PutUserPolicy.

Sysdig にはアクション別にルールが用意されています。

4.5 Ensure CloudTrail configuration changes are monitored

CIS Benchmark の CloudWatch アラーム例では、Update/Delete/Start/Stop Logging を検知しています。

GuardDuty の検知ルール Stealth:IAMUser/CloudTrailLoggingDisabled
で、Stop や Delete は検知できそうです。
Sysdig 側のルールは、アクション別になっており、特にリスクの高いものは Severity: High となっています。

4.6 Ensure AWS Management Console authentication failures are monitored

コンソールログインの失敗をモニタリングするというコントロール。意図としては、ブルートフォース攻撃の検知、攻撃者のIPなどのindicatorを取得し、他のイベントとの相関分析に使う、などのようです。

GuardDuty にはログイン失敗を検知するルールはなさそうでしたが、Sysdig 側にはルールが用意されていました。
ただ、ログイン失敗の都度通知して調査するのは運用上現実的ではないので、元の Remediation Guideline のように CloudWatch アラームを設定して、閾値を調整する方が良いかもしれません。

なお、今回設定チェックをした環境では、平時は IAM User でログインして作業するような運用を行っていないため、上記のようなアラームは設定せずに、GuardDuty や Sysdig のその他のルールにて IAM User の異常な振る舞いを検知する、という方向としました。

4.7 Ensure disabling or scheduled deletion of customer created CMKs is monitored

暗号化されたデータが、キー削除によって復元不可になるのを防ぐためのコントロールです。
CloudWatch を使った設定例では、KMSのDisableKey、ScheduleKeyDeletionを検知しています。

GuardDuty には CMKの無効化や削除を検知しているような記載はありませんでしたが、Sysdig のルールでカバーできそうです。

4.8 Ensure S3 bucket policy changes are monitored

機密データの入ったS3バケットを保護し、設定不備を検知し早く修正するために、バケットポリシーの変更をモニタリングするというコントロール…なのですが、CIS Benchmark の CloudWatch による対応例を見てみると、CORS や Lifecycle や Replication など、さまざまな設定の変更が検知対象になっています。

GuardDuty の Impact:IAMUser/AnomalousBehavior で、一部検知できそうです。

APIs for this finding type are typically delete, update, or put operations, such as, DeleteSecurityGroup, UpdateUser, or PutBucketPolicy.

Sysdig では Info レベルで検知ルールがありますが、全ての設定変更を通知していたら大変なことになりそうなので、GuardDuty で検知したら、そのときに Sysdig の Info イベントを合わせて見る、などが良いのかもしれません。

4.9 Ensure AWS Config configuration changes are monitored

構成情報とその履歴を保持するため、Config の設定変更をモニタリングするというコントロールです。

GuardDuty には Config の設定変更を検知しているような記載はありませんでしたが、Sysdig のルールでカバーできそうです。

4.10 Ensure security group changes are monitored

リソースやサービスが意図せず外部公開されないようにするため、セキュリティグループの変更をモニタリングするというコントロールです。

GuardDuty の Impact:IAMUser/AnomalousBehavior で検知できそうでした。

APIs for this finding type are typically delete, update, or put operations, such as, DeleteSecurityGroup, UpdateUser, or PutBucketPolicy.

Sysdig にもルールがあります。

4.11 Ensure Network Access Control Lists (NACL) changes are monitored

リソースやサービスが意図せず外部公開されないようにするため…という目的は4.10と同じで、今度は NACL の変更をモニタリングするというコントロールです。

4.11〜4.14 はネットワークリソースの設定モニタリングをするコントロールですが、セキュリティグループ以外のネットワークリソースの変更検知をしているような記載は、GuardDuty のドキュメントからは読み取れませんでした。
（全て書いていないだけで、対象に含まれている可能性はあります）

Sysdig 側にはルールがありましたので、そちらでカバーできそうです。

4.12 Ensure changes to network gateways are monitored

Site-to-Site VPN の設定や Internet Gateway の設定をモニタリングし、意図した経路だけトラフィックを流すためのコントロールのようです。

4.13 Ensure route table changes are monitored

その名の通り、ルートテーブルの変更をモニタリングするというものです。

4.14 Ensure VPC changes are monitored

VPC 自体や VPC Peering の設定変更をモニタリングするというものです。

4.10〜4.14 とネットワークリソースのモニタリング要件が続きましたが、NAT Gateway やら VPC Endpoint やら Transit Gateway やら、ネットワークリソースは他にも多々あります。
ネットワークトポロジーも様々なので、全リソースの変更をアクションベースで検知していくのは対象アクションが多すぎて厳しいのではないでしょうか…

リアルタイム性は落ちますが、4.16 で有効化が求められている Security Hub を使って、オープンな Security Group を特定したり、Inspector のネットワーク到達可能性チェック機能（現在はEC2のみ対応）を使ってインターネットから到達可能なインスタンスを特定する、なども考えられます。

また、Sysdig にも Network Exposure の表示があり、パブリック公開されているホストなどを特定することができます。更に、Risk という機能（2024/09 現在、Technical Preview 中）を使うと、パブリック公開状況や脆弱性スキャン結果、脅威検知などを組み合わせて、リスクの高いリソースを可視化できるようになっているので、そちらも活用したいと考えています。

4.15 Ensure AWS Organizations changes are monitored

意図しない情報漏洩や許可されていないアクセスを防ぐため、Organizations の各種設定（アカウント作成、Organization からの離脱、OU や SCP の設定など）をモニタリングするコントロールです。

Sysdig ルールでカバーできそうです。

おわりに

Sysdig で Amazon GuardDuty ポリシーと CloudTrail ベースの検知ポリシー両方を使うことで、CloudWatch アラーム設定をしなくても、CIS Amazon Web Services Foundations Benchmark のモニタリング要件に大半準拠できそうなことが分かりました。

次回の記事は、しろうささんの「CIEM でアカウント管理の省力化を図ろう。」です。
CIEM（「キーム」と読むらしい）は、クラウド利用者の権限が過剰になっていないかチェックする、個人的には最近活用したい機能 No.1 を争う Sysdig の機能です！お楽しみに。