AWS 環境でセキュリティレスポンスの自動化を始める方法

AWS では、AWS 環境内のセキュリティイベントについて自動化による迅速な検知と対応をすることをお勧めしてます。自動化は、検知と対応の速度を向上させることに加えて、AWS で実行するワークロードを拡大するときにセキュリティ運用もスケーリングするのに役立ちます。これらの理由から、セキュリティの自動化は、Well-Architected フレームワークとクラウド導入フレームワークの両方、およびAWS セキュリティインシデント対応ガイドで概説されている重要な原則です。

このブログでは、AWS 環境内に自動セキュリティレスポンスメカニズムを実装する方法を学習します。このブログには、一般的なパターン、実装に関する考慮事項、およびソリューション例が含まれます。セキュリティレスポンスの自動化は、多くの分野にまたがる広範なトピックです。このブログの目標は、基本的な考え方を紹介し、セキュリティレスポンスの自動化の開始を支援することです。

セキュリティレスポンスの自動化とは?

セキュリティレスポンスの自動化は、条件またはイベントに基づいてアプリケーションまたはリソースの目的の状態を達成するために実行される計画およびプログラムされたアクションです。セキュリティレスポンスの自動化を実装するときは、既存のセキュリティフレームワークから引き出すアプローチを採用する必要があります。フレームワークは、組織がサイバーセキュリティ関連のリスクを管理できるようにするための標準、ガイドライン、およびベストプラクティスで構成される公開資料です。フレームワークを使用すると、一貫性と拡張性を実現し、セキュリティプログラムの戦略的側面にもっと集中できるようになります。組織内のコンプライアンスの専門家と協力して、AWS 環境にも関連する可能性のある特定のセキュリティフレームワークを理解する必要があります。

サンプルソリューションは、NIST Cybersecurity Framework （CSF）に基づいています。これは、組織がセキュリティイベントを防御、検知、および対応する能力を評価および改善できるように設計されています。CSF によれば、「サイバーセキュリティインシデントレスポンス」は、潜在的なサイバーセキュリティインシデントの影響を封じ込める能力をサポートします。自動化は CSF の要件ではありませんが、イベントへの対応を自動化すると、脅威を監視して対応するための再現可能で予測可能なアプローチを作成できます。

CSF の5つの主要なステップは、識別、防御、検知、対応、および復旧です。自動化と調査を含むように、検知と対応のステップを拡張しました。

図1: CSF の5つのステップ

上の図の各ステップの以下の定義は CSF に基づいていますが、このブログのサンプルに合わせて変更されています。検知、自動化、対応の各ステップに焦点を当てますが、プロセスフロー全体を理解することが重要です。

識別: AWS 環境内のリソース、アプリケーション、およびデータを識別して理解します。
防御: サービスの提供を確実にするために、適切な統制と防御を開発および実装します。
検知: サイバーセキュリティイベントの発生を識別するための適切なアクティビティを開発および実装します。このステップには、次のセクションでさらに説明するモニタリング機能の実装が含まれます。
自動化: 条件またはイベントに基づいて、アプリケーションまたはリソースの望ましい状態を達成する計画的でプログラムされたアクションを開発および実装します。
調査: 根本的な原因を確証するために、セキュリティイベントの体系的な調査を実行します。
対応: 検知されたセキュリティイベントに関する自動または手動のアクションを実行するための適切なアクティビティを開発および実装します。
復旧: 回復力の計画を維持し、セキュリティイベントにより低下した機能またはサービスを復旧するための適切なアクティビティを開発および実装します。

AWS 環境でのセキュリティレスポンスの自動化

AWS CloudTrail、AWS Config および Amazon EventBridge は AWS アカウントのリソースおよび構成の変更に関する詳細を継続的に記録します。この情報を使用して、リソースの変更を自動的に検知し、望ましくない状態に対して対応できます。

図2: 自動修復フロー

上の図に示すように、AWS の自動修復フローには3つの段階があります。

