PCI DSS v3.2 セキュリティ基準の内容を構造化してみた

概要#

• PCIセキュリティ基準の準拠項目を構造化しました。
• ソース
  • 最初は自分でPDFからコピペしていましたが、大変だったのでクラウドソーシングに出して作ってもらいました。
  • 自分が想定していた速度の3倍くらい速かったので、餅は餅屋だなと思いました。

- 要件1：カード会員データを保護するために、ファイアウォールをインストールして構成を維持する:

• 1.1 以下の項目を含むファイアウォールおよびルーター構成基準を確立し、実装する。:
  • 1.1 ファイアウォール/ルーター構成基準および以下で指定されたその他文書を検査し、標準が完全で、以下のように実施されていることを確認する。
• 1.1.1 すべてのネットワーク接続およびファイアウォール/ルーター構成への変更を承認およびテストする正式なプロセス:
  • 1.1.1.a　文書化された手順を調べて、すべてをテストし承認する正式なプロセスがあることを確認する。\n・ネットワーク接続\n・ファイアウォール/ルーター構成への変更
  • 1.1.1.b　ネットワーク接続のサンプルでは、責任者をインタビューし、記録を検査してネットワーク接続が承認されてテストされていることを確認する。
  • 1.1.1.c　ファイアウォールおよびルーター構成に実際に加えられた変更のサンプルを特定し、変更記録と比較して、責任者をインタビューして変更が承認されテストされたことを確認する。
• 1.1.2 ワイヤレスネットワークなど、カード会員データへのすべての接続を示す最新ネットワーク図:
  • 1.1.2.a ネットワーク図を検査してネットワーク構成を観察し、現在のネットワーク図が存在すること、また、その文書がワイヤレスネットワークを含む、カード会員データへの全接続を含んでいることを確認する。
  • 1.1.2.b 責任者をインタビューして、図が最新のものであることを確認する。
• 1.1.3 システムとネットワーク内でのカード会員データのフローを示す最新図。:
  • 1.1.3.a データフロー図を調査し、担当者にインタビューし、図を確認する。\n・システムとネットワークを流れるすべてのカード会員データフローを示している。\n・最新になっているか、必要な環境変更が更新されているか。
• 1.1.4 各インターネット接続、およびDMZ (demilitarized zone)と内部ネットワークゾーンとの間のファイアウォール要件:
  • 1.1.4.a ファイアウォール構成基準を調査し、そこに、各インターネット接続、およびDMZと内部ネットワークゾーンとの間のファイアウォール要件が含まれていることを確認する。
  • 1.1.4.b 現在のネットワーク図が、ファイアウォール構成基準と一致していることを確認する。
  • 1.1.4.c ネットワーク構成を見て、文書化された構成基準とネットワーク図で、各インターネット接続、およびDMZと内部ネットワークゾーンとの間にファイアウォールが設置されているか確認する。
• 1.1.5 ネットワークコンポーネントを論理的に管理するためのグループ、役割、責任に関する記述:
  • 1.1.5.a ファイアウォールおよびルーター構成基準に、ネットワークコンポーネントの管理のためのグループ、役割、責任に関する記述が含まれていることを確認する。
  • 1.1.5.b ネットワークコンポーネントの管理責任者をインタビューし、文書通りに役割と責任が割り当てられていることを確認する。
• 1.1.6 使用が許可されているすべてのサービス、プロトコル、ポートの文書化、および使用が許可されている業務上の理由(安全でないとみなされているプロトコルに実装されているセキュリティ機能の文書化など)。\n安全でないサービス、プロトコル、ポートの例として、FTP、Telnet、POP3、IMAP、SNMP v1 および v2などがある。:
  • 1.1.6.a ファイアウォール/ルーター構成基準に、業務における必要性を含む、すべてのサービス、プロトコル、ポートを文書化したリストが含まれていることを確認する（HTTP（ハイパーテキストプロトコル）、SSL（セキュアソケットレイヤ）、SSH（セキュアシェル）、VPN（仮想プライベートネットワーク）プロトコルなど）。
  • 1.1.6.b 使用が許可されているが安全でないサービス、プロトコル、ポートを識別し、セキュリティ機能が文書化されていることを確認する。
  • 1.1.6.c ファイアウォールとルーターの構成を検査し、文書化されているセキュリティ機能が安全でない各サービス、プロトコル、ポートに実装されていることを確認する。
• 1.1.7 ファイアウォールおよびルーターのルールセットは少なくとも6カ月ごとにレビューされる必要がある:
  • 1.1.7.a ファイアウォール/ルーター構成基準で、ファイアウォールおよびルーターのルールセットを少なくとも 6 カ月ごとにレビューするように要求していることを確認する。
  • 1.1.7.b ルールセットのレビューに関連した文書を検査し、担当者をインタビューすることで、ルールセットが少なくとも 6 カ月ごとにレビューされていることを確認する。
• 1.2 信頼できないネットワークとカード会員データ環境内のすべてのシステムコンポーネントとの接続を制限するファイアウォール/ルーター構成を構築する。\n注：「信頼できないネットワーク」とは、レビュー対象の事業体に属するネットワーク外のネットワーク、または事業体の制御または管理が及ばないネットワーク(あるいはその両方)のことである。:
  • 1.2 ファイアウォール/ルーター構成を調査して、信頼できないネットワークとカード会員データ環境内のシステムコンポーネント間で接続が制限されていることを確認する。
• 1.2.1 着信および発信トラフィックを、カード会員データ環境に必要なトラフィックにし、それ以外のすべてのトラフィックを特定的に拒否する。:
  • 1.2.1.a ファイアウォール/ルーター構成基準を調べて、カード会員データ環境に必要な着信および発信トラフィックが特定されていることを確認する。
  • 1.2.1.b 着信および発信トラフィックが、カード会員データ環境に必要なトラフィックに制限されており、制限が文書化されていることを確認する。
  • 1.2.1.c ファイアウォール/ルーター構成を検査して、たとえば明示の「すべてを拒否」、または許可文の後の暗黙の拒否を使用することで、他のすべての着信および発信トラフィックが明確に拒否されていることを確認する。
• 1.2.2 ルーター構成ファイルをセキュリティ保護および同期化する。:
  • 1.2.2.a ルーター構成ファイルを調べて、不正アクセスからセキュリティ保護されていることを確認する。
  • 1.2.2.b ルーター構成を調べて、同期化されていることを確認する。たとえば、実行（アクティブ）構成ファイルが起動構成（マシンの再起動時に使用）に一致することを確認する。
• 1.2.3 すべてのワイヤレスネットワークとカード会員データ環境の間に境界ファイアウォールをインストールし、ワイヤレス環境からカード会員データ環境へのすべてのトラフィックを拒否または制御するように(そのようなトラフィックが業務上必要な場合)ファイアウォールを構成する。:
  • 1.2.3.a ファイアウォール/ルーター構成を調べて、すべてのワイヤレスネットワークとカード会員データ環境間に境界ファイアウォールがインストールされていることを確認する。
  • 1.2.3.b ファイアウォールが、ワイヤレス環境とカード会員データ環境間のすべてのトラフィックを拒否または、業務上必要な場合、承認されたトラフィックのみ許可することを確認する。
• 1.3 インターネットとカード会員データ環境内のすべてのシステムコンポーネント間の、直接的なパブリックアクセスを禁止する。:
  • 1.3 ファイアウォール/ルーター構成を以下に説明するとおりに調査し、インターネットと内部のカード会員ネットワークセグメントのシステムコンポーネント間に直接アクセスがないことを確認する。システムコンポーネントには、インターネットのチョークルーター、DMZルーターおよびファイアウォール、DMZカード会員セグメント、境界ルーター、内部のカード会員ネットワークセグメントなどが含まれる。
• 1.3.1 DMZ を実装し、承認された公開サービス、プロトコル、ポートを提供するシステムコンポーネントのみへの着信トラフィックに制限する。:
  • 1.3.1 ファイアウォール/ルーター構成を検査し、DMZ が実装され、承認された公開サービス、プロトコル、ポートを提供するシステムコンポーネントのみへの着信トラフィックに制限していることを確認する。
• 1.3.2 着信インターネットトラフィックをDMZ内のIPアドレスに制限する。:
  • 1.3.2 ファイアウォール/ルーター構成を検査し、着信インターネットトラフィックが、DMZ 内の IP アドレスに制限されていることを確認する。
• 1.3.3 インターネットとカード会員データ環境間トラフィックの、すべての直接接続(着信/発信)を使用不可にする。:
  • 1.3.3 ファイアウォール/ルーター構成を検査し、インターネットとカード会員データ環境間トラフィックの直接経路（着信/発信）がないことを確認する
• 1.3.4 アンチスプーフィング対策を実施し、偽の送信元 IP アドレスを検出して、ネットワークに侵入されないようにブロックする。\n（たとえば、内部送信元アドレスを持つインターネットからのトラフィックをブロックするなど）:
  • 1.3.4 ファイアウォールおよびルーター構成を検査し、たとえば、内部アドレスがインターネットからDMZ内へ通過できないなど、スプーフィング対策が実装されていることを確認する。
• 1.3.5 カード会員データ環境からインターネットへの発信トラフィックを禁止する。:
  • 1.3.5 ファイアウォール/ルーター構成を検査し、カード会員データ環境からインターネットへの発信トラフィックが明示的に承認されていることを確認する。
• 1.3.6 動的パケットフィルタリングとも呼ばれる、ステートフルインスペクションを実装する。(ネットワーク内へは、「確立された」接続のみ許可される。):
  • 1.3.6 ファイアウォール/ルーター構成を検査し、ファイアウォールがステートフルインスペクション（動的パケットフィルタリング）を実行することを確認する。（確立された接続のみ許可され、前に確立されたセッションに関連付けられている場合にのみ許可される必要がある。）
• 1.3.7 DMZ やその他の信頼できないネットワークから隔離されている内部ネットワークゾーンで、カード会員データを保存するコンポーネント（データベース）が実装されている。:
  • 1.3.7 ファイアウォール/ルーター構成を検査し、DMZ やその他の信頼できないネットワークから隔離されている内部ネットワークゾーンで、カード会員データを保存するシステムコンポーネントを確認する。
• 1.3.8 プライベート IP アドレスとルーティング情報を許可されていない第三者に開示しない。\n注： IP アドレスを開示しない方法には、以下のものが含まれるが、これらに限定されるわけではない:\n・ネットワークアドレス変換（NAT）\n・カード会員データを保持するサーバをプロキシサーバ/ファイアウォールの背後に配置する。\n・ 登録されたアドレス指定を使用するプライベートネットワークのルートアドバタイズを削除するか、フィルタリングする。\n・ 登録されたアドレスの代わりにRFC1918 アドレス空間を内部で使用する。:
  • 1.3.8.a ファイアウォール/ルーター構成を検査し、プライベート IP アドレスおよび内部ネットワークからインターネットへのルーティング情報を開示しない方法が導入されていることを確認する。
  • 1.3.8.b 担当者のインタビューや文書の調査により、どのプライベートIPアドレスおよび外部事業体へのルーティング情報開示にも許可が必要であることを確認する。
• 1.4 インターネットに直接接続するすべてのモバイルデバイスまたは従業員所有のデバイス（あるいはその両方）で、ネットワークの外側ではインターネットに接続され、またネットワークへのアクセスにも使用されるものに（従業員が使用するラップトップなど）、パーソナルファイアウォールソフトウェアをインストールする。ファイアウォール構成には以下が含まれます。\n• パーソナルファイアウォールソフトウェア専用の構成設定が定義されていること\n• パーソナルファイアウォールソフトウェアがアクティブに実行中であること\n• パーソナルファイアウォールソフトウェアがモバイルデバイスまたは従業員所有のデバイスのユーザによって変更されていないこと:
  • 1.4.a ポリシーと構成基準を調べて以下を確認する：\n• ネットワーク外でインターネットに接続し、ネットワークへのアクセスにも使用される、すべてのモバイルデバイスまたは従業員所有のデバイス（あるいはその両方）にパーソナルファイアウォールソフトウェアが必要とされている\n• パーソナルファイアウォールソフトウェア専用の構成設定が定義されている\n• パーソナルファイアウォールソフトウェアがアクティブに実行するために構成されている\n• パーソナルファイアウォールソフトウェアの構成がモバイルデバイスや従業員所有のデバイスのユーザによって変更できないようになっている
  • 1.4.b モバイルデバイスまたは従業員所有デバイス（またはその両方）を検査して、以下を確認する。\n• パーソナルファイアウォールソフトウェアがインストールされており、組織の構成設定に従って設定されている\n• パーソナルファイアウォールソフトウェアがアクティブに実行中である\n• パーソナルファイアウォールソフトウェアがモバイルデバイスまたは従業員所有のデバイスのユーザによって変更さていない
• 1.5 ファイアウォールの管理に関するセキュリティポリシーと操作手順が文書化および使用されており、影響を受ける関係者全員に知らされていることを確認する。:
  • 1.5 文書を調べ、関係者をインタビューすることで、ファイアウォールの管理に関するセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 要件2：システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない:
  • 2.1 システムをネットワークに導入する前に、必ずベンダ提供のデフォルト値を変更し、不要なデフォルトアカウントを無効にする。\nこれは、オペレーティングシステム、セキュリティサービスを提供するソフトウェア、アプリケーション、システムアカウント、ポイントオブセールス（POS）端末、簡易ネットワーク管理プロトコル（SNMP）コミュニティ文字列で使用されるがこれらに限定されない、すべてのデフォルトパスワードに適用されます。:
    • 2.1.a システムコンポーネントのサンプルを選択し、ベンダ提供のデフォルトのアカウントとパスワードを使用してデバイスへのログオンを試み（システム管理者の協力を得て）、すべてのデフォルトパスワード（オペレーティングシステム、セキュリティサービスを提供するソフトウェア、アプリケーション、システムアカウント、POS 端末、簡易ネットワーク管理プロトコル（SNMP）コミュニティ文字列で使用されるものを含む）が変更されていることを確認する。（ベンダのマニュアルおよびインターネット上のソースを使用して、ベンダ提供のアカウント/パスワードを探す。）
    • 2.1.b システムコンポーネントのサンプルで、すべての不要なデフォルトアカウントを検証する（オペレーティングシステム、セキュリティソフトウェア、アプリケーション、システム、POS 端末、SNMP などで使用されているアカウントを含む） が削除または無効化されていることを確認する。
    • 2.1.c 担当者をインタビューし、関係文書を調べて、以下を確認する。\n• システムをネットワークにインストールする前にすべてのベンダデフォルト（オペレーティングシステム、セキュリティサービスを提供するソフトウェア、アプリケーション、システムアカウント、POS 端末、簡易ネットワーク管理プロトコル（SNMP）コミュニティ文字列のデフォルトパスワード）が変更されている\n• システムがネットワークにインストールされる前にすべての不要なデフォルトアカウント（オペレーティングシステム、セキュリティソフトウェア、アプリケーション、システム、POS 端末、SNMP などで使用されているアカウントを含む） が削除または無効化されている
  • 2.1.1 カード会員データ環境に接続されている、またはカード会員データを伝送するワイヤレス環境の場合、インストール時にすべてのワイヤレスベンダのデフォルト値を変更する。これには、デフォルトのワイヤレス暗号化キー、パスワード、SNMPコミュニティ文字列が含まれる(ただし、これらに限定されない)。:
    • 2.1.1 ワイヤレス環境のベンダデフォルト設定について、次の事項を確認する。
    • 2.1.1.a 担当者をインタビューし、関係文書を調べて、以下を確認する。\n• 暗号化キーがインストール時のデフォルトから変更されていること。\n• 暗号化キーの知識を持つ人物が退社または異動するたびに、そのキーが変更されていること。
    • 2.1.1.b 担当者をインタビューし、ポリシーと手順を調べることで、以下を確認する。\n• デフォルトの SNMP コミュニティ文字列をインストール後に変更する必要があること。\n• アクセスポイントのデフォルトのパスワード/パスフレーズをインストールごとに変更する必要があること。
    • 2.1.1.c システム管理者の協力を得て、ベンダ文書を調べ、ワイヤレスデバイスにログインして、以下を確認する。\n• ワイヤレスデバイスのデフォルトの SNMP コミュニティ文字列が変更されていないこと。\n• アクセスポイントのデフォルトのパスワード/パスフレーズが変更されていないこと。
    • 2.1.1.d ベンダ文書を調べ、ワイヤレス構成設定を観察して、ワイヤレスデバイスのファームウェアが、以下の強力な暗号化をサポートするために更新されていることを確認する。\n• ワイヤレスネットワーク経由の認証\n• ワイヤレスネットワーク経由での送信
    • 2.1.1.e ベンダ文書を調べ、ワイヤレス構成設定を観察することで、必要に応じて、他のセキュリティに関するワイヤレスベンダのデフォルトが変更されたことを確認する。
  • 2.2 すべてのシステムコンポーネントについて、構成基準を作成する。この基準は、すべての既知のセキュリティ脆弱性をカバーし、また業界で認知されたシステム強化基準と一致している必要がある。\n業界で認知されたシステム強化基準のソースには以下が含まれる(これらに限定されない)。\n• Center for Internet Security(CIS)\n• 国際標準化機構(ISO)\n• SysAdmin Audit Network Security(SANS) \nInstitute\n• 米国国立標準技術研究所(NIST):
    • 2.2.a すべてのタイプのシステムコンポーネントについて企業のシステム構成基準を調べて、システム構成基準が、業界で認知されたシステム強化基準と一致していることを確認する。
    • 2.2.b ポリシーを調べ、担当者をインタビューすることで、システム構成基準が、新たな脆弱性の問題が見つかったときに、要件 6.2 で規定されているように更新されていることを確認する
    • 2.2.c ポリシーを調べ、担当者をインタビューすることで、新しいシステムが構成されたときにシステム構成基準が適用され、ネットワークにシステムがインストールされる前にその実装が検証されたことを確認する。
    • 2.2.d システム構成基準に、すべての種類のシステムコンポーネントに対する以下の手順が含まれていることを確認する。\n• すべてのベンダ提供デフォルト値を変更し、不要なデフォルトアカウントを削除する\n• 同じサーバに異なったセキュリティレベルを必要とする機能が共存しないように、1 つのサーバには、主要機能を 1 つだけ実装する\n• システムの機能に必要な安全性の高いサービス、プロトコル、デーモンなどのみを有効にする\n• 安全でないとみなされている必要なサービス、プロトコル、またはデーモンに追加のセキュリティ機能を実装する\n• システムセキュリティのパラメータが、誤用を防ぐために設定されている\n• スクリプト、ドライバ、機能、サブシステム、ファイルシステム、不要なWeb サーバなど、不要な機能をすべて削除する
  • 2.2.1 同じサーバに異なったセキュリティレベルを必要とする機能が共存しないように、1 つのサーバには、主要機能を 1 つだけ実装する。（たとえば、We サーバ、データベースサーバ、DNS は別々のサーバに実装する必要がある。）\n注： 仮想化テクノロジを使用している場合は、1 つの仮想システムコンポーネントに主要機能を 1 つだけ実装する。:
    • 2.2.1.a システムコンポーネントのサンプルを選択し、システム構成を調べて 1 つのサーバに主要機能が 1 つだけ実装されていることを確認する。
    • 2.2.1.b 仮想テクノロジが使用されている場合は、システム構成を調べて、1 つの仮想システムコンポーネントまたはデバイスに主要機能が 1 つだけ実装されていることを確認する。
  • 2.2.2 システムの機能に必要な安全性の高いサービス、プロトコル、デーモンなどのみを有効にする。:
    • 2.2.2.a システムコンポーネントのサンプルを選択し、有効なシステムサービス、デーモン、プロトコルを検査して、必要なサービスまたはプロトコルだけが有効になっていることを確認する。
    • 2.2.2.b 有効になっているが安全でないサービス、デーモン、プロトコルを特定し、担当者をインタビューして、それらが文書化された構成基準に従って正当化されていることを確認する。

