CSPM4製品の判定はなぜ分かれるのか、NIST SP 800-53 Rev.5で比較検証してみた
2026.09.29
- AWS
- クラウド
- セキュリティ
1. はじめに
皆さん、こんにちは。クラウド技術部のR.Aです。
昨今、設定の誤りによる公開範囲や権限の問題がセキュリティインシデントにつながり、取引先や監査からどの基準にどこまで準拠しているかを文書で示すよう求められるようになっています。
その時に使うのが、設定をコンプライアンス基準に照らして自動で評価するCSPM製品です。
今回はAWSにおける主要なCSPMである以下の4製品の、NIST SP 800-53 Rev.5基準の出力結果を比較しました。
- AWS Security Hub
- Prowler
- Steampipe
- Service Screener V2
目次
- はじめに
- 検証環境・前提
- 検証環境
- 用語
- 検証内容
- 各製品のスキャン実行
- 基準の比較方法
- 比較マトリクス作成の流れ
- 検証結果
- 管理策カバレッジ
- 判定不一致
- リソース種別ごとの検出数
- 4製品すべてがFAILの521通り
- 分析結果
- 管理策カバレッジからわかること
- 判定不一致からわかること
- 検出数からわかること
- 全会一致FAILからわかること
- Service Screener V2用の対応表を作るときの注意
- おわりに
2. 検証環境・前提
記事中のAWSアカウントID・リソース名・リソースIDは公開にあたって別の値へ置き換えています。
引用の中の識別子も同じ規則で置き換えており、それ以外の文字列は取得した値のままです。
2.1 検証環境
表1に検証環境をまとめます。
| 項目 | 内容 |
|---|---|
| 対象基準 | NIST SP 800-53 Rev.5(全238管理策) |
| 対象製品 | AWS Security Hub / Prowler / Steampipe / Service Screener V2 |
| 対象アカウント | 単一のAWSアカウント |
| 対象リージョン | ap-northeast-1 |
| データ取得日 | 4製品とも同一日 |
| 突合キー | リソースのARN。Service Screener V2はCSVの識別子をARN形式へ変換して突合 |
その他
- AWS Configのレコーダーが停止していること
- Security Hubの
PASSのうち9つの管理策が判定の裏付けを持たない状態になっています。(理由コードCONFIG_EVALUATIONS_EMPTY、詳細は 5.1.2章を参照)
- Security Hubの
- Service Screener V2はNIST公式の管理策番号を使わず、
CategoryとRuleIdを連結した内部キーで結果を出すこと- 基準の管理策番号へ対応させる表(対応表)は自作しています。(詳細は 5.5章を参照)
- そのため、厳密な意味での比較ではないことをご了承ください。
- Service Screener V2にはNIST SP 800-53の公式な管理策対応表が存在しないこと
- 他の3製品は製品側の定義ファイルを持ちますが、Service Screener V2だけは対応表を自作しています。
2.2 用語
表2にCSPMやコンプライアンス基準の文脈で一般的に使われる用語をまとめます。
| 用語 | 定義 | 備考 |
|---|---|---|
| 基準 | セキュリティ設定の要求事項をまとめたもの | 今回はNIST SP 800-53 Rev.5。連邦政府の情報システム向けの基準 |
| 管理策 | 基準を構成する個々の要求項目を表したもの | Rev.5には238ある。管理策AC-2(アカウント管理)、管理策AU-11(監査記録の保持)のように分野の略号と番号で表される |
| スキャン | 各製品を1回実行すること、およびその出力のこと | チェックの実行単位ではなく、実行そのものを指す |
| チェック | 管理策を判定するために製品が実装した処理のこと | 1つの管理策に複数のチェックが当たることが多く、製品ごとに当てるチェックが違う |
| 判定 | チェックを実行した結果のこと | PASS(問題なし)とFAIL(問題あり)のほかに、手動確認や対象外がある |
| Findings | Security Hubが判定を1件ごとに格納して返す出力の単位のこと | Security Hub独自の呼び方。ProwlerのCSVの1行、SteampipeのJSONの `controls` 配列の要素、Service Screener V2のCSVの1行が、それぞれ同じ役割を持つ |
| カバレッジ | 製品が基準の管理策をどこまで評価できるかを表したもの | 状態の種類は表4 |
表3にこの記事で使う用語をまとめます。
※製品側の呼び方ではなく、比較を説明するために定義しています。
| 用語 | 定義 | 備考 |
|---|---|---|
| 公式定義 | 製品が公開している「どの管理策に自動チェックを持つか」の一覧のこと | Security Hubは `describe-standards-controls`、ProwlerとSteampipeは同梱の定義ファイル |
| 評価対象 | 判定が向けられているリソースやアカウント全体のこと | リソース単位、アカウント単位(アカウント全体)に分類できる |
| 比較マトリクス | 4製品の判定を、管理策と評価対象の組み合わせごとに並べた表のこと | 同じ管理策でも評価対象が違えば別の組み合わせになる |
| 名寄せ | 製品ごとに書き方が違うリソースの識別子をARNへ揃え、同じ対象への判定を1つの組み合わせにまとめること | Service Screener V2はARNを持たないため、識別子から組み立てる |
| 縮約 | 1つの管理策を複数のサブチェックで評価している製品の判定を、「1つでもFAILなら全体としてFAIL」に畳み込むこと | 例えば、Prowlerがアクセスキーとコンソールパスワードを別の行で判定する場合などに縮約します |
| 判定不一致 | 同じ組み合わせで2製品以上が判定を出していて、PASS/FAILの結論が異なっている状態のこと | - |
| 全会一致FAIL | 同じ組み合わせで、対象の全製品がFAILと判定している状態のこと | - |
表4にカバレッジの状態の種類をまとめます。
この記事では管理策ごとに製品がどの状態だったかを数えています。
| 状態 | 定義 | 備考 |
|---|---|---|
| 公式対応 | 公式定義にこの管理策の自動チェックがあること | 環境によらず決まる |
| 評価済 | 公式対応があり、今回のスキャンで判定が出たこと | 環境によって変わる |
| 評価済(裏付けなし) | PASSを返しながら、判定の裏付けが無いと製品が自己申告していること | Security Hubのみ。今回は9。理由コード `CONFIG_EVALUATIONS_EMPTY` |
| 手動確認 | 製品が「自動評価の対象外」と報告したこと | 人が確認する項目。今回はSteampipeで4 |
| 出力なし | 公式対応はあるが、今回のスキャンで判定が1件も出なかったこと | 今回はSteampipeで3。いずれも他の製品は同じ対象を検出している |
| スキップ | 製品が実行を飛ばしたと報告したこと | Steampipeのみ。今回は8 |
| 評価不能 | 製品が評価できないと報告したこと | Service Screener V2のみ。今回は2 |
| 機能なし | 公式定義にこの管理策のチェックが無いこと | 製品がこの管理策を評価できない |
3. 検証内容
検証内容についてスキャンの条件と出力結果（各製品の判定）の突合までの詳細を記載します。
3.1 各製品のスキャン実行
各製品のスキャン実行時の条件です。
- Prowlerには
--scan-unused-servicesを付けていない。 - Security Hubは公式定義・判定ともにap-northeast-1で取得し、公式定義の取得には
describe-standards-controlsを使う。 describe-standards-controlsはそのリージョンで有効な管理策しか返さない。- そのため、表8のSecurity Hubの公式対応131管理策はap-northeast-1で有効だったものに限られる。
各製品のスキャン出力から、NIST SP 800-53の判定だけを抽出します。
判定として扱う条件は製品ごとに次のとおりです。
| 製品 | 判定として扱う条件 |
|---|---|
| Security Hub | APIで取得したFindingsのうち、`Compliance.RelatedRequirements` の要素が `NIST.800-53.r5 ` で始まるもの |
| Prowler | 基準ごとにファイルが分かれるため、`nist_800_53_revision_5_aws` 向けに出力されたコンプライアンスCSVの全行 |
| Steampipe | 基準ごとに出力されるJSONを読み、各コントロールの識別子を管理策番号として使う |
| Service Screener V2 | NISTレポートのCSVのうち、`Category` と `RuleId` を連結した内部キーが、自作した対応表に載っているもの |
前提に記載の環境に対してスキャンを行ったアカウント全体の判定と表5に記載したNIST SP 800-53だけを抽出した判定結果をまとめたものが表6です。
| 製品 | 取得したもの | 全体件数 | NIST SP 800-53 |
|---|---|---|---|
| Security Hub | Findings(APIで全件取得、72ページ) | 7,124 | 12,811 |
| Prowler | 基準ごとのコンプライアンスCSV | 42,783 | 20,569 |
| Steampipe | 基準ごとのJSON | 68,366 | 28,773 |
| Service Screener V2 | NISTレポートのCSV | 274 | 6,357 |
表6の補足です。
全体件数は製品ごとに単位が違う
- Security HubはFindingsの数
- ProwlerとSteampipeは取得した全基準分の出力を合わせた判定数
- Service Screener V2はCSVの行数、これだけは判定の数ではない
Service Screener V2は1行に複数の評価対象をまとめて書く。他の3製品は1行に1つの判定を書くため、判定の単位に分けると全体件数より多くなる
- Steampipeの28,773は、JSON上の判定28,142件に、対象リソースが0件の管理策の631件を補った数
Security Hubの12,811が全体件数の7,124を上回っています。
1つのFindingが複数の管理策に紐づくためで、管理策ごとに行を展開すると件数が増えます。
この4つを名寄せした結果が、21,543通りの組み合わせです。
3.2 基準の比較方法
製品が提供するものと自作したものが混ざっているため、先に区別しておきます。
製品が提供するもの
- 各製品のスキャン出力
- Security HubのFindings
- ProwlerのCSV
- SteampipeのJSON
- Service Screener V2のCSV
- 各製品の公式定義
- Security Hubは
describe-standards-controlsの応答 - ProwlerとSteampipeは同梱の定義ファイル
- Service Screener V2はNIST SP 800-53向けの定義を持たない
- Security Hubは
- 各製品のチェック実装のソースコード
自作したもの
- 突合スクリプト(表7の5段階を実行する)
- Service Screener V2の内部キーとNIST SP 800-53の管理策番号の対応表(以下、対応表)
- 対応表をSecurity Hubの生Findingsから導出する仕組み
- 比較マトリクス(突合スクリプトの出力)
3.3 比較マトリクス作成の流れ
製品ごとにレポートのフォーマットが違うため、加工なしに比較できません。
そのため、5段階でデータの粒度や表現をそろえて比較マトリクスを作成します。
| 段階 | 処理 | 出力 |
|---|---|---|
| 1. 抽出 | 各製品のレポートから管理策番号・リソース・PASS/FAILを取り出す。公式定義も別に取り出す | 製品ごとの判定一覧と公式定義 |
| 2. 番号の正規化 | 製品ごとの管理策番号をNIST SP 800-53の番号へ揃える | 同じ番号体系に揃った判定一覧 |
| 3. 名寄せ | リソースの識別子をARNへ揃え、同じ対象への判定を1つの組み合わせにまとめる。ARNを持たない判定は疑似ARNを立てる | 比較マトリクス(21,543通り) |
| 4. 縮約 | 複数のサブチェックの判定を「1つでもFAILなら全体としてFAIL」に畳み込む | 製品ごとに1つに定まった判定 |
| 5. 検証 | 比較マトリクスの全組み合わせを生データと再照合する | 不整合の一覧(今回は0件) |
表7の段階3と段階4には次の補足があります。
- NIST SP 800-53は1つのリソースに多くの管理策が紐づくため、組み合わせの数が21,543まで増える
- 段階5の検証では21,543通りすべてで生データとの不整合は0件
名寄せの共通キーにARNを選んだ理由
4製品のうち3製品がARNで揃っているため、ARNを共通キーとし、Service Screener V2の Type::name を種別ごとの規則でARNへ機械的に組み立てる方針にしました。
- 評価対象をARNで示しているのは、Security Hubが12,811件中11,458件、Prowlerが20,569件中20,347件
- Steampipeは28,773件中25,732件で、3製品とも大半の判定がARNを持つ
- ARNにならない残りはアカウント全体を指す判定と、対象リソースが0件の判定で、疑似ARNを立てている
- Service Screener V2だけがARNを持たず、
Cloudtrail::example-trailのようなType::name形式で対象を示す - 組み立てたARNは、サブネット・ネットワークACL・起動テンプレートなど、他製品が独立に出したARNと一致することを確かめている
- ただしパスを持つIAMロールでは一致せず、同じロールが2つの評価対象に分かれた(詳細は 5.3.1章を参照)
4. 検証結果
検証結果の事実を記載します。分析は5章に書きます。
4.1 管理策カバレッジ
表8に各製品がNIST SP 800-53の238管理策をどこまでカバーしたかをまとめます。
数字は管理策の数です。
| 製品 | 公式対応 | 評価済 | 評価済(裏付けなし) | 手動確認 | 出力なし | スキップ | 評価不能 | 機能なし |
|---|---|---|---|---|---|---|---|---|
| Security Hub | 131 | 122 | 9 | 0 | 0 | 0 | 0 | 107 |
| Prowler | 206 | 206 | 0 | 0 | 0 | 0 | 0 | 32 |
| Steampipe | 206 | 191 | 0 | 4 | 3 | 8 | 0 | 32 |
| Service Screener V2 | 125 | 123 | 0 | 0 | 0 | 0 | 2 | 113 |
表8の補足です。
- 公式対応: 各製品の公式定義。ただし、Service Screener V2は自作した対応表で算出した
- 評価済以降: 上の公式定義と実際のスキャン結果を管理策ごとに突き合わせた数
4.2 判定不一致
表9に判定不一致6,324通りを評価対象のサービスごとにまとめます。
1つの違いが多数のリソースに広がるため、組み合わせを1通りずつ並べるのではなく、評価対象のサービス単位で件数を分類しています。
| サービス | 通り | 主な管理策 | 詳細 |
|---|---|---|---|
| CloudWatch Logs(ロググループ) | 3,495 | CA-7、AU-10、AU-11、SI-12 ほか | 5.2.1章 |
| IAM | 1,471 | AC-2系、AC-3系、AC-6系 ほか | 5.2.2章、5.2.5章 |
| Lambda | 949 | AC-17系、AC-3、SC-7系 ほか | 5.2.3章、5.2.4章 |
| S3 | 218 | SC-28系 ほか | 5.2.5章、5.2.6章 |
| RDS | 44 | CP-9系 ほか | 5.2.7章 |
| CloudTrail | 42 | AU-2系 ほか | 5.2.7章 |
| EC2 | 40 | SC-7系 ほか | 5.2.7章 |
| (種別なし。アカウント単位の判定) | 36 | AC-2 ほか | 5.2.7章 |
| API Gateway | 10 | AC-4系 ほか | 5.2.7章 |
| CloudWatch(アラーム) | 10 | SI-4系 ほか | 5.2.7章 |
| ECR | 6 | RA-5 ほか | 5.2.7章 |
| KMS | 3 | SC-12系 | 5.2.7章 |
| 合計 | 6,324 | - | - |
表9の補足です。
- 通り: 比較マトリクスのうち、2製品以上が判定を出していて結論が異なった組み合わせの数
- サービス: 対象リソースのARNから読んだAWSのサービス名。アカウント全体への判定はサービス名を持たないため「(種別なし)」とした
4.3 リソース種別ごとの検出数
表10にリソース種別ごとに各製品が検出したARNの数をまとめます。
判定が異なる点とは別にそもそも各製品が同じリソースを見ているかを確認するためです。
| リソース種別 | 総数 | Security Hub | Prowler | Steampipe | Service Screener V2 |
|---|---|---|---|---|---|
| CloudWatchロググループ | 228 | 227 | 228 | 228 | 196 |
| IAMロール | 212 [*1] | 209 | 77 | 116 | 77 |
| IAMポリシー | 183 | 94 | 162 | 94 | 0 |
| API Gateway | 88 | 88 | 0 | 1 | 0 |
| Lambda関数 | 35 | 35 | 35 | 35 | 35 |
| セキュリティグループ | 26 | 26 | 10 | 26 | 8 |
| サブネット | 24 | 24 | 0 | 24 | 0 |
| ルートテーブル | 16 | 0 | 0 | 16 | 0 |
| S3バケット | 12 | 12 | 12 | 12 | 12 |
| VPC | 9 | 9 | 6 | 9 | 0 |
表10の補足です。
- 各製品の列: 比較マトリクスでその製品が判定を出しているリソースのARNの、重複を除いた数
- 総数: 4製品が検出したARNの和集合の要素数。AWSへ問い合わせた値ではない
- [*1] IAMロールの総数212には同じロールが2つに分かれて数えられた3個が含まれる。実際のロールは209(詳細は 5.3.1章を参照)
- ネットワークACLも総数9で、Security Hub 9・Prowler 9・Steampipe 0・Service Screener V2 0
- 件数がVPCと並ぶため、上位10には含めていない
- API Gatewayを検出しているのはほぼSecurity Hubだけで、他の3製品は88件中1件以下
4.4 4製品すべてがFAILの521通り
表11に、4製品すべてがFAILで一致した521通りのうち、上位の管理策をまとめます。
53の管理策に広がっています。
比較マトリクスのうち、4製品の判定がすべてFAILの組み合わせを、管理策ごとに数えました。
| 管理策 | 内容 | 通り |
|---|---|---|
| CA-7 | 継続的な監視 | 30 |
| AU-10、AU-6(3)、AU-6(4) | 否認防止と監査記録のレビュー | 各29 |
| SC-13 | 暗号化の利用 | 19 |
| AU-11、SI-12 | 監査記録の保持と情報の取り扱い | 各16 |
| AC-2(4)、AC-4(26)、AC-6(9)、AU-12、AU-2、AU-3、SC-7(9)、SI-3(8)、SI-4(20)、SI-7(8) | アカウント管理・最小権限・監査記録の生成と保護 | 各13 |
| その他36の管理策 | バックアップ、伝送中の暗号化、監査ログの保護など | 1から11 |
5. 分析結果
4章に並べた表から読み取れることを表ごとにまとめます。
5.1 管理策カバレッジからわかること
製品が対応していると示す管理策の数と、実際に判定が出た数は一致しませんでした。
Security Hubは238管理策のうち107に対応せず、ProwlerとSteampipeは206ずつに対応していても、評価に至った数と止まった理由は製品ごとに違います。
5.1.1 Security Hubは107管理策にチェックを持たない
Security HubだけではNIST SP 800-53の238管理策のうち107を評価できません。
基準の充足を見るなら、他の製品か手動確認で補うことになります。
NIST SP 800-53の238管理策のうち、Security Hubが自動チェックを持つのは131でした。ProwlerとSteampipeは206ずつに対応しています。
Service Screener V2は自作した対応表で125管理策に対応しています。
対応管理策数だけでは製品を比べられません。詳細は5.1.3章で扱います。
5.1.2 AWS Configの停止で9つのPASSが裏付けを失っている
Security Hubの評価済122には判定の根拠を持たないPASSが9つ混ざっていました。
評価済の数はそのまま充足の証拠にはならず、実際より高く見えます。
根拠を持たない9つは理由コード CONFIG_EVALUATIONS_EMPTY が付いたPASSでした。
AWS Configの評価結果が空のまま、判定だけがPASSになっている状態です。
この環境ではAWS Configのレコーダーが停止しています。
表8の評価済122にはこの9つも含まれますが、実際には評価できていません。
5.1.3 対応範囲が同じでも評価に至る数が違う
ProwlerとSteampipeは対応管理策数がどちらも206でも、評価に至った数と止まった理由が違いました。
対応管理策数は製品を比べる指標になりません。
Prowlerは公式対応206のすべてで判定を出しており、手動確認も出力なしもスキップもゼロです。
Steampipeは206のうち191だけが評価済で、残りは手動確認4・出力なし3・スキップ8に分かれます。
同じ206管理策に対応していてもSteampipeは15管理策で判定を出せていません。
この違いは5.3章で扱うリソース種別ごとの検出数にも表れています。
5.2 判定不一致からわかること
判定不一致6,324通りは1件ずつ読める数ではありません。
評価対象のサービスごとに束ねると、上位3つのサービス(CloudWatch Logs・IAM・Lambda)で5,915通り(全体の93.5%)を占めていました。
生データで原因を裏取りできたのは、上位3サービスの5,664通りとS3の128通りを合わせた5,792通りです。
5.2.1 ロググループ228個の保持期間の解釈の違いが3,495通りに広がる
Prowlerは無期限を要件充足とみなしてPASSにし、Steampipeは保持期間の未設定自体をFAILにします。
この1つの解釈の違いが、監査記録関連の管理策を通じて3,495通りまで広がりました。
この環境には228個のCloudWatchロググループがあります。
そこへ監査記録に関する多数の管理策が紐づくため、1つの解釈の違いが広範囲に及びます。
管理策AU-10(否認防止)のうち、ロググループ /aws-glue/jobs/error に対する判定を例に、各製品の生データ(加工前)を引用します。
Security Hub: (公式非対応)
Prowler: PASS cloudwatch_log_group_retention_policy_specific_days_enabled Log Group /aws-glue/jobs/error comply with 365 days retention period since it never expires.
Steampipe: alarm cloudwatch_log_group_retention_period_365 /aws-glue/jobs/error retention period not set.
Service Screener V2: (公式非対応)引用した2行から、次のことがわかります。
- どちらも「保持期間が設定されていない(無期限)」という同じ事実を見ている
- Prowlerは無期限なら要件の期間以上保持されるので要件を満たすと判断してPASSにしている
- Steampipeは保持期間が設定されていないこと自体を要件未達と判断してFAILにしている
- 事実の認識は一致していて、基準の読み方が違う
上の引用にある2つのチェックの組み合わせはAU-10のほか約20の管理策に共通して当たっています。
AU-11・AU-6(3)・AU-6(4)・CA-7・SI-12・AC-16などです。
同じ2つのチェックが管理策の数だけ繰り返し比較され、3,495通りまで積み上がりました。
3,495通りのうち1,080通りでは、Service Screener V2も同じロググループにFAILを出しています。
ただし理由は保持期間ではありません。
logGroupsWithoutLogInsightsUsage という、Logs Insights未使用を指摘する別のチェックによるものでした。
1つのロググループに、保持期間の解釈違いとService Screener V2独自のチェックという2つの不一致要因が重なっている状態です。
5.2.2 IAMのインラインポリシーで見ている基準の違いが1,471通りのうち1,180通りに現れる
Prowlerはインラインポリシーの中身を見て、管理者権限を含まなければPASSにします。
Steampipeはインラインポリシーが存在すること自体をFAILにします。求めている水準が違います。
IAMサービスの判定不一致1,471通りのうち1,180通りが、同じ構造でした。
該当する管理策はAC-2・AC-2(6)・AC-3・AC-3(7)・AC-3(15)・AC-6・AC-6(3)です。
ほかにAC-24・AC-4(28)・CM-5(1)・CM-6・CM-9も含まれます。
IAMグループ example-group-02 に対する管理策AC-2(6)の判定を例に各製品の生データ(加工前)を引用します。
Security Hub: (公式非対応)
Prowler: PASS iam_inline_policy_no_administrative_privileges Inline policy AmazonSesSendingAccess attached to group example-group-02 does not allow '*:*' administrative privileges.
Steampipe: alarm iam_group_user_role_no_inline_policies Group example-group-02 has 1 inline policies.
Service Screener V2: (公式非対応)引用した2行から、次のことがわかります。
- Prowlerの
iam_inline_policy_no_administrative_privilegesはポリシーの中身を読んで管理者権限の有無を見る - Steampipeの
iam_group_user_role_no_inline_policiesはインラインポリシーが1件でもあればFAILにする - 同じ対象について、片方は内容を審査し、片方は存在の有無だけを審査している
このIAMグループには12個のNIST管理策が紐づいており、同じ2つのチェックの組み合わせが管理策の数だけ繰り返されます。
残り291通りは個別の要因が混在しており、本稿では代表的な構造として分類していません。
5.2.3 Lambda関数のVPC配置チェックの有無が704通りに現れる
Steampipeは公開設定とVPC配置の両方をNIST管理策へ対応させ、Prowlerは公開設定だけを対応させています。
このVPC配置チェックの有無が、Lambda関数949通りの不一致の中心にあります。
管理策AC-17(リモートアクセス)のうち、Lambda関数 example-function-01 に対する判定を例に、各製品の生データ(加工前)を引用します。
Security Hub: (公式非対応)
Prowler: PASS awslambda_function_not_publicly_accessible Lambda function example-function-01 has a resource-based policy without public access.
Steampipe(lambda_function_in_vpc, alarm): example-function-01 is not in VPC.
Steampipe(lambda_function_restrict_public_access, ok): example-function-01 does not allow public access.
Service Screener V2: (公式非対応)引用した3行から、次のことがわかります。
- Prowlerの
awslambda_function_not_publicly_accessibleは公開アクセスの有無だけを見ており、PASSにしている - Steampipeは公開アクセスとVPC配置の2つのチェックを同じ管理策に対応させており、VPC配置がFAILのため全体としてFAILになる
- この関数はVPCに配置されていない
- Steampipeが持つLambda向けチェックは、VPC配置・公開アクセス・同時実行数上限・デッドレターキューの4種類。このうちVPC配置だけが一貫してFAILだった
同じVPC配置チェックの有無は少なくとも11の管理策で363通りの不一致を生んでいます。
該当する管理策はAC-17系(AC-17、AC-17(1)、AC-17(10)、AC-17(4)、AC-17(9))・MP-2・SC-25・SC-7系などです。
残る586通りのうち341通りにも同じVPC配置の有無が関わっています。
Security Hubにも同じ趣旨のチェックがあります。
Lambda.3(Lambda functions should be in a VPC)です。
管理策AC-3のうち、同じLambda関数 example-function-01 に対する判定を引用します。
Security Hub(Lambda.3, FAILED): Lambda functions should be in a VPC
Prowler(awslambda_function_not_publicly_accessible, PASS): Lambda function example-function-01 has a resource-based policy without public access.
Steampipe(lambda_function_in_vpc, alarm): example-function-01 is not in VPC.
Service Screener V2: (判定なし)- Security Hubの
Lambda.3もVPC配置を見ている - この関数はVPCに配置されていないため、Security HubもFAILになる
- Prowlerは公開アクセスしか見ないため、VPC配置とは無関係にPASSのまま
- Security HubとSteampipeの両方がFAILに加わる分だけ、判定のパターンが変わる
同じVPC配置チェックの有無は、Lambda関数949通りのうち704通り(363 + 341)の原因です。
残り245通りはVPC配置と同じ構造かどうかを個別に確認していません。
5.2.4 Lambda関数のランタイム判定基準の違いが178通りの大半に現れる
Security Hubはランタイムがサポート終了していないかどうかだけを見てPASSにします。
Service Screener V2はサポート中でも新しいバージョンが出ていればFAILにします。
どちらも Lambda.2 という同じ名前のチェックですが、見ている基準の厳しさが違います。
Lambda関数 example-function-01 に対する判定を例に各製品の生データ(加工前)を引用します。
Security Hub(Lambda.2, PASSED): Lambda functions should use supported runtimes
Prowler: (公式非対応)
Steampipe: (公式非対応)
Service Screener V2(Lambda.2, Need Attention): [lambdaRuntimeUpdate] - Runtime Update Available- Security Hubの
Lambda.2はランタイムが未サポートになっていないかだけを見ている - Service Screener V2の同じ
Lambda.2は、新しいランタイムへの更新余地があるとFAILにする - ss_keyの命名がSecurityControlIdと同じでも、実際に評価している基準は同じではない
該当する管理策はCA-9(1)・CM-2・SI-2(2)・SI-2(4)・SI-2(5)の5つで、34件のLambda関数に共通しています。
178通りのうち170通りがこの構造です。
残り8通りは対象のLambda関数や管理策が異なり、個別に確認していません。
5.2.5 Service Screener V2独自のチェックがIAM・S3の判定不一致に広がる
Service Screener V2は他の3製品が持たない独自のチェックでもFAILを出します。
IAMの115通りとS3の95通りが、この構造です。
IAMグループ example-group-01 に対する管理策AC-2(アカウント管理)の判定を例に各製品の生データ(加工前)を引用します。
Security Hub(KMS.2, PASSED): IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys
Prowler: (判定なし)
Steampipe(iam_group_user_role_no_inline_policies, ok): Group example-group-01 has 0 inline policies.
Service Screener V2(IAM.1, Need Attention): [FullAdminAccess] - Limit permissions.- Security Hubの
KMS.2はKMSキーの全鍵復号を許すインラインポリシーの有無だけを見ている - Steampipeはこのグループにインラインポリシーが無いことを確認してPASSにしている
- Service Screener V2の
IAM.1は、管理者権限を丸ごと許可するポリシーが付いていることを独自に検出している - 他の3製品が見ていない観点で、Service Screener V2だけがFAILを出す
該当する管理策はAC-2・AC-2(1)・AC-3・AC-3(7)・AC-3(15)・AC-6・AC-6(3)です。
IAMグループ21件・IAMロール94件、合わせて115通りがこの構造です。
S3バケット example-bucket-01 に対する管理策AC-3の判定を例に引用します。
Security Hub(S3.8, PASSED): S3 general purpose buckets should block public access
Prowler(s3_bucket_policy_public_write_access, PASS): All S3 public access blocked at account level.
Steampipe(s3_public_access_block_bucket, ok): example-bucket-01 all public access blocks enabled.
Service Screener V2(S3.19, Need Attention): [UnpredictableBucketNames] - Use Unpredictable Bucket Names- Security Hub・Prowler・Steampipeの3製品は、バケットへの公開アクセスを許可していないかだけを見ている
- Service Screener V2の
S3.19は、バケット名が推測されやすいかどうかを独自に評価している - バケット名の推測されやすさは他の3製品が見ている公開アクセスの許可とは別の観点
該当する管理策はAC-3・AC-3(7)・AC-4・AC-4(21)・AC-6・SC-7系です。
95通りがこの構造です。
5.2.6 S3の暗号化設定に対する認識の違いが51通りのうち33通りに現れる
Prowlerはこのバケットの暗号化にKMSが使われていると判定し、Steampipeは使われていないと判定しています。
同じバケットの同じ設定について、2製品の認識そのものが食い違っています。
S3バケット example-bucket-01 に対する管理策CP-9(8)の判定を例に各製品の生データ(加工前)を引用します。
Security Hub: (判定なし)
Prowler(s3_bucket_default_encryption, PASS): S3 Bucket example-bucket-01 has Server Side Encryption with aws:kms.
Steampipe(s3_bucket_default_encryption_enabled_kms, alarm): example-bucket-01 default encryption with KMS disabled.
Service Screener V2: (判定なし)- Prowlerは「aws:kmsによるサーバー側暗号化がある」ためPASSにしている
- Steampipeは「KMSによるデフォルト暗号化が無効」だとしてFAILにしている
- 同じバケットの同じ設定を2製品が逆に読んでいる
この認識の違いはCP-9(8)・SI-19(4)の2管理策で12件のバケットに、AU-9(3)・SC-8(3)・SC-8(4)の3管理策で3件のバケットに現れます。
51通りのうち33通りがこの構造です。
残り18通りは対象の管理策が異なり、個別に確認していません。
5.2.7 残り532通りは個別の要因を追い切れていない
5.2.1〜5.2.6章で生データから裏取りできた原因は5,792通りで、残り532通りは個別の要因を追い切れていません。
サービス単位で1つの原因に絞り込めていない分です。
内訳は、IAMサービス内の残り176通り、Lambdaサービス内の残り75通り、S3サービス内の残り90通りです。
これにCloudWatch Logs・IAM・Lambda・S3以外のサービスの191通りが加わります。
191通りの内訳は表9のRDS・CloudTrail・EC2・API Gatewayです。
CloudWatch・ECR・KMSと、アカウント単位の判定(種別なし)も含みます。
これらは表9のサービス別件数どおりに存在しますが、代表例を1件読んで残りの構造が同じと確認する作業までは行っていません。
5.3 検出数からわかること
リソース種別ごとの検出数は製品間で大きく開きましたが、差の多くは持っている管理策とその管理策の評価対象で決まっていました。
検出数の差を製品の取りこぼしと読むことはできません。
5.3.1 IAMロールの検出数はチェックの持ち方で決まる
IAMロール212個に対する検出数は、Security Hubの209からProwlerの77まで開きました。
検出数の大小だけでは製品がリソースを見落としているかどうかを判断できません。
差の正体は評価対象に誰が作ったロールを含めるかでした。
212個の内訳は、AWSのサービスが自動で作るサービスリンクロールが94個、利用者が作ったロールが118個です。
- Security Hubはサービスリンクロール94個すべてに判定を出している
- Steampipeは94個のうち1個、Prowlerは7個しか判定を出していない
- 利用者が作った118個では、Security Hub 115、Steampipe 115、Service Screener V2 76、Prowler 70と差が縮まる
Security Hubの209はAWSが自動で作ったロールまで数え上げた結果です。
利用者が作ったロールに限れば、Security HubとSteampipeは同じ115個を見ています。
自分たちが作った資産の点検にはこの118個が対象で、サービスリンクロールまで並べると差分が94個分かさ上げされます。
ただし118個のうち3個は、製品が見落としたのではなく、自作した名寄せの仕組みが同じロールを2つに割ってしまったものでした。
対象はIAM Identity Centerが作る3つのロールです。
Security Hub / Prowler / Steampipe:
arn:aws:iam::123456789012:role/aws-reserved/sso.amazonaws.com/ap-northeast-1/AWSReservedSSO_example_admin_0123456789abcdef
Service Screener V2(自作の規則で組み立てたARN):
arn:aws:iam::123456789012:role/AWSReservedSSO_example_admin_0123456789abcdefService Screener V2はロール名だけを出すため、組み立てたARNにパスが入りません。
他の3製品が出すARNと文字列が一致せず、別のリソースとして数えられていました。
同じ構造が3つのロールで起きており、IAMロールの総数212は実際には209です。
疑似ARNを立てて名寄せをする方法にはこの種の取りこぼしがついて回ります。
製品間で件数が数個だけ違うときは、製品の差だと決める前に同じ対象が2行に割れていないかを先に確かめることになります。
IAMポリシーは総数183に対しProwlerが162、Security HubとSteampipeが94、Service Screener V2は0でした。
ロールでは最も少なかったProwlerが、ポリシーでは最も多く見ています。
検出数の多い製品と少ない製品はリソース種別ごとに入れ替わります。
5.3.2 API Gateway 88件はSecurity Hubだけが検出している
API Gatewayの検出数は総数88に対し、Security Hubが88、Steampipeが1、ProwlerとService Screener V2は0でした。
この差は検知漏れではなく、API Gatewayの管理策を持っているかどうかで決まっています。
NIST SP 800-53のAPI Gateway関連チェックは、公式定義の段階でSecurity Hubにしか存在しません。
ProwlerとService Screener V2はAPI Gateway向けのNIST管理策マッピングを持たず、Steampipeも1件しか判定を出していません。
検出数0という結果だけでは対象リソースが無いのか製品が対象外にしているのかを区別できません。
API Gatewayを基準の対象として扱いたい場合、この環境ではSecurity Hubを外せません。
他の3製品に入れ替えると、88件が評価されないまま結果に残らなくなります。
検出数0の種別は、表8の機能なしと突き合わせて、製品を選ぶ前に誰がその種別を見るのかを決めておくことになります。
5.3.3 ルートテーブル16件はSteampipeだけが評価している
ルートテーブルはSteampipeだけが16件全件を評価し、他の3製品は0件でした。
ルートテーブルを評価対象にする管理策自体を持っているのがSteampipeだけだったためです。
サブネット24件も同じ構造で、Security HubとSteampipeが24件ずつを検出し、ProwlerとService Screener V2は0件でした。
どちらも対応する管理策を持たない製品では検出数が必ず0になります。
ルートテーブルとサブネットはネットワークの経路と境界を持つリソースです。
この2種別を見られるのはSteampipeだけ、あるいはSteampipeとSecurity Hubだけでした。
1製品に絞る選定では評価対象になるリソース種別そのものが狭まります。
5.3.4 Service Screener V2はIAMポリシーとVPCを検出していない
Service Screener V2はIAMポリシー183件、VPC9件のどちらも0件でした。
自作した対応表にこの2つのリソース種別を評価する管理策が含まれていないためです。
Service Screener V2の対応表はSecurity HubのRelatedRequirements経由で機械的に導出したものです。
対応する内部キーが見つからなければ、管理策自体が対応表に載りません。
2つの0は同じ0でも中身が違いました。
Service Screener V2のレポートが持つチェックの分類にVPCという分類自体がありません。
IAMの分類は12のチェックを持ちますが、判定はロール77個とユーザーに対して出ており、ポリシー単位の行はありません。
- VPCの0は評価するチェックを持っていないことによる0
- IAMポリシーの0は、IAMを見るチェックはあるが、ポリシーを単位として評価していないことによる0
前者は製品の対応範囲の問題で、後者は評価の粒度の問題です。
検出数0を一律に未対応と読むと、この違いが消えます。
対応表の作り方については5.5章で扱います。
5.4 全会一致FAILからわかること
全会一致FAIL521通りのうち、上位7つの管理策群で168通り(全体の32.2%)を占めます。
いずれも監査記録の生成・レビュー・保持に関する管理策でした。
4製品の判定が揃うのは、ログや監査証跡の有無のように、1つの属性だけで読める管理策です。
CA-7(継続的な監視)が30通り、AU-10・AU-6(3)・AU-6(4)(否認防止と監査記録の相関分析)が各29通りです。
SC-13(暗号化の利用)が19通り、AU-11・SI-12(監査記録の保持と情報の取り扱い)が各16通り続きます。
5.2.1章で見たロググループの保持期間は解釈が割れる例でした。
ここに挙がった管理策の多くは、ロググループの有無やメトリクスフィルタの有無のように、4製品とも同じ結論に達しやすい属性を見ています。
53の管理策に広がっている点は5.2章で見た判定不一致とは対照的です。
判定不一致は少数のチェックの組み合わせに集中していましたが、全会一致FAILは特定のチェックに偏らず、幅広い管理策で製品間の一致が見られました。
5.5 Service Screener V2用の対応表を作るときの注意
Service Screener V2にはNIST SP 800-53の公式な管理策対応表が存在しません。
今回は自前で導出したため、表8の公式対応125は製品の実装そのものではなく、導出方法に左右される数です。
導出には、Service Screener V2のレポートが持つ内部識別子がSecurity Hubの SecurityControlId と同じ命名体系である点を使いました。
その識別子をSecurity Hubの Compliance.RelatedRequirements に当てて管理策番号を引いています。
274件の識別子のうち247件が解決でき、対応表は1,799行になりました(完全一致1,709、大文字小文字違い63)。
解決できない27件は対応表にもカバレッジにも含まれていません。
この方法はSecurity Hub側のデータに依存します。
Security Hubが該当の管理策番号をこの環境で1件も出さなければ、Service Screener V2が実際にチェックを持っていても対応表に現れません。
公式の対応表が無い製品を比較に入れるときは、カバレッジの数が製品の実力ではなく導出方法の写しであることを断ってから読むことになります。
6. おわりに
NIST SP 800-53 Rev.5を4製品で突き合わせた結果をまとめます。
- 判定が異なったのは21,543通りのうち6,324通り(29.36%)。CloudWatch Logs・IAM・Lambdaの3サービスで5,915通り(93.5%)を占める
- ロググループの保持期間は、Prowlerが無期限なら要件を満たすと判断し、Steampipeは未設定自体を要件未達と判断する
- 同じ2つのチェックが約20の管理策に当たるため、この解釈の違いが3,495通りまで広がった
- IAMのインラインポリシーは、Prowlerが中身を審査し、Steampipeは存在の有無だけを審査する。1,471通りのうち1,180通りがこの構造だった
- Lambda関数はSteampipeが公開設定とVPC配置の両方を評価に含め、Prowlerは公開設定だけを見る。この差が704通りの不一致に現れた
- 全会一致FAIL521通りは53の管理策に広がり、上位は監査記録の生成・レビュー・保持に関する管理策に集中する
- ProwlerとSteampipeは公式対応が206で一致し、Security Hubは131、Service Screener V2は125だった
- Service Screener V2の125は、Security Hub経由で機械的に導出した対応表による数である
CSPM製品の選定を検討している方の参考になれば幸いです。
今回の内容は弊社の検証環境における分析結果であり、環境によって結果は変わり得ることをご了承ください。
最後までご覧いただきありがとうございました！
RELATED ARTICLE関連記事
RELATED SERVICES関連サービス
Careersキャリア採用
この記事をシェアする
