技術者ブログ

はじめに

私は「シグネチャ依存型のWAFは避けよう」という記事(以下、前記事)において、以下の内容を示しました。

• WAFの仕事の本質は「分類」である
• WAFというのは、ソフトウェアが分類を行う場面である
• ソフトウェアが分類する＝AI/データサイエンス分野の技術である
• シグネチャは10年以上前の古い分類技術で性能が低く、2020年の時点で使うべきでない

上記だけ眺めれば、WAFにおいてシグネチャを使っても良い事はなさそうに見えます。しかし実際には、シグネチャ(あるいはルール)だけを使っている「シグネチャ依存型」のWAFが今もたくさん存在しています。つまり、何かしら、シグネチャが生き残っている理由があるはずです。

今回は、WAFにおけるシグネチャの利点・欠点について、より掘り下げて行きたいと思います。なお、本文内で何度か登場する「誤検知」は、「本来止めるべきでない正常な通信を、誤って攻撃と分類してしまった」というケース、つまり偽陽性の意味で使っています。

まずは欠点の方からです。

欠点1：分類性能が低い

シグネチャは多くの場合正規表現で定義され、データに対して「マッチするか・しないか」の二者択一を行います。前記事にも書きましたが、データサイエンスの分野ではこれは「決定株」、あるいは非常に深さが浅い「決定木」として知られています。

この2つは非常に単純で原始的なアルゴリズムであり、分類の性能は極端に低いです。この点が、とにかくシグネチャの最大の欠点です。後述しますがシグネチャには意外と良いところもあります。「良いところ」を読んでいるとシグネチャが好きになってしまうかもしれませんので、先にここで強調しておきます。シグネチャは、WAFにおける最も重要なタスクである分類がそもそも苦手です。

シグネチャ依存型のWAFは分類性能が低いので、すぐに次のような問題を引き起こします。

問題その1：正常通信を止めてしまう

誤検知で正常通信が止まってしまう、という事が頻繁に起こります。これによって

1. その通信が本来行おうとしていたビジネスに支障が出る
2. WAFが誤って止めてしまったこと(誤検知の発生)を認識するための人的コストがかかる
3. WAFが次は同じような通信で誤検知しないように調整するための人的コストがかかる

という3つの問題が生じます。上記が一日に何回も何十回も出てしまうような酷い現場もあるかもしれません。

さてこの1〜3の問題のうち、3に注目してみます。次に同じような通信が発生しても、今度は誤って止めてしまわないようにしましょう。具体的にはどうすればよいでしょうか。そう、その問題を引き起こしたシグネチャを無効にするのです(※1)。すると、次の問題が生じてきます。

問題その2：攻撃が止まらないWAFになる

シグネチャ依存型WAFが持つ大きな問題として、誤検知に対応するためにシグネチャをどんどん無効にせざるを得ないというものがあります。その結果、結局攻撃を止めてくれないWAFになります。

極端なケースだと、WAFは導入されているものの、頻繁な誤検知対応への運用負荷を理由にやむなく、ログを取るだけで実際には通信を止めないモードにして動かしているようなこともあります。

このように、シグネチャのような分類性能が低い技術でWAFを作ってしまうと、

• 攻撃はきちんと止めるが、正常通信もかなり止めてしまうWAF
• 正常通信は止めないが、攻撃もあまり止めてくれないWAF

のどちらかになってしまう、という悪い「二極化」が起こります。もちろん理想は「攻撃はきちんと止め、正常通信は止めない」状態です。（わざわざ確認するまでもありませんが...）

余談になりますが、我々が簡単にクラウド型のWAFを調査した印象だと、初期の味付けとして、国産のWAFは上のタイプが多く、海外のWAFは下のものが多いように感じました。

欠点2：回避されやすい

引き続きシグネチャの悪い点を見ていきます。2つめの欠点は、「回避されやすい」というものです。

シグネチャは正規表現等によって「きっちり」定義されているため、逆に言えば「一箇所でもマッチングをすり抜ければ、シグネチャそのものを回避できる」ことになります。

