Payment Card Industry Data Security Standard v4.0を勉強し、要点をメモ書きする。

https://www.pcisecuritystandards.org/document_library/

主要なPCI DSS要件

分類 要件
安全なNWとシステムの構築と維持 1.NWのセキュリティコントロールを導入、維持
2.すべてのシステムコンポーネントに安全な設定を適用
アカウントデータの保護 3.保存されたアカウントデータを保護
4.オープンな公共NWでカード会員データを伝送する場合、 強力な暗号化技術でカード会員データを保護
脆弱性管理プログラムの維持 5.すべてのシステムとNWを悪意のあるSWから保護
6.安全性の高いシステムおよびSWを開発、保守
強力なアクセス制御手法の導入 7.システムコンポーネントおよびカード会員データへのアクセスを、 業務上必要な適用範囲に制限
8.ユーザを識別し、システムコンポーネントへのアクセスを認証
9.カード会員データへの物理的なアクセスを制限
NWの定期的な監視およびテスト 10.システムコンポーネントおよびカード会員データへのすべてのアクセスを記録し、監視
11.システムおよびNWのセキュリティを定期的にテスト
事業体のポリシーとプログラムにより、情報セキを維持

PCI DSS適用情報

カード会員データ(CHD)、機密認証データ(SAD)を保存、処理、または伝送するすべての事業体と、カード会員データ環境(CDE)のセキュリティに影響を与える可能性のあるすべての事業体を対象とする。

  • アカウントデータ
    • カード会員データ
      • プライマリアカウント番号(PAN)
      • カード会員名
      • 有効期限
      • サービスコード
    • 機密認証データ
      • フルトラックデータ(磁気ストライプデータまたはチップ上の 同等のデータ)
      • カード検証コード（セキュリティコード）
      • PIN/PIN ブロック

PCI DSS要件の適用範囲

  • 適用範囲内システム file
  • 対象外システム 　　file

  • 年次 PCI DSS 適用範囲の確認 事業体は、PCI DSS 適用範囲を決定するための文書を保持することが期待され、検証される。

  • セグメンとPCI DSS適用範囲 適用範囲のシステムと、セグメント（隔離）されていることの有効性が検証できれば、対象外にできる。セグメントされていない or 有効性が検証できなければ、環境全体が適用対象になる。

  • 暗号化されたCHDとPCI DSS適用範囲
    • CHDの暗号化/復号化の実行システム、鍵管理機能の実行システム
    • 暗号化/復号化と鍵管理プロセルから分離されていない暗号化CHD
    • 暗号化CHDで、復号鍵と同じシステム/メディアにあるもの、同じ環境にあるもの、復号鍵へアクセスできるもの。
  • 暗号化されたCHDとTPSPのPCI DSS適用範囲
    TPSP：サードパーティサービスプロバイダ
    • 他の事業体によって暗号化データのみを受信、保存し、データを復号化する能力を持たない場合、TPSP は、一定の条件を満たせば、暗号化データを適用範囲外とみなすことが可能。
    • 顧客（事業体）は下記TPSPのPCI DSS準拠状況を管理/監督する必要あり
      • CDEにアクセスできるTPSP
      • 適用範囲内システムを管理するTPSP
      • CDEのセキュリティに影響を与えるTPSP

PCI DSS v4.0の実施タイムライン

file

用語の略称

略した書き方 意味
CHD カード会員データ
CDE ード会員データ環境
NSC ネットワークセキュリティコントトール
セキポリ セキュリティポリシー
シスコン システムコンポーネント
デフアカ デフォルトアカウント
デフパス デフォルトパスワード
セキレベ セキュリティレベル
PAN プライマリアカウント番号
SAD 機密認証データ
BIN Bank Identification Number
カード番号の先頭6桁
HSM ハードウェア・セキュリティ・モジュール
ベスプラ ベストプラクティス
セキプロ セキュリティプロトコル
シスアカ システムアカウント
ACS アクセスコントロールシステム
PCFF ペイメントカードフォームファクタ
PCD ペイメントカードデータ
SCS セキュリティ制御システム
WFAP ワイヤレスアクセスポイント
セグメン セグメンテーション
情セキ 情報セキュリティ
カスアプ カスタマイズアプローチ
テク テクノロジ
コンプラ コンプライアンス
セキイン セキュリティインシデント

PCI DSS の詳細な要件

安全なネットワークとシステムの構築と維持

要件 1:ネットワークセキュリティコントロール（NSC）の導入と維持

信頼できないNWの一般例

  • インターネット
  • 企業間通信チャネルなどの専用接続
  • 無線NW
  • キャリアNW
  • 3rd Partyネットワーク
  • その他企業の管理能力の及ばないソース

要件１概要

1.1 NSCを導入・維持するためのプロセスや仕組みが定義/理解されている

  • 1.1.1 要件1のセキポリが文書化/最新化/利用され/周知される
  • 1.1.2 役割と責任が文書化

1.2 NSCが設定/維持されている

  • 1.2.1 NSCルールセットの構成基準が定義/実装/維持されている
  • 1.2.2 NW接続とNSCの構成変更は、変更管理プロセスに従って承認/管理する
  • 1.2.3 CDEと他のNW間の全接続の正確なNW図が維持されている
  • 1.2.4 システムとNW上の全アカウントデータのデータフロー図が整備/更新されている
  • 1.2.5 許可された全サービス/プロトコル/ポートが特定/承認/必要性が定義されている
  • 1.2.6 使用中で非安全なサービス/プロトコル/ポートで、リスク軽減のセキュリティ機能が定義/実装されている
  • 1.2.7 NSCの設定を最低でも6ヶ月に1回は見直し/適切で機能するのを確認
  • 1.2.8 NSC構成ファイルが不正アクセスから保護され、動的なNW構成と整合性保持

1.3 CHDへのNWアクセスおよびCDEからのNWアクセスが制限されている

  • 1.3.1 CDEへのアクセスは必要なモノのみ、それ以外は明確に拒否される
  • 1.3.2 CDEからのアクセスは必要なモノのみに、それ以外は明確に拒否される
  • 1.3.3 NSCは無線LANがCDEであるか関係なく、全無線NWからCDEへのアクセスはデフォルトで拒否、許可された無線アクセスのみ許可

1.4 信頼できるNWと信頼できないNW間のNW接続が制御されている

  • 1.4.1 NSCを信頼できるNWと信頼できないNWの間で実装
  • 1.4.2 信頼できないNWから信頼できるNWへの着信トラフィックは以下に制限される
    1. 一般公開されたサービス/プロトコル/ポートを提供許可されるシステム
    2. 信頼できるNWによって開始される通信に対するステートフル応答
    3. その他はすべて拒否
  • 1.4.3 偽造送信元IPから信頼NWへ侵入検知＆ブロックするためのスプーフィング対策を実施
  • 1.4.4 信頼できないNWからCHEへ直接アクセスできないようにする
  • 1.4.5 内部IPやルーティング情報は許可された関係者のみ開示限定

1.5 信頼できないNWとCDEの両方に接続できるシステムによるCDEへのリスクが軽減されている

  • 1.5.1 信頼できないNWとCDEの両方に接続できるシステムに対し、特定の構成設定を定義、アクティブにセキュリティを実行、文書化されたセキュリティ管理の変更が適宜に承認される

要件 2: すべてのシスコンにセキュアな設定を適用する

2.1 すべてのシスコンにセキュアな設定を適用するためのプロセスと仕組みが定義/理解されている

  • 2.1.1 要件2のセキポリが文書化/最新化/利用され/周知される
  • 2.1.2 要件2活動の役割と責任が文書化/割当/理解される

