CSPM4製品の判定はなぜ分かれるのか AWS Foundational Security Best Practices v1.0.0で比較検証してみた

みなさん、こんにちは！

1. はじめに

昨今、設定の誤りによる公開範囲や権限の問題がセキュリティインシデントにつながり、取引先や監査からどの基準にどこまで準拠しているかを文書で示すよう求められるようになっています。
その時に使うのが、設定をコンプライアンス基準に照らして自動で評価するCSPM製品です。
今回はAWSにおける主要なCSPMである以下の3製品の、AWS Foundational Security Best Practices v1.0.0基準の出力結果を比較しました。

• AWS Security Hub
• Prowler
• Steampipe

2. 検証環境・前提

記事中のAWSアカウントID・リソース名・リソースIDは公開にあたって別の値へ置き換えています。
引用の中の識別子も同じ規則で置き換えており、それ以外の文字列は取得した値のままです。

2.1 検証環境

表1に検証環境をまとめます。

表1: 検証環境

項目	内容
対象基準	AWS Foundational Security Best Practices v1.0.0(全411管理策)
対象製品	AWS Security Hub / Prowler / Steampipe
対象アカウント	単一のAWSアカウント
対象リージョン	ap-northeast-1
データ取得日	3製品とも同一日
突合キー	リソースのARN
AWS Configの状態	レコーダーが停止しており、スキャン時点で無効

その他

1．AWS Configのレコーダーが停止していること
・FSBPではこの影響が最も大きく出ます。(詳細は 5.1.2章を参照)

2．Security Hubの公式定義は、ap-northeast-1を主として取得し、us-east-1を補足に使うこと
・Security Hubの describe-standards-controls は、そのリージョンで有効な管理策しか返しません。
・CloudFrontやWAFのようなグローバルサービスの管理策はus-east-1でしか返らず、東京だけでは公式対応の一覧から抜け落ちます。
・何が評価され得る管理策なのかを取りこぼさないため、両リージョンの和を公式定義として扱っています。今回はus-east-1でのみ返った管理策が20ありました。

3．判定はap-northeast-1で取得した分のみであること
・公式定義と取得範囲がずれるため、us-east-1でしか評価されない管理策は公式対応に載るが判定が無い状態になります。(詳細は 5.1.3章を参照)

4．Service Screener V2はこの比較に参加していないこと
・FSBPの管理策番号へ対応させる公式の定義を持っていません。

2.2 用語

表2にCSPMやコンプライアンス基準の文脈で一般的に使われる用語をまとめます。

表2: 一般的に使われる用語

用語	定義	備考
基準	セキュリティ設定の要求事項をまとめたもの	今回はAWS Foundational Security Best Practices。AWSが自社で定義した基準
管理策	基準を構成する個々の要求項目を表したもの	FSBPには411ある。「S3.5」「ECR.1」のようにサービス名と連番で表される
スキャン	各製品を1回実行すること、およびその出力のこと	チェックの実行単位ではなく、実行そのものを指す
チェック	管理策を判定するために製品が実装した処理のこと	Security Hubは管理策番号がそのままチェック名になる。Prowlerは ecr_repositories_scan_images_on_push_enabled など
判定	チェックを実行した結果のこと	PASS(問題なし)とFAIL(問題あり)のほかに、手動確認や対象外がある
カバレッジ	製品が基準の管理策をどこまで評価できるかを表したもの	状態の種類は表4

表3にこの記事で使う用語をまとめます。
※製品側の呼び方ではなく、比較を説明するために定義しています。

表3: この記事で定義した用語

