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

川原征大

2023.03.27

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

はじめに

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

ASRとは

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

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

img

– 画像引用: 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 により、問題なく「統合されたコントロールの検出結果」を有効化できるようになっています。 やったね。

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

最新 ASRを入れてみた

今回はさっそく ASR v2.0.0 を導入して、動作を確かめてみます。

見るべき公式リンク

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

デプロイ手順は実装ガイドの 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パラメータは以下のとおり。

img

  • 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パラメータは以下のとおり。

img

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を指定します。

img

リソースを確認

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

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

EventBridgeルール

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

img

$ 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ルールです。

img

Step Functionsステートマシン

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

img

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

試してみる(統合前)

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

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

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

img

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

img

実行ログは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)

おわりに

新しいバージョンの Security Hub 自動修復ソリューションを試してみました。

「統合コントロールをまだ有効にしていない」かつ 「過去のバージョン(1.4以降)のソリューションが稼働している」ような環境では 以下のように移行対応を進めると良いのではないでしょうか。

  1. LoadSCAdminStack および他のルール (LoadAFSBPAdminStack 等)を有効化した状態でソリューションをアップデートする
  2. SC_2.0.0_XXX.N_AutoTrigger と AFSBP_1.0.0_XXX.N_AutoTrigger の有効化状況をあわせる
  3. 統合コントロールを有効化する
  4. 他のルール (LoadAFSBPAdminStack 等) を削除するように、テンプレートを更新する

以上、参考になれば幸いです。

参考

スキルアップ|初心者向け|書評|デベキャン|AWS認定|スキルアップ|デベキャンだより|勉強会|コミュニティ

関連記事

[アップデート] AWS Security Hub の新しいセキュリティスタンダード「AWS Resource Tagging Standard v1.0.0」を使って組織に必要なタグキーがリソースに設定されているか検出出来るようになりました

いわさ

2024.05.02

Security Hubで知る、AWSアカウント開設後に対応したいセキュリティ項目を確認しよう

こーへい

2024.04.30

[アップデート] AWS Chatbotを使ったSecurity Hubの検知通知に検知を抑制するボタンが自動設定されるようになりました

のんピ

2024.04.30

[小ネタ] CSVダウンロードしたAWS Security Hub検出結果のファイル構造が変わっていました

あしざわ

2024.04.29