PCI DSS Version 4.0における変更点のポイント 第二回

~ 未来日付の新規要件について~

PCI DSS徹底解説

2023.09.05

前回記事(PCI DSS Version 4.0における変更点のポイント 第一回)では、PCI DSS Version 4.0の移行スケジュールと主な変更点の概要を紹介しましたが、新バージョンへの移行状況はいかがでしょうか。今回は「Summary of Changes from PCI DSS Version 3.2.1 to 4.0」で紹介されているVersion 4.0の変更点のうち、2025年3月31日より後に要件化(それまではベストプラクティスの位置づけ)される未来日付の新規要件について抜粋して紹介したいと思います。

新規要件の全体概要

PCI DSS Version 4.0の新規要件は「Summary of Changes from PCI DSS Version 3.2.1 to 4.0」の「6. 新規要件の概要」にまとめられており、全64項目の新規要件があります。

表1:PCI DSS Version 4.0 新規要件リスト(1/3)※2
新要件 適用範囲 発行日
全ての事業体 サービスプロバイダのみ すべてのv4.0アセスメントで即時実施 2025年3月31日
2.1.2 要件2の活動を行うための役割と責任が文書化され、割り当てられ、理解されている。
3.1.2 要件3の活動を行うための役割と責任が文書化され、割り当てられ、理解されている。
3.2.1 オーソリゼーション完了前に保存された機密認証データ(SAD)は、データ保持および廃棄の方針、手順、およびプロセスの実施により、最小限にとどめる。
3.3.2 オーソリゼーションが完了する前に電子的に保管される機密認証データ(SAD)は、強力な暗号技術を使用して暗号化される。
3.3.3 イシュアが保管する機密認証データ(SAD)は、強力な暗号技術を使用して暗号化される。 ※1
3.4.2 リモートアクセス技術を使用する場合、明示的な許可を得た場合を除き、PANのコピーおよび/または移動を防止するための技術的な管理が行われている。
3.5.1.1 PANを読み取り不能にするために使用するハッシュ(要件3.5.1の最初の箇条書きによる)は、関連する鍵管理プロセスおよび手順を備えたPAN全体の鍵付き暗号ハッシュとする。
3.5.1.2 PANを読み取り不可能にするために使用する場合、ディスクレベルまたはパーティションレベルの暗号化を実装する。
3.6.1.1 暗号アーキテクチャの文書化された説明には、実稼働環境およびテスト環境における暗号鍵の使用防止が含まれる。
4.1.2 要件4の活動を実行するための役割と責任が文書化され、割り当てられ、理解されている。
4.2.1 オープンな公共ネットワークでの送信時にPANを保護するために使用される証明書が有効であることが確認され、有効期限が切れていない、または失効していない。
4.2.1.1 事業体の信頼できる鍵および証明書のインベントリが維持されている。
5.1.2 要件5の活動を実行するための役割と責任が文書化され、割り当てられ、理解されている。
5.2.3.1 マルウェアのリスクがないと識別されたシステムコンポーネントの定期的な評価の頻度を決定するために、ターゲットリスク分析が実施される。
5.3.2.1 定期的なマルウェアスキャンの頻度を決定するために、ターゲットリスク分析が実施される。
5.3.3 リムーバブル電子メディアが使用されている場合、マルウェア対策スキャンが実施される。
5.4.1 フィッシング攻撃を検知し、従業員を保護する仕組みがある。
6.1.2 要件6の活動を実施するための役割と責任が文書化され、割り当てられ、理解されている。
6.3.2 脆弱性およびパッチ管理を容易にするため、特注およびカスタムソフトのインベントリを維持する。
6.4.2 公開用Webアプリケーションに対して、Webベースの攻撃を継続的に検出・防止する自動化された技術的ソリューションを展開する。
6.4.3 消費者のブラウザに読み込まれ、実行されるすべての決済ページスクリプトを管理する。
7.1.2 要件7の活動を実行するための役割と責任が文書化され、割り当てられ、理解されている。
7.2.4 すべてのユーザアカウントと関連するアクセス権限を適切にレビューする。
表2:PCI DSS Version 4.0 新規要件リスト(2/3)※2
新要件 適用範囲 発行日
全ての事業体 サービスプロバイダのみ すべてのv4.0アセスメントで即時実施 2025年3月31日
7.2.5 すべてのアプリケーションおよびシステムのアカウント、並びに関連するアクセス権を適切に割り当て、管理する。
7.2.5.1 アプリケーションおよびシステムアカウントによるすべてのアクセス、並びに関連するアクセス権を適切にレビューする。
8.1.2 要件8の活動を実施するための役割と責任が文書化され、割り当てられ、理解されている。
8.3.6 認証要素として使用されるパスワードの最小限の複雑さのレベル。
8.3.10.1 パスワード/パスフレーズが顧客ユーザアクセスの唯一の認証要素である場合、パスワード/パスフレーズは少なくとも90日ごとに変更されるか、アカウントのセキュリティ状態が動的に分析され、リソースへのリアルタイムのアクセスが決定される。
8.4.2 カード会員データ環境(CDE)へのすべてのアクセスに多要素認証が適用される。
8.5.1 多要素認証システムが適切に実装されている。
8.6.1 システムやアプリケーションで使用するアカウントの双方向ログインを管理する。
8.6.2 アプリケーションやシステムのアカウントの対話型ログインに使用されるパスワード/パスフレーズが悪用されないよう保護されている。
8.6.3 アプリケーションおよびシステムアカウントのパスワード/パスフレーズが悪用されないように保護されている。
9.1.2 要件9のアクティビティを実行するための役割と責任が文書化され、割り当てられ、理解されている。
9.5.1.2.1 定期的なPOI装置の検査頻度を決定するために、ターゲットリスク分析が実施される。
10.1.2 要件10の活動を実行するための役割と責任が文書化され、割り当てられ、理解されている。
10.4.1.1 監査ログレビューが自動化されている。
10.4.2.1 他のすべてのシステムコンポーネントのログレビューの頻度を決定するために、ターゲットリスク分析が実施される。
10.7.2 重要なセキュリティコントロールシステムの障害が迅速に検出され、警告され、対処される。
10.7.3 重要なセキュリティコントロールシステムの障害が迅速に対応される。
11.1.2 要件11の活動を実施するための役割と責任が文書化され、割り当てられ、理解されている。
11.3.1.1 その他の該当するすべての脆弱性(高リスクまたは重要であるとランク付けされていないもの)を管理する。
11.3.1.2 内部脆弱性スキャンが認証されたスキャンによって実行される。
11.4.7 マルチテナント型サービスプロバイダーは、外部からの侵入テストのためにお客様をサポートします。
11.5.1.1 秘密のマルウェア通信チャネルは、侵入検知および/または侵入防止技術によって、検知、警告および/または防止、および対処を行います。
11.6.1 決済ページに対する変更および改ざん検知メカニズムが導入されている。
表3:PCI DSS Version 4.0 新規要件リスト(3/3)※2
新要件 適用範囲 発行日
全ての事業体 サービスプロバイダのみ すべてのv4.0アセスメントで即時実施 2025年
3月31日
12.3.1 各PCIDSS要件に対して、実行頻度に柔軟性を持たせたターゲットリスク分析が行われる。
12.3.2 カスタマイズアプローチで満たされる各PCIDSS要件に対して、ターゲットとなるリスク分析が実行される。
12.3.3 使用されている暗号スイートおよびプロトコルが文書化され、レビューされる。
12.3.4 ハードウェアおよびソフトウェア技術のレビューが行われる。
12.5.2 PCIDSSの範囲を文書化し、少なくとも12カ月に1回確認する。
12.5.2.1 PCIDSSの範囲は、少なくとも6カ月に1回、および大幅な変更時に文書化され、確認される。
12.5.3 重要な事業体の変更がPCIDSSの範囲に及ぼす影響を文書化し、確認し、その結果を経営陣に伝達する。
12.6.2 セキュリティ意識向上プログラムは、少なくとも12カ月に1回レビューされ、必要に応じて更新される。
12.6.3.1 セキュリティ意識向上トレーニングには、フィッシングおよび関連攻撃、ソーシャルエンジニアリングなど、カード会員データ環境(CDE)のセキュリティに影響を与える可能性のある脅威に関する意識が含まれている。
12.6.3.2 セキュリティ啓発トレーニングには、エンドユーザ・テクノロジの許容される使用に関する啓発が含まれる。
12.9.2 TPSPは、PCIDSS準拠状況およびTPSPの責任であるPCIDSS要件に関する情報を提供するよう顧客の要求をサポートする。
12.10.4.1 インシデント対応担当者の定期的なトレーニングの頻度を決定するために、ターゲットリスク分析が実行される。
12.10.5 セキュリティインシデント対応計画には、決済ページの変更および改ざん検出メカニズムからのアラートが含まれる。
12.10.7 インシデント対応手順が整備され、PANが検出されると開始される。
A1.1.1 マルチテナント型サービス事業者は、顧客環境とのアクセスが論理的に分離され、不正なアクセスを防止していることを確認する。
A1.1.4 マルチテナント型サービス事業者は、顧客環境を分離するための論理的分離制御の有効性を、半年に一度以上、侵入テストにより確認しています。
A1.2.3 マルチテナント型サービスプロバイダは、疑わしい又は確認されたセキュリティインシデント及び脆弱性を報告し、対処するためのプロセス又はメカニズムを実装している。
A3.3.1 以下のような障害が適時に検知され、警告され、報告されている。
・ログレビューの自動化機構
・コードレビューの自動化ツール

