ほんとうに大事なサービスを守れるのか！？ 実運用に向けてAWS WAFを検討してみた

2018/08/03 Security JAWS 【第10回】勉強会での、安東・徳田の講演資料になります

Transcript

1. ほんとうに大事なサービスを守れるのか！？
   実運用に向けてAWS WAFを検討してみた
   株式会社リクルートテクノロジーズ
   安東 美穂
   徳田 聡介
   

   View Slide

2. 自己紹介
   氏名
   所属
   お仕事
   徳田 聡介 (とくだ そうすけ)
   株式会社リクルートテクノロジーズ
   インフラソリューション部
   ・セキュアインフラ基盤の運用
   ・社内向アプリのエンハンス対応
   備考
   ・セキュリティに興味をもちREDチームに半年間所属
   ・この期間に AWS WAF 検証担当として参画
   

   View Slide

3. 自己紹介
   安東 美穂 (あんどう みほ)
   株式会社リクルートテクノロジーズ
   セキュリティオペレーションセンター（SOC）
   氏名
   所属
   日経コンピュータ連載記事に寄稿
   （書籍：「現場で使えるセキュリティ事故対応」）
   好きなコマンド：nmap
   ・リクルートのサービスのセキュリティ監視、解析（IDS/WAF）
   ・WAF監視導入支援 など
   お仕事
   課外活動：ミニ四駆
   

   View Slide

4. Recruit-CSIRTについて
   IRG
   Incident Response Group
   SEG
   SOC
   Security Operation Center
   サイバー攻撃への対応をリード
   ・事故発生時の対応支援
   ・外部関連機関との連携
   ・Recruit-CSIRTの運営、各社展開
   サイバー攻撃を早期検知し、被害拡大を防止
   ・グループ共通インフラのセキュリティ監視
   ・未知マルウェアの監視、解析、一次対応
   ・被害発生時のフォレンジック (NWおよびPC)
   ・内部不正のモニタリング
   平時からセキュリティを向上、被害を未然に
   防止
   ・脆弱性診断、開発者教育などのセキュア開発支
   援
   ・セキュリティパッチの情報収集および各社展開
   ・早期警戒(脅威情報の収集および対策検討)
   Security Engineering Group
   

   View Slide

5. 1. なぜ AWS WAF を検証するのか？
   

   View Slide

6. 今までのセキュリティ対応
   • 主要な商用インフラはすべてオンプレミス
   • オンプレミス向けにWAF、IDS、NWフォレンジックを入れて監視
   • セキュリティは一定レベルを担保できている
   

   View Slide

7. 時代の流れ
   

   View Slide

8. 時代の流れ
   社内の主流
   

   View Slide

9. AWS でのセキュリティ対応をどうするか
   • AWS環境に適したセキュリティ対策が求められる
   • 監視はオンプレと同じ商用製品（MP提供）を使う？
   • コストと柔軟性の面で懸念あり
   • ではAWS WAF？
   • 社内にはAWS WAFの導入事例は無く、知見も少ない
   • 本当に実運用に耐えうるのか？
   

   View Slide

10. AWS でのセキュリティ対応をどうするか
    じゃあ 検証するしかないよね
    • AWS環境に適したセキュリティ対策が求められる
    • 監視はオンプレと同じ商用製品（MP提供）を使う？
    • コストと柔軟性の面で懸念あり
    • ではAWS WAF？
    • 社内にはAWS WAFの導入事例は無く、知見も少ない
    • 本当に実運用に耐えうるのか？
    

    View Slide

11. このセッションで伝えること
    1. なぜ AWS WAF を検証するのか？
    2. 検証してみた
    3. セキュリティ運用を考えてみた
    

    View Slide

12. View Slide

13. 2. 検証してみた
    

    View Slide

14. 検証のゴール
    • どの程度攻撃を検知するか
    • どの程度過検知をするか
    • AWS WAF の仕様/構築手順の確認
    →AWS WAFを実運用する場合の課題を把握する
    

    View Slide

15. 検証環境の構成
    AWS WAF
    EC2
    CloudFront ELB
    通常： “200” OK
    遮断時： “403” Forbidden
    投げたリクエストに対するレスポンスのステータスコードから
    AWS WAF が遮断したかを判定
    

    View Slide

