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

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

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

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

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

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

時代の流れ

時代の流れ 社内の主流

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

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

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

No content

2. 検証してみた

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

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

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

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

攻撃用データ① 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

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

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

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

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

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/

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月現在） • 今回の検証では汎用的に使えそうな８種類に絞り込んだ

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

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

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

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

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

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

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

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

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

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

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

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

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

Web ACL / CloudFront 連携手順①

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

Condition 設定時の落とし穴

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

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

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

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

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

AWS WAF 結構良いかも！

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

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

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

運用課題① 誤遮断

とある遮断された正常系リクエスト 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':{}} ※実際のログのため一部文字を変更しています

遮断された正常系リクエストの１つ 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':{}} “あああ” という文字が原因... ？？ ※実際のログのため一部文字を変更しています

遮断された正常系リクエストの１つ 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':{}} ではなかった ※実際のログのため一部文字を変更しています

“あああ” 除外しても遮断される 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':{}} ※実際のログのため一部文字を変更しています

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) もっと絞っても遮断される ※実際のログのため一部文字を変更しています

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() さらに絞っても遮断される ※実際のログのため一部文字を変更しています

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) やっと遮断されなくなった ※実際のログのため一部文字を変更しています

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

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

運用課題② チューニング

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

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

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

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

運用課題③ ログ

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

{ "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） • 検知時刻 • アクション ※一部伏字＆修正しています

ログの課題 • 検知ログをみるならば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

ログの課題 • 検知ログをみるならば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のログだけでは難しい  もっとログが欲しい場合は工夫が必要

ログの工夫例 ログの保管期間の延長 • 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に関連づけて動作

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

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

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

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

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

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

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

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

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

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