PCIDSS要件6.6、コードレビューとWAF導入選択の留意事項

●PCIDSSとは？

PCIDSSは、Payment Card Industry Security Standardsの略称で、国際カードブランド5社が共同で策定した、クレジットカード業界のセキュリティ標準である。この基準と、それを取り巻くフレームワークは、これも国際カードブランド5社が共同で設立した、PCISSC（Payment Card Industry Security Standards Council）によって運用、管理されている。ISMSやQMS、ITIL、もしくは業界に特化した様々な基準やマネジメントシステムが存在するが、その中でもPCIDSSはより実装に近い部分について、具体的に書かれていることが特徴である。

Payment Card Industry Security Standards Council
https://www.pcisecuritystandards.org/
Download the PCI DSS PCI Security Standards Council
（ライセンス条項に同意する必要あり）
https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm
Supporting Documents ? PCI Security Standards Council
（各種手順書や補足事項）
https://www.pcisecuritystandards.org/tech/supporting_documents.htm

●アメリカと日本の対応状況

PCIDSSが最も積極的に展開されている国は、アメリカであるといえる。PCIDSSが策定されるきっかけとなったのが、アメリカでの大規模なカード情報漏えい事故だったことも理由として挙げられるかもしれないが、訴訟大国、契約社会などと言われるような、アメリカの文化が普及の速さに拍車をかけていると考えられる。これに比べて日本では、アメリカのような急速な普及ではないものの、ここ1年程で認知度は非常に高まっており、積極的にセキュリティ施策を推進している企業は、クレジットカード業界に限らず、PCIDSSの情報収集や自社への適用を実施している。

また、クレジットカード加盟店から「これは義務なのか？」という質問を筆者はよく受けるが、PCISSCはカード会員データの安全性を高めるための基準やフレームワークを提供する組織であって、加盟店に直接準拠を義務付ける、もしくは強制するような組織ではない。

加盟店に対してどのような要求、依頼をするかは、加盟店契約を結ぶカード会社である。その要求や依頼の内容は、カード会社や加盟店によって異なる。例えば加盟店の、年間、月次の取引の量や、漏えい、カード情報危殆の有無などにもよってどの程度要求されるかは異なる。ただし、PCISSCを設立したのは、他ならない国際カードブランドであるため、PCIDSSで求められている要求事項を満たす必要がある、という基本的な部分は変わらない。

カードブランド、カード会社によって違うのは、その確認をどこまで、どのように行わなければならないかである。その手続きは、各国際カードブランドによるカード会員データ保護のためのプログラムで示されている。各ブランドのプログラムについては、下記リンクを参照していただきたい。

American Express ? Data Security Operation Policy(DSOP)
https://www209.americanexpress.com/merchant/singlevoice/dsw/FrontServlet?request_type=dsw&pg_nm=home&ln=ja&frm=JP
JCB ? JCB Data Security Program
http://www.jcb-global.com/pci/index.html
MasterCard ? Site Data Protection(SDP)
http://www.mastercard.com/jp/merchant/jp/security/what_can_do/SDP/merchant/index.html
Visa International ? Account Information Security(AIS)
http://www.visa-asia.com/ap/jp/merchants/riskmgmt/ais.shtml

PCISSCはあくまで基準とフレームワークを運用、管理しているだけで、加盟店やサービスプロバイダのPCIDSS準拠状況を把握しているわけではない。ただし、PCIDSS準拠の確認を行うために認定されたQSA企業（Qualified Security Assessor）の数である程度の状況を推測できる。

現在アメリカで調査サービスを提供している企業はおよそ80社存在するが、日本において、日本語で調査サービスを提供できるQSAは10社ほどである。（ただしオフィスが日本にあるとは限らない）ただし、当初は、日本向けに日本語で提供できるQSA企業はたった2社程度であったため、当時と比較すると日本においても広まりつつあることがわかる。

kPCISSC ? QSA List
https://www.pcisecuritystandards.org/resources/qualified_security_assessors.htm

●PCIDSS要件6.6におけるWAF導入のポイント

PCIDSSには12の要件が存在するが、その中にはWAF（Web Application Firewall）に関して、要件6.6に記載されている。要件6.6は、2008年6月30日まではベストプラクティスであるとされており、2008年7月以降は必須要件となる。本要件では、Webに面したアプリケーションに対して、アプリケーションコードレビューを行って脆弱性を修正するか、WAFを導入することが求められている。コードレビューとWAF導入は「or」であり、どちらかを実施すれば良いとされている。実際にどちらを実施するかは、システム更改のタイミングや変更による影響範囲、導入時および長期的な運用コストを考え、より適切な方法を選択することが望ましい。選択の際は、以下の点を考慮していただきたい。