2.2 システムの構成要素が安全に設定/管理される

  • 2.2.1 構成基準は以下のように開発/実施/維持する
    1. 全シスコンをカバー
    2. 全既知脆弱性に対処
    3. 業界認知の堅牢化標準とベンダー堅牢化推奨と整合
    4. 新脆弱性問題が特定された際に更新
    5. シスコンが本番接続前or直後に構成され、適切を確認後に適用される
  • 2.2.2 ベンダーのデフアカを使う場合はデフパスは要件8.3.6で変更、使わない場合は削除or無効化
  • 2.2.3 異なるセキレベがある主機能は、1つのシスコンに1主機能/同じシスコンにセキレベの異なる主機能を分離/最もセキレベの高い機能の要求に合わせる
  • 2.2.4 必要なサービス/プロトコル/デーモン/機能のみ有効化、不要なのを全削除/無効化
  • 2.2.5 安全でないサービス/プロトコル/デーモンがある場合、正当性を文書化、リスク軽減のセキュリティ機能が文書化/実装される
  • 2.2.6 システムのセキュリティパラメータの誤使用の防止を設定される
  • 2.2.7 コンソール以外の全管理者アクセスは強力な暗号で暗号化

2.3 無線環境が安全に設定/管理される

  • 2.3.1 CDEに接続/データ送信の無線環境は、すべての無線ベンダーのデフォルトを変更する
    1. ワイヤレス暗号化キー
    2. PW or ワイヤレスアクセスポイント
    3. SNMPのデフォルト etc.
  • 2.3.2 CDEに接続/データ送信の無線環境で、無線暗号鍵を以下の都度に変更
    1. 鍵を知る担当者がその役割を離れた都度
    2. 鍵の漏洩が疑われる or 判明した都度

アカウントデータの保護

要件 3: 保存されたアカウントデータの保護

アカウントデータが非永続的メモリ(RAM、揮発性メモリなど)に存在する場合、アカウントデータの暗号化は必要ない データは、業務の目的が完了した時点で、揮発性メモリから削除される必要がある

3.1 保存されているアカウントデータを保護するためのプロセスとメカニズムが定義/理解される

  • 3.1.1 要件3のセキポリが文書化/最新化/利用され/周知される
  • 3.1.2 要件3活動の役割と責任が文書化/割当/理解される

3.2 アカウントデータの保存を最小限にとどめる

  • 3.2.1 データの保持は、保持/廃棄ポリシー、手順/プロセスを実施し、最小限に留める
    1. 保存場所も含む
    2. オーソリ完了までに保存される全SDAを対象
    3. データの保存量/保存機関を、法律/規制/事業要件に必要なモノに限定。
    4. 保有期間を定義、文書化された理由/保存要件
    5. 不要になったデータを完全削除/復元不可能にする
    6. 保存期間超過の保存データが完全削除/復元不可能にされることを最低3ヶ月に一度に検証

3.3 SADは、オーソリ後に保存されない

  • 3.3.1 SADは暗号化されてもオーソリ後は保持されない。受信した全SADはオーソリ完了時点で復元不可能にする
    • 3.3.1.1 オーソリの完了時に、トラックの全内容が保持されない
    • 3.3.1.2 オーソリ完了時に、カード検証コードを保持しない
    • 3.3.1.3 オーソリの完了時に 、個人識別番号およびPINブロックを保持しない
  • 3.3.2 オーソリが完了前に電子的に保存される SADは、強力な暗号化技術を使用して暗号化される 事業体は、PAN の暗号化に使用するのとは異なる暗号鍵でSADを暗号化することを検討すべき
  • 3.3.3 イシュアおよびイシュイングサービスをサポートしSADを保存する企業に対する追加要件:SADの保存では
    1. 正当なイシュイング業務に必要なモノに限定し安全性を確保
    2. 強力な暗号化技術を使用し暗号化されていること

3.4 PAN 全体の表示へのアクセスと PAN のコピー機能が制限されている

  • 3.4.1 PANは表示時にマスクされ（BINと末尾4桁が最大表示桁数）、業務上の正当な理由がある担当者のみがより多くみることができる
  • 3.4.2 リモートでは技術的なコントロールにより文書化or承認された正当な者以外、PANのコピー/移動を防止する

3.5 PANは、保存場所に関わらず、保護されている

  • 3.5.1 PANを以下いずれの方法で保存されている場所の読み取りを不可能にする
    1. 強力な暗号化技術によるPAN全体の一方向ハッシュ
    2. トランケーション
    3. インデックストークン
    4. 強力な暗号化技術と、関連する鍵管理プロセスおよび手順
    • 3.5.1.1 PAN を読み取り不能にするために使用するハッシュは、PAN全体の鍵付き暗号ハッシュ
    • 3.5.1.2 ディスクレベルまたはパーティションレベルの暗号化を使用して PAN を読み取り不能にする場合、以下のようにのみ実装される
      1. リムーバブル電子メディア上。
      2. リムーバブル電子メディア上に使用する場合、PANも読み取り不能にする
    • 3.5.1.3 PAN を読み取り不能にするために、ディスクレベルまたはパーティションレベルの暗号化を使用する場合、次のように管理する

3.6 保存されているアカウントデータを保護するために使用される暗号化鍵が保護されている

  • 3.6.1 アカウントデータの暗号鍵の保護要件
    1. 暗号化鍵へのアクセスが必要最小限の管理者に制限
    2. 鍵暗号化鍵がすくなくとも保護対象データの暗号化鍵と同じ強度を有する
    3. 鍵暗号化鍵はデータ暗号化鍵とは別に保存。
    4. 鍵の保存場所と形式を最小限に安全に保存
    • 3.6.1.1 SPのみに対する追加要件：暗号化技術を以下を含む文書化/維持される
      1. 暗号化のすべてのアルゴリズム/プロトコルおよび鍵詳細
      2. 本番とテスト環境で同じ暗号化鍵が使用されないようにする
      3. 各鍵の使用方法の説明
    • 3.6.1.2 暗号化・復号に使用する秘密鍵（共通鍵暗号）とプライベート鍵（公開鍵暗号）は、常に次のいずれか（複数可）の形態で保存される
      1. データ暗号化鍵と同等以上の強度を持つ鍵暗号鍵で暗号化され、データ暗号化鍵とは別に保存される
      2. HSMやPTSが承認した加盟店端末などの安 全な暗号化デバイス(SCD)内にあること
      3. 業界で認められた方法に従い、少なくとも2 つのフルレングス（Full Length）の鍵コンポーネントまたは鍵共有として
    • 3.6.1.3 平文の暗号化鍵コンポーネントへのアクセスを必要最小限の管理者に制限

3.7 暗号化鍵のライフサイクルのすべての側面を網羅する鍵管理プロセスおよび手順が定義/実施されている

  • 3.7.1 強力な暗号化鍵の生成を含む、鍵管理ポリシおよび手順が実施される
  • 3.7.2 暗号化鍵の安全な配布を含む、鍵管理ポリシおよび手順が実施されている
  • 3.7.3 暗号化鍵の安全な保管を含む、鍵管理のポリシーと手順が実装されている
  • 3.7.4 鍵管理のポリシーおよび手順が定義され、業界のベスプラに基づき、暗号期間の終わりに達した鍵の変更について実装されている
    1. 使用中の鍵タイプごとに定義された暗号期間
    2. 暗号期間の終了時に鍵変更のプロセス
  • 3.7.5 鍵管理ポリシーおよび手続きは、以下の場合に必要で、鍵の廃止/交換/廃棄を含めて実装される
    1. 鍵が、定義された暗号期間の終わりに達した
    2. 鍵の完全性が弱まった場合（平文の鍵を知る担当者の退社、鍵を知る役割を終えた場合など）
    3. 鍵の漏洩が疑われる/判明された場合
  • 3.7.6 担当者が手動による平文の暗号化鍵の管理操作する場合、鍵管理ポリシおよび手順には、知識分割およびデュアルコントロールを使用して操作管理する
  • 3.7.7 暗号化鍵の不正置換の防止を含む鍵管理ポリシーおよび手順が実施されている
  • 3.7.8 鍵管理のポリシーおよび手順が、暗号化鍵の管理者が鍵の管理者としての責任を理解し受け入れ、(書面または電子的に)正式に承認することを含めて実施されている

要件 4: オープンな公共NWでの送信時に、強力な暗号化技術でCHDを保護する

