2010年7月28日 09:21
JCDSCメンバーのQSA有資格者が集結
PCI DSS要件の解釈と許容範囲の緩やかな統一を目指す
日本カード情報セキュリティ協議会（JCDSC）参加企業のQSA（認定セキュリティ評価機関）は3カ月に一度、PCI DSS審査においての課題や問題点を議論する部会を開催している。4月27日に行われたJCDSC総会の川島祐樹氏（NTTデータ・セキュリティ）の講演から同部会の活動をまとめた。
部会は2～3カ月のスパンで開催
6回目までの開催で9社が参加
日本カード情報セキュリティ協議会に参加しているQSA（認定セキュリティ評価機関）が集い活動する「QSA部会」。
同部会活動の目的としては「QSA審査員の審査技術向上」が挙げられる。もともとQSAの資格を取得するためには非常に厳しい審査がある。例え、QSA認定を取得したとしても毎年、PCI SSCが実施するトレーニングにパスしなければ資格が取り消されてしまう。QSA部会では各社のQSAの有資格者が集い、情報を共有することで、それぞれのレベルを高めていく狙いがある。
2つ目は、これまで各社ごとで判断にブレがあった「要件の解釈と許容範囲の緩やかな統一」だ。PCI DSS各要件の解釈に曖昧な部分があると、各サービスプロバイダや加盟店では、「どこまで取り組めばいいのか」という明確な判断基準が見えてこない。実際は個社ごとの決済環境によって基準への対応方法は異なるため、ここまでやればいいという風に明確化してしまうと審査においても弊害が出る可能性がある。そのため、同部会では要件の解釈と許容範囲に関してはあくまでも緩やかな統一を目指している。
そして3つ目が「QSAの認知度向上」だ。この部分に関しては現状、QSA部会で議論した内容は外部に公開されていないため、認知度向上は達成できていない。
QSA部会への参加対象はQSAの有資格者となり、その証明として初回参加時にQSA認定書のコピーを持参してもらっている。部会は2～3カ月に一度のスパンで開催され、開催場所は各社の持ち回りとなっている。現時点では成果物などの報告は特に行っていない。第1回～3回目までの参加企業はNRIセキュアテクノロジーズ、NTTデータ・セキュリティ、国際マネジメントシステム認証機構、日本IBM、ブロードバンドセキュリティの5社。4回目からはBSIグループ・ジャパン、ビジネスアシュアランスが加わり、6回目にはインフォセック、テュフラインランドジャパンが参加している。各回での参加者は毎回10名前後。
部会ではまず、JCDSCとしての活動報告やPCI DSSの最新トピック、国際ブランドのプログラムの変更点、他組織との連携点などの情報を共有する。メインは実際に審査を行っていくなかでの要件に関する疑問点を部会のメンバーと共有して解決することだ。具体的な解決方法としては、PCI SSCに直接問い合わせることもあるが、基本的にPCI SSCは一般論しか発することができないため、具体的な質問を投げても「そこは各社の決済環境に依存するので回答できない」というケースもしばしばだ。そのため、QSAが審査で悩んでいるような問題点に関しては基本的に部会で議論し、解決することが多いという。
部会での議論の際、まず考えるべきなのは「そもそもの要件が意図している本来の目的がどこにあるか」だ。この点は「PCI DSSナビゲート」に記載されていることが多いため、その内容を参考にしたり、そもそもセキュリティ対策として何のためにカード会員情報を守るのかを考えるという。また、要件通りに対応すれば審査にパスできるが、コスト負担がかさむため、運用的に無理がある点なども議論の対象だ。
PCI DSSの審査実績がある会社などで独自の判断基準を持っているケースがある場合はそれも参考にしているが、その時も「この要件に関してはこの対処方法になる」という断定的な回答ではなく、「本来の要件の意図を踏まえてこういった対策もある」といった程度に留めている。
要件は2、3、6、10、11の議論が多い
PCI DSSの対象範囲特定も議題にあがる
QSA部会では第5回までの部会で約70の議論を行った。そのなかで議題にあがった回数が多い要件は2、3、6、10、11だ。またPCI DSSの対象範囲の特定についても議論されることが多い。
要件2は「システムの要塞化」「デフォルト値の変更」などを定めているが、例えば「仮想環境ではどう考えたらいいのか」「主要機能とは何を指すのか」「対象にクライアントを含むのか」といった点を議論している。
「カード会員データの暗号化」に関する要件3は取得企業の多くが苦労している部分だ。ここでは、「暗号鍵の管理方法」「暗号強度はどこまでで十分か」「イシュア（カード発行会社）の場合センシティブ認証データ非保持要件をどう考えるか」などが議題にあがっている。
要件6は「パッチの適用、開発プロセス」に関してだが、「パッチ適用の頻度」「脆弱性診断と要件11のぺネトレーションテストとの違い」などの悩みが多い。
要件10は「ログの取得と監視」について定められている。ここでは、「どのようなログを取得すればいいのか」「1日1回のログの確認はどのように行えばいいのか」「ログサーバの設置場所はどこがいいのか」「データベースローカルから発しているSQLはどこまで取得したらいいのか」などが議論された。
「定期的なテストと監視」を定めたのが要件11。ここでは要件6同様に「脆弱性スキャンとぺネトレーションテストの違い」「IDS/IPSの設置場所や運用方法」についての議題が多い。
審査時の悩みについて共有するだけでも有益
今後はQSAの認知度向上にも力を入れる
これらの議題に関しては、最終的にどこまで明確化するかが大切になるが、部会のメンバーとしては、それぞれの悩みについて意見交換をするだけでも有益で、他社の審査事例を聞くことにより、自社においての判断基準に生かすことができるという。ただし、「この要件はこの対策をすればパスできる」という明確な答えを出してしまえば、弊害も起きる。実際の各要件に対する判断基準は加盟店やサービスプロバイダの決済環境に依存する場合がほとんどのため、複合的にリスクを分析しなければ回答を導き出せないケースが多いからだ。
前述のように、現状、QSA部会で議論した内容は外部に公開されていないが、もし成果物の発表をする場合は、見ている人に誤解を与えないような表現にするなど、注意が必要だ。また、QSA部会自体、閉鎖的な活動のため、QSAの認知度向上は達成できていないという。今後は研究会やコミュニティへの参加など、他組織との連携も積極的に検討する方針だ。
