PCI DSSv4.0を読む⑮ 要件12の変更概要

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

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

要件12：組織の方針とプログラムによって情報セキュリティをサポートする

要件12のタイトルが少し変わっています。v3.2.1では”情報セキュリティポリシー”に関する要求事項だったのですが、

v4.0では、情報セキュリティをサポートする方針（ポリシー）とプログラムに焦点を当てる内容となっています。

要件12における新要件は12です。他の章とは違い役割と責任に関する新要件がありませんが、これはもともと要件に入っていた（12.1.3）為です。

1つ目の新要件は12.3.1で、v4.0になって新しく採り入れられた手法であるターゲットリスク分析についての要件となっています。他の要件でターゲットリスク分析が要求されているものは、この12.3.1に従って分析を実施する必要があります。

ISMS等でリスクアセスメントを実施した事がある方であれば、この新しい要件内容についてある程度把握できると思いますが、正直に言えば”初見の方”には理解しづらい内容かも知れません。

この要件ガイダンスにもISMS実施の為のガイダンスでもあるISO 27005（NIST SP 800-30）が参考として挙げられている事から考えると、要件に合わせて保護資産の定義（把握）や脅威特定、影響度、攻撃実現性などをきちんと分析要素に入れる必要がある様です。

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

この内容を見ると、ひな形が欲しい所ですが、E2に添付されている『ターゲットリスク分析テンプレート例』（※P418）は、必須記載事項はともかく、個人的には使いづらい印象です。

※このテンプレートを利用しなくても良いとも書かれていますので、自組織のISMS等で使っているアセスメントシートがあれば、もしかするとそちらをアレンジする方が良いかも知れません。

ISMSに馴染みが無い方は、こうした要件やテンプレートの他に、JIPDECが出しているISMSユーザーガイドを一読し、資産の所をカード会員データや、PIN、磁気情報など、PCI DSSで定義しているアカウントデータ（機密認証データ）に読み換えて考えてみると理解が深まるかと思います。

2つ目の新要件は12.3.2で、こちらもv4.0になって新しく採り入れられた手法のカスタマイズアプローチを使う場合の要件です。

※カスタマイズドアプローチはオプションですので、従来からのアプローチ（定義されたアプローチ）でv4.0準拠を目指す場合にはNAとなる要件です。

カスタマイズドアプローチは、要件が満たせない場合の代替手段（代替コントロール）ではなく、目的を達成する為に、新しい技術などによって（複数の）要件を満たす考え方ですので、カスタマイズドアプローチを選択する場合は、その内容を審査するQSAと事前によく相談しておく必要があります。

3つ目の新要件は12.3.3、使用中の暗号プロトコルや暗号強度を”定期的にレビューする”事が求められています。

暗号プロトコルや暗号強度は通信やデータ（ファイル）を守る最も重要な手段です。こうした暗号プロトコルや暗号強度は、初回設定すれば終わりというものではなく、例えば既に危殆化状態となっている無線LANの暗号WEP（Wired Equivalent Privacy）を使用していた場合、簡単なソフトでWEPキーが割り出さてしまう可能性があります。

暗号を構成する要素は方式だけでなく鍵長などもありますが、強固である方式と長い鍵を使う事でセキュリティは向上しますが、実用では復号化に時間がかかるなど問題が発生する可能性も出てくる為、全体のセキュリティ強度を考えて暗号スイート（設定）を決める事になるかと思います。

近年量子コンピュータの実用化に向けて動きが加速しつつある事もあり、強固だと思われている暗号スイートを”解読する”能力も、ある日突然世に出てきてしまう可能性もあります。そうした中で、PCI DSSでは少なくても年1回は使用中の暗号スイート及びプロトコルを見直し（≒危殆化の恐れが無いかチェック）する事を要求しています。

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

当然の事ながら、年1回見直しする為には、その前に使用している暗号プロトコルや暗号強度について把握（＝棚卸）しておかなければいけません。そのリストを元に、CRYPTREC（電子政府推奨暗号リスト）やNIST文書などを参考に自組織で暗号の危殆化を発生させない様に早めに動いて欲しいというPCI SSCの考えが背景にある様に思えます。

※別な見方をすると、PCI DSSv3リリースの後、TLS1.2の扱いで二転三転した事に懲りて、事業体側にその責任を寄せた様にも思えます。（尚、TLS要件は付録A2と補足文書に要件や推奨が残っています）

4つ目の新要件は12.3.4、使用中のハードウェア及びソフトウェア技術の定期的なレビューの要件です。少なくても年に1度はハードウェア及びソフトウェアのサポート切れリスクをレビューする事が求められています。

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