PAN 送信は、送信前のデータの暗号化、またはデータが送信されるセッションの暗号化、もしくはその両方によって保護することができる データレベルとセッションレベルの両方で強力な暗号化技術を適用することは必須ではないが、推奨される。

4.1 オープンな公共NWを介した伝送中に、強力な暗号化技術でCHDを保護するための プロセスおよびメカニズムが定義/文書化されている

  • 4.1.1 要件4のセキポリが文書化/最新化/利用され/周知される
  • 4.1.2 要件4活動の役割と責任が文書化/割当/理解される

4.2 送信時の PAN は強力な暗号化技術で保護されている

  • 4.2.1 強力な暗号とセキプロを以下のように実装し、オープンな公共NWでの送信時に PAN を保護する
    1. 信頼できる鍵と証明書のみ受け付ける
    2. PANを保護するための証明書は有効で有効期限が切れていたり失効していない
    3. 使用中プロトコルは安全なVerや設定のみサポート、安全でないVer、アルゴ、鍵サイズ、実装へのフォールバックや使用しない
    4. 暗号強度は使用中の暗号化方式に適したもの
    • 4.2.1.1 送信中のPANを保護用の事業体の信頼できる鍵と証明書のインベントリが維持
    • 4.2.1.2 PAN の送信、またはCDEに接続するワイヤレスNWは、認証と送信に強力な暗号を実装するために業界のベスプラを使用
  • 4.2.2 エンドユーザメッセージングテクノロジを介して送信される場合、PAN は常に強力な暗号で保護 → Mail / IM / SMS / Chatなど

脆弱性管理プログラムの維持

要件 5: 悪意のあるSWからすべてのシステムおよびNWを保護する

5.1 全てのシステムおよびNWを悪意のあるSWから保護するためのプロセスおよびメカニズムが定義/理解されている

  • 5.1.1 要件5のセキポリが文書化/最新化/利用され/周知される
  • 5.1.2 要件5活動の役割と責任が文書化/割当/理解される

5.2 悪意のあるSW(マルウェア)が防止または検出/対処

  • 5.2.1 定期的な評価で、マルウェアによるリスクがないと判断されたシスコンを除く、すべてのシスコ にマルウェア対策ソリューションが配備
  • 5.2.2 導入されたマルウェア対策ソリューションは、既知の全種類のマルウェアを検出/削除/ブロッ ク、または封じ込める
  • 5.2.3 マルウェアのリスクがないシスコンは定期的に評価される。文書化されたリスト、進化するマルウェアの脅威特定/評価し、引き続きマルウェア対策を保護必要かしないかを確認
    • 5.2.3.1 マルウェアのリスクがないと特定されたシスコンの定期的な評価の頻度は、事業体のターゲットリスク分析で定義され、要件12.3.1で指定されたすべての要素に従って実行

5.3 マルウェア対策メカニズムおよびプロセスがアクティブであり維持/監視

  • 5.3.1 マルウェア対策ソリューションが自動更新により最新状態を保持
  • 5.3.2 マルウェア対策ソリューションは、定期スキャン/アクティブススキャン実行 or システム/プロセスの継続的な振る舞い分析
    • 5.3.2.1 定期的なスキャンの頻度は、事業体のターゲットリスク分析において定義
  • 5.3.3 リムーバブル電子メディアの場合、マルウェ ア対策のソリューションは、メディア挿入/接続/論理マウントされる際に自動スキャン実行/継続的な振る舞い分析を実行
  • 5.3.4 マルウェア対策ソリューションの設定を調査し、ログが有効化/保持を確認

5.4 フィッシング対策機構は、フィッシング攻撃からユーザを保護

  • 5.4.1 フィッシング攻撃を検知し、担当者保護のプロセスや自動化メカニズムがある

要件 6 : 安全なシステムおよびSWの開発と維持

6.1 安全なシステムおよびSWを開発し、維持するためのプロセス/仕組みが定義/理解

  • 6.1.1 要件6のセキポリが文書化/最新化/利用され/周知される
  • 6.1.2 要件6活動の役割と責任が文書化/割当/理解される

6.2 特注・カスタムSWが安全に開発

  • 6.2.1 特注SWおよびカスタムSWは、安全な開発の業界標準やベスプラに基づき、PCI DSSに準拠、SW開発ライフサイクルの各段階においての問題を考慮
  • 6.2.2 特注SWおよびカスタムSWに従事するSW開発担当者は，少なくとも12カ月に1回，次のような訓練をうける
    1. 自分の職能および開発言語に関連するSWセキュリティ
    2. 安全なSW設計と安全なコーディング技法
    3. セキュリティテストツールを使う場合、SW脆弱性の検出方法
  • 6.2.3 特注SWおよびカスタムSWは、潜在的なコーディングの脆弱性を特定し修正するために、リリースする前に、以下のようにレビュー
    1. コードが安全なコーディング規則で開発される
    2. 既存のSW脆弱性と新しいSW脆弱性の両方を調査
    3. リリース前に適切な修正を実施
    • 6.2.3.1 本番リリース前に、特注SWおよびカスタムSWに対して手動コードレビューを実施する場合、コード変更は
      1. コードレビュー技術やセキュアコーディングの実践に精通した、元のコード作成者以外の個人がやる
      2. リリース前に管理者でレビューし承認
  • 6.2.4 一般的なSW攻撃および関連する脆弱性を防止/軽減するため、技術方法などを定義し、 SW開発担当者が使用
    1. SQL/LDAP/XPath/コマンドなどのインジェクション攻撃
    2. データとその構造に対する攻撃
    3. 暗号の使用に関する攻撃
    4. 高リスクの脆弱性を経由した攻撃

6.3 セキュリティの脆弱性を特定/対処

  • 6.3.1 以下のようにセキュリティ脆弱性を特定/管理
    1. CERTなど業界認知された脆弱性情報源を使用して特定
    2. 脆弱性は業界べスプラと影響を考慮しリスクランクが割り当てられる
    3. リスクランキングでは最低限、高リスクor環境に重要な全脆弱性を特定
    4. 特注SW/カスタムSW、3rd Party SWの脆弱性が対象
  • 6.3.2 特注SWおよびカスタムSW、3rd Party SWのインベントリを維持し、脆弱性/パッチ管理を容易にする
  • 6.3.3 全シスコンは、以下の適用可能なセキュリティパッチ/アップデー トをインストールすることで、既知の脆弱性を保護
    1. 重要or高セキュリティなパッチ/アップデー トがリリース後1カ月以内にインストールされる
    2. その他の適用可能なセキュリティパッチ/アッ プデートが、事業体の定める適切な期間内にインストールされる

6.4 一般公開されているWebアプリは攻撃を保護

  • 手動/自動のアプリ脆弱性セキュリティ評価ツール/手法により、公開用アプリを以下のようにレビュー
  • 最低でも12ヶ月に一度 or 大幅な変更後に実施
  • アプリのセキュリティの専門事業体によるもの
  • 最低でも要件6.3.6のSW攻撃を含む
  • 全脆弱性が要件6.2.1でランク付け
  • 全脆弱性が修正される

  • 修正後アプリを再評価

  • 6.4.2 一般公開されているWebアプリで、ウェブ ベースの攻撃を継続的に検知・防止する自動化された技術的ソリューションを導入し、少なくとも以下の条件を備える
    1. 一般公開Webアプリの前にインストールされ、Webベースの攻撃を検知・防止
    2. アクティブに実行され、最新状態に更新
    3. 監査ログを生成
    4. Webベースの攻撃をブロックか、アラート生成し直ちに調査するように設定
  • 6.4.3 消費者のブラウザに読み込まれ実行される全決済スクリプトは、以下のように管理
    1. 各スクリプトの認可を確認する方法が実装
    2. 各スクリプトの整合性を保証する方法が実装
    3. 全スクリプトのインベントリが各スクリプトが必要な理由の説明文書が維持される