用語	定義	備考
公式定義	製品が公開している「どの管理策に自動チェックを持つか」の一覧のこと	Security Hubは describe-standards-controls の応答、ProwlerとSteampipeは同梱の定義ファイル
評価対象	判定が向けられているリソースやアカウント全体のこと	リソース単位が1,647、アカウント単位が289
比較マトリクス	3製品の判定を、管理策と評価対象の組み合わせごとに並べた表のこと	同じ管理策でも評価対象が違えば別の組み合わせになる
名寄せ	製品ごとに書き方が違うリソースの識別子をARNへ揃え、同じ対象への判定を1つの組み合わせにまとめること	3製品ともARN形式で出すため、識別子の組み立ては不要
縮約	1つの管理策を複数のサブチェックで評価している製品の判定を、「1つでもFAILなら全体としてFAIL」に畳み込むこと	-
判定不一致	同じ組み合わせで2製品以上が判定を出していて、PASS/FAILの結論が異なっている状態のこと	-
全会一致FAIL	同じ組み合わせで、対象の全製品がFAILと判定している状態のこと	-

表4にカバレッジの状態の種類をまとめます。
この記事では管理策ごとに製品がどの状態だったかを数えています。

表4: カバレッジの状態

状態	定義	備考
公式対応	公式定義にこの管理策の自動チェックがあること	環境によらず決まる
評価済	公式対応があり、今回のスキャンで判定が出たこと	環境によって変わる
評価済(裏付けなし)	PASSを返しながら、判定の裏付けが無いと製品が自己申告していること	Security Hubのみ。理由コード CONFIG_EVALUATIONS_EMPTY。今回は223
手動確認	製品が「自動評価の対象外」と報告したこと	人が確認する項目。今回はProwlerで1、Steampipeで1
出力なし	公式対応はあるが、今回のスキャンで判定が1件も出なかったこと	対象リソースが無い場合、他製品は検出しているのにこの製品だけ出力が無い場合、取得したリージョンの外でしか評価されない場合がある
スキップ	製品が実行を飛ばしたと報告したこと	Steampipeのみ。今回は16
機能なし	公式定義にこの管理策のチェックが無いこと	製品がこの管理策を評価できない
要調査	公式定義に無いはずの管理策に判定が存在すること	Security Hubのみ。今回は1(ELB.1)

3. 検証内容

検証内容についてスキャンの条件と出力結果の突合までの詳細を記載します。

3.1 各製品のスキャン実行

各製品のスキャン実行時の条件です。

• Prowlerには --scan-unused-services を付けていない
• Security Hubの公式定義は、ap-northeast-1を主として取得し、グローバルサービスの管理策を取りこぼさないためus-east-1を補足に使う
• Security Hubの判定はap-northeast-1で取得した分のみ

各製品のスキャン出力から、FSBPの判定だけを抽出します。
判定として扱う条件は製品ごとに次のとおりです。

表5: FSBPの判定として扱う条件

製品	判定として扱う条件
Security Hub	APIで取得したFindingsのうち、Compliance.AssociatedStandards の StandardsId に aws-foundational-security-best-practices を含むもの
Prowler	基準ごとにファイルが分かれるため、scan_prowler_fsbp.csv の全行
Steampipe	scan_steampipe_fsbp.json を読み、各コントロールの識別子を管理策番号として使う

表5の条件で抽出した結果が表6です。

表6: 各製品の取得データとFSBPの抽出結果

製品	取得したもの	全体件数	FSBP
Security Hub	Findings(APIで全件取得、72ページ)	7,124	1,337
Prowler	基準ごとのコンプライアンスCSV	42,783	894
Steampipe	基準ごとのJSON	68,366	1,604

表6の補足です。

• 全体件数は製品ごとに単位が違う
  ・Security HubはFindingsの数
  ・ProwlerとSteampipeは取得した全基準分の出力を合わせた判定数
• Steampipeの1,604は、JSON上の判定1,420件に、対象リソースが0件の管理策の184件を補った数

この3つを名寄せした結果が、1,936通りの組み合わせです。

3.2 基準の比較方法

製品が提供するものと自作したものが混ざっているため、先に区別しておきます。

製品が提供するもの

• 各製品のスキャン出力(Security HubのFindings、ProwlerのCSV、SteampipeのJSON)
• 各製品の公式定義(Security Hubは describe-standards-controls の応答、ProwlerとSteampipeは同梱の定義ファイル)
• 各製品のチェック実装のソースコード

自作したもの

• 突合スクリプト(表7の5段階を実行する)
• 比較マトリクス(突合スクリプトの出力)