• 2.2.3 安全でないとみなされている必要なサービス、プロトコル、またはデーモンにセキュリティ機能を実装する（たとえば、SSH、SFTP、SSL、または IPSec VPN などの安全なテクノロジを使用して、 NetBIOS、ファイル共有、Telnet、FTP などの安全性の低いサービスを保護する:

• 2.2.3.a 構成設定を調べて、安全でないすべてのサービス、デーモン、プロトコルに対するセキュリティ機能が文書化および反映されていることを確認する。
• 2.2.4 システムの誤用を防止するためにシステムセキュリティパラメータを構成する。:
  • 2.2.4.a システム管理者やセキュリティ管理者にインタビューし、システムコンポーネントの一般的なセキュリティパラメータ設定に関する知識があることを確認する。
  • 2.2.4.b システム構成基準を調べて、一般的なセキュリティパラメータ設定が含まれていることを確認する。
  • 2.2.4.c システムコンポーネントのサンプルを選択し、一般的なセキュリティパラメータ設定を調べて、それらが構成基準に従って正しく設定されていることを確認する。
• 2.2.5 スクリプト、ドライバ、機能、サブシステム、ファイルシステム、および不要なWebサーバなど、すべての不要な機能を削除する。:
  • 2.2.5.a システムコンポーネントのサンプルを選択し、構成を調べ、不要な機能（スクリプト、ドライバ、機能、サブシステム、ファイルシステムなど）がすべて削除されていることを確認する。
  • 2.2.5.b. 文書とセキュリティパラメータを調べて、有効な機能が文書化されていて、セキュリティ保護された構成をサポートしていることを確認する。
  • 2.2.5.c. 文書とセキュリティパラメータを調べて、文書化された機能だけがサンプリングされたシステムコンポーネントに存在していることを確認する。
• 2.3 強力な暗号化を使用して、すべてのコンソール以外の管理アクセスを暗号化する。\nWebベースの管理など非コンソール管理アクセスについては、SSH、VPN、またはSSL/TLSなどのテクノロジを使用します。:
  • 2.3 システムコンポーネントのサンプルを選択し、コンソール以外の管理アクセスが、以下によって暗号化されていることを確認する。
  • 2.3.a 各システムへの管理者ログオンを観察し、システム構成を調べて、管理者のパスワードが要求される前に、強力な暗号化メソッドが実行されていることを確認する。
  • 2.3.b サービスおよびパラメータファイルシステムをレビューし、Telnet やその他の安全でないリモートログインコマンドがコンソール外からのアクセスに使用できないことを確認する。
  • 2.3.c 管理者の各システムへのログオンを観察し、Web ベースの管理インタフェースへの管理者アクセスが、強力な暗号方式で暗号化されていることを確認する。
  • 2.3.d ベンダ文書を調べ、担当者をインタビューすることで、使用テクノロジの強力な暗号化が業界のベストプラクティスとベンダの推奨事項に従って導入されていることを確認する
• 2.4 PCI DSS の適用範囲であるシステムコンポーネントのインベントリを維持する:
  • 2.4.a システムのインベントリを調べて、ハードウェアとソフトウェアのコンポーネントリストが維持されており、それぞれの機能/使用に関する説明が含まれていることを確認する。
  • 2.4.b 担当者をインタビューして、文書化されたインベントリが最新状態に保たれていることを確認する。
• 2.5 ベンダデフォルト値およびその他のセキュリティパラメータの管理に関するセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する:
  • 2.5 文書を調べ、関係者をインタビューすることで、ベンダーデフォルトとその他のセキュリティパラメータの管理に関するセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 2.6 共有ホスティングプロバイダは、各事業体のホスト環境およびカード会員データを保護する必要がある。これらのプロバイダは、付録A:「共有ホスティングプロバイダでの追加 PCIDSS 要件」に示されているように、特定の要件を満たす必要がある。:
  • 2.6 共有ホスティングプロバイダの PCI DSS 評価について、「付録 A: 共有ホスティングプロバイダ向けの PCI DSS 追加要件」に詳しく説明されているテスト手順 A.1.1 ～ A.1.4 を実行し、共有ホスティングプロバイダが事業体（加盟店およびサービスプロバイダ）のホスト環境およびデータを保護していることを確認する。
• 要件3：保存されるカード会員データを保護する:
  • 3.1 データ保存および廃棄ポリシー、手順、プロセスを実装し、すべてのカード会員データ（CHD）ストレージに少なくとも以下のものを含めようにすることで保存するカード会員データを最小限に抑える。\n・保存するデータ量と保存期間を、法律上、規則上、業務上必要な範囲に限定する。\n・必要性がなくなった場合のデータを安全に削除するためのプロセス\n・カード会員データの特定のデータ保存要件\n・定義された保存要件を超えるカード会員データを安全に廃棄する四半期ごとのプロセス。:
    • 3.1.a データの保存および廃棄について、ポリシー、手順、プロセスを調べ、少なくとも以下のことが含まれていることを確認する。\n• 以下を含むデータ保存についての、法律上、規制上、業務上の要件\n• カード会員データの保存についての特定の要件（カード会員データは、X の期間、Y という業務上の理由で保存する必要がある、など）。\n• 法律上、規制上、または業務上の理由で不要になったカード会員データの安全な削除\n• カード会員データの保存すべてを対象とする\n• 定義された保存要件を超えるカード会員データを安全に廃棄する四半期ごとのプロセス。
    • 3.1.b 担当者をインタビューして、以下を確認する。\n• 保存されているカード会員データの場所すべてがデータ保存および破棄プロセスに含まれている。\n• カード会員データを見つけて安全に廃棄する四半期ごとの自動または手動プロセスが含まれている。\n• カード会員データのすべての場所に対して四半期ごとの自動または手動プロセスが実施されている。
    • 3.1.c カード会員データを保存するシステムコンポーネントのサンプル\n• ファイルとシステムレコードを調べて、保存されているデータがデータ保存ポリシーで定義された要件を超えていないことを確認する。\n• 削除方法を観察して、データが安全に削除されることを確認する。
  • 3.2 承認後に機密認証データを保存しない（暗号化されている場合でも）。機密認証データを受け取った場合、認証プロセスが完了し次第すべてのデータを復元不可能にする。\n以下の場合に、データが安全に保存される場合は、発行者と企業が、機密認証データを保存するため、発行サービスをサポート可能である。\n• 業務上の理由がある\n• データが安全に保存されている\n機密認証データには、以降の要件 3.2.1～ 3.2.3 で言及されているデータを含む。:
    • 3.2.a サービスの発行をサポートし、機密認証データを保存する\n発行者または会社について、機密認証データの保存に関して業務上の理由があることを確認する。
    • 3.2.b サービスの発行をサポートし、機密認証データを保存する発行者または会社について、データストアとシステム構成を調べて、機密認証データがセキュリティで保存されていることを確認する。
    • 3.2.c その他のすべての事業体では、機密認証データを受信した場合、ポリシーと手順をレビューし、システム構成を調べて、認証後にデータが保存されていないことを確認します。
    • 3.2.d その他のすべての事業体では、機密認証データを受け取った場合、手順をレビューしてデータを安全に削除するプロセスを調べ、データが回復不能であることを確認する。
  • 3.2.1 （カードの背面やチップ上の同等のデータなどにある磁気ストライプの）追跡データの完全な内容を保存しない。このデータは、全トラック、トラック、トラック 1、トラック 2、磁気ストライプデータとも呼ばれます。\n注： 通常の取引過程では、磁気ストライプからの以下のデータ要素を保存する必要が生じる場合があります。\n・ カード会員名\n・プライマリアカウント番号（PAN）\n・ 有効期限\n・ サービスコードリスクを最小限に抑えるため、取引に必要なデータ要素のみを保存します。:
    • 3.2.1 システムコンポーネントのサンプルで、データソースを調べる。これには、以下の項目が含まれるがこれらに限定されない。また、カード裏面の磁気ストライプまたはチップの同等データから得られたトラック内容が、承認後、保存されていないことを確認する。\n・受信トランザクションデータ\n・すべてのログ（トランザクション、履歴、デバッグ、エラーなど）\n・履歴ファイル\n・トレースファイル\n・データベーススキーマ\n・データベースコンテンツ
  • 3.2.2 カードを提示しない取引を検証するために使用された、カード検証コードまたは値（ペイメントカードの前面または背面に印字されている 3 桁または 4 桁の数字）を保存しない。:
    • 3.2.2 システムコンポーネントのサンプルについて、カード前面または署名欄に印字されている 3 桁または 4 桁のカード検証コードまたは値（CVV2、CVC2、CID、CAV2 データ）を含む\n（ただし、これらに限定されない）データソースを調べて、これらが、承認後、保存されないことを確認する。\n・受信トランザクションデータ\n・すべてのログ（トランザクション、履歴、デバッグ、エラーなど）\n・履歴ファイル\n・トレースファイル\n・データベーススキーマ\n・データベースコンテンツ
  • 3.2.3 個人識別番号（PIN）または暗号化されたPINブロックを保存しない。:
    • 3.2.3 システムコンポーネントのサンプルについて、データソースを調べる。これには PIN および暗号化された PIN ブロックが、承認後、保存されないことの確認も含まれる（ただし、これらに限定されない）。\n・受信トランザクションデータ\n・すべてのログ（トランザクション、履歴、デバッグ、エラーなど）\n・履歴ファイル\n・トレースファイル\n・データベーススキーマ\n・データベースコンテンツ
  • 3.3 表示時に PAN をマスクして（最初の 6 桁と最後の 4 桁が最大表示桁数）、業務上の正当な必要性がある関係者だけが PAN 全体を見ることができるようにする。注： カード会員データの表示（法律上、またはペイメントカードブランドによる POS レシート要件など）に関するこれより厳しい要件がある場合は、その要件より優先されることはありません。:
    • 3.3.a PAN の表示をマスクするための、書面によるポリシーと手順を調べて、以下を確認する。\n• PAN 全体の表示へのアクセスを必要とする役割の一覧が、各役割がそのようなアクセス権を持つ必要性の正当な業務上の理由と共に文書化されていること。\n• PAN は、業務上の合法的な必要性により PAN 全体を見る必要がある担当者のみが PAN 全体をできるようにマスクする必要がある。\n• PAN 全体を表示する承認のない役割の者はすべて、マスクされた PAN しか見えなくする。
    • 3.3.b システム構成を調べて、文書化された業務上の必要性のあるユーザ/役割に対してのみ PAN 全体が表示され、他のすべての表示要求に対しては PAN はマスクされることを確認する。
    • 3.3.c PAN の表示（画面、紙のレシートなど）を調べて、業務上の合法的な必要性により PAN 全体を見る必要のある場合を除き、カード会員データを表示する際に PAN がマスクされることを確認する。
  • 3.4 以下の手法を使用して、すべての保存場所でPANを読み取り不能にする(ポータブルデジタルメディア、バックアップメディア、ログを含む)。\n• 強力な暗号化をベースにしたワンウェイハッシュ(PAN全体をハッシュする必要がある)\n• トランケーション(PANの切り捨てられたセグメントの置き換えにはハッシュを使用できない)\n• インデックストークンとパッド(パッドは安全に保存する必要がある)\n• 関連するキー管理プロセスおよび手順を伴う、強力な暗号化\n注： 悪意のある個人がトランケーションされたPANとハッシュ化されたPANの両方を取得した場合、元の PAN を比較的できますができます。ハッシュ化および切り捨てられた PAN の同じバージョンが事業体の環境に存在する場合、元の PAN を再構築するために、ハッシュ化および切り捨てられたバージョンを関連付けることはできないことを確認する追加コントロールを導入する必要があります。:
    • 3.4.a 以下の方法を用いて、ベンダ、システム/プロセスのタイプ、暗号化アルゴリズム（該当する場合）などが記載された、PAN の保護に使用されているシステムに関する文書を調べる。\n• 強力な暗号化技術をベースにしたワンウェイハッシュ\n• トランケーション\n• インデックストークンとパッド(パッドは安全に保存する必要がある)\n• 関連するキー管理プロセスおよび手順を伴う、強力な暗号化
    • 3.4.b データリポジトリのサンプルから複数のテーブルまたはファイルを検査し、PANが読み取り不能になっていることを確認する（平文で保存されていない）。
    • 3.4.c リムーバブルメディア（バックアップテープなど）を検査し、PAN が読み取り不能であることを確認する。
    • 3.4.d 監査ログのサンプルを検査し、PAN が読み取り不能であることを確認する。
  • 3.4.1 （ファイルまたは列レベルのデータベース暗号化ではなく）ディスク暗号化が使用される場合、論理アクセスはネイティブなオペレーティングシステムの認証およびアクセス制御メカニズムとは別に管理する必要がある（ローカルユーザアカウントデータベースや一般的なネットワークログイン資格情報を使用しないなどの方法で）。復号キーがユーザアカウントと\n関連付けられていない:
    • 3.4.1.a ディスク暗号化を使用している場合、構成を調べて、認証プロセスを観察し、暗号化されたファイルシステムへの論理アクセスが、ネイティブなオペレーティングシステムのメカニズムとは別のメカニズムで実装されていることを確認する\n（ローカルユーザアカウントデータベースや一般的なネットワークログイン資格情報を使用しないなどの方法で）。
    • 3.4.1.b プロセスを観察し、担当者をインタビューすることで、暗号化キーが安全に保存されていることを確認する（強力なアクセス制御で適切に保護されているリムーバブルメディアに保存されているなど）。
    • 3.4.1.c 構成を調べて、プロセスを観察することで、どこに保存されている場合でも、リムーバブルメディアのカード会員データが暗号化されていることを確認する。\n注： ディスク暗号化がリムーバブルメディアの暗号化に使用されていない場合は、この媒体に保存されるデータを、他の方法を使って、読み取り不能にする必要があります。
  • 3.5 カード会員データを漏洩と誤用から保護するために使用されるキーを保護するための手順を文書化し、実施する。\n注： この要件は、保存されているカード会員データを暗号化するキーに適用され、またデータ暗号化キーの保護に使用するキー暗号化キーにも適用される。つまり、キー暗号化キーは、少なくともデータ暗号化キーと同じ強度を持つ必要がある。:
    • 3.5 キー管理ポリシーと手順を調べて、プロセスがカード会員データを暗号化したキーを漏洩と誤使用から保護する指定となっており、少なくとも以下を含むことを確認する。\n• 暗号化キーへのアクセスが必要最小限の管理者に制限されている\n• キー暗号化キーが少なくとも保護対象データの暗号化キーと同じ強度を持つ\n• キー暗号化キーがデータ暗号化キーとは別に保存されている\n• キーの保存場所と形式を最小限にし、安全に保存する
  • 3.5.1 暗号化キーへのアクセスを、必要最小限の管理者に制限する。:
    • 3.5.1 ユーザアクセスリストを調査し、キーへのアクセスが必要最小限の管理者に制限されていることを確認する。
  • 3.5.2 カード会員データの暗号化に使用される秘密暗号化キーは、以下のいずれかの形式（複数可）で常時保存する。\n• 少なくともデータ暗号化キーと同じ強度のキー暗号化キーで暗号化されており、データ暗号化キーとは別の場所に保存されている\n• 安全な暗号化デバイス（ホストセキュリティモジュール（HSM）または PTS 承認の加盟店端末装置など）内\n• 業界承認の方式に従う、少なくとも 2 つの全長キーコンポーネントまたはキー共有として\n注： 公開キーがこれらの形式で保存されていることは要求されていません。:
    • 3.5.2.a 文書化された手順を調べて、カード会員データの暗号化に使用される暗号化キーが常に以下のいずれかの形式でのみ存在することを確認する。\n• 少なくともデータ暗号化キーと同じ強度のキー暗号化キーで暗号化されており、データ暗号化キーとは別の場所に保存されている\n• 安全な暗号化デバイス（ホストセキュリティモジュール（HSM）または PTS 承認の加盟店端末装置など）内\n• 業界承認の方式に従う、キーコンポーネントまたはキー共有として
    • 3.5.2.b システム構成とキー保存場所を調べて、カード会員データの暗号化に使用される暗号化キーが常に次のいずれかの形式（複数可）で存在していることを確認する。\n• キー暗号化キー付き暗号化\n• 安全な暗号化デバイス（ホストセキュリティモジュール（HSM）または PTS 承認の加盟店端末装置など）内\n• 業界承認の方式に従う、キーコンポーネントまたはキー共有として
    • 3.5.2.c キー暗号化キーを使用する場合、システム構成とキー保存場所を調べて、以下を確認する。\n• キー暗号化キーが少なくとも保護対象データの暗号化キーと同じ強度を持つ\n• キー暗号化キーがデータ暗号化キーとは別に保存されている
  • 3.5.3 暗号化キーを最小限の場所に保存する。:
    • 3.5.3 キーの保存場所を調べ、プロセスを観察し、必要最小限の場所にキーが保存されていることを確認する。

