お使いの WAF (Web アプリケーションファイアウォール) が実際にどれだけ効果的か疑問に思ったことはありませんか？攻撃を本当にブロックできるのか確信が持てますか？どのくらい、誤検知が発生しますか？最近行った変更で、検出能力が改善されましたか？それとも悪化しましたか？
ほとんどの WAF テクノロジーでは、長い正規表現リストの面倒な管理が必要です。そのため、すでに WAF に良い印象を抱いていない場合、このような疑問から WAF の使用を完全にやめることを検討し始めるのも当然です。
Fastly では、WAF 有効性フレームワークを導入することで、このような疑問に対処することにしました。この記事ではこのフレームワークについてご紹介します。同フレームワークは、継続的な検証と妥当性確認を通じて、WAF の検出能力の有効性を測定する標準的な方法を提供します。有効性が十分でない点を特定し、改善と管理に役立つフィードバックループを提供します。これには、さまざまな攻撃タイプをテストするためのシミュレーション攻撃の評価が組み込まれており、その結果は全体スコアに反映されます。得られたスコアは継続的改善のためのワークフローに送信され、現在の有効性のスポットチェックに使用されたり、時間とともに変化する有効性の傾向分析に使用されます。
Fastly のアプローチ
WAF はアプリケーションサーバーにトラフィックが到達する前に HTTP/S トラフィックを検査します。WAF はアプリとクライアントの間に位置し、通過するあらゆる通信を分析するものとして考えることができます。WAF は怪しいトラフィックや異常なトラフィックをモニタリングし、望ましくないトラフィックがご利用のアプリケーションに到達する前に特定のルールに基づいてリクエストをブロックし、アプリケーションを攻撃から保護します。
HTTP/S リクエストには、以下が含まれます。
ドメイン (fastly.com など)
リソース (/cat.png など)
メソッド (GET、POST、PUT など)
ヘッダー (サーバーに送信される追加情報、攻撃者が悪意のあるコードを挿入する場所でもあります)
さらに、任意のリクエストボディもあります。GET リクエストには通常、ボディがありませんが、正当な情報と望ましくない情報の両方を送信できる POST リクエストには、ボディが含まれる傾向があります。
以下は、fastly.com/cat.png に対する HTTP 1.1 GET リクエストを分かりやすく解説したものです。
さらに、JSON ボディを持つ POST リクエストの例を示します。
攻撃者は、URL、ボディ、クッキー、その他の HTTP ヘッダーなど、常にリクエストの中で攻撃の足掛かりとなる場所を探しています。このため、リクエストのさまざまな場所でペイロードが検出されるかどうかをテストすることが、有効性フレームワークの主な原則となります。
すべてのセキュリティ技術と同様に、検出メソッドが強力になると、攻撃者は検出を回避する方法を模索し、目標を達成し続けようとします。WAF による検出を回避するためによく使用されるメソッドに、検出をバイパスするようにペイロードを暗号化するというものがあります。このため Fastly では、複数の暗号化技術を含むテストも実行しています。あらかじめ定義されたペイロードをそれぞれのペイロードの位置に注入し、リクエストの平文バージョンと暗号化バージョンの両方をターゲットに送信することで、回避メソッドが使用されている場合でも検出範囲をテストできる貴重な手段を提供します。
ただし、もちろんペイロードの妖精が魔法を使って空からペイロードを落とすわけではありません。また、関連するペイロードは、攻撃メソッドの進化に伴い、時間の経過とともに変化する可能性があります。そこで、PayloadsAllTheThings、PortSwigger、Nuclei、exploit-db、Twitter を起点としてペイロードリストを構築し、ペイロードリストを定期的に更新することをお勧めします。
WAF の有効性をテストするのに、脆弱性のあるアプリを使用する必要はありません。目的は、WAF 検出能力の有効性を測定することであり、アプリケーション自体に脆弱性があるかどうかをテストすることではありません。最終的に、WAF の使用を通じて目指す理想的な状態は、アプリの脆弱性がインシデントにつながらないことです。ご利用の WAF がさまざまなタイプの攻撃からアプリを保護できることが確認できれば、特定の脆弱性のような小さな問題に悩む必要がなくなります。そのためには、https://httpbin.org のような単純な HTTP のリクエスト・レスポンスサービスを利用するだけで十分です。
Fastly では、各攻撃タイプについて、真陽性と偽陽性の2つのケースをテストして WAF の有効性を評価します。真陽性のテストでは、攻撃ペイロードが正しく特定されたかどうかを確認します。そして、偽陽性のテストでは、容認可能なペイロードが間違って特定されたかどうかを確認します。
WAF がリクエストを正しく特定したかどうかを判断するため、レスポンスのステータスコードを調べます。ほとんどの WAF ソリューションでは、ブロックされたリクエストに対するカスタムレスポンスのステータスコードを作成する機能がサポートされています (この例については、関連する Fastly のドキュメントをご覧ください)。もしご利用の WAF ソリューションでカスタムレスポンスのコードを設定できない場合は、そのソリューションへの投資を見直す価値があります。
WAF 有効性フレームワークでは、リクエストがブロックされた場合、「406 Not Acceptable」のレスポンスコードを受信しているかどうかに特に注目します。真陽性のテストケースでは、406以外のレスポンスコードを受信した場合、偽陰性とみなされます。逆に、偽陽性のテストケースでは、406以外のレスポンスコードを受信した場合、真陰性とみなされます。これらの結果は、攻撃タイプごとの有効性スコアを計算するために使用され、これらのスコアは、すべての攻撃タイプに対する WAF の有効性を示す総合スコアに集約されます。
結果の評価
個々の有効性スコアと集計された有効性スコアを生成した後、これらの指標をアクションプランにつながるナレッジに変換するにはどうすればよいのでしょうか？これらの結果を評価する上で、考慮すべき重要なポイントの一つに組織の優先事項があります。皆さんの組織では、一部の攻撃が小さな隙を狙って入り込んだとしても、アプリケーションへのトラフィックを最大化することを優先しますか？それとも、トラフィックを削減することになったとしても、できるだけ多くの攻撃をブロックしたいと考えますか？Fastly の顧客ベースを見渡すと、一般的にはトラフィックの最大化が優先される傾向が見られます。トラフィックの削減は収益に影響を与える可能性があり、これはビジネスの観点から言えば最悪の影響と言えます。
実際のところ、Web 攻撃からの完璧な保護は不可能です。文字通り、すべてのリクエストをブロックすれば完璧な保護は可能ですが、それではインターネット上でアプリを実行するという根本的目的を果たすことができません。そのため、偽陽性と偽陰性の正確なバランスを見つけることが WAF ソリューションの有効性を判断する上で重要な要素となります。すべてのセキュリティツールには、偽陽性と偽陰性があります。すべてのケースで100%確実であることが可能なら、セキュリティの問題は存在しないも同じです。
偽陽性率が高いほど、攻撃を検出できる可能性が高くなります。しかし正当なトラフィックが攻撃として間違って特定される確率も高まり、ブロックモードではこの問題による影響は特に深刻です。また、偽陽性は誤検知による誤ったアラートのようなものです。人間の性質として、誤ったアラートを多く体験しすぎると、アラートを無視し始めます。その結果、本物の攻撃トラフィックに対処しない可能性が高まるだけではなく、WAF の投資利益率も損なわれます。さらに、大量の誤検知は認知的な負担をもたらします。誤検知に対応することでスタッフが精神的に疲労してパフォーマンスが低下し、チームメンバーの離職率が高まる原因となることもあります。
一方、偽陰性率が高いほど、偽陽性の確率が低くなり、結果としてアラートの信頼度が高まります。しかし、これは実際の攻撃トラフィックが検出されない可能性も高まるということでもあります。
このような陰性結果と陽性結果のクラス間の不一致を明確にするため、Fastly の WAF 有効性フレームワークには「バランスの取れた精度 (balanced accuracy)」と呼ばれる指標が組み込まれています。バランスの取れた精度によって、クラスにおける不均衡を明らかにすることが可能になり、陰性と陽性のケースを正しく予測することにおいて、特にどちらも優先しない場合に、便利な指標を提供します。皆さんに必要なのは、ビジネスやシステムを保護するために、これらの指標を賢く活用することです。以下のセクションでは、バランスの取れた精度の計算方法についてご説明します。
面倒な作業を自動化
手作業によるテストは決して容易ではなく、可能なテスト方法や結果の測定方法をすべて考慮しようとすると、実現不可能なタスクのスパイラルに陥る可能性があります。これは攻撃ペイロードの大規模なデータセットを扱う場合、特に当てはまります。テストは再現可能で柔軟性に優れ、目に見える証拠に基づいて Web アプリケーションのセキュリティ戦略を調整できるよう、結果に集中できるようでなければなりません。
そのため、Fastly は Nuclei と呼ばれるオープンソースプロジェクトをこのフレームワークの土台として選びました。Nuclei はシンプルな YAML ベースのテンプレートを使用することで、テストにおいて面倒で反復的なタスクを手作業で行う手間を省きます。Nuclei テンプレートは、リクエストがどのように送信され処理されるかを定義します。また、Nuclei は柔軟な設定が可能で、送信されるリクエストに関して、非常に細かいことまで設定し、定義することができます。
新しい知識・情報を得ることはフィードバックループを促進する上で不可欠なため、すべてのリクエストが JSON 形式でログに記録されます。ログには、リクエスト/レスポンスのペアとその他のメタデータが含まれます。これらのログは、ダッシュボードや履歴の比較など、WAF 戦略の向上に役立つインサイトを得るために利用することができます。例として、Google Cloud Storage (GCS) バケットに結果をアップロードし、BigQuery でテーブルを作成するためのデータセットとして利用できるようにしました。そして、データを Data Studio に接続してスコア付きの詳細なレポートが生成されるようにしました。
自動化によりテストの拡張と再現が容易になり、チームは面倒な作業から解放されます。Fastly では、このような手順を統合して、WAF の有効性テストを実行する CI/CO パイプラインを作成することをお勧めします。ワークフローは、以下の手順で定義することができます。
テストのターゲットを構築する
有効性テストを実行する
任意のバックエンドに結果を保存する
レポートを生成する
任意のペースで繰り返す
Fastly をぜひお試しください
この機能をより広範囲のセキュリティコミュニティと共有するために、Fastly セキュリティリサーチチームは「wafefficacy」と呼ばれるオープンソースプロジェクトを作成しました。このプロジェクトには開始する際に必要な初期コードとテンプレートが含まれています。このプロジェクトでは、コマンド実行 (cmdexe)、SQL インジェクション (sqli)、トラバーサル (traversal)、クロスサイトスクリプティング (xss) のボイラープレートの例が用意されているので、これらの主要な攻撃タイプに対する有効性テストをすぐに開始することができます。
有効性テストを実施する前に、確認すべき要件が2つあります。
テスト対象の WAF が、ブロックモードに設定されている
リクエストがブロックされた場合に返されるレスポンスのステータスコードが設定されている。デフォルトでは、wafefficacy は「406 Not Acceptable」の受信を確認します。
初期設定を完了したら、以下のようにターゲット URL またはホストを指定して、プロジェクトディレクトリから実行可能バイナリを実行することができます。./wafefficacy run -u https://example.com
評価が完了すると、スクリプトによってスコア結果が以下の標準出力で表示されます。
有効性スコア
バランスの取れた精度を指標に使用して、有効性スコアがどのように計算されるかを詳しく見てみましょう。
まずは、以下に示す混同行列から始めましょう。
上記において、TP/FP/TN/FN の「positive (陽性)」と「negative (陰性)」は実際のクラスではなく、予測されたものを指しています。(つまり、「False Positive (偽陽性)」とは、間違って陽性と予測してしまったことを意味します)
バランスの取れた精度は、一般的に使用される2つの指標に基づきます。
感度 (真陽性率とも呼ばれます) は、「陽性のケースをいくつ検出したか」という質問に関するものです。
特異度 (真陰性率または 1 - 偽陽性率とも呼ばれます) は、「陰性のケースをいくつ検出したか」という質問に関するものです。
バランスが取れていないクラス設定において、バランスの取れた精度が検出において、いかにより良い判断基準となるか、例を使って説明します。WAF に対して SQL インジェクション攻撃のシミュレーションを行い、以下の混同行列に示される結果を得たと仮定します。
この混同行列は、750件の真陽性のテストケースのうち700件が真陽性、50件が偽陰性だったことを意味します。これと並んで、105件の偽陽性のテストケースのうち5件が偽陽性、100件が真陰性だったとします。
この情報を使用して、バランスの取れた精度の計算方法を以下に示します。
バランスの取れた精度の計算によると、この WAF は SQL インジェクション攻撃に対して約94.3%の防御効果を発揮していることになります。
比較のために、別の WAF をテストして偽陽性の結果が逆転したと仮定してみましょう。たとえば、105件の偽陽性のテストケースのうち100件が偽陽性、5件が真陰性だったとします。
これにより、特異度の割合は以下のように変わります。
そして、バランスの取れた精度の割合も以下のように変わります。
バランスの取れた精度に基づくと、SQL インジェクション攻撃に対する防御において、1番目の WAF (94.3%) は2番目の WAF (49.1%) よりも優れていると確信をもって言うことができます。
概要
攻撃者が試す前に、自社システムのセキュリティをテストするのが最善です。Fastly の WAF 有効性フレームワークは、継続的な検証と妥当性確認を推奨します。同フレームワークを活用することで、攻撃シミュレーションを自動化し、技術的なセキュリティコントロール能力を検証すると同時に、セキュリティギャップを特定し、ツールの有効性をレポート・測定することが可能になります。実際、同じ方法を、自社や自社システムに関連するあらゆるセキュリティツールに対して適用することができます
このように有効性テストを実施することで、安全でコントロールされたテストが可能になり、実際の状況でコントロール機能がどのように脅威に反応するか観察できるようになります。コントロールが適切かつ効果的に実装されているか判断するのに役立つフィードバックループの導入を可能にする有効性フレームワークは非常に価値のあるツールです。
WAF の有効性に対する理解を深め、その向上に向けて、是非 Fastly のプロセスやツールをご活用ください。
Web アプリケーションのセキュリティニーズに対する Fastly のソリューションの詳細については、セキュリティ製品の概要をご覧ください。また、Fastly の一員として一緒に仕事をすることに興味がある方は、Fastly の求人情報をぜひご覧ください。
クラウドネイティブの AppSec プレイブック
エンタープライズ Web アプリケーションを標的とする攻撃者が使用する、ますます巧妙化する攻撃の手口と、それらをブロックする方法を理解しましょう。このプレイブックでは、エンジニアリング/運用/セキュリティチームを対象にクラウド・ネイティブ・アプリケーションに必要なセキュリティの仕組みと、その確保が重要な理由をご説明します。e ブックをダウンロード