辛抱強い攻撃者であれば、シグネチャを回避しつつ攻撃を成功させることが出来る場合が少なくありません。また、一度回避する方法を見つけてしまえば、以後その部分に気をつけることで、シグネチャに見つかること無く様々な攻撃を行うことができます。これは特にSQLインジェクションやコマンドインジェクションにおいてよく見られる現象です。

シグネチャによる防御は回避されやすいため、

• 腕の立つ、危険度の高い攻撃者による攻撃は止められない
• 見境なくどこにでも攻撃してくるようなスクリプトキディの攻撃は止める

ような傾向になります。発見した攻撃の件数では後者が多いために「WAFが役に立っている」ように見えますが、実は前者の危険な攻撃はすり抜けているかもしれません。

欠点3：誤検知が起こった後、うまくカバーする方法がない

先述した「問題その2」に書いたように、WAFの運用では「誤検知が起こった後に、どう調整するか」というなかなか難しい問題が待ち構えています。シグネチャの場合、基本的には「そのシグネチャを無効にする」という選択しか残されていないと言えるでしょう(※2)。これは非常につらい欠点です。

欠点4：処理が重くなる

シグネチャは単体では比較的処理が速い・軽いものですが、WAFシステム全体では百個あるいはそれ以上のシグネチャを直列で処理しなければならないため、全体としては重くなる傾向があります。そのため、シグネチャによって多種多様な攻撃にまんべんなく対応することが難しく、シグネチャの取捨選択を迫られてしまうケースがあります。

基本的にはCPUリソースを消費するので、速い(=高価な)ハードウェアを使うことが可能ならば、それで解決できる場合があります。

欠点5：管理・運用が難しい場合がある

シグネチャ依存型WAFの中には、ユーザが管理画面でそれぞれのシグネチャの「有効・無効」を選択できるものがあります。「できる」ということは自由度があるということなので良い事に見えますが、反面、「どのシグネチャを有効にして、どのシグネチャを無効にすべきか？」というとても難しい「WAFの管理・運用」をユーザ側がやらなければいけない、という事になりかねません。

この欠点は、先述した「欠点その3」とも関連があります。いざ誤検知が起こった際にシグネチャを無効にするのがユーザ側の担当者である場合、「果たして自分の責任でシグネチャを無効にしてしまってよいのか？」という、非常に難しい状況にぶつかることになります。

欠点6：ゼロデイ防御が苦手である

欠点1で説明したように、シグネチャは分類が苦手で誤検知を起こしやすいため、特に新しい脆弱性に対してシグネチャを新規に作成して追加する場合、「必要最小限の箇所のみにマッチするシグネチャ」が作られやすいです。

例えばあるミドルウェアにおいて、HTTPヘッダの「Content-Type」フィールドの処理に脆弱性が発見されたとします。この場合、ほとんどのシグネチャ依存型WAFでは、「Content-Typeの値が○☓だったら止める」というシグネチャを投入します。そして、そのシグネチャは他のヘッダの内容については一切検知を行いません。

ところが、後になり、実は別のヘッダにも同様の脆弱性があった、となることがあります。この場合、また後追いでそこにシグネチャを追加していくでしょう。このようにシグネチャはゼロデイ防御が苦手な傾向があるのです。

ここまでシグネチャの欠点を見てきました。目に見えて問題になりやすいのは欠点1と3です。欠点5については、基本的に全部マネージドでやってくれて、ユーザが個別のシグネチャの有効・無効に触らずに済ませられるようなサービスであれば、親切で使いやすいでしょう。

さて続いて、利点について見ていきます。

利点1：理解できる

データサイエンス/AIの分野でよく問題になるのが、誤検知などの予期せぬ挙動が起こった際に「なぜソフトウェア(モデル)はそのように判断したのか？」の理由が分からない場合があるという事です。これは分類性能の良し悪しとは別の軸の問題です(※3)。人には問題が起こった場合にその理由を知りたいという強い欲求があります。

「このシグネチャの正規表現が、リクエストの中の文字列のこの部分に、意図せずマッチしてしまって...」と説明されれば、理由が明らかになりスッキリできます。

一方、仮にシグネチャ型ではない完全なAI型のようなWAFがあったとします。誤検知が起こった後に「コンピュータがどうやら攻撃と判断したようです。その理由は担当者にもよくわからないのですが...」などと説明したら、スッキリされるどころか怒られてしまうでしょう。