「すべてのv4アセスメントで即時実施」と記載されている要件は13項目あり、Version 4.0での審査において直ちに評価対象となりますが、主にはPCI DSSの各要件に対する役割と責任を明確化するなど、文書化の必要がある要件です。一方「2025年3月31日」と記載されている要件は51項目あり、2025年3月31日まではベストプラクティスの位置づけとなりますが、いずれも対策に時間を要する可能性のある要件が中心となっています。その中でも新たな脅威に対応する形で新規に追加されたと考えられる要件について、ピックアップして紹介したいと思います。

【新規要件に関連する脅威(抜粋版)】

  • 不正なサーバ証明書の悪用
  • フィッシングによるカード情報や認証情報などの窃取
  • Log4jなどライブラリやAPIの脆弱性の悪用
  • 不正なJavaScript埋込などによるオンラインカードスキミング
  • GitHubのリポジトリなどから盗み出したソースコード内の認証情報の悪用
  • 秘密のマルウェア通信(DNSトンネリングなど)

① 不正なサーバ証明書の悪用

【求められる対策】有効期限切れや失効した証明書の検証

オープンな公共ネットワークを介した送信時にPANを保護するために使用される証明書は、有効であることが確認され、有効期限が切れていたり失効していないこと(要件4.2.1 抜粋)

