PCI DSSv4.0を読む⑧ 要件5の変更概要

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

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

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

要件5：悪意のあるソフトウェアからすべてのシステムおよびネットワークを保護する

要件タイトルの変更部分ですが、v3.2.1では”マルウェア”や”ウィルス対策”という表現でどちらかと言うとエンドポイント対策が求められていた要件でした。

しかし昨今のカード情報漏洩インシデントは、必ずしもマルウェアばかりが原因という訳ではなく、決済ページに挿入された悪意のあるコード（JavaScript等のカードスキマー）が仕掛けられるケースやフィッシングによるカード情報漏洩も増えています。攻撃側が広範な攻撃テクニックを用いている現状を踏まえ加筆された様です。

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

まず5.1.2で、「役割と責任」が要件単位で加筆されています。要件6や要件12等を除き、12要件の多くはIT部門の担当者に割り振られる事になると思いますので、担当者がv3.2.1と同じである事も多いかと思います。

しかしv4.0によって役割と責任が明確になる事で、良い点もあります。それが”審査時”の説明者が確定するという事です。PCI DSS審査”慣れ”をしていない組織では、QSA(審査人）に対し質問事項への回答がピントずれしている場合、あるいは回答者が準備できておらずに審査時間を取られてしまう事が発生する場合がありますが、「役割と責任」が明確になる事で、事前の書類準備や審査の効率化に繋がるものと思われます。

新要件2つ目は、5.2.3.1でマルウェアのリスクが無いシステムコンポーネントの定期的な評価実施の頻度を、ターゲットリスク分析で判断するという内容です。ここで問題となるのが、『マルウェアリスクの無い』が何を指すのか？という部分かと思います。以前はLinux、MacOS、UNIX、メインフレームが該当するとしていたQSAが多かった気がしますが、最近はLinuxが外れ、MacOSも”怪しくなり始めている”気がします。

頻度に関しては、直近（審査期間スパンから考えると1年以内）に発生した自社・他社のインシデントや業界やベンダーからの情報を参考に、マルウェアスキャン実施の頻度を分析して決める事になりますが、この要件は2025年3月31日まではベストプラクティス（要件ではなく推奨）になっている事から、”相当手間がかかる”可能性があると考えておいた方が無難であり、v4.0審査実施の前年辺りから資料準備を進める事が重要な気がします。

※ターゲットリスク分析は長くなりそうなので説明を割愛しますが、判断根拠を持って結論文書を作る事が要求されていると言い換えられます。

この規定に関連するのが、v3.2.1における5.1.2です。v3.2.1までは影響評価のみの内容ですので、審査時にQSAから詳しく聞かれるケースはあまり多く無かったのではないかと思います。

しかし、v4.0では新規定ではありませんが（※ここも注意が必要です）、ｖ5.2.3の明確化が進み、「マルウェアリスクが無い全てのシステムコンポーネントの文書化されたリスト」や、特定のシステム（例えばMacOS）がマルウェアの影響を受けないと判断した根拠（業界の証拠、ベンダのリソース、ベストプラクティス等）が問われる事になる様です。

ガイダンスにあるベストプラクティス部分を見ると、例示ではありますが、”きちんと評価を実施する”事が求められているのが分かるかと思います。

3つ目の新要件は、5.3.2.1で「ターゲットリスク分析によって定期的なマルウェアスキャンの実施頻度を定義する」事が要求されています。

これは、上記の5.2.3.1と似た内容ですが、こちらは元々マルウェアスキャンの実施が必要なWindows端末（Linux端末）に求められるリアルタイムスキャンでは無く、定期的なスキャン頻度に関するものです。

PCI DSS規定（≒カスタマイズドアプローチの目的）は、「マルウェアが実行を完了できない」事を目的としていますので、その端末が置かれている環境によっては、あまりリスクが高くなく、頻繁にマルウェアスキャンを実施する必要が無いケースもあります。

また、振る舞い検知型のサービスで常にプロセスを監視している場合、マルウェア実行防止効果がかなり期待できる事もある為、定期的なマルウェアスキャンを実施するのは”PCI DSS規定(v3.2.1）が要求しているから”という状態であったケースもあり、リスク分析を実施した上で、実施頻度について各組織に委ねるという事になった様です。

こちらも新たに登場した「ターゲットリスク分析」の対象である為、未来日付（2025年3月31日まではベストプラクティス）が設定されています。

4つ目の新規要件は、5.3.3「リムーバブル電子メディア用マルウェアソリューション」に関する要件です。

USBメモリやDVD等のリムーバルメディアが端末に挿入（接続）された際に、アンチウィルススキャン又は振る舞い分析が自動的に実施される事が要求されています。

これは、振る舞い検知による外部媒体のロックは良いとして、アンチウィルスソフトによっては既に機能としてあるのではないかと思いますが、自動スキャンを強制する事がカードデータ環境（CDE）における全ての端末で実装できるか？という事を考えた際に、時間がかかる組織が多いとの判断があって、2025年までの猶予期間（ベストプラクティス判断）になっているものと思われます。

5つ目の新要件は5.4.1で、フィッシング攻撃の検知に関する内容です。留意すべきなのは、これはフィッシング対策教育（セキュリティ意識向上トレーニング）ではなく、仕組みとしてフィッシングメールを防ぐ事が求められています。

※例示としてDMARC（SPF,DKIM）が挙げられています

QSAによる評価ポイントにフィルタリングやマイクロソフトのVBAマクロ禁止などがどこまで含まれるのかは分かりませんが、恐らく多層的になっている組織としてのフィッシング対策（例：Emotet対策）がどうなっているのかを説明できる必要があります。この規定も2025年3月31日の未来日付が付けられており、（検証に時間がかかると想像される）DMARC導入を含め、従業員がフィッシングに引っかかるリスクを軽減する多層的重層的な仕組みを構築する事が求められています。

■PCI DSSv4.0を読むシリーズ

　PCI DSSv4.0を読む① v3.0リリースの頃を振り返る

　PCI DSSv4.0を読む② v4.0の印象とタイムスケジュール

　PCI DSSv4.0を読む③ カスタマイズドアプローチ

　PCI DSSv4.0を読む④ 要件1の変更概要

　PCI DSSv4.0を読む⑤ 要件2の変更概要

　PCI DSSv4.0を読む⑥ 要件3の変更概要

　PCI DSSv4.0を読む⑦ 要件4の変更概要

　PCI DSSv4.0を読む⑧ 要件5の変更概要

　PCI DSSv4.0を読む⑨ 要件6の変更概要

　PCI DSSv4.0を読む➉ 要件7の変更概要

　PCI DSSv4.0を読む⑪ 要件8の変更概要