Security Hub の評価基準が厳格化！スコア低下の原因と対策を確認してみた

あしざわです。

Security Hub、使っていますか？

「最近、なぜかSecurity Hub のスコアが急に下がった」とそんな疑問をお持ちの方、いませんか？

もしかしたらその原因は、直近のSecurity Hub のアップデートにあるかもしれません。

本ブログではSecurity Hubスコアが下がった原因となる直近のSecurity Hub のアップデート内容について紹介します。

いきなりまとめ

• アップデートによってSecurity Hub のコントロールをチェックする基準が厳しくなり、Configのリソースタイプの記録にコントロールがチェックするリソースタイプが含まれていないと、Security Hub スコアが下がる(警告となる)ように変更された
• スコアを上げるためにはConfig レコーダーの設定を変更し、Security Hub コントロールがチェックするリソースタイプを記録する必要がある
• Config レコーダーの設定で不足しているリソースタイプは、Config.1のコンプライアンスステータスから一覧できる

前置き：Security Hub のセキュリティスコアについて

このアップデートの影響について理解するために、Security Hub がどのようにセキュリティスコアを計算するのか、おさらいしましょう。

前提として、Security Hub のスコアはセキュリティ標準別に計算されます。本記事ではAWS 基礎セキュリティのベストプラクティス v1.0.0をベースにしますが、他のセキュリティ標準でも考え方は同じです。

Security Hub のスコアは、AWS公式ドキュメントによると「有効になっているコントロールのうち、合格(PASSED)の状態にあるコントロールの割合」と記載があります。

Security Hub にはコンプライアンスステータスとコントロールステータスの2つの評価単位があります。

コンプライアンスステータスとは、EC2.1で評価される各リソースの1つを評価する単位です。

以下の4つのステータスが存在します

• PASSED(合格)：コントロールが検出結果のセキュリティチェックに合格した
• FAILED(失敗)：コントロールが検出結果のセキュリティチェックに合格しなかった
• WARNING(警告)：リソースがPASSED またはFAILED のどちらにあるかどうかを判断できない
• NOT_AVAILABLE(利用不可):サーバーが失敗した、リソースが削除されたなどの事由でチェックを完了できない

コントロールステータスとは、EC2.1のような1つのコントロールIDで評価されるすべてのリソースのコンプライアンスステータスをまとめて評価する単位です。

以下の5つのステータスが存在します

• 合格：チェックされたすべてのリソースのコンプライアンスステータスがPASSED(合格)だった
• 失敗：チェックされたリソースのうち、少なくとも1つがFAILED(失敗)だった
• 不明：チェックされたリソースのうち、少なくとも1つがWARNING(警告)またはNOT_AVAILABLE(利用不可)で、FAILED(失敗)はなかった
• データなし：コンプライアンスステータスが存在しない
• 無効：コントロールが無効になっている

Security Hubのスコアは、Security Hubで有効化されているすべてのコントロールのコントロールステータスを集計し計算された割合で表現されます。

その計算式がこちら：

成功の数 ÷ (成功の数 + 失敗の数 + 不明の数) × 100

※データなしや無効のステータスは計算式から除外
※小数点以下は四捨五入

例えば、以下のAWS環境(281件成功・35件データなし・1件不明のステータス)では99.55156...%となるため、セキュリティスコアは100%と表示されています。

こちらのAWS環境(206件成功・27件データなし・72件不明)では、74.1007...%となるためセキュリティスコアは74%です。

なお、Security Hub のセキュリティスコアの計算方法について、以下の記事では図付きでまとめられておりわかりやすかったです。

https://qiita.com/infra365/items/050fe084fcbc4f2c3753

アップデート概要

ここから本題に入ります。

冒頭で紹介したSecurity Hub のアップデートはこちらです。

• Security Hub は、コントロールがチェックするリソースタイプの記録が AWS Config で有効になっていない場合、"WARNING（警告）" の検出結果を生成するようになりました。

本件は、Security Hub ユーザーガイドの改訂履歴(History)にて周知されています。

・Updates to control findings
Security Hub now generates WARNING findings for an enabled control if resource recording isn't turned on in AWS Config for the type of resource that the control checks. This can help you identify and address potential configuration gaps in your security control checks.
February 25, 2025
引用: https://docs.aws.amazon.com/securityhub/latest/userguide/doc-history.html

