1. はじめに

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

1. AWS Security Hub
2. Prowler
3. Steampipe

目次

1. はじめに
2. 検証環境・前提
   1. 検証環境
   2. 用語
3. 検証内容
   1. 各製品のスキャン実行
   2. 基準の比較方法
   3. 比較マトリクス作成の流れ
4. 検証結果
   1. 管理策カバレッジ
   2. 判定不一致
   3. リソース種別ごとの検出数
   4. 3製品すべてがFAILの156通り
5. 分析結果
   1. 管理策カバレッジからわかること
   2. 判定不一致からわかること
   3. 検出数からわかること
   4. 全会一致FAILからわかること
6. おわりに

2. 検証環境・前提

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

2.1 検証環境

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

表1: 検証環境

項目	内容
対象基準	PCI DSS v3.2.1(全85管理策)
対象製品	AWS Security Hub / Prowler / Steampipe
対象アカウント	単一のAWSアカウント
対象リージョン	ap-northeast-1
データ取得日	3製品とも同一日
突合キー	リソースのARN

その他

1. この環境はカード情報を扱っていないこと
   • PCI DSSに準拠する必要がある環境ではなく、製品の判定を比べるために基準を適用しています。
2. AWS Configのレコーダーが停止していること
   • Security HubのPASSのうち2つの管理策が判定の裏付けを持たない状態になっています。(詳細は 5.1.2章を参照)
   • 該当は管理策2.3(非コンソール管理アクセスの暗号化)と管理策6.2(重要なセキュリティパッチの適用)です。
3. Service Screener V2はこの比較に参加していないこと
   • PCI DSSの管理策番号へ対応させる公式の定義を持っていません。

2.2 用語

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

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

用語	定義	備考
基準	セキュリティ設定の要求事項をまとめたもの	今回はPCI DSS v3.2.1。カード情報を扱う環境向けの基準
管理策	基準を構成する個々の要求項目を表したもの	v3.2.1には85ある。「10.1 監査証跡を実装する」のように番号で表される
スキャン	各製品を1回実行すること、およびその出力のこと	チェックの実行単位ではなく、実行そのものを指す
チェック	管理策を判定するために製品が実装した処理のこと	1つの管理策に複数のチェックが当たることがあり、製品ごとに当てるチェックが違う
判定	チェックを実行した結果のこと	PASS(問題なし)とFAIL(問題あり)のほかに、手動確認や対象外がある
Findings	Security Hubが判定を1件ごとに格納して返す出力の単位のこと	Security Hub独自の呼び方。ProwlerのCSVの1行、SteampipeのJSONの1件がそれぞれ同じ役割を持つ
カバレッジ	製品が基準の管理策をどこまで評価できるかを表したもの	状態の種類は表4

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

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

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

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

表4: カバレッジの状態

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

3. 検証内容

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

3.1 各製品のスキャン実行

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

• Prowlerには --scan-unused-services を付けていない
• Security Hubは公式定義・判定ともにap-northeast-1で取得し、公式定義の取得には describe-standards-controls を使う
• describe-standards-controls はそのリージョンで有効な管理策しか返さないため、表8のSecurity Hubの公式対応40管理策はap-northeast-1で有効だったものに限られる

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

表5: PCI DSS v3.2.1の判定として扱う条件

製品	判定として扱う条件
Security Hub	APIで取得したFindingsのうち、`Compliance.RelatedRequirements` の要素が `PCI DSS v3.2.1/<管理策番号>` の形であるもの
Prowler	基準ごとにファイルが分かれるため、`pci_3.2.1_aws` 向けに出力されたコンプライアンスCSVの全行
Steampipe	基準ごとに出力されるJSONを読み、各コントロールの識別子を管理策番号として使う

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

表6: 各製品の取得データとPCI DSS v3.2.1の抽出結果

製品	取得したもの	全体件数	PCI DSS v3.2.1
Security Hub	Findings(APIで全件取得、72ページ)	7,124	859
Prowler	基準ごとのコンプライアンスCSV	42,827	6,026
Steampipe	基準ごとのJSON	68,366	7,421

表6の補足です。

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

