PCI DSS v3.2主な変更点の解説

2016年4月28日、PCI SSCよりPCI DSS v3.2がリリースされました。PCI DSS v3.1からv3.2への変更点一覧については、前回の速報[1]でSummary of Changesを日本語化したものを紹介いたしました。今回は、変更点の中から、ポイントとなる箇所を解説したいと思います。

移行スケジュール

・PCI DSS v3.2は2016年4月28日公開と同時に発効となる
・PCI DSS v3.1は2016年10月31日に終息
・PCI DSS v3.2で追加される新たな要件は2018年2月1日から有効化

新バージョン3.2はリリース後、即時発効つまり審査に使用できるバージョンとなり、旧バージョン3.1は6カ月の移行期間を経た後、2016年10月31日に終息されることとなりました。2016年にv3.1で審査を予定されている組織は、2016年10月末か少し前を準拠期限としてスケジューリングする、あるいはv3.2での受審を検討する必要があるでしょう。
v3.2で追加される新たな要件は、2018年1月31日までの間はベストプラクティスの扱いとなりますので、受審組織にとってすぐに大きな影響はないはずです。

PCI DSS 主な変更点

[SSL/初期TLS関連]
・SSL/初期TLS移行期限の更新(2018年6月30日迄)
・SSL/初期TLSを使用する組織への追加要件(Appendix A2)

SSL/初期TLSの移行期限については、期限の延長について2015年12月に公表された内容が反映される形となりました(詳細は過去のコラム[2]を参照)。新規実装におけるSSLとTLS1.0以前のバージョンは使用禁止で、既存の実装におけるSSLとTLS1.0以前のバージョンは、2018年6月30日までに廃止すること、サービスプロバイダは2016年6月30日までにTLS1.1以降を選択できるサービスを提供することが求められます。
移行期限までSSL/初期TLSを使用する場合に必要となる、RMMP(Risk Mitigation and Migration Plan、リスク低減策と移行計画)などの対応は、付録「Appendix A2」としてまとめられました。

[PAN表示のマスキング関連]
・業務上の正当な必要性のある関係者が見ることのできるPANの桁数(要件3.3)
・マスキング例の追加(要件3.3)

PAN(Primary Account Number)を表示する際のマスキング要件の桁数に変更はなく、従来どおり先頭6桁/末尾4桁が最大表示桁数です。今回変更となったのは、表現のみです。従来、「業務上の正当な必要性がある関係者だけがPAN全体を見ることができる」と記載されていたのに対し、「業務上の正当な必要性がある関係者だけがPANの先頭6桁/末尾4桁以上を見ることができる」と変更され、業務上の必要性と桁数の関係がより厳密に表現されています。
マスキング例については、BIN(Bank Identification Number)だけを見る必要のある職務が挙げられ、BINの桁数としては伝統的には先頭の6桁であることがガイダンスに追加されました。これは、クレジットカードなどの番号スキームを制定する国際規格ISO/IEC 7812で、今後BINの桁数が拡張される可能性があり、そのことを示唆した表現となっています。

[BAU関連 - すべての組織]
・システム変更時におけるPCI DSS要件の実装(要件6.4.6)

BAU(Business As Usualの略)は日常業務を意味する言葉ですが、PCI DSSのコントロールを日常業務に組み込むという概念として、PCI DSS v3.0から規格序文にベストプラクティスとして紹介されるようになりました。PCI DSSの取り組みが年1回の審査だけを見据えた活動となっており、審査後の維持運用ができていない組織が多いことを背景に、BAUの重要性が増してきています。

今回、すべての組織に適用されるBAUの要件として、システムの重要な変更が行われた際に、関連するPCI DSS要件の実装と文書化を行うことが追加されました。この要件に対応するには、変更管理プロセスの中でPCI DSS要件への影響分析を実施することが重要となります。システム変更に影響するPCI DSS要件の例として次のものが挙げられていますので、少なくともこれらは考慮する必要があるでしょう。

  • ネットワーク構成図のアップデート
  • システム構成基準の適用(デフォルトパスワードの変更および不必要なサービスの無効化を含む)
  • 要件で求められるシステムの保護(例:ファイル整合性監視、アンチウイルス、パッチ、監査ログ)
  • 機密認証データの非保持、保存されるカード会員データの文書化、データ保管ポリシーや手順への反映
  • 新しいシステムを四半期毎の脆弱性スキャンプロセスに含める

[BAU関連 - サービスプロバイダ]
・暗号アーキテクチャの文書化(要件3.5.1)
・重要なセキュリティ制御システムの障害検知/報告/対応(要件10.8、10.8.1)
・6カ月毎のセグメンテーション制御のペネトレーションテスト(要件11.3.4.1)
・正式なPCI DSS準拠プログラムの確立(要件12.4.1)
・四半期毎の従業員のポリシー順守状況チェック(要件12.11、12.11.1)