監視: 自動監視ツールは、AWS 環境で実行されているリソースとアプリケーションに関する情報を収集します。たとえば、AWS アカウントで実行されたアクティビティに関する AWS CloudTrail 情報、Amazon EC2 インスタンスからの使用状況メトリック、または Amazon Virtual Private Cloud (VPC)のネットワークインターフェイスを行き来するトラフィックに関するフローログ情報を収集する場合があります。
検知: 監視ツールが、しきい値超え、異常なアクティビティ、構成情報の逸脱などの事前定義された条件を検知すると、システム内でフラグを立てます。トリガー条件は、Amazon GuardDuty によって検知された異常なアクティビティ、AWS Config Rule に準拠していないリソース、Amazon VPC セキュリティグループまたは AWS WAF ウェブアクセスコントロールリストでブロックされたリクエスト数の異常値などです。
対応: 条件にフラグが付けられると、事前定義されたアクションを実行する自動レスポンスがトリガーされます。これは、フラグが付けられた条件を修正または緩和するためのものです。自動レスポンスのサンプルには、VPC セキュリティグループの変更、Amazon EC2 インスタンスへのパッチ適用、認証情報のローテーションが含まれます。

上記のイベント駆動型フローを使用して、さまざまな種類の自動レスポンスパターンを数多く実現できます。レスポンスパターンは、単一の AWS Lambda 関数を呼び出すのと同じくらい単純な場合もあれば、高度なロジックを備えた複雑な一連の AWS Step Function タスクの場合もあります。このブログでは、サンプルソリューションで2つの単純な Lambda 関数を使用します。

レスポンス自動化の定義方法

セキュリティレスポンスの自動化の概念が導入されたので、自動化によって実施する環境内のセキュリティ要件について考えてみましょう。設計要件は、一般的なベストプラクティスに基づいている場合もあれば、ビジネスに関連する特定のコンプライアンスフレームワークの統制である場合もあります。目標は定性的ではなく定量的でなければなりません。定量目標の例を次に示します。

リモートからネットワーク接続する特権アクセスの制限
サーバーストレージの暗号化
多要素認証による AWS コンソールへのログインの保護

オプションのステップとして、これらの目標を、イベントが発生した場合の条件と修復アクションを定義するユーザーストーリーに拡張できます。ユーザーストーリーは、ソフトウェアシステム内の機能を文書化した形式ばらない形の説明です。ユーザーストーリーはグローバルで、複数のアプリケーションにまたがる場合もあれば、単一のアプリケーションに固有の場合もあります。ユーザーストーリーの例です。

「リモートからネットワーク接続する特権アクセスは制限する必要があります。リモートアクセスポートには、SSH の TCP/22および RDP のTCP/3389が含まれます。AWS 環境内で開いているリモートアクセスポートが検知された場合、それらは自動的に閉じられ、管理者に通知されます。

ユーザーストーリーを完了したら、AWS 環境でこれらの目標を達成するために自動修復の方法を決定できます。ユーザーストーリーは、バージョン管理機能を提供し、関連する自動化コードを参照できる場所に保存する必要があります。

リソースとアプリケーションへの意図しない影響を防ぐために、修復メカニズムの効果を慎重に検討する必要があります。インスタンスの終了、認証情報の取り消し、セキュリティグループの変更などの修復アクションは、アプリケーションの可用性に悪影響を及ぼす可能性があります。組織が許容できるリスクのレベルに応じて、自動化されたメカニズムは通知を提供するだけで、修正前に手動で調査するようにもできます。自動修復メカニズムを特定したら、必要なコンポーネントを構築し、プロダクション以外の環境でテストします。

レスポンス自動化の例

次のセクションでは、不正なアクティビティの可能性（CloudTrail ロギングの意図しない無効化）を示唆するシミュレーションイベントの自動修復について説明します。外部の悪意のある者は、許可されていないアクティビティの検知と記録を防ぐために、ロギングを無効にしたいでしょう。私たちの対応は、CloudTrail ロギングを再度有効にして、すぐにセキュリティ担当者に通知することです。このシナリオのユーザーストーリーは次のとおりです。