Security Hubの859に対してProwlerとSteampipeが桁違いに多いのは、1つのリソースに複数の管理策が紐づくためです。
この3つを名寄せした結果が、4,078通りの組み合わせです。

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. 番号の正規化	製品ごとの管理策番号をPCI DSSの番号へ揃える	同じ番号体系に揃った判定一覧
3. 名寄せ	リソースの識別子をARNへ揃え、同じ対象への判定を1つの組み合わせにまとめる。ARNを持たない判定は疑似ARNを立てる	比較マトリクス(4,078通り)
4. 縮約	複数のサブチェックの判定を「1つでもFAILなら全体としてFAIL」に畳み込む	製品ごとに1つに定まった判定
5. 検証	比較マトリクスの全組み合わせを生データと再照合する	不整合の一覧(今回は0件)

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

• PCI DSSは1つのリソースに複数の管理策が紐づくため、縮約前779通りから縮約後410通りへと大きく減る
• 段階5の検証では4,078通りすべてで生データとの不整合は0件

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

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

• 評価対象をARNで示しているのは、Security Hubが859件中788件、Prowlerが6,026件中5,954件、Steampipeが7,421件中6,785件
• ARNにならない残りはアカウント全体を指す判定と、対象リソースが0件の判定で、疑似ARNを立てている
• Security Hubの疑似ARN71件はすべてアカウント単位
• Prowlerの疑似ARN72件はアカウント単位50件と手動確認22件
• Steampipeの疑似ARN636件はアカウント単位392件と対象リソースなし244件
• 比較マトリクス4,078通りのうち、どの製品も判定を出していない行は77通り

4. 検証結果

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

4.1 管理策カバレッジ

表8に各製品がPCI DSS v3.2.1の85管理策をどこまでカバーしたかをまとめます。
数字は管理策の数です。

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

製品	公式対応	評価済	評価済(裏付けなし)	手動確認	出力なし	スキップ	機能なし
Security Hub	40	38	2	0	0	0	45
Prowler	73	67	0	0	6	0	12
Steampipe	76	67	0	2	5	2	9

表8の補足です。

• 公式対応: 各製品の公式定義に基づく管理策の数
• 評価済以降: 上の公式定義と実際のスキャン結果を管理策ごとに突き合わせた数
• 出力なし: 対象リソースが0件の場合と、他製品は検出しているのにこの製品だけ出力が無い場合をまとめた数。Prowlerの6はうち4が前者、2が後者

4.2 判定不一致

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

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

サービス	通り	詳細
logs(CloudWatchロググループ)	366	5.2.1章
cloudtrail	19	5.2.2章
iam	9	5.2.3章
ec2	5	5.2.4章
(種別なし。アカウント単位の判定)	5	5.2.4章
s3	4	5.2.4章
rds	2	5.2.4章
合計	410	-

表9の補足です。

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

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

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

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

リソース種別	総数	Security Hub	Prowler	Steampipe
CloudWatchロググループ	228	0	228	228
IAMロール	209	0	23	209
IAMポリシー	94	94	0	94
Lambda関数	35	35	35	35
セキュリティグループ	26	26	10	26
CloudFormationスタック	24	0	0	0
バックアッププラン	17	0	0	17
ルートテーブル	16	0	0	16
S3バケット	12	12	12	12
ネットワークACL	9	0	9	9

表10の補足です。

• 各製品の列: 比較マトリクスでその製品が判定を出しているリソースのARNの、重複を除いた数
• 総数: 3製品が検出したARNの和集合の要素数。AWSへ問い合わせた値ではない
• VPCも総数9で、Security Hub 8・Prowler 6・Steampipeが9。件数がネットワークACLと並ぶため上位10には含めていない

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

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

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

管理策	内容	通り
1.2.1、1.3.1、1.3.2、1.3.4	ネットワークの通信制限	各33
2.2	システム構成の標準化	12
8.1.4	90日以上未使用のアカウントの無効化	4
その他8の管理策	監査証跡の保護、暗号化、パスワードポリシーなど	各1

5. 分析結果

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

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

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

---

5.1.1 Security Hubは85管理策のうち45にチェックを持たない

Security HubだけではPCI DSS v3.2.1の85管理策のうち45を評価できません。
3製品で最もカバー範囲が狭く、基準の充足を見るなら他の製品か手動確認で補うことになります。

