PCI DSS V3.2における変更点解説（3） 要件12.11/12.11.1　サービスプロバイダに対する四半期レビューの要求

関連記事：PCI DSS V3.2における変更点解説（１） 要件10.8セキュリティ制御システムの監視と障害への対応
関連記事：PCI DSS V3.2における変更点解説（２） 要件8.3　管理者アクセスに対する多要素認証の要求

PCI DSS Ver3.2の主な変更点について、今回は要件12.11および12.11.1をとりあげる。これらはサービスプロバイダのための追加要件であり、セキュリティポリシーの維持運用について四半期ごとのレビューを求めている。なお、本要件は2018年1月31日まではベストプラクティスとみなされる。

定めた手順が「守られている」ことを確認

PCI DSSは、技術面の要件が中心となるが、実際に導入された技術やセキュリティの運用についても多くの要求事項がある。それらのセキュリティポリシーは、事業体の全体での情報セキュリティの方向性と関連する担当者に期待される意識や行動を明文化したものである。担当者は理解し遵守することが求められている。

PCI DSS要件12は、担当者に対する情報セキュリティポリシーの維持と、そのために求められるセキュリティ運用についての要件である。セキュリティポリシーの確立と普及、リスク評価プロセス、重要なテクノロジーに対する使用ポリシーの策定、ポリシーおよび手続きの文書化などが含まれる。これらの要件は、ISMS構築もしくはISO27001認証取得をすでにしている企業においては大半が達成されていると言われている。しかし全ての会社が日常的な業務の中にきちんとセキュリティを組み込んでいるとは限らない。

そこでV3.2で追加された要件12.11は、サービスプロバイダの担当者が日々、それらのセキュリティポリシーと操作手順に従っていることを確実するために、少なくとも四半期ごとのレビューの実施と、そのレビュー結果の文書化を求めている。対象として以下のプロセスを含む必要がある。ここでいう「レビュー」とはISMSでいう内部監査のようなものが求められると考えればよい。
本要件の目的は、PCI DSSの要件を再評価することではなく、「要件に従って定められた手順が守られていること」を確認することだ。PCI DSSに定められた運用サイクル（下表）によるレビュー結果や、運用サイクルそのものが正しく守られているかを四半期ごとにチェックし、文書化する。

▼サービスプロバイダのためのPCI DSSに定められた運用サイクルの例

要件番号	運用内容	実施サイクル
定められた期間ごとに行うもの
1.1.7	ファイアウォールおよびルータルールセットのレビュー	6ヶ月ごと
3.1	削除されたカード会員データに関するレビュー	四半期ごと
6.2.a	重要なセキュリティパッチの確認と適用	リリース後1ヶ月以内
6.5	開発者への安全なコーディング技法のトレーニング	1年に1回以上
8.2.4	パスワードの変更間隔	90日に1回以上
9.5	バックアップの入った媒体の保管場所のレビュー	1年に1回以上
9.7	すべての媒体の在庫調査	1年に1回以上
9.1.1	ビデオカメラ及び／またはアクセス制御メカニズムからのデータのレビュー	随時（データは3ヶ月保存）
10.6.1	セキュリティイベント、システムコンポーネントのログレビュー	毎日
11.1	ワイヤレスアクセスポイントのスキャン	四半期ごと
11.2	内部の脆弱性スキャンテスト	四半期ごと （又はシステム変更時）
11.2	外部の脆弱性スキャンテスト（ASVスキャン）	四半期ごと （又はシステム変更時）
11.3	ネットワーク（内部／外部）のペネトレーションテスト	1年に1回以上 （又はシステム変更時）
11.3	アプリケーションのペネトレーションテスト	1年に1回以上 （又はシステム変更時）
11.3	境界のペネトレーションテスト	半期に1回以上 （又はシステム変更時）
11.5	ファイル変更監視	週に1回以上
12.1.1	情報セキュリティポリシーの見直し	1年に1回以上
12.2	脅威と脆弱性を特定したリスク評価	1年に1回以上
12.6.1	従業員のセキュリティ教育	雇用時及び1年に1回以上
12.8.4	サービスプロバイダのPCI DSS準拠ステータスの確認	1年に1回以上
12.10.2	インシデント演習	1年に1回以上
12.11	セキュリティポリシーと運用手順に従っていることの確認	四半期ごと
常時または随時行うもの
6.3	ソースコードレビュー	随時
6.4	変更管理	随時
8.1.4	非アクティブ（90日間）なユーザIDの削除または無効化	随時
9.1	入退室記録	随時
9.2	契約が終了したオンサイト要員、訪問者IDの無効化	随時
10.8	セキュリティ制御システム不全の検知	随時
12.10.3	インシデント対応	24時間365日

