「AWSアカウントのセキュリティインシデント調査どうする? Amazon Detectiveを利用した調査の勘所」というタイトルでAKIBA.AWS ONLINE #04に登壇しました #AKIBAAWS

こんにちは、臼田です。

みなさん、インシデント対応してますか？(挨拶

今回は以下のイベントで登壇した資料とその解説を載せます。

【6/25（金）リモート開催】AKIBA.AWS ONLINE #04 – こんなときどうする⁉︎ トラブル・インシデント対応 編- #AKIBAAWS

動画

資料

解説

前置き

毎回AWSセキュリティの話をするときに、いろんな前提のセキュリティの話とかから始めるんですが、今回はWell-Architectedフレームワークの質問をピックアップしてみました。質問項目を並べると以下のとおりです。

• SEC 1: ワークロードを安全に運用するには、どうすればよいですか?
• SEC 2: ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
• SEC 3: 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
• SEC 4: セキュリティイベントをどのように検出し、調査していますか？
• SEC 5: ネットワークリソースをどのように保護しますか?
• SEC 6: コンピューティングリソースをどのように保護していますか?
• SEC 7: どのようにデータを分類していますか?
• SEC 8: 保管時のデータをどのように保護していますか?
• SEC 9: 転送時のデータをどのように保護していますか?
• SEC 10: インシデントの予測、対応、復旧はどのように行いますか?

ぜひ胸に手を当てて考えたり、チームやプロジェクトや部署や会社でのディスカッションの題材に使ってください。

ちなみにWell-Architected全体について以下を確認していただくといいです。最高なブログ。

本題のセキュリティインシデントやインシデントレスポンスに対応した部分はSEC4とSEC10です。どちらも結局「AWSの」とか「IAMの」みたいな単位ではなくもっと広いフォーカスで考える必要があります。

で、今回はそのうちの一部であるAmazon GuardDutyで検知できるセキュリティインシデントとその対応について紹介していきます。

Detectiveどうやるの？

Amazon Detectiveの前にGuardDutyの話から。

GuardDutyではAWS上やその上に構築された環境のセキュリティインシデントを検知して通知してくれます。検知する内容は以下のような感じ。

• EC2でコインマイニング
• IAMアクセスキーの不正利用
• ブルートフォース
• 怪しいIPからの通信
• S3バケットが公開される
• などなど

対応フローは以下のような感じ。

1. GuardDutyによるインシデント検知
2. CloudTrail / VPC Flow Logs / Athenaなどによるログ調査
3. インシデントの優先度判断
4. 影響範囲の確認
5. インシデント対応

検知したあとの対応がぼちぼち大変で、このあたりに準備や知見が必要になってきます。特にログや環境の調査部分についてDetectiveが力を発揮します。

図でわかりやすく説明されているものがあるので紹介します。以下がbefore

で、これがafter

調査のフェーズで必要なログの収集や分析がDetectiveに置き換わります。うれしい。

そしてなによりも各エンティティ間の関連付けを自動的にやってくれます。エクセルで頑張っているとあっちのログで出てきたこれとこっちのログのこれが同じで、とか見ていくのがすごい大変なんですね。

内部的にグラフDBを利用していてこの関係性を扱うのが得意なのです。

詳しくは以下のブログでも紹介していて、実際の画面を動画で説明しているので参考にしてください。

Detectiveとか調査の勘所

まずはDetectiveの全般的な話から。殆どは上記ブログにありますが、以下が新しくなっているところです。「Detectiveで調査する」ボタンから直接EC2インスタンスやIAMなどのエンティティに飛ぶことが出来ます。以前はGuardDuty Findings一択でした。

続いてコインマイニングされていた場合を参考に具体的な調査の手法を解説します。

まず検知はGuardDutyです。CryptoCurrency:EC2/BitcoinTool.BなどのFindings Typeで通知されます。GuardDutyはこれをVPCフローログやDNSログから検知します。

このコインマイニングに関するFindingsは100%マイニングされていると思っていいです。問題はなぜマイニングされているのかというところです。

正規の利用者が故意に(あるいは正常な業務で)やっている場合を除けば、IAMが乗っ取られているかEC2が乗っ取られているかのどちらかです。EC2だけならまだ救いがありますが、経験的に言うとほとんどIAMが乗っ取られています。

Detectiveの画面ではまず対象のEC2インスタンスの作成日時と作成者を確認します。

だいたい知らない人が最近作ってます。作成者のIAMがリンクになっているのでそれをたどっていくと、同じようにIAMの作成日時と作成者があるので知っている人に当たるまでたどっていくとそのあたりが元の原因です。これがたどりやすいのがDetectiveのいいところ。

というわけでそのあたりの情報がどこから漏れたか確認する作業を誰かがやります。(根本原因確認)

IAMユーザーのアクセスキーがGitHubにうっかりpushされてしまっていたり、EC2にアタッチされたIAMロールの一時クレデンシャルがSSRFなどの攻撃によって取得されている場合があります。でもほとんど前者。

封じ込めとして該当のアクセスキーを削除するか、権限をすべて取る(Denyにする)かしたり、IAMロールならアクティブなセッションの無効化(IAMの画面にボタンがある)したりします。

DetectiveのIAM画面では実行したAPIの集計がみれます。RunInstancesとかCreateKeyPairとか強いAPIがサクッと見つけられます。

あとは実際のログを見ながらそれぞれ対処していきます。API実行履歴の詳細はDetectiveでは確認できません。ざっくり全体の確認をDetectiveでした後はいつもどおりCloudTrailを眺めます。でも見るべきものは明確になっているのでだいぶ楽。影響範囲の確認がこのあたりです。

良くないEC2が動いていたら消したくなりますが、既存で正常に利用していたEC2などで内部調査が必要そうであれば保全する必要があります。再起動無しでAMIバックアップを取得し、すべての通信を拒否するSecurity Groupを当てて隔離します。

後大事なのはすべてのリージョンで確認します。GuardDutyやDetectiveはリージョナルサービスなので、すべてのリージョンの情報をまとめて確認することは現状できません。

S3データアクセス周り

今度は別のGuardDutyの検知の話。

PenTest:S3/KaliLinuxなどS3周りのGuardDuty Findingsを検知したらどうするかです。

これはS3データアクセスがデータソースの検知です。S3に対して怪しいアクセスがあるので、公開されているバケットなのか、公開しているデータなのか、参照・取得されて問題ないかなどを判断します。

残念ながらこれをDetectiveで調査することはできません。

Detectiveで対応しているFindings Typeが以下にまとめられています。すべてのFindings Typeに対応していないのです。

サポートされている検索結果タイプ - Amazon Detective

そしてS3データイベントはCloudTrailを有効化するだけでは取得できません。デフォルトでは管理イベントのみしか取得できないのです。

重要なデータを扱う場合には、S3データイベントを収集する設定を追加しておきましょう。でないと誰が重要なデータにアクセスしたかトラッキングできません。

また、ログなどをS3に保管する場合は、削除・改ざんされないように別AWSアカウントに集約したり、S3オブジェクトロックやSCPによる削除防止をしましょう。

まとめ

Amazon Detectiveの勘所について紹介しました。

セキュリティインシデントの対応のためには、事前の準備ももちろん大事です。

各種ログの取得やGuardDuty/Detectiveの有効化などはしっかりやりつつ、Well-Architectedフレームワークも参考にやっていきましょう。