2010年9月24日7:00
連載の第4回目は、PCI DSSの要件の中でも注目されることの多い、要件6.6を取り上げる。
＜要件6.6_前篇＞
6.6は、インターネットなどを経由して一般公開されているWebアプリケーションを、既知の攻撃から保護するための要件である。公開するWebアプリケーションのみが対象で、内部向けののWebアプリケーションは含まない。
ここはPCI DSSの全体を通して、v1.2への更新で大きく変わった点である。v1.1では、年に1回のソースコードレビューか、Webアプリケーションファイアウォール（WAF）を導入するいずれかの管理策の二者択一を求めていた。また2008年6月30日まではWAFの導入は不要という内容もあり、解釈に迷うことも多かった。
v1.2では、Webアプリケーションの脆弱性検査かWAFの導入のいずれかと記載されている。この二者択一になってからは、一般的な企業の判断としては、WAFの導入を選択することはほとんどない。その理由は、脆弱性検査を、要件6.5や11.3などで行うためだ。例えば、6.5では、外部と内部、すべてのリリース前のWebアプリケーションに対し、OWASP Top 10に基づいて脆弱性検査を伴う開発プロセスを要求している。11.3では、外部と内部、Webアプリケーションに対し、年に1回以上または変更があった場合のアプリケーションレイヤーのペネトレーションテストを要求している。これらが実施されていれば、6.6の一方を満たす、つまりWAFの導入は不要なのだ。
要件を素直に解釈して、できるだけコストをかけないで準拠するとなると、こうした対応になる。要件6.5、11.3に対応すれば、6.6も達成できてしまう。6.6は形骸化しており、建て付け自体に矛盾があるといえる。ここはPCI DSSの次バージョンでの改善ポイントの一つになるだろう。
双方の特性を考えると、WAFと年に1度の脆弱性検査を比較すること自体がナンセンスという指摘もある。WAFはリアルタイムで脆弱性を検知、制御するシステムだ。もちろん、脆弱性が既知のものであれば、同じ結果を生むとする見方もあるが、SQLインジェクションなどは、亜種が非常に多い。これに対して、年に1度の検査では、その時点で既知の脆弱性しか検出できない。
亜種が出たとき、パターンファイルをアップデートしてWAFにより攻撃を止める、これは検査ではなし得ない機能である。結果的にWAFを導入した方が、間違いなくコントロールのレベルは上がる。
※本記事は「PCI DSS Version1.2徹底解説」の一部分をご紹介したものです。