単純にこの要件を読むと、ハードウェア及びソフトウェア技術のサポートが生きている事で充足しそうに見えるのですが、使用している技術が”PCI DSS準拠”を妨げていない事もレビューする事が求められており、2.2.1で要求されているシステムコンポートネントの構成資料などを最新バージョンやサポートを付加する形でこの要件のレビュー資料を作る事も出来そうな気がします。

5つ目の新要件は12.5.2、PCI DSSの適用範囲は、少なくても年1回及び、大幅な変更があった場合に、関連する文書が更新されている事を要求しています。

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

この要件は新規要件ですが年に1回のレビュー実施は別にして、本来であれば大幅な変更が発生した際にはデータフローやデータフロー図、システムコンポーネント等の文書が変更されるのが当然かと思います。

新規定で確実なレビューが細かく要求されたのは、多くの事業者が文書の更新を”忘れていた”事を物語っている気がします。

※恐らく、多くの事業者が年1回のレビュー実施を・・・QSA審査前に実施するのではないかと思います。（一番効率的ではあります）

6つ目の新要件は12.5.2.1、サービスプロバイダー向けの要件で、12.5.2の要件がより厳しくなって、少なくても半年に1回実施および大幅な変更があった際に実施が要求されています。

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

7つ目の新要件は12.5.3、こちらもサービスプロバイダー向けの要件です。

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

適用範囲の再確認という内容がサービスプロバイダーに課されます。半年に1回、および適用範囲内の環境に大幅な変更があった際に、文書化され、内部レビューによって影響調査を実施する必要があります。比較的実施頻度が多い（年2回以上）様に思えますが、これはサービスプロバイダーが多数の顧客のカードデータを取扱うという点と、そして様々なシステムを内部に持っていてシステム更新等が一般の組織に比べて多いという事があってこの頻度になっているのかと思います。

今年前半に公表された大手決済プロバイダー（サービスプロバイダー）からの大量のカード情報漏えい事件では、カードデータ環境に別なシステムが接続していたにも関わらず適用環境外としていた事でSQLインジェクション攻撃を受けたと報告されていました。

接続されていないと思っていたシステムが実はカードデータ環境（CDE）に接続していたという事は、多くのシステム担当の方が”似た様な経験”をしてきたのではないかと思いますが、きちんと調べてみないと”思わぬ抜け穴（裏口）”がいつの間にか出来ているリスクを軽減する為に、脆弱性診断や侵入テスト結果などと共に新しいネットワーク図を総合的にレビューする事は、PCI DSSの適用範囲（スコープ）でなくても重要な事かと思います。

8つ目の新要件は12.6.2、セキュリティ啓発プログラム（教育）に関するものです。

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

v3.2.1までの教育については、あまりその内容について細かく書かれておらず、一般的なセキュリティ教育の実施記録を持って要件をクリアしていた組織も多いのではないかと思います。ISMS教育や一般的なEラーニング教材を使ったものが悪いという事はないのかと思いますが、この新規定を見る限り、『12か月に1回見直す』と書かれている事から、『セキュリティ意識向上』という考え方はより実践的に行う事が求められていると言えます。

例えば直近のカード情報漏えい事件といったものを教育内容に入れる事や、PCI DSSv4.0の変更点や”その規定の意図”について専門家の方々の記事や、PCI DSS基準書の『ガイダンス』を題材として教育するのも良いかと思います。

一般的な教育をセキュリティ啓蒙プログラムに使うのであれば、『毎年同じ教材を使う事が本当に良いのか？』という点について、改めて12か月毎にCISOと一緒に考えるべきかと思います。

9つ目の新要件は12.6.3.1、セキュリティ意識向上トレーニングについて上記12.6.2に関連して、2つ必ず入れなければいけないテーマがあるという新要件です。

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

v4.0切替（初年度審査）の年度は、こうした（※要件12.6.3.1だけでなく、要件12.6.3.2も必須内容です）変更ポイントとしてしまえば、要件12.6.2も達成する事になりそうですが、最近特にインシデントが増えている『フィッシング』と『ソーシャルエンジニアリング』は、従業員教育として必須となります。

多くの企業では、こうした最新の脅威については既に従業員教育の題材として採り入れているかと思いますが、フィッシングもソーシャルエンジニアリングも次から次へと”新しい手法”が出てきていますので、フィッシング対策協議会、IPA、JPCERTなどが出しているレポート等を参考にプログラム構成を考えると、より実効性の高いものになるかと思います。

10番目の新要件は12.6.3.2、こちらもセキュリティ意識向上トレーニングについての内容です。こちらは『エンドユーザ・テクノロジ』の許容される使用について従業員に教える必要があるというものです。

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

エンドユーザ・テクノロジーについては、要件12.2.1の「運用の注意」で例が挙げられています。

利用ポリシーが求められるエンドユーザ・テクノロジの例としては、リモートアクセスや無線技術、ノートパソコン、タブレット端末、携帯電話、リムーバブル電子メディア、電子メールの使用、インターネットの使用などが挙げられますが、これらに限定されない。

この新要件が出てきた背景について、個人的には、コロナ禍においてテレワークが当たり前となり、新しいクラウドサービス（SaaS）、BYOD（私用端末）の利用が進んだ事が大きい気がします。

急速にIT化、もっと言えばDX化が進んでいく中で、新しい端末・技術は新しい（潜在的）リスクも齎す可能性が高い事から、従業員が勝手に新しい端末・技術・サービスを使う事によってセキュリティレベルが低下してしまう（セキュリティホールが出来てしまう）可能性がある事を正しく理解し、きちんとルールを決めて、そのルールを従業員に守らせる事が求められているのだと思います。

11番目の新要件は12.9.2、サービスプロバイダー向けの内容です。

日本の場合、クレジットカード・セキュリティガイドラインとの整合で、一部曖昧な部分が出てくる気がしますが、サービスプロバイダーは、利用顧客が準拠証明（AOC）を求めた際に協力する事、及び顧客との責任分界点について明確にする事が求められています。

※PCI DSSの基本的な考え方は、顧客＋サービスプロバイーの責任範疇を合算すると全ての規定準拠が出来ている事（全ての項目に〇がつく）を要求しており、曖昧な”管理外（想定外）”の部分が出ない様にする事です。よくあるのが、それはベンダーがやっていてくれるものだと思っていた・・・という某徳島の医療機関がランサム被害を受けた際に恥ずかし気もなく主張した様なケースですが、PCI DSS審査を受ける主体組織は、自身の責任において全ての規定準拠が出来ているかを証明（説明）する事が求められています。

12番目の新要件は12.10.4.1、インシデント対応訓練の実施頻度はターゲットリスク分析を使って決定する事です。

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

極論を言ってしまえば、インシデント対応訓練を数年間実施しない、といった事も（最低要求が1年に1回と書かれていないので）リスク分析の結果次第では可能だと思われますが、何故その判断に至ったのかについて、リスク分析結果について毎年QSAから厳しく質問が飛ぶ事になる気がします。

※要件には書かれていませんが、（無難に）従来通り年1回実施にする組織が、当面は多くなるのではないでしょうか。

13番目の新要件は12.10.5、インシデント対応計画の内容ですが、新要件部分が少しわかりにくく見えます。ここでは決済ページの変更と改竄検知メカニズムが新要件となります。

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

見覚えがある項目が並んでいるのですが、ｖ3.2.1では要件12.10.5、11.1.2、11.5.1が明確化でまとめられ、新要件11.6.1の『決済ページ保護』が新たに加わった要件となっており、この部分だけが未来日付となっています。

※考えてみれば当たり前なのですが、決済ページが改ざんされた（可能性がある）場合は、インシデントが発生した可能性が高いという事で、この部分が加わったという事だと思われます。

最後の新要件は12.10.7、CDE環境外でカード番号（PAN）が見つかった場合をインシデント対応計画に含むという内容です。

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

インシデント対応計画でカード番号（PAN）がカード会員データ環境（CDE）外で見つかった場合を想定しておく事が要求されています。

カード番号（PAN）が想定外の所（例えばイベントログ）から発見された場合、例えばセキュリティコード等も一緒の所から見つかる可能性があります。こうしたケースではインシデント（又はインシデント一歩手前）に発展する可能性が高いという事で、インシデント対応計画に書いておく事が要求されているものと思われます。

※この新要件が出てきた背景には、想定外の所からカード情報が漏洩するインシデントが多数発生した事があるのだと思います。個人的には、PCI SSCは、組織が”想定外”の所にカード情報を消し忘れてないか、あるいはハッカーが外に持ち出す為に一時的にカード情報を含んだデータファイルを組織内に置いていないかどうかを自身で定期的にチェックして欲しいという”想い”がある気がします。

大分時間がかかってしまいましたが、ようやく要件12までたどり着きました。

（要件12原稿を途中まで書いていたのを忘れていました）

最後に、これからv4.0の対応準備を始められる企業も多いかと思いますが、新要件対応は特に時間がかかると思われますので、要件の理解をQSAと一緒に早い段階から進めていく事を強くお勧めします。

過去の経験では、未来日付のある新要件が、自組織に当てはめてみると”重たい”≒対応に時間がかかる事が多かった気がします。

まだ”先の話だ”と考えずに、どのレベルまで達したら要件をパスできるのかを早めに把握する事が肝要かと思います。

■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の変更概要