16. 検証作業の自動化
    WebACL①
    WebACL②
    WebACL③
    WebACL④
    WebACL⑤
    https://github.com/stqp/aws_waf_verification
    ルール (WebACL) 切替え
    結果出力
    ※検証用にスクリプトを作成
    検証実行
    

    View Slide

17. 検証用データ
    • 2種類 (攻撃/正常) のWebリクエストデータセット
    • 正常系データを用意した理由は誤検知リスク検証のため
    

    View Slide

18. 攻撃用データ①
    Sqlmap
    1. 脆弱なサーバを用意して Sqlmap (=攻撃) を実行
    2. プロキシとして Burp Suite を経由させて攻撃ログを取得
    3. burpProHistory2Flat.py を使ってログから攻撃リクエストを復元
    • ※ 元のスクリプトを少し使いやすく修正
    burpProHistory2Flat.py
    Burp Suite Pro
    1. 脆弱なサーバを用意して Burp Suite Pro の Scan (=攻撃) を実行
    2. デフォルトでは攻撃ログが残らないので拡張モジュールを導入
    • Logger++
    3. Logger++のログからツールで攻撃リクエストを復元
    • ※ 簡易なものを自作
    loggerPlusPlus2Flat.py
    

    View Slide

19. 攻撃用データ②
    CSIC2010
    • http://www.isi.csic.es/dataset/
    • スペインの研究機関が提供するWAF検証のためのwebリクエストセット
    • 攻撃系 (約25,000件) だけでなく 正常系 (約36,000件) も含む
    • SQL Injection
    • XSS
    • File disclosure
    • CRLF Injection etc
    

    View Slide

20. 正常系データ
    CSIC2010
    • スペインの研究機関が提供するwebリクエストセット
    実アプリ
    • 社内のREDチームが脆弱性検査で使ったリクエストデータを再利用
    （※アプリは弊社所有）
    

    View Slide

21. そもそも AWS WAF とは
    出典：「WAFとは？」
    https://aws.amazon.com/jp/waf/what-is-waf/
    

    View Slide

22. AWS WAFのルール構成
    Web ACL
    Managed Rule（by ベンダー）
    Condition
    XSS
    Get match
    SQL Injection IP match
    Size constraints Regex match
    Custom Rule
    （by AWS）
    … … …
    

    View Slide

23. Managed ルール
    • AWS Marketplaceでベンダーより提供されているルールセット
    • 細かい設定が不要ですぐに使える
    詳しくは 「AWS Marketplace ルールグループ」を参照
    https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-managed-rule-
    groups.html
    • Managed ルールセットは自動更新のため運用負荷が小さい
    • ただし脆弱性が公開されてからどのくらいの時間で更新されるか不
    明なので、ベンダーに確認が必要。（ベストエフォート？？)
    料金については 「AWS WAF 料金表」 を参照
    https://aws.amazon.com/jp/waf/pricing/
    

    View Slide

24. Managed ルール
    ルール名 ※⼀部省略 ベンダー 検証対象？
    Web Application CVE Signatures F5 Yes
    Bot Detection Signatures F5 Yes
    Web Exploits Rules F5 Yes
    General and Known Exploits Fortinet Fortinet Yes
    Malicious Bots Fortinet Fortinet Yes
    SQLi/XSS Fortinet Fortinet Yes
    Complete OWASP Top 10 Fortinet Fortinet Yes
    ModSecurity Virtual Patching TrustWave Yes
    OWASP Top 10 for WordPress Alert Logic No
    Impervaʼs Managed Rules for WordPress Protection Imperva No
    Managed Rules for IP Reputation Imperva No
    Content Management System (CMS) Trend Micro No
    WebServer (Apache, Nginx) Trend Micro No
    CMS Virtual Patches TrustWave No
    • Managed ルールは全部で14種類（※2018年 7月現在）
    • 今回の検証では汎用的に使えそうな８種類に絞り込んだ
    

    View Slide

25. カスタム ルール
    • Condition は全部で6種類（※2018年 7月現在）
    • XSS
    • SQL Injection
    • IP
    • Geolocation (国)
    • 正規表現
    • サイズ (Bytes)
    • 今回の検証では汎用に使えそうな以下2種類に絞り込んだ
    • XSS
    • SQL Injection
    

    View Slide

