【アップデート】Security Hub 修復ソリューションが v2.0.0 に更新！統合コントロールに対応しました

#AWS Security Hub

#AWS

川原征大

2023.03.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWS Security Hub の「修復の仕組み」構築に役立つソリューションの新規バージョン (v2.0.0)がリリースされました。本ブログで紹介します。

ASRとは

AWS での自動化されたセキュリティ対応 (以降 ASR )はAWSソリューションの1つです。 AWS Security Hub を起点にした「セキュリティ修復の仕組み」を簡単に展開できます。

アーキテクチャは以下のようになっています。

– 画像引用: Architecture diagram - Automated Security Response on AWS

Security Hub セキュリティ基準で非準拠になっている検出結果に対して、修復を実施できます。修復は手動でも自動でもトリガーできます。手動の場合は Security Hubのカスタムアクションを使います。自動の場合は、対応するコントロールのEventBridgeルールを有効化することで始められます。

マルチアカウント環境にも対応していて、 Security Hubの管理アカウントにて修復オペレーションを集中管理できる点もメリットです。

ASRがv2.0.0 がリリースされました

そして、ASRのバージョンが v2.0.0 になりました。

[2.0.0] - 2023-03-23

Added

New remediations contributed by 6Pillars: CIS v1.2.0 1.20

New AFSBP remediations for CloudFormation.1, EC2.15, SNS.1, SNS.2, SQS.1

Service Catalog AppRegistry integration

New support for Security Controls, finding deduplication

New support for CIS v1.4.0 standard

Changed

Added protections to avoid deployment failure due to SSM document throttling

– Release v2.0.0 · aws-solutions/aws-security-hub-automated-response-and-remediation · GitHub

新規修復の追加もありますが、大きいのは Security Hubの新機能である 「統合されたコントロールの検出結果」※に対応した ことです。この新機能を有効化すると、検出結果JSONの構造が一部変わります。その副作用を過去バージョンのASRでは受けていました。

今回のASR v2.0.0 により、問題なく「統合されたコントロールの検出結果」を有効化できるようになっています。やったね。

※「統合されたコントロールの検出結果」の詳細は以下ブログにまとまっています。

[アップデート]AWS Security Hubが統合コントロールビューと統制結果の統合に対応しました | DevelopersIO

見るべき公式リンク

「とりあえず見る」的なページとしては以下2つあります。

Automatically address security threats with predefined response and remediation actions in AWS Security Hub
- 実装ガイドです
- 実装概要やデプロイ手順などを確認できます
GitHub - aws-solutions/aws-security-hub-automated-response-and-remediation
- ソリューションのコード等が記載されています
- 実装詳細や Issueなどを確認できます

デプロイ手順は実装ガイドの Deploy the solution ページにあります。今回はこのページを参考に展開してみます。

また、既に過去バージョンのASRを入れている場合は、実装ガイドの Update the solution を必ず確認しましょう。簡単にまとめると「v1.4より前のバージョンの場合は一度ASRのアンインストールが必要」、「v1.4以降の場合は展開スタックを更新する」です。

展開してみる

実装ガイドどおりに展開してみます。今回はシングルアカウント上に新規展開します。

展開する必要のあるCloudFormation(CFn)テンプレートは以下の3種類です。 (それぞれのテンプレートのリンクは実装ガイドページに記載があります)

aws-sharr-deploy.template
aws-sharr-member.template
aws-sharr-member-roles.template

以降順番に展開していきます。

aws-sharr-deploy.template

ソリューションのコア要素(Step Functionsなど)です。マルチアカウント環境で使っている場合は「Security Hubの管理アカウント」上に展開します。

CFnパラメータは以下のとおり。

LoadAFSBPAdminStack : Load CloudWatch Event Rules for AFSBP? (default: yes)

LoadCIS120AdminStack : Load CloudWatch Event Rules for CIS120? (default: no)

LoadCIS140AdminStack : Load CloudWatch Event Rules for CIS140? (default: yes)

LoadPCI321AdminStack : Load CloudWatch Event Rules for PCI321? (default: yes)

LoadSCAdminStack : Load CloudWatch Event Rules for SC? (default: yes)

ReuseOrchestratorLogGroup : Reuse existing Orchestrator Log Group? Choose "yes" if the log group already exists, else "no" (default: no)

特に今回のSecurity Hub新機能「統合されたコントロールの検出結果」に関係があるのは、 LoadSCAdminStack パラメータです。

「統合されたコントロールの検出結果」を既にONにしている場合は、 LoadSCAdminStack=yes としましょう。 OFFの状態で自動修復を作りたい場合は他のパラメータを適宜変更しましょう ( LoadAFSBPAdminStack=yes など) 。

今回は、全てのEventBridgeルールを見たいので、 AdminStack系は全て yes としました。

aws-sharr-member.template

各種自動化ランブックを展開するテンプレートです。 全てのAWSアカウント(Security Hub管理アカウントを含む)の修復させたい全てのリージョン に展開する必要がある点に注意です。

CFnパラメータは以下のとおり。

LogGroup Configuration

Provide the name of the LogGroup to be used to create Metric Filters and Alarms : Name of the log group to be used to create metric filters and cloudwatch alarms. You must use a Log Group that is the the logging destination of a multi-region CloudTrail

Playbooks

