SiteGuardの

開発秘話

はじめに

2005年、我々は「SiteGuard」の初期バージョンを開発しました。

この年は、大手ネットサービス業者など多くの著名なWebサイトが不正アクセスの被害を受け、世の中で「SQLインジェクション」という言葉が大きく報道された年でもあります。

当時、我々は新製品の開発を模索していました。既存の製品やソリューションでは対応できない脅威の出現を見据え、対象とするシステムや製品分野を選定するべく、継続的に情報収集や検討を重ねていたのです。

検討にあたり、自社内にこだわらず知見を求めたいと考え、かねてより懇意にしていた株式会社ラック社（以下、ラック社）に協力を打診したところ、快く賛同頂くことができました。以降、企画段階から現在の継続的な機能強化・改善にいたるまで、ラック社には大きな技術協力を頂くことになります。心強いパートナを得て、本格的に製品開発プロジェクトがスタートしたのです。

プロジェクトには様々な立場、職種のメンバが関わりました。我々からは企画担当や開発、SEが参加しました。ラック社からは、企画担当をはじめ、各種セキュリティサービスのコンサルタントや エンジニアなど、多様な立場の方々にご協力頂きました。セキュリティインシデントの傾向、既存の製品・ソリューションの普及動向、今後想定される脅威、など様々な観点から情報収集、検討を重ねていったのです。

検討を進める中で徐々に話題の中心となっていったのが、Webアプリケーションを狙った攻撃です。前年の2004年に中国で「SQLインジェクション」を用いた攻撃用ツールが出回ったこともあり、Webアプリケーションを狙った攻撃は増加傾向にありました。今でこそ認知されている「SQLインジェクション」も当時はまだ一般的ではありませんでしたが、近い将来、大きな脅威になると予測できました。

プロジェクトの推進にあたり、ラック社の知見は大変貴重なものでした。同社では、他社に先駆けてWebアプリケーション検査サービスを提供してきた実績から、脆弱なWebサイト がとても多い実情にいち早く気づいていたのです。毎年定期検査をするWebサイトで「前年度報告された脆弱性と同じ脆弱性が次年度の検査でも報告される」といったケースも多々あったようです。改修方法の不備やサービス運営上の事情など、様々な理由が関係していたようですが、少なくともこの事実は、Webアプリケーションの改修が簡単でないことを裏付けるものだと考えられました。
Webを介して様々なサービスが展開される将来を見据えた時、Webサイトのセキュリティは今以上に重要となる。誰もが安心して利用できるWebサイトが求められている。自然と我々の焦点はWebサイトの防御に向かい、新しいWAF製品を開発することになりました。

実は、当時から既にWAFというものは存在していました。開発元が海外のアプライアンス製品が中心だったのですが、様々な理由から、あまり普及しているとは言えない状況でした。某社のWAF製品を扱っていたラック社自身も、いろいろと課題を感じていたようです。

そこで我々は、設計に先立ち、当時WAFの普及を妨げていた原因の調査・分析を行い、克服すべき課題として二つのポイントに着目しました。

一つは製品価格です。

既存のWAF製品は、作業費を含めると1千万円ほどになる案件もざらといった、大変高価なものだったのです。

ニーズに合っても予算に合わないケースも多く、導入の大きなハードルとなっていました。

もう一つは防御する仕組みです。

当時、既存のWAF製品では「ホワイトリスト」による防御機能が一般的でした。ホワイトリストは未知の攻撃にも対応できるといったメリットがある反面、設定が難しく、導入・運用負荷が高いという側面があります。

というのも、ホワイトリストによる防御機能は、アプリケーションが生成する通信すべてを正しく登録することで、はじめて有効に機能します。

逆に言えば、効果を発揮させるには、正常通信すべてを漏れなくルールとして定義しなければなりません。 一般的な（ネットワーク）ファイアウォールにおいては有効な仕組みなのですが、頻繁に修正されるWebコンテンツを保護するWAFにとっては、活用するのが難しい仕組みだと考えていました。

ホワイトリスト型のWAFは、導入効果はありつつも大変で、多くの技術者にとって手に負えないシロモノだったのです。