「CloudTrail のロギングは、すべての AWS アカウントとリージョンで有効にする必要があります。CloudTrail ロギングが無効になっている場合、自動的に有効になり、セキュリティ運用チームに通知されます。」

注: このレスポンス自動化サンプルは、CloudWatch イベントをベースに拡張したAmazon EventBridgeを利用しています。Amazon EventBridge は Amazon CloudWatch イベントと同じ API を使用するため、イベントの構造とルールの設定方法は同じです。このブログ投稿では、EventBridge イベントと CloudWatch イベントの両方で同一の基本機能を使用しています。

前提条件

サンプルの修復を使用するには、選択したAWSリージョンで Amazon GuardDuty および AWS Security Hub を有効にする必要があります。これらのサービスには、30日間の無料試用版が含まれています。詳細については、AWS Security Hub の料金ページと Amazon GuardDuty の料金ページをご覧ください。

重要: AWS CloudTrail を使用して、サンプルの修復をテストします。AWS アカウントで複数のCloudTrail の証跡情報を有効にすると、その間に処理されたイベントの数に基づいて料金が発生します。リージョンで記録された管理イベントの追加コピーの料金は、公開されている料金設定プランに基づいて適用されます。料金を最小限に抑えるには、このブログの後半で提供するクリーンアップ手順に従って、自動化サンプルを削除し、証跡情報を削除します。

レスポンス自動化サンプルのデプロイ

このセクションでは、CloudTrail ロギング修復サンプルをデプロイしてテストする方法を示します。Amazon GuardDuty は、CloudTrail のロギングが無効になっている場合には、Stealth：IAMUser/CloudTrailLoggingDisabledd を生成します。AWS Security Hub は標準化された AWS Security Finding 形式で GuardDuty から検索結果を収集します。この自動化サンプルを本番以外の AWS アカウントにデプロイすることをお勧めします。

下の「Launch Stack」ボタンをクリックして、自動化サンプルを含む CloudFormation テンプレートを us-east-1 リージョンにデプロイします。テンプレートをダウンロードして、別のリージョンに実装することもできます。テンプレートは、Amazon EventBridge ルール、AWS Lambda 関数、および両方のコンポーネントの実行に必要な IAM アクセス許可で構成されています。CloudFormation スタックのビルドが完了するまで数分かかります。

CloudFormation コンソールのスタックの作成ページにて、「次へ」を選択します。
スタックの詳細を指定ページにて、セキュリティ連絡先のメールアドレスを入力します。（このチュートリアルでは、アクセスできる電子メールアドレスである必要があります）。「次へ」を選択します。
スタックオプションの設定ページにて、デフォルト設定値を変更せずに、「次へ」を選択します。
レビューページにて、内容を確認および「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを入れてから、「スタックの作成」を選択します。
スタックの作成中に、ステップ2で指定したメールアドレスの受信ボックスを確認してください。件名が AWS Notification – Subscription Confirmation のメールがあります。メールの本文にあるリンクを選択して、 Amazon Simple Notification Service （Amazon SNS）トピックへのサブスクリプションを確認します。以下のスクリーンショットのような成功メッセージが表示されるはずです。

図3：SNS サブスクリプションの確認
CloudFormation コンソールに戻ります。 CloudFormation スタックの Status フィールドが CREATE COMPLETE に変更されると（図4を参照）、ソリューションが実装され、テストの準備が整います。

図4：CREATE_COMPLETE ステータス

自動化サンプルのテスト

ここまでの作業でレスポンスの自動化をテストする準備が整いました。CloudTrail でテスト用証跡情報を作成して停止を試みることができます。

AWS マネジメントコンソールの上部メニューバーの「サービス」から「CloudTrail」を選択します
「証跡情報」を選択してから「証跡の作成」を選択
「証跡情報の作成」画面:
1. 証跡名の値を入力します。以下の例では test-trail を使用しています。
2. 「管理イベント」で、「書き込み専用」を選択します。（イベントボリュームを最小化するため）
  
  図5：CloudTrail 証跡情報を作成する
