[レポート]SEC416: AWSのフォレンジックをサーバレスに行う方法 #reinvent
こんにちは、臼田です。
本記事はAWSの一大イベントであるre:Inventの下記セッションについてのレポートです。
SEC416 - How to Perform Forensics on AWS Using Serverless Infrastructure
Performing forensics on AWS resources is a new experience for many customers who might have older runbooks based on on-premises workflows using manual steps, or perhaps no processes in place at all. In this session, get a deeper insight into the various runbooks to perform practical forensic tasks on AWS resources like Amazon EC2 instances, using a combination of industry tooling, AWS serverless services like AWS Lambda and AWS Step Functions, and managed services like Amazon Athena.
Henrik Johansson - Principal, Office of the CISO, AWS Andrew Krug - Staff Security Engineer, Mozilla
新しく「ssm_acquire」というフォレンジックツールが公開された有意義なセッションでした!
レポート
登壇者はOffice of the CISOでもあるAWSのHenrik氏と、MozillaのAndrew氏
Andrew氏はAWSのフォレンジックツールをよく開発している方です。
クラウドのフォレンジックは簡単ではありません。クラウドは巨大で、フォレンジックのためのリソースの特定が困難であったり、利用するツールやプロセスが適切にスケールして利用できる必要があります。
しかしクラウドの進化は速く、時にツールは追いつけないことがあります。
常に準備をしておくことがフォレンジック可能な状態にする秘訣です。
常に環境の状態を保全しておくことで、異常を検知して復旧や封じ込めが可能です。
異常を検知するツールは下記のようなものがあります
- Amazon GuardDuty
- AWS Trusted Advisor
- SIEMのスレットインテリジェンス
- AWS CloudTrail anomalies
- Billing alarms
- AWS outreach
- Ad-hoc contact
例えば下記のようなコードでEC2を環境分離(自分の端末からしか通信できず、外部への通信は遮断する設定)にできます
#!/bin/bash aws ec2 authorize-secuirty-group-ingress --group-name isolation-sg \ --protocol tcp --port 22 --cidr YOUR.IP.ADDRESS.HERE/32 aws ec2 revoke-security-group-egress --group-id sg-BLOCL-ID \ --protocol '-1' --port all --cidr '0.0.0.0/0' \ # removed rule that allws all outbound traffic
付加情報として、環境分離はエビデンス取得後に行う必要があり、またautoscalingを利用している場合には終了前に追加の作業(EBSの保持や動作状況の保存など)が必要になる場合があります。
AWSのフォレンジックは下記のような理由で必要になります。
- コンプライアンス
- PCI、GDPR、ISO27001等
- インシデント対応計画も含まれます
- アラインメント
- 責任共有モデル対応など
- 顧客向け
- 様々な脅威から守る
- 信用を得る
フォレンジックのツールとして下記が利用可能です。
- AWSサービス
- Amazon cloudWatch Events
- AWS Lambda functions
- AWS Step Functions
- EC2 API
- AWS CLI
- Amazon Athena
- コミュニティのツール
- Rekall framework / Volatility framework
- ssm_acquire (new) - 今回新たに発表されました!
- AWS_IR
- MargaritaShotgun
フォレンジック環境はどのようなものか
- 標準のEC2イメージから派生したもの
- 適切なベースラインでハードニングする
- 必要な情報を含む使い捨ての環境を作成する
- 定期的に更新し、現在の環境を検証する
- 影響を受けたリソースを閉じて、フォレンジックを実行
各種エビデンスはインスタンス内にあるものとAPIベースで取得するものがあります
- インスタンスベース
- Syslog ファイル
- メモリサンプル
- APIベース
- CloudTrail
- インスタンスメタデータ
- ディスクスナップショット
追加のエビデンスとして下記も有用な場合があります。
- Amazon S3オブジェクトログ
- API Gatewayログ
- CloudFrontログ
- Docker containerログ
いいフォレンジックツールで作られるテナントの条件
- 取得時に新たに攻撃者に特権を渡さない
- 1つのインスタンスに対して各アクションを1回のみ行う
- 環境を変更する時に、前後の監査ログを取得する
- 可能な限り最小限の変更のみ行う
AWS Systems Manager(SSM)を利用したフォレンジックツールで、揮発性のデータをトリアージ・フォレンジック・その他のアプリで利用できるよう収集します
SSM Acquireはインシデントデータを環境分離や破壊に先立って、YAMLベースのシステムで使いやすいように変換して保存します
Github: https://github.com/mozilla/ssm-acquire
アーキテクチャは図のとおりです
コマンドを実行することにより様々なプロセスが動き、指定したEC2の情報をSSM経由で取得します
必要な情報は取得できるので、分析に専念することが可能です
- 現状では何をすればいいか
- フォレンジックが実施可能であることを認識し価値を提供する
- 環境分離・封じ込めの前段階の処理を理解する
- どのような証跡・ログを保存しているか把握する
- 次に何をすればいいか
- 潜在的なインシデントに対応するための覧ブックの作成を始める
まとめ
AWS環境の(特にEC2の)フォレンジックは、有事の際に必要ですが、そのためには平時から各種情報を取得し続けてインシデントに対応する準備をすることが大切であることがわかりました。
ssm_acquireを利用すると、サーバレスアーキテクチャでフォレンジックに必要な情報を安くて簡単に取得することができるため非常に有用です。
いざという時を意識して、このツールや考え方を利用してみてはいかがでしょうか?