インターネットなどオープンなネットワーク経由でクレジットカード番号(PAN:Primary Account Number)を伝送する場合、強力なプロトコル(TLS 1.2以上など)や適切な暗号強度(AESなど)を用いた通信の暗号化が求められていました。これに加えて新規要件では、通信の保護に使用される証明書について以下のような観点で検証することが求められます。

  • 信頼できるソースが発行しているか
  • 有効期限が切れていないか
  • 証明書が失効していないか

利用者にとってセキュアなWeb通信であることを確認するための拠り所の1つでもある証明書ですが、過去には証明書の秘密鍵が漏洩してしまい、信頼が損なわれてしまうような事案もあったことから追加された要件と考えられます。要件のガイダンスでは、最新の証明書失効リスト(CRL)またはオンライン証明書状態プロトコル(OCSP)の使用が推奨されていますので、可能な限り証明書の有効性を技術的に検証できる仕組みの構築が望まれます。

② フィッシングによるカード情報や認証情報などの窃取

【求められる対策】複数のアプローチによるフィッシング攻撃対策

フィッシング攻撃を検知し、担当者を保護するためのプロセスや自動化されたメカニズムがある(要件5.4.1)

PCI DSS対象システムにアクセスする担当者の保護を目的に追加された新規要件です。「情報セキュリティ10大脅威 2023(IPA)」の上位には「ランサムウェアの被害/サプライチェーンの弱点を悪用した攻撃/標的型攻撃による機密情報の窃取」などの脅威が列挙されていますが、いずれも従業員や取引先社員をフィッシングメールなどで欺くことでマルウェアなどに感染させることを攻撃のきっかけにしています。そのような状況から、クレジットカード情報やシステムにアクセスするための認証情報がフィッシング攻撃により窃取されることのないよう追加された要件と考えられます。本要件のガイダンスでは、複数のアプローチにより対策を講じることが推奨され、例えば以下の対策項目が挙げられています。

  • フィッシングメールやマルウェアが担当者に届く前にブロック可能なソリューションの導入など技術的管理策
  • DMARC(Domain-based Message Authentication, Reporting & Conformance)、センダーポリシーフレームワーク(SPF)などによるスプーフィング対策(なりすまし防止)
  • フィッシングに関する教育や対策訓練などの人的管理策※3

