AWS

Security Hubの通知をLambdaを使わずに成形してみた

akira

はじめに

朝ジムにハマっているakiraです。少し早起きしてジムに行って汗を流してから業務に入ることで集中力が増している気がします!

今回は直近アサインされているプロジェクトにおいて、AWS Security Hubのメール通知について調べる機会があったので書いてみます。
成形せずにAmazon SNSでメール通知を行うと、「情報量は多いけど結局何を見れば良いのかわからない!」「AWSコンソールに入ったほうがメール読むより早い!」といった感想を持つ方が大半なのではないでしょうか。

そのまま真似をするだけで簡単に実装できるようにご紹介するので最後までご覧ください。

前提事項

Security Hubとは

Security Hubは一言でいうと、使用しているAWSアカウントがセキュリティのベストプラクティスを満たしているかをチェックしてくれるサービスになります。

Security Hubでは現在以下の6つのセキュリティ標準をサポートしており、AWSアカウントの用途に応じて有効化することでベストプラクティスに沿った運用をサポートしてくれます。

  • AWS Foundational Security Best Practices (FSBP) 標準
  • CIS AWS Foundations Benchmark
  • 米国国立標準技術研究所 (NIST) SP 800-53 Rev. 5
  • Payment Card Industry Data Security Standard (PCIDSS)
  • AWS リソースタグ付け標準
  • サービスマネージドスタンダード

※詳細は下記を参照ください

Security Hub standards reference
Security Hub standards reference

他のサービスとの統合

前項でご紹介した機能の他に、Security Hubは他のセキュリティサービスとの統合も可能で以下のAWSサービスの検知結果を集約することができます。

  • AWS Config
  • AWS Firewall Manager
  • Amazon GuardDuty
  • AWS Health
  • AWS Identity and Access Management Access Analyzer
  • Amazon Inspector
  • AWS IoT Device Defender
  • Amazon Macie
  • AWS Systems Manager Patch Manager

また、Security Hubでの検知内容を以下のサービスに連携しセキュリティ情報を活用することもできます。

  • AWS Audit Manager
  • AWS Chatbot
  • Amazon Detective
  • Amazon Security Lake
  • AWS Trusted Advisor

※詳細は下記を参照ください

AWS service integrations with Security Hub
AWS service integrations with Security Hub

Security Hubの検出通知の必要性

ここまでで、Security Hubを活用することでAWSアカウントをより安全に活用することが出来ることを簡単にご紹介してきました。とても便利なサービスですが、Security Hub自体に通知機能は無いため、検出項目の有無はコンソールから確認する必要があります。

コンソールから簡単に確認できても毎日定期的に確認しに行くのはアカウント運用として現実的ではありません。そこで、検知の有無を知る方法の1つとしてSNSを活用したメール通知があります。

しかし、冒頭に記載のとおり、ただ単純にSNSでメール通知をするのでは以下のような未整形のJSONが送信されてしまいます。フォーマッタなどを活用して1つ1つを手動で整形することもできますが、不定期に検知されるメールをわざわざフォーマットしなくてはならないのはとても不便です。ましてや、複数アカウントを管理する場合は言うまでもないと思います。

Security Hubの検出内容をそのままメール通知した例

通知方法の例とメリット・デメリット

前段が長くなってしまいましたが、ここからが本題になります。

Security Hubのメール通知にはいくつもの方法がありますが、代表的なもの(No.1,2)と今回ご紹介する方法(No.3,4)についてメリット・デメリットを考えてみました。

No通知方法メリットデメリット
1  Security Hub の検出内容をEventBridgeで検出し、SNSでメール通知すべての情報を漏らすことなく取得できるJSON形式で送られるため見て瞬時に判断するのは難しい
2  Security Hub の検出内容をLambdaで成形し、SNSでメール通知件名・本文ともに自由度高く変更することができ、必要な情報を選択的に取得することができるLambdaを作成するのでランタイム管理などの手間が発生する
3  Security Hub の検出をEventBridgeで検出し、トランスフォーマーで整形後SNSでメール通知メール本文に必要な情報を選択的に取得することができるメールの件名は修正できないため、複数アカウント管理をしている場合は本文を読まなくてはならない
4 No.3と同様にトランスフォーマーで整形後、StepFunctionsからSNSのAPIを実行することでメール通知メール本文に加えて件名の修正も可能になるLambdaで実現できるほどの自由度の高いカスタマイズはできない
メール通知の方法例とメリット・デメリット

上記の表のとおり、Lambdaで整形を行えばリッチな整形を行うことができますが、ランタイム管理などの追加の運用が発生してしまいます。本来の意図として、Security Hubの運用を簡単にすることが目的なので新たな運用が増えてしまうのは本意ではありません。

そのため、今回はNo.3,4の手法で通知する方法について整理してみました。

No.3 Event Bridgeのみを用いた本文の編集

前提

