個人情報保護，内部統制，グリーンIT…。米国でブームになったことが2年くらい遅れて日本でブームになるというのはいつものことだが，もしかすると次のブームになるかもしれないのが，「PCIDSS（PCIデータセキュリティ規準）」である。

　PCIDSSとは，有力なカード・ブランド会社5社が2004年12月に共同で策定した情報セキュリティの規準（関連記事）。情報システムからのカード情報の漏洩を防ぐためのものである。「カード会員データを保護するためにファイアウォールを導入し、最適な設定を維持すること」「システムパスワードと他のセキュリティ・パラメータにベンダー提供のデフォルトを使用しないこと」など12項目の要件で構成されており，各項目はさらに具体的な中項目，小項目に分けられている。

　PCIDSSは，クレジットカード会社のためだけの基準ではなく，幅広い事業者が対象になる。PCIDSSを推進する立場にあるビザ・インターナショナル アジア・パシフィック・リミテッドの井原亮二氏（カントリーリスクダイレクター）は「カード情報を保管・処理・伝送しているすべての事業者が対象になる」と説明する。カード発行会社に加えて，カード加盟店，データセンター，印刷会社などが含まれる。クレジットカード決済を取り入れているECサイトは，決済機能を他社にアウトソースしている事業者を除き，すべてが対象になると考えればよいだろう。

　米国では今，このPCIDSSが盛り上がりを見せている。米国の情報セキュリティ事情に詳しいネットワンシステムズの山崎文明氏（セキュリティ事業推進本部 本部長）は次のように語る。

　「米CSI（Computer Security Institute）が主催する有力な情報セキュリティのイベント『NetSec』では2007年，キーワードとしてPCIDSSが大きく取り上げられた。米国のセキュリティ・ベンダーは今『うちの製品/サービスは要件○○を満たすのに役立ちます』という言い方で製品を紹介することが多い」。

　私自身もそういう場面に遭遇している。先日，住商情報システムが国内総代理店となっている米BlueLane社のAllwyn Sequeira（オールウィン・シークゥイーラ）氏にインタビューしたが，その際も「（ウチの製品を使えば）要件6.1をクリアできる」という表現を使っていた（関連記事）。

　米国でPCIDSSが盛り上がるのには理由がある。PCIDSSはもともと民間企業が策定した情報セキュリティ基準なのだが，マサチューセッツ州，ミネソタ州，カリフォルニア州など州法レベルでの法制化が始まっており，半ば強制に近い形で基準を満たす必要に迫られているからだ。

　それらの州法が施行されると，米国のカード発行会社やカード加盟店がクレジットカードにかかわる個人情報を漏洩した場合，PCIDSSの基準を満たしていることを1カ月以内に証明できなければ損害賠償のペナルティを課せられることになる。逆に，PCIDSSの基準を満たしていることを証明できれば，損害賠償を免責されると法律で規定されたのである。米国では，TJXのデータ流出事件をはじめ大規模なカード情報漏洩事件が続いており，その被害が甚大であったという状況が背景にある（関連記事）。

　日本では今のところ，このようなペナルティはないものの，PCIDSSの普及につながりそうな兆しはある。例えば，経済産業省が公開した個人情報保護法のガイドラインには「クレジットカード情報を含む個人情報の取扱いについて」と題する文書が添付されており，システム上の対処を想起させるような表現がある。そうでなくても外資系企業の日本法人は，米SOX法のときにいち早く対応を迫られたのと同じように，PCIDSSへの対応を今迫られている。

セキュリティ・ポリシーの最低ラインが示される

　情報セキュリティの認定基準と言えば，ISMS（情報セキュリティマネジメントシステム）がよく知られている。ネットワンシステムズの山崎氏によると「ISMSの認定を取得している企業は多いが，ISMSは客観的なセキュリティ規準になりにくいという弱点がある。PCIDSSはその弱点を補う」。具体的に見てみよう。

　警察庁が2007年1月に公開した「不正アクセス対策等の実態調査」によると，上場企業や行政機関1024のうちISMSで必要とされるセキュリティ・ポリシーを策定している企業は62％。「現在策定を進めている」「策定はしていないが，今後策定する予定」を合わせると，95％以上の企業が既にISMSに取り組んでいることになる。

　ところが，ISMSに取り組んでも企業の不安は消えない。同じ調査の「情報セキュリティ対策実施上の問題点」を見ると，「どこまで行えば良いのか基準が示されていない」と答えている企業が50％もあるのである。ISMSは，リスクとの見合いでセキュリティの基準を自前で策定するという考え方が基本にある。だから，同じISMSの認定を取得した企業であっても，A社は「パスワードは9桁以上で数字と英字を組み合わせる。1カ月に1回以上変更する」といったルールが必要だが，B社は「パスワードは英数字4桁以上。3カ月に1回以上変更する」で構わないということがあり得る。

　それに対して，PCIDSSは表現が具体的である。現在のバージョン1.1ではパスワードについて下記のような規定がある。

■要件8.5.8　グループ、共有または汎用のアカウントとパスワードを使用しないこと。
■要件8.5.9　ユーザー・パスワードは少なくとも90日ごとに変更する。
■要件8.5.10　最小パスワード長は少なくとも7文字以上にする。
■要件8.5.11　数字と英字の組合せから成るパスワードを使用する。
■要件8.5.12　直近4回に使用されたのと同じパスワードは、新しいパスワードとして使用できないようにする。
■要件8.5.13　ユーザーIDをロックアウトすることにより、連続したアクセス試行を6回以内に制限する。
■要件8.5.14　ロックアウト時間は30分間、またはアドミニストレータがユーザーID を有効にするまでとする。

　基準が具体的であるということは，どこまでやっておけばよいかが明確であるということだ。セキュリティ・ポリシーの最低ラインが示されているわけで，これが客観的なセキュリティ規準になりにくいというISMSの弱点を補うことになる。

　ただ，逆の見方もできる。基準が具体的であるということは，少なくともそこまでは何としても満たさなければならない。要件の中には満たすのが難しいと感じるものもあるため，それが敷居の高さにつながる可能性がある。「要件6」から一部を抜粋してみよう。

■要件6.1　すべてのシステムコンポーネントとソフトウェアに、最新のベンダー供給セキュリティ・パッチが適用されていることを確認する。関連するセキュリティ・パッチはリリース後1ケ月以内にインストールする。
■要件6.2　新しく見つかったセキュリティ脆弱性を特定するためのプロセス（例えば、インターネット上無料で利用可能な警告サービスに加入する）を確立する。新しい脆弱性の問題に対処するために基準を更新する。
■要件6.6　すべてのWebに面したアプリケーションは、以下のどちらかの手法を適用することで、既知の攻撃から防護されなければならない。
・カスタム・アプリケーション・コードについては、アプリケーションセキュリティに特化した組織に依頼して、一般的な脆弱性についての見直しをしてもらう。
・Webに面したアプリケーションの手前に、アプリケーション・レイヤー・ファイアウォールをインストールする。

　日々，現場でシステム開発・運用に当事者として携わっているエンジニアは，自分が担当する情報システムを思い起こしてみてほしい。この3項目だけでも，現時点ですべて満たしている情報システムは多くはないはずだ。PCIDSSは，一つでも要件を満たせなければ，認定を受けることはできない。

　そして，問題は敷居の高い要件だけではない。