2022年3月31日（日本時間では4月1日）、PCI SSCよりPCI DSS Version 4.0がリリースされました[1]。2022年4月29日には、PCI DSS Version 4.0 のSAQ[2]が、また、2022年5月13日には、PCI DSS Version 4.0の日本語版[3]も公開され、PCI DSS Version 4.0への対応準備を進めやすい状態となってきました。すでに自社への影響の確認を進められている組織も多いと思います。

PCI DSSの前回のメジャーバージョンVersion 3.0のリリースが2013年11月でしたので、実に8年4か月ぶりのメジャーバージョンアップとなります。また、現行バージョンであるVersion 3.2.1がリリースされたのが2018年5月ですので、この時点から数えても、3年10か月ぶりのバージョンアップとなります。今回リリースされたVersion4.0は、Version 3.2.1リリース後すぐに改訂作業が開始され、3回のRFC、200社以上の会社からの6000以上のフィードバックを経てリリースされています。前回のメジャーバージョンアップや、現行バージョンのリリース後、セキュリティ対策を実施する上で考慮すべきさまざまな事態が発生しましたが、それらの多くは上記のRFCを通じてVersion 4.0に反映されています。このコラムでは、PCI DSS Version 3.2.1 から Version 4.0 への移行スケジュール、変更点のポイントを解説します。

移行スケジュール

Version 4.0（以下、v4.0）は公開されてすぐにこのバージョンでの評価を実施することができるわけではありません。評価者（ISA/QSA）向けのトレーニングは2022年Q2（4月-6月）中に開始され、評価に関連する文書も、今後公開されていきます。
一方、これに伴いVersion 3.2.1（以下、v3.2.1）は2024年3月31日に引退となりますので、現在 v3.2.1でPCI DSSに準拠されている組織は、これから２年以内にv4.0に移行していくことが求められています。
なお、v4.0で新たに追加された64要件のうち13要件は直ちに適用され、残りの51要件は、2025年3月31日以降に要件化（それまではベストプラクティスの位置づけ）されますので、それまでに対応することが必要となります。

PCI DSS v4.0 実装タイムライン

（PCI SSC, “PCI DSS v4.0 At a Glance” [4] をもとに作成。Q1は、1～3月を指す）

PCI DSS v4.0における主な変更点

ここからは、PCI DSS v4.0で明示された事項や、柔軟に検証を行うために導入された 「カスタマイズアプローチ」（Customized Approach）について説明します。

1. PCI DSSの適用対象

PCI DSSの要求事項が適用される組織は、「アカウントデータを保存、処理、または伝送する事業体」と説明されることが一般的でした。クレジットカードが利用される加盟店や決済処理を行う決済代行事業者、クレジットカード会社が対象となるのはわかりやすいですが、こうした決済環境を安全に維持するために関与する組織が存在することも事実です。v4.0 では、アカウントデータを保存、処理、または伝送しない事業者であっても、一部のPCI DSS要件が適用される場合があることが明示されました。
例えば

は、アカウントデータを保存、処理、または伝送しない事業者ですが、一部の要件が適用されることが指摘されています。クレジットカード決済に何らかの形で関わる組織は、自組織に適用される要件がないか、再確認することが必要です。

一方で、これまでも指摘されることはありましたが、PCI DSSの要件の制限事項として、国や地域の法律に優先しないことが明確化されています。日本では、割賦販売法に規定するセキュリティ対策義務の「実務上の指針」として、クレジット取引セキュリティ対策協議会が公開している「クレジットカード・セキュリティガイドライン」（2022年3月に3.0版発行 [5]）でクレジットカード情報保護対策としてPCI DSS準拠についても触れられていますので、併せて参照し、自組織に必要なセキュリティ対策について見極めることが望まれます。

2. PCI DSSの適用範囲

これまで、PCI DSSの適用範囲については、Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation [6] という文書で説明されていました。ここで説明されていた内容が、v4.0 に統合され、要件が適用される範囲とカード会員データ環境の定義を明確化しています。また、PCI DSSが適用されるシステムコンポーネントの例として、クラウドや他のシステムコンポーネントについても追記されています。ここでの記載を再確認し、これまで対策してきた範囲やシステムコンポーネントが適切であったか見直し、対策が必要な範囲やシステムコンポーネントが見つかった場合は、対策の検討を始めてください。

3. PCI DSSの要件で使用される時間枠

PCI DSSの要件では、「四半期に一度」、脆弱性スキャンを実行するなどのように、定期的に実施することが求められている要件があります。これまで、定期的に実施する要件の時間枠についての説明は明示されていませんでした。v4.0では、こうした要件に記載されている時間枠についての考え方、例が示されました。各組織はこれまでの営みが、今回示された考え方に沿ったものになっているか、見直しが必要となります。

「四半期に一度」のアクティビティの実行について

上図は、四半期に一度実施することが求められているアクティビティの実施間隔を表したものです。上図の上の例は、同じ間隔で実施されていることを示していますが、下の例は、四半期の枠内で一度実施されているものの、その間隔はまちまちになっています。V4.0で明示された時間枠の説明では、出来るだけ近い間隔でアクティビティが実施されることを求めているため、上図の下のような間隔で実施される場合、「四半期に一度」という条件は満たしているように思われますが、不適合とみなされる場合があります。なお、予定されたアクティビティが行われない場合であっても、それを検知し対処するための文書化されたプロセスがあらかじめ定められており、これに従ってアクティビティが実施されたことを示す証跡があれば、要件は満たされます。そのためにも定期的な実施が求められている要件では、定義されたスケジュール通りにアクティビティが実施されない場合の対応を定めたプロセスを文書化し、プロセスに従って対応、これを証跡として残すことが求められます。アクティビティの実施プロセスを定めた文書については、あらかじめQSAを含めた有識者と協議の上、定めておくことが有効です。