レビュー結果の文書に対しては、PCI DSS準拠プログラム責任者による結果のレビューと承認が求められる（要件12.11.1）。ISMSでいうところのマネジメントレビューと同じと考えればよい。

より厳格なセキュリティポリシー維持が求められるサービスプロバイダ

本要件はPCI DSSの対象となる事業体のうちサービスプロバイダのみを対象としている。また、これ以外にも要件12.4では、サービスプロバイダ向け追加要件として、経営層がカード会員データの保護とPCI DSS準拠プログラムの責任を宣誓することを求めている（こちらも2018年1月31日まではベストプラクティスである）。

具体的には、PCI DSS準拠に対する責任者が経営層（執行役員、取締役または同等レベル以上）であることや、PCI DSS準拠プログラムの実施条件と経営層のコミュニケーション条件を概説した「PCI DSS憲章」を定めることを挙げている。

サービスプロバイダは加盟店と比較して、より大量のカード情報を扱っていると想定されるため、より厳格なPCI DSS準拠が求められる。ひとたびカード情報の流出が起きれば重大な結果を招くことは言うまでもない。

特にPSP（決済代行事業者）などのサービスプロバイダは、他社のカード情報を取り扱うことが前提となる。情報流出のインシデントが発生した場合は、カードの再発行や不正利用に対する補償などカード会員に対する責任は一次的にはPANの所有者であるカード発行会社（イシュア）が負うことになる。すなわち、影響範囲が自社内にとどまらず、多くの場合は複数のイシュアに及ぶ。

PCI DSSを日常業務に

PCI DSSは2006年にカード情報を守るために定められた基準である。しかし、米国では既にPCI DSS準拠企業であっても多数のカード情報を含む個人情報の流出事件が発生している。また2017年3月には、日本でもPCI DSSに準拠済みのPSPから約40万件に上る大量のカード情報が流出する事件が発生した。

PCI DSSは決して万能ではない。カード情報を取り扱う組織がPCI DSSに準拠することは最低限の基準であり、進化するサイバー攻撃に備え追加コントロールを組み込む必要がある。「PCI DSS以上の強固なセキュリティを各々の組織が実装すべきである」というのが、すでに準拠企業から多数流出事件が発生している米国企業における考え方である。日本企業も前述の事件を期に意識を変える必要がある。

とはいえ日本においては、カード情報取扱いの立場によって、PCI DSSへの準拠状況が大きく異なるのが現状だ。加盟店については大半がカード情報の非保持化やPCI DSS準拠を準備している途中にあり、いきなりPCI DSS以上のセキュリティを要求するのは現実的ではない。一方で、PSPや他社カード情報を大量に扱う事業体については、大半の事業者がPCI DSSに準拠済みであり、日々のPCI DSS運用をより厳密に行う必要がある。日々モニタリングを行い、必要であれば追加コントロールを組み込むことで、大きなインシデントが防げる可能性もある。

そのためには、PCI DSSを「年1回のQSA監査というイベント」への対応ではなく、日常業務の手順にしっかりと組み込む必要がある。12.11の四半期レビューはそのためのセルフチェックとして位置付けて考えるとよい。

PCI DSS Ready Cloudでは、PCI DSS v4.0への効率的な移行支援及び準拠を促進するクラウドサービスを提供しています。
是非一度、ご相談ください。
PCI DSS準拠を促進するクラウドサービスならPCI DSS Ready Cloud

■ PCI DSS の構築、維持・運用にかかるコストと工数を削減する
 
■ AWSでの開発事業者や外部ベンダー/事業者との専用線接続がない場合に最適
 
■ 国内トップクラスのPCI DSS専門のコンサルタント集団によるPCI DSS準拠支援サービス