WAF導入失敗あるある ～WAFを導入してから気付く5つのポイント～
知っていればWAF導入前のチェックで防げる、５つの「WAF失敗あるある」をまとめました。
導入前のチェックで防げる、5つの 「WAF失敗あるある」 とは？
Webサイトに関するセキュリティ意識が高まる中、「ウチもそろそろWAF導入を考えよう」とか、「これまで一部サイトでWAFを導入していたが、対象サイトを広げよう」といった検討をされているご担当者も多いのではないでしょうか。
現在、日本国内でも様々なWAFサービスが出揃い、選択肢は豊富にある状況ですが、どのWAFもたいてい「高性能」「低コスト」「手間が掛からない」「誤検知が少ない」といった謳い文句を判で押したようにアピールしています。そのため、「どんなWAFでも導入してさえいれば同じだろう」とか、「費用が安ければそれでよい」とか、「SIや開発会社が提案したものをそのまま受け入れれば問題ないだろう」とか、「利用しているインフラ事業者のオプションWAFを利用するのが楽そう」といった判断をしてしまうのもごく自然なことです。
しかし、WAFは事前にベンダーが提供する情報だけでは分からないことが非常に多く、導入して初めて分かるトラブルでご担当者や関係者が苦しむケースも多数見受けられます。ここでは、そんな「WAF失敗あるある」を紹介することで、WAFは安価で導入が楽なら何でも良い訳ではないこと、また、事前にちょっと調べるだけで導入後の予想外のトラブルを避け、安定した運用が可能となることをお伝えしたいと思います。
特に考えずに手近なWAFの導入を決めてしまう前に少しだけ足を止めていただき、自社のニーズや運用実態に合ったWAFがどんなものか、比較検討してみてはいかがでしょう？
WAF失敗あるある 【1】
「正常リクエストなのに遮断されてしまい、顧客や関連部署から怒られる」
WAFの検知方式に起因する失敗として、「誤検知」に悩まされることが挙げられます。たとえ誤検知が少ないと謳っていても、「シグネチャ」という古い判定方法にいまだに頼っているWAFには注意が必要です。シグネチャのみで攻撃を検知しようとすると、一部だけシグネチャにマッチした正常通信を攻撃と見なす誤検知が増えてしまいます。これが「WAFを導入してから、アクセスを止められがち」「特定の環境のユーザが通信できない」「アプリケーションの更新時に誤検知が発生しやすく都度調整が必要」といった関係各所からのクレームの元に。しかし、誤検知を避けるために検知を弱めると防御ができず、どちらを選んでも責任を問われる最悪のパターンになることも。
- WAFのサポートに求められる専門性、特殊性について
- WAF運用サービス委託先とWAFベンダー間の連携/調整の難しさ
- 通常時も障害時もサポートフローが明確であることが重要
- 一次対応段階から広範囲のサポートを素早く提供できるWAFが安心
- サポートサイトの充実もポイント
WAF失敗あるある 【2】
「新たな脆弱性を狙った攻撃にいつ対応できるかとの質問に答えられず焦る」
新たな脆弱性や攻撃手法への対応スピードが不十分なWAFを選んでしまった場合の「失敗あるある」です。IPA、JPCERT/CCからの注意喚起やニュースで知った上司や関係者から、「WAFで防御できているか」を聞かれてもなかなか答えられない。ベンダー資料では新脆弱性への素早い対応を謳っていても、公式サイトに対応情報が速やかに掲載されなかったり、担当者へ問い合わせてもすぐに返答がもらえず、板挟み状態でやきもきさせられる結果に…。その対応も、IPAやJPCERT/CCの注意喚起発表から数日後では今の時代は遅すぎです。また「実はもう対応済でした」といった“後出し報告”にも注意したいところです。
- Log4shell、Apache Struts2の脆弱性など、近年の脆弱性対応で求められるスピード感
- 脆弱性調査→WAF開発/実装→サポートのスムーズな連携の必要性
- WAFと「ゼロデイ攻撃」「ゼロデイ防御」
- WAFベンダーが脆弱性への具体的な対応実績/所要日数を公表していることの重要性
WAF失敗あるある 【3】
「誤検知発生時は原因となったシグネチャをOFFにして対応…それって大丈夫？」
誤検知で正常通信が止まってしまう場合、「シグネチャを一時的に無効にする」という対策しか選べないWAFも少なくありません。その方法で問題ないという見解を持っているWAFベンダーもあるようですが、各シグネチャには本来止めようとしていた攻撃があったはずで、無効にすればその分ダイレクトに防御能力の低下に繋がります。せっかく導入したWAFなのに、「なぜ誤検知調整によって防御力が落ちるの？」と不安を抱えたまま運用することに…。
- シグネチャ依存WAFの誤検知調整の難しさ
- 担当者の責任でシグネチャをOFFにする際のプレッシャー
- 多面的な検知方法によって初めて可能となる柔軟な誤検知調整
- 誤検知発生時の対応フローが明確になっているか確認することが重要
WAF失敗あるある 【4】
「サポート品質を導入前に確認できないがまあ大丈夫だろう…ダメだった！」
トラブル発生時のサポート品質がイマイチという話も、WAF導入後に発覚しがちな「失敗あるある」です。一刻を争う状況なのに、一次サポート担当者からの返答は「確認します」「調査中です」だけで、回答が来るまで延々と待たされるケースも。その間、社内からの問い合わせに歯切れの悪い回答を繰り返すしかなく、イライラの矛先を向けらえれることも。導入前にサポートフローをしっかり確認しておけばよかった…と後悔する結果に。
- WAFのサポートに求められる専門性、特殊性について
- WAF運用サービス委託先とWAFベンダー間の連携/調整の難しさ
- 通常時も障害時もサポートフローが明確であることが重要
- 一次対応段階から広範囲のサポートを素早く提供できるWAFが安心
- サポートサイトの充実もポイント
WAF失敗あるある 【5】
「安価で手軽なクラウドインフラのオプションWAF、使ってみたらこんな限界が」
「低コストで素早く導入できるから」と、メジャーなクラウドインフラのオプションとして提供されているWAFを選んだら、運用が大変で結局使えなかった…というガッカリもよくあるケース。あくまでも基本機能のみの「オプション」的な役割のため、設定や更新が煩雑だったり、通信内容の一部しかチェックしていなかったりシグネチャ依存による誤検知や防御能力低下の問題を抱えていたりと、導入前よりも手間が増えたのに効果的に防御できないこともしばしば。費用を抑えようとしたが、予想外に担当者の仕事が回らなくなるという悪循環に陥ることも…。
- ・WAFは通信のどこを監視するのか？
- ・インフラオプション型WAFはシグネチャ依存型が多い
- ・攻撃者に研究されやすく狙われやすいという弱点
- ・運用を外注すると結局コスト削減にならないジレンマ
- ・導入する場合はインフラオプション型WAFの限界も知った上で検討を
関連ページ
WAFを選択する前にチェックしておきたい、7つの比較ポイント
WAFの比較ポイント～自社のニーズに合ったWAFを選択するヒント～
Scutumの関連情報に関する詳細はこちらで公開しています。
Scutumサポートサイト
Scutum活用ブログ
Scutum技術ブログ（Scutum開発者自身がScutumの技術的背景を解説）