4. PCI DSS の検証方法

PCI DSS v4.0 の大きな変更点の一つに検証方法の柔軟化があります。これまでは、PCI DSSの要件を、「正当かつ文書化された技術上またはビジネス上の制約」により満たすことができない場合、元の要件の意図と厳格さを満たし、リスクを十分に低減する「代替コントロール」を実装し、これを検証することで要件を満たすことが認められていました。v4.0では、代替コントロールを含む従来の要件に定義された通りにセキュリティコントロールの状況を検証する方法〔「定義されたアプローチ」（Defined Approach）〕に加え、要件には厳密には従っていない方法であっても、要件の目的に合致したセキュリティコントロールを実装し、これを検証することも認められるようになります。このアプローチは「カスタマイズアプローチ」と呼ばれています。

代替コントロールとカスタマイズアプローチの違いは、分かりにくいところがありますが、以下のように考えるとよいかもしれません。
例として、マルウェア対策について考えてみましょう。
マルウェア対策について、v3.2.1では要件5.2でウイルス対策メカニズムが最新の状態に維持され、定期的およびリアルタイムにスキャンし、監査ログを生成することを求めています。具体的には検知エンジンやパターンファイル（シグネチャ）を自動更新して、スキャンを行い、スキャン結果をログに残すことが求められていました。
一方、マルウェア対策については、攻撃手法やマルウェアそのものの多様化からパターンファイルによる検知方式に限界があるということが指摘されています。これに対し、マルウェア対策の技術として、人工知能を用い、ふるまいによってマルウェアを判定する方式や、サンドボックスで安全確認を行う方式も導入されて来ています。
こうした新しい考え方の製品を導入している場合、パターンファイルの最新化や定期的なスキャンを行い、その結果をログに残すということにはなじまないかもしれません。この様な製品を利用した場合、v3.2.1の要件5.2を厳密に満たすことができず、代替コントロールを検討されていたのではないでしょうか。このようにPCI DSSの要件には準拠しない新しい考え方の製品を導入しようとすると、代替コントロールを検討するしかないのでしょうか。PCI DSSの古い要件に縛られて、最新の高度で効率の良いセキュリティコントロールを導入できないということは、セキュリティ対策としては本末転倒です。
こうした問題を回避し、柔軟なセキュリティ対策を実現できるために導入されたのがカスタマイズアプローチです。

マルウェア対策に戻って説明します。上に記載したマルウェア対策製品に求められている要件の目的は、「最新のマルウェアを検知し、マルウェアの影響を受ける前に対処すること」と言えます。これらの目的に対応できていれば、コントロールは妥当と見なすことができるでしょう。従来のパターンファイルを用いたマルウェア対策製品が利用されており、検知エンジンやパターンファイルの自動更新および定期スキャンを実施することに制約がある場合は、代替コントロールを検討する必要があります。一方、パターンファイルを利用せず、定期的なスキャンを行う必要のない新しい機能を備えたマルウェア対策製品で上記の目的に対応しようとする場合は、v4.0であればカスタマイズアプローチで要件を満たすことができます。

カスタマイズアプローチを採用して評価を受ける事業体は、カスタマイズしたコントロールが要件の目的を満たしていることを文書化する必要があります。まず、PCI DSS v4.0の付録 E1に示されているコントロールマトリクスのサンプルに基づいて、実装されているコントロールの内容や、要件の目的を満たしていることを示すためのテストとその結果を文書化します。また、付録 E2に示されているテンプレートを参考に、要件12.3.2で求められているリスク分析を実施し、コントロールマトリクスやテストの証跡などと併せて、評価者に提出する必要があります。
評価者はカスタマイズされたコントロールが要件の目的を満たしていることを確認するため、カスタマイズされたコントロールごとにテスト手順を作成し、これに基づいて評価を行います。
自組織のPCI DSS準拠対応でカスタマイズアプローチを採用する場合は、代替コントロールを採用する場合と同様、事前に専門家に相談し、評価者に説明しておくことが肝要です。

このコラムでは、PCI DSS v4.0 の移行スケジュールおよびカスタマイズアプローチを中心に、PCI DSS v4.0における主な変更点を説明しました。今回の変更点や、新たに追加された要件、明確化され進化した要件に対応するために自組織に適した対策を検討し、必要に応じて新たに予算を計上して対策を進めていくということを考えると、v3.2.1からv4.0への移行期間として準備されている期間はそれほど長いわけではありません。時間があるから、と安心するのではなく、自社環境の早目の再分析と対策準備をお勧めいたします。移行にあたってご不明な点があれば、問い合わせフォームからお問い合わせください。次回のコラムでは、追加された要件や明確化された要件について解説する予定です。今回のコラムや次回以降のコラムが、自社のPCI DSS準拠に向けたセキュリティ対策を見直す機会になれば幸いです。

参考文献