3.3 比較マトリクス作成の流れ

製品ごとにレポートのフォーマットが違うため、加工なしに比較できません。
そのため、5段階でデータの粒度や表現をそろえて比較マトリクスを作成します。

表7: 比較の手順

段階	処理	出力
1. 抽出	各製品のレポートから管理策番号・リソース・PASS/FAILを取り出す。公式定義も別に取り出す	製品ごとの判定一覧と公式定義
2. 番号の正規化	製品ごとの管理策番号をFSBPの番号へ揃える	同じ番号体系に揃った判定一覧
3. 名寄せ	リソースの識別子をARNへ揃え、同じ対象への判定を1つの組み合わせにまとめる。ARNを持たない判定は疑似ARNを立てる	比較マトリクス(1,936通り)
4. 縮約	複数のサブチェックの判定を「1つでもFAILなら全体としてFAIL」に畳み込む	製品ごとに1つに定まった判定
5. 検証	比較マトリクスの全組み合わせを生データと再照合する	不整合の一覧(今回は0件)

表7の段階3と段階4には次の補足があります。

• FSBPは1つのリソースに複数の管理策が紐づくため、縮約前53通りから縮約後43通りへと減る
• FSBPは管理策番号がサービス名と連番のため、CIS系のような枝番の正規化は起きない
• 段階5の検証では1,936通りすべてで生データとの不整合は0件

名寄せの共通キーにARNを選んだ理由

3製品ともARN形式で評価対象を出しているため、ARNを共通キーにしました。

• 評価対象をARNで示しているのは、Security Hubが1,337件中1,096件、Prowlerが894件中789件、Steampipeが1,604件中1,205件
• ARNにならない残りはアカウント全体を指す判定、手動確認に回された判定、対象リソースが0件の判定で、疑似ARNを立てている
• Security Hubの疑似ARN241件はすべてアカウント単位
• Prowlerの疑似ARN105件はアカウント単位25件と手動確認80件
• Steampipeの疑似ARN399件はアカウント単位215件と対象リソースなし184件
• 比較マトリクス1,936通りのうち、どの製品も判定を出していない行は101通り

4. 検証結果

検証結果の事実を記載します。分析は5章に書きます。

4.1 管理策カバレッジ

表8に各製品がFSBPの411管理策をどこまでカバーしたかをまとめます。
数字は管理策の数です。

表8: 管理策カバレッジ(全411管理策)

製品	公式対応	評価済	評価済(裏付けなし)	手動確認	出力なし	スキップ	機能なし
Security Hub	366	119	223	0	24	0	44
Prowler	206	114	0	1	91	0	205
Steampipe	339	138	0	1	184	16	72

表8の補足です。

• 公式対応: 各製品の公式定義に基づく管理策の数
• 評価済以降: 上の公式定義と実際のスキャン結果を管理策ごとに突き合わせた数
• 出力なし: 対象リソースが0件の場合、他製品は検出しているのにこの製品だけ出力が無い場合、取得したリージョンの外でしか評価されない場合をまとめた数。Security Hubの24はうち20が取得範囲外、2が全製品、2が他製品は検出
• Security Hubにはこのほかに要調査が1つ(ELB.1)あり、公式対応366・機能なし44・要調査1を足すと411になる

4.2 判定不一致

表9に判定不一致43通りを評価対象のサービスごとにまとめます。
1つの解釈の違いが多数のリソースに広がるため、組み合わせを1通りずつ並べるのではなく、サービス単位で件数を分類しています。

表9: 判定不一致43通りの内訳(評価対象のサービス別)

サービス	通り	詳細
secretsmanager	10	5.2.2章
ec2	7	5.2.3章、5.2.4章
ecr	6	5.2.1章
(種別なし。アカウント単位の判定)	10	5.2.5章
s3	3	5.2.4章、5.2.5章
rds	2	5.2.5章
cloudfront、cloudtrail、guardduty、iam、lambda	各1	5.2.5章
合計	43	-

表9の補足です。