PCI DSS v3.2.1の85管理策のうち、Security Hubが自動チェックを持つのは40でした。
Prowlerは73、Steampipeは76に対応しています。

チェックを持たない45管理策の内訳では、44をProwlerかSteampipeのどちらかが対応していました。
3製品とも対応が無いのは1管理策だけです。

この45は自動評価になじまない要求項目だから空いているのではありません。
Security Hubが対象にしていないために空いています。
1製品だけで基準の充足を見た場合、自動で評価できるはずの44管理策を人手に回すことになります。

---

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

Security Hubの評価済38には判定の根拠を持たないPASSが2つ混ざっています。
評価済の数はそのまま充足の証拠にはならず、実際より高く見えます。

根拠を持たない2つは管理策2.3(非コンソール管理アクセスの暗号化)と管理策6.2(重要なセキュリティパッチの適用)です。
この環境ではAWS Configのレコーダーが停止しており、AWS Configの評価結果が空のまま判定だけがPASSになっている状態です。
表8の評価済(裏付けなし)2はこの2つを指します。

この2つはProwlerとSteampipeが独立に判定を出しており、突き合わせれば裏付けの不足に気づけます。
1製品の結果だけを見ていると、AWS Configの停止という1つの設定不備が、2管理策のPASSに隠れたまま残ります。

---

5.1.3 「出力なし」の内訳は対象リソースの有無で分かれる

Prowlerの出力なし6とSteampipeの出力なし5は、いずれも公式には対応がありながら判定が出なかった管理策です。
出力なしという結果だけでは対象リソースが無いのか検知漏れなのかを区別できません。

Prowlerの出力なし6の内訳は、対象リソースがこの環境に無い管理策が4、他製品は検出している管理策が2です。

• 対象リソースが無い4つ
  • 管理策3.5(暗号鍵へのアクセス制限)
  • 管理策3.6(暗号鍵の管理手順)
  • 管理策6.6(公開Webアプリケーションの保護)
  • 管理策7.1(業務上必要な範囲へのアクセス制限)
• 他製品は検出している2つ: 管理策10.8(重要な統制の障害の検知と通知)、管理策7.1.2(特権IDへの最小権限の付与)

Steampipeの出力なし5の内訳は、対象リソースが無い管理策が2、他製品は検出している管理策が3です。

• 対象リソースが無い2つ: 管理策1.3.3(IPアドレス偽装対策)、管理策6.6
• 他製品は検出している3つ: 管理策10.2(監査証跡に記録する操作)、管理策5.1(マルウェア対策ソフトの導入)、管理策5.2(マルウェア対策ソフトの最新化とスキャン)

後者は同じ管理策を他製品が評価できているため、検知漏れの可能性が残ります。

2製品の出力なしは合計11あり、そのうち5は他製品が同じ管理策で判定を出していました。
出力なしを問題なしと読んだ場合、この5管理策分の検知範囲の差が見えなくなります。
出力なしが出たら、対象リソースが無いのか対象外にしているのかを製品の定義まで戻って確かめます。

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

判定不一致410通りは1件ずつ読める数ではありません。
サービスごとに束ねると、上位3つのサービス(logs・cloudtrail・iam)で394通りを占めていました。

---

5.2.1 ロググループ228個の保持期間の解釈の違いが366通りに広がる

Prowlerは無期限を要件充足とみなしてPASSにし、Steampipeは保持期間の未設定自体をFAILにします。
この1つの解釈の違いが、監査証跡に関する管理策を通じて366通りまで広がりました。

この環境には228個のCloudWatchロググループがあります。
そこへ管理策10.1(利用者と操作を結びつける監査証跡)などの監査証跡関連の管理策が紐づくため、1つの解釈の違いが広範囲に及びます。
ロググループの366通りはすべて同じ判定の組み合わせでした。
いずれもSecurity Hub判定なし、Prowler PASS、Steampipe FAILという同じ組み合わせです。
管理策10.1のうち、ロググループ /aws-glue/jobs/error に対する判定を例に、各製品の生データ(加工前)を引用します。