• 3.6 カード会員データの暗号化に使用される以下の暗号化キーのキー管理プロセスおよび手順をすべて文書化し、実装する。これには、以下が含まれる。\n注：キー管理には多数の業界標準があり、NIST(http://csrc.nist.govを参照)などさまざまなリソースから入手可能である。:

• 3.6.a サービスプロバイダ用の追加手順：サービスプロバイダがカード会員データの伝送に使用するキーを顧客と共有している場合、サービスプロバイダが顧客に提供する文書を調べて、以下の要件 3.6.1〜3.6.8 に従って、顧客のキー（顧客とサービスプロバイダ間でデータを伝送するために使用される）を安全に伝送、保存、変更する方法が記述されていることを確認する。
• 3.6.b カード会員データの暗号化に使用される暗号化キーの管理手順とプロセスを調べて、以下を行う。
• 3.6.1 強力な暗号化キーの生成:
  • 3.6.1.a キー管理手順に、強力なキーの生成方法が指定されていることを確認する。
  • 3.6.1.b キーの生成方法を観察して、強力なキーが生成されることを確認する。
• 3.6.2 安全な暗号化キーの配布:
  • 3.6.2.a キー管理手順に、キーの安全な配布方法が指定されていることを確認する。
  • 3.6.2.b キーを配布する方法を観察し、キーが安全に配布されることを確認する。
• 3.6.3 安全な暗号化キーの保存:
  • 3.6.3.a キー管理手順に、キーの安全な保存方法が指定されていることを確認する。
  • 3.6.3.b キーを保存する方法を観察して、キーが安全に保存されることを確認する。
• 3.6.4 関連アプリケーションベンダまたはキーオーナーが定義し、業界のベストプラクティスおよびガイドライン(たとえば、NIST Special Publication 800-57)に基づいた、暗号化期間の終了時点に到達したキーの暗号化キーの変更。暗号化期間の終了時点とは、たとえば、定義された期間が経過した後、または付与されたキーで一定量の暗号化テキストを作成した後(またはその両方)である。:
  • 3.6.4.aキー管理手順に、使用されている各キータイプ用の暗号化期間の定義が含まれており、定義された暗号化期間の終わりに行うキー変更のプロセスが定義されていることを確認する。
  • 3.6.4.b 担当者をインタビューすることで、定義された暗号化期間の終わりにキーが変更されていることを確認する。
• 3.6.5 クリアテキストキーの知識を持つ従業員が離職したなど、キーの整合性が脆弱になっている場合、またはキーの脆弱性が悪用された可能性がある場合に必要な、キーの破棄または取り替え（アーカイブ、破壊、無効化など）。\n注： 破棄された、または取り替えられた暗号化キーを保持する必要がある場合、そのキーを（たとえば、キー暗号化キーを使用することにより）安全にアーカイブする必要がある。アーカイブされた暗号化キーは、復号/検証の目的のためにのみ使用できます。:
  • 3.6.5.a キー管理手順に、以下のプロセスが指定されていることを確認する。\n• キーの整合性が脆弱になったときのキーの破棄または取り替え。\n• 侵害されたことがわかっているまたは疑われるキーの取り替え。\n• 破棄された、または取り替えられたキーを保持する場合、そのキーが暗号化操作に使用されていないこと。
  • 3.6.5.b　担当者をインタビューすることで、以下のプロセスが実施されていることを確認する。\n• キーの知識を持つ従業員が退職した場合など、キーの整合性が脆弱になったときに必要に応じてキーを破棄する、または取り替える。\n• 侵害されたことがわかっているまたは疑われるキーが取り替えられている。\n• 破棄された、または取り替えられたキーを保持する場合、そのキーが暗号化操作に使用されていないこと。
• 3.6.6 平文暗号化キー管理を手動で操作する場合、キーの知識分割と二重管理を使用する必要がある。\n注： 手動のキー管理操作の例には、キーの生成、伝送、読み込み、保存、破棄などが含まれますが、これらに限定されません:
  • 3.6.6.a 手動の平文キー管理手順に、以下のプロセスが指定されていることを確認する。\n• キー知識の分割により、キーコンポーネントが 2 人以上の管理下に置かれ、各人は自分のキーコンポーネントに関する知識しか持たないようにする。および\n• キーの二重管理により、どのようなキー管理操作を行う場合にも 2 人以上を必要とし、どちらも他方の認証情報（パスワードやキーなど）にアクセスできないようにする。
  • 3.6.6 b 担当者をインタビューするかプロセスを観察して、手動の平文キーが次の方法で管理されていることを確認する。\n• 知識分割、および\n• 二重管理
• 3.6.7 暗号化キーの不正置換の防止。:
  • 3.6.7.a キー管理手順で、キーの不正置換を防止するプロセスが指定されていることを確認します。
  • 3.6.7.b 担当者をインタビューするかプロセスを観察して、キーの不正置換が防止されていることを確認する。
• 3.6.8 暗号化キー管理者が自身の責務を理解し、キー管理者としての責務を受諾する。:
  • 3.6.8.a キー管理手順に、キー管理者が自身の責務を理解し、キー管理者としての責務を受諾したことを示す書面または電子ファイルへの署名を要求するプロセスが指定されていることを確認する。
  • 3.6.8.b キー管理手順に、キー管理者がキー管理者としての責務を理解し、受諾したことを書面または電子的に示す文書または他の証拠を調べる。
• 3.7 保存されているカード会員データを保護するためのセキュリティポリシーと操作手順が文書化および使用されており、影響を受ける関係者全員に知られていることを確認する。:
  • 3.7 文書を調べ、関係者をインタビューすることで、保存されているカード会員データを保護するためのセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 要件4：オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する:
  • 4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、以下のような、強力な暗号化とセキュリティプロトコル（SSL/TLS、IPSEC、SSH など）を使用して保護する。\n• 信頼できるキーと証明書のみを受け入れる\n• 使用されているプロトコルが、安全なバージョンまたは構成のみをサポートしている\n• 暗号化の強度が使用中の暗号化方式に適している\nオープンな公共ネットワークの例として\n以下が挙げられるが、これらに限定されない。\n・インターネット\n・802.11 と Bluetooth（ブルートゥース）を含\nむワイヤレステクノロジ\n・Global System for Mobile communications（GSM） や Code division multiple access（CDMA） などの携帯端末テクノロジ\n・General Packet Radio Service （GPRS）\n・ 衛星通信:
    • 4.1 カード会員データがオープンな公共ネットワーク経由で送受信される場所をすべて特定し、文書化された基準を調べ、システム構成を比較して、すべての場所でセキュリティプロトコルと強力な暗号化が使用されていることを確認する。
    • 4.1.a 文書化されたポリシーと手順を調べて、以下のプロセスが指定されていることを確認する。\n• 信頼できるキーまたは証明書（あるいはその両方）のみが受け付けられている\n• 使用されているプロトコルが安全なバージョンと構成のみをサポートしており、安全でないバージョンや構成がサポートされない\n• 使用中の暗号化手法に、適切な強度の暗号化が実装されている
    • 4.1.b 発信と着信トランザクションのサンプルを選び、トランザクションを実際に観察し、カード会員データが転送中に強力な暗号で暗号化されているかどうかを確認する。
    • 4.1.c キー/証明書を調べて、信頼できるキー/証明書のみが受け付けられていることを確認する。
    • 4.1.d システム構成を調べて、プロトコルの安全な構成のみが使用され、安全でないバージョンまたは構成がサポートされないことを確認する。
    • 4.1.e システム構成を調べて、使用中の暗号化手法に、適切な強度の暗号化が実装されていることを確認する（ベンダの推奨事項/ベストプラクティスを確認する）。
    • 4.1.f SSL/TLS 実装の場合：システム構成を調べて、カード会員データの送受信時に SSL/TLS が有効になっていることを確認する。\nたとえば、ブラウザベースの実装の場合：\n・ ブラウザの URL プロトコルとして HTTPS が表示される\n・カード会員データは、URL に HTTPS が表示される場合にのみ要求される
  • 4.1.1 カード会員データを伝送する、またはカード会員データ環境に接続されているワイヤレスネットワークが、認証および伝送用に強力な暗号化を実装するため、業界のベストプラクティス（IEEE 802.11i 規格など）を使用していることを確認する。\n注： セキュリティ制御としての WEP の使用は、禁止されています。:
    • 4.1.1 カード会員データを伝送する、またはカード会員データ環境に接続されているすべてのワイヤレスネットワークを識別する。文書化されている基準を調べ、システム構成設定と比較して、識別されたすべてのワイヤレスネットワークについて以下を確認する。\n• 業界のベストプラクティス（IEEE 802.11i など）を使用して認証および伝送用の強力な暗号化が実装されている。\n• 認証や送信のセキュリティ制御に弱い暗号化（WEP、SSLバージョン 2.0 以前など）が使用されていない。
  • 4.2 保護されていないPANをエンドユーザメッセージングテクノロジ(電子メール、インスタントメッセージング、チャットなど)で送信しない。:
    • 4.2.a エンドユーザメッセージングテクノロジを使用してカード会員データを送信する場合は、PAN を送信するプロセスを観察し、送信内容のサンプルを調査して、PAN を読み取り不能にするか、強力な暗号化で保護していることを確認する。
    • 4.2.b 文書化されているポリシーを調べ、保護されていないPANがエンドユーザメッセージングテクノロジを介して送信されないことを記したポリシーの存在を確認する。
  • 4.3 カード会員データの伝送を暗号化するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。:
    • 4.3 文書を調べ、関係者をインタビューすることで、カード会員データの伝送を暗号化するためのセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n・ 文書化されている\n・ 使用されている\n・ 影響を受ける関係者全員に知らされている
• 要件5：アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新する:
  • 5.1 悪意のあるソフトウェアの影響を受けやすいすべてのシステム(特にパーソナルコンピュータとサーバ)に、ウィルス対策ソフトウェアを導入する。:
    • 5.1 悪意のあるソフトウェアの影響を受けやすいすべてのオペレーティングシステムタイプを含む、システムコンポーネントのサンプルについて、適用可能なウィルス対策テクノロジが存在する場合は、ウィルス対策ソフトウェアが導入されていることを確認する。
  • 5.1.1 ウィルス対策プログラムが、既知の悪意のあるソフトウェアの全タイプに対して、検出、削除、保護が可能であることを確認する。:
    • 5.1.1 ベンダ文書を読み、ウィルス対策構成を調べて、ウィルス対策プログラムが以下を行うことを確認する\n• 既知の悪意のあるソフトウェアの全タイプを検出する。\n• 既知の悪意のあるソフトウェアの全タイプを削除する。\n• 既知の悪意のあるソフトウェアの全タイプから保護する。\n例として、ウィルス、トロイの木馬、ワーム、スパイウェア、アドウェア、ルートキットなどがあります。
  • 5.1.2 一般的に悪意のあるソフトウェアに影響されないとみなされているシステムでは、定期的に評価して、進化を続けるマルウェアの脅威を特定して評価することで、システムにウィルス対策ソフトウェアが依然として必要ないかどうかを判断する:
    • 5.1.2.b 担当者をインタビューすることで、システムにウィルス対策ソフトウェアが依然として必要ないかどうかを判断するために、進化を続けるマルウェアの脅威の、一般的に悪意のあるソフトウェアに影響されないとみなされているシステムに対する影響が監視されていることを確認する。
  • 5.2 すべてのウィルス対策メカニズムが以下のように維持されていることを確認する。\n• 最新の状態である\n• 定期的にスキャンを行う\n• PCI DSS 要件 10.7 に従って監査ロ\n・保持する:
    • 5.2 すべてのアンチウィルスソフトウェアが最新で、有効に実行されており、監査ログが生成されることを確認するために、以下の項目を確認する。
    • 5.2.a ポリシーと手順を調べて、ウィルス対策ソフトウェアおよび定義を最新状態に保つことが要求されていることを確認する。
    • 5.2.b ソフトウェアのマスタインストールを含め、ウィルス対策構成を調べることで、ウィルス対策メカニズムが以下を満たすことを確認する。\n• 自動更新するように構成されている\n• 定期的にスキャンするように構成されている
    • 5.2.c 悪意のあるソフトウェアの影響を受けやすいすべてのオペレーティングシステムタイプを含む、システムコンポーネントのサンプルについて、以下を確認する。\n• ウィルス対策ソフトウェアと定義が最新である。\n• 定期的なスキャンが実行される。
    • 5.2.d ソフトウェアのマスタインストールを含め、ウィルス対策構成を調べることで、ウィルス対策メカニズムが以下を満たすことを確認する。\n• ウィルス対策ソフトウェアログの生成が有効になっている\n• ログが PCI DSS 要件 10.7 に従って保持されている
  • 5.3 ウィルス対策メカニズムがアクティブに実行されており、経営管理者からケースバイケースで期間を限って特別に許可されない限り、ユーザが無効にしたり変更できないことを確認する。\n注： ウィルス対策ソリューションは、ケースバイケースで経営管理者により許可されたことを前提に、正当な技術上のニーズがある場合に限り、一時的に無効できますす。特定の目的でアンチウィルス保護を無効にする必要がある場合、正式な許可を得る必要があります。アンチウィルス保護が無効になっている間、追加のセキュリティ手段が必要になる場合があります。:
    • 5.3.a ソフトウェアのマスタインストールとシステムコンポーネントのサンプルを含め、ウィルス対策構成を調べることで、ウィルス対策ソフトウェアがアクティブに実行されていることを確認する。
    • 5.3.b ソフトウェアのマスタインストールとシステムコンポーネントのサンプルを含め、ウィルス対策構成を調べることで、ウィルス対策ソフトウェアがユーザによって無効化・変更できないことを確認する。
    • 5.3.c 責任者をインタビューし、プロセスを観察することで、ウィルス対策ソフトウェアは、経営管理者からケースバイケースで期間を限って特別に許可されない限り、ユーザが無効化・変更できないことを確認する。
  • 5.4 マルウェアからシステムを保護するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。:
    • 5.4 文書を調べ、関係者をインタビューすることで、マルウェアからシステムを保護するためのセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 要件6：安全性の高いシステムとアプリケーションを開発し、保守する:
  • 6.1 セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を特定し、新たに発見されたセキュリティの脆弱性にリスクのランク（「高」、「中」、「低」など）を割り当てるプロセスを確立する。\n注： リスクのランク分けは、業界のベストプラクティスと考えられる影響の程度に基づいている必要があります。たとえば、脆弱性をランク分けする基準は、CVSS ベーススコア、ベンダによる分類、影響を受けるシステムの種類などを含む場合があります。\n脆弱性を評価し、リスクのランクを割り当てる方法は、組織の環境とリスク評価戦略によって異なります。リスクのランクは、最小限、環境に対する「高リスク」とみなされるすべての脆弱性を特定するものである必要があります。リスクのランク分けに加えて、環境に対する差し迫った脅威をもたらす、重要システムに影響を及ぼす、対処しないと侵害される危険がある場合、脆弱性は「重大」とみなされます。重要システムの例としては、セキュリティシステム、一般公開のデバイスやシステム、データベース、およびカード会員データを保存、処理、送信するシステムなどがあります。:
    • 6.1.a ポリシーと手順を調べ、以下のプロセスが定義されていることを確認する。\n• 新しいセキュリティの脆弱性の識別\n• すべての「高」リスクと「重大」な脆弱性の識別を含む脆弱性のランク分けの割り当て\n• セキュリティ脆弱性情報の信頼できる外部情報源の使用
    • 6.1.b 担当者をインタビューするかプロセスを観察して、以下を確認する。\n• 新しいセキュリティの脆弱性が識別されている\n• すべての「高」リスクと「重大」な脆弱性の識別を含む脆弱性のランク分けが割り当てられている\n• 新しいセキュリティの脆弱性を特定するプロセスに、セキュリティ脆弱性情報を得るための外部情報源の使用が含まれている
  • 6.2 すべてのシステムコンポーネントとソフトウェアに、ベンダ提供のセキュリティパッチがインストールされ、既知の脆弱性から保護されている。重要なセキュリティパッチは、リリース後 1 カ月以内にインストールする。\n注： 要件 6.1 で定義されているリスクのランク分けプロセスに従って、重要なセキュリティパッチを識別する必要があります:
    • 6.2.a セキュリティパッチのインストールに関連したポリシーと手順を調べて、以下のプロセスが定義されていることを確認する。\n• 該当する、ベンダ提供の重要セキュリティパッチは、リリース後 1 カ月以内にインストールする。\n• 該当する、ベンダ提供のセキュリティパッチをすべて、適切な時間枠内（3 カ月以内など）にインストールする。
    • 6.2.b システムコンポーネントおよび関連ソフトウェアのサンプルについて、各システムにインストールされたセキュリティパッチのリストと、ベンダの最新のセキュリティパッチのリストを比較して、以下を確認する。\n• 該当する、ベンダ提供の重要セキュリティパッチは、リリース後1 カ月以内にインストールする。\n• 該当するすべてのベンダが提供するセキュリティパッチは、適切な時間枠（たとえば 3 カ月以内）内に設置されている。
  • 6.3 内部および外部ソフトウェアアプリケーション（アプリケーションへの Webベースの管理アクセスを含む）を次のように開発する。\n• PCI DSS （安全な認証やロギングなど）に従って。\n• 業界基準やベストプラクティスに基づいて。\n• ソフトウェア開発ライフサイクル全体に情報セキュリティを組み込む。\n注：これは、社内開発ソフトウェアすべて、および第三者によって開発されたカスタムソフトウェアにも当てはまります。:
    • 6.3.a 文書化されたソフトウェア開発プロセスを調べて、プロセスが業界標準またはベストプラクティス（あるいはその両方）に基づいていることを確認する。
    • 6.3.b 記述されたソフトウェア開発プロセスを検査し、ライフサイクル全体に情報セキュリティが組み込まれていることを確認する。
    • 6.3.c 記述されたソフトウェア開発プロセスを検査し、PCI DSS に従って、ソフトウェアアプリケーションが開発されていることを確認する。
    • 6.3.d ソフトウェア開発者のインタビューから、文書化されたソフトウェア開発プロセスが実装されていることを確認する。
  • 6.3.1 アプリケーションがアクティブになる前、または顧客にリリースされる前に、テスト/カスタムアプリケーションアカウント、ユーザ ID、パスワードを削除する:
    • 6.3.1 文書化されたソフトウェア開発手順を調べ、責任者をインタビューすることで、本番前とカスタムアプリケーションアカウント、ユーザ ID/パスワードが、システムが本番環境に導入される、または顧客にリリースされる前に削除されることを確認する。
  • 6.3.2 コーディングの脆弱性がないことを確認するための、本番または顧客のリリース前のカスタムコードのレビューする（手動または自動プロセスによる）。\n・コード変更は、コード作成者以外の、コードレビュー手法と安全なコーディング手法の知識のある人がレビューする。\n・ コードレビューにより、コードが安全なコーディングガイドラインに従って開発されたことが保証される\n・ リリース前に、適切な修正を実装している。\n・ コードレビュー結果は、リリース前に管理職によってレビューおよび承認される。\n注： このコードレビュー要件は、システム開発ライフサイクルの一環として、すべてのカスタムコード（内部および公開）に適用される。\nコードレビューは、知識を持つ社内担当者または第三者が実施できる。一般に公開されている Web アプリケーションは、実装後の脅威および脆弱性に対処するために、PCI DSS 要件 6.6 に定義されている追加コントロールの対象となる。:
    • 6.3.2.a ポリシーを入手してレビューし、すべてのカスタムアプリケーションコードの変更に対して、(手動または自動プロセスで)以下のようにレビューが要求されていることを確認する。\n• コード変更は、コード作成者以外の、コードレビュー手法と安全なコーディング手法の知識のある人がレビューする。\n• コードレビューにより、コードが安全なコーディングガイドラインに従って開発されたことが保証される(PCI DSS要件6.5を参照)。\n• リリース前に、適切な修正を実装している。\n• コードレビュー結果は、リリース前に管理職によってレビューおよび承認される。
    • 6.3.2.b 最近のカスタムアプリケーションの変更についてサンプルを選択し、そのカスタムアプリケーションコードが上記6.3.2.aに従ってレビューされていることを確認する。
  • 6.4 システムコンポーネントへのすべての変更において、変更管理のプロセスおよび手順に従う。これらのプロセスには、以下を含める必要がある。:
    • 6.4 ポリシーと手順を調べ、以下が定義されていることを確認する。\n• 開発/テスト環境が、本番環境から分離されていて、分離を実施するためのアクセス制御が行われていること\n• 開発/テスト環境に割り当てられている担当者と本番環境に割り当てられている担当者との間で責務が分離されていること\n• テストまたは開発に本番環境データ（実際の PAN）を使用しないこと。\n• 本番環境システムがアクティブになる前にテストデータとテストアカウントが削除されること\n• セキュリティパッチやソフトウェアの変更の実装に関連する変更管理手順が文書化されていること
  • 6.4.1 開発/テスト環境を本番環境から分離し、分離を実施するためのアクセス制御を行う。:
    • 6.4.1.a ネットワーク文書とネットワークデバイス構成を調べて、開発/テスト環境が本番環境から分離されていることを確認する。
    • 6.4.1.b アクセス制御設定を調べて、開発/テスト環境と本番環境の分離を強制するためのアクセス制御が行われていることを確認する。
  • 6.4.2 開発/テスト環境と本番環境での責務の分離:
    • 6.4.2 プロセスを観察し、開発/テスト環境に割り当てられている担当者と本番環境に割り当てられている担当者をインタビューすることで、開発/テスト環境と本番環境の責務が分離されていることを確認する。
  • 6.4.3 テストまたは開発に本番環境データ(実際のPAN)を使用しない:
    • 6.4.3.a テストプロセスを観察し、担当者をインタビューすることで、本番環境データ（実際の PAN）がテストまたは開発に使用されていないことを確認する。
    • 6.4.3.b テストデータのサンプルを観察して、本番環境データ（実際の PAN）がテストまたは開発に使用されていないことを確認する。
  • 6.4.4 本番環境システムがアクティブになる前にテストデータとテストアカウントを削除する:
    • 6.4.4.a テストプロセスを観察し、担当者をインタビューすることで、本番環境システムがアクティブになる前にテストデータとアカウントが削除されることを確認する。
    • 6.4.4.b 最近インストールされたか更新された本番システムからのデータとアカウントのサンプルを調べて、本番環境システムがアクティブになる前にテストデータとアカウントが削除されることを確認する。
  • 6.4.5 セキュリティパッチの適用とソフトウェアの変更に関する変更管理手順は以下を含む必要がある。:
    • 6.4.5.a セキュリティパッチやソフトウェアの変更の実装に関する文書化された変更管理手順を調べて、以下の手順が定義されていることを確認する。\n• 影響の文書化\n• 適切な権限を持つ関係者による文書化された変更承認。\n• 変更がシステムのセキュリティに悪影響を与えていないことを確認するための機能テスト\n• 回復手順
    • 6.4.5.b システムコンポーネントのサンプルについて、責任者をインタビューすることで、最新の変更/セキュリティパッチを確認し、それらの変更内容に関連する変更管理文書を確認する。確認した変更内容について、以下を実行する。
  • 6.4.5.1 影響の文書化。:
    • 6.4.5.1 サンプリングした変更で、影響の文書化が変更管理文書に含まれていることを確認する。
  • 6.4.5.2 適切な権限を持つ関係者による文書化された変更承認。:
    • 6.4.5.2 サンプリングした変更で、適切な権限を持つ関係者による文書化された変更承認が存在していることを確認する。
  • 6.4.5.3 変更がシステムのセキュリティに悪影響を与えないことを確認するための機能テスト。:
    • 6.4.5.3.a サンプリングした各変更で、変更がシステムのセキュリティに悪影響を与えないことを確認するため、機能テストが実施されたことを確認する。
    • 6.4.5.3.b カスタムコードの変更では、すべての更新を本番環境に導入する前に、PCI DSS の要件 6.5 に従って準拠がテストされていることを確認する。
  • 6.4.5.4 回復手順。:
    • 6.4.5.4 サンプリングした各変更で、回復手順が準備されていることを確認する。
  • 6.5 次のようにしてソフトウェア開発プロセスで一般的なコーディングの脆弱性に対応する。\n• 開発者に安全なコーディング技法のトレーニングをする\n• 一般的なコーディングの脆弱性を避け、機密データをメモリで扱う方法を理解することを含め、安全なコーディングガイドラインに基づいてアプリケーションを開発する\n注： 要件6.5.1～6.5.11に挙げられている脆弱性は、このバージョンの PCI DSSが発行された時点の最新の業界ベストプラクティスを踏襲しているが、しかし、脆弱性管理のための業界のベストプラクティスは更新されているため（OWASPガイド、SANS CWE Top 25、CERT\nSecure Coding など）、現在のベストプラクティスは、これらの要件を使用する必要がある。:
    • 6.5.a ソフトウェア開発ポリシーと手順を調べ、プロセスが、業界のベストプラクティスとガイダンスに基づき、開発者のための安全なコーディング技法についてトレーニングを要求していることを確認する。
    • 6.5.b 数人の開発者をインタビューし、安全なコーディング技法に精通していることを確認する。
    • 6.5.c トレーニング記録を調べて、ソフトウェア開発者が、一般的なコーディングの脆弱性を避け、機密データをメモリで扱う方法を理解することを含め、安全なコーディング技法についてのトレーニングを受けたことを確認する。
    • 6.5.d アプリケーションを少なくとも以下の脆弱性から保護するためのプロセスが存在することを確認する。\n注：以下の要件 6.5.1 から 6.5.6 は、すべてのアプリケーション\n（内部または外部）に適用されます。
  • 6.5.1 インジェクションの不具合（特にSQL インジェクション）。OS コマンドインジェクション、LDAP およびXpath のインジェクションの不具合、その他のインジェクションの不具合も考慮する。:
    • 6.5.1 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、以下を含め、コーディング技法によってインジェクションの不具合が対処されていることを確認する。\n• 入力を調べて、ユーザデータがコマンドとクエリの意味を変更できないことを確認する\n• パラメータ化クエリを使用する
  • 6.5.2 バッファオーバーフロー:
    • 6.5.2 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、以下を含め、コーディング技法によってバッファオーバーフローが対処されていることを確認する。\n• バッファ境界を検証する\n• 入力文字列をトランケーションする
  • 6.5.3 安全でない暗号化保存:
    • 6.5.3 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、以下を含め、コーディング技法によって安全でない暗号化保存が対処されていることを確認する。\n• 暗号化の不具合を防止する\n• 強力な暗号化アルゴリズムとキーを使用する
  • 6.5.4 安全でない通信:
    • 6.5.4 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、安全でない通信がすべての機密情報の通信を適切に認証して暗号化するコーディング技法によって対処されていることを確認する
  • 6.5.5 不適切なエラー処理:
    • 6.5.5 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、不適切なエラー処理が、エラーメッセージを通して情報を漏洩しないコーディング技法によって対処されていることを確認する（たとえば、具体的なエラー情報ではなく汎用エラーメッセージを返すなど）
  • 6.5.6 脆弱性特定プロセス（PCI DSS要件 6.1 で定義）で特定された、すべての「高リスク」脆弱性。:
    • 6.5.6 コーディング技法により、アプリケーションを侵害する可能性のある、PCI DSS 要件 6.1 で特定されたすべての「高リスク」脆弱性に対処する。\n- 注：以下の要件6.5.7～6.5.10は、Webアプリケーションとアプリケーションインターフェース(内部または外部)に適用される。
  • 6.5.7 クロスサイトスクリプティング(XSS):
    • 6.5.7 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、以下を含め、コーディング技法によってクロスサイトスクリプティング（XSS）が対処されていることを確認する。\n• 取り込む前にすべてのパラメータを検証\n• コンテキスト依存エスケープの使用
  • 6.5.8 不適切なアクセス制御（安全でないオブジェクトの直接参照、URL アクセス制限の失敗、ディレクトリトラバーサル、機能へのユーザアクセス制限の失敗など）:
    • 6.5.8 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、不適切なアクセス制御（安全でないオブジェクトの直接参照、URL アクセス制限の失敗、ディレクトリトラバーサルなど）が以下を含むコーディング技法によって対処されていることを確認す。\n•ユーザの適切な認証\n• 入力値の削除\n• 内部オブジェクト参照をユーザに公開しない\n• ユーザインタフェースで無許可の機能へのアクセスを許可しない
  • 6.5.9 クロスサイトリクエスト偽造(CSRF):
    • 6.5.9 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、クロスサイトリクエスト偽造（CSRF）は、アプリケーションがブラウザから自動的に送信された認証情報とトークンに依存しないコーディング技法によって対処されていることを確認する。
  • 6.5.10 不完全な認証管理とセッション管理\n注： 要件 6.5.11 は、2015 年 6 月 30 日まではベストプラクティスとみなされ、それ以降は要件になる。:
    • 6.5.10 ソフトウェア開発ポリシーと手順を調べ、責任者をインタビューすることで、以下を含め、コーディング技法によって不完全な認証管理とセッション管理が対処されていることを確認する。\n• セッショントークン（クッキーなど）を「安全」としてフラグ付けする\n• URL にセッションを含めない\n• ログイン後の適切なタイムアウトとセッション ID の巡回\n• ユーザ ID とパスワードがアプリケーションアカウント機能を使って上書きできなくする
  • 6.6 一般公開されているWebアプリケーションで、継続的に新たな脅威や脆弱性に対処し、これらのアプリケーションが、次のいずれかの方法によって、既知の攻撃から保護されていることを確認する。\n・一般公開されているWeb アプリケーションは、アプリケーションのセキュリティ脆弱性を\n手動/自動で評価するツールまたは手法によって、少なくとも年 1 回および何らかの変更を加えた後にレビューする\n注： この評価は、要件 11.2 で実施する脆弱性スキャンとは異なる。\n・Web ベースの攻撃を検知および回避するために、一般公開されている Web アプリケーションの手前に、Web アプリケーションファイアウォールをインストールする。:
    • 6.6 一般公開されているWebアプリケーションについて、以下のいずれかの手法がとられていることを確認する。\n・ 文書化されているプロセスを調べ、担当者をインタビューして、アプリケーションセキュリティ評価記録を見ることで、一般公開されている Web アプリケーションが（セキュリティ脆弱性を手動/自動で評価するツールまたは手法を使用して）以下のようにレビューされていることを確認する。\n- 少なくとも年に一度実施する\n- 何らかの変更を加えた後\n- アプリケーションのセキュリティを専門とする組織によって\n- 評価に少なくとも要件 6.5 に記載されている脆弱性を含める\n- 脆弱性がすべて修正されている\n- 修正後、アプリケーションが再評価されている\n・防止する技術的な解決策（Web アプリケーションファイアウォールなど）が以下の通り備わっていることを確認する。\n- Web ベースの攻撃を検知および防止するために、一般公開されている Web アプリケーションの手前にインストールされている\n- アクティブに実行されており、最新状態である（該当する場合）\n- 監査ログを生成する\n- Web ベースの攻撃をブロックするか、アラートを生成する
  • 6.7 セキュアシステムとアプリケーションを開発・保守するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。
    • 6.7 文書を調べ、関係者をインタビューすることで、安全なシステムとアプリケーションを開発・保守するためのセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 要件7：カード会員データへのアクセスを、業務上必要な範囲内に制限する:
  • 7.1 システムコンポーネントとカード会員データへのアクセスを、業務上必要な人に限定する。:
    • 7.1.a アクセス制御に関する文書化されたポリーを入手して検討し、ポリシーが以下のように 7.1.1〜7.1.4 を含んでいることを確認する。\n• 各役割のアクセスニーズと特権割り当てを定義する\n• 特権ユーザ ID に与えるアクセス権が、職務の実行に必要な最小限の特権に制限されていること\n• 特権の付与は、個人の職種と職務に基づくこと\n• すべてのアクセスに対して、権限を持つ関係者による、許可された特権のリストを含む、文書化された承認（書面または電子的）
  • 7.1.1 以下を含む、各役割のアクセスニーズを定義する\n• 各役割が職務上アクセスする必要のあるシステムコンポーネントとデータリソース\n• リソースへのアクセスに必要な特権レベル（ユーザ、管理者など）:
    • 7.1.1 役割のサンプルを選択し、各役割のアクセスニーズが定義されており、以下を含むことを確認する。\n• 各役割が職務上アクセスする必要のあるシステムコンポーネントとデータリソース\n• 各役割が職務を遂行するために必要な特権の特定
  • 7.1.2 特権ユーザ ID に与えるアクセス権を職務の実行に必要な最小限の特権に制限する。:
    • 7.1.2.a アクセス権の割り当ての責任者をインタビューすることで、特権ユーザ ID へのアクセスが以下を満たしていることを確認する。\n• そのようなアクセス権を特に必要とする役割にのみ割り当てられる\n• 職務の実行に必要な最小限の特権に制限されている
    • 7.1.2.b アクセス権を持つユーザ ID のサンプルを選択し、管理責任者をインタビューすることで、割り当てられた特権が以下を満たすことを確認する。\n• そのユーザの職務に必要\n• 職務の実行に必要な最小限の特権に制限されている
  • 7.1.3 個人の職種と職務に基づくアクセス権の割り当てる。:
    • 7.1.3 ユーザ ID のサンプルを選択し、管理責任者をインタビューすることで、割り当てられた特権がその個人の職種と職務に基づいていることを確認する。
  • 7.1.4適切な権限を持つ関係者による文書化された変更承認を必要とする。:
    • 7.1.4 ユーザ ID を選択し、文書化された承認と比較することで、以下を確認する。\n• 割り当てられた特権に対する文書化された承認が存在する\n• その承認は権限のある関係者によるものである\n• 指定された特権がその個人に割り当てられた役割に一致している
  • 7.2 システムコンポーネントで、ユーザの必要性に基づいてアクセスが制限され、特に許可のない場合は「すべてを拒否」に設定された、アクセス制御システムを確立する。\nアクセス制御システムには以下の項目を含める必要がある。:
    • 7.2 システムの設定とベンダの文書を検査し、アクセス制御システムが以下のように実装されていることを確認する。
  • 7.2.1 すべてのシステムコンポーネントを対象に含む:
    • 7.2.1 アクセス制御システムがすべてのシステムコンポーネントに実装されていることを確認する。
  • 7.2.2 職種と職能に基づく、個人への特権の付与:
    • 7.2.2 アクセス制御システムが、職種と職務に基づいて個人に割り当てられる特権を強制するよう構成されていることを確認する。
  • 7.2.3 デフォルトでは「すべてを拒否」の設定:
    • 7.2.3 アクセス制御システムに「すべてを拒否」がデフォルト設定されていることを確認する。
  • 7.3 カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。:
    • 7.3 文書を調べ、担当者をインタビューすることで、カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 要件8：コンピュータにアクセスできる各ユーザに一意のIDを割り当てる:
  • 8.1 ポリシーと手順を定義して実装することで、次のように、すべてのシステムコンポーネントで、非消費者ユーザと管理者のための適切なユーザ識別および認証の管理が行われるようにする。:
    • 8.1.a 手順を調べて、以下の 8.1.1 ～ 8.1.8 の各項目についてのプロセスが定義されていることを確認する。
    • 8.1.b 以下を実行することによって、ユーザ識別管理のための手順が実施されていることを確認する。
  • 8.1.1 システムコンポーネントまたはカード会員データへのアクセスを許可する前に、すべてのユーザに一意のIDを割り当てる。:
    • 8.1.1 管理責任者をインタビューすることで、すべてのユーザに、システムコンポーネントまたはカード会員データにアクセスするための一意のIDが割り当てられていることを確認する。
  • 8.1.2 追加、削除、ユーザ ID の変更、資格情報、およびその他の識別オブジェクトを管理する。:
    • 8.1.2 特権ユーザ ID と一般ユーザ ID について、関連付けられている権限を調べ、システム設定を観察して、各ユーザ ID と特権ユーザ ID に、文書化されている承認内容で指定されている特権のみが実装されていることを確認する。
  • 8.1.3 契約終了したユーザのアクセスを直ちに取り消す。:
    • 8.1.3.a 過去 6 カ月間に契約終了したユーザのサンプルを選択し、現在のユーザアクセスリストを調べて、– ローカルとリモートアクセス両方につき – これらのユーザの ID が無効化または削除されていることを確認する。
    • 8.1.3.b スマートカード、トークンなど、すべての物理的認証方法が返還されたか、無効にされたことを確認する。
  • 8.1.4少なくとも 90 日ごとに非アクティブなユーザアカウントを削除/無効にする。:
    • 8.1.4 ユーザアカウントを観察することで、90 日間を超える非アクティブなアカウントが削除または無効になっていることを確認する。
  • 8.1.5 ベンダがリモートアクセス経由でシステムコンポーネントのアクセス、サポート、メンテナンスに使用するユーザ ID を以下のように管理する。\n• 必要な期間内だけ有効になり、使用されていないときは無効になっている。\n• 使用時に監視されている。:
    • 8.1.5.a 担当者をインタビューし、ベンダがシステムコンポーネントのアクセス、サポート、メンテナンスに使用するアカウントを管理するためのプロセスを観察して、ベンダがリモートアクセスに使用するアカウントが以下を満たしていることを確認する。\n• 使用されていないときに無効になっている\n• ベンダが必要なときにのみ有効になり、使用されていない場合は無効になる
    • 8.1.5.b 担当者をインタビューし、プロセスを観察することで、使用中にベンダのリモートアクセスアカウントが監視されていることを確認する。
  • 8.1.6 6 回以下の試行で、ユーザ ID をロックアウトすることによって、アクセスの試行回数を制限する。:
    • 8.1.6.a システムコンポーネントのサンプルで、システム構成設定を調べ、6 回以上無効のログオンを繰り返した場合に、ユーザのアカウントがロックされることを要求するよう、認証パラメータが設定されていることを確認する。
    • 8.1.6.b サービスプロバイダの場合のみの追加の手順、内部プロセスと顧客/ユーザマニュアルをレビューし、実装されたプロセスを観察することで、6 回以上無効のログオンを繰り返した場合に、ユーザのアカウントが一時的にロックされるこを確認する。
  • 8.1.7 最低 30 分間、または管理者がユーザ ID を有効にするまでのロックアウト期間を設定する。:
    • 8.1.7 システムコンポーネントのサンプルで、システム構成設定を調べ、ユーザアカウントがロックアウトされたら、最低 30 分間、または管理者がユーザ ID を有効にするまでのロックアウト状態が続くことを要求するよう、認証パラメータが設定されていることを確認する。
  • 8.1.8 セッションのアイドル状態が 15分を超えた場合、ターミナルまたはセッションを再度アクティブにするため、ユーザの再認証が必要となる。:
    • 8.1.8 システムコンポーネントのサンプルで、システム構成設定を調べ、セッションのアイドル状態が 15 分を超えた場合、ターミナルまたはセッションを再度アクティブにするため、ユーザの再認証が必要となることを確認する。
  • 8.2 一意の ID を割り当てることに加え、すべてのユーザを認証するため、次の方法の少なくとも 1 つを使用することで、すべてのシステムコンポーネント上での顧客以外のユーザと管理者の適切なユーザ認証管理を確認する。\n• ユーザが知っていること（パスワードやパスフレーズなど）\n• トークンデバイスやスマートカードなど、ユーザが所有しているもの\n• ユーザ自身を示すもの（生体認証など）:
    • 8.2ユーザがカード会員データ環境にアクセスするための一意の ID と追加の認証（パスワード/パスフレーズなど）を使用して認証されることを確認するため、次の項目を実行する。\n• 使用される認証方法について記述した文書を調べる。\n• 使用される認証方法の各種類およびシステムコンポーネントの各種類について、認証を調べて、文書に記述された認証方法に従って認証が機能していることを確認する。
  • 8.2.1 強力な暗号化を使用して、すべてのシステムコンポーネントで、送信と保存中に認証情報（パスワード/パスフレーズなど）をすべて読み取り不能とする。:
    • 8.2.1.a ベンダ文書とシステム構成設定を調べて、送信および保存中にパスワードが強力な暗号化によって保護されていることを確認する。
    • 8.2.1.b システムコンポーネントのサンプルに対して、パスワードファイルを調べて、パスワードが保存中に読み取り不能であることを確認する。
    • 8.2.1.c システムコンポーネントのサンプルに対して、データ伝送を調べて、パスワードが保存中に読み取り不能であることを確認する。
    • 8.2.1.d サービスプロバイダ用の追加手順。パスワードファイルを観察して、保存中に顧客のパスワードが読み取れないことを確認する。
    • 8.2.1.e サービスプロバイダ用の追加手順。データの送信を観察して、送信中に顧客のパスワードが読み取れないことを確認する。
  • 8.2.2 パスワードのリセット、新しいトークンの準備、新しいキーの生成など、認証情報を変更する前に、ユーザの身元を確認する。:
    • 8.2.2 認証情報を変更するための認証手順を調べて、セキュリティ担当者を観察して、ユーザが、電話、電子メール、Web、または他の非対面法でパスワードのリセットを要求した場合、パスワードがリセットされる前に、ユーザの身元が確認されていることを確認する。
  • 8.2.3 パスワード/パスフレーズは以下を満たす必要がある。\n• パスワードに 7 文字以上が含まれる\n• 数字と英文字の両方を含む\nあるいは、上記のパラメータに等しい複雑さと強度を持つパスワード/パスフレーズ:
    • 8.2.3a システムコンポーネントのサンプルについて、システム構成設定を調べて、少なくとも以下の強度/複雑さを必要とするようにユーザパスワードのパラメータが設定されていることを確認する。\n• パスワードに 7 文字以上が含まれる\n• 数字と英文字の両方を含む
    • 8.2.3.b サービスプロバイダ用の追加手順。内部プロセスおよび顧客/ユーザ文書を確認して、消費者以外のユーザのパスワードが少なくとも次の強度/複雑さを満たすことが要求されていることを確認する。\n• パスワードに 7 文字以上が含まれる\n• 数字と英字の両方を含む
  • 8.2.4 ユーザパスワード/パスフレーズは、少なくとも90日ごと変更する。:
    • 8.2.4.a システムコンポーネントのサンプルについて、システム構成設定を調べて、少なくとも 90 日ごとにパスワードを変更することを要求するようにユーザパスワードのパラメータが設定されていることを確認する。
    • 8.2.4.b サービスプロバイダ用の追加手順。内部プロセスおよび顧客/ユーザ文書を調べて、以下を確認する。\n• 非消費者ユーザパスワードを定期的に変更することが要求されている\n• 消費者以外のユーザに、いつどのような状況下でパスワードを変更する必要があるかについてのガイダンスが与えられている
  • 8.2.5 これまでに使用した最後の 4 つのパスワード/パスフレーズのいずれかと同じである新しいパスワード/パスフレーズを許可しない。:
    • 8.2.5.a システムコンポーネントのサンプルで、システム構成設定を入手して調べ、新しいパスワードとして、これまでに使用した最後の 4 つのパスワードのいずれかと同じパスワードを指定できないことを要求するユーザパスワードパラメータが設定されていることを確認する。
    • 8.2.5.b サービスプロバイダ用の追加手順。内部プロセスと顧客/ユーザマニュアルを調べて、非消費者ユーザのパスワードがこれまでに使用した 4 つのパスワードのいずれかにできなくなっていることを確認する
  • 8.2.6 初期パスワード/パスフレーズとリセットパスワード/パスフレーズをユーザごとに一意の値にリセットし、初回の使用後直ちに変更する。:
    • 8.2.6 パスワード手順を調べて、新しいユーザの初期パスワードと既存ユーザのリセットパスワードが、各ユーザで一意の値に設定され、初回の使用後に変更されていることを確認する。
  • 8.3 従業員（ユーザと管理者を含む）および第三者（サポートやメンテナンス用のベンダアクセスを含む）によるネットワークへのリモートアクセス（ネットワーク外部からのネットワークレベルアクセス）に 2 因子認証を組み込む。\n注： 2 因子認証では、3 つの認証方法のうち 2 つを認証に使用する必要がある（認証方法については、要件 8.2 を参照）。1 つの因子を 2 回使用すること（たとえば、2 つの個別パスワードを使用する）は、2 因子認証とは見なされない。\n2 因子認証方式の例としては、トークン\n使用の RADIUS（Remote Authentication\nand Dial-In Service）、トークン使用の\nTACACS（Terminal Access Controller\nAcceess Control System）、および 2 因\n子認証を促進する他の方式があります。:
    • 8.3.a リモートアクセスサーバとシステムのシステム構成を調べて、以下に対して 2 因子認証が要求されていることを確認する。\n• 従業員によるすべてのリモートアクセス\n• すべての第三者/ベンダリモートアクセス（サポートやメンテナンス目的でのアプリケーションやシステムコンポーネントへのアクセスを含む）
    • 8.3.b ネットワークにリモート接続する従業員（ユーザや管理者など）のサンプルを観察し、3 つの認証方法のうち 2 つが使用されていることを確認する。
  • 8.4以下を含む認証手順およびポリシーを文書化し、すべてのユーザに通達する。\n• 強力な認証情報を選択するためのガイダンス\n• ユーザが自分の認証情報を保護する方法についてのガイダンス\n• 前に使用していたパスワードを再使用しないという指示\n・パスワードが侵害された疑いがある場合にはパスワードを変更するという指示:
    • 8.4.a 手順を調べ、担当者をインタビューすることで、認証手順とポリシーがすべてのユーザに配布されていることを確認する。
    • 8.4.b ユーザに配布された認証手順とポリシーを調べることで、以下を確認する。\n• 強力な認証情報を選択するためのガイダンス\n• ユーザが自分の認証情報を保護する法方についてのガイダンス\n• 前に使用していたパスワードを再使用しないという指示\n• パスワードが侵害された疑いがある場合にはパスワードを変更するという指示
    • 8.4.c ユーザのサンプルにインタビューし、認証手順およびポリシーに精通していることを確認する。
  • 8.5 次のように、グループ、共有、または汎用の ID やパスワード、または他の認証方法が使用されていない。\n• 汎用ユーザ ID およびアカウントが無効化または削除されている\n• システム管理作業およびその他の重要な機能に対する共有ユーザ ID が存在しない\n• システムコンポーネントの管理に共有および汎用ユーザ ID が使用されていない:
    • 8.5.a システムコンポーネントのサンプルについて、ユーザ ID リストを調べて、以下を確認する。\n• 汎用ユーザ ID が無効化または削除されている\n• システム管理作業およびその他の重要な機能のための共有ユーザ ID が存在しない\n• システムコンポーネントの管理に共有および汎用ユーザ ID が使用されていない
    • 8.5.b 認証ポリシー/手順を調べて、グループおよび共有 ID やパスワードまたは他の認証方法が明示的に禁止されていることを確認する。
    • 8.5.c システム管理者にインタビューし、グループおよび共有 ID やパスワード、または他の認証方法が、要求があっても配布されないことを確認する。
  • 8.5.1 サービスプロバイダに対する追加要件：顧客環境へのアクセス権を持つサービスプロバイダは、各顧客に一意な認証情報（パスワード/パスフレーズなど）を使用する必要がある。\n注： この要件は、複数の顧客環境がホストされている、独自のホスティング環境にアクセスする共有ホスティングプロバイダに適用することを意図していません。\n注： 要件 8.5.1 は、2015 年 6 月 30 日まではベストプラクティスとみなされ、それ以降は要件になる。:
    • 8.5.1 サービスプロバイダ用の追加手続き: 認証ポリシーと手順を調べ、担当者をインタビューすることで、各顧客環境にアクセスするために異なる認証が使用されていることを確認する。
  • 8.6 その他の認証メカニズムが使用されている（たとえば、物理的または論理的セキュリティトークン、スマートカード、証明書など）これらのメカニズムの使用は、以下のように割り当てる必要がある。\n• 認証メカニズムは、個々のアカウントに割り当てなければならず、複数アカウントで共有できない\n• 物理/論理制御により、意図されたアカウントのみがアクセスできるようにする必要がある:
    • 8.6.a 認証ポリシーと手順を調べ、物理セキュリティトークン、スマートカード、証明書などを使用する手順が定義されており以下を含むことを確認する。\n• 認証メカニズムが、個々のアカウントに割り当てられており、複数アカウントで共有されていない\n• 物理/論理制御により、意図されたアカウントのみがアクセスできるようになっている
    • 8.6.b セキュリティ担当者をインタビューすることで、認証メカニズムが、個々のアカウントに割り当てられており、複数アカウントで共有されていないことを確認する。
    • 8.6.c システム構成設定や該当する場合は物理制御を調べて、物理/論理制御により、意図されたアカウントのみがそのメカニズムを使ってアクセスできるようにする制御が実装されていることを確認する。
  • 8.7 カード会員データを含むデータベースへのすべてのアクセス（アプリケーション、管理者、およびその他のすべてのユーザによるアクセスを含む）が以下のように制限されている。\n• データベースへのユーザアクセス、データベースのユーザクエリ、データベースに対するユーザアクションはすべて、プログラムによる方法によってのみ行われる。\n・ データベースへの直接アクセスまたはクエリはデータベース管理者のみに制限される。\n・ データベースアプリケーション用のアプリケーション ID を使用できるのはそのアプリケーションのみである\n（個々のユーザやその他の非アプリケーションプロセスは使用できない）。:
    • 8.7.a データベースおよびアプリケーションの構成設定を調べ、すべてのユーザがアクセスする前に認証されていることを確認する。
    • 8.7.b データベースおよびアプリケーションの構成設定を調べて、データベースでのすべてのユーザアクセス、ユーザのクエリ、およびユーザのアクション（たとえば、移動、コピー、削除）が、プログラムを使用する方法（ストアドプロシージャを介してなど）によってのみ実行されることを確認する。
    • 8.7.c データベースアクセス制御設定とデータベースアプリケーション構成設定を調べて、ユーザの直接アクセスまたはデータベースへのクエリがデータベース管理者に制限されていることを確認する。
    • 8.7.d データベースアクセス制御設定、データベースアプリケーション設定、および関連アプリケーション ID を調べて、アプリケーション ID がアプリケーションによってのみ使用できることを確認する（個々のユーザまたはその他のプロセスでは使用できない）。
  • 8.8 識別と認証に関するセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。:
    • 8.8 文書を調べ、関係者をインタビューすることで、識別と認証に関するセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 要件9：カード会員データへの物理アクセスを制限する:
  • 9.1 適切な施設入館管理を使用して、カード会員データ環境内のシステムへの物理アクセスを制限および監視する。:
    • 9.1 各コンピュータルーム、データセンター、およびカード会員データ環境内のシステムを備えた物理的なエリアで、物理的なセキュリティコントロールが存在することを確認する。\n・バッジ読み取り機または承認済みバッジ、施錠、鍵などのその他のデバイスによってアクセスが管理されていることを確認する。\n・システム管理者がカード会員環境内のランダムに選択したシステムのコンソールにログインするのを観察して、コンソールが不正使用を防止するように「ロック」されていることを確認する。
  • 9.1.1 ビデオカメラやアクセス管理メカニズムを使用して、機密エリアへの個々の物理アクセスを監視する。収集されたデータを確認し、その他のエントリと相関付ける。法律によって別途定められていない限り、少なくとも3カ月間保管する。\n注：「機密エリア」とは、データセンタ、サーバルーム、またはカード会員データを保存、処理、または伝送するシステムが設置されているエリアのこと。これには、小売店のレジなど、POS端末のみが存在するエリアは含まれない。:
    • 9.1.1.a ビデオカメラやアクセス制御メカニズムを使用して、機密エリアへの入退場ポイントを監視する。
    • 9.1.1.b ビデオカメラやアクセス制御メカニズムが改ざんや無効化から保護されていることを確認する。
    • 9.1.1.c ビデオカメラやアクセス管理メカニズムが監視されていて、カメラまたはその他のメカニズムからのデータが少なくとも3カ月間保管されていることを確認する。
  • 9.1.2 物理/論理制御を実施することで、誰でもアクセス可能なネットワークジャックへのアクセスを制限する。\nたとえば、公共の場や訪問者がアクセス可能なエリアにあるネットワークジャックは、無効にしておき、ネットワークへのアクセスが明示的に承認されている場合にのみ有効できる。。または、アクティブなネットワークジャックがあるエリアでは訪問者に常に同行者をつけるプロセスを実施できる。:
    • 9.1.2 責任者をインタビューし、誰でもアクセスできる場所にあるネットワークジャックの場所を観察して、物理/論理制御が備わっており、誰でもアクセスできる場所にあるネットワークジャックへのアクセスを制限していることを確認する。
  • 9.1.3 ワイヤレスアクセスポイント、ゲートウェイ、ハンドヘルドデバイス、ネットワーク/通信ハードウェア、および電気通信回線への物理アクセスを制限する。:
    • 9.1.3 ワイヤレスアクセスポイント、ゲートウェイ、ハンドヘルドデバイス、ネットワーク/通信ハードウェア、および電気通信回線への物理的なアクセスが適切に制限されていることを確認する。
  • 9.2 次のようにオンサイト要員と訪問者を容易に区別できるような手順を開発する。\n・新しいオンサイト要因や訪問者を識別する\n（バッジの使用など）\n・アクセス要件を変更する\n・契約が終了したオンサイト要員や期限切れの訪問者の ID（バッジなど）を無効にする:
    • 9.2.a オンサイト要員および訪問者にバッジを割り当てるためのプロセスと手順を確認して、これらのプロセスに以下が含まれていることを確認する。\n• 新しいバッジを付与すること\n• アクセス要件を変更すること\n• 契約が終了したオンサイト要員と期限切れの訪問者バッジを取り消すこと
    • 9.2.b オンサイト担当者と訪問者を識別し、区別するプロセスを観察し、以下を確認する。\n• 訪問者が明確に識別される\n• オンサイト要員と訪問者を容易に区別できる
    • 9.2.c 識別プロセス（バッジシステムなど）へのアクセスが、許可された担当者に制限されていることを確認する。
    • 9.2.d 使用されている識別方法（ID バッジなど）を調べて、訪問者を明確に識別し、オンサイト担当者と訪問者を簡単に区別できることを確認する。
  • 9.3 オンサイト要員の機密エリアへの物理アクセスを次のように制御する。\n• アクセスが個々の職務に基づいて許可される\n• 職務の終了後直ちにアクセスを無効とし、鍵、アクセスカードなどすべての物理アクセスメカニズムを返還するか無効にする:
    • 9.3.a CDE への物理アクセス権を持つオンサイト要員のサンプルに対して、責任者をインタビューし、アクセス制御リストを見て、以下を確認する。\n• CDE へのアクセスが許可されている\n• アクセスがその個人の職務に必要
    • 9.3.b 関係者による CDE へのアクセスを観察して、すべての関係者は、アクセスを許可される前に、承認が必要であることを確認する。
    • 9.3.c 最近退職した従業員のサンプルを選択し、アクセス制御リストを調べ、その従業員が CDE への物理アクセスを持たないことを確認する。
  • 9.4 訪問者を識別し、承認する手順を実施する。\n手順には、以下を含める必要がある。:
    • 9.4 訪問者の承認とアクセス制御が次のように行われていることを確認する。
  • 9.4.1 訪問者は、カード会員データが処理または保守されているエリアに入る前に承認が行われ、そのエリアにいる間ずっと同行者に付き添われている:
    • 9.4.1.a 手順を観察し、担当者をインタビューすることで、訪問者は、カード会員データが処理または保守されているエリアに入ることが許可される前に承認が行われ、そのエリアにいる間ずっと同行者に付き添われていることを確認する。
    • 9.4.1.b 訪問者 ID バッジまたは他のID の使用を観察して、物理トークンのバッジがカード会員データの処理または保守がされている物理エリアに同行者なしでアクセスできないことを確認する。
  • 9.4.2 訪問者が識別され、オンサイト担当者から明確に区別するための有効期限付きバッジその他の ID を与えられる。:
    • 9.4.2.a 施設内にいる人を観察し、訪問者バッジが使用されていて、訪問者とオンサイト担当者を明確に区別できることを確認する。
    • 9.4.2.b 訪問者のバッジその他の ID が有効期限を過ぎると無効になることを確認する。
  • 9.4.3 施設を出る前、または期限が切れる日にバッジその他の ID の返還を求められる:
    • 9.4.3 施設から出る訪問者を観察して、訪問者が退去時または期限切れのときにバッジその他の ID の返還を求められていることを確認する。
  • 9.4.4 訪問者ログを使用して、カード会員データの保存または送信が行われているコンピュータルームやデータセンターなどの施設への訪問者の行動の物理的監査証跡を保持する。\n訪問者の名前、所属会社、物理アクセスを承認したオンサイト要員をログに記録する。\n法律によって別途定められていない限り、このログを少なくとも3カ月間保管する。:
    • 9.4.4.a カード会員データが保存または伝送されるコンピュータルームやデータセンターだけでなく、施設への物理アクセスの記録にも訪問者ログが使用されていることを確認する。
    • 9.4.4.b ログに以下が含まれていることを確認する。\n• 訪問者名\n• 所属会社\n• 物理アクセスを承認したオンサイト担当者
    • 9.4.4.c ログが 3 カ月以上保持されることを確認する。
  • 9.5 すべての媒体を物理的にセキュリティ保護する。:
    • 9.5 カード会員データを保護する手順に、すべての媒体（コンピュータ、リムーバブル電子媒体、紙の受領書、紙のレポート、FAX を含むがこれらに限定されない）のセキュリティを物理的に保護するための管理が含まれていることを確認する。
  • 9.5.1 バックアップの入った媒体を安全な場所に保管する（代替またはバックアップサイト、商用ストレージ施設などのオフサイト施設が望ましい）。保管場所のセキュリティを少なくとも年に一度確認する:
    • 9.5.1.a 保管場所の物理的なセキュリティを観察して、バックアップメディアの保管が安全であることを確認する。
    • 9.5.1.b 保管場所のセキュリティを少なくとも年に一度レビューしていることを確認する。
  • 9.6 次の項目を含め、あらゆるタイプの媒体を内部または外部に配布する際の厳格な管理を維持する。:
    • 9.6 媒体の配布を管理するためのポリシーが存在し、そのポリシーが、個人に配布されるものを含め、すべての配布媒体に対応していることを確認する。
  • 9.6.1 データの機密性を識別できるように、媒体を分類する。:
    • 9.6.1 データの感度を決定できるように、すべての媒体が分類されていることを確認する。
  • 9.6.2 安全な配達業者または正確に追跡できるその他の方法によって媒体を送付する。:
    • 9.6.2.a 担当者をインタビューし、記録を調べて、施設の外部に送付されるすべての媒体がログに記録され、安全な配達業者または追跡可能なその他の配送方法によって送付されることを確認する。
    • 9.6.2.b すべての媒体の数日分のオフサイト追跡ログの最新サンプルを選択し、追跡の詳細がログに記録されていることを確認する。
  • 9.6.3 安全なエリアから移動されるすべての媒体を管理者が承認していることを確認する\n（媒体が個人に配布される場合を含む）。:
    • 9.6.3 すべての媒体の数日分のオフサイト追跡ログの最新サンプルを選択する。ログを調べ、責任者をインタビューすることで、媒体が安全なエリアから移動される（媒体が個人に配達される場合を含む）たびに適切な管理者の承認が得られていることを確認する。
  • 9.7 媒体の保管およびアクセスについて、厳密な管理を維持する。:
    • 9.7 すべての媒体の保管と維持を管理するためのポリシーを入手して調べ、ポリシーで定期的な媒体の在庫調査が要求されていることを確認する
  • 9.7.1 すべての媒体の在庫ログを保持し、少なくとも年に一度、媒体の在庫調査を実施する:
    • 9.7.1 媒体の在庫ログを調べて、媒体の在庫調査が少なくとも年に一度行われていることを確認する。
  • 9.8 次のように、ビジネスまたは法律上不要になった媒体を破棄する。:
    • 9.8 定期的な媒体破棄ポリシーを調べて、すべての媒体が対象になっており、以下の要件が定義されていることを確認する。\n• ハードコピー資料は再現できないことの合理的な保証が得られるように、クロスカット裁断、焼却、またはパルプ化する必要がある。\n• 破棄する資料を保管する容器は安全でなければならない。\n• 電子媒体上のカード会員データが、安全な削除に関して業界が承認した標準に従った安全なワイププログラムによって、またはそれ以外の場合は媒体の物理的な破壊によって、回復不能になっている必要がある。
  • 9.8.1 カード会員データを再現できないよう、ハードコピー資料を裁断、焼却、またはパルプ化する。破棄する資料を保管する容器を安全に保護する。:
    • 9.8.1.a 担当者をインタビューし、手順を調べて、ハードコピーの資料が再現できないことの合理的な保証が得られるように、クロスカット裁断、焼却、またはパルプ化されていることを確認する。
    • 9.8.1.b 破棄される情報を含む資料の保管に使用されるコンテナを調べて、コンテナが安全に保護されていることを確認する。
  • 9.8.2 カード会員データを再現できないよう、電子媒体上のカード会員データを回復不能にする。:
    • 9.8.2 電子媒体上のカード会員データが、安全な削除に関して業界が承認した標準に従った安全なワイププログラムによって、またはそれ以外の場合は媒体の物理的な破壊によって、回復不能になっていることを確認する。
  • 9.9 カードの物理的な読み取りによってペイメントカードデータを取り込む装置を改ざんや不正置換から保護する。\n注： これには、カード（カードのスワイプやディップ）によるトランザクションに使用されるカード読み取り装置も含まれる。この要件は、コンピュータのキーボードや POS のキーパッドのような手動キー入力コンポーネントには適用されない。\n注： この要件は、2015 年 6 月 30 日まではベストプラクティスとみなされ、それ以降は要件になる。:
    • 9.9 文書化されたポリシーと手順を調べ、以下が含まれていることを確認する。\n• デバイスのリストの管理\n• デバイスを定期的に検査して改ざんや不正置換がないか調べる\n• 関係者にトレーニングを受けさせて、怪しい行動を識別し、デバイスの改ざんや不正置換を報告できるようにする
  • 9.9.1 装置のリストを保持する。リストには以下を含める必要がある。\n• 装置のメーカーと型式\n• 装置の場所（装置が設置されている店舗の住所など）\n• 装置の連番や他の一意識別方法:
    • 9.9.1.a 装置のリストを見て、以下が含まれていることを確認する。\n• 装置のメーカーと型式\n• 装置の場所（装置が設置されている店舗の住所など）\n• 装置の連番や他の一意識別方法
    • 9.9.1.b リストから装置のサンプルを選択して、装置の場所を観察し、リストが正確で最新のものであることを確認する。
    • 9.9.1.c 担当者をインタビューすることで、装置が追加、移動、廃棄された場合に装置のリストが更新されることを確認する。

• 9.9.2 定期的に装置の表面を検査して改ざん（カードスキマーの取り付けなど）や不正置換（連番など装置の特性を調べて偽の装置に差し替えられていないことを確認する）を検出する。\n注： 装置が改ざんされたり不正置換されたりする兆候の例としては、予期していない付着物やケーブルが装置に差し込まれている、セキュリティラベルが無くなっていたり、変更されている、ケースが壊れていたり色が変わっている、あるいは連番その他の外部マーキングが変更されているなどがある:

• 9.9.2.a 文書化された手順を調べて、プロセスに以下が含まれるように定義されていることを確認する。\n• 装置を検査する手順\n• 検査の頻度
• 9.9.2.b 責任者をインタビューし、検査プロセスを観察して、以下を確認する。\n• 関係者が装置を検査する手順を知っている\n• すべての装置が改ざんや不正置換の形跡がないことを定期的に検査されている
• 9.9.3 関係者が装置の改ざんや不正置換の試みを認識できるようにトレーニングを実施する。トレーニングには以下を含める必要がる。\n・保守要員を名乗っている者に装置へのアクセスを許可する前に、身元を確認する。\n• 検証なしで装置を設置、交換、返品しない。\n• 装置の周辺での怪しい行動（知らない人が装置のプラグを抜いたり装置を開けたりする）に注意する\n• 怪しい行動や装置が改ざんや不正置換された形跡がある場合には適切な関係者（マネージャーやセキュリティ要員など）に報告する:
  • 9.9.3.a 販売場所の関係者用トレーニング材料を調べて、以下のトレーニングが含まれていることを確認する。\n・保守要員を名乗っている者に装置への変更、トラブルシューティングのためのアクセスを許可する前に、身元を確認する。\n• 検証なしで装置を設置、交換、返品しない\n• 装置の周辺での怪しい行動（知らない人が装置のプラグを抜いたり装置を開けたりする）に注意する\n• すべての怪しい行動を適切な関係者（マネージャーやセキュリティ要員など）に報告する\n• 怪しい行動や装置が改ざんや不正置換された形跡がある場合には適切な関係者（マネージャーやセキュリティ要員など）に報告する
  • 9.9.3.b 販売場所の関係者のサンプルをインタビューすることで、彼らがトレーニングを受けており、以下の手順を知っていることを確認します。\n・保守要員を名乗っている者に POS 装置への変更、トラブルシューティングのためのアクセスを許可する前に、身元を確認する。\n• 検証なしで装置を設置、交換、返品しない\n• POS 装置の周辺での怪しい行動（知らない人が装置のプラグを抜いたり装置を開けたりする）に注意する\n• 怪しい行動や POS 装置が改ざんや不正置換された形跡がある場合には適切な関係者（マネージャーやセキュリティ要員など）に報告する
• 9.10 カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。:
  • 9.10 文書を調べ、担当者をインタビューすることで、カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知らされている
• 要件10：ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する:
  • 10.1 システムコンポーネントへのすべてのアクセスを各ユーザにリンクする監査証跡を確立する:
    • 10.1 システム管理者の観察とインタビューを通じて、\n• システムコンポーネントに対する監査証跡が有効になっていてアクティブであることを確する\n• システムコンポーネントへのアクセスを各ユーザにリンクする
  • 10.2 次のイベントを再現するために、すべてのシステムコンポーネントの自動監査証跡を実装する。:
    • 10.2 責任者のインタビュー、監査ログの調査、および監査ログ設定の調査を通じて、以下を実行する。
  • 10.2.1 カード会員データへのすべての個人アクセス:
    • 10.2.1 カード会員データへのすべてのアクセスがログに記録されることを確認する。
  • 10.2.2 ルート権限または管理権限を持つ個人によって行われたすべてのアクション:
    • 10.2.2 ルートまたは管理者権限を持つ個人によって実施されたすべてのアクションが記録されていることを確認する。
  • 10.2.3 すべての監査証跡へのアクセス:
    • 10.2.3 すべての監査証跡へのアクセスがログ記録されることを確認する。
  • 10.2.4 無効な論理アクセス試行:
    • 10.2.4 無効な論理アクセス試行が記録されていることを確認する。
  • 10.2 5 識別と認証メカニズムの使用および変更（新しいアカウントの作成、特権の上昇を含むがこれらに限定されない）、およびルートまたは管理者権限を持つアカウントの変更、追加、削除のすべて:
    • 10.2.5.a 識別および認証メカニズムの使用がログに記録されることを確認する。
    • 10.2.5.b 特権の上昇がすべてログに記録されることを確認する
    • 10.2.5.c ルートまたは管理者権限を持つアカウントの変更、追加、または削除がすべてログに記録されていることを確認する
  • 10.2.6 監査ログの初期化、停止、一時停止:
    • 10.2.6 以下がログに記録されていることを確認する。\n• 監査ログの初期化\n• 監査ログの停止と一時停止
  • 10.2.7 システムレベルオブジェクトの作成および削除:
    • 10.2.7 システムレベルオブジェクトの作成および削除がログ記録されることを確認する。
  • 10.3 イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査証跡エントリを記録する。:
    • 10.3 インタビューと観察を通じて、監査可能なイベント(10.2に記載)ごとに、以下を実行する。
  • 10.3.1 ユーザ識別:
    • 10.3.1 ユーザ識別がログエントリに含まれることを確認する。
  • 10.3.2 イベントの種類:
    • 10.3.2 ログエントリにイベントの種類が含まれていることを確する
  • 10.3.3 日付と時刻:
    • 10.3.3 ログエントリに日付と時刻が含まれていることを確認する。
  • 10.3.4 成功または失敗を示す情報:
    • 10.3.4 ログエントリに成功または失敗を示す情報が含まれることを確認する。
  • 10.3.5 イベントの発生元:
    • 10.3.5 ログエントリにイベントの発生元が含まれていることを確認する。
  • 10.3.6 影響を受けるデータ、システムコンポーネント、またはリソースのIDまたは名前:
    • 10.3.6 影響を受けるデータ、システムコンポーネント、またはリソースのIDまたは名前がログエントリに含まれることを確認する。
  • 10.4 時刻同期技術を使用してすべての重要なシステムクロックおよび時間を同期し、時間を取得、配布、保存するために以下の要件が実施されていることを確認する。\n注： ネットワークタイムプロトコル（NTP）は、時刻同期技術の一例である。:
    • 10.4 構成基準とプロセスを調べることで、時刻同期技術が実装され、PCI DSS の要件 6.1 と 6.2 に従って最新状態に保たれていることを確認する。
  • 10.4.1 重要なシステムが正確で一貫性のある時刻を持っている。:
    • 10.4.1.a 組織内で正しい時刻を取得、配布、保存するプロセスを調べて、以下を確認する。\n• 指定した中央タイムサーバが、外部ソースから時刻信号を受信し、外部ソースからの時刻信号は国際原子時または UTC に基づいている。\n• 複数のタイムサーバがある場合、それらのタイムサーバが正確な時刻を保つためにお互いに通信する。\n• システムは時刻情報を指定した中央タイムサーバからのみ受信する。
    • 10.4.1.b システムコンポーネントのサンプルに対して、時刻関係のシステムパラメータ設定を観察して、以下を確認する。\n• 指定した中央タイムサーバが、外部ソースから時刻信号を受信し、外部ソースからの時刻信号は国際原子時または UTC に基づいている\n• 複数のタイムサーバが指定されている場合、指定した中央タイムサーバが正確な時刻を保つためにお互いに通信する\n• システムは時刻情報を指定した中央タイムサーバからのみ受信する
  • 10.4.2 時刻データが保護されている。:
    • 10.4.2.a システム構成および時刻同期設定を調べて、時刻データへのアクセスは、業務上時刻データにアクセスする必要のある担当者のみに制限されていることを確認する。
    • 10.4.2.b システム構成および時刻同期設定とプロセスを調べて、重要なシステムの時刻設定への変更が、ログ記録、監視、およびレビューされていることを確認する。
  • 10.4.3 時刻設定は、業界で認知されている時刻ソースから受信されている。:
    • 10.4.3 システム構成を調べて、タイムサーバが（悪意のある個人が時計を変更するのを防ぐために）業界で認知されている特定の外部ソースから時刻更新を受け付けることを確認する。（内部タイムサーバの不正使用を防ぐために）これらの更新を対称キーで暗号化し、時刻更新が提供されるクライアントマシンの IP アドレスを指定するアクセス制御リストを作成もできる。
  • 10.5 変更できないよう、監査証跡をセキュリティで保護する。:
    • 10.5 システム管理者をインタビューし、システム構成とアクセス権限を調べて、次のように、監査証跡が変更できないようにセキュリティで保護されていることを確認する。
  • 10.5.1 監査証跡の表示を、業務上の必要がある人物のみに制限する。:
    • 10.5.1 業務上の必要がある個人のみが監査証跡ファイルを表示できることを確認する。
  • 10.5.2 監査証跡ファイルを不正な変更から保護する。:
    • 10.5.2 アクセス制御メカニズム、物理的な分離、ネットワークの分離などによって、現在の監査証跡ファイルが不正な変更から保護されていることを確認する。
  • 10.5.3 監査証跡ファイルを、変更が困難な一元管理ログサーバまたは媒体に即座にバックアップする。:
    • 10.5.3 現在の監査証跡ファイルが変更が困難な一元管理ログサーバまたは媒体に即座にバックアップされることを確認する。
  • 10.5.4 外部に公開されているテクノロジのログを、安全な一元管理の内部ログサーバまたは媒体デバイス上に書き込む。:
    • 10.5.4 外部に公開されているテクノロジ（ワイヤレス、ファイアウォール、DNS、メールなど）のログが安全な一元管理される内部ログサーバまたは媒体に書き込まれることを確認する。
  • 10.5.5 ログに対してファイル整合性監視または変更検出ソフトウェアを使用して、既存のログデータを変更すると警告が生成されるようにする(ただし、新しいデータを追加する場合は警告を発生させない)。:
    • 10.5.5 システム設定、監視対象ファイル、および監視作業からの結果を調査して、ログに対してファイル整合性監視または変更検出ソフトウェアが使用されていることを確認する。
  • 10.6 すべてのシステムコンポーネントのログとセキュリティイベントを調べ、異常や怪しい活動を特定する。\n 注： この要件に準拠するために、ログの収集、解析、および警告ツールを使できますす。:
    • 10.6 以下のことを実行します
  • 10.6.1 毎日一度以上以下をレビューす\n• すべてのセキュリティイベン\n• CHD や SAD を保存、処理、または送信する、または CHD や SAD のセキュリティに影響を及ぼす可能性のあるすべてのシステムコンポーネントのログ\n• すべての重要なシステムコンポーネントのログ\n• すべてのサーバとセキュリティ機能のあるシステムコンポーネント（ファイアウォール、侵入検出システム/侵入防止システム（IDS/IPS）、認証サーバ、電子商取引リダイレクションサーバなど）のログ:
    • 10.6.1.a セキュリティポリシーと手順を調べて、手動またはログツールを用いて、以下を少なくとも毎日一度レビューする手順が定義されていることを確認する。\n• すべてのセキュリティイベン\n• CHD や SAD を保存、処理、または送信する、または CHD やSAD のセキュリティに影響を及ぼす可能性のあるすべてのシステムコンポーネントのログ\n• すべての重要なシステムコンポーネントのログ\n• すべてのサーバとセキュリティ機能のあるシステムコンポーネント（ファイアウォール、侵入検出システム/侵入防止システム（IDS/IPS）、認証サーバ、電子商取引リダイレクションサーバなど）のログ
    • 10.6.1.b プロセスを観察し、担当者をインタューすることで、以下が少なくとも毎日一度レビューされていることを確認する。\n• すべてのセキュリティイベント\n• CHD や SAD を保存、処理、または送信する、または CHD やSAD のセキュリティに影響を及ぼす可能性のあるすべてのシステムコンポーネントのログ\n• すべての重要なシステムコンポーネントのログ\n• すべてのサーバとセキュリティ機能のあるシステムコンポーネント（ファイアウォール、侵入検出システム/侵入防止システム（IDS/IPS）、認証サーバ、電子商取引リダイレクションサーバなど）のログ
  • 10.6.2 組織のポリシー、および年間リスク評価によって決定されたリスク管理戦略に基づいて他のシステムコンポーネントすべてのログを定期的にレビューする:
    • 10.6.2.a セキュリティポリシーと手順を調べて、組織のポリシーとリスク管理戦略に基づき定期的に、手動またはログツールを用いて、他のすべてのシステムコンポーネントをレビューする手順が定義されていることを確認する。
    • 10.6.2.b 組織のリスク評価文書を調べ、担当者をインタビューして、レビューが組織のポリシーとリスク管理戦略に従って実施されていることを確認する。
  • 10.6.3 レビュープロセスで特定された例外と異常をフォローアップする。:
    • 10.6.3.a セキュリティポリシーと手順を調べて、レビュープロセスで特定された例外と異常をフォローアップする手順が定義されていることを確認する。
    • 10.6.3.b プロセスを観察し、担当者をインタビューすることで、例外と異常のフォローアップが実施されていることを確認する。
  • 10.7 監査証跡の履歴を少なくとも1年間保持する。少なくとも3カ月はすぐに分析できる状態にしておく(オンライン、アーカイブ、バックアップから復元可能など)。:
    • 10.7.a セキュリティポリシーと手順を調べ、以下が定義されていることを確認する。\n• 監査ログ保存ポリシー\n• 監査ログを少なくとも 1 年間保持し、最低 3 カ月はすぐに使用できる状態にしておくための手順。
    • 10.7.b 担当者をインタビューし、監査ログを調べることで、監査ログが少なくとも1年間利用可能であることを確認する。
    • 10.7.c 担当者をインタビューし、プロセスを観察することで、解析用に、少なくとも過去3カ月分のログが即座に復元できることを確認する
  • 10.8 ネットワークリソースとカード会員データへのすべてのアクセスを監視するためのセキュリティポリシーと操作手順が文書化され、使用されており、影響を受ける関係者全員に知られていることを確認する。:
    • 10.8 文書を調べ、担当者をインタビューすることで、ネットワークリソースとカード会員データへのすべてのアクセスを監視するためのセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知られている
• 要件11：セキュリティシステムおよびプロセスを定期的にテストする:
  • 11.1 四半期ごとにワイヤレスアクセスポイントの存在をテストし（802.11）、すべての承認されているワイヤレスアクセスポイントと承認されていないワイヤレスアクセスポイントを検出し識別するプロセスを実施する\n 注： プロセスで使用される方法には、ワイヤレスネットワークのスキャン、システムコンポーネントおよびインフラストラクチャの論理的/物理的な検査、ネットワークアクセス制御（NAC）、無線 IDS/IPS が含まれるがこれらに限定されるわけではない。\nいずれの方法を使用する場合も、承認されてるデバイスと承認されていないデバイスを両方検出および識別できる機能を十分に備えている必要がある。:
    • 11.1.a ポリシーと手順を調べ、四半期ごとに承認されているワイヤレスアクセスポイントと承認されていないワイヤレスアクセスポイントを両方検出し識別するプロセスが定義されていることを確認する。
    • 11.1.b 方法が、少なくとも以下を含むすべての不正なワイヤレスアクセスポイントを検出して識別するのに十分であることを確認する。\n・ システムコンポーネントに挿入された WLAN カード\n・ ワイヤレスアクセスポイントを作成するためにシステムコンポーネントに（USB などで）接続したポータブルやモバイルデバイス\n・ネットワークポートまたはネットワークデバイスに接続されたワイヤレスデバイス
    • 11.1.c 最近のワイヤレススキャンの出力を調べて、以下を確認する。\n• 承認されているワイヤレスアクセスポイントと承認されていないワイヤレスアクセスポイントが識別される\n• すべてのシステムコンポーネントおよび施設に対し、このスキャンが少なくとも四半期ごとに実施されている
    • 11.1.d 自動監視（ワイヤレス IDS/IPS や NAC など）が使用されている場合は、担当者に通知するための警告が生成されるように構成されていることを確認する。
  • 11.1.1 文書化されている業務上の理由を含め、承認されているワイヤレスアクセスポイントのインベントリを維持する。:
    • 11.1.1 文書化されている記録を調べて、承認されているワイヤレスアクセスポイントのインベントリが維持されており、すべての承認されているワイヤレスアクセスポイントに対して業務上の理由が文書化されていることを確認す
  • 11.1.2 不正なワイヤレスデバイスが検出された場合のインシデント対応計画を実装する。:
    • 11.1.2.a 組織のインシデント計画を調べて（要件 12.9）、承認されていないワイヤレスアクセスポイントが検出された場合に、その応答を定義し、要求していることを確認する。null
    • 11.1.2.b 責任者をインタビューし、最近のワイヤレススキャンと関連応答を調べて、承認されていないワイヤレスアクセスポイントが見つかった場合に対処されていることを確認する。
  • 11.2 内部と外部ネットワークの脆弱性スキャンを少なくとも四半期に一度およびネットワークでの大幅な変更（新しいシステムコンポーネントのインストール、ネットワークトポロジの変更、ファイアウォール規則の変更、製品アップグレードなど）後に実行する。\n注： 四半期ごとのスキャンプロセスの複数のスキャンレポートをまとめて、すべてのシステムがスキャンされ、すべての脆弱性に対処されたことを示すことができる。未修正の脆弱性が対処中であることを確認するために、追加の文書が要求される場合がある。\n初期の PCI DSS 準拠では、評価者が 1）最新のスキャン結果が合格スキャンであったこと、2）事業体で四半期に一度のスキャンを要求するポリシーと手順が文書化されていること、および 3）スキャン結果で判明した脆弱性が再スキャンにおいて示されているとおりに修正されたことを確認した場合、初回のPCI DSS 準拠のために、四半期に一度のスキャンに 4 回合格することは要求されない。\n初回 PCI DSS レビュー以降は毎年、四半期ごとのスキャンに 4 回合格しなければならない。:
    • 11.2 スキャンレポートと関連文書を調べて、内部および外部脆弱性スキャンが、次のように実行されていることを確認する。
  • 11.2.1 すべての「高リスク」脆弱性（要件6.1 で識別）が解決されるまで、必要に応じて四半期ごとの内部脆弱性スキャンを繰り返す。スキャンは有資格者が実施する必要がある。:
    • 11.2.1.a スキャンレポートをレビューし、四半期ごとの内部スキャンが過去 12 カ月間で 4 回行われたことを確認する。
    • 11.2.1.b スキャンレポートをレビューし、スキャンプロセスで再スキャンを行ったこと、または PCI DSS 要件 6.1 で定義されたすべての「高リスク」の脆弱性が解決されるまで再スキャンを行ったことを確認する。
    • 11.2.1.c 担当者をインタビューすることで、スキャンが内部リソースまたは資格のある外部の第三者によって行われたこと、該当する場合は、テスターの組織の独立性（QSA や ASV である必要はない）が存在することを確認する。
  • 11.2.2 四半期に一度の外部の脆弱性スキャンは、PCI（Payment Card Industry）セキュリティ基準審議会（PCI SSC）によって資格を与えられた認定スキャニングベンダ（ASV）によって実行される必要がある。スキャンに合格するまで、必要に応じて再スキャンする。\n注： 四半期に一度の外部の脆弱性スキャンは、PCI（Payment Card Industry）セキュリティ基準審議（PCI SSC）によって資格を与えられた認定スキャニングベンダ（ASV）によって実行される必要がある。\nスキャンにおける顧客の責任、スキャンの準備などについては、PCI SSC Web サイトで公開されている『ASV プログラムガイド』を参照してください。:
    • 11.2.2.a 四半期ごとに行われた最新の 4 回の内部スキャンからの結果をレビューし、過去 12 カ月間で四半期ごとのスキャンが 4回行われたことを確認する。
    • 11.2.2.b 四半期ごとの各スキャンの結果をレビューし、『ASV プログラムガイド』の要件（たとえば、CVSS による 4.0 以上のレートの脆弱性がなく、自動エラーがない）を満たすことを確認する。
    • 11.2.2.c スキャンレポートをレビューし、PCI SSC認定スキャニングベンダ（ASV）がスキャンを完了したことを確認する。
  • 11.2.3 最初の変更があった後の内部と外部脆弱性スキャンを必要に応じて繰り返す。\nスキャンは有資格者が実施する必要がある。:
    • 11.2.3.a 変更管理文書とスキャンレポートを調べて相関させ、大幅な変更の対象となるシステムコンポーネントがスキャンされたことを確認する。
    • 11.2.3.b スキャンレポートをレビューし、スキャンプロセスに、以下の要件を満たすまで再スキャンを実行することが含まれていることを確認する。\n・ 外部スキャンの場合、CVSS スコアで 4.0 以上の脆弱性がないこと。\n・ 内部スキャンの場合、合格結果が取得されること、またはPCI DSS 要件 6.1 で定義されたすべての「高リスク」脆弱性が解消されること。
    • 11.2.3.c スキャンが有資格の内部リソースまたは有資格の外部第三者によって行われたこと、該当する場合は、テスターの組織の独立性（ QSA や ASV である必要はない）が存在することを確認する。
  • 11.3 少なくとも以下を含むペネトレーションテスト方法を開発し、実装する。\n• 業界承認のペネトレーションテスト方法（NISTSP800-115 など）に基づいている\n• CDE 境界と重要システム全体を対象とした対応を含める\n• ネットワークの内部と外部からの侵入テスト\n• セグメンテーションと範囲減少制御の有効性テストを含める\n• アプリケーション層のペネトレーションテストは、少なくとも要件 6.5 に記載されている脆弱性を含める必要がある\n• ネットワーク層のペネトレーションテストには、ネットワーク機能とオペレーティングシステムをサポートするコンポーネントを含める必要がある\n• 過去 12 カ月にあった脅威と脆弱性のレビューと考慮を含める\nペネトレーションテスト結果と修正実施結果の保持を指定する\n注： 要件 11.3 へのこの更新は、2015 年 6 月30 日まではベストプラクティスとみなされ、それ以降は要件になる。ペネトレーションテストの PCI DSS v2.0 要件は、v3.0 で更新されるまで順守する必要がある。:
    • 11.3 ペネトレーションテスト方法を調べ、責任者をインタビューすることで、この方法が実装されており少なくとも以下を含むことを確認する。\n• 業界承認のペネトレーションテスト方法に基づいている\n• CDE 境界と重要システム全体を対象とした対応\n• ネットワークの内部と外部からの侵入テスト\n• セグメンテーションと範囲減少制御の有効性テスト\n• アプリケーション層のペネトレーションテストは、少なくとも要件 6.5 に記載されている脆弱性を含める必要がある\n• ネットワーク層のペネトレーションテストには、ネットワーク機能とオペレーティングシステムをサポートするコンポーネントを含める必要がある\n• 過去 12 カ月にあった脅威と脆弱性のレビューと考慮\n• ペネトレーションテスト結果と修正実施結果の保持を指定する
  • 11.3.1 外部のペネトレーションテストを少なくとも年に一度および大幅なインフラストラクチャまたはアプリケーションのアップグレードや変更（オペレーティングシステムのアップグレード、環境へのサブネットワークの追加、環境への Web サーバの追加など）後に実行する。:
    • 11.3.1.a 最新の外部ペネトレーションテストの対象範囲と結果を調べて、ペネトレーションテストが以下を満たしていることを確認する。\n• 定義された方法に従っている\n• 少なくとも年に一度実施する\n• 環境に対して重大な変更が行われた後実施する
    • 11.3.1.b テストが認定された内部リソースまたは認定された外部の第三者によって実行されたこと、および該当する場合はテスターが組織的に独立した立場であること（QSA または ASV である必要はない）を確認する。
  • 11.3.2 内部ペネトレーションテストを少なくとも年に一度および大幅なインフラストラクチャまたはアプリケーションのアップグレードや変更（オペレーティングシステムのアップグレード、環境へのサブネットワークの追加、環境への Web サーバの追加など）後に実行する。:
    • 11.3.2.a 最新の内部ペネトレーションテストの結果を調べて、ペネトレーションテストが少なくとも年に一度および環境への大幅な変更後に実行されていることを確認する。\n• 定義された方法に従っている\n• 少なくとも年に一度実施する\n• 環境に対して重大な変更が行われた後に実施する
    • 11.3.2.b テストが認定された内部リソースまたは認定された外部の第三者によって実行されたこと、および該当する場合はテスターが組織的に独立した立場であること（QSA または ASV である必要はない）を確認する。
  • 11.3.3 ペネトレーションテストで検出された悪用可能な脆弱性が修正され、テストが繰り返されて修正が確認される。:
    • 11.3.3 ペネトレーションテスト結果を調べて、既知の悪用可能な脆弱性が修正され、テストが繰り返されて脆弱性が修正されたことを確認する。
  • 11.3.4 セグメンテーションを用いて CDE を他のネットワークから分離した場合、少なくとも年に一度とセグメンテーションの制御/方法が変更された後にペネトレーションテストを行って、セグメンテーション方法が運用可能で効果的であり、適用範囲内のシステムから適用範囲外のシステムをすべて分離することを確認する:
    • 11.3.4.a セグメンテーション制御を調べ、ペネトレーションテスト方法をレビューして、ペネトレーションテスト手順ですべてのセグメンテーション方法をテストし、ペネトレーションテストを行って、セグメンテーション方法が運用可能で効果的であり、適用範囲内のシステムから適用範囲外のシステムをすべて分離することを確認する。
    • 11.3.4.b 最新のペネトレーションテストからの結果を調べて、セグメンテーション制御を確認するペネトレーションテストが以下を満たしていることを確認する。\n• 少なくとも年 1 回およびセグメンテーション制御/方法に何らかの変更を加えた後に実施される\n• 使用されているすべてのセグメンテーション制御/方法を対象とする\n• セグメンテーション方法が運用可能で効果的であり、対象範囲内システムから対象範囲外システムを分離する
  • 11.4侵入検知システムや侵入防止手法を使用して、ネットワークへの侵入を検知および/または防止する。カード会員データ環境との境界およびカード会員データ環境内の重要なポイントを通過するすべてのトラフィックを監視し、侵害の疑いがある場合は担当者に警告する。\nすべての侵入検知および防止エンジン、ベースライン、シグネチャを最新状態に保つ。:
    • 11.4.a システム構成とネットワーク図を調べて、（侵入検知システムや侵入防止などの）手法が使用されていて、すべてのトラフィックが監視されていることを確認する。\n• カード会員データ環境の境界で\n• カード会員データ環境内の重要なポイントで
    • 11.4.b システム構成を調べ、責任者をインタビューすることで、侵入検知や侵入防止が侵害の疑いを担当者に警告することを確認する。
    • 11.4.c 侵入検知や侵入防止手法の構成とベンダ文書を調べて、侵入検知や侵入防止手法デバイスが最適な保護を実現するためのベンダの指示に従って構成、保守、更新されていることを確認する。
  • 11.5 変更検出メカニズム（ファイル整合性監視ツールなど）を導入して重要なシステムファイル、構成ファイル、またはコンテンツファイルの不正な変更を担当者に警告し、重要なファイルの比較を少なくとも週に一度実行するようにソフトウェアを構成する。\n注：変更検出目的で、重要なファイルとは通常、定期的に変更されないが、その変更がシステムの侵害や侵害のリスクを示す可能性があるファイルを示す。ファイル整合性監視製品などの変更検出メカニズムでは通常、関連オペレーティングシステム用の重要なファイルがあらかじめ構成されている。カスタムアプリケーション用のファイルなど、その他の重要なファイルは、事業体（つまり、加盟店またはサービスプロバイダ）による評価および定義が必要である。:
    • 11.5.a システム設定と監視されたファイルを観察し、監視活動の結果をレビューすることで、カード会員データ環境で、変更検出メカニズムが使用されていることを確認する。\n監視する必要があるファイルの例:\n・ システム実行可能ファイル\n・ アプリケーション実行可能ファイル\n・ 構成およびパラメータファイル\n・ 集中的に保存されている、履歴またはアーカイブされた、ログおよび監査ファイル\n・ 事業体が指定した追加の重要ファイル（リスク評価その他の方法で）
    • 11.5.b 重要なファイルの不正な変更を担当者に警告し、重要なファイルの比較を少なくとも週に 1 回実行するようにメカニズムが構成されていることを確認する。
  • 11.5.1 変更検出ソリューションによって生成された警告に対応するプロセスを実装する。:
    • 11.5.1 担当者をインタビューすることで、すべての警告が調査され解決されたことを確認する。
  • 11.6 セキュリティ監視とテストに関するセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。:
    • 11.6 文書を調べ、担当者をインタビューすることで、セキュリティ監視とテストに関するセキュリティポリシーと操作手順が以下の要件を満たしていることを確認する。\n• 文書化されている\n• 使用されている\n• 影響を受ける関係者全員に知られている
• 要件12：従業員および派遣社員向けの情報セキュリティポリシーを整備する:
  • 12.1 セキュリティポリシーを確立、公開、維持、普及させる:
    • 12.1 情報セキュリティポリシーを調べて、ポリシーが公開され、すべての関係者（ベンダ、ビジネスパートナーを含む）に普及されていることを確認する。
  • 12.1.1 少なくとも年に一度レビューし、環境が変更された場合にポリシーを更新する。:
    • 12.1.1 情報セキュリティポリシーを少なくとも年に一度レビューし、ビジネス目標またはリスク環境への変更を反映するため、必要に応じて更新されていることを確認する。
  • 12.2 以下のリスク評価プロセスを実装する。\n• 少なくとも年に一度と環境に大きな変更があった場合（買収、合併、移転など）に実施される\n• 重要なアセット、脅威、脆弱性を識別する\n• 正式なリスク評価に至る\n（リスク評価方法の例としては、OCTAVE、ISO 27005、および NIST SP800-30 が挙げられますが、これらに限定されません。）:
    • 12.2.a 正式なリスク評価で、脅威、脆弱性、結果を識別する、年に一度のリスク評価プロセスが文書化されていることを確認する。
    • 12.2.b リスク評価文書をレビューし、リスク評価プロセスが少なくとも年に一度と大きな変更があった場合に実施されていることを確認する。
  • 12.3 重要なテクノロジに関する使用ポリシーを作成して、これらのテクノロジの適切な使用を定義する\n注： 重要なテクノロジの例には、リモートアクセスおよびワイヤレステクノロジ、ノートパソコン、タブレット、リムーバブル電子メディア、電子メールの使用、インターネットの使用がありますが、これらに限定されません\nこれらの使用ポリシーで以下を要求することを確認する。
    • 12.3 重要なテクノロジに関する使用ポリシーを調べ、責任者をインタビューすることで、ポリシーが実装・順守されていることを確認する。
  • 12.3.1 権限を持つ関係者による明示的な承認:
    • 12.3.1 使用ポリシーが、テクノロジを使用するために、許可された当事者からの明示的な承認を要求していることを確認する。
  • 12.3.2 テクノロジの使用に対する認証:
    • 12.3.2 使用ポリシーが、すべてのテクノロジの使用に、ユーザ ID とパスワードまたはその他の認証項目（トークンなど）による認証を要求するプロセスを含んでいることを確認する。
  • 12.3.3 このようなすべてのデバイスおよびアクセスできる担当者のリスト:
    • 12.3.3 使用ポリシーが、すべてのデバイスおよびデバイスの使用を許可された担当者のリストを定義していることを確認する。
  • 12.3.4 デバイスの所有者、連絡先情報、目的を正確にその場で識別できる方法（ラベル付け、コーディング、デバイスのインベントリ）:
    • 12.3.4 使用ポリシーがデバイスの所有者、連絡先情報、目的を正確にその場で識別できる方法（ラベル付け、コーディング、デバイスのインベントリ）を定義することを確認する。
  • 12.3.5 テクノロジの許容される利用法:
    • 12.3.5 使用ポリシーが、テクノロジの許容される利用法を定義していることを確認する。
  • 12.3.6 テクノロジの許容されるネットワーク上の場所:
    • 12.3.6 使用ポリシーが、テクノロジの許容されるネットワーク上の場所を定義していることを確認する。
  • 12.3.7 会社が承認した製品のリスト:
    • 12.3.7 使用ポリシーが、会社が承認した製品のリストを含むことを確認する。
  • 12.3.8 非アクティブ状態が特定の期間続いた後のリモートアクセステクノロジのセッションの自動切断:
    • 12.3.8.a 使用ポリシーが、非アクティブ状態が一定期間続いた後のリモートアクセステクノロジのセッションの自動切断を要求していることを確認する。
    • 12.3.8.b リモートアクセステクノロジの構成を調べて、非アクティブ状態が一定期間続いた後にリモートアクセステクノロジのセッションが自動切断されることを確認する。
  • 12.3.9 ベンダおよびビジネスパートナーには必要とする場合にのみリモートアクセステクノロジをアクティブ化し、使用後直ちに非アクティブ化する:
    • 12.3.9 使用ポリシーで、ベンダやビジネスパートナーが必要とする場合にのみリモートアクセステクノロジをアクティブ化し、使用後直ちに非アクティブ化することが要求されていることを確認する。
  • 12.3.10 リモートアクセステクノロジ経由でカード会員データにアクセスする担当者については、定義されたビジネスニーズのために明示的に承認されていない限り、ローカルハードドライブおよびリムーバブル電子メディアへのカード会員データのコピー、移動、保存を禁止する。　承認されたビジネスニーズがある場合、使用ポリシーはデータが適用される PCI DSS 要件すべてに従って保護されることを要求する必要がある。:
    • 12.3.10.a 使用ポリシーで、リモートアクセステクノロジを介してカード会員データにアクセスする場合、このようなデータをローカルハードドライブやリムーバブル電子媒体にコピー、移動、保存することは禁止されていることを確認する。
    • 12.3.10.b 適切な承認を持つ担当者について、使用ポリシーが PCI DSS 要件に従って、カード会員データの保護を要求していることを確認する。
  • 12.4 セキュリティポリシーと手順が、すべての担当者に関する情報セキュリティ責任を明確に定義していることを確認する。:
    • 12.4.a すべての担当者について、情報セキュリティを明確に定義する情報セキュリティポリシーを確認する。
    • 12.4.b 責任者のサンプルをインタビューして、セキュリティポリシーを理解していることを確認する。
  • 12.5 個人またはチームに以下の情報セキュリティ管理責任を割り当てる。:
    • 12.5 情報セキュリティポリシーと手順を調べ、以下を確認する。\n• 情報セキュリティが最高セキュリティ責任者またはマネージメントのその他のセキュリティに詳しいメンバーに正式に割り当てられている。\n• 以下の情報セキュリティ責任が明確かつ正式に割り当てられている：
  • 12.5.1 セキュリティポリシーおよび手続きを確立、文書化、配布する。:
    • 12.5.1 セキュリティポリシーと手順を確立、文書化、および配布する責任が、正式に割り当てられていることを確認する。
  • 12.5.2 セキュリティの警告や情報を監視および分析し、適切な担当者に配布する。:
    • 12.5.2 セキュリティの警告を監視および分析し、情報を適切な情報セキュリティおよび部署管理担当者に配布する責任が、正式に割り当てられていることを確認する。
  • 12.5.3 セキュリティインシデントの対応およびエスカレーション手順を確立、文書化、配布し、すべての状況にタイムリーかつ効率的に対処することを確認する。:
    • 12.5.3 セキュリティインシデントの対応およびエスカレーション手順を確立、文書化、および配布する責任が、正式に割り当てられていることを確認する。
  • 12.5.4 追加、削除、変更を含め、ユーザアカウントを管理する:
    • 12.5.4 ユーザアカウントの管理（追加、削除、変更）の責任と認証管理の責任が正式に割り当てられていることを確認する。
  • 12.5.5 すべてのデータへのアクセスを監視および管理する。:
    • 12.5.5 すべてのデータへのアクセスを監視および管理する責任が正式に割り当てられていることを確認する。
  • 12.6 カード会員データセキュリティの重要性を全担当者が認識できるように正式なセキュリティ意識向上プログラムを実装する:
    • 12.6.a 正式なセキュリティ意識向上プログラムを調べて、このプログラムがカード会員データセキュリティの重要性を全担当者に認識させることができることを確認する。
    • 12.6.b セキュリティ意識向上プログラム手順と文書を調べて、以下を実施する。
  • 12.6.1 担当者の教育を採用時および少なくとも年に一度行う。\n注： 方法は、担当者の役割とカード会員データへのアクセスレベルに応じて異なる。:
    • 12.6.1.a セキュリティ意識向上プログラムが、担当者の意識向上と教育を図るため、複数の方法（たとえば、ポスター、手紙、メモ、Webベースのトレーニング、会議、プロモーションなど）で提供されていることを確認する。
    • 12.6.1.b 担当者が、採用時および少なくとも年に一度、セキュリティ意識向上トレーニングに参加していることを確認する。
    • 12.6.1.c 担当者のサンプルをインタビューすることで、意識向上トレーニングを完了しており、カード会員データセキュリティの重要さを認識していることを確認する。
  • 12.6.2 担当者は、少なくとも年に一度セキュリティポリシーおよび手順を読み、理解したことを認める必要がある。:
    • 12.6.2 担当者が、少なくとも年に一度セキュリティポリシーおよび手順を読み、理解したことを書面または電子的に認める必要があることを、セキュリティ意識向上プログラムが要求していることを確認する。
  • 12.7 雇用する前に、可能性のある担当者を選別して、内部ソースからの攻撃リスクを最小限に抑える。（バックグラウンドチェックの例には、職歴、犯罪歴、信用履歴、経歴照会がある。）\n注： このような可能性のある担当者を、トランザクションの実施で一度に 1 つのカード番号にしかアクセスできないようなレジ係など、特定の役職に採用する場合は、この要件は推奨のみです。:
    • 12.7 人事部門の管理者に問い合わせて、カード会員データまたはカード会員データ環境にアクセスする可能性のある担当者については、雇用の前にバックグラウンドチェックが（地域法の制約内で）実施されることを確認する。
  • 12.8 カード会員データがサービスプロバイダと共有される場合は、次の項目を含め、サービスプロバイダを管理するポリシーと手順を維持および実装する。:
    • 12.8 ポリシーと手順の観察とレビュー、関連文書のレビューを通して、カード会員データを共有するか、カード会員データのセキュリティに影響を及ぼす可能性のあるサービスプロバイダ（たとえば、バックアップテープ保管施設、Web ホスティング企業やセキュリティサービスプロバイダなどの管理対象サービスプロバイダ、または不正モデリング目的でデータを受信するサービスプロバイダなど）を次のように管理するプロセスが実装されていることを確認する。
  • 12.8.1 サービスプロバイダのリストを維持する。:
    • 12.8.1 サービスプロバイダのリストが維持されていることを確認する。
  • 12.8.2サービスプロバイダは、プロバイダが、顧客に代わって所有、保存、処理、送信するカード会員データのセキュリティについて、または顧客のカード会員データのセキュリティに影響を与える範囲について責任を持つことを認める内容の書面による契約書を維持する。\n注： 同意の正確な言葉づかいは、提供されるサービスの詳細、各事業体に割り当てられる責任など、2 つの事業体間の同意よって異なります。同意の正確な言葉づかいに、この要件で提供されているのと同じものを含める必要はありません。:
    • 12.8.2 書面による契約を調べて、サービスプロバイダが、顧客に代わって所有、保存、処理、送信するカード会員データのセキュリティについて、または顧客のカード会員データのセキュリティに影響を与える範囲について責任を持つことを認める内容の書面による契約書を維持していることを確認する。
  • 12.8.3 契約前の適切なデューディリジェンスを含め、サービスプロバイダとの契約に関するプロセスが確立されている。:
    • 12.8.3 サービスプロバイダとの契約前の適切なデューディリジェンスを含め、ポリシーと手順が文書化されて、実施されていることを確認する。
  • 12.8.4 少なくとも年に一度、サービスプロバイダのPCI DSS準拠ステータスを監視するプログラムを維持する。:
    • 12.8.4 事業体が、少なくとも年に一度そのサービスプロバイダのPCI DSS準拠ステータスを監視するためのプログラムを維持していることを確認する。
  • 12.8.5 各サービスプロバイダに対し、どのPCI DSS 要件がサービスプロバイダによって管理され、どの PCI DSS が事業体によって管理されるかについての情報を維持する。:
    • 12.8.5 各サービスプロバイダに対し、どの PCI DSS 要件がサービスプロバイダによって管理され、どの PCI DSS が事業体によって管理されるかについての情報を事業体が維持していることを確認する。
  • 12.9 サービスプロバイダ用の追加要件:顧客に代わって所有、保存、処理、送信するカード会員データのセキュリティについて、または顧客のカード会員データのセキュリティに影響を与える範囲について責任を持つことを認める内容の書面による契約書を維持する。\n注： この要件は、2015 年 6 月 30 日まではベストプラクティスとみなされ、それ以降は要件になる。\n注： 同意の正確な言葉づかいは、提供されるサービスの詳細、各事業体に割り当てられる責任など、2 つの事業体間の同意よって異なります。同意の正確な言葉づかいに、この要件で提供されているのと同じものを含める必要はありません。:
    • 12.9.1 サービスプロバイダのポリシーと手順をレビューし、書面による契約のテンプレートを読んで、サービスプロバイダが、顧客のカード会員データや機密の認証データを取り扱う、アクセスする、または他の方法で保存、処理、送信するか、顧客のカード会員データ環境を顧客に委託されて管理するという業務範囲において該当するすべての PCI DSS 要件を順守するという同意を書面にて顧客に提示したことを確認する。
  • 12.10 インシデント対応計画を実施する。システム違反に直ちに対応できるよう準備する。:
    • 12.10 インシデント対応計画と関連手順を調べて、事業体がシステム違反に対して以下を実施することで即時対応する用意があることを確認する。
  • 12.10.1 システム違反が発生した場合に実施されるインシデント対応計画を作成する。計画では、最低限、以下に対応する。\n・ペイメントブランドへの通知を最低限含む、侵害が発生した場合の役割、責任、および伝達と連絡に関する戦略\n・具体的なインシデント対応手順\n・ビジネスの復旧および継続手順\n・データバックアッププロセス\n・侵害の報告に関する法的要件の分析\n・すべての重要なシステムコンポーネントを対象とした対応\n・ペイメントブランドによるインシデント対応手順の参照または包含:
    • 12.10.1.a インシデント対応計画に以下が含まれていることを確認する。\n・ペイメントブランドへの通知を最低限含む、侵害が発生した場合の役割、責任、および伝達に関する戦略\n・具体的なインシデント対応手順\n・ビジネスの復旧および継続手順\n・データバックアッププロセス\n・侵害の報告に関する法的要件の分析（データベースにカリフォルニア在住者が含まれている企業に対し、実際の侵害または侵害の可能性が発生した場合に、影響を受ける消費者への通知を要求するCalifornia Bill 1386 など）\n・すべての重要なシステムコンポーネントを対象とした対応\n・ペイメントブランドによるインシデント対応手順の参照または包含
    • 12.10.1.b 担当者をインタビューし、以前に報告されたインシデントや警告をレビューして、文書化されたインシデントレスポンス計画と手順に従っていることを確認する。
  • 12.10.2 少なくとも年に一度、計画をテストする。:
    • 12.10.2 少なくとも年に一度、計画がテストされていることを確認する。
  • 12.10.3 警告に 24 時間 365 日体制で対応できる担当者を指定する。:
    • 12.10.3 ポリシーの観察とレビュー、および責任者のインタビューを通じて、承認されていない活動、承認されていないワイヤレスアクセスポイントの検出、重要な IDS 警告、重要なシステムまたはコンテンツファイルの承認されていない変更の痕跡がないかどうかを調査するために、インシデント対応および監視が 24 時間体制で行われていることを確認する。
  • 12.10.4 セキュリティ違反への対応を担当するスタッフに適切なトレーニングを提供する。:
    • 12.10.4 ポリシーの観察とレビュー、および責任者のインタビューを通じて、セキュリティ違反への対応に責任を持つスタッフが定期的にトレーニングされていることを確認する。
  • 12.10.5 侵入検知、侵入防止、ファイアウォール、ファイル整合性監視システムを含むがこれらに限定されない、セキュリティ監視システムからの警告を含める。:
    • 12.10.5 ポリシーの観察とレビューを通じて、承認されていない無線アクセスポイントの検出を含め、セキュリティ監視システムからの警告の監視および対応がインシデント対応計画に含まれていることを確認する。
  • 12.10.6 得られた教訓を踏まえてインシデント対応計画を変更および改善し、業界の発展を組み込むプロセスを作成する。:
    • 12.10.6 ポリシーの観察とレビュー、および責任者のインタビューを通じて、得られた教訓を踏まえてインシデント対応計画を変更および改善し、業界の発展を組み込むプロセスがあることを確認する。