SaaS型のWAFとは?(What is SaaS type WAF?) なぜSaaSなのか? (Why we choose SaaS) WAFが抱える問題(The problems of WAF) なぜ順調にユーザ数を増やしているのか? (Why it is going well so far?) どんなシステム構成か?(About system architectures) どんなWAFソフトウェアなのか?(About WAF SoZware) どのように運用しているのか?(About operaLons) 今後の展望(Future work)
first SaaS type Web ApplicaLon Firewall on the earth ( since 2009 ) Made in Japan 2014年2月現在、約450のウェブサイトを防御(ProtecLng about 450 web sites at Feb 2014 ) 順調にユーザに受け入れられている(Geang users) 「WAFを使うのは初めて」というユーザが8割以上(It is a first WAF experience for 80% of our customers) WAFが原因で利用を停止したユーザはほとんどいない(Almost no customers have stopped using this service because of this WAF service itself) ほとんどのユーザがブロックモード(攻撃と思われるリクエストは実際に遮断する)で 運用している(Almost all customers are using this WAF on ‘BLOCK MODE’)
system changes are required. Just change IP address to the one of WAF) インターネット上をウェブのトラフィックが遠回りする (The web traffic goes a long way round) ユーザが直接通信するサーバが本来のウェブサーバではなく、サービス運 営側のサーバになるという点で、CDNに似ている(It is similar to CDN) (より詳しくはウェブを参照のこと) (Google ‘SaaS WAF’ for more details)
is really suitable for the special Internet environment of Japan) 狭い国土(速いコミュニケーション)(Narrow country, high speed for communicaLons) 東京・大阪へのサーバリソースの集中(Many servers are located in Tokyo-‐ Osaka) ISP間のすばらしい連携(Good relaLonship between ISPs) SaaS型でウェブのトラフィックを遠回りさせても体感速度として問題がない (Latency is not high even when the web traffic goes long way round) トラフィックに対して従量課金されないサービスが多い (No extra charge on network traffic in many IaaS/VPS service in Japan)
our experience of web applicaLon development and operaLon) 全てをモニターする(Monitor all) 全てをコントロールする(Control all) 必要なときにすぐにソフトウェアアップデートを行う (Update the soZware immediately, on anyLme) シグネチャの追加(Add signatures) 機能の追加(Add funcLons) バグの修正(Fix bugs) 年間に100回程度のソフトウェアアップデート(100 updates/year) SaaSは「ソフトウェア」の良さをインターネットの時代に最大限に活かすサー ビス形態である (SaaS is the best way to use soZware)
using) ウェブサーバやOSの種類を問わない (Can be used with any Web Servers/OperaLon Systems) DNS、Firewall、SSLの設定のみ (Requires only DNS/Firewall/SSL seang changes) リスクゼロで本番環境でのテストが可能(hostsファイル) (Test on producLon environment using hosts file is almost no risk) 通常は1~2週間程度(Only 1 or 2 weeks to get started) 最短での実績は24時間(Min record: 24 hours) 簡単に導入できる=簡単にやめられる (Easy to get started = easy to stop using) ロックインしない(双方にとってのメリット)(No lock-‐in is good for us too) 短期間だけの利用が可能(Short term use is supported)
servers can be located anywhere on the Internet) 基本的にインターネット上であればどこでも可 クラウド上(EC2やAzure、IIJGIOなど)も、もちろん可 (Amazon EC2/Azure/IIJGIO etc) あちこちにウェブサーバが散らかっている場合でも可 (If each web servers are located on several different places, customer can use WAF on all servers)
evolving and changing) ソフトウェアを変化させる自由(Changing soZwares) ハードウェア(IaaS)を乗り換える自由(Changing hardwares) いつの間にか防御性能が上がっている (Become more accurate unnoLceably) より高性能で低価格のWAFサービスへ (To more accurate, low cost WAF service)
not work as expected in most situaLons) 検知精度(Accuracy problem) 必ず誤検知による正常通信の遮断が発生する (Blocks legal traffic, false posiLves, inevitable) 顧客とWAF提供側のパワーバランス (RelaLonship/Power balance between customers and service providers) WAFを誰がいつ運用するのか (Who operates WAF? And When? 24/365?) ウェブアプリケーションの知識 (Knowledge about Web ApplicaLons) ウェブアプリケーションセキュリティの知識(Knowledge about Web applicaLon Security) 顧客がやるべきではない(Customers don’t have both)
of IDS/IPS/SOC) 監視サービスは本当に必要か? (Do you really need a 24/365 monitoring service?) 夜中に「攻撃が来てるみたいです」と電話されて幸せか? (Are customers happy with midnight phone call?) やって欲しいのは監視ではなく防御 (What customers really need is 'protecLon' not 'monitoring')
WAFを「まともに動かす」ために必要とされる要素(Things required to handle WAF) 誤検知対策(Handling false alarms) 誤検知がなるべく起こらないようにする(Suppress false alarms as liQle as possible) 誤検知を発見する(Monitor/Detect false alarms) 誤検知が次に起こらないようにする(Do not repeat same false alarms) 「仕方ないのでWAFを切っちゃおう」はダメ (Giving up and “Ahhh, turn off WAF” is NG!) 基本的にWAFサービス側ですべて行う(Basically, we manage everything) 顧客の担当者に無理を押しつけない(Do not make customers do WAF related work) 「WAFが入っていることを忘れてた」と言われるのが理想 (If customer says “I forgot that WAF is here”, that is our goal)
低価格の実現(How we achieve low prices) そもそも低価格なWAFの実現を目的の一つにしている (Achieving low prices itself is one of our goals) 自社開発(Developed in house) IaaSの利用(Using IaaS services as pla;orm) シンプルな障害対策(Simple redundancy) 顧客との認識合わせ(Keep in touch with customers) 高サービスレベルを謳わない(Do not promise high service level like 99.9999..) まずは20点から80点に(20 points to 80 points) 無理しない(No overworks)
SaaSの利点を活かし、ソフトウェアの力を最大限に引き出す (Enpower the soZware by using the advantages of SaaS) 顧客固有の事象に対する柔軟かつ迅速な対応 (Apply changes/updates quickly for customer specific problems) シグネチャ部分がJavaソースコードにコンパイルされるので、ほぼどんな要求 にも応えられる (Almost all problems can be fixed because our WAF signatures/rules are compiled into Java source codes) エキスパートの仕事をスケールアウトさせる (Make experts knowledge scale out)
3 servers ) 2台はWAF( 2 servers for WAF ) 1台はMongoDBのクラスタの一部( 1 server for MongoDB arbiter) DNSラウンドロビンによるシンプルかつ安価な冗長化 (DNS roundrobin. Simple redundancy) 大口の顧客は専用(High traffic customers use dedicated server sets) 小口はマルチテナント(Other customers use shared server sets) 現在、約100台のサーバ(100 servers) 一部のサーバのみ物理マシン、多くのサーバは仮想マシン (Almost all servers are virtual machines)
2002) Java製(100% pure Java) フルスクラッチで開発(WriQen from scratch) リバースプロキシサーバとしての機能(Has own reverse proxy server funcLonality) WAFとしての機能(Has own WAF engine) ネットワーク上で独立して動作(Runs as standalone server applicaLon) 元々は自社のウェブアプリケーションを保護するために内製 (Originally developed to protect the websites of our own) PHP/Apache/OpenSSLの脆弱性など (To stop aQacks against PHP/Apache/OpenSSL)
自身がSSLサーバとして稼働 (Runs as an SSL/TLS server) 暗号化された通信の中身もチェックする (Decrypt SSL/TLS traffic) 秘密鍵とSSL証明書をWAF側にインストールする (CerLficates/Keys are also need to be installed on WAF)
architecture) サーバのスペックに合わせ、数百~数千スレッド (some hundreds to some thousand threads) オンデマンドでスケールアウトできる (It can be scaled out on demand) 高負荷対応を謳う専用アプライアンスは本当に必要なのか? (Do customers really need *GB promised WAF appliance?)
2009年スタート時にはシンプルなシグネチャモデル Snortを参考にした (Simple Snort-‐like signature model) エンジン部とシグネチャ部がきれいに分かれている (Engine and signatures are separated) 現在はより高精度な閾値モデルやベイジアンネットワークなどを使った検知 エンジンへと進化 (Currently, have changed to more accurate models with Bayesian Networks, Threshold models)
‘alert’ then die! 単純だがメリットも数多くある(Too simple, but have some advantages) 挙動が明確(Clear) パフォーマンス一定(比較的速い)(Performance: stable/fast enough) 人間がメンテナンスしやすい(Maintainable/Human readable) 最大のデメリット(Disadvantages) 検知精度は低い(誤検知が多い)(High false posiLve rate)
(Inc/Dec scores on each signature matching) 最終的に閾値を超えていたら攻撃とみなす (Treated as an aQack when total score exceeds the certain threshold) 検知精度↑(Low false posiLves : GOOD) メンテナンス性↓(Hard to change/maintenance : BAD) チューニング作業中に違和感あり UNIONで5点加算(ルール1)(Example rule1: score +5 on 'UNION') SELECTで5点加算(ルール2)(Example rule 2: score +5 on 'SELECT') UNIONとSELECT両方ある場合は?10点でいいのか? (Example rule 3: score +20 on 'UNION and SELECT both') UNIONもSELECTもある場合は20点加算(ルール3) 組み合わせが増えすぎる (Too complicated / Too many rules)
+5 on 'Alert') UNIONで5点加算(Score +5 on 'UNION') “Alert UNION”で10点?(Score +10 on 'Alert UNION'?) 「XSS」「SQLi」など複数の属性ごとに計算すべき (Should disLnct XSS and SQLi, as different classes)
24/365) 監視ではなく防御(ProtecLon, not Monitoring) 最小限のコストで最大限の効果(Maximum effect, low cost) 将来的には完璧なWAFを目標に(Want to be a perfect WAF, someday) サービス運用側も健全な状態に(We should not overwork)