Security Hub:                                                        (出力なし)
Prowler(cloudwatch_log_group_retention_policy_specific_days_enabled): PASS  Log Group /aws-glue/jobs/error comply with 365 days retention period since it never expires.
Steampipe(cloudwatch_log_group_retention_period_365):                 FAIL  /aws-glue/jobs/error retention period not set.

引用した3行から、次のことがわかります。

• どちらも「保持期間が設定されていない(無期限)」という同じ事実を見ている
• Prowlerは無期限なら要件の期間以上保持されるので要件を満たすと判断してPASSにしている
• Steampipeは保持期間が設定されていないこと自体を要件未達と判断してFAILにしている
• 事実の認識は一致していて、基準の読み方が違う
• Security Hubはこの環境でロググループに対するPCI DSSの判定を出していない

366通りすべてが同じ判定パターンで揃っていることから、他のロググループでも同じ構造の不一致が起きていると判断できます。

---

5.2.2 CloudTrailで見ている観点の違いが19通りに現れる

Prowlerは過去24時間のログ記録の有無を見てPASSにし、SteampipeはCloudWatch Logsへの連携設定の有無を見てFAILにします。
同じトレイルに対して、記録が動いていることと連携が設定されていることを別々に評価しています。

CloudTrailの19通りのうち18通りは同じ判定の組み合わせです。
いずれもSecurity Hub判定なし、Prowler PASS、Steampipe FAILという組み合わせです。
残り1通り(管理策3.4(保存するPANの読み取り不能化))だけはSecurity HubもPASSを返しており、パターンが異なります。
管理策10.1(利用者と操作を結びつける監査証跡)のうち、トレイル example-trail-02 に対する判定を例に、各製品の生データ(加工前)を引用します。

Security Hub:                                       (出力なし)
Prowler(cloudtrail_cloudwatch_logging_enabled):      PASS  Multiregion trail example-trail-02 has been logging in the last 24h.
Steampipe(cloudtrail_trail_enabled):                 ok    example-trail-02 enabled.
Steampipe(cloudtrail_trail_integrated_with_logs):    alarm example-trail-02 not integrated with CloudWatch logs.

引用した3行から、次のことがわかります。

• Prowlerはトレイルが実際にログを記録しているかどうかだけを見ている
• Steampipeはトレイルの有効化とCloudWatch Logsへの連携の2つを見ており、連携が無いためFAILになる
• 同じトレイルに対して、稼働の有無と構成の完全性という別の観点を評価している

18通りが同じ判定パターンで揃っていることから、他のCloudTrail関連の管理策でも同じ構造の不一致が起きていると判断できます。

---

5.2.3 IAMユーザーのMFAで見ている観点の違いが9通りに現れる

Prowlerはコンソールパスワードの有無を見てPASSにし、Steampipeは仮想MFAデバイスの登録有無を見てFAILにします。
同じユーザーに対して、パスワードログインの可否とMFAデバイスの有無という別の観点を評価しています。

IAMの9通りは2つの判定の組み合わせに分かれます。
6通りはSecurity Hub判定なし、残り3通りはSecurity HubもFAILです。
どちらのパターンも、Prowlerがコンソールパスワード起点でPASS、SteampipeがMFAデバイス起点でFAILという同じ構造です。
管理策8.3.1(管理アクセスへの多要素認証)のうち、IAMユーザー example-user-01 に対する判定を例に、各製品の生データ(加工前)を引用します。

Security Hub:                                    FAIL  MFA should be enabled for all IAM users
Prowler(iam_user_mfa_enabled_console_access):    PASS  User example-user-01 does not have Console Password enabled.
Steampipe(iam_user_console_access_mfa_enabled):  ok    example-user-01 password login disabled.
Steampipe(iam_user_mfa_enabled):                 alarm example-user-01 MFA device not configured.

引用した3行から、次のことがわかります。

• Prowlerはコンソールパスワードが無効なのでMFAの要件を満たすと判断してPASSにしている
• Steampipeはコンソールログインの無効化を確認しつつ、別のチェックでMFAデバイス自体の未設定を検出してFAILにしている
• Security Hubは同じ管理策を「MFAデバイスが有効か」で判定しておりFAILになる

