はじめに
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 には、以下の項目が含まれています。
項目 | 参考訳 |
---|---|
4.1 Ensure unauthorized API calls are monitored (Manual) | 未承認の API コールがモニタリングされていること |
4.2 Ensure management console sign-in without MFA is monitored (Manual) | MFA を利用しないマネジメントコンソールサインインがモニタリングされていること |
4.3 Ensure usage of ‘root’ account is monitored (Manual) | root アカウントの利用がモニタリングされていること |
4.4 Ensure IAM policy changes are monitored (Manual) | IAM ポリシーの変更がモニタリングされていること |
4.5 Ensure CloudTrail configuration changes are monitored (Manual) | CloudTrail の設定変更がモニタリングされていること |
4.6 Ensure AWS Management Console authentication failures are monitored (Manual) | AWS マネジメントコンソールへの認証失敗がモニタリングされていること |
4.7 Ensure disabling or scheduled deletion of customer created CMKs is monitored (Manual) | カスタマーマネージドキー (CMK) の無効化やスケジュール削除がモニタリングされていること |
4.8 Ensure S3 bucket policy changes are monitored (Manual) | S3 バケットポリシーの変更がモニタリングされていること |
4.9 Ensure AWS Config configuration changes are monitored (Manual) | AWS Config の設定変更がモニタリングされていること |
4.10 Ensure security group changes are monitored (Manual) | セキュリティグループの変更がモニタリングされていること |
4.11 Ensure Network Access Control Lists (NACL) changes are monitored (Manual) | NACL の変更がモニタリングされていること |
4.12 Ensure changes to network gateways are monitored (Manual) | ネットワークゲートウェイの変更がモニタリングされていること |
4.13 Ensure route table changes are monitored (Manual) | ルートテーブルの変更がモニタリングされていること |
4.14 Ensure VPC changes are monitored (Manual) | VPC の変更がモニタリングされていること |
4.15 Ensure AWS Organizations changes are monitored (Manual) | AWS Organizations の変更がモニタリングされていること |
4.16 Ensure AWS Security Hub is enabled (Automated) | AWS Security Hub が有効化されていること |
ログイン失敗や、意図しないバケット・ネットワーク公開に繋がりかねないリソース変更操作など、リスクのあるアクションがモニタリング設定対象としてピックアップされていることがわかります。
項目名末尾の『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 のモニタリング要件をカバーできそうか、まとめてみました。
Control | GuardDuty + Sysdig でカバーできるか | GuardDuty ルールで対応しそうなもの | CloudTrail ベースで検知する Sysdig ルールで対応しそうなもの (記載形式は [Policy名 (Severity)] Control 名) |
---|---|---|---|
4.1 Ensure unauthorized API calls are monitored (Manual) | △ | アクセス失敗を検知するルールはない アクセス元のIPが普段と異なる地域や既知の攻撃者などかどうかや、偵察の疑いのあるAPI呼び出しアクティビティなどを検知するルールはある |
アクセス失敗を検知するルールはない 既知の攻撃者からAWSサービスへのアクセス成功を検知するルールや、普段と異なる地域やブラウザ、OSからのログインを検知する機械学習ルールはある [Sysdig AWS Threat Intelligence (High)] AWS Suspicious IP Inbound Request [AWS ML Policy] |
4.2 Ensure management console sign-in without MFA is monitored (Manual) | ◯ | MFA 有無を考慮していそうなルールはない | 対応ルールあり [Sysdig AWS Notable Events (Medium)] Console Login Without MFA [Sysdig AWS Threat Detection (High)] Console Root Login Without MFA |
4.3 Ensure usage of ‘root’ account is monitored (Manual) | ◯ | 対応ルールあり Policy:IAMUser/RootCredentialUsage (Severity: Low) |
対応ルールあり [Sysdig AWS Notable Events (Medium)] Root User Executing AWS Command |
4.4 Ensure IAM policy changes are monitored (Manual) | ◯ | 一部対応しそうなルールあり PrivilegeEscalation:IAMUser/AnomalousBehavior (Severity: Medium) |
対応ルールあり [Sysdig AWS Activity Logs (Info)] Attach IAM Policy to User [Sysdig AWS Activity Logs (Info)] Attach IAM Policy to Role [Sysdig AWS Activity Logs (Info)] Put IAM Inline Policy to User [Sysdig AWS Activity Logs (Info)] Attach IAM Policy to Group [Sysdig AWS Notable Events (Medium)] Attach Administrator Policy [Sysdig AWS Notable Events (Medium)] Create IAM Policy that Allows All [Sysdig AWS Activity Logs (Info)] Put Inline Policy in Group to Allow Access to All Resources |
4.5 Ensure CloudTrail configuration changes are monitored (Manual) | ◯ | 一部対応しそうなルールあり Stealth:IAMUser/CloudTrailLoggingDisabled (Severity: Low) |
対応ルールあり [Sysdig AWS Threat Detection (High)] CloudTrail Trail Deleted [Sysdig AWS Threat Detection (High)] Cloudtrail Management Events Disabled via Event Selectors [Sysdig AWS Threat Detection (High)] CloudTrail Logging Disabled [Sysdig AWS Notable Events (Medium)] CloudTrail Multi-region Disabled [Sysdig AWS Activity Logs (Info)] CloudTrail Trail Updated [Sysdig AWS Activity Logs (Info)] CloudTrail Trail Created [Sysdig AWS Activity Logs (Info)] CloudTrail Logfile Validation Disabled [Sysdig AWS Activity Logs (Info)] CloudTrail Logfile Encryption Disabled |
4.6 Ensure AWS Management Console authentication failures are monitored (Manual) | ◯ | ログイン失敗を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Activity Logs (Info)] Console Login Failure |
4.7 Ensure disabling or scheduled deletion of customer created CMKs is monitored (Manual) | ◯ | CMKの無効化や削除を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Activity Logs (Info)] Disable Key [Sysdig AWS Notable Events (Medium)] Schedule Key Deletion |
4.8 Ensure S3 bucket policy changes are monitored (Manual) | ◯ | 一部対応しそうなルールあり Impact:IAMUser/AnomalousBehavior (Severity: High) |
対応ルールあり [Sysdig AWS Activity Logs (Info)] Put Bucket Policy [Sysdig AWS Activity Logs (Info)] Delete Bucket Policy その他、Lifecycle, CORS, Public Access Block の Put や Delete を検知するルールもあり(記載割愛) |
4.9 Ensure AWS Config configuration changes are monitored (Manual) | ◯ | Config の設定変更を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Activity Logs (Info)] Stop Configuration Recorder [Sysdig AWS Activity Logs (Info)] Delete Configuration Recorder [Sysdig AWS Activity Logs (Info)] Delete Delivery Channel |
4.10 Ensure security group changes are monitored (Manual) | ◯ | 一部対応しそうなルールあり Impact:IAMUser/AnomalousBehavior (Severity: High) |
対応ルールあり [Sysdig AWS Activity Logs (Info)] Create Security Group 以外の Security Group 変更検知ルールあり。 [Sysdig AWS Notable Events (Medium)] には、0.0.0.0/0 や ::0 からの Inbound 許可を検知するルールが含まれる |
4.11 Ensure Network Access Control Lists (NACL) changes are monitored (Manual) | ◯ | NACL の変更を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Activity Logs (Info)] |
4.12 Ensure changes to network gateways are monitored (Manual) | ◯ | Security Group 以外のネットワークリソースの設定変更を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Activity Logs (Info)] Attach Internet Gateway |
4.13 Ensure route table changes are monitored (Manual) | ◯ | Route Table の変更を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Activity Logs (Info)] Create VPC Route [Sysdig AWS Activity Logs (Info)] Replace Route |
4.14 Ensure VPC changes are monitored (Manual) | ◯ | VPC の変更を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Activity Logs (Info)] Create VPC with Default Security Group [Sysdig AWS Activity Logs (Info)] Create VPC with No Flow Log [Sysdig AWS Activity Logs (Info)] Create VPC Peering Connection [Sysdig AWS Activity Logs (Info)] Accept VPC Peering Connection |
4.15 Ensure AWS Organizations changes are monitored (Manual) | ◯ | Organizations の変更を検知しているようなルールはない | 対応ルールあり [Sysdig AWS Notable Events (Medium)] Organization Update Service Control Policy [Sysdig AWS Notable Events (Medium)] Organization Delete Service Control Policy [Sysdig AWS Notable Events (Medium)] Leave Organization [Sysdig AWS Activity Logs (Info)] Organization Create Service Control Policy |
なお、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 の機能です!お楽しみに。