LoadAFSBPMemberStack : Load Playbook member stack for AFSBP? (default: yes)

LoadCIS120MemberStack : Load Playbook member stack for CIS120? (default: yes)

LoadCIS140MemberStack : Load Playbook member stack for CIS140? (default: yes)

LoadPCI321MemberStack : Load Playbook member stack for PCI321? (default: yes)

LoadSCMemberStack : Load Playbook member stack for SC? (default: yes)

CreateS3BucketForRedshiftAuditLogging : Create S3 Bucket For Redshift Cluster Audit Logging. (default: no)

SecHubAdminAccount : Admin account number

LogGroup Configuration には一旦は適当な値(testなど)を入れておきます。 SecHubAdminAccount には aws-sharr-deploy.template を展開したAWSアカウントのIDを指定します。

それ以外はデフォルトで、作成しました。

aws-sharr-member-roles.template

修復に必要なIAMロール用のテンプレートです。全てのAWSアカウント(Security Hub管理アカウントを含む)の1リージョンに展開します。

CFnパラメータは以下のとおり。aws-sharr-deploy.template を展開したAWSアカウントのIDを指定します。

リソースを確認

よく使うであろう EventBridgeルールと Step Functions ステートマシンを確認します。

※それ以外のリソース(IAMロールやSSMドキュメントなど)もありますが、今回は割愛。

EventBridgeルール

以下のように、大量のEventBridgeルールが生成されています。

$ aws events list-rules --query "Rules[].Name" --output yaml
# - AFSBP_1.0.0_AutoScaling.1_AutoTrigger
# - AFSBP_1.0.0_CloudFormation.1_AutoTrigger
# ... (略)
# - CIS_1.2.0_1.10_AutoTrigger
# - CIS_1.2.0_1.11_AutoTrigger
# ... (略)
# - CIS_1.4.0_1.12_AutoTrigger
# - CIS_1.4.0_1.14_AutoTrigger
# ... (略)
# - PCI_3.2.1_PCI.AutoScaling.1_AutoTrigger
# - PCI_3.2.1_PCI.CW.1_AutoTrigger
# ... (略)
# - Remediate_with_SHARR_CustomAction
# - SC_2.0.0_AutoScaling.1_AutoTrigger
# - SC_2.0.0_CloudTrail.1_AutoTrigger
# ... (略)

※今回はすべて yes にしたので特に大量です。統合コントロールを有効にしている場合は SC_2.0.0_XXX.N_AutoTrigger のみで済むはずです。

それぞれデフォルトで無効になっています。有効にすると「自動トリガー」となり、 Security Hubで非準拠を見つけたタイミングで自動修復が走ります。

あと、Remediate_with_SHARR_CustomAction は Security Hub カスタムアクションで活用するための EventBridgeルールです。

Step Functionsステートマシン

SO0111-SHARR-Orchestrator というステートマシンが1つできています。

先程のEventBridgeルールは、基本このステートマシンをターゲットとしています。上手く修復されない、といったときはこのステートマシンや関連ログを確認すると良いでしょう。

試してみる(統合前)

まずはコントロールの統合前の状態で修復を確認します。

基礎セキュリティのベストプラクティスのコントロール [EC2.7] EBS default encryption should be enabled で試します。

AFSBP_1.0.0_EC2.7_AutoTrigger を有効にしたタイミングで、非準拠を発生させて、修復させます。

しばらくすると以下のように自動修復されました。

実行ログはCloudWatchロググループ SO0111-SHARR でも確認できます。以下のようなログが出力されていました。

# SHARR-2023-03-26 ログストリーム
INFO: 3c657818-8398-4735-bb14-212ba03e55fc: Remediation queued for AFSBP control EC2.7 in account 123456789012

# AFSBP-EC2.7-2023-03-26 ログストリーム
INFO: 3c657818-8398-4735-bb14-212ba03e55fc: Remediation succeeded for AFSBP control EC2.7 in account 123456789012: 
{
    "ExecRemediation.Output": [
        "{\"EbsEncryptionByDefault\":true,\"ResponseMetadata\": ...(略) }"
    ],
    "ParseInput.AffectedObject": [
        "{\"Type\":\"AwsAccount\",\"Id\":\"AWS::::Account:123456789012\",\"OutputKey\":\"Remediation.Output\"}"
    ]
}
 (AwsAccount AWS::::Account:123456789012)

試してみる(統合後)

コントロールの統合を有効にした状態での修復を確認します。

今度は SC_2.0.0_EC2.7_AutoTrigger EventBridgeルールを有効化します。そして、再度 [EC2.7] EBS default encryption should be enabled にて非準拠リソースを発生させました。 (ワークフローステータスも NEWに戻します)

結果としては同じように修復されました。

SO0111-SHARR ログは以下のとおり。少しAFSBPのときと違いますね。

# SHARR-2023-03-27 ログストリーム
INFO: 18105932-3c02-44cd-9c25-2d2bdf2d2e5e: Remediation queued for SC control EC2.7 in account 123456789012

# SC-EC2.7-2023-03-27 ログストリーム (長いので改行加えてます)
INFO: 18105932-3c02-44cd-9c25-2d2bdf2d2e5e: Remediation succeeded for SC control EC2.7 in account 123456789012:
  Remediation status: Success - please verify remediation (AwsAccount AWS::::Account:123456789012)