3. 「ストレージの場所」で、既存の S3 バケットを選択するか、新しいバケットを作成します。S3バケット名はグローバルに一意であるため、名前に文字（ランダムな文字列など）を追加する必要があることに注意してください。例： my-test-trail-<bucket-random-string>
4. 内容の確認後にページ下部の「作成」を選択してください。
CloudTrail コンソールの「証跡情報」ページで、新しい証跡情報が開始されたことを確認します。図6に示すように、「ステータス」列に緑色のチェックマークが表示されます。

図6：新しい証跡情報開始の確認
これで、許可されていないユーザーが自分の痕跡を隠そうとしているように振る舞う準備が整いました！作成したばかりの証跡情報のロギングを停止します。
1. 新しく作成した証跡名を選択して設定ページを表示します。
2. ページ右上の「ログ記録」スイッチを OFF に切り替えます。
3. 警告ダイアログボックスが表示されたら、「続行」を選択します。
4. 次に示すように、「ログ記録」スイッチが OFF になっていることを確認します。
  
  図7：ログ記録スイッチがオフになっていることを確認
  
  これで、CloudTrail サービスのいずれかの証跡情報のログ記録を無効にするセキュリティイベントをシミュレートできました。数秒以内に、ニアリアルタイムでレスポンスの自動化が停止した証跡情報を検知し、再有効化をして、電子メール通知を送信します。CloudTrail コンソールの証跡情報ページを更新して、ログ記録スイッチのステータスが再び ON になっていることを確認できます。
  
  さらに数分以内に、調査の自動レスポンスも開始されます。GuardDutyは、証跡情報を停止したアクションを検知し、予期しない動作の原因に関するデータをエンリッチさせます。Security Hub はその情報を取り込み、オプションで他のセキュリティイベントと相関します。
  
  次の手順に従って、Security Hub で検出結果タイプ TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled が生成されるかどうかを確認します。
AWSマネジメントコンソールの上部メニューバーの「サービス」から「Security Hub」を選択します
1. 左ペインの「検出結果」を選択します。
2. 「フィルターの追加」フィールドをクリックし「タイプ」を選択します。EQUALS を選択し、TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled をフィールドに貼り付けて「Apply」をクリックします
3. 検出結果が生成されるまでブラウザを定期的に更新してください。
  
  図8：Security Hub で検出結果を確認
調査結果のタイトルを選択して、詳細を確認します。確認が終わったら、「アーカイブ」を選択して、検出結果をアーカイブすることができます。または、「アクション」のプルダウンメニューから事前に設定したカスタムアクションを選択して対応をすることができます。カスタムアクションは、Security Hub をパートナーソリューションと統合できる方法の1つです。

調査結果のレビューが完了したので、自動化のコンポーネントを掘り下げましょう。

自動化サンプルの仕組み

このサンプルには、ニアリアルタイムのワークフローと調査ワークフローの2つの自動化レスポンスが組み込まれています。ニアリアルタイムのワークフローにより、個々のイベント（この場合は CloudTrail 証跡情報の停止）に迅速に対応できます。目標は、証跡情報のロギング状態を復元し、セキュリティ担当者にできるだけ早く警告することです。調査のワークフローには、多層防御を提供するための対応が含まれており、インシデントのより詳細な調査をサポートするサービスも使用しています。

図9：サンプルの自動化ワークフロー

図9：自動化サンプルワークフロー

ニアリアルタイムのワークフローでは、Amazon EventBridge は望ましくないアクティビティを監視します。証跡情報が停止すると、AWS CloudTrail は EventBridge バスにイベントを発行します。EventBridge ルールは証跡情報停止イベントを検知し、Lambda 関数を呼び出して証跡情報を再有効化する対応をしています。Lambda 関数は Amazon Simple Notification Service （SNS）トピックを介してセキュリティ担当者に通知します。

