支付行业PCI DSS 3.0学习概述
支付卡行业 (PCI) 数据安全标准 要求和安全评估程序
0x00 前言
本支付卡行业数据安全标准 (PCI DSS) 旨在促进并增强持卡人的数据安全，便于统一的数据安全措施在全球范围内的广泛应用。PCI DSS 为意在保护持卡人数据的技术和操作要求提供了一个基准。PCI DSS 适用于所有涉及支付卡处理的实体，包括商户、处理机构、收单机构、发卡机构、服务 提供商以及所有其他存储、处理或传输持卡人数据 (CHD) 和/或敏感验证数据 (SAD) 的实体。以下是对 12 条 PCI DSS 要求的主要概述。
本文档《PCI 数据安全标准要求和安全评估程序》将 12 条 PCI DSS 要求和相应的测试程序合并为一个安全评估工具。该工具在 PCI DSS 遵从性评估期间专门用作实体验证程序的组成部分。以下提供的详细指南和最优方法可协助实体准备、执行 PCI DSS 评估并汇报评估结果。PCI DSS 要求 和测试程序自第 14 页开始。除当地、地区和行业法律法规外，PCI DSS 至少要包含一组持卡人数据保护要求，并通过制定附加控制措施和操作规程加以完善，以进一步规避风险。另外，立法或监管规定可能会要求对个人可识别信息或其他数据元素（例如持卡人姓名）施以特别保护。PCI DSS 不能取代当地或地区法律、 政府法规或其他法律要求。
0x01适用性
PCI DSS 适用于所有涉及支付卡处理的实体，包括商户、处理机构、收单机构、发卡机构、服务提供商以及所有其他存储、处理或传输持卡人数据和/或敏感验证数据的实体。持卡人数据和敏感验证数据的定义如下：| 帐户数据 | ||
| 持卡人数据包括： | 敏感验证数据 | |
| § 主帐户 (PAN) § 持卡人姓名 § 失效日 § 业务码 |
全磁道数据（磁条数据或芯片上的等效 数据） CAV2/CVC2/CVV2/CID PIN/PIN 数据块 |
|
主帐户是持卡人数据的决定性因素。 如果持卡人姓名、业务码和/或失效日与 PAN 一起存储、处理或传输，或以其他方式出现在持卡人数据环境中，则必须按照所有适用的 PCI DSS 要求予以保护。
PCI DSS 要求适用于可存储、处理或传输帐户数据（持卡人数据和/或敏感验证数据）的组织和环境。部分 PCI DSS 要求也可能适用于外包其支付操作或 CDE 管理的组织 1。此外，将 CDE 或支付操作外包给第三方的组织有责任确保第三方按照适用的 PCI DSS 要求保护帐户数据。
下页中的表格列举了持卡人数据和敏感验证数据的常用元素、是否允许存储各数据元素，以及是否必须保护各数据元素。该表格的内容并非详尽无遗，只用于列举适用于每种数据元素的不同类型的要求。
| 帐户 数据 | 持卡人数据 | 数据元素 | 允许存储 | 按照要求 3.4 |
| 主帐户 (PAN) | 是 | 是 | ||
| 持卡人姓名 | 是 | 否 | ||
| 敏感验证数据 | 业务码 | 是 | 否 | |
| 失效日 | 是 | 否 | ||
| 全磁道数据 3 | 否 | 要求 3.2 规定不能存储 | ||
| CAV2/CVC2/CVV2/CID4 | 否 | 要求 3.2 规定不能存储 | ||
| PIN/PIN 数据块5 | 否 | 要求 3.2 规定不能存储 |
0x02 PCI DSS 与 PA-DSS 的关系
PCI DSS 对 PA-DSS 应用程序的适用性
实体使用符合支付应用程序数据安全标准 (PA-DSS) 的应用程序本身并不表示其遵从 PCI DSS 要求，这是因为应用程序必须应用于符合 PCI DSS的环境，并遵守支付应用程序供应商提供的 PA-DSS 实施指南。
凡存储、处理或传输持卡人数据的应用程序均属于实体的 PCI DSS 评估范围，包括已按照 PA-DSS 验证的应用程序。PCI DSS 评估应确认经 PA-DSS 验证的支付应用程序已按照 PCI DSS 的要求正确配置并安全应用。如果支付应用程序已经过任何定制，在 PCI DSS 评估期间则需开展更深入 的审核，因为该应用程序可能已经不能代表经 PA-DSS 验证的版本。
PA-DSS 要求出自《PCI DSS 要求和安全评估程序》（详见本文档）。PA-DSS 详细规定了支付应用程序必须满足的要求，以促使客户遵守 PCIDSS。
在符合 PCI DSS 的环境中使用安全支付应用程序，可最大限度减少潜在的安全漏洞，从而防止 PAN、全磁道数据、卡片验证码与验证值 (CAV2、CID、CVC2、CVV2)、PIN 和 PIN 数据块遭受威胁，并避免因安全漏洞所造成的严重欺诈行为。要确定 PA-DSS 是否适用于指定的支付应用程序，请参阅《PA-DSS 程序指南》，该《指南》可在 www.pcisecuritystandards.org 上获取。
PCI DSS 对支付应用程序供应商的适用性
如果支付应用程序供应商可存储、处理或传输持卡人数据或有权访问其客户的持卡人数据（例如充当服务提供商的角色），则 PCI DSS 适用于该供应商。
0x03 PCI DSS 要求的范围
| 本 PCI DSS 安全要求适用于持卡人数据环境中包含或与之连接的所有系统组件。持卡人数据环境 (CDE) 包含存储、处理或传输持卡人数据或敏感 |
| 验证数据的人员、流程和技术。“系统组件”包括网络设备、服务器、计算设备和应用程序。系统组件包括但不限于： |
| · 提供安全服务（例如验证服务器）、方便分段（例如内部防火墙）或可能影响 CDE 安全性（例如名称解析或 web 跳转服务器）的系统。 |
| · 虚拟化组件，例如虚拟机、虚拟交换机/路由器、虚拟设备、虚拟应用程序/桌面和虚拟机监控程序。 |
| · 网络组件，包括但不限于防火墙、交换机、路由器、无线接入点、网络设备和其他安全设备。 |
| · 服务器类型，包括但不限于 web、应用程序、数据库、验证、邮件、代理、网络时间协议 (NTP) 和域名系统 (DNS)。 |
| · 应用程序，包括所有购买和自定义的应用程序以及内部和外部（例如互联网）应用程序。 |
| · 位于 CDE 内或连接到 CDE 的任何其他组件或设备。 |
| PCI DSS 评估的第一步是准确确定审核范围。评估至少每年进行一次，接受评估的实体应在年度评估前查找持卡人数据的所有位置和数据流并确保其包含在 PCI DSS 的范围内，从而确定实体 PCI DSS 范围的准确性。要确定 PCI DSS 范围的准确性和适宜性，可执行下列步骤： |
| § 接受评估的实体查找并记录其环境中存在的所有持卡人数据，确认所有持卡人数据均包含在当前规定的 CDE 之内。 |
| § 在确定并记录持卡人数据的所有位置后，实体可利用相关结果确认 PCI DSS 的范围是否适宜（例如，结果可能是一个关于持卡人数据位置 的图表或目录）。 |
| § 实体应考虑任何属于 PCI DSS 评估范围和 CDE 组成部分的持卡人数据。如果实体发现当前未纳入 CDE 的数据，应将这些数据安全地删除、 迁移到当前规定的 CDE 内，或重新界定 CDE 以纳入该数据。 |
| § 实体将保留有关说明如何确定 PCI DSS 范围的文档记录。这些文档记录留待评估商审核以及/或留作下一次年度 PCI DSS 范围确认活动的 参考。 |
| 对于每一次 PCI DSS 评估，评估商都必须验证评估范围是准确界定并有文档记录的。 |
3.1 网络分段
| 持卡人数据环境的网络分段或将持卡人数据环境与实体网络的剩余部分隔离（分段）并非 PCI DSS 的一项要求。但这种方法值得大力推荐，因为它可以： | ||
| § 缩小 PCI DSS 的评估范围 | ||
| § 减少 PCI DSS 的评估费用 | ||
| § 降低实施和维护 PCI DSS 控制的成本和难度 | ||
| § 降低组织面临的风险（通过将持卡人数据合并到更少、更易控制的位置来降低风险） | ||
| 如果没有足够的网络分段（有时也称为“扁平网络”），则整个网络均属于 PCI DSS 的评估范围。网络分段可通过若干物理或逻辑方法来实现，例如 正确配置的内部网络防火墙、带有严格访问控制列表的路由器或其他限制访问特定网络分段的技术。如果被视为不属于 PCI DSS 的评估范围，则系 统组件必须与 CDE 正确隔离（分段），这样即便该范围外系统组件受到威胁，也无法影响 CDE 的安全性。 | ||
| 要缩小持卡人数据环境的范围需满足一个重要的前提条件，即清楚了解与持卡人数据的存储、处理或传输有关的业务需求和流程。通过消除不必要 的数据和合并必要的数据将持卡人数据限制尽量少的位置，这可能需要对长期业务实践进行重建。 | ||
| 通过数据流程图记录持卡人数据流有助于全面了解所有的持卡人数据流，并确保任意网络分段在隔离持卡人数据环境时均有效。 | ||
| 如果已设置网络分段并将其用于缩小 PCI DSS 的评估范围，则评估商必须确认该分段足以缩小评估范围。处于高层级时，充足的网络分段可将存储、 处理或传输持卡人数据的系统与其他无法执行此类操作的系统隔离开来。然而，就具体实施的网络分段而言，其充足性非常多变并且取决于多种因 素，例如特定网络的配置、部署的技术以及可能已实施的其他控制措施。 | ||
| 附录 D：网络分段与企业设施/系统组件抽样提供了更多关于网络分段和抽样对 PCI DSS 评估范围所产生影响的信息。 | ||
3.2无线
在常规业务流程中实施 PCI DSS 的最优方法
3.3采用第三方服务提供商 / 外包
对需要接受年度现场评估的服务提供商而言，必须对持卡人数据环境中的所有系统组件执行遵从性验证。
服务提供商或商户可通过第三方服务提供商代为存储、处理或传输持卡人数据，或管理路由器、防火墙、数据库、物理安全和/或服务器等组件。在 此情况下，持卡人数据环境的安全性可能会受影响。
各方应清楚确定服务提供商的 PCI DSS 评估范围内所包含的服务和系统组件、服务提供商规定的具体 PCI DSS 要求以及服务提供商的客户有责任 纳入各自 PCI DSS 审核的任何要求。例如，托管管理供应商应明确规定哪些 IP 地址应作为其季度安全漏洞扫描过程的一部分进行扫描，哪些 IP 地 址由客户负责纳入各自的季度扫描。
第三方服务提供商验证遵从性时有两种选择：
1) 他们可自行接受 PCI DSS 评估并向客户提供证据证明其遵从性；或
2) 如果未自行接受 PCI DSS 评估，则需在每位客户的 PCI DSS 评估中接受服务审核。
如果第三方自行接受 PCI DSS 评估，则应向客户提供充分证据，证明该服务提供商的 PCI DSS 评估范围涵盖客户适用的服务，且相关 PCI DSS 要
求已检查完毕并认定现已到位。服务提供商向客户提供的具体证据类型将取决于双方的现有协议/合同。例如，提供 AOC 和/或服务提供商 ROC（为 保护任何机密信息而编写）的相关部分有助于提供全部或部分信息。
此外，商户和服务提供商必须管理并监督所有有权访问持卡人数据的相关第三方服务提供商的 PCI DSS 遵从性。请参阅本文档中的要求 12.8 了解 详情。
3.4在常规业务流程中实施 PCI DSS 的最优方法
| 为确保安全控制继续得以妥善实施，实体应在常规业务 (BAU) 活动中实施 PCI DSS，作为整个安全策略的一部分。实体可借此持续监控其安全控制的有效性，并在 |
| 两次 PCI DSS 评估之间维护 PCI DSS 遵从性环境。 关于应如何将 PCI DSS 纳入常规业务活动的方式包括但不限于： |
| 1. 监控安全控制（例如防火墙、入侵检测系统/入侵防御系统 (IDS/IPS)，文件完整性监控 (FIM)、反病毒、访问控制等） – 以确保其按计划有效地运作。 |
| 2. 确保及时发现所有安全控制故障并作出响应。安全控制故障响应流程应包括： |
| · 恢复安全控制 |
| · 找出故障原因 |
| · 发现并解决安全控制故障期间出现的任何安全问题 |
| · 实施防范措施（例如过程或技术控制），防止故障原因再次出现 |
| · 恢复对安全控制的监控，或在一段时间内加强监控力度，以确认控制正在有效运行 |
| 3. 在完成环境变更（例如增加新系统、变更系统或网络配置）前审查这些变更，并执行下列操作： |
| · 确定对 PCI DSS 范围的潜在影响（例如允许 CDE 中的某个系统与另一系统连接的一条防火墙新规则可能会将额外的系统或网络纳入 PCI DSS 的范 围） |
| · 确定 PCI DSS 要求适用于受变更影响的系统和网络（例如，如果一个新系统属于 PCI DSS 的范围，则可能需要按照系统配置标准进行配置，包括 |
| FIM、AV、补丁和检查日志等，并需添加进季度漏洞扫描计划） |
| · 更新 PCI DSS 范围并视情况实施安全控制 |
| 4. 组织结构如有变化（例如公司合并或收购），应正式审核其对 PCI DSS 范围和要求的影响。 |
| 5. 应定期进行审核和沟通，以确保 PCI DSS 要求继续有效并且工作人员均遵守安全流程。此类定期审核应涵盖所有设施和位置（包括零售店、数据中心等） |
| 并应包括系统组件（或系统组件样本）审核，以确认 PCI DSS 要求继续有效，例如配置标准已应用，补丁和 AV 已更新，检查日志已审核等。定期审核的频 度应由实体根据其环境的规模和复杂性确定。 |
| 此类审核还可用于确认已保留适当证据（例如检查日志、漏洞扫描报告、防火墙检查等），从而帮助实体为下一次遵从性评估做准备。 |
| 6. 至少每年审核一次硬件和软件技术，确认其继续获得供应商的支持，并能满足实体的安全要求（包括 PCI DSS）。如果发现这些技术未继续获得供应商的支 持或不能满足实体的安全需求，实体则应制定补救方案、更新或者甚至在必要时替换该技术。 |
| 除了上述方法外，组织还可以考虑实现安全功能的职责分离，以便将安全性和/或审计功能与操作功能分开。在单人承担多重职责的环境中（例如管理和安全操作）， 可以转让职责，确保没有任何个人拥有流程的端到端控制，而缺少一个独立的检查点。例如，可以将配置工作和变更审批工作分配给不同的人。 |
3.5 对于评估商：企业设施/系统组件抽样
| 如果企业设施和/或系统组件的数量很多，评估商可选择采取抽样的方式简化评估流程。 |
| 评估商可以对企业设施/系统组件进行抽样，作为对实体 PCI DSS 遵从性审核的一部分，但实体不可将 PCI DSS 要求仅应用于其环境的样本部分 |
| （例如，有关季度漏洞扫描的要求适用于所有系统组件）。同样，评估商也不可只审核样本部分的 PCI DSS 遵从性要求。 |
| 在考虑被评估环境的整体范围和复杂性后，评估商可独立选择有代表性的企业设施/系统组件样本，以评估实体对 PCI DSS 要求的遵从情况。必须 首先明确企业设施样本，然后明确每个选定的企业设施中的系统组件样本。样本必须选择所有企业设施类型和位置中以及所选企业设施内所有系统 组件类型中具有代表性的部分。样本必须足够大，这样才能让评估商确信控制措施已按预期实施。 |
| 企业设施包括但不限于：公司办公室、商店、加盟店、处理机构、数据中心及处于不同位置的其他设施类型。抽样应包括每个所选企业设施内的系 |
| 统组件。例如，对于每个选定的企业设施，均包括适用于受审核区域的各种操作系统、功能和应用程序。 |
| 例如，评估商可选定企业设施中的一个样本，包括运行 Apache 的 Sun 服务器、运行 Oracle 的 Windows 服务器、运行遗留卡处理应用程序的大型 机系统、运行 HP-UX 的数据传输服务器和运行 MySQL 的 Linux 服务器。如果所有应用程序均从一个版本的操作系统（例如 Windows 7 或 Solaris 10）运行，该样本仍应包含各种应用程序（例如数据库服务器、web 服务器、数据传输服务器）。 |
| 在独立选择企业设施/系统组件样本时，评估商应考虑以下方面： |
| § 如果现有可确保一致性且每个企业设施/系统组件必须遵守的标准化、集中式的 PCI DSS 安全与操作流程和控制，则样本总量可比没有标准 流程/控制时小。样本必须足够大，这样才能让评估商合理确信所有企业设施/系统组件均按照标准流程配置。评估商必须确认此类标准化、 集中式控制均已实施并有效运作。 |
| § 如果现有一种以上的标准安全和/或操作流程（例如针对不同类型的企业设施/系统组件），则样本必须足够大才能包含采用每种安全流程的 企业设施/系统组件。 |
| § 如果目前未采用任何 PCI DSS 标准流程/控制，并且每个企业设施/系统组件均通过非标准流程进行管理，则样本必须更大，这样评估商才能 确信每个企业设施/系统组件均已适当执行 PCI DSS 要求。 |
| § 系统组件的样本必须包含正在使用的每个类型和组合。例如，在对应用程序抽样时，样本必须包含每类应用程序的所有版本和平台。 |
| 对于使用抽样法的每种情形，评估商必须： |
| § 记录抽样方法和样本容量背后的依据， |
| § 记录并验证确定样本容量时使用的标准化 PCI DSS 流程和控制，以及 |
| § 解释样本适宜且在整体中具有代表性的原因。 评估商必须在每次评估中重复验证抽样依据。如果要采用抽样法，必须为每次评估选择不同的企业设施和系统组件样本。 |
0x04 补偿性控制
评估商每年均须记录、审核和验证补偿性控制一次，并同时提交遵从性报告，具体遵照附录 B：《补偿性控制》和附录 C：《补偿性控制工作表》。
对于每项补偿性控制，必须填写《补偿性控制工作表》（附录 C）。此外，应在遵从性报告相应的 PCI DSS 要求栏内记录补偿性控制结果。 如需了解更多关于“补偿性控制”的详情，请参阅上述附录 B 和 C。
0x05 遵从性报告的说明与内容
PCI DSS ROC 报告模板中现提供有遵从性报告 (ROC) 的说明与内容。必须使用 PCI DSS ROC 报告模板作为创建遵从性报告的模板。接受评估的实体应遵守每个支付品牌各自的报告要求，以确保各支付品牌确认实体 的遵从状态。请与各支付品牌或收单机构联系，确定报告要求和说明。
0x06 PCI DSS 评估流程
1. 确认 PCI DSS 的评估范围。
2. 根据每项要求的测试程序执行环境 PCI DSS 评估。
3. 如果需要，纠正任何不到位的项目。
4. 根据适用的 PCI 指南和说明，完成适用的评估报告（即自我评估调查问卷 (SAQ) 或遵从性报告 (ROC)），包括所有补偿性控制文档记录。
5. 如果适用，完成服务提供商或商户的遵从性证明书。遵从性证明书可从 PCI SSC 网站获取。
6. 向收单机构（商户）、支付品牌或其他申请机构（服务提供商）提交 SAQ 或 ROC、遵从性证明书以及任何其他要求的文档记录（例如 ASV 扫描报告）。
0x07 参考资料
https://github.com/ym2011/SecurityManagement/tree/master/PCI DSS
欢迎大家分享更好的思路，热切期待^^_^^ !