以下の手順ではSecurity Hubの有効化、SNSトピックの作成を前提としております。
不足がある場合はリンク先を参照いただき、有効化・作成の上で手順を進めてください。

  1. Security Hubの有効化
  2. SNSのトピック作成

作成手順

まずは本文のみを成形していきたいと思います。

Event Bridgeの作成

まず最初にSecurity Hubの検出をトリガに起動するイベントを作成します。

Amazon EventBridge > ルール よりルールの作成を選択します。

任意の名前を設定し次へ進みます。

カスタムパターンを選択し以下のJSONを設定します。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Compliance": {
        "Status": ["FAILED", "WARNING", "NOT_AVAILABLE"]
      },
      "RecordState": ["ACTIVE"],
      "Severity": {
        "Label": ["CRITICAL", "HIGH"]
      },
      "Workflow": {
        "Status": ["NEW"]
      }
    }
  }
}

上記パターンでは重要度が"CRITICAL"、"HIGH"の新たな検知があった場合にトリガーされるようになっています。

これはあくまで1例なので実環境でご利用の際は要件に応じてイベントパターンを修正ください

入力トランスフォーマーの設定

イベントトリガーのターゲットとしてSNSトピックを選択し、追加設定で「入力トランスフォーマー」を選択します。

Security HubはASFFと呼ばれる形式に沿ってイベント通知を行うので、その中で最低限必要と思われる項目を抽出してみます。

入力トランスフォーマーでは以下のように元のイベントソースの値を参照する変数を定義することで値を取得できます。

{
  "account": "$.account",
  "description": "$.detail.findings[0].Description",
  "severityLabel": "$.detail.findings[0].Severity.Label",
  "productName": "$.detail.findings[0].ProductName",
  "time": "$.time",
  "title": "$.detail.findings[0].Title"
}

定義した変数は<variable>のように指定することで利用できます。入力テンプレートの内容がSNSのmessageに渡されるため、本文に表示したい内容をここに記載します。

"アカウントID <account> にて重要度 <severityLabel> の検出がありました"

"タイトル: <title>"
"検出時刻: <time>"
"検出元: <productName>"
"詳細:"
"<description>"

入力すると以下のようになります。問題なければ次へ進んでいき、「ルールの作成」を押下します。

※その他制約事項や記法は以下をご確認ください

Amazon EventBridge input transformation
Amazon EventBridge input transformation

動作確認

最後に動作確認をします。今回は即座に検出されるようにすべてのポートが開かれたセキュリティグループを作成してみました。

検出内容を整形できていることが確認できました。

No.4 StepFunctionsを用いた編集

続いてStepFunctionsを用いた通知内容の編集をご紹介します。

前提

  1. No.3の手順が完了していること

作成手順

実際にやってみると基本的な流れはNo.3と同様であるため、No.3を編集していく形で進めてみます。

StepFunctionsの作成

SNSを用いてメールを送信する際にメールの件名を設定したい場合、SDKから実行して上げる必要があります。No.2の例などではLambdaを用いて実行するのですが、今回は代わりにStepFunctionsのSDK統合を用います。

EventBridgeのターゲットととなり、SNSを実行するStepFunctionsを作成していきます。

ビジュアルワークフローを用いると以上の様になり、JSONの定義としては以下のようになります。10-11行目の変数がそれぞれ、メールの本文と件名になります。

{
  "Comment": "A description of my state machine",
  "StartAt": "SNS Publish",
  "States": {
    "SNS Publish": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:sns:publish",
      "Parameters": {
        "TopicArn": "<ターゲットになるSNSトピックのARN>",
        "Message.$": "$.message",
        "Subject.$": "$.subject"
      },
      "End": true
    }
  }
}

Event Bridgeの修正

前項で記載のとおり、10-11行目の変数に対してEventBridgeで値を渡すように変更してあげれば完成です。

先ほど作成のEventBridgeルールを編集していきます。「ターゲット」タブから「編集」を押下します。

イベントのターゲットを先ほど作成のStepFunctionsに変更します。

さらに入力テンプレートを以下のようなJSON形式に変更してあげます。

基本的な記法はさきほど同様で、定義した変数は<variable>のように指定し、改行は\nで実現できます。

{
  "subject":"アカウントID <account> にて重要度 <severityLabel> の検出がありました",
  "message":"タイトル: <title> \n検出時刻: <time> \n検出元: <productName> \n詳細: \n<description>"
}

動作確認

先ほど同様にすべてのポートが開かれたセキュリティグループを作成してみました。

検出内容だけでなく、件名も整形できていることが確認できました。

まとめ

簡単な手順でSecurity Hubの通知が整形できることがわかりました。
要件に応じて活用することで通知の確認作業が格段に楽になるのでは無いでしょうか?

このブログがどなたかのお役に立てれば幸いです。以上、akiraでした!

AUTHOR
akira
akira
記事URLをコピーしました