6.5 すべてのシスコンの変更が安全に管理されている。

  • 6.5.1 本番環境における全シスコンの変更管理は手順化されている
    1. 変更理由と説明
    2. セキュリティ上の影響の文章化
    3. 権限者による変更承認
    4. 変更の検証テスト
    5. 変更が本番環境に導入前、要件6.2.4準拠するかのテスト
    6. 切り戻しの手順
  • 6.5.2 大幅変更が完了後、該当する全 PCI DSS 要件が全新規/変更システムとNWに適用されることを確認し、文書更新
  • 6.5.3 プレ本番環境は本番環境から分離され、その分離はアクセス制御によって強制される
  • 6.5.4 本番環境とプレ本番環境の間で役割と機能を分離し、レビュー/承認された変更のみを導入することで説明責任を果たす
  • 6.5.5 実際の PAN はプレ本番環境では使用してはならない。ただし、プレ本番環境がCDE)に含まれ、適用されるすべての PCI DSS 要件に従って保護されている場合はこの限りではない
  • 6.5.6 テストデータ/テストアカウントは、本番稼動前にシスコンから削除される

強固なアクセス制御の実施

要件 7: シスコンおよびCHDへのアクセスを、業務上必要な適用範囲(Need to Know)によって制限する

Need to Know

業務に必要な最小限のデータのみにアクセスできること

最小限の権限

業務を遂行するために必要な最小限の権限のみを提供すること

7.1 業務上知る必要のあるシスコンとCHDへのアクセスを制限するためのプロセスおよびメカニズムが定義/理解

  • 7.1.1 要件7のセキポリが文書化/最新化/利用され/周知される
  • 7.1.2 要件7活動の役割と責任が文書化/割当/理解される

7.2 シスコンやデータへのアクセスが適切に定義/割当

  • 7.2.1 アクセス制御モデルが定義され、以下のようにアクセスを許可
    1. 事業体のビジネスとアクセスの必要性に応じたアクセス
    2. ユーザの職務分離と機能に基づく、シスコンとDBへのアクセス
    3. 職務上必要最小限の権限
  • 7.2.2 特権ユーザを含むユーザには、職務分離と機能、職責に必要最小限の特権が割当
  • 7.2.3 必要な権限は、任命された担当者にて承認
  • 7.2.4 サードパーティ/ベンダのアカウントを含む全アカウント/アクセス権を、以下のようにレビュー
    1. 最低でも半年に一度
    2. ユーザアカウント/アクセス権限が適切
    3. 不適切なアクセスに対処
    4. 管理者はアクセスが適切
  • 7.2.5 すべてのアプリおよびシスアカと関連するアクセス権は、次のように割当/管理
    1. システムorアプリの操作性に必要最小限の権限
    2. アクセスは、必要とするシステム、アプリまたはプロセスに限定
  • 7.2.5.1 アプリおよびシスアカによる全アクセス/アクセス権限を以下のようにレビュー
    1. 定期的に実施
    2. アプリ/システムへのアクセスの実行が適切であり続ける
    3. 不適切なアクセスに対処
    4. 管理責任者はそのアクセスが適切であり続ける
  • 7.2.6 保存されたCHDリポジトリへクエリを行うすべてのユーザアクセスは、以下のよう に制限
    1. アウリ/その他プログラムによる方法で、ユーザの役割と最小特権に基づくアクセスと許可されたアクション
    2. 担当の管理者のみがCHDのリポジトリに直接アクセスし、クエリできる

7.3 シスコンおよびデータへの論理的なアクセスは、アクセス制御システムを介して管理

  • 7.3.1 ユーザの知る必要性に基づいてアクセスを制限し、全シスコンをカバーするアクセス制御システムがある
  • 7.3.2 ACSは、個人/アプリ/システムに割り当てられたアクセス許可を、職種と機能に基づいて強制するように設定
  • 7.3.3 アクセス制御システムはデフォルトで「すべて拒否」に設定

要件 8: ユーザの識別とシスコンへのアクセスの認証

8.1 ユーザを識別し、シスコンへアクセの認証プロセス/メカニズムが定義/理解

  • 8.1.1 要件8のセキポリが文書化/最新化/利用され/周知される
  • 8.1.2 要件8活動の役割と責任が文書化/割当/理解される

8.2 ユーザと管理者の識別/アカウントは、アカウントのライフサイクルを通じて厳密に管理

  • 8.2.1 全ユーザには、シスコン/CHDへのアクセスが許可される前に、一意のIDが割当
  • 8.2.2 グループアカ、共有アカ、汎用アカ/その他の共有された認証情報は、例外的に必要な場合のみ使用し、以下のように管理
    1. 例外的に必要な場合を除き、利用禁止
    2. 例外状況の使用は、必要な時間に制限
    3. 使用正当化のビジネス理由を文書化
    4. 利用は、経営陣により明示的に承認
    5. アクセスへアクセスを許可前に、個々のユーザを身元確認
    6. 実行される全アクションは、個々のユーザに起因するもの
  • 8.2.3 SPのみに対する追加要件:顧客環境へリモートアクセスするSPは、顧客環境ごとに一意の認証要素を使用
  • 8.2.4 ユーザID/認証要素/その他の識別子オブジェクトの追加、削除、変更は、適切に承認され、文書化された承認に定められる権限のみで実施
  • 8.2.5 契約終了したユーザのアクセスは直ちに取り消される
  • 8.2.6 非アクティブなユーザアカウントは、非アクティブ化された日から90日以内に削除/無効化
  • 8.2.7 リモートアクセス、サポート、または保守のために第三者が使用するアカウントは
    1. 必要な時間帯のみ有効、終了後に無効化
    2. 予期せぬ実態が発生しないよう監視
  • 8.2.8 ユーザセッションが15分以上アイドル状態の場合、端末またはセッションを再度アクティブにするために再認証が必要

8.3 利用者/管理者の強力な認証が確立/管理

  • 8.3.1 ユーザと管理者の全アクセスは、以下の認証要素のうち最低でも1つを経由して認証
    1. PWやパスフレーズなどユーザが知る情報
    2. トークン・デバイスやスマーどカードなど、ユーザが保有するもの
    3. バイオメトリクス要素など、ユーザ自身を示すもの
  • 8.3.2 強力な暗号を使用して、全シスコンで送信中/保存中の全認証要素を読み取り不能にする
  • 8.3.3 認証要素を変更する前に、利用者の身元を確認
  • 8.3.4 無効な認証の試行は、以下の方法で制限される
    1. 10回以下の試行回数でユーザIDをロックアウト
    2. ロックアウトの時間は最低30分、または本人確認ができるまで
  • 8.3.5 PW/パスフレーズを認証要素として使用する場合、次のよう にユーザごとに設定/解除
    1. 初回仕様時/リセット時にユニークな値を
    2. 初回使用後直ちに矯正変更
  • 8.3.6 PW/パスフレーズを認証要素として使用する場合、以下の最小レベルの複雑さを満たす
    1. 12文字以上（orシステムが12文字に対応しない場合は、8文字以上）
    2. 数字とアルファベットの両方が含まれる
  • 8.3.7 個人が過去に使用した 4つのPW/パスフレーズのいずれかと同じ新しいPW/パ スフレーズを使用禁止
  • 8.3.8 認証の方針と手順が文書化され、以下を含む全ユーザに伝達
    1. 強力な認証要素の選択に関する指南
    2. ユーザがどのように認証要素を選択すべきかの指南
    3. 以前に使用したPW/パスフレーズを再使用しない指南
    4. PW/パスフレーズが漏洩疑い/判明した場合、それを変更とインシデント報告の方法を指示
  • 8.3.9 PW/パスフレーズが、唯一の認証要素として使う場合、以下のいずれかが行われる
    1. PW/パスフレーズが少なくとも90日に1回変更
    2. アカウントのセキュリティ状態を動的分析し、応じてリソースへのリアルタイムアクセスを自動決定</span>