同じ組み合わせが、IAMユーザー example-user-01 ・example-user-02 ・example-user-03 の3人と、管理策8.3.1・8.3.2・8.6の3つに対して起きています。

---

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

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

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

管理策	通り	中身
1.3、2.2.2	2	VPCエンドポイントの評価範囲の違い。ProwlerはEC2用インターフェースエンドポイントの有無だけを見てPASS、SteampipeはVPCエンドポイント全般の設定有無を見てFAIL
2.4	3	EC2インスタンスがSSM管理下にあるかの判定の違い。Prowlerはパッチ適用済みと判定してPASS、Security HubはSSM管理下にないと判定してFAIL、SteampipeはPCI DSSの2.4に対応するチェックを持たない
3.4、3.4.1、8.2.1	3	S3バケットの既定暗号化がKMSかどうかの判定の違い。Prowlerは既定の暗号化とKMSによる暗号化の両方のチェックでPASS、SteampipeはKMS限定の既定暗号化チェックでFAIL
10.7	1	S3バケットのライフサイクル設定とバージョニングの評価範囲の違い。Prowlerはライフサイクル設定の有無だけを見てPASS、Steampipeはバージョニングの有効化も含めた複合チェックでFAIL
3.1、3.4	2	RDSインスタンスの評価範囲の違い。Prowlerはストレージの暗号化の有無だけを見てPASS、Steampipeはバックアップやロギングなど暗号化以外の観点を含めた複合チェックでFAIL
10.5、10.5.2、11.5、3.4、8.2.1	5	アカウント単位の判定。うち3通り(10.5、10.5.2、11.5)はAWS Config recorderが無効と判定されたことによるFAIL、残り2通り(3.4、8.2.1)も同じアカウント単位の判定

5.3 検出数からわかること

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

---

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

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

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

• Prowlerは管理策8.1.4(未使用アカウントの無効化)だけをIAMロールに当てている
• Steampipeは管理策3.5.2(暗号鍵へのアクセス者の限定)と管理策3.6.4(暗号鍵の有効期間による変更)を当てている
• Security Hubはこの環境でIAMロールに対するPCI DSSの判定を出していない

Prowlerが23個にとどまる理由はチェックの実装にありました。
管理策8.1.4に当てているのは iam_role_access_not_stale_to_bedrock という、Amazon Bedrockの利用状況を見るチェックです。
生データを引用します。

Prowler(iam_role_access_not_stale_to_bedrock): FAIL  IAM Role AmazonBedrockExecutionRoleForAgents_XXXX has not accessed Bedrock in 304 days (threshold: 60 days).
Prowler(iam_role_access_not_stale_to_bedrock): FAIL  IAM Role AmazonBedrockExecutionRoleForFlows_XXXX has Bedrock permissions but has never used them.

Bedrockの権限を持つロールだけが対象になるため、209個のうち23個しか評価されません。
Steampipeが209個すべてを評価しているのは暗号鍵の管理策をロール全件に当てているためです。
ロールの中身を読んで評価しているわけではありません。
検出数が多い製品が、細かく見ているとは限りません。

---

5.3.2 IAMポリシーはProwlerだけが検出していない

IAMポリシー94個は、Security HubとSteampipeが94個ずつ検出している一方、Prowlerは0個でした。
この差は検知漏れではなく、IAMポリシー向けの管理策をPCI DSSで持っているかどうかで決まっています。

Prowlerの公式定義にはこの環境で該当するIAMポリシー向けのPCI DSSチェックがありません。
検出数0という結果だけでは対象リソースが無いのか製品が対象外にしているのかを区別できません。

Security HubとSteampipeは管理策7.2.1(アクセス制御システムの導入)でIAMポリシーを見ています。
Prowlerの0はIAMポリシーに問題が無いという意味ではありません。見ていないという意味です。
製品を入れ替えるときは、検出数が減った種別について、その製品がチェックを持っているかどうかを先に確かめることになります。

---

5.3.3 CloudFormationスタック24個はどの製品の判定にも紐づいていない

CloudFormationスタック24個は3製品のどの判定にも紐づいていません。
総数はARNの和集合の要素数であり、判定を持つリソースとは限らないことを示す例です。