アップデート内容は記載の通りで、Security Hub コントロールのチェック対象になっているリソースタイプがConfig レコーダーで記録されていない場合、Security Hubのコンプライアンスステータスが「WARNING(警告)」となるようになった、というものです。

これまで前述した状態のリソースがあった場合、どのようなステータスになっていたのかはざっと調べてみても明確な記述は見つかりませんでした。

ただ、以下の2年前のre:Post記事によると、「設定レコーダーが正しく設定されていない」ときに「有効にしたコントロールで結果が得られない場合」があったような記載がありました。

Security Hub でセキュリティスコアまたはコンプライアンスステータスを解決する | AWS re:Post

つまり、以前はコンプライアンスステータスが「NOT_AVAILABLE」になり、それに従ってコンプライアンスステータスが「データなし」と表示されていたと想定されます。

コンプライアンスステータスが「データなし」のコントロールは、セキュリティスコアに含まれないためセキュリティスコアの計算式から除外されます。

しかし今回のアップデートによって、Configレコーダーの設定不備があるコントロールはコンプライアンスステータスが"WARNING(警告)"になり、それに合わせてコントロールステータスは「不明」となります。

コントロールステータスが「不明」になると、セキュリティスコアの計算式の対象になります。不明の割合が増えると成功の割合が下がるため、セキュリティスコアは下がります。

コンプライアンスステータスを確認してみた

ここからはコンプライアンスステータスを確認しながら、アップデートによる変更内容をもう少し詳しく見ていきましょう。

先ほど紹介したスコアが74％だったAWSアカウントは、このアップデートの影響でスコアが下がったアカウントの1つです。

コントロールステータスが「不明」であるDocument.1のコントロールの詳細を確認すると、Security Hub が有効化されている2つのリージョンのコンプライアンスステータスが「警告」となっていました。

「警告」をクリックすると、なぜリソースがそのように評価されたのかの説明が表示されました。

CONFIG_RECORDER_MISSING_REQUIRED_RESOURCE_TYPES
AWS Config isn't recording all resource types that correspond to this control. Turn on recording for the following resources: AWS::RDS::DBClusterSnapshot. To see all missing resource types for every enabled control, check your Config.1 findings.

説明をAI(ChatGPT-4o latest)に翻訳してもらいました。

CONFIG_RECORDER_MISSING_REQUIRED_RESOURCE_TYPES

AWS Config がこのコントロールに対応するすべてのリソースタイプを記録していません。以下のリソースの記録を有効にしてください: AWS::RDS::DBClusterSnapshot。

有効になっているすべてのコントロールに対して不足しているリソースタイプを確認するには、Config.1 の検出結果を確認してください。

AWS::RDS::DBClusterSnapshotのリソースタイプの記録がないため、警告のステータスになったとわかりますね。

ただその次の一文が気になります。不足しているリソースタイプが一覧できるのだろうか。

同じAWS アカウントのConfig.1の検出結果を確認しました。FAILEDをクリックすると確かにリソースタイプの一覧が表示されました。

文章が長かったので枠に収まっていませんね。全文がこちらです。

CONFIG_RECORDER_MISSING_REQUIRED_RESOURCE_TYPES
AWS Config isn't recording all resource types that correspond to enabled Security Hub controls. Turn on recording for the following resources: AWS::ECS::TaskDefinition, AWS::ApiGateway::Stage, AWS::NetworkFirewall::FirewallPolicy, AWS::WAFv2::RuleGroup, AWS::DMS::Endpoint, AWS::AutoScaling::LaunchConfiguration, AWS::EC2::Instance, AWS::WAFRegional::RuleGroup, AWS::SSM::AssociationCompliance, AWS::ApiGatewayV2::Stage, AWS::Connect::Instance, AWS::CodeBuild::ReportGroup, AWS::S3::AccessPoint, AWS::RDS::DBClusterSnapshot, AWS::AppSync::GraphQLApi, AWS::SageMaker::Model, AWS::Backup::RecoveryPoint, AWS::SSM::ManagedInstanceInventory, AWS::EC2::LaunchTemplate, AWS::AutoScaling::AutoScalingGroup, AWS::Lambda::Function, AWS::NetworkFirewall::RuleGroup, AWS::RDS::DBSnapshot, AWS::SSM::PatchCompliance, AWS::ElasticBeanstalk::Environment, AWS::WAFRegional::Rule, AWS::EC2::Volume, AWS::WAFv2::WebACL, AWS::ElasticLoadBalancingV2::Listener, AWS::ECS::Service, AWS::EC2::ClientVpnEndpoint, AWS::ECS::TaskSet, AWS::EC2::VPCBlockPublicAccessOptions, AWS::KafkaConnect::Connector.
CONFIG_RECORDER_CUSTOM_ROLE
The AWS Config recorder is using a custom IAM role instead of the AWS Config service-linked role.