• サービス: 対象リソースのARNから読んだAWSのサービス名。アカウント全体への判定はサービス名を持たないため「(種別なし)」とした
• 通り: 比較マトリクスのうち、2製品以上が判定を出していて結論が異なった組み合わせの数

4.3 リソース種別ごとの検出数

表10にリソース種別ごとに各製品が検出したARNの数をまとめます。
判定が異なる点とは別にそもそも各製品が同じリソースを見ているかを確認するためです。

表10: リソース種別ごとの検出数(上位10)

リソース種別	総数	Security Hub	Prowler	Steampipe
IAMロール	209	209	61	116
IAMポリシー	183	94	162	94
Lambda関数	35	35	35	35
セキュリティグループ	26	26	17	26
ネットワークインターフェース	26	10	0	11
CloudFormationスタック	24	6	0	24
サブネット	24	24	14	24
S3バケット	12	12	12	12
VPC	9	9	6	9
ネットワークACL	9	9	9	9

表10の補足です。

• 各製品の列: 比較マトリクスでその製品が判定を出しているリソースのARNの、重複を除いた数
• 総数: 3製品が検出したARNの和集合の要素数。AWSへ問い合わせた値ではない

4.4 3製品すべてがFAILの79通り

表11に3製品すべてがFAILで一致した79通りの内訳をまとめます。
評価方式が違っても共通して検出された設定です。

表11: 全会一致FAILの内訳(合計79通り)

管理策	内容	通り
S3.9	S3のサーバーアクセスログ	12
S3.13	S3のライフサイクル設定	10
S3.5	S3のTLS必須化	9
ECR.2、ECR.3	ECRのタグ変更不可設定とライフサイクルポリシー	各6
EC2.10、EC2.6	VPCエンドポイントとVPCフローログ	各5
EC2.3、RDS.4	EBSの暗号化とRDSスナップショットの暗号化	各4
IAM.8、SecretsManager.1	未使用の認証情報とシークレットの自動ローテーション	各3
その他14の管理策	CloudTrail、EC2、IAM、Lambda、RDSの各設定	各1

5. 分析結果

4章に並べた表から読み取れることを表ごとにまとめます。

5.1 管理策カバレッジからわかること

製品が対応していると示す管理策の数と実際に判定が出た数は一致しません。
評価済の数だけを見て準拠状況を比べると、実際より高く見える場合があります。

5.1.1 Prowlerは411管理策のうち205にチェックを持たない

Prowlerが公式に対応するのは411管理策のうち206で、残る205にはチェックがありません。
3製品で最も評価できる範囲が狭く、FSBPの管理策のほぼ半分に判定を出せません。

FSBPはAWSが自社サービス向けに定義した基準で、対象サービスの数がCISやPCI DSSより多くなっています。
Security Hubは自社基準のため366をカバーし、Steampipeは339をカバーしています。
Prowlerが206にとどまるのは、FSBPのマッピングに載せているチェックの数がそのまま出た結果です。

判定不一致が43通りと8基準のなかで少なめなのは、Prowlerが判定を出さない管理策が多く、2製品以上が判定を出す組み合わせ自体が少なくなることも一因です。

5.1.2 AWS Configの停止で223のPASSが裏付けを失っている

Security Hubの評価済342(119+223)には判定の根拠を持たないPASSが223混ざっています。
評価済の数はそのまま充足の証拠にはならず、実態より高く見えます。

この環境ではAWS Configのレコーダーが停止しており、AWS Configの評価結果が空のまま判定だけがPASSになっている状態です。
表8の評価済(裏付けなし)223はこの状態を指し、理由コードは CONFIG_EVALUATIONS_EMPTY です。
該当する管理策の一部を挙げます。

Security Hub(ACM.1):        PASSED  Imported and ACM-issued certificates should be renewed after a specified time period
Security Hub(APIGateway.1): PASSED  API Gateway REST and WebSocket API execution logging should be enabled

どちらも理由文は要件どおりの文面ですが、status_reasons に CONFIG_EVALUATIONS_EMPTY が付いており、AWS Configの記録が無いままPASSを返しています。
CIS v1.4.0では裏付けなしが2つ、v3.0.0とv5.0.0では3つでした。
FSBPは対象サービスが広いぶん、影響が桁違いに大きく出ます。

