Amazon AWS Cloud でのインシデント対応:どこから考え始めれば良いのか?

Incident Response In The AWS Cloud

2021/09/30 CyberSecurityIntelligence — Amazon Web Services (AWS) のクラウドは、他の主要クラウド。ベンダーと同様に、責任共有モデルで機能している。つまり、AWS 側は基盤となるインフラを保護し、クラウドの顧客側は、アカウントと権限、ネットワークとデータ、クラウドに配置されたアプリケーション・コードなどの、クラウド上のリソースとデータを保護することが求められている。

したがって、クラウド・リソースの異常な使用や課金行為などの、潜在的な脅威を示す指標はいくつかある。そして、クラウド利用者が、タイムリーなインシデント対応を実現するためには、クラウド環境を継続的に監視する必要が生じる。具体的には、イベントログ・データの保存、および、AWS のセキュリティ機能の活用、必要に応じたサードパーティの監視ソリューションの追加などが考えられる。また、AWS クラウド内で発生したセキュリティ・イベントに対応するために、特別に設計されたインシデント対応計画を作成する必要がある。

AWSセキュリティ・インシデントのドメイン

組織の責任範囲内には、セキュリティに関連するインシデントが発生し得る3つのドメインが存在する。このドメインの違いは、対応に用いるツールに関係することになる。

3つのドメインは以下の通りである

Service Domain: サービス・ドメインのインシデントは、顧客 IAM 権限や、AWS アカウント、課金、リソースのメタデータなどに影響を与える。サービス・ドメインのイベントは、AWS API のメカニズムだけで対応するイベント、または、リソースの権限や構成に関連する根本的な原因があるイベントとなり、関連するサービス指向のロギングが存在する場合がある。

Infrastructure Domain:インフラストラクチャ・ドメイン内のインシデントは、ネットワークまたはデータに接続されたアクティビティとなる。具体的には、Amazon EC2 インスタンス上のデータとプロセス、および、VPC 内の Amazon EC2 インスタンスへのトラフィック、コンテナ・サービスなどのコンポーネントが含まれる。これらのイベントへの対応は、フォレンジック目的でのインシデント関連データの復元/取得/検索を伴う傾向がある。通常では、インスタンスのオペレーティング・システムとの通信が含まれ、特定のケースでは、AWS API メカニズムが含まれることもある。

Application Domain:このドメインでのインシデントは、インフラストラクチャおよびサービスへ向けて展開された、ソフトウェア/アプリケーションのコードで発生するもとなる。 このドメインは、ユーザー・クラウドにおける脅威対応と検出 Runbook の要素となる必要があり、インフラストラクチャ・ドメイン内のような対応を組み込むことが可能である。 考慮された適切なアプリケーション・アーキテクチャを使用すると、自動的なリカバリ/フォレンジック/デプロイメントを利用するクラウド・ツールを介して、このドメインを監視できる。

これらの各領域では、自社のリソース/データ/アカウントに対して行動を起こす可能性のある、サイバー犯罪者について考える必要がある。外部であれ内部であれ、リスク・フレームワークを利用して、組織にとっての特定のリスクを確認し、それらのリスクを念頭に置いて対策を講じる。

サービス領域では、AWS の API のみで目的を達成することを目指す。インフラストラクチャ領域では、ワークステーションの OS に Digital Forensics / Incident Response (DFIR) と、AWS API を採用することができる。たとえば、Incident Response (IR) の目的で開発した Amazon EC2 インスタンスなどが挙げられる。

インフラストラクチャ領域のインシデントには、Amazon Elastic Block Store (Amazon EBS) ボリューム上のディスク・ブロックおよび、ネットワーク・パケット・キャプチャの調査、そしてインスタンス経由で取得した揮発メモリ内容などがある。ランサムウェアの脅威が高まっているため、AWS のバックアップ戦略を慎重に行うことが重要となる。

AWS セキュリティ・イベントの指標

いくつかのセキュリティ・イベントは、インシデントとは見なされないかもしれないが、調査する価値があるかもしれない。AWS クラウド環境におけるセキュリティ関連のイベントを特定するためには、以下のような仕組みを利用することができる。完全なリストではないが、潜在的な指標の例を考えてみまよう。