特にメール送受信を伴いフィッシング攻撃による影響が大きいと想定される業務(コールセンターやオペレーションセンターなど)において上記観点での対策が講じられているかの状況確認が望まれます。

③ Log4jなどライブラリやAPIの脆弱性の悪用

【求められる対策】サードパーティコンポーネントのインベントリ維持およびパッチ管理

特注ソフトウェアおよびカスタムソフトウェア、並びに特注ソフトウェアおよびカスタムソフトウェアに組み込まれたサードパーティソフトウェアコンポーネントのインベントリを維持し、脆弱性およびパッチ管理を容易にする(6.3.2)

近年、Apache Log4j の脆弱性(ロギングライブラリであるApache Log4jのJNDI Lookup機能で任意のコードがリモート実行される)が世間を騒がせましたが、まだ記憶に新しい方も多いのではないでしょうか。また、ソフトウェアライブラリのバージョン情報などを統一されたフォーマットで管理し、ソフトウェアの透明性を高めることを目的に、米国の大統領令でSBOM(Software Bill of Materials:ソフトウェア部品表)というリスト作成が求められるようになりつつあることも昨今話題となっています。このようにソフトウェアサプライチェーンのセキュリティ向上が重要度を増すなか、新規要件としてソフトウェアに組み込まれたサードパーティコンポーネント(dllなどのライブラリ、API含む)をリストアップして脆弱性管理の対象に含めることが求められるようになったと考えます。要件のガイダンスでは、ソフトウェア構成分析ツールなどソリューションの使用が推奨されています。ソフトウェアコンポーネントとの依存関係や網羅性の把握による影響範囲の特定が脆弱性管理では重要なポイントとなりますが、手動での管理には限界があるため、可能な限りツールなどの使用が望まれます。

④ 不正なJavaScript埋込などによるオンラインカードスキミング

【求められる対策】決済ページスクリプトなどのコントロール

消費者のブラウザに読み込まれ、実行されるすべての決済ページスクリプトを管理する(要件6.4.3抜粋)

要件6.4.3はクレジットカード決済を行う消費者ブラウザで読み込まれた不正なスクリプトによってクレジットカード情報が漏洩してしまうオンラインスキミングを防ぐことを目的としています。近年、国内のクレジットカード加盟店は改正割賦販売法への対応として、消費者がクレジットカード情報を入力するWeb画面は決済代行業者が提供するものを用いることで、加盟店自身のシステムではクレジットカード情報を直接持たない非保持化対応が行われています。しかしながら、加盟店側のWebサイトが侵害された場合、決済代行業者のWeb画面に遷移する前段階で不正なJavaScript埋込などが行われてしまうため、オンラインスキミング攻撃を完全に防ぐことはできません。そこで加盟店側のWebサイトも含め、消費者ブラウザ上での対策を強化し、不正なスクリプトが読み込まれてしまうリスクを低減するために追加された要件と考えられます。要件のガイダンスでは、コンテンツセキュリティポリシー(CSP)を使用した読込スクリプト制限設定(特定ドメインからの読込のみを許可など)が推奨されています。

⑤ GitHubのリポジトリなどから盗み出したソースコード内の認証情報の悪用

【求められる対策】システム/アプリケーションアカウントの管理強化

システムやアプリケーションで使用されるアカウントが対話型ログインに使用できる場合、以下のように管理される(8.6.1抜粋)
対話型ログインに使用できるアプリケーションおよびシステムアカウント用のパスワード/パスフレーズは、スクリプト、構成ファイル/プロパティファイル、カスタムソースコードにハードコードされていてはならない (8.6.2抜粋)
アプリケーションおよびシステムアカウント用のパスワード/パスフレーズは、次のように悪用されないように保護されている(8.6.3抜粋)

