Slide 1

Slide 1 text

BLEAで異常検出と通知を実装して、 インシデントの訓練まで行ってみた 2022/08/24 高木 建太朗

Slide 2

Slide 2 text

目次 1. この資料の目的 2. Baseline Environment on AWS(BLEA)とは 3. BLEAに関連する設定で実現できた環境 4. 事前準備 5. インシデントを発生させてみる 6. インシデントの通知を受け取ってみる 7. インシデント対応 8. Findingsのアーカイブ 9. まとめ

Slide 3

Slide 3 text

この資料の目的 背景 • AWS上でシステムを構築する際に、ユーザは要件に合わせてセキュリティを設定する必要があります • 設定に伴って、以下のような課題が発生します 1. 設定したセキュリティがAWS Well-Architected など※1に沿っているか自信をもてない 2. 複数アカウントを管理すると、全てのアカウントに最低限の設定がなされているか保証しにくい 3. 設定に要する工数が大きくなりがち • 上記の課題を解決する手段としてBaseline Environment on AWS(BLEA)が存在します 目的 1:BLEA によるマルチアカウントのセキュリティ設定を実施した※2ので事例を紹介します #設定の詳細な手順は本家に譲ります。ここでは運用した際にのありがたみ等の所感を述べます。 2:BLEAで構築した環境でインシデントを模擬するツールを動作してみたので事例を紹介します ※1.AWS Security Reference Architecture (AWS SRA)も参照すべき ※2.スタンドアロン版は以下の記事が参考になります BLEA(CDK)を使用したAWSアカウントの簡単セットアップ https://tech.nri-net.com/entry/aws_setup_with_blea

Slide 4

Slide 4 text

Baseline Environment on AWS(BLEA)とは • AWSのセキュリティのベストプラクティスを実装した環境を、迅速に実現するためのテンプレート • テンプレートは AWS Cloud Development Kit (CDK) で実装されており、拡張可能 #セキュリティの要件は年次で変わるので重要 • 平易なコードで解説コメントを多くする方針で開発しており、CDK の学習用途としても使える • 日本のソリューションアーキテクトが発起したプロジェクト(応援したい) 参照1)https://aws.amazon.com/jp/blogs/news/announcing-baseline-environment-on-aws/ 参照2)https://www.slideshare.net/AmazonWebServicesJapan/20220409-aws-blea • 日本語でのドキュメントも提供されており、始めやすい。Git のリポジトリは以下 参照3)https://github.com/aws-samples/baseline-environment-on-aws

Slide 5

Slide 5 text

BLEAの利用パターン • BLEAには2種類の利用パターンがある。 • 今回はマルチアカウント版を適用してみた。 参照1より

Slide 6

Slide 6 text

BLEAに関連する設定で実現できた嬉しさ audit (親アカウント) guest(子アカウントa) guest(子アカウントc) … • 管轄するAWSのアカウントで何か起こった時にどのような効能がえられるか、の一例。 AWSの統括的な管理者 マイニング用の リソース 侵入、作成 攻撃者 Amazon GuardDuty AWS SNS AWS Chatbot 検出 Mail guest アカウント の管理者 効能1 面倒な通知系をアカウ ントごとに実装しなく てよい Amazon GuardDuty AWS Security Hub IAM Access Analyzer 集約、管理 効能3(本資料では詳細割愛) セキュリティ上まずいセッティングは ConfigRuleで潰してくれる (EX. port 22 の 0.0.0.0/0 の SG ) #基本的なものに対して guest(子アカウントb) Security Group Port 22 IP 0.0.0.0/0 inbound 効能2 Organizationsの機能と連携して複数 アカウントのビューが得られる。また、 guestでのアーカイブが不可能になる。

Slide 7

Slide 7 text

事前準備1 詳細な手順は語るに落ちるので、本家を参照ください。ここでは以下を前提として進めます。 • ControlTowerを有効にしてマルチアカウントを管理可能にします • autid(親)とguest(子)アカウントを用意します (audit : 35始まりのアカウント、guest : 71始まりのアカウント) • auditアカウントでSecurityHub、GuardDuty、IAM Access Analyzer、TrustedAdviserのセットアップ を実施済みです。 このアカウントでインシデントを起こします。 サポートプランによっては 設定不可

Slide 8

Slide 8 text

事前準備2 • 通知用のスラックチャネルを用意します。

Slide 9

Slide 9 text

事前準備3 • それぞれのAWSアカウントのChatbot とSlackのworkspaceを連携させます。 workspace ID

Slide 10

Slide 10 text

• BLEAのプロジェクトをクローンします • ディレクトリに移動します • 依存パッケージを取得します • コンフィグ2~3行書き換えてコマンド実行(通知用のmail アドレスや,Slackの情報を書き換えます) • ここまで実施するとauditと1つのguestアカウントにセキュリティ用のスタックがデプロイされます 事前準備4(@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

Slide 11

Slide 11 text

インシデントを発生させてみる1 • ここまででセキュリティに関するスタックが完成したのでインシデントを発生させてみる • 利用ツールは guard-duty-tester • クリプトマイニングの疑似的環境を構築してGuardDutyの通知を発生させる 攻撃用インスタンスと 被攻撃用インスタンス を構築してシミュレー ションが可能 参照4)guard-duty-tester https://github.com/awslabs/amazon- guardduty-tester

Slide 12

Slide 12 text

インシデントを発生させてみる2 • 攻撃用インスタンスからスクリプトを実行 • しばらく待つとGuardDuty が反応して Findingsが発生する パスワード総攻撃や、 ポートスキャンを検出

Slide 13

Slide 13 text

インシデントの通知を受け取る(効能1) • Guard Duty の検出結果をメールとSlackのメッセージとして受け取ることができた #デフォルトではseverity 4以上を通知する設定となっている • メールの文面は少し読みづらいので入力テンプレートを調整した方がいいかもしれない メール文面 PC Slack アプリ スマホSlackアプリ

Slide 14

Slide 14 text

インシデント対応 • 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の権限しかないため、インスタ ンスの状態を変えるコマンドは発行できなかった。

Slide 15

Slide 15 text

Findingsのアーカイブ(効能2) • BLEAの設定過程でGuardDutyもaudit と guest の関係になっており、audit 側でguest側の Findingsを確認することができる。また、guest 側ではアーカイブ操作ができなくなっている • guest側での「よくわからないけど、とりあえずアーカイブしてしまおう」が防げ • audit 側でFindingsをアーカイブして、一連の流れを終了 audit : 35始まりのアカウント guest : 71始まりのアカウント guest 側では アーカイブできない audit 側では アーカイブできる

Slide 16

Slide 16 text

まとめ • BLEA によるマルチアカウントのセキュリティ設定を実施したので事例を紹介しました • インシデントを模擬するツール(gurad-duty-tester)を紹介しました • BLEAを利用すると嬉しいなと感じたのは以下の点です 1. 面倒なセキュリティの通知系をアカウントごとに実装しなくてよい 2. Organizationsの機能と連携して複数アカウントのセキュリティのビューが得られる。 guest アカウント側での勝手なアーカイブが防げる。 3. 基本的なセキュリティ上まずいセッティングをConfigRuleで潰してくれる Ex. Port 22 に対する 0.0.0.0/0 からのインバウンドを許可するセキュリティグループ • BLEAを使ってみて、改善したいなと思った点は以下です。 1. GuardDutyのFindingsをメールで通知する際の入力テンプレートが改行を含まないため非常 に読みづらい