2010年9月24日7:10
＜要件6.6_後篇＞
v1.1のリリース当時、WAF導入に向けての課題はコストにあった。数年前までは、冗長化した構成で導入すると、最低でも1,000万円程度の導入コストが必要であり、要件6.6の解釈がよれてしまったことは否めない。しかし、現在ではWAF自体の導入コストも下がってきている。
また当初のWAFは、iMPERVAなどに代表されるゲートウェイ型が一般的で、導入によりネットワーク構成がより複雑になる懸念もあった。昨今のネットワークは多段構成により階層が深くなっている。ファイアウォール、ロードバランサ、ゲートウェイ型のアンチウィルスなど、これ以上、階層を重ねてしまうと、障害時の解析が困難を極める。運用面からWAFは避けたいとの声もあったことも事実である。
最近はWebサーバにモジュール型でインストールするタイプも出てきているため、その懸念も解消している。
ゲートウェイ型よりスムーズに導入でき、WAFも身近な存在になった。WAFの導入は、Gumblar攻撃対策などの機能をもつものもあり、PCI DSSに限らず確実にコントロールレベルを上げてくれる。低価格化したWAFも考慮の余地はある。ここは直近の変化だ。
なお、WAFに関してはスペックが明確に定義されていない。ここもよく質問を受けるところだが、要件の意図にしたがえば、要件6.5に示す10の脆弱性が検知できるものが望ましいだろう。PCI DSSの次バージョンでは、WAFのスペックを定義した上で、導入を進めるべしという方針が出ることを期待する。
なおASVによるインターネット経由のスキャニングサービスでは6.6（及び6.5、11.3）の要件を満たすことはできないので注意していただきたい。仮にそのスキャニングサービスにOWASP Top10の脆弱性の検知、カタログスペックとして載っていたとしても、クロスサイトスクリプティングやSQLインジェクションは、ユーザ認証のプロセスを経ないと検査の完全性は保証できない。この手のサービスの厄介なことは、カタログスペックで検査を行い、検査が不完全であったとしてもクリーンな結果が返ってくることである。
特にセション系の脆弱性はツールだけでは完全に発見できないため、手動の検査を加えることは避けられない。
Webアプリケーションが大量にある場合、すべて検査会社に依頼するのはコストが肥大化する可能性がある。そのため、検査の実施者は開発チームから独立性を実証できる人物であり、一定の力量を持ち合わせていれば社内のスタッフでも構わないとしている。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
●要件解釈の注意（v1.1は以下の2択だった）
－ソースコードレビュー
・ソースコードレビューは6.3項で常に実施する必要がある
－Web アプリケーションファイアウォール（WAF）の導入
●システム要求
－WAFの導入
・OWASPのトップ10のような脆弱性を抑止するファイアウォール
・パターンファイルのアップデートにより常に亜種を含む最新の攻撃に備えることができる
－Webアプリケーションの脆弱性検査
・要件11.3と同時に達成できるため効率的だが、WAFよりはセキュリティレベルは落ちる可能性が高い
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
※本記事は「PCI DSS Version1.2徹底解説」の一部分をご紹介したものです。