サービスプロバイダ向けのBAU要件は、5つ追加されています。
暗号アーキテクチャの文書化では、カード会員データの保護に使用される暗号化アルゴリズム、プロトコル、各暗号鍵の詳細、鍵管理に使用するハードウェアのリストなどを含む文書が必要となります。

重要なセキュリティ制御システムの障害検知/報告/対応では、次に挙げるようなシステムの障害に対してタイムリーに検知/報告/対応を行うよう求めています。

  • ファイアウォール
  • IDS/IPS
  • FIM(ファイル整合性監視)
  • アンチウイルス
  • 物理的アクセス制御
  • 論理的アクセス制御
  • 監査ログメカニズム
  • セグメンテーション制御(使用されている場合)

従来PCI DSSではシステムの可用性に関する要件がほとんどありませんでしたが、重要なセキュリティ機能の停止は、システムの機密性や完全性の侵害につながるため、サービスプロバイダ向けにこの要件が追加されたのは合理的といえます。

セグメンテーション制御の有効性を確認するペネトレーションテストは、1年毎から6カ月毎へと頻度が上がりました。大幅なシステム変更時にも実施が必要なのは従来どおりです。

従来から、すべての担当者に情報セキュリティの責任を定義することが要件12.4にありましたが、これに加えてPCI DSS準拠維持に関わる全体の責任を経営層が割り当てること、PCI DSS憲章を定めることが要件12.4.1として追加されました。PCI DSS憲章には、PCI DSS準拠プログラムがどのように組織化され経営層へ伝達されるかを含める必要があります。近年、情報流出事故で経営責任を厳しく問われるケースが増えており、事業継続の観点でも重要な要件となるでしょう。

四半期毎の従業員のポリシー順守状況チェックは、次に挙げる運用が手順どおりに実施されているかをレビューする要件となります。運用の有効性をモニタリングするレビューの位置づけとなるため、運用部門ではなく、PCI DSS準拠を統括する部門が実施するのが望ましいといえます。

  • 日次ログレビュー
  • ファイアウォールのルールセットレビュー
  • 新たなシステムへの構成基準の適用
  • セキュリティアラートへの対応
  • 変更管理プロセス

[BAU関連 - 指定事業体]
・指定事業体向けの補足検証(Appendix A3: DESV)

指定事業体向けの追加要件であるDESV(Designated Entities Supplemental Validationの略、デスヴィーと読む)は、カード会員データを大量に扱う事業者を対象に、通常のPCI DSSに加えて評価する要件となります。PCI DSS v3.1向けのDESV要件は、PCI DSSとは独立した文書となっていましたが、PCI DSS v3.2からは付録「Appendix A3」としてPCI DSSに組み込まれました。DESVの内容解説については、また別の機会に譲りたいと思います。

[多要素認証関連]
・「二要素認証(two-factor)」から「多要素認証(multi-factor)」への用語変更
・CDE(カード会員データ環境)への管理アクセスに多要素認証の適用

「多要素認証」への用語変更については、要件の目的に変更はありません。従来どおり、「知識認証」、「所有物認証」、「生体認証」のうち異なる2つ以上を組み合わせた認証を指しています。一方で、v3.1まではリモートアクセスに適用されていた二要素認証(多要素認証)が、v3.2から内部ネットワークであっても管理アクセスに適用されるようになりました。これはフィッシングメールなどによりシステム管理者の端末がマルウェアに感染し、これを足がかりにCDEのサーバが侵害される脅威への対策となるでしょう。

まとめ

ここまで見てきたとおり、今回の変更の中心はBAUです。PCI DSSの普及が先行している米国では、PCI DSS準拠を維持できていない組織による大規模な情報流出事故が発生していることから、問題意識は、「PCI DSSに準拠しているか?」から「PCI DSS準拠を維持できているか?」へと変わってきており、それが色濃く反映されたバージョンになったと思います。

システム実装面で影響が大きい多要素認証については、対応期限を見据えて早めに計画を進める必要があるでしょう。PCI DSS v3.2で設定されている対応期限などを時系列で以下にまとめましたので、計画時の参考になれば幸いです。

PCI DSS v3.2対応期限など

2016年6月30日TLS1.1以降を使用できるサービスの提供(サービスプロバイダ)
2016年10月31日PCI DSS v3.1での審査終了
2018年2月1日BAU関連(すべての組織/サービスプロバイダ)の要件必須化
多要素認証の要件必須化
2018年6月30日SSLとTLS1.0以前のバージョン廃止(POS POI端末を除く)

参考リソース

Writer Profile

セキュリティ事業部
セキュリティコンサルティング担当 チーフコンサルタント
池谷 陽(CISSP、CFE、QSA、PA-QSA)

セキュリティ診断部門において、ネットワーク診断、システム基盤構築 ソリューションの研究開発に従事後、2009年よりPA-DSS、PCI DSSの準拠支援および審査を担当。POSベンダーや決済サービス事業者向けの支援・審査実績を多く有する。


PCI DSS v3.2主な変更点の解説