Security HubのPASSを準拠の根拠として扱う場合は、AWS Configの稼働状態と、Findingの status_reasons を併せて確認することになります。

5.1.3 「取得範囲外」20管理策はCloudFront・WAF・Route53に集中する

Security Hubの出力なし24のうち20は、取得範囲外(us-east-1でしか評価されない)という理由でした。

該当する20管理策の内訳です。

• CloudFront系14: CloudFront.1、CloudFront.10、CloudFront.12、CloudFront.13、CloudFront.15、CloudFront.16、CloudFront.17、CloudFront.3、CloudFront.4、CloudFront.5、CloudFront.6、CloudFront.7、CloudFront.8、CloudFront.9
• WAF系4: WAF.1、WAF.6、WAF.7、WAF.8
• そのほか2: EC2.173、Route53.2

CloudFrontとWAFはグローバルサービスで、Security Hubの評価はus-east-1で行われます。
今回の判定はap-northeast-1で取得した分のみのため、これらの管理策には判定が存在しません。
公式定義はap-northeast-1とus-east-1の和で取っているため、公式対応には載ります。
製品の機能不足ではなく、取得の仕方による欠落として区別しています。

5.2 判定不一致からわかること

判定不一致43通りは1件ずつ読める数ではありません。
サービスごとに束ねると、上位2サービス(secretsmanager・ec2)で17通り、単一の管理策で6通り以上を占めるのはECR.1だけでした。

5.2.1 ECRのイメージスキャン設定でProwlerとSteampipeが逆の事実を報告する(6通り)

ECR.1(プッシュ時のイメージスキャン)で、ProwlerとSteampipeが同じリポジトリに正反対の事実を報告しています。

Security Hub:                                          PASS  example-repo-01 scan on push enabled.
Prowler(ecr_repositories_scan_images_on_push_enabled): FAIL  ECR repository example-repo-01 has scan on push disabled.
Steampipe(foundational_security_ecr_1):                PASS  example-repo-01 scan on push enabled.

どちらが事実に合うかを確かめるため、AWS CLIの ecr describe-repositories で該当リポジトリの設定を読みました。

• imageScanningConfiguration.scanOnPush が false
• ProwlerのFAILが事実に合い、SteampipeとSecurity HubのPASSはこの環境の設定と合わない

6件はすべて同じ判定パターン(Security Hub PASS、Prowler FAIL、Steampipe PASS)で揃っており、他のリポジトリでも同じ構造の不一致が起きていると判断できます。

5.2.2 シークレットのローテーションで見ている属性が管理策ごとに違う(10通り)

secretsmanagerサービスの10通りは、SecretsManager.1(自動ローテーションの有無、4通り)とSecretsManager.4(一定期間内のローテーション、6通り)の2つの管理策に分かれます。

SecretsManager.1では、Security HubとProwlerがFAIL、SteampipeがPASSという組み合わせでした。

Security Hub:                                    FAIL  Secrets Manager secrets should have automatic rotation enabled
Prowler(secretsmanager_automatic_rotation_enabled): FAIL  SecretsManager secret example-secret-01 has rotation disabled.
Steampipe(foundational_security_secretsmanager_1):  PASS  example-secret-01 automatic rotation enabled.

AWS CLIの secretsmanager describe-secret で確認したところ、RotationEnabled が false でした。
ただし RotationLambdaARN と RotationRules(7日ごと)は設定されたまま残っており、LastRotatedDate も記録されています。
Security HubとProwlerのFAILが事実に合い、Steampipeの理由文が「automatic rotation enabled」だったのは、ローテーションの仕組みが設定されていること自体を見ているためと考えられます。
実装までは確認していないため推測です。

SecretsManager.4はこの逆側で、Security HubとSteampipeの判定が対象ごとに入れ替わりました。

Security Hub(SecretsManager.4):                    PASS  Secrets Manager secrets should be rotated within a specified number of days
Steampipe(foundational_security_secretsmanager_4):  FAIL  example-secret-02 automatic rotation using Lambda function disabled.