8.3.10 SPのみに対する追加要件: 顧客ユーザがCHDにアクセスするための唯一の認証要素としてPW/パスフレーズ を使用する場合、以下を含むガイダンスを提供

  • 顧客に対しPW/パスフレーズを定期更新するように指南

  • PW/パスフレーズをいつどのような状況で変更するかを指南

  • 8.3.10.1 SPのみに対する追加要 件:PW/パスフレーズが唯一の認証要素として使う場合、以下のいずれかを行う
    1. PW/パスフレーズを少なくとも90日に1回更新 or
    2. アカウントのセキュリティ状況を動的分析し、応じてリソースへリアルタイムアクセスを自動決定
  • 8.3.11 物理的or論理的セキュリティトークン/スマートカード/証明書などの認証要素を使用する場合
    1. 認証要素はユーザ間共有しない
    2. 意図されたユーザのみがその要素を使用してアクセスできることを保証

8.4 CDEへアクセス保護するためにMFAを実装

  • 8.4.1 管理者アクセスを持つ担当者のCDEへの全ての非コンソールアクセスにMFAを実装 → 1つの要素を2回使用する(例： つの別々のPWの使用)ことは、多要素認証とはみなされない
  • 8.4.2 CDEへの全アクセスにMFAを実装
  • 8.4.3 CDEにアクセス/影響を与える可能性のある、事業体のNW外から発信される全リモートNWアクセスに対して、以下のようにMFAを実施
    1. 全担当者による事業者のNW外からの発信される全リモートアクセス
    2. 3rd Party/ベンダーによる全リモートアクセス

8.5 MFAシステムが悪用されないように構成

  • 8.5.1 MFAシステムは、以下のように実装
    1. MFAシステムはリプレイ攻撃の影響を受けない
    2. MFAシステムは、期間限定し特別に文書化された例外的に管理者による許可がない限り、管理者ユーザ含む全ユーザはバイパスできない
    3. 少なくとも2種類の認証要素使用
    4. アクセスが許可される前に、すべての認証要素が成功することを要求

8.6 アプリ/シスアカの使用/関連する認証要素を厳密に管理

  • 8.6.1 システム/アプリアカウントが対話型ログインに使用できる場合、以下のように管理
    1. 例外が必要な場合を除き、インタラクティブ使用禁止
    2. インタラクティブな使用は、例外状況で制限時間内
    3. インタラクティブな使用の正当化する理由が文書化
    4. インタラクティブな使用は、経営陣が明示的に承認
    5. アクセス許可される前、ユーザ身元確認
    6. 実行された全アクションは個々のユーザに帰属
  • 8.6.2 対話型ログインに使用できるアプリ/シスアカ用のPW/パス フレーズは、コード等にハードコードされていてはならない
  • 8.6.3 アプリケ/シスアカ用のPW/パスフレーズは、次のように保護
    1. PW/パスフレーズは定期更新、侵害疑い/判明された場合に更新
    2. PW/パスフレーズは、事業体がそれの変更頻度に応じて、十分な複雑さで構築

要件 9: CHDへの物理アクセスを制限

9.1 CHDへの物理的なアクセスを制限するためのプロセス/メカニズムが定義/理解

  • 9.1.1 要件9のセキポリが文書化/最新化/利用され/周知される
  • 9.1.2 要件9活動の役割と責任が文書化/割当/理解される

9.2 物理的なアクセス制御により、CHDを含む施設/システムへ入館管理

  • 9.2.1 CDE内のシステムへの物理的アクセスを制限するための適切な施設入館管理
    • 9.2.1.1 CDE内の機密エリアへの個々の物理的アクセスは、ビデオカメラ/物理的アクセス制御機構で監視
      1. CDE内の機密エリアへの/からの出入口は監視
      2. 監視装置/機構は、改ざん/無効化されないように保護
      3. 収集されたデータは、レビュー/他のエントリと関連付けられる
      4. 収集されたデータは、法律の制約がない限り、少なくとも3カ月間保管
  • 9.2.2 施設内の誰でもアクセス可能なNWジャックの使用を制限するための物理的/論理的な管理を実施
  • 9.2.3 施設内の無線AP、Gateway、NW/通信HW、通信回線への物理的なアクセスを制限
  • 9.2.4 機密エリアにあるコンソールへのアクセスは、使用されていないときはロックにより制限

9.3 担当者/訪問者の物理的なアクセスは許可/管理

  • 9.3.1 CDEへの担当者の物理的アクセスを許可/管理するために、以下の手順を実施
    1. 担当者の識別
    2. 個人の物理アクセス要件の変更を管理
    3. 担当者のIDの失効/終了
    4. 識別プロセス/システムへのアクセスを許可された担当者に限定
  • 9.3.2 CDEへの訪問者のアクセスを承認し管理するための手順実施
    1. 訪問者は、入館前に承認される
    2. 訪問者は、常に付き添われている
    3. 訪問者は、明確に識別され、有効期限付きバッジその他のIDが渡される
    4. 訪問者のバッジ/その他識別情報は、訪問者と職員とを目に見える形で区別
  • 9.3.3 訪問者バッジ/身分証明書は、訪問者が施設を出る前/有効期限が切れた時点で引き渡し/無効化される
  • 9.3.4 訪問者記録は、施設内/機密エリア内での訪問者のアクティビティに関する物理的な記録を維持するために使用される。
    1. 訪問者の名前と代表する組織
    2. 訪問日時。物理的なアクセスを許可した担当者の名前
    3. 法律で制限されていない限り、少なくとも3カ月間ログ保持

9.4 CHDを含むメディアを安全に保管/アクセス/配布/破棄

  • 9.4.1 CHDのあるすべてのメディアは、物理的に安全である
    • 9.4.1.1 CHDを含むOnlineメディアのBackupは、安全な場所に保管
    • 9.4.1.2 CHDを含むOnlineメディアのBackup場所のセキュリティは、少なくとも12カ月に1回見直される。
  • 9.4.2 CHDを含むすべてのメディアは、データの機密性に応じて分類。
  • 9.4.3 施設外に送付されるCHDを含むメディアは、以下のように保護
    1. 施設外に送られたメディアは記録される。
    2. メディアは、安全な宅配便または正確に追跡できる配送方法で送付される
    3. オフサイトの追跡ログには、メディアの場所に関する詳細が含まれる
  • 9.4.4 管理者は、施設外に移動されるCHDが含まれるすべてのメディアを承認する（メディアが個人に配布される場合を含む）。
  • 9.4.5 CHDのあるすべての電子メディアのインベントリログが維持されている。
    • 9.4.5.1 CHDのある電子メディアのインベントリは、少なくとも12カ月に1回実施。
  • 9.4.6 カード会員情報を含むハードコピー資料は、業務/法律上の理由で不要になった場合、下記で破棄される。
    1. 資料は、CHDを再構築できないように、クロスカットでシュレッダー/焼却/パルプ化
    2. 資料は、破壊される前に安全な保管容器に保管される
  • 9.4.7 CHDの入った電子メディアは、業務/法律上の理由で不要になった場合、下記で破棄される。
    1. 電子媒体を破棄する
    2. CHDが復元不可能になり、再構築できなくなる

9.5 POI端末が改ざん/不正な置き換えから保護される。

  • 9.5.1 PCFFとの直接的な物理的相互作用によってPCDを取得するPOI端末は、以下を含め、改ざん/不正な置換から保護。
    1. POI端末のリストを維持
    2. POI端末を定期的に検査し、改ざん/不正置換がないか調べる
    3. 不審な行動に注意し、装置の改ざんや不正な代用品を報告するよう担当者を教育 　注意）スキミング防止
    • 9.5.1.2 POI端末の表面は定期的に検査され、改ざんや不正置換を検出。
    • 9.5.1.2.1 POI端末の定期検査の頻度/検査の種類は、要件12.3.1に規定する全要素に従って実施、事業体の目標リスク分析において定義される。
  • 9.5.1.3 POI環境の担当者に対し、POI端末の改ざん/不正置換注意のトレーニングが提供され、その内容は以下を含む。
    1. デバイスの修正/トラブル対応のためのアクセスを許可する前に、修理/保守担当者の身元を確認する
    2. 確認なしに機器が設置/交換/返却されないようにする確実な手順を守る
    3. デバイス周辺での不審な行動に注意すること
    4. 疑わしい行動、デバイスの改ざん/不正置換の兆候を適切な担当者に報告