同じくAIで日本語訳しておきます。

CONFIG_RECORDER_MISSING_REQUIRED_RESOURCE_TYPES
AWS Config が、有効になっている Security Hub のコントロールに対応するすべてのリソースタイプを記録していません。以下のリソースの記録を有効にしてください:  
`AWS::ECS::TaskDefinition`、`AWS::ApiGateway::Stage`、`AWS::NetworkFirewall::FirewallPolicy`、`AWS::WAFv2::RuleGroup`、`AWS::DMS::Endpoint`、`AWS::AutoScaling::LaunchConfiguration`、`AWS::EC2::Instance`、`AWS::WAFRegional::RuleGroup`、`AWS::SSM::AssociationCompliance`、`AWS::ApiGatewayV2::Stage`、`AWS::Connect::Instance`、`AWS::CodeBuild::ReportGroup`、`AWS::S3::AccessPoint`、`AWS::RDS::DBClusterSnapshot`、`AWS::AppSync::GraphQLApi`、`AWS::SageMaker::Model`、`AWS::Backup::RecoveryPoint`、`AWS::SSM::ManagedInstanceInventory`、`AWS::EC2::LaunchTemplate`、`AWS::AutoScaling::AutoScalingGroup`、`AWS::Lambda::Function`、`AWS::NetworkFirewall::RuleGroup`、`AWS::RDS::DBSnapshot`、`AWS::SSM::PatchCompliance`、`AWS::ElasticBeanstalk::Environment`、`AWS::WAFRegional::Rule`、`AWS::EC2::Volume`、`AWS::WAFv2::WebACL`、`AWS::ElasticLoadBalancingV2::Listener`、`AWS::ECS::Service`、`AWS::EC2::ClientVpnEndpoint`、`AWS::ECS::TaskSet`、`AWS::EC2::VPCBlockPublicAccessOptions`、`AWS::KafkaConnect::Connector`。  

CONFIG_RECORDER_CUSTOM_ROLE
AWS Config のレコーダーが、AWS Config のサービスリンクロールではなくカスタム IAM ロールを使用しています。

たくさんのリソースタイプが記録対象になっていなかったとわかります。

本記事の本題とは関連がないですが、Config.1の評価基準は直近の2025年2月に変更がありました。詳細は以下記事が参考になります。

https://dev.classmethod.jp/articles/security-hub-config1-evaluation-change-2025/

下がったスコアを上げてみた

せっかくなので、Configレコーダーによるリソースタイプの記録対象を追加し、Security Hub スコアを上げてみましょう。

現在のConfig レコーダーの設定は、特定のリソースタイプを記録するで245個のリソースタイプのみを選択している状態でした。

記録戦略をカスタマイズ可能なオーバーライドのあるすべてのリソースタイプに変更して保存します。

しばらく時間を置いてから確認すると、、、、

あれ、変わっていませんでした。

コントロールの詳細を見るとわかりました。Config の設定変更が東京リージョンでしかやれていなかったからですね。

バージニア北部リージョンでも同様の設定変更をして、再度確認したらスコアが上がっているはずです。

（確認出来次第、キャプチャを追加します）

最後に

このブログでは、アップデートによって変更されたSecurity Hub のコンプライアンスステータスのチェック基準について確認・検証しました。

最近Security Hub のスコア下がったなーと思っていた方、ぜひConfig レコーダーの設定変更を検討してみてください。

以上です。