質問: ■依頼 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 3) 該当する脆弱性があれば、影響するシステムのバージョンを把握する ex) phpMyAdmin 4.6.4 未満の 4.6.x、phpMyAdmin 4.4.15.8 未満の 4.4.x、phpMyAdmin 4.0.10.17 未満の 4.0.x 4) WAFで保護するWEBサーバがphpMyAdminを使用しているか、WEBサーバの構築業者に確認する 5) 4)の回答がyesの時、WEBサーバのphpMyAdminのバージョンが「影響するシステム」のバージョン範囲内であるか、WEBサーバの構築業者に確認する 6) 5)の回答がyesの時、誤検知を引き起こしたシグネチャーを無効にする ※シグネチャーを無効にしたときのリスクと対策についてWEBサーバの構築業者に説明する
回答: 良いか悪いかで言うと、まったく駄目と言わざるを得ないですね。 ご提案のフローですと、サーバーに該当の既知の脆弱性がなければシグネチャを無効化するようにしておられるようです。しかし、既知の脆弱性については原則としてバージョンアップや設定変更などで予め対応しておくべきです。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を含む攻撃を防御し、かつ誤検知しないカスタムシグネチャを追加しました。 このように、誤検知対処はケースバイケースであり、フローチャートにより機械的に対応することは難しいのではないかと考えます。