第6回 PCI DSS対応の難しさは「あいまいさ」？

川島　祐樹
NTTデータ・セキュリティ株式会社
コンサルティング本部　PCI推進室
CISSP
2009/8/7

　PCI DSSの要件、あいまい表現トップ3

　ここでは、筆者の少々の経験と独断により、PCI DSSの中でも、特にあいまいで対応方法の決定が難しい表現のトップ3を挙げてみたいと思います。このランキングは、要件のあり方やその表現を否定するものではありません。

1. ペネトレーションテスト（要件11.3）
2. 一般的なセキュリティ対策（要件2.2.x）
3. 保存するカード会員データは最小限に抑える（要件3.1）
   

●ペネトレーションテストと脆弱性スキャンの違い

　1のペネトレーションテストについて、必ず聞かれる質問があります。

「ペネトレーションテストって、どこまでやればよいのですか？」

　最もよくみられるミスは、脆弱性スキャンをもってペネトレーションテストとしてしまうことです。脆弱性スキャンとペネトレーションテストは、手法も目的も異なると考えるべきです。

　脆弱性スキャンは通常、ツールで実施されます。脆弱性スキャンの目的は、目立つ、大きな問題点を早期に発見することであり、決して網羅的なテストではありません。また、当たっていないパッチを確認するだけのものでもありません。ペネトレーションテストでは通常、検査中の1プロセスとして脆弱性スキャンも実施しますが、スキャン結果だけでなく、さまざまな手法で収集された情報を踏まえ、疑似侵入行為が行われます。これにより、ツールでは潜在的と判断されたような問題点も含め、誤検知ではないのか、誤検知でなければその影響範囲はどの程度なのかまでを含めて、総合的に、かつ網羅的に行われるテストです。

　さまざまなセキュリティ会社がセキュリティ診断サービスを提供していますが、選定のポイントはズバリ、「手作業による確認（exploit）を含んでいるか」です。安価なサービスはツールを流すだけ、ということもあるようですので、PCI DSS準拠のためにペネトレーションテストの外部業者への委託を検討する場合は、上記のような観点であらかじめ確認してみるとよいでしょう。

　脆弱性スキャンとペネトレーションテストの違いについては、QSAトレーニング時にもしつこく説明されることであり、区別できないQSAはいないはずです。具体的に選定する際にQSAにも助言を求めるのも1つの手かもしれません。

【関連記事】 セキュリティ対策の「ある視点」 第14回 ASV検査、ペネトレテスターの思考を追う http://www.atmarkit.co.jp/fsecurity/rensai/view14/view01.html

●“一般的”をどう解釈すべきか

　「一般的なセキュリティ対策」について、このような表現となってしまっている理由は、OSやアプリケーションごとに対策の方法が異なるためでしょう。世の中にあるあらゆるOSやアプリケーションについて、強固な設定にするための方法を盛り込むことは困難です。どこまでやれば一般的といえるのかは、やはり考えなくてはならないわけです。

　最も簡単なのは、そのアプリケーションの提供元ベンダが推奨するセキュリティ設定を参考にすることです。PCI DSSではアメリカ国立標準技術研究所（NIST）やSANS、Center for Internet Security（CIS）といった団体が挙げられていますが、日本にはこのほかにも金融情報システムセンター（FISC）の安全対策基準や、公共機関向けの政府統一基準、情報処理推進機構（IPA）が提供している情報などさまざまなものがありますので、これらを参考にすれば問題ないはずです。内部のドキュメントに内容を盛り込むのもよいでしょうし、「本項目については、最新版の●●基準の■■章に準ずるものとする」としてしまうのもよいでしょう。

●システムによって異なる“最小限”

　要件3.1によると、保存するカード会員データは最小限に抑える必要があります。確かに、持っている必要のないカード会員データは、漏えいリスクを考えても保持しないようにすることが最善であることはすぐに分かります。ただし、本当に「最小限」であるかというのは、考え始めるとなかなか難しいものです。こんな状況が考えられるのではないでしょうか。

• PAN（カード会員番号）がデータベースの主キーになっているので外せない。システムの動作上でも必要なデータで、暗号化もできません
• 不具合解析の時に原因が分からなくなってしまうかもしれないので、トランザクションのログはそのまま保管してあります
• そもそもカード会員データを頻繁に見る業務なので、Accessファイルにエクスポートされたデータが各自のPCのハードディスクに保管してあります

　QSAの立場であっても、一方的に「それはNGです。削除して、別の方法で業務を行ってください」などとはいえません。必要最小限の「必要」とは、何をもってして必要といえるのか、どのような立場で、どのような業務やサービスを行っているのか、規模やそれ以外のセキュリティ対策状況によっても変化することがあるでしょう。

　そのときは、すぐに代替コントロールを検討するのではなく、まずは「保持しないこと」が実現できないかどうかを徹底的に検討し、どうしても保持しなければならない場合は、保持することによって発生するリスクの大きさと範囲、それをカバーするためにはどのような追加の対策が必要となるのかを合わせて考える必要があります。

3/4

Index
PCI DSS対応の難しさは「あいまいさ」？
	Page1 PCI DSSは動き続ける
	Page2 QSAは偉い？ 基準に残るあいまいさ、それが問題
	Page3 PCI DSSの要件、あいまい表現トップ3
	Page4 あいまいさを克服するためには 「PCI DSSに準拠するための3つの重要なポイント」とは

オール・ザッツ・PCI DSS 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）