BLEAで異常検出と通知を実装してインシデントの訓練まで行ってみた

2022/08 の JAWS-UG 名古屋でLTした内容です。
マルチアカウント版のBaseline Environment on AWSを手元で試してみてその挙動や効能を確認してみました。

Transcript

1. BLEAで異常検出と通知を実装して、 インシデントの訓練まで行ってみた 2022/08/24 高木 建太朗
2. 目次 1. この資料の目的 2. Baseline Environment on AWS（BLEA）とは 3. BLEAに関連する設定で実現できた環境 4. 事前準備 5. インシデントを発生させてみる 6. インシデントの通知を受け取ってみる 7. インシデント対応 8. Findingsのアーカイブ 9. まとめ
3. この資料の目的 背景 • AWS上でシステムを構築する際に、ユーザは要件に合わせてセキュリティを設定する必要があります • 設定に伴って、以下のような課題が発生します 1. 設定したセキュリティがAWS Well-Architected など※1に沿っているか自信をもてない 2. 複数アカウントを管理すると、全てのアカウントに最低限の設定がなされているか保証しにくい 3. 設定に要する工数が大きくなりがち • 上記の課題を解決する手段としてBaseline Environment on AWS（BLEA）が存在します 目的 １：BLEA によるマルチアカウントのセキュリティ設定を実施した※2ので事例を紹介します ＃設定の詳細な手順は本家に譲ります。ここでは運用した際にのありがたみ等の所感を述べます。 ２：BLEAで構築した環境でインシデントを模擬するツールを動作してみたので事例を紹介します ※１．AWS Security Reference Architecture (AWS SRA)も参照すべき ※２．スタンドアロン版は以下の記事が参考になります BLEA（CDK）を使用したAWSアカウントの簡単セットアップ https://tech.nri-net.com/entry/aws_setup_with_blea
4. Baseline Environment on AWS（BLEA）とは • AWSのセキュリティのベストプラクティスを実装した環境を、迅速に実現するためのテンプレート • テンプレートは AWS Cloud Development Kit (CDK) で実装されており、拡張可能 ＃セキュリティの要件は年次で変わるので重要 • 平易なコードで解説コメントを多くする方針で開発しており、CDK の学習用途としても使える • 日本のソリューションアーキテクトが発起したプロジェクト（応援したい） 参照１）https://aws.amazon.com/jp/blogs/news/announcing-baseline-environment-on-aws/ 参照２）https://www.slideshare.net/AmazonWebServicesJapan/20220409-aws-blea • 日本語でのドキュメントも提供されており、始めやすい。Git のリポジトリは以下 参照３）https://github.com/aws-samples/baseline-environment-on-aws
5. BLEAの利用パターン • BLEAには２種類の利用パターンがある。 • 今回はマルチアカウント版を適用してみた。 参照１より
6. BLEAに関連する設定で実現できた嬉しさ audit （親アカウント） guest（子アカウントa） guest（子アカウントc） … • 管轄するAWSのアカウントで何か起こった時にどのような効能がえられるか、の一例。 AWSの統括的な管理者 マイニング用の リソース 侵入、作成 攻撃者 Amazon GuardDuty AWS SNS AWS Chatbot 検出 Mail guest アカウント の管理者 効能１ 面倒な通知系をアカウ ントごとに実装しなく てよい Amazon GuardDuty AWS Security Hub IAM Access Analyzer 集約、管理 効能３（本資料では詳細割愛） セキュリティ上まずいセッティングは ConfigRuleで潰してくれる (EX. port 22 の 0.0.0.0/0 の SG ) #基本的なものに対して guest（子アカウントb） Security Group Port 22 IP 0.0.0.0/0 inbound 効能２ Organizationsの機能と連携して複数 アカウントのビューが得られる。また、 guestでのアーカイブが不可能になる。
7. 事前準備１ 詳細な手順は語るに落ちるので、本家を参照ください。ここでは以下を前提として進めます。 • ControlTowerを有効にしてマルチアカウントを管理可能にします • autid（親）とguest（子）アカウントを用意します （audit : 35始まりのアカウント、guest : 71始まりのアカウント） • auditアカウントでSecurityHub、GuardDuty、IAM Access Analyzer、TrustedAdviserのセットアップ を実施済みです。 このアカウントでインシデントを起こします。 サポートプランによっては 設定不可
8. 事前準備２ • 通知用のスラックチャネルを用意します。
9. 事前準備３ • それぞれのAWSアカウントのChatbot とSlackのworkspaceを連携させます。 workspace ID
10. • BLEAのプロジェクトをクローンします • ディレクトリに移動します • 依存パッケージを取得します • コンフィグ2~3行書き換えてコマンド実行（通知用のmail アドレスや,Slackの情報を書き換えます） • ここまで実施するとauditと1つのguestアカウントにセキュリティ用のスタックがデプロイされます 事前準備４(@Local PC) git clone https://github.com/aws-samples/baseline-environment-on-aws.git Cloning into 'baseline-environment-on-aws'... ... Receiving objects: 100% (700/700), 6.59 MiB | 6.05 MiB/s, done. Resolving deltas: 100% (361/361), done cd .¥baseline-environment-on-aws npm ci cdk destroy --all -c environment=dev-audit --profile master cdk destroy --all -c environment=dev --profile ct-guest
11. インシデントを発生させてみる１ • ここまででセキュリティに関するスタックが完成したのでインシデントを発生させてみる • 利用ツールは guard-duty-tester • クリプトマイニングの疑似的環境を構築してGuardDutyの通知を発生させる 攻撃用インスタンスと 被攻撃用インスタンス を構築してシミュレー ションが可能 参照４）guard-duty-tester https://github.com/awslabs/amazon- guardduty-tester
12. インシデントを発生させてみる２ • 攻撃用インスタンスからスクリプトを実行 • しばらく待つとGuardDuty が反応して Findingsが発生する パスワード総攻撃や、 ポートスキャンを検出
13. インシデントの通知を受け取る（効能１） • Guard Duty の検出結果をメールとSlackのメッセージとして受け取ることができた #デフォルトではseverity 4以上を通知する設定となっている • メールの文面は少し読みづらいので入力テンプレートを調整した方がいいかもしれない メール文面 PC Slack アプリ スマホSlackアプリ
14. インシデント対応 • GuardDutyの通知を見てみると以下の様にあるのでインスタンスをマネコンから停止/終了させた 1. i-028cca6e2b0791c3a is performing SSH brute force attacks against 172.16.0.29. 2. i-028cca6e2b0791c3a is performing RDP brute force attacks against 172.16.0.28. 3. EC2 instance i-028cca6e2b0791c3a is performing outbound port scans against remote host 172.16.0.29. ＃実運用では連絡体制構築やフォレンジック用のメモリダンプなどの対応が必要と思われます • Slackからコマンド発行しようとしたらデフォルトではReadOnlyの権限しかないため、インスタ ンスの状態を変えるコマンドは発行できなかった。
15. Findingsのアーカイブ（効能２） • BLEAの設定過程でGuardDutyもaudit と guest の関係になっており、audit 側でguest側の Findingsを確認することができる。また、guest 側ではアーカイブ操作ができなくなっている • guest側での「よくわからないけど、とりあえずアーカイブしてしまおう」が防げ • audit 側でFindingsをアーカイブして、一連の流れを終了 audit : 35始まりのアカウント guest : 71始まりのアカウント guest 側では アーカイブできない audit 側では アーカイブできる
16. まとめ • BLEA によるマルチアカウントのセキュリティ設定を実施したので事例を紹介しました • インシデントを模擬するツール(gurad-duty-tester)を紹介しました • BLEAを利用すると嬉しいなと感じたのは以下の点です 1. 面倒なセキュリティの通知系をアカウントごとに実装しなくてよい 2. Organizationsの機能と連携して複数アカウントのセキュリティのビューが得られる。 guest アカウント側での勝手なアーカイブが防げる。 3. 基本的なセキュリティ上まずいセッティングをConfigRuleで潰してくれる Ex. Port 22 に対する 0.0.0.0/0 からのインバウンドを許可するセキュリティグループ • BLEAを使ってみて、改善したいなと思った点は以下です。 1. GuardDutyのFindingsをメールで通知する際の入力テンプレートが改行を含まないため非常 に読みづらい