PCIDSSにおいては、コードレビューは、専門的な組織によって定期的に実施され、その評価結果を受けて必要に応じて修正が行われること、その後、コードレビューを再度行って修正が適切に行われたことを確認するプロセスまで必要とされている。これは個別のプロセスとして考えるのではなく、開発プロセスに組み込み、商用環境への導入前に、脆弱性を徹底的に排除できるよう運用するものと考えると良いだろう。このため、新規に開発を開始する際や、システムの大きな更改がある際には、同時に開発プロセスにコードレビュープロセスを組み込むのが最適だろう。また、メリットとしては、商用環境に直接影響を与えず、開発環境でこの対策を行えることが挙げられる。ただし、コスト面は軽視できないだろう。コードレビューの手法は、手動、ツールによる実施、また、内部組織、外部組織による実施、など、様々な方法が存在するが、その体制を整備すること、場合によってはレビューを自動化するツールの購入、もしくはコードレビューを提供する専門企業のソリューションなどが必要となるためである。

WAFは、導入してしまえば、アプリケーション自体に変更を加えることなく、新たな脆弱性に迅速に対応できることから、既に商用環境で運用されているアプリケーションで、アプリケーションコードの修正が容易ではない場合、コードレビューよりもWAFが適切と考えられる。当然ながら、WAFは、Webアプリケーションの他に、同ネットワーク内のすべてのコンポーネント、正規のエンドユーザにさえ影響を与えるため、導入時や設定変更時には十分な注意が必要だ。つまり、False Positiveを起こしてしまっては、エンドユーザの正しい利用を阻害することになってしまい、セキュリティを考える上で最重要事項である「可用性」が損なわれてしまい、本末転倒である。しかし、それを恐れて、遮断すべきものさえ遮断を行わず、False Negativeが起きてしまう、つまり、WAFを導入しても結局攻撃を通過させてしまう、といったことも避けなければならない。導入後は、この2つのバランスの難しさに直面するだろう。

WAFに関して、要件6.6には導入が必須となることのみ記載されているが、2008年4月15日に、「要件6.6コードの見直しとアプリケーションファイアウォールの明確化」として補足情報が追加で公開されている。この文書には、コードレビューとWAF導入、2つのうちどちらかを選択する際の留意事項が記載されている。

概要としては、WAFのフェイルオープンやバイパスモードの使用時にはあらかじめ手順や基準を定め、長期間これらのモードを使用しないこと、WAFとWebアプリケーション間の影響を評価する必要があること、適切な変更管理や監視の必要性などが挙げられている。また、実際に搭載しているWAFの機能として、OWASPのトップ10脆弱性への対応、ホワイトリスト方式とブラックリスト方式両方の実装、WAF自身に対する脅威への対応、SSL/TLSターミネーションの実装などが挙げられている。このように、導入することだけではなく、運用にあたって必要となる事項や、WAFが備えているべき機能についても具体的に記載されているので、是非ご一読いただきたい。

PCISSC 補足情報
要件6.6 コードの見直しとアプリケーションファイアウォールの明確化
https://www.pcisecuritystandards.org/pdfs/japanese_infosupp_6_6_applicationfirewalls_codereviews.pdf

●WAFの導入事例

様々なWAFの導入事例があるが、積極的にセキュリティ施策を進めている企業では、多くの場合、パッチ適用プロセスや脆弱性診断の運用との組み合わせでWAFの運用を行っている。ベンダから提供される情報や、定期的に行われている脆弱性診断で、OSやアプリケーションの脆弱性が顕在化する。これらを修正するためのネットワークやシステムの変更には、その対象のみならず、周囲の環境への影響もあることから、必ずしも迅速に問題を是正することができない。このような時、WAFを使用して該当する脆弱性に対する対策を行い、パッチやアプリケーションコードの修正を行う間の暫定的対策とする。つまり、パッチ適用や、脆弱性診断の結果を受けてのアプリケーションの修正など、根本的な対策を行うのにかかる間の暫定的対策としてWAFを運用している事が多い。

WAFを導入するだけで、Webアプリケーションのセキュリティ対策が万全であるとは言えない。つまり、WAFを導入し、ゲートウェイでWebアプリケーションを保護することと、Webアプリケーション自体に存在する脆弱性を修正してWebアプリケーションを保護するということは、片方の対策を実施することで万全なものではなく、互いに補い合う対策なのである。

現在WAFの必要性が各所で騒がれているが、まずは自社システムの形態や運用を見つめなおす必要がある。そこで、自社システムに合った製品を導入、運用することで、より効果が高くなるはずだ。つまり、選定される際は、WAF自身の持つ機能だけでなく、自社システムの運用の中にどう組み込むかといった、運用面での適合性も合わせて検討されることをお勧めする。

【執筆：NTTデータ・セキュリティコンサルティング本部 PCI推進室　川島祐樹】

【関連記事】
WAF導入の手引き
https://www.netsecurity.ne.jp/3_11827.html
PCIDSS対策研究所
https://www.netsecurity.ne.jp/pcidss/

【関連リンク】
NTTデータ・セキュリティ
http://www.nttdata-sec.co.jp/