調査のワークフローでは、CloudTrail ログで好ましくないアクティビティが監視されます。たとえば、証跡情報が停止した場合、それに対応するログレコードがあります。GuardDuty はこのアクティビティを検知し、API 呼び出しを実行したソース IP に関する追加のデータポイントを取得します。GuardDuty の結果に含まれるこれらの追加データポイントの2つの一般的な例には、API 呼び出しが脅威リストの IP アドレスからのものか、AWS アカウントで一般的に使用されないネットワークからのものかが含まれます。AWS Lambda 関数は、CloudTrail の証跡情報を再有効化してセキュリティ担当者に通知します。検出結果は AWS Security Hub にインポートされ、アナリストが表示できるように他の検出結果と統合されます。EventBridge を使用すると、調査結果をパートナーセキュリティオーケストレーションツール、SIEM（セキュリティ情報およびイベント管理）システム、およびチケットシステムにエクスポートするように Security Hub を設定できます。

AWS Security Hub は、GuardDuty、Amazon Macie、Amazon Inspector などの AWS セキュリティサービスと、統合したサードパーティ製品の検出結果をインポートします。すべての検出結果は、AWS Security Finding 形式で Security Hub に提供されます。これにより、データ変換の必要がなくなります。Security Hub はこれらの調査結果を関連付けて、関連するセキュリティイベントを特定し、根本原因を特定するのに役立ちます。また、Security Hub はその検出結果を Amazon EventBridge に発行して、AWS Lambda などの他のAWS サービスによるさらなる処理を可能にします。Security Hub を使用してカスタムアクションを作成することもできます。カスタムアクションは、一つまたはいくつかの検出結果をレスポンスワークフローまたは修復ワークフローに送信することができ、Security Hub コンソールで作業するセキュリティアナリストに役立ちます。カスタムアクションの詳細については、AWS パートナーネットワーク（APN）ブログのHow to Enable Custom Actions in AWS Security Hub を確認してください。

対応ステップの詳細

Amazon EventBridge と AWS Lambda は連携してセキュリティの検出結果に対応します。Amazon EventBridge は、コードを記述せずに、AWS サービス、独自のアプリケーション、および Software-as-a-Service（SaaS）アプリケーションのデータの変更へのリアルタイムアクセスを提供するサービスです。このサンプルでは、EventBridge はアクションが必要な Security Hub の検出結果を識別し、修復を実行する Lambda 関数を呼び出します。図10に示すように、Lambda 関数は、SNS 経由でセキュリティ担当者に通知し、停止した CloudTrail の証跡情報を再有効化します。

図10: サンプルの対応ワークフロー

この対応を設定するために、証跡情報が停止されたか無効になったことを示すイベントを探しました。CloudTrail のログ記録が無効になっている場合、GuardDuty がStealth:IAMUser/CloudTrailLoggingDisabledを検知していることがわかりました。したがって、このイベントを検索するようにデフォルトのイベントバスを設定しました。利用可能なすべての GuardDuty の検出結果の詳細については、ユーザーガイドをご覧ください。

コードの詳細

Security Hub が EventBridge に発行した検出結果には、GuardDuty によって検出されたインシデントの詳細が含まれます。検出結果は JSON 形式で発行されます。サンプルの検出結果の詳細を確認する場合、特定のイベントを識別するのに役立ついくつかのフィールドがあることに注意してください。関連する詳細の一部を次に示します。