ネットワークの定期的な監視とテスト

要件 10: シスコン/CHDへの全アクセスをログに記録/監視

10.1 シスコン/CHDへの全アクセスを記録/監視するためのプロセス/メカニズムが定義/文書化

  • 10.1.1 要件10のセキポリが文書化/最新化/利用され/周知されている
  • 10.1.2 要件10活動の役割と責任が文書化/割当/理解されている

10.2 監査ログが実装され、異常や疑わしい活動の検出/イベントのフォレンジック分析をサポート

  • 10.2.1 監査ログは、全シスコン/CHDに対して有効/アクティブ
    • 10.2.1.1 監査ログでCHDの全ての個々のユーザクセスを記録
    • 10.2.1.2 監査ログには、アプリ/ステアカの対話的な使用を含め、管理アクセスを持つ個人が行った全アクションを記録
    • 10.2.1.3 監査ログは監査ログへの全アクセスを取得
    • 10.2.1.4 監査ログは、すべての無効な論理的アクセスの試行を記録
    • 10.2.1.5 監査ログは、以下のような識別情報/認証情報への全変更を記録
      1. 新しいアカウントの作成
      2. 特権の昇格
      3. 管理者アクセス権を持つアカウントに対する全変更/追加/削除
  • 10.2.1.6 監査ログは、以下を取得
    1. 新しい監査ログのすべての初期化
    2. 既存の監査ログのすべての開始/停止/一時停止

  • 10.2.1.7 監査ログはシステムレベルオブジェクトの全作成/削除を記録

  • 10.2.2 監査ログでは、監査可能イベントごとに次の詳細を記録
    1. ユーザの識別
    2. イベントの種類
    3. 日付と時間
    4. 成功/失敗の表示
    5. イベントの発生元
    6. 影響を受けるデータ/シスコン/リソース/サービスの識別または名前

10.3 監査ログが破壊/不正な改ざんから保護

  • 10.3.1 監査ログへの読み取りアクセスは、業務上必要な者に限定
  • 10.3.2 監査ログは、個人による改ざんを防ぐために保護されている
  • 10.3.3 監査ログは、外部に公開されているテクのものも含め、安全で一元的な内部ログサーバ/変更が困難な他の媒体に速やかにBackupされる
  • 10.3.4 監査ログに対して整合性監視/変更検出メカニズムを使用し、既存のログデータを変更すると警告を生成

10.4 監査ログをレビューし、異常/疑わしいアクティビティを識別できる

  • 10.4.1 以下の監査ログを少なくとも毎日一度レビュー
    1. 全セキュリティイベント
    2. CHD and/or SADを保存/処理/伝送する全シスコンのログ
    3. 全重要なシスコンのログ
    4. セキュリティ機能(例えば、NSC、IDS/IPS、認証サーバ)を実行する全サーバ/シスコンのログ
    • 10.4.1.1 監査ログのレビューに自動化のメカニズムを使用
  • 10.4.2 その他全てのシスコン(10.4.1 に規定外)のログを定期レビュー
    • 10.4.2.1 その他全てのシスコン(10.4.1 に規定外)のログを定期レビューの頻度は、12.3.1で指定された全要素に従って実行される、事業体のターゲットリスク分析で定義される
  • 10.4.3 レビューの過程で確認された例外や異常に対処

10.5 監査ログの履歴を保持し、分析に利用

  • 10.5.1 監査ログの履歴を少なくとも12カ月間保持、直近3カ月間は分析のために直ちに利用できるようにする

10.6 時刻同期メカニズムが、全システムで一貫した時刻設定を

  • 10.6.1 時刻同期技術により、システムクロック/時刻を同期させる
  • 10.6.2 システムは次のように正しく一貫した時刻に設定
    1. 1つ以上の指定したタイムサーバを使用
    2. 中央タイムサーバだけが外部から時刻を受信
    3. 外部から受信した時刻は、国際原子時/協定世界時(UTC)に基づく
    4. タイムサーバは、業界で認められた特定の外部ソースからのみ時間更新を受ける
    5. 複数のタイムサーバがある場合、正確な時間を保つために互いにピアリングを行う
    6. 内部システムは、中央タイムサーバからのみ時間情報を受信
  • 10.6.3 時刻同期の設定とデータは、以下のように保護
    1. 時刻データへのアクセスは、業務上必要な担当者のみに制限
    2. 重要なシステムの時刻設定の変更は、ログに記録され/監視され/レビューされる

10.7 重要なセキュリティ管理システムの障害を迅速に検知/報告/対応

  • 10.7.1 SPのための追加要件:重要なセキュリティ管理システムの障害を迅速に検知/警告/対処すること。以下の重要なセキュリティ対策システムの障害を含むが、これらに限定されない
    1. NWセキュリティ管理
    2. IDS/IPS
    3. FIM(File Integrity Monitoring/ファイル整合性監視)
    4. マルウェア対策ソリューション
    5. 物理アクセス制御
    6. 論理アクセス制御
    7. 監査ログメカニズム
    8. セグメン制御(if use)
  • 10.7.2 重要なセキュリティ対策システムの障害が迅速に検知/警告/対処される
    1. NWセキュリティ制御
    2. IDS/IPS
    3. 変更検出メカニズム
    4. マルウェア対策ソリューション
    5. 物理アクセス制御
    6. 論理アクセス制御
    7. 監査ログメカニズム
    8. セグメン制御(if use)
    9. 監査ログレビューメカニズム
    10. 自動化されたセキュリティテストツール(if use)

要件 11: システム/NWのセキュリティを定期的にテスト

11.1 システム/NWのセキュリティの定期テストするためのプロセス/仕組みが定義/理解

  • 11.1.1 要件11のセキポリが文書化/最新化/利用され/周知される
  • 11.1.2 要件11活動の役割と責任が文書化/割当/理解される

11.2 WFAPを特定/監視/不正なWFAPに対処

  • 11.2.1 承認されたWFAP/許可されていないWFAPは、以下のように管理
    1. WFAPの存在が検査される
    2. 全ての承認された/されていないWFAPが検出/識別
    3. テスト/検出/識別は最低でも1回/3ヶ月行われる
    4. 自動監視を使用する場合は、アラートで担当者に通知
  • 11.2.2 承認されているWFAPのインベントリが、文書化されたビジネス上の正当な理由を含めて、維持される

11.3 外部/内部の脆弱性を定期的に特定/優先順位付け/対処

  • 11.3.1 内部脆弱性スキャンは、以下のように実施
    1. 最低でも1回/3カ月は実施
    2. 高リスク/重要な脆弱性が解決される
    3. 再スキャンを実施し、高リスク/重要な脆弱性がすべて解決されていることを確認
    4. スキャンツールは、常に最新の脆弱性情報に更新
    5. スキャンは有資格者によって実施され、テスト担当者の組織的な独立性を確保
    • 11.3.1.1 他のすべての該当する脆弱性は、以下のように管理される
      1. 要件12.3.1に基づいて対処
      2. 必要に応じて再スキャンを実施
    • 11.3.1.2 内部脆弱性スキャンは、以下で認証スキャンを実施
      1. 認証スキャンの認証情報を受入できないシステムは、文書化される
      2. スキャンの認証情報を受入るシステムには十分な権限を使用
      3. 認証スキャンに使用したアカウントが対話的ログインに使用できる場合は、要件 8.2.2で管理する
    • 11.3.1.3 大幅な変更後には、次のように内部スキャンを実施
      1. 高リスク/重要な脆弱性が解決される
      2. 必要に応じて再スキャンを実施
      3. スキャンは有資格者によって実施され、テスターの組織的独立性を確保
  • 11.3.2 外部からの脆弱性スキャンは、次のように実施
    1. 最低でも1回/3カ月は実施
    2. PCISSC認定のASVによって実施
    3. 脆弱性が解決され、ASVの合格スキャンの要件を満たす
    4. 必要に応じて再スキャンを行い、ASVの合格スキャンの要件を満たして脆弱性の解決を確認
    • 11.3.2.1 外部スキャンは、大幅な変更後に次のように実施
      1. CVSS4.0以上の脆弱性が解決される
      2. 必要に応じて再スキャンを実施
      3. スキャンは有資格者によって実施され、テスターの組織的独立性を確保