Security Hub(SecretsManager.4):                    FAIL  Secrets Manager secrets should be rotated within a specified number of days
Steampipe(foundational_security_secretsmanager_4):  PASS  example-secret-01 scheduled for rotation using Lambda function.

あるシークレットではSecurity HubがPASSでSteampipeがFAIL、別のシークレットでは逆になっています。
SecretsManager.1と同じく、ローテーションが有効かどうかと、ローテーションの仕組みが設定されているかどうかの違いによるものと考えられます。
この6件はライブ環境での確認をしていません。

5.2.3 停止中のEC2インスタンスをどう扱うかで判定が割れる(5通り)

SSM.1(EC2インスタンスのSystems Manager管理)で5通りの判定が異なりました。

Security Hub:                              FAIL              EC2 instances should be managed by AWS Systems Manager
Prowler(ec2_instance_managed_by_ssm):      PASS              EC2 Instance i-0123456789abcdef0 is unmanaged by Systems Manager because it is stopped.
Steampipe(foundational_security_ssm_1):    対象外(手動確認)  example-ec2-01 is in stopped state.

3製品とも、対象のEC2インスタンスが停止中であるという同じ事実を見ています。
その先の扱いが分かれました。

• Security Hubは停止中かどうかにかかわらずFAILにする
• Prowlerは停止中であることを理由に、管理対象外と判断してPASSにする
• Steampipeは停止中であることを理由に、自動評価の対象外として手動確認に回す

ProwlerとSteampipeは「停止中のインスタンスにSSM管理を求めない」という考え方では一致しており、それをPASSで表すかスキップで表すかが違うだけです。
Security Hubだけが稼働状態を見ずに一律でFAILにしています。
5通りすべてが同じ判定パターンで揃っていました。

5.2.4 少数の管理策で起きた不一致

残る22通りは管理策ごとに事情が違います。
表12にまとめます。

表12: 少数の管理策で起きた不一致(合計22通り)

管理策	通り	評価対象	中身
S3.12	2	S3バケット	ACLの有無をどう扱うかの解釈違い(5.2.5章参照)
EC2.10、EC2.4	2	VPC、EC2インスタンス	VPCエンドポイントの評価範囲とインスタンスのパッチ適用状況の判定違い
RDS.19、RDS.20、RDS.21、RDS.22	4	アカウント単位	RDS関連の推奨設定に対するアカウント単位の判定違い
Inspector.1、Inspector.2、Inspector.3、Inspector.4	4	アカウント単位	Inspectorの有効化状況に対するアカウント単位の判定違い
Config.1、IAM.7	2	アカウント単位	AWS Configの有効化状況とパスワードポリシーに対するアカウント単位の判定違い
CloudFront.4、CloudTrail.5、GuardDuty.7、KMS.2、Lambda.2、RDS.23、RDS.9、S3.8	8	各リソース1件	サービスごとに単発で起きた判定違い

S3.12はECR.1・SecretsManager.1と同じ3つの管理策の1つで、AWS CLIで確認済みです。

Prowler(s3_bucket_acl_prohibited):                 FAIL  S3 Bucket example-bucket-01 has bucket ACLs enabled.
Steampipe(foundational_security_s3_12):            PASS  example-bucket-01 does not have ACLs for user access.

get-bucket-ownership-controls は設定が見つからないという応答で、ACLの仕組みは有効な状態でした。
get-bucket-acl のGrantsは所有者へのFULL_CONTROLだけで、他のユーザーへの付与はありませんでした。

• Prowlerは前者を見て「ACLが有効」としてFAILにしている
• Steampipeは後者を見て「ACLでユーザーアクセスを管理していない」としてPASSにしている
• S3.12の文面は「ACLをユーザーアクセスの管理に使わないこと」で、文面に近いのはSteampipeの読み方
• ACLそのものを無効にする(BucketOwnerEnforced)のがAWSの推奨で、そちらに沿うのがProwlerの読み方

この1件は、事実の認識は一致していて、どちらの基準の読み方を採るかで判定が変わるケースでした。

