PCI DSSv4.0を読む⑭ 要件11の変更概要

PCI DSSv4.0が3月31日（日本時間の4月1日）にリリースされました。PCI DSSv3.0がリリースされたのは2013年12月でしたので、実に8年ぶりのメジャー改訂となります。

5/13に日本語版が1ヶ月少し遅れてリリースされました。英語版の360ページに比べて遥かに多い453ページの”大作”となっており、中々細部まで読むのが大変な基準書となっていますが、PCI DSSの専門家を自負している1人として、個人的な感想を交えて何回かに分けてv4.0について記事を書ければと思います。

※前回記事の6月から間が空いてしまいましたが、お盆休み期間に少し記事がかけたので公開します。

要件11：システムおよびネットワークのセキュリティを定期的にテストする

要件11のタイトルは微妙に変わっており、「セキュリティ」が外れました。変更履歴を見てもこの点はほとんど触れられていませんが、セキュリティシステム以外もCDE環境を構築する要素であるとの考え方からこうしたマイナー変更になった様に思えます。

※v3.2.1

※v4.0

要件11における新要件は6つです。

最初は11.1.2です。他の章と同様に「役割と責任」に関する要件が新規追加されています。他の章と同様に、文書化要求がありますので留意下さい。

※元々定義があった要件12以外の全て、しかも要件の最初の方にわざわざ11の新しい要件を入れた事は、各要件に対して事業体がきちんと役割と責任を割り振るべきであるとのPCI SSCの強い想いを感じます。

2つ目の新要件は11.3.1.1で、未来日付（2025年3月31日まではベストプラクティス）がついてはいますが、事業体の多くが”苦しむ”可能性を感じる要件です。

内容は、高リスクの脆弱性（CriticalやHigh）以外の脆弱性、即ち中低リスクの脆弱性（MediumやLow）についても、ターゲットリスク分析の上で対応をする事が要求されています。

多くの方が感じている様に、脆弱性は日々発表されていますので、各種のスキャン等で検出された高リスクの脆弱性対応だけで手一杯な所を、中低リスクについても対処が必要となると、脆弱性管理は非常に重たい作業になる事が予想されます。

QSAの（統一）見解次第ではありますが、ターゲットリスク分析の結果、『対処の必要無し』と判断した事業体側の意見が通るのならば別ですが、中低リスクの脆弱性について、対処が基本的に必要だとすると、今まで通りのやり方（v3.2.1手法の脆弱性管理）では指摘を受ける可能性も出てくる様に思えます。

※未来日付（2025年3月31日まではベストプラクティス）の規定です

この規定の”目的”部分を見ると、機械的に中小リスクだから対応は不要と判断するのではなく、ターゲットリスク分析において、きちんとした根拠を持って”対処が不要”とした事業体の結論（証査）を出す必要がある様に思えます。

※担当者は必要に応じて”修正パッチを適用しない”根拠をひねり出す必要がありそうです

3つ目の新要件は11.3.1.2で、内部脆弱性スキャンで、スキャン実施の為に必要な特権が付与される事、付与が出来ないシステムの場合はそのシステムが定義・文書化されている事が要求されています。

※システムに制約がありローカルユーザーしかスキャン実施を受け付けない様な場合には、QSAの審査でその理由が確認される事になると思われますので留意が必要です。セキュリティ機器やメインフレーム、コンテナ等がこうした制約があるシステム例として書かれている事を考えると、他のシステムの場合は正当な理由がなければ、内部脆弱性スキャン用の特権を付与する必要があるという事になります。

※未来日付（2025年3月31日まではベストプラクティス）の規定です

内部脆弱性スキャンにおいて特権を付与すると、（テスト環境が無い場合）稼働中の本番環境に大きな影響を与える（例えば停止してしまう）可能性があるから、と特権付与をしてこなかった事業体は、この要件の”影響範囲”についてQSAとよく相談しておくべきかと思います。

4つ目の新要件は11.4.7、マルチテナントサービスプロバイダー向け要件で、顧客の侵入テストをサポートする事に関する内容です。マルチテナントサービスプロバーダーですので、SaaS型のサービスを顧客（PCI DSS準拠の事業体）に提供している様な事業者が対象となります。

※未来日付（2025年3月31日まではベストプラクティス）の規定です

要件内容（運用上の注意）を見ると、マルチテナント型サービス事業者は、

①顧客がペネトレーションテストの実施する事をサポートする

②PCI DSSのサービス基盤（IaaSやSaaS）において、PCI DSS要件（11.4.3/11.4.4）に従ってペネトレーションテストを実施した証拠を顧客に提供する

2つのいずれかの方法で、顧客のペネトレーションテストをサポートする事が求められています。

想像が過分に入りますが、多くのマルチテナント型サービス事業者は②を選択する気がします。

その場合、顧客の契約インフラまで含めた形でPCI DSSv4.0準拠し、準拠証明書（AOC）を提示するか、顧客インフラ部分に対して（適切な作業対価を要求して）ペネトレーションテストを代行実施した結果を顧客に提示するのだと思いますが、諸々のリスクを考慮して顧客自身のペネトレーションテスト実施（①）を選択する事業者も出てくるかも知れません。

これも環境によって影響度が大きく変わりそうですので、サービス事業者は未来日付までの間にどのパターンが自社にとって良い選択なのかを検証を急ぐ事になりそうです。

5つ目の新要件は11.5.1.1、サービスプロバイダー向けの要件で、マルウェア侵害された際にマルウェアがC&Cサーバーと通信するのを検知／警告／防止する事が求められています。※DLPやIDS/IPS等のツールが必要となりそうです

※未来日付（2025年3月31日まではベストプラクティス）の規定です

最後6つ目の新要件は11.6.1、いわゆるカードスキマー対策、決済ページのコンテンツに対する不正変更の警告、変更と改竄の検出メカニズムの導入が求められています。

カードスキマー対策をECサイトやSaaS型のサービスプロバイダー（カートシステム提供事業者）に要求するのは、日本だとEC-CUBE等で頻発しているカードスキマーを不正に設置されるのと同様に、海外でもMagecartが（日本での攻撃が活発になる以前から）同様な攻撃を仕掛けてきている事が影響しているのかと思います。

※『カード情報非保持』だけでは国内ECサイトを守り切れていない状況を考えると、割販法のガイドラインである、クレジットカード・セキュリティガイドラインでもこの要件の考え方を取り入れるべきではないかと思います。