11.4 外部/内部へのペンテストを定期実施し、悪用可能な脆弱性/セキュリティ上の弱点を是正

  • 11.4.1 侵入テストの方法論は、事業体にて定義/文書化/実施され、以下を含む
    1. 業界で受入のペンテストのアプローチ
    2. CDEの境界全体/重要システムを対象
    3. NWの内側/外側の両方テスト
    4. セグメンテーションと適用範囲縮小制御の有効性テスト
    5. 要件6.2.4に記載された脆弱性を最低限特定するためのアプリ層ペンテスト
    6. OSだけでなく、NW機能をサポートする全コンポーネントを包含するNW層のペンテスト
    7. 過去12か月に経験した脅威と脆弱性のレビューと考察
  • 11.4.2 内部ペンテストを実施
    1. 事業者が定義した方法論に従う
    2. 少なくとも12カ月に1回
    3. インフラ/アプリの大幅なVerUp/変更後
    4. 認定された内部リソース/外部第三者によるもの
    5. テスターの組織的な独立性がある
  • 11.4.3 外部ペンテストを実施
    1. 事業体が定義した方法論に従う
    2. 少なくとも12カ月に1回
    3. インフラ/アプリの大幅なVerUp/変更後
    4. 認定された内部リソース/第三者によるもの
    5. テスターの組織的な独立性がある
  • 11.4.4 ペンテストで発見された悪用可能な脆弱性/セキュリティ上の弱点は、以下のように修正
    1. 要件6.3.1でのセキュリティ上の問題でのリスクに関する事業体の評価に従う
    2. 修正内容を確認するためにペンテストが繰り返される
  • 11.4.5 CDEを他のNWから分離するためにセグメンを使用する場合、セグメン制御に対してペンテストを以下のように実施
    1. 少なくとも12カ月に一度/セグメン制御/方法に変更があった後
    2. 使用中の全セグメン制御/方法を対象
    3. 事業体が定義したペンテストの方法論に従う
    4. セグメン制御/方法が運用され、効果的であること、CDEが適用範囲外の全システムからの分離を確認
    5. セキュリティレベルの異なるシステムを分離するために隔離を使用した場合の有効性確認
    6. 認定された内部リソース/第三者によって実施される
    7. テスターの組織的な独立性がある
  • 11.4.6 SPのみに対する追加要件:CDEを他のNWから分離のためセグメンを使う場合、セグメン制御について次のようにペンテストを実施
    1. 最低で半年に一度、セグメン制御/方法を変更後
    2. 使用する全セグメン制御/方法を対象
    3. 事業体が定義したペンテストの方法論に従う
    4. セグメン制御/方法が運用し効果的である/CDEが適用範囲外の全システムからの分離を確認
    5. セキュリティレベルの異なるシステムを分離するためにセグメンを使う場合の有効性を確認
    6. 認定された内部リソース/3rd Partyにて実施。
    7. テスターの組織的な独立性がある
  • 11.4.7 マルチテナントSPのみの追加要件: マルチテナント型SPは、要件11.4.3/11.4.4に従い、外部侵入試験について顧客をサポート

11.5 NWの侵入/予期しないファイルの変更が検出され/対応される

  • 11.5.1 NWへの侵入を検知/防止するために、次の侵入検知技術/侵入防止技術が使用される
    1. CDEの境界の全トラフィックを監視
    2. CDE内の重要なポイントの全トラフィックを監視
    3. 担当者は侵入疑いがあると警告される
    4. 全ての侵入検知/防止エンジン/ベースライン/シグネチャが最新を保持
    • 11.5.1.1 SPのみに対する追加要件:侵入検知/侵入防止技術が、マルウェアの秘密通信経路を検知/警告/防止/対処
  • 11.5.2 変更検出メカニズムは次のように展開
    1. 重要なファイルの不正な変更/追加/削除を担当者に警告
    2. 最低でも週1回、重要ファイルを比較

11.6 決済ページの不正な変更を検知/対応

  • 11.6.1 変更/改ざん検知のメカニズムは、次のように展開
    1. 消費者ブラウザが受信したHTTPヘッダーと決済ページのコンテンツに対する不正な変更 を担当者に警告
    2. メカニズムは、受信したHTTPヘッダーと決済ページを評価できる構成
    3. メカニズムの機能は次のように実行
    4. 最低でも7日に1回 or 定期的に

情報セキュリティポリシーの維持

要件 12: 組織の方針とPGによって情報セキュリティをサポート

12.1 組織の情報資産の保護を管理、方向付ける包括的な情報セキ方針が周知/最新化

  • 12.1.1 要件12のセキポリが文書化/最新化/利用され/周知される

  • 12.1.2 要件12活動の役割と責任が文書化/割当/理解される

  • 12.1.3 セキポリにより、全担当者に対して情報セキの役割と責任を明確に定義、全担当者が情報セキの責任を認識

  • 12.1.4 情報セキに関する責任が、最高情セキ責任者/情セキに精通した経営陣のメンバーを割当

12.2 エンドユーザ・テクの使用に関する方針が定義/実施

  • 12.2.1 エンドユーザ・テクに関する利用ポリシーが文書化/実施される
    1. 権限者による明示的な承認
    2. 技術の許容される使用方法
    3. 従業員が使用可能な会社承認の製品リスト(HW/SW含む)

12.3 CDEに対するリスクが正式に特定/評価/管理

  • 12.3.1 実行頻度に柔軟性がある各PCI DSS要件は、文書化され、以下を含むターゲットリスク分析によってサポートされる
    1. 保護対象の資産を特定
    2. 要件が保護する脅威を特定
    3. 脅威の実現可能性/影響に寄与する要因の特定
    4. 脅威が実現する可能性を最小化するために、要件の実行頻度を決定、正当性を含む分析結果
    5. 最低でも12カ月に一度、対象となる各リスク 分析をレビュー、結果がまだ有効か/最新のリスク分析が必要かを判断
    6. 年次レビューの決定通りに、必要な時期にリスク分析を更新
  • 12.3.2 カスアプで事業体が満たす各PCI DSS要件について、以下を含むターゲットリスク分析を実施
    1. 付録Dでの各要素の詳細を示す文書化された証拠。カスアプで指定された各要素を詳述する文書化された証拠
    2. 文書化された証拠を上級管理職が承認
    3. 最低でも12カ月に一度、ターゲットリスク分析を実施
  • 12.3.3 使用中の暗号スイート/プロトコルが文 書化され、最低でも12カ月に一度、以下のように見直
    1. 使う全暗号スイート/プロトコルの最新のインベントリ
    2. 使う全暗号スイートとプロトコルの継続的な有効性に関して、業界動向を積極的に監視
    3. 暗号の脆弱性で予測変化に対する文書化された戦略
  • 12.3.4 使用中のHW/SW技術を最低でも12カ月に一度、以下を含む見直
    1. 当該技術が、引き続きベンダからのセキュリテ ィ修正を速やかに受けているかを分析
    2. テクが引き続き事業体のPCI DSS準拠を サポートすることを分析
    3. ベンダがテクの「耐用年数終了」計画を発表した場合など、テクに関連する業界発表/傾向の文書化
    4. ベンダが「耐用年数終了」計画を発表したもの を含め、古くなったテクを修正するための、上級管理職が承認した計画の文書化