シグネチャは単純で原始的であるが故に人間にもほぼ完全に理解可能なので、「理解できる・説明できる」という利点があります。

利点2：簡単な分類はできる

これはあまり「利点」ではないかもしれませんが、WAFにおけるシグネチャの役立ち方としての大きなポイントの1つなのでここに記します。

私はしつこく「WAFの仕事は分類だ」と書いていますが、このWAFが行う分類には「簡単な分類」から「難しい分類」まで、さまざまなケースがあります。シグネチャは、簡単な分類はそつなく行うことができます。

ウェブサーバに来る攻撃の中には分類が簡単なものもあります。そのような攻撃は、シグネチャで十分に対応できます。

利点3：手軽に作れる

一般的に「分類するソフトウェア」を作るためにはデータサイエンスの技術が必要になりますが、シグネチャくらい原始的ならば、誰でも(※4)作ることができます。また、データサイエンスでは多くの場合、まず最初にそれなりの量のデータが必要になりますが、シグネチャはデータが殆どあるいは全く無い状態からでも作り出すことができます。

この手軽さは分類性能の低さの裏返しではありますが、やはり利点と言ってよいでしょう。

利点4：単体で扱える

シグネチャによる攻撃の検知は複数のシグネチャを並べ、順番に処理していく形で行います。このとき、それぞれのシグネチャはお互いに無関係、粗結合です。そのため「あるシグネチャのみ削除する」あるいは「新しいシグネチャを1つ追加する」ようなことが行えます。そしてその際に「このシグネチャを追加したら、別のシグネチャの挙動に予期せぬ影響が出ないだろうか...」と心配する必要がありません(※5)。

このことから、例えば「新しく知られた攻撃に対し、緊急に素早く対応したい」という場面では、本番環境のシステムに予期せぬ複雑な副作用を与えることなく新しいシグネチャを投入(単純に追加)できるという利点があります。もちろん、そのシグネチャ自体が誤検知を起こす可能性はありますが、これはあくまで予想できる範囲内の不具合ですし、最悪の場合でもそのシグネチャを無効にするだけでシステムを元の状態に戻すことができます。

それぞれのシグネチャが独立して単体で扱えるため、管理画面でそれぞれのシグネチャの「有効・無効」を制御することが可能になります。ただし、この事は利点にもなりえますが、欠点5に書いたように運用の負担が伴ってしまって欠点となる場合もあります。

ここまで、シグネチャの利点を4つ挙げました。シグネチャにも良いところがあることがわかります。ある意味、シグネチャは、データを分類するためのアルゴリズムの中で、「シンプルさ」に極端に寄せた性質のものであると言えます。そのため、シンプルさが活きる点では強いです。

Scutumはどうなの？

前記事でも書いたように、Scutumは過去シグネチャ依存型であり、先述したようなシグネチャの欠点に悩まされました。そしてそれを受け、今では分類の技術の中核にベイジアンネットワークを使っています。ベイジアンネットワークはシグネチャの欠点をほぼすべて克服しています。ここで簡単に内容を説明します。

シグネチャの欠点1：「分類性能が低い」について

ベイジアンネットワークはより高度なアルゴリズムであり、分類性能はシグネチャに比べとても高く、この欠点は存在しません。そのため理想的なWAFである「攻撃はきちんと止め、正常通信は止めない」状態を目指すことができます。

シグネチャの欠点2：「回避されやすい」について

ベイジアンネットワークは多くの視点、手がかりから総合的に判断して最終的に確率を弾き出します。そのため、1つの点だけで攻撃者がこちらの観測をかいくぐったとしても、少しだけ確率が低くなってしまうだけで済みます。そして結果として、他の要素から攻撃であると判断することができます。そのため、この欠点も持ちません。

シグネチャの欠点3：「誤検知が起こった後、うまくカバーする方法がない」について

ベイジアンネットワークでは色々な視点・手がかりについて、それぞれを「使う」「使わない」「値を決め打ちしてしまう」ように個別に選択することができます。