26. カスタム ルール
    • Rule は複数の Condition を AND 条件で組合せて作成する
    • １つのRuleに複数のconditionを入れると全てにマッチしないと検知しない
    ので注意
    • 今回の検証では“One Rule One Condition” とした
    Rule① (XSS & SQLi)
    Rule① (XSS)
    Rule② (SQLi)
    わるい例 よい例
    

    View Slide

27. カスタム ルール
    • WebACL は Ruleを OR 条件で組合せて作成する (最大10個)
    • ※ ただしManaged ルールは１つしか組み込む事はできない
    • 今回は検証では“One WebACL One Rule” とした
    ※ 1つのWebACLに2つ以上のManagedルールを追加して保存しようとすると失敗する
    

    View Slide

28. AWS WAF 設定手順 (カスタムルール)
    • https://console.aws.amazon.com/waf/home
    

    View Slide

29. AWS WAF 設定手順 (カスタムルール)
    • https://console.aws.amazon.com/waf/home#/wafhome
    

    View Slide

30. Condition 設定手順①
    • https://console.aws.amazon.com/waf/home#/xssmatchsets
    

    View Slide

31. Condition 設定手順②
    • https://console.aws.amazon.com/waf/home#/xssmatchsets/new
    Part of the request to filter on:
    ・検知対象とするHTTPリクエストの部位を指定
    Transformation:
    ・HTTPリクエストの変換方法
    参考：
    https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/web-acl-xss-conditions.html
    

    View Slide

32. Rule 設定手順①
    • https://console.aws.amazon.com/waf/home#/rules
    

    View Slide

33. Rule 設定手順②
    • https://console.aws.amazon.com/waf/home#/rules/new
    When a request:
    ・コンディション種別 (SQLi, XSSなど) を選択
    ・コンディションを選択
    

    View Slide

34. Web ACL 設定手順①
    • https://console.aws.amazon.com/waf/home#/webacls
    

    View Slide

35. Web ACL 設定手順②
    • https://console.aws.amazon.com/waf/home#/wizard/webacl
    

    View Slide

36. Web ACL 設定手順③
    • https://console.aws.amazon.com/waf/home#/wizard/webacl
    このステップで Condition を作成できるが
    すでに作成済みなのでスキップ
    

    View Slide

37. Web ACL 設定手順④
    • https://console.aws.amazon.com/waf/home#/wizard/webacl
    ここでさっき作成した Rule を選択・追加
    

    View Slide

38. Web ACL / CloudFront 連携手順①
    

    View Slide

39. Web ACL CloudFront 連携手順②
    連携する CloudFront を選択
    

    View Slide

40. Condition 設定時の落とし穴
    

    View Slide

41. Condition 設定時の落とし穴
    リクエストのデコード方法を正しく指定しないと
    WAFは正しく検査しない （あたりまえw？）
    

    View Slide

42. 落とし穴から脱出するまで
    1. 最初はデコード方法をあまり気にせず「None」に設定していた。
    • AWS WAF側でうまくやってくれるだろうという暗黙の期待もあった。
    2. 検証結果をみるとカスタムルールの検知状況が非常に悪かった。
    • 無料だし、ベンダーの存在もあるし、AWSはほとんど注力していないのかなと思った。
    3. チームに結果共有したところ、指摘を受けて発覚。
    4. デコード設定を修正して再検証すると格段に検知するように。
    Σ (゜ロ゜;)
    

    View Slide

43. 落とし穴に落ちないように
    Transformation を適切に選択する
    ・None
    ・Convert to lowercase
    ・HTML decode
    ・Normalize whitespace
    ・Simplify command line
    ・URL decode
    (※ 画像再掲)
    

    View Slide

44. 検証アウトプット
    • CSVファイルに Response Status (200 or 403) を一覧出力
    • 攻撃リクエストに対して 403 応答していると Good!
    • 正常リクエストに対して 403 応答していると Bad! (=誤検知)
    リ
    ク
    エ
    ス
    ト
    番
    号
    リクエスト詳細 と ルール名
    

    View Slide

45. 検証結果
    • CSVファイルに Response Status (200 or 403) を一覧出力
    • 攻撃リクエストに対して 403 応答していると Good!
    • 正常リクエストに対して 403 応答していると Bad! (=誤検知)
    リ
    ク
    エ
    ス
    ト
    番
    号
    リクエスト詳細 と ルール名
     攻撃はそれなりにブロック
     誤検知も少ない
    ＝なかなかの成績
    

    View Slide