表10のとおり、この24件はSecurity Hub・Prowler・Steampipeともに検出数が0でした。
比較マトリクスの名寄せの過程で現れたARNですが、3製品のどの判定にも紐づいていません。
PCI DSS v3.2.1にはCloudFormationスタックを直接評価対象にする管理策が3製品とも無いことを示しています。

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

全会一致FAIL156通りのうち、上位5つの管理策で144通り(92.3%)を占めます。
ただしその中身は5種類の異なる問題ではありませんでした。

• 管理策1.2.1(必要な通信だけを許可するファイアウォール設定)
• 管理策1.3.1(インターネットからの接続をDMZに限定)
• 管理策1.3.2(インバウンド通信のDMZ内への制限)
• 管理策1.3.4(カード会員データ環境からの送信の制限)
• 管理策2.2(システム構成基準の策定)

管理策1.2.1・1.3.1・1.3.2・1.3.4は各33通りで、評価対象はいずれもLambda関数でした。
ネットワークの境界を求めるこの4つを3製品ともLambda関数のVPC配置に当てています。
Prowlerの awslambda_function_inside_vpc の理由文を引用します。

Prowler(awslambda_function_inside_vpc): FAIL  Lambda function hr-platform-dev-imports is not inside a VPC

132通りは、33個のLambda関数がVPCの外にあるという1つの事実を、4つの管理策で数え直したものです。
全会一致FAILの件数は問題の数ではなく、1つの設定不備に紐づく管理策の数で膨らみます。
件数の多い管理策から手を付けるより、評価対象でまとめてから手を付ける方が早く減ります。

残る12通りの内訳も見ておきます。

• 管理策2.2の12通りは対象がS3バケット12個。Prowlerの s3_bucket_cross_region_replication がクロスリージョンレプリケーションの未設定をFAILにしている
• 管理策8.1.4(未使用アカウントの無効化)の4通りは、アカウント全体が1、IAMユーザーが3

上位5つ以外の8管理策は各1通りで、評価対象は2種類に分かれます。

• CloudTrail証跡が4
  • 管理策10.5.2(監査証跡ファイルの変更防止)
  • 管理策10.5.3(監査証跡の集中管理サーバへの退避)
  • 管理策10.5.5(監査ログの変更検知)
  • 管理策3.4(保存するPANの読み取り不能化)
• アカウント単位が4
  • 管理策7.2.1(アクセス制御システムの導入)
  • 管理策8.2.3(パスワードの最小長と文字種)
  • 管理策8.2.4(パスワードの定期変更)
  • 管理策8.2.5(パスワードの再利用防止)

CloudTrail証跡の4つは1本の証跡に、アカウント単位の4つはパスワードポリシー1つに紐づいています。
上位5管理策と同じで、少数の設定を直すと複数の管理策がまとめて解消する形です。

表8で見たとおりSecurity Hubのカバー範囲は3製品で最も狭いものの、これらの管理策では3製品とも判定を出しており、解釈も一致していました。
判定が割れるのは製品ごとに見る属性が違うときで、1つの属性で読める設定不備は製品をまたいで揃います。

6. おわりに

PCI DSS v3.2.1を3製品で突き合わせた結果をまとめます。

• 判定が異なったのは4,078通りのうち410通り(10.05%)
• 410通りのうち366通りは、CloudWatchロググループの保持期間に対する1つの解釈の違いが228個のロググループに広がったもの
• 保持期間が未設定のとき、Prowlerは無期限だから要件を満たすとし、Steampipeは設定されていないから要件未達とする。事実の認識は一致していて、基準の読み方が違う
• CloudTrailはPASS/FAILの根拠が製品ごとに違う。Prowlerは記録の有無、Steampipeは連携設定の有無を見る
• この構造は19通りのうち18通りに共通する
• IAMユーザーのMFAはPASS/FAILの根拠が製品ごとに違う。Prowlerはコンソールパスワードの有無、SteampipeはMFAデバイスの有無を見る
• 3人のユーザー×3つの管理策で9通りに現れた
• 3製品すべてがFAILで一致したのは156通り、うち144通り(92.3%)が5つの管理策に集中する
• Security Hubは85管理策のうち40にしかチェックを持たない。PCI DSSは自動評価になじまない要求項目を多く含む

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