そのため、誤検知が起こった後の調整では、その誤検知を引き起こした要素についてのみ「情報として使わない」あるいは「値を決め打ちする」ように調整することで、弾き出される確率に与える影響を最小に留めながら、次は誤検知が起こらないようにすることができます。この調整のしやすさは、シグネチャはもとより他の高度なデータサイエンスのアルゴリズムにも殆ど見られない、ベイジアンネットワーク独自の大きな利点の1つです。

シグネチャの欠点4：「処理が重くなる」について

ベイジアンネットワークも処理はそこそこ重いです。しかしScutumでは計算結果のキャッシュなどを使い、エンジニアリングによって問題を回避しています。この点については、特にベイジアンネットワークがシグネチャよりも優れているということはないです。

シグネチャの欠点5：「管理・運用が難しい場合がある」について

ベイジアンネットワークや他の高度なデータサイエンスのアルゴリズムでは、シグネチャのように分類に関する細かな設定をユーザ側に開示することはほぼありません。基本的に「おまかせ」になります。そのため、ユーザの立場からは自由度は低くなる一方で、管理・運用の手間は殆どかからなくなります。

シグネチャの欠点6：「ゼロデイ防御が苦手である」について

ベイジアンネットワークは分類性能が高く、誤検知をそれほど恐れる必要がありません。そのため、最初から「万が一、別のヘッダフィールドなどに同様の脆弱性が見つかっても、止まるようにしておく」という考えで、リクエスト内の広い範囲を監視対象としてカバーすることができます。Scutumは特にこれを上手く実現しており、Struts2で問題となったOGNLインジェクションをはじめ、多くの脆弱性について、他のWAFに比べリクエスト内の広い範囲で監視を行っています。そのため、ゼロデイの脆弱性についても止めることができる場合がかなりあります。

このように、ベイジアンネットワークはシグネチャの欠点を完全に逆にしたような利点を持っているわけです(欠点4を除く)。Scutumで採用しているのは、まさにこれが理由です。

一方でシグネチャの利点2、3、4については、これらがベイジアンネットワークを使うよりも良い場合があります。そのような場面では、Scutumでは今でもシグネチャを併用しています(※6)。例えば、緊急の対応としてまずはシグネチャを投入し、2〜3日の時間をかけてそれをベイジアンネットワーク側に組み込んで、その後シグネチャは廃止する、といったオペレーションを行うことがあります。このようにすることでシグネチャの身軽さを活かした緊急対応が可能となり、最初の数日は誤検知の可能性がある程度存在するものの、数日後からはベイジアンネットワーク側に切り替わるので誤検知の可能性を下げることができるようになります。

まとめ

今回はWAFにおけるシグネチャの利点・欠点について説明しました。シグネチャは利点も多いのですが、欠点がどれもかなり深刻なものであり、多くの利点を全て打ち消していると思います。10〜15年以上前の常識である「WAFといえばシグネチャ」という考えは、今の時代にはそぐわないことがわかります。

今回のエントリでは「2020年にもなって、いまだにシグネチャ依存型のWAFが多いのは何故か？」というところまではたどり着けませんでした。これについては、また後日別のエントリにまとめたいと思います。

※1：問題を起こしたURLやパラメータのみについて無効にするなど、影響範囲が狭く済むようにすることが多いかとは思いますが...

※2：原理的には、シグネチャそのもの(正規表現の中身など)を微調整・変更することで改善することができるはずですが、多くの現実の場面ではシグネチャそのものを変更することは行われないのではないかと思います。かなりの金額を支払っているようなエンタープライズ向けのWAFサービスであれば、やってくれることもあるかと思います。

※3：別の軸と書きましたが、分類性能が高いアルゴリズムになるほど人が理解できなくなる、という傾向が見られます。

※4：正規表現を理解できるくらいのレベルのエンジニアをイメージしています。つまり、そのへんに沢山います。

※5：一方、シグネチャよりも分類性能の高い、データサイエンスの「モデル」と呼ばれるようなソフトウェア(例えば、機械学習で生成されるようなもの)では、シグネチャでできるような「個別の追加や削除」といった概念が存在しない場合が多いです。

※6：Scutumではベイジアンネットワークにこだわっているわけではありません。より良いWAFを実現するために最適な技術を貪欲に使っていきます。