このような状況を踏まえ、我々は「安価で分かり易いWAF」を目指すことにしました。具体的には、IDS/IPSやウイルス対策の手法として一般化していた「シグネチャ（ブラックリスト）」ベースの検査手法を採用することで、個別のルール作成を不要とし、導入の頻雑さといった課題を克服することを目標としたのです。これにより、導入が楽になるだけでなく、シグネチャを自動更新にすることで、運用負荷も大幅に軽減することができます。
ここで重要となるのがシグネチャの品質です。「扱うのは簡単でも防御性能は低い」ということでは意味がありません。事実、そのようなWAF製品も存在していました。この点において、ラック社とのパートナシップが大きな意味を持ちます。国内最大規模で監視サービスを提供する同社は、実際に発生している攻撃やインシデントに関する情報の保有量では他に類をみません。疑似攻撃とも言える検査サービスを提供していることもあり、攻撃手法に関しては最先端の技術力を有しています。我々の開発するWAF製品では、当時課題とされていたシグネチャベースの防御性能を、逆に強みにできると確信できたのです。

「SiteGuard」の特徴は、一言で言えば「シンプルで使いやすいシグネチャ型のWAF」です。実は、それ以外にも、（シンプルさを伝えるため積極的には紹介していないのですが）既存のWAF製品の課題や脅威の動向を考慮した様々な工夫を施しています。ここで、参考までに三つほどご紹介します。

一つ目は、カスタムシグネチャの作成機能です。

基本的に「SiteGuard」はシグネチャベースで利用頂くことを想定しているのですが、要件によっては独自のポリシーを作成する必要もありうると考えました。例えば、「特定のURLは検査対象外としたい」、「特定のパラメータのみはホワイトリストで守りたい」、といったケースです。既存のWAF製品には独自ポリシーのカスタマイズ性が低い製品が多く、それが理由でこのような要件に対応できない場合もあったのです。そこで、シグネチャによって難しい設定を不要とする一方で、個別要件に対しては柔軟なルールも設定頂けるよう、独自ポリシーの作成機能にも高いカスタマイズ性を実装しました。「SiteGuard」では、正規表現を用いて大変細かなポリシー（カスタムシグネチャ）を作成できるようになっています。標準のシグネチャに加え、お客様環境に合わせたカスタムシグネチャを併用することで、セキュリティレベルをより向上させることができます。

二つ目は、日本語環境特有の攻撃への対応です。

既存のWAF製品は、開発元が海外であるせいか、日本語環境に特有の攻撃（マルチバイト文字を悪用した攻撃など）への考慮が足りない製品がありました。日本のみで流行している攻撃への対応についても同様です。「SiteGuard」は純国産の製品であり、日本のインターネット文化を熟知したスタッフによって開発されているため、このような心配はありません。

最後は、防御システムを回避する新しい手法への継続的かつ迅速な対応です。

例として、2008年10月に報告された「無効な%を含む攻撃」への対応があります。この手法は、SQLインジェクション攻撃の文字列に無効な%を含めることで、IDS/IPS/WAFなどの防御システムによる検知を回避するものです。当時、既存の様々な防御システムがこの手法により回避されてしまうことが判明し、大きな問題となりました。この問題に関し、我々は早急に「SiteGuard」の機能改善を実施し、いち早く対処することができました。

攻撃手法は刻々と変化し、既存の仕組みでは対応できない脅威が常に発生してしまう可能性があります。我々は継続的な情報収集や研究を通じて、日々迅速な対応に努めています。
このように、ユーザにはあまり意識頂く必要のない機能や取り組みもあるのですが、「SiteGuard」には様々な工夫が施されているのです。

最後に

初期バージョン以降、多くのお客様からもご意見を頂きながら、より「使える」製品を目指し、継続的な開発に取り組んでいます。また、シグネチャは最新の攻撃に対応するべく随時更新されており、「SiteGuard」の防御性能は第三者の調査でも高い評価を得ています。
増え続けるWebサイトのセキュリティ対策に継続的に貢献するべく、「日本発の技術」で我々は今後も努力していきたいと考えています。

　「SiteGuard」に関する詳細情報はこちらから。