【WAF】正常な通信を誤検知した時の対応フローについて

Question

■依頼
WAFの導入に当たり、正常な通信を誤検知した時の対応フローを検討し、以下の通りまとめました。
対応フローは、まったくの初心者を除き、ある程度ITスキルの基礎を有した方でも対応できるような内容を目指しております。
有識者の皆様に、以下の対応フローの問題点や、ほかによい方法など様々なアドバイスを賜りたいです。

■誤検知時の対応フロー案

1. 誤検知を引き起こしたシグネチャーがブロックする攻撃名を確認する
   ex) OSコマンドインジェクション

2. 以下のサイトで、攻撃名のCWE-を入力して、WEBサーバで使われるプログラム(ex. PHP, Java等)の脆弱性がないか確認する。
   ex) CVE-2016-6631

http://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja

1. 該当する脆弱性があれば、影響するシステムのバージョンを把握する
   ex) phpMyAdmin 4.6.4 未満の 4.6.x、phpMyAdmin 4.4.15.8 未満の 4.4.x、phpMyAdmin 4.0.10.17 未満の 4.0.x

2. WAFで保護するWEBサーバがphpMyAdminを使用しているか、WEBサーバの構築業者に確認する

3. 4)の回答がyesの時、WEBサーバのphpMyAdminのバージョンが「影響するシステム」のバージョン範囲内であるか、WEBサーバの構築業者に確認する

4. 5)の回答がyesの時、誤検知を引き起こしたシグネチャーを無効にする
   ※シグネチャーを無効にしたときのリスクと対策についてWEBサーバの構築業者に説明する

Answer 1

良いか悪いかで言うと、まったく駄目と言わざるを得ないですね。
ご提案のフローですと、サーバーに該当の既知の脆弱性がなければシグネチャを無効化するようにしておられるようです。しかし、既知の脆弱性については原則としてバージョンアップや設定変更などで予め対応しておくべきです。WAFに期待したいのは、

• プラットフォームソフトウェアに新たに発見された脆弱性
• 自ら開発した（させた）アプリケーションの脆弱性

であり、これらはご検知が見つかった時点では既知となっていないわけです。
したがって、「この環境にはOSコマンドインジェクション脆弱性がないからOSコマンドインジェクションのシグネチャは無効化しても大丈夫」と判断しても、その後新たにOSコマンドインジェクション脆弱性が発見されたタイミングでは、WAFが対応できないことになります。そういう場面こそWAFに働いて貰いたいわけです。
なので、shoko1さんが既に指摘されているように、プロに任せた方がよろしいかと思います。

---

コメントいただいた内容に対して、長くなりますので、回答本文に追記いたします。

誤検知で業務影響で出ているのにWAF側で何も対応しない訳にはいかないと思います。

その通りです。なので基本的に誤検知のでるシグネチャは無効化しますが、

まず、サイト全体にわたって当該シグネチャを無効化するかどうかを検討します。
通常シグネチャが誤検知するのは特定ページ(URL)だけですので、WAFにもよるでしょうが該当URLだけ無効化できれば、無効化による防御力低下を緩和できます。

次に、シグネチャ無効化による防御力低下が許容範囲かどうかを確認します。

たとえば、たまたまStruts2の脆弱性に対するシグネチャが誤検知していて、当該サイトでStruts2を使っていない場合であれば、そのシグネチャを無効化することによる防御力低下は無視できます。
また、SQLインジェクション脆弱性のシグネチャ（の一つ）が誤検知していても、当該サイトでSQLを使っていない場合は同様です。

私が過去に経験した例では、バランサーがクッキーに100%という値をセットしていて、これがWAFで誤検知した例があります。100%はパーセントエンコード（URLエンコード）として見た場合不正な値だからという理由です。しかし、当該サイトはクッキーにはセッションIDしか入っておらず、不正なパーセントエンコードによる攻撃はできないだろうという判断から当該シグネチャは単に無効化しました。何らかの理由で無効化では不安な場合は、(1)ホワイトリストによるチェックを追加する、(2)クッキー値が「100%」という値の場合のみ当該シグネチャを無視するというルールを追加する、等の運用が考えられます。

また、当該脆弱性のシグネチャが複数あり、そのうちの一つのみが誤検知している場合は、他のルールで十分守れると判断すれば、当該シグネチャを単に無効化します。

また、CMSのサイトによくありますが、特定シグネチャが管理者ページで誤検知するが、当該ページはBASIC認証で保護されていて外部からの攻撃は想定しなくて良い場合は、管理者ページ全体で当該シグネチャを無効化するという作戦も考えられます。

最後に、上記のような無効化戦略が使えない場合はやっかいです。
私の経験では、フランス語を扱うサイトで、語尾が「'or」で終わるフランス語単語が誤検知する例がありました。これは単に無効化は危険だと思われたので、当該シグネチャを無効化する代わりに、ORを含む攻撃を防御し、かつ誤検知しないカスタムシグネチャを追加しました。

このように、誤検知対処はケースバイケースであり、フローチャートにより機械的に対応することは難しいのではないかと考えます。

Comments

[退会済みユーザー]

ockeghem様

ご回答ありがとうございます。

私もockeghem様のご意見に賛同で、
既知の脆弱性についてはWEBサーバ側でバージョンアップや設定変更すべきだと思います。
しかし、タイミングや金銭的な理由などの諸事情でWEBサーバ側ですぐに対応できない場合もあります。
そのような状況で、WAFの誤検知でページが閲覧できない問題が発生した時、シグネチャーを無効化せざるをないと思います。
しかし、単純にシグネチャーを無効化するのでなく、
JPNICなど脆弱性情報を確認し、WEBサーバ管理者にシグネチャー無効化による影響する義務はあると思います。
脆弱性がコーディングに起因するものであれば、影響範囲を明確にするのは難しいと思いますが、
アプリケーションに起因するのであれば、バージョン確認だけである程度影響範囲を絞れると思います。

誤検知で業務影響で出ているのにWAF側で何も対応しない訳にはいかないと思います。
プロに任せたほうがいいと仰っていましたが、
プロも誤検知があった時シグネチャーの無効化などチューニングされていると思います。
実際の現場で異なっていましたら、申し訳ございません。
shoko1様が、WAFはFirewallと同じというニュアンスでご説明されていましたが、
Firewallも正常な通信がブロックされたら、リスクを許容してルールを追加しますよね。

WAFもFirewallと同様にリスクや影響範囲を理解して、シグネチャーを無効化など対応をする必要があると思います。

[shoko1]

伝わらなかったようですが、「セキュリティ技術者」がリスクを許容して設定できるのは当然で、それと同じことをフローを用意した程度では「ある程度ITスキルの基礎を有した方」には無理で、そんな運用ではWAFの費用対効果がでないと書いたつもりです。

Answer 2

「ある程度ITスキルの基礎を有した方」がどの程度と想定されているのかにもよりますが、WAFのシグネチャ調整はその程度の方には難しいと思われます。WAFのFがFirewallで、Firewallを設定・運用できるスキルと考えるとわかりやすいかもしれません。

WAFは適切な運用を前提とするソリューションで、その体制が維持できないのであれば組織内導入は難しいです。だからこそクラウド型やマネージド型のWAFが存在して、それなりに売れているという現状があります。
セキュリティ技術者の有無でどのWAFソリューションを選定するかを考えた方が費用対効果があると思われます。