WAFの比較はむずかしい、、、というはなし

最近、2つのWAF(Web Application Firewall)製品を比較するということをして感じたことメモしておく。

結論としては「WAFの比較ってむずくない😱？」

今回はもともととあるWAF製品を使っていて、とあるイベント🎪で良さそうなWAF製品を紹介されたので比較してみた。

■ 機能面での比較はむずかしい

WAFで設定できるルールだったり、ダッシュボードだったり、アラートだったり、、、といったものは最近のWAF製品だとどれも大差がないんじゃないかと思う。もちろん製品固有の機能があったりするとは思うが、じゃーその機能あなたのシステムでホントに使いますかと聞かれると悩んでしまう🤔おそらくWAFでよく使う機能は独自ルールの作成だったり、アラートの定義やダッシュボードでのメトリクス確認が主になると思うが、そこでの差別化要素はほとんどないんじゃないかと感じた。

■ 本番に仮導入するのはむずかしい

WAFを導入するとき独自ルールの整備はできればしたくない。（しなければいけないということは理解しているが、極力したくない）できればマネージドなルールやデフォルトルールで多くの不正リクエストを検知してくれることが望ましい。という感じだと思う。新しいWAFが既存のWAFと比較してどれくらい検出率が優れているかというのを確認しようと思うと、新しいWAFで本番システムに流れるリクエストを受けてみるのが手っ取り早いと思う。ただ、いざ本番にいれるとなると誤検知のリスクもあるので、ブロックはしない検出モードみたいな形で導入することになると思う。そうなると既存のWAFと共存させる形で構成を組むことになるわけだが、その構成に無理が生じてくる。もともと、WAFはシステムで最初にリクエストを受け付けるところに配置するのが基本だと思う。たとえば、CDNやALBなど。検出率を比較しようとすると既存のWAFの前に新しいWAFを配置する必要があるわけだから、CDNやALBを多段にするみたいな無茶な構成になってしまう。リクエストミラーリングみたいな機能が都合よくあるといいんだが、大抵の場合そんなものはないわけなのでやっぱり頑張って構成を組むことになりなんだかなぁという気持ちになってしまう。

■ 不正リクエストの検出率の比較はむずかしい

うまく構成を組めたとして、いざリクエストを受け付けるぜ！！！となったとしても、検証期間中に検出率に差がでるようなリクエストがタイミングよくくるのかはほぼ運になる。（検出される＝不正なリクエストな訳だからできればきてほしくないまである）比較検証なわけだからそんなに長い期間かけるわけにもいかないのでより比較がむずかしい。

というなことを感じながら実際に比較をおこなってみたわけだが、仮に自分がWAF製品のセールスエンジニアでお客さんに乗り換えをすすめるとなった場合どうやったらメリットを感じてもらえるんだろという問いには答えはでなさそうだった☹️