AWSセキュリティ運用の本当の難所は“検知”ではなく“説明”である（その２）
前回の記事では、Amazon InspectorとSecurity Hub CSPMを例に、AWSセキュリティ運用における検知結果の扱い方を整理した。
Amazon Inspectorは、脆弱性を検出する。
Security Hub CSPMは、設定不備やベストプラクティスからの逸脱をFAILEDとして示す。しかし、それらの検知結果は、そのままでは実務上の判断材料として不十分である。
第2弾となる本記事では、WAF、GuardDuty、通知設計を扱う。
WAFは、Webリクエストに対する評価結果を出す。
GuardDutyは、不審なAPI操作や認証情報侵害などの脅威の兆候を出す。
通知設計は、それらの検知結果を人に届けるための仕組みである。
ただし、ここでも同じ問題が起きる。
WAFのCOUNTは、攻撃の証拠ではない。
GuardDutyで検知がないことは、安全であることの証明ではない。
セキュリティ通知は、詳細を出しすぎると、通知そのものが情報漏えいリスクになる。
本記事では、WAF、GuardDuty、通知設計を、実務上どのように判断材料へ変換するかを整理する。
5. WAF：COUNTは攻撃の証拠ではなく、調査の入口である
AWS WAFでは、Webリクエストを評価し、ルールに応じてALLOW、BLOCK、COUNTなどのアクションを実行できる。
たとえば、Rate-based ruleを使えば、一定時間内にしきい値を超えるリクエストを送信した送信元に対して、BLOCKやCOUNTなどのアクションを適用できる。AWS WAFのログには、Web ACLが評価したトラフィックの詳細、リクエスト情報、マッチしたルール情報などが記録される。AWS公式ドキュメントでも、WAFログには、AWS WAFがWebリクエストを受信した時刻、リクエストの詳細、マッチしたルールの詳細が含まれると説明されている。
参考：AWS WAF logging
https://docs.aws.amazon.com/waf/latest/developerguide/logging.html
WAFログは非常に有用である。しかし、ここで注意すべきことがある。WAFのCOUNTは、攻撃の証拠ではない。COUNTは、あくまで「ルールに一致したが、遮断せずに記録した」という状態である。
特にRate-based ruleのCOUNTは、高頻度アクセスを調査する入口としては有効だが、それだけで悪性と断定することはできない。
たとえば、1分間に100件のアクセスがあったとする。
それだけを見ると、不審に見えるかもしれない。しかし、実際には次のような可能性がある。
ブラウザがCSS、JavaScript、画像などを並列取得した
正常な利用者がページ遷移を繰り返した
検索エンジンのクローラがアクセスした
監視ツールが定期的にアクセスした
社内の確認作業で短時間にアクセスが集中した
スクレイピングツールが大量取得している
脆弱性スキャナが存在しないパスを探索している
認証画面や検索APIに機械的なアクセスが集中している
つまり、COUNTに一致したという事実だけでは、正常とも悪性とも言えない。WAFのCOUNTは、判断の結論ではなく、調査の入口である。
6. WAF COUNTログを見るときの観点
COUNTログを見るときに重要なのは、件数だけで判断しないことである。
「100件を超えたから攻撃」
「500件を超えたから即BLOCK」
「COUNTが多いからルールを緩める」
このような判断は危険である。
