GuardDutyを有効化した後の話
はじめに
AWSアカウントを新規に作成した後にやるべきこととして、
「Amazon GuardDutyの有効化」をしましょう
という話はよく聞くと思います。
30日は無料だし推奨らしいから有効化してみたという方や一度は有効化してみたけど有料になったからまた無効に戻したという方、
いらっしゃるのではないでしょうか?
私もとりあえず有効にしてみたけどそのままという経験があり、今回はGuardDutyを有効化した後どう使えば良いかについて整理したことを書きたいと思います。
GuardDutyの概要
まずGuardDutyについてですが、簡単に言うと、
脅威インテリジェンスや機械学習などを活用して継続的に脅威を検出するAWSマネージドサービス
となるでしょうか。
GuardDutyのイメージ
参照
https://pages.awscloud.com/rs/112-TZM-766/images/20220428_17th_ISV_DiveDeepSeminar_Guard_Duty.pdf
脅威の検出
GuardDutyは「脅威インテリジェンス」や「機械学習」を使用して脅威を検出します。
GuardDutyの脅威インテリジェンスは、既知の攻撃者が使用することがわかっているIPアドレスとドメインで構成されており、AWSのセキュリティチームやサードパーティプロバイダなどから継続的に提供され更新されます。
ユーザー自身も独自のカスタム脅威リストを追加することができます。
GuardDutyの機械学習による異常検出は、通常とは異なるユーザーの振る舞いや通常とは異なるトラフィックパターンなどの異常を検出します。
- 脅威インテリジェンス
- 既知の脅威に対する検出
- AWSセキュリティチームやサードパーティプロバイダから提供される
- ユーザー自身が脅威IPリストを追加できる
- 機械学習(異常検出)
- 未知の脅威に対する検出
- 通常とは異なる異常を検知
データソース
GuardDutyは以下のデータソースを使用して脅威を検出します。
- DNSクエリログ
- VPCフローログ
- CloudTrailのイベントログ
- CloudTrailの管理イベント
- CloudTrail S3データイベント
- EKS監査ログ
これらのログのデータはAWS内部で直接取得されるので、DNSクエリログやVPCフローログなどを事前に有効化する必要はありません。
検出結果
脅威が検出されると、検出結果(Findings)が生成され、
- High(高)
- Medium(中)
- Low(低)
の3つの重要度に分類されます
保護プラン
GuardDutyには保護プランというオプションがあります。
- S3 Protection
- S3データイベントのモニタリング
- EKS Protection
- EKS Audit Log Monitoring Configuration
- 監査ログ
- EKS Runtime Monitoring Configuration
- ランタイムアクティビティのモニタリング
- GuardDuty agent management (EKS)
- EKS Audit Log Monitoring Configuration
- Malware Protection
- EC2インスタンスまたはコンテナワークロード内のマルウェアの検出
- RDS Protection
- RDSログインアクティビティのモニタリング
- Lambda 保護
- Lambdaネットワークアクティビティモニタリング
2023/11現在では、GuardDuty agent management(EKS)のみデフォルトで無効で、他は全てデフォルトで有効です。
EKSを使用していない場合は、EKS Protectionはオフにしたほうが良さそうに思えますが、使用していなければ料金は発生しないので、デフォルトのままでも問題ないでしょう。
しかし、慣れるまでは頻繁に使用状況のページで推定コストの確認はしておいたほうが良さそうです。
GuardDuty有効化後にやること
それでは実際にGuardDutyを有効化した後にやることを見ていこうと思います。
アラート通知
GuardDutyは脅威の検出は行いますが、デフォルトでアラートの通知は行いません。
毎回、AWSコンソールにログインして検出結果を確認するのは非効率ですし、脅威が検出されてもすぐに気づけないということにもなりかねないので、アラート通知の設定は必須になります。
具体的には、Amazon EventBridge経由で、Amazon SNSやAWS Chatbotなどに通知を行うのが一般的かと思います。
重要度でフィルタ
全ての脅威検知のアラートを通知するのではなく、重要度が「中」以上、または「高」以上だけ通知するようにしたいケースはあると思います。
- 高: 7.0〜8.9 の範囲
- 中: 4.0〜6.9 の範囲
- 低: 0.1〜3.9 の範囲
例)重要度「中」以上のみ通知
{
"source": [
"aws.guardduty"
],
"detail-type": [
"GuardDuty Finding"
],
"detail": {
"severity": [
{ "numeric": [ ">=", 4 ] }
]
}
}
入力トランスフォーマー
GuardDutyから送られてくるメールは、デフォルトでは非常に見にくいので、入力トランスフォーマーの設定を行い、メール文面を整形します。
Input Path
{
"accountId": "$.detail.accountId",
"count": "$.detail.service.count",
"description": "$.detail.description",
"eventFirstSeen": "$.detail.service.eventFirstSeen",
"eventLastSeen": "$.detail.service.eventLastSeen",
"findingId": "$.detail.id",
"region": "$.region",
"severity": "$.detail.severity",
"type": "$.detail.type"
}
Input Template
"Amazon GuardDuty finding type : <type>"
"Account ID : <accountId>"
"Severity : <severity>"
"Count : <count>"
"First seen : <eventFirstSeen>"
"Last seen : <eventLastSeen>"
"Description : <description>"
"For more details open the GuardDuty console at https://console.aws.amazon.com/guardduty/home?region=<region>#/findings?search=id%3D<findingId>"
検出結果のエクスポートオプションの変更
検出結果がEventBridgeに出力される頻度は、デフォルトで6時間になりますが、15分に変更します。
今回は使用しませんが、今後、Amazon Detectiveと統合する場合15分が推奨されています。
検出結果の調査
GuardDutyによって脅威が検出されると検出結果が生成されますが、検出結果の中で検出結果タイプ(Finding types)が特に重要となります。検出結果タイプは以下のようなフォーマットで構成されます。
ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact
脅威の目的:影響を受けるリソース/脅威の説明.検出の方法!使用されたツール
例えば、UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
という検出結果タイプは、EC2インスタンスが脅威IPリストに含まれるIPアドレスに通信していることを知らせるものですが、次のような構成になっています。
項目 | 値 |
---|---|
脅威の目的 | UnauthorizedAccess |
影響を受けるリソース | EC2 |
脅威の説明 | MaliciousIPCaller |
検出の方法 | Custom |
その他の検出結果タイプの詳細は
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-active.html
を確認いただければと思います。
2023/11現在で、164個とかなりの数の検出結果タイプがありますが、まずは実際に検出されたもので重要度の高い検出結果タイプを中心に調査していくことをお勧めいたします。
検出結果のサンプル
GuardDutyの有効化直後は検出結果は何も表示されていません。「検出結果のサンプル」からサンプルを生成することもできますが、検出結果タイプごとに1つの検出結果が生成されるので、メール通知設定をしていると大量にメールが飛んでくるので注意してください。
ピンポイントで検出結果タイプを指定してサンプルを生成することもできます。
$ aws guardduty create-sample-findings \
--detector-id $(aws guardduty list-detectors --query 'DetectorIds' --output text) \
--finding-types UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
今回はこちらでサンプルを作成してみました。
アラート通知メールの文面が入力トランスフォーマーの形式になっていることを確認できました。
メール本文内の「GuardDuty Consoleのリンク」をクリックしコンソールを表示すると、より詳細な情報を確認することができます。
検出結果のアーカイブと抑制
検出結果が増えてくるとコンソールも見づらくなってくるので、問題ない検出結果はアーカイブをし、問題のある検出結果だけ表示されるようにするのが良いでしょう。
- 検出結果が誤検出
- アーカイブする
- 検出結果が許容できる(対応が不必要)
- アーカイブする
- 検出結果が許容できない(対応が必要)
- 対応する
検出結果が誤検出であったり対応不必要などで、手動でアーカイブを行っても、また新たに同じ脅威が更新頻度時間後に発生すると、新しい検出結果として作成され、コンソールに表示され、アラートメール通知も行われます。
繰り返し発生する問題ない検出結果は抑制したいので、抑制したい条件でフィルタリングして、抑制ルールに名前をつけて保存します。
抑制ルールを作成すると、その抑制ルールが適用されている限り、ルールで定義された条件に一致する新しい検出結果が自動的にアーカイブされます
参考
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/findings_suppression-rule.html
検出結果の対応
検出結果が許容できない場合は対応が必要となりますが、検出結果の内容により対応は異なります。
今回のサンプルの検出結果で影響を受けるリソースはEC2になるので、「侵害された Amazon EC2 インスタンスの修復」のアクションが参考になります。
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_remediate.html#compromised-ec2
- オンデマンドのマルウェアスキャンを使用して、侵害された可能性のあるEC2インスタンス内のマルウェアを特定する
- 開いているポートを閉じる
- 脆弱性を修正するためにアプリケーションをアップグレードする
- EC2インスタンス上の不正なアクティビティを特定し停止する
- EC2インスタンスを削除し、必要に応じて新しいインスタンスを作成する
などの対応が示されており、これらをヒントに対応方法を検討する形となります。
今回はサンプルの検出結果1件ですが、実際は複数の検出結果をまたがって調査をしたり、相関分析したりする必要がでてくると思います。その場合は、Amazon Detectiveを活用するという選択肢もあると思います。
GuardDutyのオンデマンドのマルウェアスキャン
まとめ
「GuardDutyの有効化」の後にやることとして、
- アラート通知の設定
- 検出結果の調査
- 検出結果の対応
の3つを見てきました。
これらは、AWS Well-Architectedフレームワークのセキュリティ柱の
SEC 4: セキュリティイベントをどのように検出し、調査していますか?
におけるベストプラクティスに沿うものになっています。
- SEC04-BP01 サービスとアプリケーションのログ記録を設定する
- GuardDutyを有効化
- SEC04-BP02 ログ、結果、メトリクスを一元的に分析する
- 検出結果を分析
- SEC04-BP03 イベントへの応答を自動化する
- 対応の自動化
- SEC04-BP04 実用的なセキュリティイベントを実装する
- アラート通知の設定
参考
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/detection.html
こちらも合わせて参照していただけると、AWSのセキュリティにおいて、「検知」や「発見的統制」がどのように行われており、その中でGuardDutyがどのように活用できるのか、より理解が深まると思います。
今回は、対応の自動化、AWS Security HubやAmazon Detectiveとの統合については触れることができませんでした。また機会があればブログに書きたいと思います。