5.3 検出数からわかること

リソース種別ごとの検出数は製品間で大きく開きましたが、差の多くは持っている管理策とその評価対象で決まっていました。
検出数の差を製品の取りこぼしと読むことはできません。

5.3.1 IAMロールの検出数はチェックの持ち方で決まる

IAMロール209個に対する検出数はSecurity Hubの209からProwlerの61まで開きました。
検出数の大小だけでは製品がリソースを見落としているかどうかを判断できません。

差の原因は3製品がIAMロールに当てている管理策が違うことでした。

• Security HubとSteampipeはKMS.2(IAMプリンシパルがすべてのKMSキーへの復号アクションを許可するインラインポリシーを持たないこと)を当てている
• Prowlerは同じ属性のKMS.2チェックを持たず、代わりにIAM.1(インラインポリシーが管理者権限を許可しないこと)を当てている

Security Hub(KMS.2):  PASS  IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys
Prowler(IAM.1):       PASS  Inline policy CodeBuildExecutionPolicy attached to role example-role-01 does not allow '*:*' administrative privileges.
Steampipe(KMS.2):     PASS  Role example-role-01 not allowed to perform decryption actions on all keys.

Security Hubは209個全件にKMS.2の判定を出しており、インラインポリシーが無いロールにも明示的にPASSを返しています。
Steampipeも同じKMS.2を実装していますが、116個にとどまりました。
インラインポリシーを持つロールだけを評価対象にしているため、それ以外のロールは判定を出さずに抜けています。
検出数が多い製品が、必ずしも広く評価しているとは限りません。

5.3.2 IAMポリシーはProwlerの評価範囲がSecurity HubとSteampipeより広い

IAMポリシー183個は、Security HubとSteampipeが94個ずつ検出している一方、Prowlerは162個でした。
3製品ともIAM.1(管理者権限を許可しないこと)を当てていますが、評価対象の範囲が違います。

• Security HubとSteampipeは顧客管理ポリシーだけを評価対象にしている(94個)
• ProwlerはAWS管理ポリシーを含む、アタッチされている全ポリシーを評価対象にしている(162個)

Prowler(iam_customer_attached_policy_no_administrative_privileges): PASS  AWS policy AWSOrganizationsServiceTrustPolicy is attached but does not allow '*:*' administrative privileges.

AWSOrganizationsServiceTrustPolicy はAWSが提供するサービスリンクロール向けのポリシーで、Security HubとSteampipeの評価対象には入りません。
Prowlerのチェック名が iam_customer_attached_policy_no_administrative_privileges であるとおり、アタッチされているポリシーであれば管理元を問わず評価しています。
同じ管理策でも製品によって評価範囲の定義が違うため、検出数だけでは優劣を判断できません。

5.3.3 ネットワークインターフェースとCloudFormationスタックはProwlerが持たない

ネットワークインターフェース26個とCloudFormationスタック24個は、Prowlerがどちらも0個でした。

• ネットワークインターフェース26個はSecurity Hubが10個、Steampipeが11個を評価している
• CloudFormationスタック24個はSecurity Hubが6個、Steampipeが24個を評価している

Prowlerの公式定義には、この2つのリソース種別を評価対象にするFSBPのチェックがありません。
検出数0という結果だけでは、対象リソースが無いのか製品が対象外にしているのかを区別できません。
今回はどちらも公式定義を確認した結果、Prowlerが対象にしていないことが原因でした。

5.4 全会一致FAILからわかること

全会一致FAIL79通りのうち、上位3つの管理策(S3.9・S3.13・S3.5)で31通り(39.2%)を占めます。
いずれもS3バケットが評価対象です。

Security Hub(S3.9):                          FAIL  S3 general purpose buckets should have server access logging enabled
Prowler(s3_bucket_server_access_logging_enabled): FAIL  S3 Bucket cdk-hnb659fds-assets-123456789012-ap-northeast-1 has server access logging disabled.
Steampipe(foundational_security_s3_9):       FAIL  cdk-hnb659fds-assets-123456789012-ap-northeast-1 logging disabled.