Logs and Monitors: AWS ログ (Amazon S3 Access Logs/Amazon CloudTrail/VPC Flow Logs を含む) と、セキュリティ監視サービス (Amazon Detective/Amazon GuardDuty/Amazon Macie/AWS Security Hub を含む) を確認する。Amazon CloudWatch のアラームや、Amazon Route 53 のヘルスチェックなどの、モニターを利用する。Linux syslog Logs/Windows Event/アプリケーションごとに作成した固有の Log を使用し、CloudWatch Agent 経由で Amazon CloudWatch に送信する。

・Billing Activity:請求アクティビティの予期せぬ変化は、セキュリティ・イベントを示している可能性がある。

・Threat Intelligence: サードパーティのインテリジェンス・フィードにサインアップした場合、その情報を他のモニタリング/ロギング・ツールと合わせて用いることで、指標となる可能性のあるイベントを見つけ出すことができる。

・One-time Contract: 開発者/顧客/スタッフなどが、何らかの異常を発見した場合に、セキュリティ・チームに対して連絡するための、明確な手順を用意する必要がある。具体的には、連絡先の電子メールアドレス/Web フォーム/チケット・システムなどがある。また、パブリックを相手にする組織であれば、一般向けのセキュリティ契約ツールが必要になることもある。

AWS Security Hub は、AWS が提供する検知/自動化のためのツールである。この Security Hub では、AWS アカウントのコンプライアンス状況や優先度の高いセキュリティアラートの詳細を、一元的に把握することができる。したがって、必要となる指標の可視性を高めることができる。

AWS Security Hub は、SIEM (Security Information and Event Management) ソフトウェアと同等ではないため、ログデータは保持されない。むしろ、複数の AWS サービスからのセキュリティ・アラートを整理/集約し、優先順位を付けるという役割を担う。

これにより、イベントが発生した際に、セキュリティ・オペレーションチームは。より深い洞察を得ることができる。Security Hub は、AWS 業界標準および、顧客組織が遵守するベスト・プラクティスに従って、自動化されたコンプライアンス・チェックを用いることで、継続的に環境を監視していく。

AWS セキュリティ・インシデント対応計画

組織内のすべての AWS ユーザーは、セキュリティ・インシデント対応手順を理解している必要があり、セキュリティ担当者は、セキュリティ問題への対応方法を知っている必要がある。準備と教育は必要不可欠だが、顧客サイドでのシミュレーションにより必要なスキルを実践し、プロセスの改善と反復を行うことが推奨される。クラウドで成功するインシデント対応計画は、次のことを実現する必要がある。

・クラウド・テクノロジーおよび、自組織による使用方法/計画について、セキュリティ・インシデント/オペレーション・レスポンスのスタッフを教育する。

・インシデント対応チームに対して、検出のための権限を与え、必要なツールとクラウドサービスへの適切なアクセスレベルを提供することで、クラウド内のインシデントに対する準備を整える。 一貫性のある信頼性の高いレスポンスを確保するために、自動/手動で必要となる Runbook を準備する。 各種のチームと協力して、期待される基本的な運用を作成し、その知識を用いて、通常の運用からの逸脱に気づくようにする。

・想定外/想定内のセキュリティ・イベントをクラウド上でシミュレートし、どれだけ準備ができているかを実証する。

・シミュレーションを繰り返して、遅延を減らし、対応態勢の規模を拡大し、リスクをさらに最小化する。

おわりに

この記事では、AWSクラウド内でのインシデント対応の基本を説明してきた。

・共有セキュリティ・モデルと、クラウドの顧客サイドで保護するすべき3つのドメインを理解すること。

・AWSセキュリティ・イベントの指標を監視し、必要に応じてログ/監視/脅威インテリジェンスのプロセスを確立すること。

・クラウド環境に特有のセキュリティ課題をカバーするために設計された、AWS セキュリティ・インシデント対応計画の策定と実施。

この記事が、AWS クラウドにおけるインシデント対応の実践とプロセスの、作成/実施/維持について、理解を深めるための一助となれば幸いである。

こういう記事が出てくると、AWS ユーザーだけではなく、あらゆるクラウド・サービスを利用するユーザーが、考える起点を得られるので、とても助かると思います。ただ、個々の脆弱性を、どのような方式で、クラウド・プロバイダーがトラッキングするのかという点が、現時点では不明です。以前に、「Black Hat 2021:クラウドの脆弱性にも CVE アプローチが必要なのか?」という記事をポストしましたが、CVE によるトラッキングが可能になると嬉しいですね。

%d bloggers like this: