2023.07.06
2026.07.08
2022年3月にPCI DSS v4.0がリリースされました。そのため、PCI DSS準拠対象の事業者は新しいPCI DSS v4.0での審査および準拠に取り組んでいかなければなりません。ここでは、PCI DSS v3.2.1は最新バージョンであるPCI DSS v4.0とどういったことが違うのかについて解説していきます。
PCI DSS v3.2.1の概要やv3.2からの変更点、v4.0との違いなどについてまとめました。
PCI DSS v3.2については2019年1月1日を以って終了することとなったので、それ以降はv3.2.1の使用が必須となっていました。v3.2からv3.2.1への変更点がいくつかあります。
また、該当要件と付録A2が更新されており、2018年6月30日以降については、POS POI（point of sales point of interaction）端末とこれらの接続先のみがSSL/early TLSをセキュリティ手法として使用できるといった内容が反映されています。
多要素認証については、すべての非コンソール管理アクセスへの要件となったため、付録Bの代替コントロールの例からはMFAが削除されました。その代わり、対策例として、ワンタイムパスワードが追加されています。
なお、新たな要件となった項目はありません。
そのため、2024年3月31日以降についてはPCI DSS v4.0での審査及び準拠が必要です。
PCI DSS v3.2.1の有効期間である2024年3月31日までは、v3.2.1とv4.0のどちらでも準拠できます。
v3.2.1から最新版であるv4.0に移行するにあたり、企業によってはシステム改修のほか、運用変更などが必要なケースも十分に想定されます。そのため、準拠対象となる企業においては、PCI DSS v3.2.1とv4.0との要件差分について十分な確認を行い、対応していかなければなりません。
急なシステム改修や運用変更が難しいものが多いため、早期に対応を検討することが重要です。
これまでと基本となる考え方は大きく変わりませんが、リスク分析に関する考え方などが追加されているため、変更点が多いです。最新バージョンであるPCI DSS v4.0にはどういった特徴があるのかについて解説していきます。
ターゲットリスク分析とは、運用ごとにログファイルや認証情報といった資産の脅威を想定し、考えられる危険性を洗い出す作業のことをいいます。資産にはさまざまな種類がありますが、それぞれに対してどういったリスクが潜んでいるのか的確に見極めるための情報収集や判断も必要です。
リスク分析を行った上で、各運用に取り組まなければならないことから、効果的で効率的な運動が行えるようになるといえるでしょう。
どのような形でリスク分析を行うのかについては、慎重に判断が必要です。実際のリスクを可視化してからでなければ、適切な運用頻度の決定は行えません。
クレジットカードに関するデータの漏洩事故はなかなかなくなりません。例えば、クレジットカードにはカード会員番号や有効期限、カード会員名といった「カード会員データ」のほか、PIN・PINブロック・磁気ストライプ情報・セキュリティコードといった「機密認証データ」があります。
どちらの情報も漏えいしてしまうことは防がなければなりませんが、仮にカード会員データが流出したとしても機密認証データが守られていれば大きな被害を防ぐことが可能です。そのため、機密認証データについては加盟店側で保存することが禁じられていました。
ところが、実際には本来であれば保存が禁じられているような事業体から機密認証データが漏れる事故が起こっています。
こういった影響を受け、これまでは要件の対象は「カード会員データ」だったものが「アカウントデータ」へと変更されました。アカウントデータとは、カード会員データと機密認証データの両方を指します。より厳密化された形です。
また、フィッシング被害も増えていることから、PCI DSSv4.0ではフィッシング攻撃への対応に関する内容も加えられました。
例えば、ユーザーアカウントのパスワードについては数字・英字の両方を含むこと、文字数については12文字以上であることと、複雑なパスワードであることなどが定められています。
v3.2.1では要件5.4はマルウェアからシステムを保護するためのセキュリティこポリシー・操作の手順が文書化されていること、関係者全員が理解していることなどが要件でした。
一方、v4.0の要件5.4は、フィッシング対策に関する仕組みの要件です
要件に沿った対応では、フィッシング攻撃を検知し、なおかつユーザーを保護するためのプロセスや、記憶されたメカニズムがあることと定義されています。
注意しておきたいこととして、追加された内容は「フィッシング被害に遭わないようにセキュリティ意識を向上させるための内容」ではありません。そもそもフィッシングメールを防ぐ対策を取ることが求められています。
例えば、対策の一つとしてDMARCが挙げられていました。DMARC（ディーマーク）とは「Domain-based Message Authentication Reporting and Conformance」の頭文字を取ったもののことであり、送信ドメイン認証技術です。フィッシング攻撃による成り済ましメールなどに対して高い防御効果を発揮します。
他にも、センダーポリシーフレームワーク（SPF）、ドメインキー識別メール（DKIM）などが対策として有効として挙げられていました。
どういった形で対策をとれば良いのかについては、多くの企業で頭を抱える悩みともいえるでしょう。こういった関係もあり、こちらの項目はベストプラクティス要件です。
ベストプラクティス要件とは、PCI DSSv4.0に準拠するにあたり企業にとって大きな負担がかかるような項目に対して設定されるものであり、準拠まで猶予期間を設ける措置のことをいいます。2024年3月31日以降についてはPCI DSSv4.0への準拠が必要となりますが、こちらの項目については2025年3月31日までの期日が設けられている形です。
2025年3月31日に到達すると案件は有効の扱いになります。ベストプラクティス要件に設定されているということは、それだけ対応が難しいとも言えるので、どういった形でフィッシングメールを防ぐ対策をとるのかについては早期に検討が必要になります。
この中でWAF（Web Application Firewall）を導入することが求められています。
WAFとは、セキュリティ対策の中でも非常に重要とされているものであり、Webアプリケーションの脆弱性を見つけ、それを悪用した攻撃からWebサイトを守るための対策です。特にECサイトやインターネットバンキングでは、万が一の不正アクセスからシステムを守るために必要性が高いとされています。
Webアプリケーションの脆弱性についてはWebサイトの中でも非常に狙われやすいです。ネットワークレベルでのセキュリティ対策ができるFWや、プラットフォームレベルでのセキュリティ対策に繋がるIPSよりも上位となるアプリケーションレベルでのセキュリティ対策がWAFといえます。
v3.2.1では、Webアプリケーションの脆弱性診断を実施していない場合については、WAFの導入を必須とはしていませんでした。ですが、v4.0では必須となっているため、注意が必要です。
WAFの導入について検討する際、セキュリティ強度を高めたいと考えているのであれば、選択肢に挙がるのが「アプライアンス型WAF」です。「ゲートウェイ型WAF」「ネットワーク型WAF」とも呼ばれるものであり、大きな特徴として専用機器を導入する形で独自に運用を行います。のため、カスタマイズ性が高いのが魅力です。
一方、デメリットとしてコストが高額になる問題が挙げられます。導入時の費用だけでなく、メンテナンスやカスタマイズをするとなれば専門の技術者も必要です。
そのため、アプライアンス型導入が難しい場合は、比較的導入を検討しやすい「クラウド型WAF」についても検討してみると良いでしょう。「サービス型WAF」とも呼ばれるもので、アプライアンス型よりも費用を抑えて導入できます。
v4.0の要件8.3.6では、システムが12文字に対応していない場合は8文字以上、それ以外については12文字以上のパスワード設定にすることが定められています。また、数字・アルファベットの両方を含んでいなければなりません。
パスワードはセキュリティ上、できるだけ複雑なものにすることが好ましいといえます。特に長らく変更されていないものや予想されやすいものなどについては危険です。そのため、事業者はユーザーの安全性を高めるため、複雑なパスワードの設定を求めなければなりません。
特殊文字の使用や大文字と小文字の両方の使用を必須とするケースも増えてきました。
こちらの要件も企業にとって大きな負担がかかる要件であると判断できることから、2025年3月31日までの期日が設けられているベストプラクティス要件です。v3.2.1ではパスワードを最低7文字と定めていたため、2025年3月31日までは最低7文字でも準拠しているとされます。
つまり、社内のネットワークを通じてシステムにアクセスしているような場合などについても多要素認証の対象としなければなりません。そのため、企業によっては現在の認証方式では不十分と判断されてしまうような可能性も十分に考えられます。
多要素認証は、パスワードやPINコード、秘密の質問といった「知的情報」、携帯電話やハードウェアトークン、ICカードといった「所持情報」、指紋や静脈、声紋といった「生体情報」のうち、2つ以上を組み合わせたものです。
1回目の認証でIDとパスワード、次に暗証番号を入力するといった形で認証を行う二段階認証とは異なります。
多要素認証を用いることによって攻撃者がそれらを突破するのは難しくなるため、セキュリティ性が大きく高まります。なお、自動化された機能を実行するためのアプリケーションやシステムアカウント、1 回の取引を促進するために一度に 1 つのカード番号にのみアクセスできるような POS 端末のユーザーアカウントについては、要件が適用されません。
また、要件8.4.3ではカード会員データ環境（CDE）にアクセスまたは影響を与える可能性があるような事業体のネットワーク外から発信されるすべてのリモートネットワークアクセスに対することも定義されています。
こちらも同様に多要素認証について定められているのですが、要件8.4.2と要件8.4.3で指定されている両方のタイプのアクセスに対しMFAが必要となります。
どういった形で多要素認証を取り入れていくのかについては、慎重に判断する必要があります。自社の環境だけでなく、規模なども踏まえた上で多要素認証をサポートするような製品を活用していきましょう。
なお、要件8.4.2についても2025年3月31日までの期限が設定されているベストプラクティス要件となります。
まず、認証スキャンのため認証情報を受け入れることができないようなシステムについては、文書化される必要があります。それから、スキャンの目的で認証情報を受け入れるシステムは十分な権限が使用されていること、認証スキャンに使用したアカウントが対話的ログインに使用できるケースでは要件8.2.2に従って管理されること、といった内容です。
要件8.2.2とは、共有アカウントの管理に関して定められている要件となっています。要件8.2.2では、グループアカウントや共有アカウント、汎用アカウント、またはその他の共有された認証情報について、例外的に必要な場合のみ使用することと定められており、管理の方法についても定義されているので確認しておく必要があるでしょう。
以下が挙げられます。
◆要件8.2.2で定められるアカウントや認証情報の管理方法
脆弱性の中には認証スキャンのみでしか検出されないものもあることから、非認証スキャンのみ取り入れている場合は攻撃者に狙われやすいともいえるでしょう。
多くの脆弱性が検出されるようになれば、それだけ対応にも時間がかかることをおさえておかなければなりません。そのため、要件11.3.1.2については、2025年3月31日までの期限が設定されているベストプラクティス要件となります。
例えば、定期的に実行する各PCI DSS要件などは実行頻度に柔軟性があるといえますが、これらについては文書化され、なおかつ、適切なターゲットリスク分析によって運用の実施頻度を決定しなければなりません。
保護の対象となる資産を特定し、要件が保護する脅威を特定、脅威の可能性や影響に寄与する要因の特定などが必要です。
要件12.3.1準拠のためには想定される脅威に対応するために必要な頻度で要件を実行することが重要ですが、その正当性を含む分析も求められます。
なお、他の要件についても、要件12.3.1で定めている要素に従って行うターゲットリスク分析で定義したリスクに基づき対処しなければならないものが多々あります。
そのため、重要な要件の一つといえるでしょう。
ぜひ、ご相談ください。
PCI DSS v3.2.1の概要やv3.2からの変更点、v4.0との違いなどについてまとめました。
目次
PCI DSS v3.2.1の概要
PCI DSS v3.2.1は、2013年11月にリリースされました。PCI DSS v3.2については2019年1月1日を以って終了することとなったので、それ以降はv3.2.1の使用が必須となっていました。v3.2からv3.2.1への変更点がいくつかあります。
PCI DSS v3.2からの変更点
まず、v3.2であった注記の2018年1月31日までを期限としたベストプラクティスについては、期限を過ぎたので、削除となりました。また、該当要件と付録A2が更新されており、2018年6月30日以降については、POS POI（point of sales point of interaction）端末とこれらの接続先のみがSSL/early TLSをセキュリティ手法として使用できるといった内容が反映されています。
多要素認証については、すべての非コンソール管理アクセスへの要件となったため、付録Bの代替コントロールの例からはMFAが削除されました。その代わり、対策例として、ワンタイムパスワードが追加されています。
なお、新たな要件となった項目はありません。
v3.2.1は2024年3月31日に終了
PCI DSS v3.2.1は、2024年3月31日終了することとなっています。そのため、2024年3月31日以降についてはPCI DSS v4.0での審査及び準拠が必要です。
PCI DSS v3.2.1の有効期間である2024年3月31日までは、v3.2.1とv4.0のどちらでも準拠できます。
v3.2.1から最新版であるv4.0に移行するにあたり、企業によってはシステム改修のほか、運用変更などが必要なケースも十分に想定されます。そのため、準拠対象となる企業においては、PCI DSS v3.2.1とv4.0との要件差分について十分な確認を行い、対応していかなければなりません。
急なシステム改修や運用変更が難しいものが多いため、早期に対応を検討することが重要です。
最新バージョンPCI DSS v4.0の特徴
最新バージョンPCI DSS v4.0は、2022年3月にリリースされています。PCI DSS v3.0が公開されて以降、メジャーバージョンアップは、実に約8年ぶりのことでした。これまでと基本となる考え方は大きく変わりませんが、リスク分析に関する考え方などが追加されているため、変更点が多いです。最新バージョンであるPCI DSS v4.0にはどういった特徴があるのかについて解説していきます。
特徴①リスク分析
リスク分析に関して強化されました。例えば、要件12.3.1では、定期的に実行する要件など実行頻度に柔軟性がある各PCI DSS要件は、文書化することや、適切なターゲットリスク分析によって運用の実施頻度を決定する必要があると定めています。ターゲットリスク分析とは、運用ごとにログファイルや認証情報といった資産の脅威を想定し、考えられる危険性を洗い出す作業のことをいいます。資産にはさまざまな種類がありますが、それぞれに対してどういったリスクが潜んでいるのか的確に見極めるための情報収集や判断も必要です。
リスク分析を行った上で、各運用に取り組まなければならないことから、効果的で効率的な運動が行えるようになるといえるでしょう。
どのような形でリスク分析を行うのかについては、慎重に判断が必要です。実際のリスクを可視化してからでなければ、適切な運用頻度の決定は行えません。
特徴②最近の情報漏洩の動向に基づいた新規要件の追加
PCI DSS v4.0に新しく加えられているものとして、最近の情報漏洩の動向に基づいた新規要件が挙げられます。クレジットカードに関するデータの漏洩事故はなかなかなくなりません。例えば、クレジットカードにはカード会員番号や有効期限、カード会員名といった「カード会員データ」のほか、PIN・PINブロック・磁気ストライプ情報・セキュリティコードといった「機密認証データ」があります。
どちらの情報も漏えいしてしまうことは防がなければなりませんが、仮にカード会員データが流出したとしても機密認証データが守られていれば大きな被害を防ぐことが可能です。そのため、機密認証データについては加盟店側で保存することが禁じられていました。
ところが、実際には本来であれば保存が禁じられているような事業体から機密認証データが漏れる事故が起こっています。
こういった影響を受け、これまでは要件の対象は「カード会員データ」だったものが「アカウントデータ」へと変更されました。アカウントデータとは、カード会員データと機密認証データの両方を指します。より厳密化された形です。
また、フィッシング被害も増えていることから、PCI DSSv4.0ではフィッシング攻撃への対応に関する内容も加えられました。
特徴③既に求められている対策の一層強化
すでにPCI DSS v3.2.1で盛り込まれている内容についても、対策が強化されている形です。そのため、PCI DSS v3.2.1に準拠する形で対応していた事業者だったとしても、新たに確認、対応が必要です。例えば、ユーザーアカウントのパスワードについては数字・英字の両方を含むこと、文字数については12文字以上であることと、複雑なパスワードであることなどが定められています。
v3.2.1とv4.0の違い
v3.2.1からv4.0になるにあたり、さまざまなことが変更されました。その中でも特に注目したい変更要件と、対応に時間がかかったり、対応の難易度が高かったりするものについてピックアップします。要件5.4 フィッシング攻撃の検知
v3.2.1ではマルウェアやウイルス対策が重視されている傾向が強かったのですが、近年、情報漏えいはマルウェアによるものだけではなくなっています。そのため、増えているフィッシング攻撃に備えるための変更が加えられました。v3.2.1では要件5.4はマルウェアからシステムを保護するためのセキュリティこポリシー・操作の手順が文書化されていること、関係者全員が理解していることなどが要件でした。
一方、v4.0の要件5.4は、フィッシング対策に関する仕組みの要件です
要件に沿った対応では、フィッシング攻撃を検知し、なおかつユーザーを保護するためのプロセスや、記憶されたメカニズムがあることと定義されています。
注意しておきたいこととして、追加された内容は「フィッシング被害に遭わないようにセキュリティ意識を向上させるための内容」ではありません。そもそもフィッシングメールを防ぐ対策を取ることが求められています。
例えば、対策の一つとしてDMARCが挙げられていました。DMARC（ディーマーク）とは「Domain-based Message Authentication Reporting and Conformance」の頭文字を取ったもののことであり、送信ドメイン認証技術です。フィッシング攻撃による成り済ましメールなどに対して高い防御効果を発揮します。
他にも、センダーポリシーフレームワーク（SPF）、ドメインキー識別メール（DKIM）などが対策として有効として挙げられていました。
どういった形で対策をとれば良いのかについては、多くの企業で頭を抱える悩みともいえるでしょう。こういった関係もあり、こちらの項目はベストプラクティス要件です。
ベストプラクティス要件とは、PCI DSSv4.0に準拠するにあたり企業にとって大きな負担がかかるような項目に対して設定されるものであり、準拠まで猶予期間を設ける措置のことをいいます。2024年3月31日以降についてはPCI DSSv4.0への準拠が必要となりますが、こちらの項目については2025年3月31日までの期日が設けられている形です。
2025年3月31日に到達すると案件は有効の扱いになります。ベストプラクティス要件に設定されているということは、それだけ対応が難しいとも言えるので、どういった形でフィッシングメールを防ぐ対策をとるのかについては早期に検討が必要になります。
要件6.4.2 WAFの導入
要件6.4.2では、WAFの導入に関する内容が加えられています。内容としては、一般公開されているWebアプリケーションは、Webベースの攻撃を継続的に検知・防止するために自動化されている技術的ソリューションを導入することです。この中でWAF（Web Application Firewall）を導入することが求められています。
WAFとは、セキュリティ対策の中でも非常に重要とされているものであり、Webアプリケーションの脆弱性を見つけ、それを悪用した攻撃からWebサイトを守るための対策です。特にECサイトやインターネットバンキングでは、万が一の不正アクセスからシステムを守るために必要性が高いとされています。
Webアプリケーションの脆弱性についてはWebサイトの中でも非常に狙われやすいです。ネットワークレベルでのセキュリティ対策ができるFWや、プラットフォームレベルでのセキュリティ対策に繋がるIPSよりも上位となるアプリケーションレベルでのセキュリティ対策がWAFといえます。
v3.2.1では、Webアプリケーションの脆弱性診断を実施していない場合については、WAFの導入を必須とはしていませんでした。ですが、v4.0では必須となっているため、注意が必要です。
WAFの導入について検討する際、セキュリティ強度を高めたいと考えているのであれば、選択肢に挙がるのが「アプライアンス型WAF」です。「ゲートウェイ型WAF」「ネットワーク型WAF」とも呼ばれるものであり、大きな特徴として専用機器を導入する形で独自に運用を行います。のため、カスタマイズ性が高いのが魅力です。
一方、デメリットとしてコストが高額になる問題が挙げられます。導入時の費用だけでなく、メンテナンスやカスタマイズをするとなれば専門の技術者も必要です。
そのため、アプライアンス型導入が難しい場合は、比較的導入を検討しやすい「クラウド型WAF」についても検討してみると良いでしょう。「サービス型WAF」とも呼ばれるもので、アプライアンス型よりも費用を抑えて導入できます。
要件8.3.6 パスワードの複雑さ
v3.2.1でもパスワードについてはさまざまな要件が定められていましたが、v4.0ではさらに強化されています。v4.0の要件8.3.6では、システムが12文字に対応していない場合は8文字以上、それ以外については12文字以上のパスワード設定にすることが定められています。また、数字・アルファベットの両方を含んでいなければなりません。
パスワードはセキュリティ上、できるだけ複雑なものにすることが好ましいといえます。特に長らく変更されていないものや予想されやすいものなどについては危険です。そのため、事業者はユーザーの安全性を高めるため、複雑なパスワードの設定を求めなければなりません。
特殊文字の使用や大文字と小文字の両方の使用を必須とするケースも増えてきました。
こちらの要件も企業にとって大きな負担がかかる要件であると判断できることから、2025年3月31日までの期日が設けられているベストプラクティス要件です。v3.2.1ではパスワードを最低7文字と定めていたため、2025年3月31日までは最低7文字でも準拠しているとされます。
要件8.4.2 アクセスの多要素認証
多要素認証の実装については、PCI DSS v3.2.1では非コンソールアクセスの管理者やリモートアクセスに限られていました。ですが、PCI DSSv4.0の場合はカード会員データ環境（CDE）へのすべての接続が対象となっています。つまり、社内のネットワークを通じてシステムにアクセスしているような場合などについても多要素認証の対象としなければなりません。そのため、企業によっては現在の認証方式では不十分と判断されてしまうような可能性も十分に考えられます。
多要素認証は、パスワードやPINコード、秘密の質問といった「知的情報」、携帯電話やハードウェアトークン、ICカードといった「所持情報」、指紋や静脈、声紋といった「生体情報」のうち、2つ以上を組み合わせたものです。
1回目の認証でIDとパスワード、次に暗証番号を入力するといった形で認証を行う二段階認証とは異なります。
多要素認証を用いることによって攻撃者がそれらを突破するのは難しくなるため、セキュリティ性が大きく高まります。なお、自動化された機能を実行するためのアプリケーションやシステムアカウント、1 回の取引を促進するために一度に 1 つのカード番号にのみアクセスできるような POS 端末のユーザーアカウントについては、要件が適用されません。
また、要件8.4.3ではカード会員データ環境（CDE）にアクセスまたは影響を与える可能性があるような事業体のネットワーク外から発信されるすべてのリモートネットワークアクセスに対することも定義されています。
こちらも同様に多要素認証について定められているのですが、要件8.4.2と要件8.4.3で指定されている両方のタイプのアクセスに対しMFAが必要となります。
どういった形で多要素認証を取り入れていくのかについては、慎重に判断する必要があります。自社の環境だけでなく、規模なども踏まえた上で多要素認証をサポートするような製品を活用していきましょう。
なお、要件8.4.2についても2025年3月31日までの期限が設定されているベストプラクティス要件となります。
要件11.3.1.2 認証スキャン
要件11.3.1.2で定めているのは、v3.2.1では定められていなかった認証スキャンに関することです。認証スキャンによって内部脆弱性スキャンを実行するための要件が追加されました。まず、認証スキャンのため認証情報を受け入れることができないようなシステムについては、文書化される必要があります。それから、スキャンの目的で認証情報を受け入れるシステムは十分な権限が使用されていること、認証スキャンに使用したアカウントが対話的ログインに使用できるケースでは要件8.2.2に従って管理されること、といった内容です。
要件8.2.2とは、共有アカウントの管理に関して定められている要件となっています。要件8.2.2では、グループアカウントや共有アカウント、汎用アカウント、またはその他の共有された認証情報について、例外的に必要な場合のみ使用することと定められており、管理の方法についても定義されているので確認しておく必要があるでしょう。
以下が挙げられます。
◆要件8.2.2で定められるアカウントや認証情報の管理方法
- 例外的に必要な場合以外はアカウントの理由を禁止する
- 使用は例外的に必要な時間に制限される
- なぜ使用するのかなどを正当化するためのビジネス上の理由が文書化されている
- 使用は経営陣によって明示的に承認される
- アカウントへのアクセス許可前に個々のユーザーの身元が確認される
- 実行されたアクションはすべて個々のユーザーに起因するものである。
脆弱性の中には認証スキャンのみでしか検出されないものもあることから、非認証スキャンのみ取り入れている場合は攻撃者に狙われやすいともいえるでしょう。
多くの脆弱性が検出されるようになれば、それだけ対応にも時間がかかることをおさえておかなければなりません。そのため、要件11.3.1.2については、2025年3月31日までの期限が設定されているベストプラクティス要件となります。
要件12.3.1 ターゲットリスク分析
要件12.3.1で追加されたのは、ターゲットリスク分析に関することです。v.3.2.1でもリスク分析について定められている要件がありましたが、v4.0の要件12.3.1において定められているのは、PCIDSS要件の特性を踏まえた上で行うターゲットリスク分析の実施です。例えば、定期的に実行する各PCI DSS要件などは実行頻度に柔軟性があるといえますが、これらについては文書化され、なおかつ、適切なターゲットリスク分析によって運用の実施頻度を決定しなければなりません。
保護の対象となる資産を特定し、要件が保護する脅威を特定、脅威の可能性や影響に寄与する要因の特定などが必要です。
要件12.3.1準拠のためには想定される脅威に対応するために必要な頻度で要件を実行することが重要ですが、その正当性を含む分析も求められます。
なお、他の要件についても、要件12.3.1で定めている要素に従って行うターゲットリスク分析で定義したリスクに基づき対処しなければならないものが多々あります。
そのため、重要な要件の一つといえるでしょう。
PCI DSS Ready Cloudでは、PCI DSS v4.0への効率的な移行支援及び準拠を促進するクラウドサービスを提供しています。
PCI DSSのクラウドサービスならPCI DSS Ready Cloudぜひ、ご相談ください。
構成/監修者
滝村 享嗣 氏
株式会社リンク
セキュリティプラットフォーム事業部 事業部長
群馬県高崎市出身。1999年、新卒で大手商社（情報通信系サービス）に入社。その後、ITベンチャーの営業責任者、ソフトウエアベンチャーの営業/マーケティング/財務責任者に従事。2011年にリンクに入社し、セキュリティプラットフォーム事業の事業責任者として、クレジットカード業界のセキュリティ基準であるPCI DSS準拠を促進するクラウドサービスなどを企画・事業化している。
滝村 享嗣 氏
株式会社リンク
セキュリティプラットフォーム事業部 事業部長
群馬県高崎市出身。1999年、新卒で大手商社（情報通信系サービス）に入社。その後、ITベンチャーの営業責任者、ソフトウエアベンチャーの営業/マーケティング/財務責任者に従事。2011年にリンクに入社し、セキュリティプラットフォーム事業の事業責任者として、クレジットカード業界のセキュリティ基準であるPCI DSS準拠を促進するクラウドサービスなどを企画・事業化している。
この記事をシェアする
Copyright by LINK, INC.