【AWS re:Invent2023セッションレポート】セキュリティインシデント対応

セッション概要

タイトル

SUP302-R1 | Detect, investigate, and respond to security incidents

説明

In this workshop, dive deep into security anomaly scenarios like exposed AWS access keys, insecure security group ports, Amazon EC2 port scanning, and unauthorized resource launches. Perform discovery, diagnosis, troubleshooting, resolution, and root-cause analysis. Learn how to correlate data from sources like AWS CloudTrail, IAM Access Analyzer, AWS Config, and AWS Trusted Advisor. Discover how to respond to incidents using AWS Systems Manager, AWS Lambda, and Amazon CloudWatch Events. In all of these hands-on scenarios, get the opportunity to explore Trusted Advisor findings, different log types, automated audit rules, and alerts. You must bring your laptop to participate.

補足情報

Keynoteの裏だったためか並びは予約・非予約とも控えめでしたが、なんだかんだ開始時刻には8〜9割くらいは埋まってました。
前説が15分・Workshop105分くらいの配分で、Workshopは概ね90分前後で退出者が増えてくるくらいのボリューム感でした。
私は他の業務対応を少しやりつつ進めて100分くらいで完了。

内容

アジェンダ

• AWSユーザーが直面する主なクラウドセキュリティ上の課題
• Trusted Advisor、GuardDuty紹介
• AWSのセキュリティサービス俯瞰
• Workshop

AWSユーザーが直面する主なクラウドセキュリティ上の課題

• クラウドセキュリティとは具体的に何か、どう手をつけたらいいのか
• インシデントの検知方法、発生時の対応方法

GuardDutyやTrusted Advisorの紹介に繋げるためのお決まりの話題という感じ。

Trusted Advisor、GuardDuty紹介

この手のセッションにしては珍しく？　Security HubやInspectorやDetectiveに関してはあまり触れずにこの2つの紹介に絞ってました。（ワークショップではSecurity Hubも出てきましたが）
Trusted Advisorは無料でとりあえずこれだけ調べられますよ、という感じの紹介だったのでどちらかというとクラウドセキュリティにこれからゼロベースで着手する人向けの話題。

AWSのセキュリティサービス俯瞰

• 前提として、セキュリティのモニタリングは継続して行うこと
• Inspector、Macie、GuardDutyで検知→Security Hubで集約→Detective、Security Lakeと連携
  • Macie、Inspector、Detective,SecurityLakeをSecurity Hubと連携させる点に関して、社内では現状の優先度を低くしているが、どこかのタイミングで再確認しておく
• AWSのセキュリティサービス一覧
  • 「セキュリティ」の括りだと色んな角度のサービスが入ってくるため流石に多い
    

Workshop

モジュールは3つ。
Detailで触れる中でConfigやIAM Access Analyzerには触れなかったような気がします。
モジュール1、2は低難易度ですが3は多少実践的になりました。

• Module1: Trusted AdvisorとIAMによる不正挙動検知。
  • 心当たりのないIAMユーザーが作られている、というところからスタート
  • Trusted Advisorで状況確認
    • Security GroupでRDPやMySQL用のポートが0.0.0.0/0で開いていることを確認→対応
    • SGから関連して、EBSスナップショットが作られて知らないアカウントに共有されていることを確認
      • ここはTrusted Advisorでは出てこないので、現実の対応としてはIAMユーザーやその他盗られた認証情報ベースでCloudTrailを調べて検知するか、或いはIAMユーザーのAccess Advisorやポリシーから関連リソースを全て洗うような流れになると思われる
    • EBSスナップショットをアカウント指定で共有ではなくPublicにされることもありうる（こちらはTrusted Advisorで拾える）→実際にやってみてTrusted Advisorに検知されるか確認
• Module2: GuardDutyによる検知と対応
  • GuardDutyの使い方
  • IAMクレデンシャルを実際に抜いてみる
    • インスタンスプロファイルとして設定されているIAMロールのクレデンシャルを抜いて不正アクセスを試みる、という流れで、いわゆる「IAMユーザーはアクセスキーが危険だから作るな」という話から一歩進んで「IAMロールだからって100％安全ではない」という内容になっていました。
      • 数年前であれば、まず「極力ユーザーを使わない」みたいな話から入ることが多い印象でしたが、最近はもうその前提は共有されている認識か。
  • 抜いたクレデンシャルでS3にアクセスを試みてGuardDutyに検知されることを確認
• Module3: 攻撃者の挙動追跡と対応
  • 1,2は前座でここからが本番。
  • GuardDutyから不審な挙動（脅威IPからのアクセス、EC2用のロールのクレデンシャルがEC2外から利用された）検知
  • 別の検出結果で、問題のEC2インスタンスへのブルートフォース攻撃を検知
    • 「自分が攻撃対象となった」場合の重要度はLowなので注意
    • CloudWatch Logsに流している/var/log/secureからブルートフォース攻撃が成功したかどうかを確認
    • →成功していたのでOS設定でIDパスワード認証が有効になっていないか確認→無効化
  • 他の可能性として、IAMポリシーからS3を自由にできたことがわかるのでS3を調査
    • Security Hub Insightsで確認
      • マネージドインサイトの1つ「Top S3 buckets by counts of findings」でGuardDuty等で検出された結果が多いバケットを確認
    • 確認したバケットの個々の不審アクセスについてGuardDusyのS3 Protectionで検出結果を確認
      • いくつか大量アクセスや不審IPリストからのアクセスがあったファイルがあり、かつ機密情報ファイルが暗号化されていなかったので、暗号化とバケット公開設定を修正
• 余録
  • GuardDuty検知→EventBridge→Lambdaで、悪意のあるIPアドレスを検出したらNACLに拒否ルールを追加してインスタンを自動保護、というアーキテクチャの紹介

所感・まとめ

Module3が本番で、概要だけ見ると割とGuardDutyのハンズオンとしては王道に近い部分もありつつ、色んなケースに触れて引き出しを増やしておけばそれだけ実際のインシデント対応で視野が広がるので、やって損はないWorkshopでした。
GuardDutyもSecurity Hubもそれ自体のオペレーションはシンプルなので慣れていた部分もありますが、Security Hub Insights等、まだまだ使いこなせていないサービスもあると実感しました。
（使いこなせる＝それだけインシデント対応を経験してるということなので、ある意味使いこなせていないくらいが健全なのかもしれないですが）

マイナビにおいてはGuardDutyは比較的活用しているものの、Security Hubやそれと連携できる各種サービスについてはまだ検討中だったり「入れただけ」になっている部分も多く、復習しながら改めてサービスの有用性を検証して導入・運用を検討していければと思います。

また、GuardDutyのオプション機能もここ1・2年で急速に拡充されており、今回のWorkshopにS3 protectionが含まれていたように今後も触れる機会があれば積極的に触っていきたいです。

※本記事は2024年01月時点の内容です。