46. AWS WAF 結構良いかも！
    

    View Slide

47. 検証結果の所感
    • 一部ベンダーのManaged ルールが比較的よさそう。
    • ただし カスタムルール も想像よりずっと堅い守りだった。
    • AWS WAFの実運用には、いくつか課題がありそう。
    

    View Slide

48. 3. セキュリティ運用を考えてみた
    

    View Slide

49. 実運用する上での課題になりそうな事
    ①誤遮断
    ②チューニング
    ③ログ
    

    View Slide

50. 運用課題①
    誤遮断
    

    View Slide

51. とある遮断された正常系リクエスト
    POST http://localhost:8080/ HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
    Accept: */*
    Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
    Accept-Encoding: x-gzip, x-deflate, gzip, deflateAccept-Language: en
    Content-Length: 1269
    Connection: close
    {'requests':{'g0':{'resource':'mail','operation':'create','params':{'id':100},'body':{'subject':'[Substr ああああああああああ
    ああ] ああああああああああああああああああああああああ ああああああああああああああﾎｹ(ああああああああああああああﾎｹ
    8)','body':'ああああああああああああああああああああああああああああああ¥n¥nあああああああああああああああああああああ
    あああああああああああああああ¥nああああああああああああああﾎｹ8ああああああああﾎｹ ああああああああああああああﾎｹ¥nあ
    あああああああああああああああああああああああああああああああああああああああああああああああああああああああﾎｹ¥n¥n
    ああああああああああああああﾎｹ8¥n¥n¥nあああああああああああああああああああああああああああああああああああああああ
    あああああああああああああああああああああああああああああああああああああああ¥n¥nあああああああああああああああああ
    あああああああああああああああああああああああああああﾎｹ'}}},'context':{}}
    ※実際のログのため一部文字を変更しています
    

    View Slide

52. 遮断された正常系リクエストの１つ
    POST http://localhost:8080/ HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
    Accept: */*
    Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
    Accept-Encoding: x-gzip, x-deflate, gzip, deflateAccept-Language: en
    Content-Length: 1269
    Connection: close
    {'requests':{'g0':{'resource':'mail','operation':'create','params':{'id':100},'body':{'subject':'[Substr ああああああああああ
    ああ] ああああああああああああああああああああああああ ああああああああああああああﾎｹ(ああああああああああああああﾎｹ
    8)','body':'ああああああああああああああああああああああああああああああ¥n¥nあああああああああああああああああああああ
    あああああああああああああああ¥nああああああああああああああﾎｹ8ああああああああﾎｹ ああああああああああああああﾎｹ¥nあ
    あああああああああああああああああああああああああああああああああああああああああああああああああああああああﾎｹ¥n¥n
    ああああああああああああああﾎｹ8¥n¥n¥nあああああああああああああああああああああああああああああああああああああああ
    あああああああああああああああああああああああああああああああああああああああ¥n¥nあああああああああああああああああ
    あああああああああああああああああああああああああああﾎｹ'}}},'context':{}}
    “あああ” という文字が原因... ？？
    ※実際のログのため一部文字を変更しています
    

    View Slide

53. 遮断された正常系リクエストの１つ
    POST http://localhost:8080/ HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
    Accept: */*
    Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
    Accept-Encoding: x-gzip, x-deflate, gzip, deflateAccept-Language: en
    Content-Length: 1269
    Connection: close
    {'requests':{'g0':{'resource':'mail','operation':'create','params':{'id':100},'body':{'subject':'[Substr ああああああああああ
    ああ] ああああああああああああああああああああああああ ああああああああああああああﾎｹ(ああああああああああああああﾎｹ
    8)','body':'ああああああああああああああああああああああああああああああ¥n¥nあああああああああああああああああああああ
    あああああああああああああああ¥nああああああああああああああﾎｹ8ああああああああﾎｹ ああああああああああああああﾎｹ¥nあ
    あああああああああああああああああああああああああああああああああああああああああああああああああああああああﾎｹ¥n¥n
    ああああああああああああああﾎｹ8¥n¥n¥nあああああああああああああああああああああああああああああああああああああああ
    あああああああああああああああああああああああああああああああああああああああ¥n¥nあああああああああああああああああ
    あああああああああああああああああああああああああああﾎｹ'}}},'context':{}}
    ではなかった
    ※実際のログのため一部文字を変更しています
    

    View Slide

54. “あああ” 除外しても遮断される
    POST http://localhost:8080/ HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
    Accept: */*
    Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
    Accept-Encoding: x-gzip, x-deflate, gzip, deflateAccept-Language: en
    Content-Length: 1269
    Connection: close
    {'requests':{'g0':{'resource':'mail','operation':'create','params':{'id':100},'body':{'subject':'[Substr] (8)','body':'8
    red8'}}},'context':{}}
    ※実際のログのため一部文字を変更しています
    

    View Slide

55. POST http://localhost:8080/ HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
    Accept: */*
    Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
    Accept-Encoding: x-gzip, x-deflate, gzip, deflateAccept-Language: en
    Content-Length: 1269
    Connection: close
    [Substr] (8)
    もっと絞っても遮断される
    ※実際のログのため一部文字を変更しています
    

    View Slide

56. POST http://localhost:8080/ HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
    Accept: */*
    Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
    Accept-Encoding: x-gzip, x-deflate, gzip, deflateAccept-Language: en
    Content-Length: 1269
    Connection: close
    Substr()
    さらに絞っても遮断される
    ※実際のログのため一部文字を変更しています
    

    View Slide

57. POST http://localhost:8080/ HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)
    Accept: */*
    Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
    Accept-Encoding: x-gzip, x-deflate, gzip, deflateAccept-Language: en
    Content-Length: 1269
    Connection: close
    Substr)
    やっと遮断されなくなった
    ※実際のログのため一部文字を変更しています
    

    View Slide

58. 誤遮断のリスク
    • あるルールでは特定の SQL関数を遮断する可能性アリ
    • concat()
    • substr()
    • cast()
    • あるルールでは特定の SQL構文を遮断する可能性アリ
    • select ~ from
    • insert into
    • drop table
    

    View Slide

59. 誤遮断のリスク
    • あるルールでは特定の SQL関数を遮断する可能性アリ
    • concat()
    • substr()
    • cast()
    • あるルールでは特定の SQL構文を遮断する可能性アリ
    • select ~ from
    • insert into
    • drop table
     AWS WAFに適さないサイトもある。事前に正常系の通信で要検証。
    • ユーザーの自由入力でソースコードや関数が入るケース
    • “Select Shop from LA ”がもしリクエストに含まれたらNG
     誤遮断の発生時の調査の仕組みや、ユーザー対応などの検討
    • ソーリーページ、サポートとの連携など
    

    View Slide

60. 運用課題②
    チューニング
    

    View Slide

61. Condition設定はとてもシンプル
    例えばSQLinjectionの設定画面
    リクエストのどこを
    監視するか
    Decodeなどの文字列
    変換するか
    →どこにSQLiのフィルターを適用するかを選択するだけ
    →検知条件の中身（シグニチャ）はブラックボックス
    

    View Slide

62. つまり
    誤検知をすることが判明した場合、
    “特定のURI宛のこういうリクエストだけ除外”ができない。
    やる場合は、IPや正規表現でホワイトリストルールを作成し、
    ACLの順序で検知除外
    

    View Slide

63. チューニングが難しい
    • ポリシーの中身（シグニチャ）がブラックボックス
    →何が検知するのかわからない、何が検知したかがわからない
    • ポリシーの細かい調整ができない
    →誤検知の際に調整が難しい
    最悪ポリシー自体の無効化をせざるをえない
    

    View Slide

64. チューニングが難しい
    • ポリシーの中身（シグニチャ）がブラックボックス
    →何が検知するのかわからない、何が検知したかがわからない
    • ポリシーの細かい調整ができない
    →誤検知の際に調整が難しい
    最悪ポリシー自体の無効化をせざるをえない
     Conditionの中身（シグニチャ）についてはAWSまたは
    マネージドルールのベンダーにお任せ
     細かいチューニングは難しい（ACLの順序でできる限り）
     あとは割り切る覚悟
    

    View Slide

65. 運用課題③
    ログ
    

    View Slide

66. AWS WAF ダッシュボード
    • Web ACLs ＞ 設定したWeb ACLを選択
    • Sampled Web Requestsが参照できる
    

    View Slide

67. {
    "Request": {
    "ClientIP": ”XX.XX.XX.XX",
    "Country": "JP",
    "URI": "/test/WAF/editar.jsp",
    "Method": "POST",
    "HTTPVersion": "HTTP/1.1",
    "Headers": [
    {
    "Name": "Host",
    "Value": ". *************cloudfront.net"
    },
    {
    "Name": "Content-Length",
    "Value": "295"
    },
    {
    "Name": "POST http",
    "Value": "//*************.cloudfront.net/test/WAF/editar.jsp HTTP/1.1"
    },
    〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 一部抜粋 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
    {
    "Name": "User-Agent",
    "Value": "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.8 (like Gecko)"
    },
    },
    "Weight": 3,
    "Timestamp": "2018-05-15T06:09:42.321000+00:00",
    "Action": "COUNT"
    },
    AWS WAF APIの“GetSampledRequests”
    • 送信元IPアドレス
    • リクエストメソッド
    • リクエストヘッダー（URI,
    UA, Content-Length）
    • 検知時刻
    • アクション
    ※一部伏字＆修正しています
    

    View Slide

68. ログの課題
    • 検知ログをみるならばSampled Log
    • 5,000件のうちの500件が出力可能
    →全ての検知ログが出ないため、検知をしたか確認できないことがある
    • 保存期間は３時間
    →３時間以上過去の調査ができない
    • 検知箇所（文字列）、リクエストbody、レスポンスは含まれない
    →POSTの場合のリクエスト特定や攻撃の影響調査が難しい
    “Gets detailed information about a specified number of requests--a sample--that AWS WAF
    randomly selects from among the first 5,000 requests that your AWS resource received during
    a time range that you choose. You can specify a sample size of up to 500 requests, and you
    can specify any time range in the previous three hours.”
    出典：https://docs.aws.amazon.com/ja_jp/waf/latest/APIReference/API_GetSampledRequests.html
    

    View Slide

69. ログの課題
    • 検知ログをみるならばSampled Log
    • 5,000件のうちの500件が出力可能
    →全ての検知ログが出ないため、検知をしたか確認できないことがある
    • 保存期間は３時間
    →３時間以上過去の調査ができない
    • 検知箇所（文字列）、リクエストbody、レスポンスは含まれない
    →POSTの場合のリクエスト特定や攻撃の影響調査が難しい
    “Gets detailed information about a specified number of requests--a sample--that AWS WAF
    randomly selects from among the first 5,000 requests that your AWS resource received during
    a time range that you choose. You can specify a sample size of up to 500 requests, and you
    can specify any time range in the previous three hours.”
    出典：https://docs.aws.amazon.com/ja_jp/waf/latest/APIReference/API_GetSampledRequests.html
     検知リクエストの特定、詳細分析はWAFのログだけでは難しい
     もっとログが欲しい場合は工夫が必要
    

    View Slide

70. ログの工夫例
    ログの保管期間の延長
    • AWS WAFのイベントをCloudWatchでモニタリング
    • CloudWatchでLambdaを実行しAWS WAFのログをS３に保管
    参考：「AWS WAFのログが3時間しか見れないのでなんとかしてみる 」
    https://speakerdeck.com/tmorinaga/aws-waffalseroguga3shi-jian-sikajian-
    renaifalsedenantokasitemiru
    詳細ログの取得
    • Lambda@edge（Cloudfront＋lambda）を使用しフロントで
    リクエストとレスポンスのログ取得
    • AWS WAFはALBに関連づけて動作
    

    View Slide

71. チューニング
    動作検証
    ポリシーチューニング
    機器構築・回線敷設
    初期設定
    サイト設定・ポリシー設定
    監視開始後の
    運用
    ポリシー更新
    SWバージョンアップ
    ライセンス更新 ..etc
    検証
    監視開始
    商用WAF（オンプレ）
    基本的な導入時の流れ（商用WAF/オンプレ/非インライン）の例との比較
    セキュリティ運用はどうなる？（導入時）
    

    View Slide

72. チューニング
    動作検証
    ポリシーチューニング
    機器構築・回線敷設
    初期設定
    サイト設定・ポリシー設定
    監視開始後の
    運用
    ポリシー更新
    SWバージョンアップ
    ALB/Cloudfrontに関連づけ
    ライセンス更新 ..etc
    ACL作成・ルール設定
    検証
    監視開始
    商用WAF（オンプレ） AWS WAF
    基本的な導入時の流れ（商用WAF/オンプレ/非インライン）の例との比較
    カスタムルール追加
    セキュリティ運用はどうなる？（導入時）
    

    View Slide

73. チューニング
    動作検証
    ポリシーチューニング
    機器構築・回線敷設
    初期設定
    サイト設定・ポリシー設定
    監視開始後の
    運用
    ポリシー更新
    SWバージョンアップ
    ALB/Cloudfrontに関連づけ
    ライセンス更新 ..etc
    ACL作成・ルール設定
    検証
    監視開始
    商用WAF（オンプレ） AWS WAF
    WAF自体のメンテナンスは
    不要
    countモードで
    検知状況を確認
    基本的な導入時の流れ（商用WAF/オンプレ/非インライン）の例との比較
    カスタムルール追加
    ポリシーの
    中身はお任せで、
    必要なものは
    カスタムで追加
    セキュリティ運用はどうなる？（導入時）
    

    View Slide

74. 検知
    二次調査
    対象サイトのアセット情報を確認
    NWフォレンジック調査
    （攻撃の成否・影響の解析）
    WAFで検知
    一次調査
    検知ログ調査
    （攻撃内容の解析）
    事後対応
    FW遮断
    脆弱性の修正
    商用WAF（オンプレ）
    ..etc
    攻撃成功 攻撃失敗/過検知
    ポリシー
    チューニング
    基本的なアラート対応の流れ（商用WAF/オンプレ/非インライン）の例との比較
    セキュリティ運用はどうなる？（アラート対応）
    

    View Slide

75. 検知
    二次調査
    対象サイトのアセット情報を確認
    NWフォレンジック調査
    （攻撃の成否・影響の解析）
    WAFで検知
    一次調査
    検知ログ調査
    （攻撃内容の解析、検知リクエストの特定）
    事後対応
    FW遮断
    脆弱性の修正
    商用WAF（オンプレ） AWS WAF
    WAFで検知&遮断
    ..etc
    攻撃成功 攻撃失敗/過検知
    ポリシー
    チューニング
    ポリシーチューニング
    基本的なアラート対応の流れ（商用WAF/オンプレ/非インライン）の例との比較
    セキュリティ運用はどうなる？（アラート対応）
    

    View Slide

76. 検知
    二次調査
    対象サイトのアセット情報を確認
    NWフォレンジック調査
    （攻撃の成否・影響の解析）
    WAFで検知
    一次調査
    検知ログ調査
    （攻撃内容の解析、検知リクエストの特定）
    事後対応
    FW遮断
    脆弱性の修正
    商用WAF（オンプレ） AWS WAF
    WAFで検知&遮断
    ..etc
    攻撃成功 攻撃失敗/過検知
    ポリシー
    チューニング
    ポリシーチューニング
    基本は
    特になし
    細かい
    チューニングは
    できない
    検知ログがあれ
    ば見る
    基本的なアラート対応の流れ（商用WAF/オンプレ/非インライン）の例との比較
    セキュリティ運用はどうなる？（アラート対応）
    

    View Slide

77. AWS WAF向きなユースケース
    • PCI対応
    • AWS WAF はPCI DSS 3.2に準拠
    • “ガートナーのレポートによると25-30パーセントはPCI対応のために
    AWS WAFを導入”
    出典：https://www.slideshare.net/AmazonWebServicesJapan/20171122-aws-
    blackbeltawswafowasptop10
    • 特定のリクエストの遮断
    • 判明している脆弱性の攻撃を防ぎたい
    • 特定のUser-Agentでくるbotを遮断したい
    （カスタムルールの正規表現を使って対応）
    • 動的なFWとして活用
    • ブラックリストIP/ホワイトリストIP
    • MPの製品との組み合わせ
    • SIEM連携 ..etc
    

    View Slide

78. （例）AWS WAF セキュリティオートメーション
    AWS CloudFormation テンプレートで提供されているアーキテクチャ
    出典：https://aws.amazon.com/jp/answers/security/aws-waf-security-automations/
    Lambda＋サードパーティ
    のIPブラックリスト
    →
    WAFのブラックリスト
    ルールを自動更新して遮断
    Lambda＋S3のログで
    ログ解析
    →
    疑わしいIPをWAFルール
    に追加して遮断
    

    View Slide

79. 最後に
    • うちではこんな使い方してるよ！
    • 導入検討してます！ などなど
    ぜひ情報交換させてください
    

    View Slide

80. ご静聴ありがとうございました
    

    View Slide