サーバログインなど対話型のログイン認証で通常利用されるアカウントだけではなく、システムやアプリケーションの動作や接続などで用いられているシステムアカウントやアプリケーションアカウントについても厳格に管理することが求められます。具体的には以下のような対策が要求されます。

  • 対話型ログインの原則禁止(要件8.6.1)
  • 構成ファイル/ソースコード等への認証情報のハードコード禁止(要件8.6.2)
  • パスワード/パスフレーズの定期変更、複雑な文字列での構成(要件8.6.3)

近年GitHubなどのリポジトリ上のソースコードが流出し、ソースコード上にハードコーディングされたクラウドサービスへの接続認証情報が悪用されてしまうなどの事案が発生していることから、対策強化を目的に追加された要件と考えられます。対話型ログインの禁止設定や、パスワード保管庫(パスワードVault)の導入による認証情報の暗号化保存および認証情報が変更可能な仕組みとするなど、システムアカウントやアプリケーションアカウントの保護方法を検討ください。

⑥ 秘密のマルウェア通信(DNSトンネリングなど)

【求められる対策】マルウェアによる秘密の通信を検知可能なソリューションの導入

侵入検知および/または侵入防止技術が、マルウェアの秘密の通信経路を検知し、警告し/防止し、対処する (11.5.1.1)

組織のネットワークに一次侵入したマルウェアは、さらなる内部ネットワークへの横展開や機密情報の持出しを行うため、攻撃者が用意したC&C(Command and Control)サーバとの接続を行おうとします。その際にトラフィックをTLSで暗号化したり、DNSトンネリングなどの手法で正規のトラフィックに紛れ込ませたりするなど秘密の通信経路を確立し、セキュリティ対策ソリューションによる監視を回避しようとします。そこで、本要件ではマルウェアによる秘密の通信について検知可能なソリューションの導入を求めています。要件のガイダンスでは、エンドポイントでのリアルタイムスキャン、発信トラフィックのフィルタリング、データ損失防止ツール(DLP)、IDS/IPSなどのネットワークセキュリティ監視ツールなどの方法が例示されています。すべてが必須というわけではありませんが、これらの対策ソリューションを組み合わせて秘密の通信を検知、対処可能な仕組みを構築することが推奨されます。

まとめ

今回はVersion 4.0の変更点のうち、未来日付の新しい要件について抜粋して紹介しました。
PCI DSS Version 4.0への取組みは、PCI DSS準拠というコンプライアンス維持だけが目的ではなく、上記に挙げる脅威に対処してシステム全体のセキュリティ向上につなげることが重要です。要件化されるまで1年以上の対応期間が残されていますが、新規要件に対処して効果的な対策とするためには、システムの改修、新たなソリューション導入、運用の見直しなどが必要です。そのため、Version 4.0改訂による影響は想像する以上に大きなものとなる可能性が考えられますので、現行システムの調査・分析、対応方針の策定、対策実施などを計画的に進めていくことが望まれます。

注釈

  • ※1 イシュアおよび発行サービスをサポートし、機密認証データを保管する企業のみに適用される。
  • ※2 「Summary of Changes from PCI DSS Version 3.2.1 to 4.0」の「6.新規要件の概要」をもとに作成。
  • ※3 要件5.4.1は自動化されたメカニズムに対して適用されると注記されているため、人的管理策だけでは本要件を満たすことができない可能性があり、技術的管理策やスプーフィング対策と組み合わせての対策が求められる。

参考文献

  • [1]PCI DSS Version 4.0
    https://www.pcisecuritystandards.org/document_library/
    検索フォームのドロップダウンリストFilter by で “PCI DSS”を選択し、表示された Standard の最右列のドロップダウンリストで、“Japanese PDF”を選択すると、日本語版がダウンロードできます。

お問い合わせ

セキュリティ基準に基づいたアセスメントサービス、各種セキュリティ診断サービスなどでのご支援が可能です。また、最新のPCI DSS Version 4.0に対応できるサービス「PCI DSS トータルサービス」も提供しております。お気軽にお問い合わせください。
https://www.intellilink.co.jp/contact-us.aspx

  • 文中の商品名、会社名、団体名は、各社の商標または登録商標です。

PCI DSS Version 4.0における変更点のポイント 第二回