12.4 PCI DSSコンプラを管理する

  • 12.4.1 SPのみの追加要件: CHDの保護とPCI DSS準拠PGに対する経営陣の責任が設定され、その内容は以下
    1. PCI DSS準拠を維持の全体の説明責任
    2. PCI DSS準拠を維持の全体の説明責任:PCI DSS準拠PGに関する憲章を定義/経営陣に伝える
  • 12.4.2 SPのみの追加要件: レビューは、担当者が全セキポリと運用手順に従って業務遂行を確認するために、最低でも3カ月に1回実施。 レビューは、業務遂行の責任者以外の担当者が実施し、以下の業務を含む
    1. 日々のログレビュー
    2. NSCの設定レビュー/新規システムに対する設定基準の適用
    3. セキュリティアラートへの対応
    4. 変更管理プロセス
    • 12.4.2.1 SPのみの追加要件: 12.4.2 に従って実施されたレビューは、以下を含み文書化
      1. レビューの結果
      2. 要件12.4.2で実施されていないタスクに対して実施した文書化された是正措置
      3. PCI DSSコンプラPGの責任を割り当てられた担当者の結果レビュー/署名

12.5 PCI DSSの適用範囲が文書化/確認される

  • 12.5.1 機能/用途の説明を含むPCI DSSの適用範囲にあるシスコンのインベントリが維持/最新状態保持
  • 12.5.2 PCI DSSの適用範囲は、最低でも12カ月 に1回/適用範囲内の大幅変更があった場合に、文書化され、事業体にて確認される。最低でも適用範囲の検確認には以下を含む
    1. 様々な決済段階(オーソリ/キャプチャ決済/チャージバック/返金など)/受け入れチャネル(カード提示/カード非提示/電子商取引など)の全データフローを特定
    2. 要件 1.2.4に従って、全データフロー図を更新
    3. アカウントデータが保存/処理/伝送される全場所を特定。1）現在定義されているCDE以外の場所、2)CHDを処理するアプリ、3)システム/NW間の伝送、4)ファイルのBackupを含む
    4. CDE内の全シスコン/CDEに接続されているもの、CDEのセキュリティに影響する可能性のあるものを特定
    5. 使用中の全セグメン制御/CDEがセグメンされている環境を特定
    6. CDEにアクセス可能な第三者からの全接続を特定
    7. 識別された全データフロー/アカウントデータ/シスコン/セグメン制御/CDEにアクセスする第三者からの接続が範囲に含まれることを確認
    • 12.5.2.1 SPのみの追加要件:PCI DSSの適用範囲は、最低でも6カ月に1回/適用範囲内の大幅変更があった場合に文書化され、事業体にて確認される。適用範囲の確認には、最低でも要件12.5.2 で指定された全要素が含まれる
  • 12.5.3 SPのみの追加要件: 組織構造の大幅な変更により、PCI DSSの範囲/管理の適用性への影響を文書化した内部レ ビューが行われ、その結果が経営陣に伝達

12.6 セキュリティ意識教育が継続的に実施

  • 12.6.1 正式なセキュリティ意識向上PGが実施され、全担当者に組織の情報セキポリ/手順/CHDの保護における各自の役割を認識

  • 12.6.2 セキュリティ啓発PGは
    1. 最低でも12カ月に1回見直す
    2. 事業体のCDEのセキュリティに影響する可能性のある新脅威/脆弱性/CHDの保護の役割について担当者に提供する情報に対処するための必要な更新
  • 12.6.3 担当者はセキュリティ意識向上トレーニングを受ける
    1. 入社時/最低でも12カ月に1回
    2. 複数のコミュニケーション手段を用いる
    3. 従業員は、情報セキュリティ方針/手順を読み、理解したことを最低でも12カ月に1度、同意
    • 12.6.3.1 セキュリティ意識向上トレーニングには、 CDEのセキュリティに影響する可能性のある脅威/脆弱性の意識を含む
      1. フィッシング/関連攻撃
      2. ソーシャルエンジニアリング
    • 12.6.3.2 セキュリティ啓発トレーニングには、要件12.2.1に従って、エンドユーザ・テクの許容される使用に関する啓発を含む

12.7 内部脅威によるリスクを低減するために、担当者のスクリーニングを行う

  • 12.7.1 CDEにアクセス可能の担当者は、現地法の制約の範囲内で、雇用前にスクリーニングされ、内部情報源からの攻撃のリスクを最小化

12.8 TPSPに関連する情報資産へのリスクを管理

  • 12.8.1 アカウントデータを共有/セキュリティに影響可能なTPSPの全リストを維持
  • 12.8.2 TPSP との契約書を次のように維持
    1. アカウントデータを共有/CDEのセキュリティに影響可能な全TPSPとの間に書面で同意を維持
    2. 書面同意には、TPSPが所有するアカウントデータ/事業体のために保存/処理/伝送するアカウントデータ/事業体のCDEのセキュリティに影響可能な範囲について、 TPSPが責任を負うというTPSPからの確認が含まれる

  • 12.8.3 TPSPと契約前に適切なデューディリジェンスを含む、TPSPを契約するための確立されたプ ロセスを実施

  • 12.8.4 TPSPのPCI DSS準拠状況を最低でも12カ月に1度監視するPGを導入

  • 12.8.5 どのPCI DSS要件が各TPSP/事業体によって管理/TPSPと事業体の間で共有されている要件かの情報を保持

12.9 TPSPは顧客のPCI DSS準拠をサポート

  • 12.9.1 SPのみの追加要件: TPSPは、TPSPが保有する/顧客に代わって保存/処理/伝送するアカウントデータのセキュ リティ、または顧客のCDEのセキュリティに影響可能性な範囲について、顧客が責任を負うことを認める内容の顧客に書面による契約を維持
  • 12.9.2 SPのみの追加要件: TPS は、要件12.8.4/12.8.5を満たすため、顧客の要求に応じて以下を提供し顧客の情報開示要求をサポート
    1. TPSPが顧客に代わって実行するあらゆるサー ビスに関するPCI DSS準拠状況情報
    2. どのPCI DSS要件がTPSPの責任で、どれが顧客の責任かに関する情報(共有責任を含む)

12.10 CDEに影響可能なセキインの疑/確認されたインシデントに即座に対応

  • 12.10.1 インシデント対応計画が存在し、セキインの疑い/確認があった場合に発動できる状態。この計画には以下を含む
    1. 少なくとも、ペイメントブランド/アクワイアラへの通知を含む、セキインが発生した場合の役割/責任/連絡/問い合わせ戦略
    2. インシデントの種類に応じた特定の封じ込め/低減活動を伴うインシデント対応手順
    3. ビジネスの復旧と継続の手順
    4. データBackupプロセス
    5. 侵害報告に関する法的要件の分析
    6. 全ての重要なシスコンの範囲と対応
    7. ペイメントブランドによるインシデント対応手順の参照/包含
  • 12.10.2 最低でも12カ月に一度、セキイン対応計画は、
    1. 見直され、必要に応じて内容更新
    2. 要件12.10.1に記載されている全要素を含めてテスト

  • 12.10.3 セキインの疑い/確認に対応するため、24/365対応可能な担当者が指定されている

  • 12.10.4 セキインの疑い/確認に対応する担当者は、インシデント対応の責任について適切かつ定期的に訓練

    • 12.10.4.1 インシデント対応担当者の定期訓練の頻度は、要件12.3.1の規定に従って実施。事業体の目標リスク分析で定義
  • 12.10.5 セキイン対応計画には、 セキュリティ監視システムからのアラート監視/対応が含まれる
    1. 侵入検知システム/侵入防止システム
    2. NWセキュリティ管理
    3. 重要ファイルの変更検出メカニズム
    4. 決済ページの変更/改ざん検知メカニズム
    5. 未許可のWFAPの検出

  • 12.10.6 セキイン対応計画は、得られた教訓を踏まえて/業界動向を組み込み変更と改善

  • 12.10.7 想定外の場所に保存されたPANが検出された場合に開始されるインシデント対応手順が用意される
    1. CDEの外側でPANが発見された場合の対処方法を決定。これには、PANの検索/安全な削除/現在定義されているCDEへの移行などが含まれる
    2. 機密性認証データがPANと共に保存されているかどうかを特定
    3. アカウントデータの出所、どのようにして想定外の場所に行き着いたかを特定
    4. アカウントデータが想定外の場所にある原因と なったデータ漏えい/プロセスギャップを修正