S3.9(アクセスログ)・S3.13(ライフサイクル設定)・S3.5(TLS必須化)は、それぞれ別の設定項目を見ている独立した管理策です。
NISTやPCI DSSのように1つの設定不備が複数の管理策へ数え直される構造とは違い、この31通りは12個のバケットに対する3種類の異なる指摘が積み上がったものです。

ECR.2(タグ変更不可)・ECR.3(ライフサイクルポリシー)も各6通りで、対象は同じ6個のリポジトリでした。

Security Hub(ECR.2):              FAIL  ECR private repositories should have tag immutability configured
Prowler(ecr_repositories_tag_immutability): FAIL  Repository example-repo-01 does not have immutability configured.
Steampipe(foundational_security_ecr_2):    FAIL  example-repo-01 tag immutability disabled.

EC2.10(VPCエンドポイント)・EC2.6(VPCフローログ)も各5通りで、5つのVPCが対象でした。

Security Hub(EC2.6):              FAIL  VPC flow logging should be enabled in all VPCs
Prowler(vpc_flow_logs_enabled):   FAIL  VPC example-vpc-01 Flow logs are disabled.
Steampipe(foundational_security_ec2_6): FAIL  vpc-0123456789abcdef0 flow logging disabled.

上位7管理策(S3.9・S3.13・S3.5・ECR.2・ECR.3・EC2.10・EC2.6)で53通り(67.1%)を占めますが、対象リソースはS3バケット12個・ECRリポジトリ6個・VPC5個の合計23個です。
79通りという件数の多さは、対象の多さではなく、1つのリソースに複数の管理策が独立して紐づいた結果です。

残る26通りは、EC2.3(EBS暗号化)・RDS.4(RDSスナップショット暗号化)が各4通り、IAM.8(未使用の認証情報)・SecretsManager.1(自動ローテーション)が各3通り、その他14の管理策が各1通りに分かれます。

FSBPは管理策の粒度が細かく、3製品とも同じ属性を見ることが多いため、全会一致FAILは判定の正誤ではなく実際の設定不備を反映していると見てよい件数です。
表8で見たとおりSecurity Hubのカバー範囲は8基準のなかでも広い一方、これらの管理策では3製品とも判定を出しており、解釈も一致していました。

6. おわりに

AWS Foundational Security Best Practicesを3製品で突き合わせた結果をまとめます。

• 判定が異なったのは1,936通りのうち43通り(2.22%)
• 43通りのうち6通りは、ECRリポジトリのプッシュ時イメージスキャンに対する事実の報告がProwlerとSteampipeで正反対だった。AWS CLIで確認したところProwlerのFAILが事実に合っていた
• シークレットのローテーションでは、有効かどうかと仕組みが設定されているかどうかの違いで10通りの判定が割れた
• 停止中のEC2インスタンスの扱いが製品ごとに違う。Security Hubは稼働状態を見ずにFAILにし、ProwlerとSteampipeは停止中を理由に管理対象外として扱う
• IAMロールの検出数はSecurity Hub209・Steampipe116・Prowler61と開くが、これはリソースの見落としではなく、当てている管理策(KMS.2かIAM.1か)の違いによるもの
• IAMポリシーの検出数はProwler162・Security HubとSteampipe94と開くが、AWS管理ポリシーを含めるかどうかの評価範囲の違いによるもの
• 3製品すべてがFAILで一致したのは79通り。うち53通り(67.1%)は23個のリソース(S3バケット・ECRリポジトリ・VPC)に対する複数の管理策の指摘で、件数の多さは対象の多さではなく管理策の細かさによる
• Prowlerは411管理策のうち205にチェックを持たない。FSBPはAWSが自社サービス向けに定義した基準で、対象サービスの数が多い
• AWS Configの停止により、Security Hubが評価済とした342の管理策のうち223でPASSが判定の裏付けを持たない

同じように複数のセキュリティツールの結果を突き合わせている方の参考になれば幸いです。
今回の内容は弊社の検証環境における分析結果であり、環境によって結果は変わり得ることをご了承ください。
最後までご覧いただきありがとうございました！