{
   …
   "source":"aws.securityhub",
   …
   "detail":{
      "findings": [{
		…
    	“Types”: [
			"TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled"
			],
		…
      }]
}

これらのフィールドを使用してイベントパターンを構築しEventBridge ルールがイベントの識別と修復 Lambda 関数の呼び出しに使用できるようにします。以下は、前半に使用した CloudFormation テンプレートの抜粋で、EventBridge ルールのイベントパターンを定義しています。

# pattern matches the nested JSON format of a specific Security Hub finding
EventPattern:
source:
- aws.securityhub
detail-type:
- "Security Hub Findings - Imported"
detail:
findings:
Types:
- "TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled"

ルールが設定されると、EventBridge はこのパターンのイベントバスを継続的に監視します。EventBridge が一致を見つけると、修復 Lambda 関数を呼び出し、イベントの詳細を関数に渡します。Lambda 関数は、イベントの JSON フィールドを解析して、次に示す Python コードスニペットを実行します。

# extract trail ARN by parsing the incoming Security Hub finding (in JSON format)
trailARN = event['detail']['findings'][0]['ProductFields']['action/awsApiCallAction/affectedResources/AWS::CloudTrail::Trail']   

# description contains useful details to be sent to security operations
description = event['detail']['findings'][0]['Description']

また、このコードはセキュリティ担当者に通知を発行するため、Security Hub やその他のサービスの検出結果やインサイトを確認して、インシデントをよりよく理解し、さらに手動による対策が必要かどうかを判断できます。以下は、SNS を使用してセキュリティ担当者にメモを送信するコードスニペットです。


#Sending the notification that the AWS CloudTrail has been disabled.
snspublish = snsclient.publish(
	TargetArn = snsARN,
	Message="Automatically restarting CloudTrail logging.  Event description: \"%s\" " %description
	)

オペレーターによる手動の通知は重要ですが、Lambda 関数はアクションを瞬時に実行できます。CloudTrail で停止した証跡情報を再有効化することにより、すぐに状態を修正します。ロギングを再度有効にするために、証跡情報を再有効化するコードスニペットを次に示します。


#Enabling the AWS CloudTrail logging
try:
	client = boto3.client('cloudtrail')
	enablelogging = client.start_logging(Name=trailARN)
	logger.debug("Response on enable CloudTrail logging- %s" %enablelogging)
except ClientError as e:
	logger.error("An error occured: %s" %e)

証跡情報が再有効化された後、API アクティビティは再度ログに記録され、監査できます。これにより、インシデントレスポンスプロセスの残りの手順に関連するデータを提供できます。このデータは、チームが学んだ教訓を分析して将来のインシデントを防止するインシデント後のフェーズにとって特に重要です。また、このフェーズを使用して、インシデントレスポンスを自動化する追加の手順を識別することもできます。

クリーンナップ

セキュリティレスポンスの自動化サンプルを完了したら、このチュートリアルで作成したリソースをアカウントから削除して、 CloudTrail の証跡情報と S3 に保存されたデータの料金を最小限に抑えることをお勧めします。

重要: アカウントのリソースを削除すると、AWS アカウントで実行されているアプリケーションに悪影響を与える可能性があります。アプリケーションと AWS アカウントのセキュリティが、削除しようとしているリソースに依存していないことを確認してください。

クリーンアップ手順は次のとおりです。

CloudFormation のスタックを削除.
CloudTrail で作成した証跡情報を削除.
CloudTrail ログ用の S3 バケットを作成した場合、その S3 バケットも削除.
新しいアカウントは、GuardDuty を30日間無料で試すことができます。無料試用終了前に GuardDuty を一時停止または無効にして、課金を回避できます
新しいアカウントは、Security Hub を30日間無料で試すことができます。無料試用終了前に Security Hub を無効にして、課金を回避できます

まとめ

AWS 環境でのセキュリティレスポンスの自動化の背後にある基本的な考え方と考慮事項、および Amazon EventBridge、Amazon GuardDuty、AWS Security Hub を使用して、AWS CloudTrail が予期せず無効になったときに自動的に再有効化する方法を学習しました。

次のステップとして、お客様の環境で自動化レスポンスの構築を開始し、AWS セキュリティインシデント対応ガイド、NIST Cybersecurity Framework（CSF）、またはクラウド導入フレームワーク(CAF) セキュリティパースペクティブをさらに掘り下げてください。AWS セキュリティブログで追加の自動修復ソリューションを調べることができます。このチュートリアルで使用したサンプルコードは GitHub にあります。

このブログについてフィードバックがある場合は、以下のコメントセクションで送信してください。このソリューションの使用について質問がある場合は、EventBridge、 GuardDuty、または Security Hub のフォーラムのスレッドを開始するか、AWS サポートにお問い合わせください。

AWS セキュリティのニュースがさらに必要ですか？ Twitter でフォローしてください。

ブログの原文はこちらです。

翻訳は SA 中島が担当しました。

Amazon Web Services ブログ