目录 引言和 PCI 数据安全标准概述...3 PCI DSS 适用性信息...4 PCI DSS 要求合规性的评估范围...5 网络分段... 5 无线... 5 第三方 / 外包... 6 业务场所和系统组件抽样... 6 补偿性控制... 7 合规性报告的说明与内容...8 报告内容和格式..

Transcription

1 支付卡行业 (PCI) 数据安全标准 要求和安全评估程序 版本 1.2

2 目录 引言和 PCI 数据安全标准概述...3 PCI DSS 适用性信息...4 PCI DSS 要求合规性的评估范围...5 网络分段... 5 无线... 5 第三方 / 外包... 6 业务场所和系统组件抽样... 6 补偿性控制... 7 合规性报告的说明与内容...8 报告内容和格式... 8 未清项的再验证 PCI DSS 合规 - 完成步骤 详细的 PCI DSS 要求和安全评估程序...11 构建并维护安全的网络 要求 1: 安装并维护防火墙配置, 以保护持卡人数据 要求 2: 系统密码和其他安全参数不使用供应商提供的默认设置 保护持卡人数据 要求 3: 保护存储的持卡人数据 要求 4: 在开放型的公共网络中传输持卡人数据时会加密 维护漏洞管理程序 要求 5: 使用并定期更新杀毒软件或程序 要求 6: 开发 维护安全系统和应用程序 执行严格的访问控制措施 要求 7: 限制为只有业务需要知道的人才能访问持卡人数据 要求 8: 为每位拥有计算机访问权限的用户分配唯一的 ID 要求 9: 限制对持卡人数据的物理访问 定期监控网络和测试网络 要求 10: 跟踪和监控访问网络资源和持卡人数据的所有操作 要求 11: 定期测试安全系统和流程 维护信息安全政策 要求 12: 维护针对雇员和承包商信息安全的政策 PCI 安全标准委员会版权所有 第 1 页

3 附录 A: 针对共享主机提供商的额外 PCI DSS 要求...47 附录 B: 补偿性控制...49 附录 C: 补偿性控制工作表...50 附录 D: 遵从性证明书 商户...52 附录 E: 遵从性证明书 服务提供商...56 附录 F: PCI DSS 检查 - 界定和选择样品 PCI 安全标准委员会版权所有 第 2 页

4 引言和 PCI 数据安全标准概述 制定支付卡行业 (PCI) 数据安全标准 (DSS) 以促进并提高持卡人数据安全, 有利于全球广泛采用统一的数据安全标准 本文档 (PCI 数据安全标准要求和安全评估程序 ) 将 12 条 PCI DSS 要求作为基础, 并将这些要求与相应的测试程序融入到安全评估工具中 此标准的设计目的是供评估者使用, 以对必须验证 PCI DSS 合规性的商家和服务提供商进行现场评估 以下是 12 条 PCI DSS 要求的高级概述 接下来几页介绍了准备 实施和报告 PCI DSS 评估的背景, 详细的 PCI DSS 要求将从第 13 页开始 2008 PCI 安全标准委员会版权所有 第 3 页

5 PCI DSS 适用性信息 下表描述了持卡人和敏感认证数据的常用元素, 无论是允许还是禁止每个数据元素的存储, 或者是必须保护每个数据元素 此表并非十分详尽, 但足以说明应用到各数据元素的不同类型的要求 数据元素允许存储需要保护 PCI DSS 要求 3.4 主账户 (PAN) 是是是 持卡人数据 持卡人姓名 1 业务代码 1 失效日 1 完整磁条数据 3 是 是 1 否 是 是 1 否 是 是 1 否 否 不存在 不存在 敏感认证数据 2 CAV2/CVC2/CVV2/CID 否 不存在 不存在 PIN/PIN 数据块 否 不存在 不存在 1 这些数据元素如果连同 PAN 一起存储, 则必须对其进行保护 该保护措施应当符合 PCI DSS 对持卡人数据环境一般保护的相关要求 此外, 如果在业务过程中收集与消费者相关的个人数据, 其他立法 ( 例如, 与消费者个人数据保护 隐私 身份盗窃或数据安全有关的法律 ) 可能要求对此类数据进行特别保护, 或要求对公司操作进行适当披露 然而, 如果不对 PAN 进行存储 处理或传输, 则 PCI DSS 不适用 2 敏感认证数据不应在认证后存储 ( 即便是经过加密的 ) 3 来自磁条 芯片上的磁条图形或其他地方的全磁道数据 2008 PCI 安全标准委员会版权所有 第 4 页

6 PCI DSS 要求合规性的评估范围 PCI DSS 安全要求适用于所有系统组件 系统组件 定义为包含于持卡人数据环境或与之相关的任何网络组件 服务器或应用程序 持卡人数据环境是处理持卡人数据或敏感认证数据的部分网络 网络组件包括但不局限于防火墙 交换机 路由器 无线接入点 网络设备和其他安全设备 服务器类型包括但不局限于以下种类 :Web 应用程序 数据库 认证 邮件 代理 网络时间协议 (NTP) 和域名服务器 (DNS) 应用程序包括所有购买和自定义的应用程序, 包括内部和外部 (Internet) 应用程序 网络分段 将持卡人数据环境进行网络分段或与企业网络提醒隔离 ( 分段 ) 不是一项 PCI DSS 要求 然而, 将它作为一种推荐方法可以降低 : PCI DSS 评估的范围 PCI DSS 评估的成本 实施和维护 PCI DSS 控制的成本和难度 机构的风险 ( 通过将持卡人的数据统一到更少 更易控制的位置来降低风险 ) 没有充足的网络分段 ( 有时称为 扁平化网络 ), 整个网络都处于 PCI DSS 评估范围中 网络分段可以通过内部网络防火墙 带有严格访问控制列表的路由器或其他限制对网络特定分段进行访问的技术来实现 缩小持卡人数据环境范围的一个前提条件是透彻理解与持卡人数据存储 处理或传输相关的业务需求和过程 通过删除不必要的数据并集中必要的数据以将持卡人数据限制在尽可能少的位置, 这可能需要对长期业务实践进行重建 通过数据流图表记录持卡人数据流有助于全面了解所有的持卡人数据流, 并确保任何网络分段在隔离的持卡人数据环境中都有效 如果已设置了网络分段, 并且将用于缩小 PCI DSS 评估范围, 则评估者必须验证分段, 以足以缩小评估范围 在高层上, 充足的网络分段将存储 处理或传输持卡人数据的系统与那些不进行这些操作的系统隔离开来 然而, 网络分段具体实施的充足性非常多变, 并且依赖于诸如指定的网络配置 部署的技术以及其他可能实施的控制等因素 附录 F:PCI DSS 检查 界定和选择样品提供了 PCI DSS 评估期间界定影响的更多信息 无线 如果使用无线技术来存储 处理或传输持卡人数据 ( 例如, 销售点交易 快速结账 ), 或者如果无线局域网 (LAN) 连接到持卡人数据环境或其部分 ( 例如, 没有明确用防火墙隔开 ), 则无线环境的 PCI DSS 要求和测试流程适用且必须执行 ( 例如, 要求 和 4.1.1) 在实施无线技术以前, 公司应该仔细评估抵御风险的技术需求 仅对非敏感数据传输部署无线技术 2008 PCI 安全标准委员会版权所有 第 5 页

7 第三方 / 外包 对于要接受年度站点评估的服务提供商, 必须对存储 处理或传输持卡人数据的所有系统组件执行合规性验证 服务提供商或商家可以使用第三方提供商来代表它们存储 处理或传输持卡人数据, 或者管理诸如路由器 防火墙 数据库 物理安全和 / 或服务器等组件 如果是这样, 可能会对持卡人数据环境安全产生影响 对于那些将持卡人数据的存储 处理或传输外包给第三方服务提供商的机构, 合规性报告 (ROC) 必须记录每家服务提供商的职责, 明确对被检查机构适用哪些要求, 以及对服务提供商适用哪些要求 对于第三方服务提供商, 验证合规性有两个选项 :1) 它们可以自行接受 PCI DSS 评估并向其客户提供证明合规性的证据,2) 如果它们不进行自行 PCI DSS 评估, 则需要将其服务安排到每个客户的 PCI DSS 评估过程中接受检查 请参阅以下 合规性报告的说明和内容 章节中第 3 部分 对于管理服务提供商 (MSP) 检查 了解更多内容 此外, 商家和服务提供商必须管理并监管所有能够访问持卡人数据的相关第三方的 PCI DSS 合规性 详情请参阅本文档中的 要求 12.8 业务场所和系统组件抽样 评估者可以选择业务场所和系统组件的代表抽样, 以评估 PCI DSS 要求 这些抽样必须同时包括业务场所和系统组件, 必须是业务场所的所有类型和位置以及系统组件类型的代表选择, 并且必须足够大, 以使评估者能够确定控制措施已按预期实施 业务场所示例包括不同地方的公司办公室 店面 加盟商和业务场所 抽样应该包含每个业务场所的系统组件 例如, 对于每个业务场所, 包含适用于接受评估区域的各种操作系统 功能和应用程序 对于每个业务场所, 评估者可以选择运行 Apache WWW 的 Sun 服务器 运行 Oracle 的 Windows 服务器 运行旧有的卡处理应用程序的主机系统 运行 HP-UX 的数据传输服务器, 以及运行 MYSQL 的 Linux 服务器 如果所有应用程序都在单操作系统 ( 例如 Windows 或 Sun) 上运行, 则抽样仍应包含多个应用程序 ( 例如数据库服务器 Web 服务器 数据传输服务器等 ) ( 请参阅附录 F:PCI DSS 检查 - 界定和选择样品 ) 在选择业务场所和系统组件抽样时, 评估者应该考虑以下方面 : 如果存在标准, 即每个场所必须遵守的 PCI DSS 流程, 则抽样可以比没有标准流程的要小, 以确保每个场所都根据标准流程进行了配置 如果使用了一种以上的标准流程 ( 例如, 针对不同类型的系统组件或场所 ), 则抽样必须足够大, 以包含由每种流程保证安全的系统组件或场所 如果没有采用标准的 PCI DSS 流程, 并且每个场所负责自己的流程, 则抽样范围必须足够大, 以确保每个场所正确理解并实施了 PCI DSS 要求 另请参阅附录 F:PCI DSS 检查 - 界定和选择样品 2008 PCI 安全标准委员会版权所有 第 6 页

8 补偿性控制补偿性控制每年都会由评估者记录 检查和验证, 并与合规性报告一起提交, 其根据是附录 B: 补偿性控制和附录 C: 补偿性控制工作表 对于每项和每次补偿性控制, 必须完成补偿性控制工作表 ( 附录 C) 此外, 补偿性控制结果必须记录在相应 PCI DSS 要求部分的 ROC 中 参见上述附录 B 和 C 了解关于 补偿性控制 的详细信息 2008 PCI 安全标准委员会版权所有 第 7 页

9 合规性报告的说明与内容 此文档必须用作创建合规性报告的模板 被评估的机构应该遵守每种支付品牌相应的报告要求, 以确保每个支付品牌知悉机构的合规性状态 联系每个支付品牌以确定报告要求和说明 报告内容和格式 在完成合规性报告时请遵守这些报告内容和格式的说明 1. 实施概要 包括以下内容 : 描述机构的支付卡业务, 包括 : - 它们在支付卡中的业务角色, 也就是它们如何以及为何存储 处理和 / 或传输持卡人数据 注 : 这不应该是从机构网站上复制和粘贴的内容, 而应该是有针对性的描述, 使评估者能够理解支付和机构的角色 - 它们如何处理支付 ( 直接 间接等 ) - 它们提供什么类型的支付渠道, 例如离卡 ( 如邮件订购 - 电话订购 (MOTO) 电子商务 ) 或持卡 - 任何连接进行支付传输或处理 ( 包括处理商关系 ) 的机构 机构网络拓朴的高级网络图表 ( 从机构获得或由评估者创建 ), 包括 : - 进出网络的连接 - 持卡人数据环境内的关键组件, 包括 POS 设备 系统 数据库和 Web 服务器 ( 视情况而定 ) - 其他需要的支付组件 ( 视情况而定 ) 2. 工作范围和采用方法的描述 根据本文档中的评估范围部分描述范围, 包括以下方面 : 评估集中的环境 ( 例如, 客户端 Internet 访问点 内部公司网络 处理连接等 ) 如果采用了网络分段, 并且用于缩小 PCI DSS 检查范围, 则只需简单说明分段以及评估者如何验证分段的有效性 记录并调整机构 ( 店面 场所等 ) 和系统组件使用的抽样, 包括 : - 总人数 - 抽样数量 - 选择抽样的基本原理 2008 PCI 安全标准委员会版权所有 第 8 页

10 - 为什么抽样范围足以让评估者可以确定检查的控制措施代表了整个机构内使用的控制措施 - 说明排除在检查范围以外的存储 处理或传输持卡人数据的任何位置或环境, 以及这些位置 / 环境为什么排除在外 列举所有要求遵守 PCI DSS 的全资机构, 以及它们是否被单独检查或作为此评估的部分接受检查 列举所有要求遵守 PCI DSS 的国际机构, 以及它们是否被单独检查或作为此评估的部分接受检查 列举所有连接或可能影响持卡人数据环境的无线 LAN 和 / 或无线支付应用程序 ( 例如 POS 终端 ), 并且说明这些无线环境的安全性 实施评估使用的 PCI DSS 要求和安全评估程序文档的版本 评估的时间框架 3. 检查环境的详细信息 本章节包含以下详细信息 : 每条通信链接的图表, 包括 LAN WAN 或 Internet 持卡人数据环境的说明, 例如 : - 持卡人数据的文档传输和处理, 包括认证 留存 结算 收费和其他适用的流程 - 存储持卡人数据的文档和表格列表, 由评估者创建 ( 或从客户处获取 ) 并保留在工作文书中的清单提供 此清单应该包括每个持卡人的数据存储 ( 文件 表格等 ): 存储持卡人数据的所有元素的清单 如何保护数据 如何记录对数据存储的访问 持卡人数据环境中使用的硬件和主要软件清单, 并附带其各自的功能 / 用法说明 服务提供商和其他与公司共享持卡人数据的机构的清单 ( 注 : 这些机构必须遵守 PCI DSS 要求 12.8) 在使用的第三方支付应用程序产品和版本号清单, 包括每个支付应用程序是否已按照 PA-DSS 验证过 即使支付应用程序已经 PA- DSS 验证过, 评估者仍需要验证应用程序已按 PCI DSS 合规方式和环境实施, 并且遵守支付应用程序供应商的 PA-DSS 实施指南 注 : 这不是使用 PA-DSS 验证应用程序的一项 PCI DSS 要求 请分别咨询每个支付品牌以了解它们的 PA-DSS 合规要求 访问的人员及其职务清单 审查的文档清单 对于管理服务提供商 (MSP) 检查, 评估者必须明确指出本文档中的哪些要求适用于 MSP ( 并且包含在审查中 ) 和哪些不包含在审查中, 以及哪些是 MSP 客户的责任, 应包含在它们的审查中 包含的信息涉及哪些 MSP IP 地址作为 MSP 季度漏洞扫描的部分进行扫描, 以及哪些 IP 地址是 MSP 客户的责任, 应包含在它们自己的季度扫描中 2008 PCI 安全标准委员会版权所有 第 9 页

11 4. 联系信息与报告日期 包括 : 商家或服务提供商和评估者的联系信息 报告日期 5. 季度扫描结果 在实施摘要和要求 11.2 备注中总结最近 4 个季度的扫描结果 注 : 如果评估者确定以下内容, 则不要求必须完成 4 次通过季度扫描才能获得初始的 PCI DSS 合规性 :1) 最近一次的扫描结果成功通过 ;2) 机构已记录了要求季度扫描的政策和程序 ; 以及 3) 初始扫描中指出的漏洞在重新扫描时显示已更正 第一次 PCI DSS 审查完成之后的年度中, 必须通过了四次季度扫描 扫描必须根据 PCI DSS 安全扫描程序覆盖机构中所有的外部可访问 ( 面向 Internet)IP 地址 6. 结果与观察结论 未清项的再验证 在实施摘要中总结任何可能与标准合规性模板格式不符的结果 所有评估者必须使用详细的 PCI DSS 要求和安全评估程序模板来提供关于每项要求和子要求的详细报告说明和结果 评估者必须审查并记录考虑到的任何补偿性控制, 以确认采用了控制 请参阅以上补偿性控制章节和附录 B 和 C, 以获得关于 补偿性控制 的更多信息 要求 采用控制 报告来验证合规性 如果此报告含有 未清项 或者在将来日期完成的项, 则被认为是非合规报告 商家 / 服务提供商必须在认证完成以前解决这些项 在商家 / 服务提供商解决这些项以后, 评估者将重新评估以验证纠正措施和所有要求均已达到 重新验证以后, 评估商将发布新的合规性报告, 确认持卡人数据环境完全合规, 并且按照说明进行提交 ( 请参阅下文 ) PCI DSS 合规 - 完成步骤 1. 根据以上标题为 合规性报告的说明与内容 章节完成合规性报告 (ROC) 2. 确保通过漏洞扫描已由 PCI SSC 认证的扫描供应商 (ROC) 完成, 并从 ASV 获得通过扫描证明 3. 视情况全部完成服务提供商或商家的合规性证明 请参阅附录 D 和 E 以获得合规性证明 4. 向购买者 ( 对于商家 ) 支付品牌或其他请求者 ( 对于服务提供商 ) 提交 ROC 通过扫描的证明 合规性证明和其他要求的文档 2008 PCI 安全标准委员会版权所有 第 10 页

12 详细的 PCI DSS 要求和安全评估程序 对于 PCI DSS 要求和安全性评估程序, 定义表格列标题的内容如下 : PCI DSS 要求 - 此列定义了数据安全性标准并列举了要求, 以实现 PCI DSS 合规性 ; 合规性必须按照这些要求进行验证 测试程序 - 此列表明评估者遵从的程序, 以验证 到位 的 PCI DSS 要求 到位 - 评估者必须使用此列提供已到位控制措施的简短说明, 包括作为补偿性控制而落实到位的控制措施 ( 注 : 对于仍未到位的项 未清项或在将来日期完成的项, 一定不能使用此列 ) 未到位 - 评估者必须使用此列来提供那些未到位控制措施的简短说明 请注意, 非合规报告不应该提交给支付品牌或购买者, 除非特别要求 请参阅附录 D 和附录 E: 合规性证明提供了关于非合规报告的进一步说明 目标日期 / 备注 - 对于那些 未到位 的控制, 评估者可以包含商家或服务提供商预计控制 到位 的目标日期 此处也可以包含其他备注或说明 2008 PCI 安全标准委员会版权所有 第 11 页

13 构建并维护安全的网络 要求 1: 安装并维护防火墙配置, 以保护持卡人数据 防火墙是控制公司网络 ( 内部 ) 和未信任网络 ( 外部 ) 之间的计算机流量以及进出公司内部受信任网络更敏感区域的流量的设备 持卡人数据环境是公司受信任网络内部更敏感区域的一个示例 防火墙检测所有网络流量并阻止那些不满足特定安全标准的传输 所有系统必须受到保护, 防止从不受信任网络进行未授权访问, 无论是通过 Internet 以电子商务形式 员工通过桌面浏览器进行的 Internet 访问 员工电子邮件访问 诸如企业对企业连接的专门连接 通过无线网络或是其他途径进入系统 通常看似无关紧要进出不受信任网络的途径都可能成为关键系统的未保护入口 防火墙是所有计算机网络的关键保护机制 PCI DSS 要求测试程序到位不到位目标日期 / 备注 1.1 建立包含以下各项的防火墙和路由器配置标准 : 批准和测试所有网络连接以及更改防火墙和路由器配置的正式流程 当前网络图表, 带有至持卡人数据的所有连接, 包括所有无线网络 1.1 获取并检查以下防火墙和路由器配置标准及其他文档, 以验证标准是完整的 完成以下各项 : 确认具有批准和测试所有网络连接以及更改防火墙和路由器配置的正式流程 a 确认具有当前网络图表 ( 例如, 一个表明网络中持卡人数据流的图表 ), 并且它记录了至持卡人数据的所有连接, 包括所有无线网络 b 确认图表是最新的 每个 Internet 连接处和隔离区 (DMZ) 与内部网络区域之间的防火墙要求 网络组件逻辑管理的组 角色和责任的说明 确认防火墙配置标准包括每个 Internet 连接处和 DMZ 与内部网络区域之间的防火墙要求 确认当前网络图表与防火墙标准一致 确认防火墙和路由器配置标准包括关于网络组件逻辑管理的组 角色和责任的说明 2008 PCI 安全标准委员会版权所有 第 12 页

14 PCI DSS 要求测试程序到位不到位目标日期 / 备注 使用允许的所有服务 协议和端口的文档和业务原因, 包括为那些认为不安全的协议实施的安全功能的文档 a 确认防火墙和路由器配置标准包括一个业务需要的服务 协议和端口 ( 例如, 超文本传输协议 (HTTP) 和安全套接层 (SSL) 安全接壳 (SSH) 和虚拟专用网络 (VPN) 协议 ) 的文档化列表 b 识别允许的不安全服务 协议和端口 ; 并且确认它们是必需的, 而且每项服务的安全功能已按检测防火墙和路由器配置标准进行了记录和实施 FTP 就是一个不安全服务 协议或端口的示例, 它通过纯文本的用户认证 要求至少每 6 个月检查一次防火墙和路由器的规则设置 a 确认防火墙和路由器配置标准要求至少每 6 个月检查一次防火墙和路由器规则设置 b 获取并检查确认至少每 6 个月检查一次规则设置的文档 1.2 设置一个限制持卡人数据环境中不受信任网络和任何系统组件之间的防火墙配置 1.2 检查防火墙和路由器配置, 以确认持卡人数据环境中不受信任网络和系统组件之间的连接受到限制, 如下所示 : 注 : 不受信任网络 是指属于受审查机构的网络以外的任何网络, 和 / 或机构无法控制或管理的网络 限制持卡人数据环境必需的进出流量 a 确认进出流量受到持卡人数据环境需要的限制, 并且对这些限制进行了记录 b 确认其他所有进出流量都是明确禁止的, 例如通过使用明示的 禁止所有 或允许声明后的暗示禁止 保护并同步路由器配置文件 确认路由器配置文件进行了保护和同步, 例如运行配置文件 ( 用于正常的路由器运行 ) 和启动配置文件 ( 当机器重新启动时使用 ) 有相同的安全配置 在任何无线网络和持卡人数据环境之间安装外围防火墙, 并且将这些防火墙配置为禁止或控制 ( 如果业务目的需要这样的流量 ) 从无线环境流入持卡人数据环境的任何流量 确认在任何无线网络和存储持卡人数据的系统之间安装了外围防火墙, 并且这些防火墙禁止或控制 ( 如果业务目的需要这样的流量 ) 从无线环境流入持卡人数据环境的任何流量 2008 PCI 安全标准委员会版权所有 第 13 页

15 PCI DSS 要求测试程序到位不到位目标日期 / 备注 1.3 禁止在持卡人数据环境中的 Internet 和系统组件之间的直接公共访问 实施 DMZ 以只限制那些持卡人数据环境需要的协议的进出流量 限制进入 DMZ 内部 IP 地址的 Internet 流量 不允许 Internet 和持卡人数据环境之间进出流量的任何直接路由 不允许从 Internet 至 DMZ 的内部地址通过 限制从持卡人数据环境至 Internet ( 例如传出流量 ) 的传出流量只能访问 DMZ 内部的 IP 地址 实施状态检测, 也即动态包过滤 ( 也就是只有 建立 的连接才允许进入网络 ) 在内部网络区域 ( 从 DMZ 隔离开来的 ) 中使用数据库 实施 IP 伪装以防止内部地址被转译和发布到 Internet 上, 使用 RFC 1918 地址空间 使用网络地址转译 (NAT) 技术, 例如端口地址转译 (PAT) 1.4 通过至 Internet 的直接连接在任何移动和 / 或员工自有计算机上 ( 例如员工使用的笔记本电脑 ) 安装个人防火墙软件, 用于访问机构网络 1.3 检查防火墙和路由器配置 ( 如下详述 ) 以确定 Internet 和系统组件之间没有直接的访问, 包括 Internet 上的阻止路由器 DMZ 路由器和防火墙 DMZ 持卡人分段 外围路由器 以及内部持卡人网络分段 确认实施了 DMZ 来只限制那些持卡人数据环境需要的协议的进出流量 确认进入 DMZ 内部 IP 地址的 Internet 流量受到限制 确认禁止了 Internet 和持卡人数据环境之间进出流量的任何直接路由 确认从 Internet 至 DMZ 的内部地址不能通过 确认从持卡人数据环境至 Internet 的传出流量只能访问 DMZ 内部的 IP 地址 确认防火墙执行状态检测 ( 动态包过滤 ) [ 应该只允许已建立的连接进入, 并且只有它们与先前的建立会话相关时 ( 在所有设定了 syn reset 或 syn ack 位的 TCP 端口上运行端口扫描程序, 该响应意味着允许通过包, 即使它们不是先前建立会话的部分 ) ] 确认在内部网络区域 ( 从 DMZ 隔离开来的 ) 中使用了数据库 对于防火墙和路由器组件抽样, 确认使用了 NAT 或其他使用 RFC 1918 地址空间的技术来限制 IP 地址从内部网络至 Internet (IP 伪装 ) 的广播 1.4.a 确认通过至 Internet 的直接连接在移动和 / 或员工自有并用于访问机构网络的计算机上 ( 例如员工使用的笔记本电脑 ) 安装并激活了个人防火墙软件 1.4.b 确认机构将个人防火墙软件配置为特定的标准, 并且移动计算机用户不能更改 2008 PCI 安全标准委员会版权所有 第 14 页

16 要求 2: 系统密码和其他安全参数不使用供应商提供的默认设置 恶意个人 ( 公司外部和内部 ) 通常使用供应商默认密码和其他供应商默认设置来危害系统 这些密码和设置为黑客团队所熟知, 并且容易通过公开信息判断得出 PCI DSS 要求测试程序到位不到位目标日期 / 备注 2.1 在网络上安装系统以前, 务必更改供应商提供的默认项, 例如包括密码 简单网络管理协议 (SNMP) 机构字串, 并删除不并要的账户 对于连接到持卡人数据环境或传输持卡人数据的无线环境, 更改无线供应商默认项, 包括但不局限于默认无线加密密钥 密码和 SNMP 机构字串 确保无线设备安全设置已启用, 采用了严格的加密技术进行认证和传输 2.2 制定所有系统组件的配置标准 确保这些标准解决了所有已知的安全漏洞, 并且符合行业接受的系统安全标准 2.1 选择一个系统组件 关键服务器和无线访问点抽样, 并试图使用供应商提供的账户和密码登录到 ( 在系统管理员的帮助下 ) 设备, 以确认默认账户和密码已更改 ( 使用供应商手册和 Internet 上的资源来查找供应商提供的账户 / 密码 ) 确认以下关于无线环境的供应商默认设置, 并确保所有无线网络实施了严格的加密机制 ( 例如 AES): 加密密钥已在安装时更改了默认值, 并且在任何知道密钥的人离开公司或改变岗位时能够随时更改 无线设备上的默认 SNMP 机构字串已更改 访问点上的默认密码 / 口令已更改 已升级了无线设备上的固件, 以支持无线网络上的严格认证和传输加密 ( 例如 WPA/WPA2) 其他安全相关性的无线供应商默认值 ( 视情况而定 ) 2.2.a 检查机构所有类型的系统组件的系统配置标准, 并确认系统配置标准与行业接受的安全标准一致, 例如系统管理和网络安全审计委员会 (SANS) 国家标准和技术研究机构 (NIST) 和 Internet 安全中心 (CIS) 2.2.b 确认系统配置标准包含以下各项 ( 在 ) 2.2.c 确认在配置新系统时应用了系统配置标准 每台服务器只执行一项主要功能 对于系统组件抽样, 确认每台服务器只执行了一项主要功能 例如,Web 服务器 数据库服务器和 DNS 应该在独立的服务器上实施 禁用所有不必要和不安全的服务和协议 ( 不直接需要用来执行设备特定功能的服务和协议 ) 对于系统组件抽样, 检测启用的系统服务 守护进程和协议 确认不必要或不安全的服务或协议没有启用, 并且已根据服务的相应使用进行了调整和记录 例如, 没有使用 FTP, 或者通过 SSH 或其他技术进行加密 2008 PCI 安全标准委员会版权所有 第 15 页

17 PCI DSS 要求测试程序到位不到位目标日期 / 备注 配置系统安全参数以防止滥用 a 访问系统管理员和 / 或安全经理, 以确认他们知道系统组件的常用安全参数设置 b 确认常用安全参数设置包含在系统配置标准中 c 对于系统组件抽样, 确认常用安全参数进行了正 确的设置 删除所有不必要的功能, 例如脚本 驱动程序 属性 子系统 文件系统和不必要的 Web 服务器 2.3 对所有非控制台管理访问进行加密 对于基于 Web 的管理和其他非控制台管理访问使用诸如 SSH VPN 或 SSL/TLS 等技术 2.4 共享托管提供商必须保护每个机构托管环境和持卡人数据 这些提供商必须满足附录 A: 针对共享托管提供商的额外 PCI DSS 要求中详细规定的具体要求 对于系统组件抽样, 确认所有不必要的功能 ( 例如脚本 驱动程序 属性 子系统 文件系统等 ) 都已删除 确认启用的功能已记录, 并且支持安全配置, 而且在抽样的机器上只显示记录的功能 2.3 对于系统组件抽样, 确认非控制台管理访问已通过下列方式加密 : 观察管理员登录到每个系统, 以确认在要求提供管理员密码以前实施了严格的加密方法 ; 检查系统上的服务和参数文件, 以确定 Telnet 和其他远程进入命令不能内部使用 ; 以及 确认管理员对基于 Web 管理接口的访问是经过强效加密法加密的 2.4 执行测试程序 A.1.1 至 A.1.4( 详情请参阅附录 A: 针对共享托管提供商的额外 PCI DSS 要求 ) 以进行共享托管提供商的 PCI DSS 评估, 确认共享托管提供商保护了它们 ( 商家和服务提供商 ) 的主机环境和数据 2008 PCI 安全标准委员会版权所有 第 16 页

18 保护持卡人数据 要求 3: 保护存储的持卡人数据 保护方法 ( 例如加密 截词 掩模和哈希等 ) 是持卡人数据保护的关键组件 如果入侵者规避了其他网络安全控制并访问了加密数据, 如果没有正确的加密密钥, 则仍不能读取并使用这些数据 也可考虑使用其他保护存储数据的有效方法来减小潜在风险 例如, 最小化风险的方法包括除非绝对必要否则不存储持卡人数据, 不需要完全的 PAN 时截断持卡人数据, 以及不在未加密的邮件中发送 PAN 请参阅 PCI DSS 术语 缩略语关于 强效加密法 和其他 PCI DSS 词汇的定义 PCI DSS 要求测试程序到位不到位目标日期 / 备注 3.1 使持卡人数据存储最小化 制定数据保留和处理政策 根据业务 法律和 / 或法规要求限制存储的大小和保留时间, 在数据保留政策中进行记录 3.2 不在授权后存储敏感的验证数据 ( 即使已经加密 ) 敏感验证数据包括下文要求 至 中列举的数据 : 3.1 获取并检查公司关于数据保留和处理的政策和流程, 并且执行以下审查 确认政策和流程包含数据保留的法律 法规和业务要求, 包括持卡人数据保留的具体要求 ( 例如, 持卡人数据因 Y 业务的原因需要保留 X 时长 ) 确认政策和流程包含不再因为法律 法规或业务原因需要进行数据处理的规定, 包括持卡人数据处理 确认政策和流程包括所有持卡人数据存储的各个方面 确认政策和流程包含程序化 ( 自动 ) 流程以至少每个季度清除一次超过业务保留要求的持卡人数据, 或者视检查要求, 至少每季度进行一次, 以确认存储的持卡人数据没有超过业务保留要求 3.2 如果接收和删除了敏感数据, 获取并检查删除数据的流程, 以确认数据不能恢复 对于以下敏感认证数据的各项执行以下步骤 : 2008 PCI 安全标准委员会版权所有 第 17 页

19 PCI DSS 要求测试程序到位不到位目标日期 / 备注 不要存储磁条任意磁道上的完整内容 ( 位于卡的背面 芯片上或其他位置 ) 该数据也可称为全磁道 磁道 1 磁道 2 和磁条数据 注 : 在正常的业务过程中, 以下磁条数据元素可能需要保留 : 持卡人姓名, 主账户 (PAN), 失效日, 以及 业务代码为将风险降至最低, 只存储业务所需的数据元素 注 : 请参阅 PCI DSS 术语 缩略语获得更多信息 不要存储用于验证离卡交易的卡验证代码或值 ( 印在支付卡正面或背面的三或四位数字 ) 注 : 请参阅 PCI DSS 术语 缩略语获得更多信息 对系统组件抽样, 检查以下各项并确认卡背面磁条上的任何磁道上的全部内容都没有在任何环境下存储 : 输入的交易数据 所有日志 ( 例如交易 历史 除错 错误 ) 存档文件 跟踪文件 几种数据库模式 数据库内容 对系统组件抽样, 确认印在卡正面或签名栏上的三位或四位数的卡验证代码或值 (CVV2 CVC2 CID CAV2 数据 ) 没有在任何情况下存储 : 输入的交易数据 所有日志 ( 例如交易 历史 除错 错误 ) 存档文件 跟踪文件 几种数据库模式 数据库内容 2008 PCI 安全标准委员会版权所有 第 18 页

20 PCI DSS 要求测试程序到位不到位目标日期 / 备注 不要存储个人识别码 (PIN) 或经加密的 PIN 数据块 3.3 显示 PAN 时对其进行掩盖 ( 最多可显示的数位包括前六位与后四位 ) 注 : 此要求不适用于那些因合法业务需要查看完整的 PAN 的员工和其他方 此要求不取代显示持卡人数据采用的更严格的要求, 例如销售点 (POS) 收据 3.4 通过以下方法尽量使 PAN 在存储的地方不可读 ( 包括在便携式数字媒体 备份媒体 日志中 ): 基于强效加密法的单向哈希 截词 索引记号与索引簿 ( 索引簿必须安全地存储 ) 带有相关密钥管理流程和过程的强效加密法在账户信息中, 最应实现不可读的就是 PAN 注 : 如果因为某些原因, 公司不能使 PAN 不可读, 请参阅附录 B: 补偿性控制 强效加密法 在 PCI DSS 术语 缩略语中进行了定义 对系统组件抽样, 检查以下各项并确认 PIN 和加密 PIN 数据块没有在任何情况下存储 : 输入的交易数据 所有日志 ( 例如交易 历史 除错 错误 ) 存档文件 跟踪文件 几种数据库模式 数据库内容 3.3 获取并检查书面政策, 并检查 PAN 显示 ( 例如屏幕 纸质收据 ), 以确认在显示持卡人数据时主账户 (PAN) 被掩盖, 除非因合法业务需要查看完整的 PAN 3.4.a 获取并检查用于保护 PAN 系统的文档, 包括供应商 系统 / 流程类型以及加密算法 ( 视情况而定 ) 确认通过了以下任一方法使 PAN 不可读 : 基于强效加密法的单向哈希 截词 索引记号与索引簿, 索引簿必须安全地存储 带有相关密钥管理流程和过程的强效加密法 3.4.b 检查数据存放抽样中的多个表格或文件, 以确认 PAN 被设为不可读 ( 也就是不以纯文本存储 ) 3.4.c 检查可移动媒体的抽样 ( 例如备份磁带 ), 以确认 PAN 被设为不可读 3.4.d 检查审核日志抽样, 以确认 PAN 已被处理或从日志中清除 2008 PCI 安全标准委员会版权所有 第 19 页

21 PCI DSS 要求测试程序到位不到位目标日期 / 备注 如使用了磁盘加密 ( 而不是文件级或列级数据库加密 ), 则对逻辑访问的管理必须独立于本地操作系统的访问控制机制 ( 例如, 不使用本地用户账户数据库 ) 解密密匙决不能与用户账户绑定 a 如果使用了磁盘加密, 确认通过独立于本地操作系统机制的机制 ( 例如, 不使用本地用户账户数据库 ) 执行了对加密文件系统的逻辑访问 b 确认加密密钥被安全存储 ( 例如, 存储在通过严格访问控制进行充分保护的可移动媒体上 ) c 确认可移动媒体上的持卡人数据在进行任存储时都进行了加密 注 : 磁盘加密通常不能加密可移动媒体, 因此存储在此媒体上的数据将需要单独加密 3.5 保护加密持卡人数据以防泄露和盗用的加密密钥 : 将对加密密钥的管理人数尽量减到最少 将加密密钥以尽量少的形式安全存储在尽量少的地方 3.6 全面记录并实施用于加密持卡人数据的加密密钥采用的所有密钥管理流程和过程, 包括以下各项 : 3.5 通过执行以下操作确认保护用于加密持卡人数据以防泄露和盗用的密钥的程序 : 检查用户访问列表, 以确认将对密钥的访问限制为了少数几个保管人 检查系统配置文件, 以确认密钥以加密的形式存储, 并且密钥加密密钥是与数据加密密钥分开存储的 3.6.a 确认存在用于加密持卡人数据的密钥的密钥管理流程 注 : 可以从各种途径 ( 包括 NIST) 获得许多密钥管理行业标准, 可以访问 b 仅对于服务提供商 : 如果服务提供商与其客户共享持卡人数据传输密钥, 确认服务提供商向客户提供了记录, 其中包含了关于如何安全存储并更改客户密钥的指南 ( 用于在客户和服务提供商之间传输数据 ) 3.6.c 检查密钥管理程序并执行以下操作 : 强效加密法密钥的生成 确认执行了密钥管理程序以要求生成强效密钥 安全的加密法密钥分发 确认执行了密钥管理程序以要求安全的密钥分发 安全的加密法密钥存储 确认执行了密钥管理程序以要求安全的密钥存储 2008 PCI 安全标准委员会版权所有 第 20 页

22 PCI DSS 要求测试程序到位不到位目标日期 / 备注 定期更改加密密钥 认为有必要并且由相关应用程序推荐 ( 例如重新加密 ); 首选自动 至少每年一次 弃用或更改旧的或疑似泄露的加密密钥 确认执行了密钥管理程序以要求至少每年进行一次定期密钥更改 a 确认执行了密钥管理程序以要求弃用旧的密钥 ( 例如 : 视情况存档 毁灭和废止 ) b 确认执行了密钥管理程序以要求更换已知或疑似泄露的密钥 加密密钥双重控制的分开保管和建立 确认执行了密钥管理程序, 以要求将密钥的保管和双重控制分开 ( 例如, 要求两至三个人, 每个人只知道其密钥的部分, 整合在一起才能构成完整的密钥 ) 防止加密密钥的未授权更改 确认执行了密钥管理程序以防止未授权更改 要求密钥保管人签署声明他们知道并接受密钥保管责任的文件 确认执行了密钥管理程序以要求密钥保管人签署文件, 表明他们理解并接受其密钥保管责任 2008 PCI 安全标准委员会版权所有 第 21 页

23 要求 4: 在开放型的公共网络中传输持卡人数据时会加密 在易于被恶意个体访问的网络中传输敏感信息时必须加密 配置不当的无线网络及旧有加密和认证协议的漏洞都可能继续成为恶意个体的攻击对象, 他们利用这些漏洞获取对持卡人数据环境的特权访问 PCI DSS 要求测试程序到位不到位目标日期 / 备注 4.1 使用强效加密法和安全协议 ( 例如 SSL/TLS 或 IPSEC) 以保护在开放型公共网络中传输敏感持卡人数据的安全 PCI DSS 范围内的开放型公共网络示例如 : Internet, 无线技术, 移动通信的全球系统 (GSM) 和 通用无线分组业务 (GPRS) 确保传输持卡人数据或连接到持卡人数据环境的无线网络使用了行业最优方法 ( 例如 IEEE i) 对认证和传输实施了强效加密 对于新的无线实施, 自 2009 年 3 月 31 日起禁止实施 WEP 对于当前的无线实施, 自 2010 年 6 月 30 日起禁止使用 WEP 4.2 切勿使用终端用户通讯技术 ( 例如, 电子邮件 即时通讯工具 聊天工具等 ) 发送未加密的 PAN 4.1.a 确认在开放型公共网络上传输或接收持卡人数据的地方使用了加密 ( 例如,SSL/TLS 或 IPSEC) 确认在数据传输过程中使用了强效加密 对于 SSL 实施 : - 确认服务器支持最新补丁版本 - 确认 HTTPS 作为浏览器统一记录定位符 (URL) 的部分出现 - 确认当 HTTPS 不在 URL 中出现时不要求持卡人数据 选择一个交易被接受并观察其进行的抽样, 确认持卡人数据在交易过程中进行了加密 确认只有受信任的 SSL/TLS 密钥 / 证书被接受 确认使用的加密方法执行了正确的加密强度 ( 核查供应商建议 / 最优方法 ) 对于传输持卡人数据或连接到持卡人数据环境的无线网络, 确认使用了行业最优方法 ( 例如 IEEE i) 对认证和传输实施了强效加密 4.2.a 确认在通过终端用户通讯技术发送持卡人数据时使用了强效加密法 4.2.b 确认存在声明不通过终端用户通讯技术发送未加密 PAN 的政策 2008 PCI 安全标准委员会版权所有 第 22 页

24 维护漏洞管理程序 要求 5: 使用并定期更新杀毒软件或程序 恶意软件 ( 通常指 malware, 包括病毒 蠕虫和木马 ) 在许多业务认证的活动中进入网络, 包括员工电子邮件和 Internet 使用 移动电脑和存储设备, 从而导致系统漏洞被利用 必须在所有经常受恶意软件影响的系统上使用杀毒软件, 防止受到当前和变种的恶意软件威胁 PCI DSS 要求测试程序到位不到位目标日期 / 备注 5.1 在所有经常受恶意软件影响的系统上部署杀毒软件 ( 特别是个人电脑和服务器上 ) 确保所有杀毒程序都能够监测 删除并防止所有已知类型的恶意软件的攻击 5.2 确保所有杀毒机制都是最新并且在运行, 而且能够生成审核日志 5.1 对包含所有经常受恶意软件影响的操作系统类型的系统组件进行抽样, 确认根据杀毒技术部署了杀毒软件 对于系统组件抽样, 确认所有杀毒程序监测 删除并防止所有已知类型的恶意软件的攻击 ( 例如, 病毒 木马 蠕虫 间谍软件 广告软件和 rootkit 等 ) 5.2 通过执行以下各项确认所有杀毒软件都是最新且都在运行, 并且能够生成日志 : 5.2.a 获取并检查政策, 并确认要求更新杀毒软件和定义 5.2.b 确认启用了软件主安装, 以进行自动更新和定期扫描 5.2.c 对包含所有经常受恶意软件影响的操作系统类型的系统组件进行抽样, 确认启用了自动更新和定期扫描 5.2d 对于系统组件抽样, 确认启用了杀毒软件日志生成功能, 并且这些日志根据 PCI DSS 要求 10.7 进行了保留 2008 PCI 安全标准委员会版权所有 第 23 页

25 要求 6: 开发 维护安全系统和应用程序 恶意个体使用安全漏洞获取对系统的特权访问 许多漏洞都能够通过供应商提供的安全补丁进行修复, 必须由管理这些系统的机构安装 所有关键系统都必须具备最新发布的合适的软件补丁, 以保护持卡人数据被恶意个体和恶意软件利用和破坏 注 : 合适的软件补丁就是那些进行了充分评估和测试以确定这些补丁不与现有安全配置冲突的补丁 对于自行开发的应用程序, 许多漏洞都可以通过使用标准系统开发程序和安全的编码技术避免 PCI DSS 要求测试程序到位不到位目标日期 / 备注 6.1 确保所有系统组件和软件都安装了最新的供应商提供的安全补丁 在发布的一个月以内安装关键的安全补丁 注 : 机构可以考虑应用基于风险的方法来排定其补丁安装的优先级 例如, 将关键的基础结构 ( 例如, 面向公众的设备 系统和数据库 ) 优先于不那么重要的内部设备, 以确保高优先级系统和设备在一个月内解决完, 再在三个月内解决不那么重要的设备 6.2 建立一个流程来识别新发现的安全漏洞 ( 例如, 订阅 Internet 免费的警告服务 ) 根据 PCI DSS 要求 2.2 更新配置标准, 以解决新的漏洞问题 6.3 根据 PCI DSS( 例如, 安全的认证和登录 ) 并基于行业最优方法开发软件应用程序, 并将信息安全融入到整个软件开发生命周期中 这些程序必须包括以下各项 : 6.1.a 对于系统组件和相关软件抽样, 将安装在每个系统上的安全补丁列表与最新的供应商安全补丁列表相比较, 以确认安装了最新的供应商补丁 6.1.b 检查与安全补丁安装相关的政策, 以确认它们要求了在一个月内安装所有关键的新安全补丁 6.2.a 洞 访问负责人, 以确认执行了该流程来识别新的安全漏 6.2.b 确认那些识别新安全漏洞的流程包括使用外部资源发现安全漏洞信息, 并在发现新安全漏洞问题时更新要求 2.2 中的系统配置检查标准 6.3.a 获取并检查书面软件开发流程, 以确认这些流程基于行业标准, 安全性融入了整个生命周期, 并且根据 PCI DSS 开发了软件应用程序 6.3.b 通过对软件开发书面流程的检查 对软件开发人员的访问以及对相关数据的检查 ( 网络配置文件 生产与测试数据等 ), 确认 : 2008 PCI 安全标准委员会版权所有 第 24 页

26 PCI DSS 要求测试程序到位不到位目标日期 / 备注 部署前, 对所有的安全补丁 系统与软件配置的更改进行测试, 包括但不仅限于对以下内容的测试 : 验证所有输入 ( 防止跨站脚本 注入攻击 恶意文件执行等 ) 所有更改 ( 包括补丁 ) 在部署投入生产前都经过测试 验证所有输入 ( 防止跨站脚本 注入攻击 恶意文件执行等 ) 验证正确的错误处理 验证正确的错误处理 验证安全加密存储 验证安全加密存储 验证安全通信 验证安全通信 验证正确的基于角色的访问控制 (RBAC) 验证正确的基于角色的访问控制 (RBAC) 分开开发 / 测试环境与生产环境 开发 / 测试环境独立于生产环境, 并设置访问控制以确保两者的分离 开发 / 测试环境与生产环境中的职责分离 在测试或开发过程中不使用生产数据 ( 真实的 PAN) 在生产系统启动前清除测试数据与账户 在激活应用程序或发布给用户以前, 清除所有自定义应用程序账户 用户 ID 和密码 对分配到开发 / 测试环境与生产环境中的人员进行职责分离 在测试和开发过程中不使用生产数据 ( 真实的 PAN), 或在使用前进行处理 在生产系统启动前, 已经清除测试数据与账户 在系统投入生产或发布给用户以前, 自定义应用程序账户 用户 ID 和 / 或密码已清除 2008 PCI 安全标准委员会版权所有 第 25 页

27 PCI DSS 要求测试程序到位不到位目标日期 / 备注 在发布生产以前检查自定义代码, 以识别所有潜在的编码漏洞注 : 代码检查的要求适用于所有自定义代码 ( 包括内部和面向公众的 ),PCI DSS 要求 6.3 将它作为系统开发生命周期的部分进行要求 代码检查可以由有经验的内部人员或第三方进行 Web 应用程序也受到更多控制 ( 如果它们是面向公众的 ), 以解决执行后不断产生的威胁和漏洞, 如 PCI DSS 要求 6.6 所定义的 a 获取并检查政策, 以确认内部应用程序的所有自定义应用程序代码变化都必须经过检查 ( 使用人工或自动程序 ), 如下所示 : 所有代码更改都必须由原始代码作者以外且熟知代码检查技术和安全编码实践的人员进行 在发布以前必须执行相应的更正 在发布以前由管理层检查并批准代码检查结果 b 获取并检查政策, 以确认 Web 应用程序的所有自定义应用程序代码变化都必须经过检查 ( 使用人工或自动程序 ), 如下所示 : 所有代码更改都必须由原始代码作者以外且熟知代码检查技术和安全编码实践的人员进行 代码检查确保代码是根据安全的编码指南进行开发的, 例如开放式 Web 安全项目指南 ( 请参阅 PCI DSS 要求 6.5) 在发布以前必须执行相应的更正 在发布以前由管理层检查并批准代码检查结果 c 选择最近的自定义应用程序更改的抽样, 并确认自定义应用程序代码已根据上述 6.3.7a 和 6.3.7b 经过检查 6.4 跟踪对系统组件进行的所有更改的更改控制流程 这些程序必须包括以下项目 : 6.4.a 获取并检查与实施安全补丁和软件更改相关的公司更改控制流程, 并确认这些流程要求下述 各项 6.4.b 对于系统组件和最近的更改 / 安全补丁抽样, 将这些更改追溯至相关的更改控制记录 对于检查的每项更改执行以下项目 : 影响记录 确认每个抽样更改的更改控制记录中已包含了对客户影响的记录 相关方管理层的签发 确认每个抽样更改都有相关方管理层的签发 对操作功能的测试 确认每个抽样更改都实施了操作功能测试 取消流程 确认每个抽样更改都准备了取消流程 2008 PCI 安全标准委员会版权所有 第 26 页

28 PCI DSS 要求测试程序到位不到位目标日期 / 备注 6.5 基于安全编码指南开发所有 Web 应用程序 ( 内部与外部的, 以及对应用程序的 Web 管理访问 ), 例如开放式 Web 应用程序安全项目指南 涵盖在软件开发过程中对常见编码漏洞的防护, 包括以下各项 : 注 :6.5.1 至 中列举的漏洞都是 PCI DSS v1.2 发布时 OWASP 指南中最新的 然而, 如果 OWASP 指南有更新, 则最新版本将用于这些要求 6.5.a 获取并检查所有基于 Web 的应用程序的软件开发流程 确认该流程已要求对开发人员实施安全编码技术培训, 并且是基于诸如 OWASP 指南 ( 6.5.b 抽取部分开发人员进行访问, 获取表明他们熟悉安全编码技术的证明 6.5.c 确认这些程序已到位, 以确认 Web 应用程序在以下方面没有漏洞 : 跨站脚本 (XSS) 跨站脚本 (XSS)( 应用前验证所有参数 ) 注入攻击, 特别是 SQL 注入 同时还须考虑 LDAP Xpath 及其他注入攻击 注入攻击, 特别是 SQL 注入 ( 验证输入以确认用户数据无法更改命令与查询的意思 ) 恶意文件执行 恶意文件执行 ( 验证输入以确认应用程序不接受来自用户的文件名或文件 ) 不安全的直接对象引用 不安全的直接对象引用 ( 不要向用户公开内部对象引用 ) 跨站请求伪造 (CSRF) 跨站请求伪造 (CSRF)( 不要回复由浏览器自动提交的授权证书和令牌 ) 信息泄露和不正确的错误处理 信息泄露与不正确的错误处理 ( 不要通过错误讯息或其他方式泄露信息 ) 失效的验证和会话管理 失效的验证和会话管理 ( 正确验证用户, 并保护账户证书和会话令牌 ) 不安全加密存储 不安全加密存储 ( 防止密码攻击 ) 不安全通信 不安全通信 ( 对所有已验证的敏感通信进行正确加 密 ) 未能限制 URL 访问 未能限制 URL 访问 ( 始终对所有的 URL 执行表示层的访问控制和业务逻辑 ) 2008 PCI 安全标准委员会版权所有 第 27 页

29 PCI DSS 要求测试程序到位不到位目标日期 / 备注 6.6 对于面向公众的 Web 应用程序, 经常解决新的威胁和漏洞, 并确保保护这些应用程序不受到以下任一方法的攻击 : 通过手动或自动应用程序漏洞安全评估工具或方法检查面向公众的 Web 应用程序, 至少每年一次并在所有更改后进行检查 在面向公众的 Web 应用程序前端安装 Web 应用程序防火墙 6.6 对于面向公众的 Web 应用程序, 确保采用了以下任一方法 : 确认检查了面向公众的 Web 应用程序 ( 使用手动或自动漏洞安全评估工具或方法 ), 如下所示 : - 至少每年一次 - 任何更改后 - 由专门检查应用程序安全的机构 - 所有的漏洞都被更改 - 更正后重新评估应用程序 确认在面向公众的 Web 应用程序前端采用了 Web 应用程序防火墙, 以检测并防止基于 Web 的攻击 注 : 专门检查应用程序安全的机构 可以是第三方公司或一个内部组织, 只要检查人是专门从事应用程序代码安全的, 并且能够证明独立于开发团队 2008 PCI 安全标准委员会版权所有 第 28 页

30 执行严格的访问控制措施 要求 7: 限制为只有业务需要知道的人才能访问持卡人数据为确保只有授权的人才能访问关键数据, 必须采用系统和流程来限制根据需要知道和工作职责进行访问 需要知道 是指当需要执行一项工作时需要授予的最少数据和权限 PCI DSS 要求测试程序到位不到位目标日期 / 备注 7.1 将对系统组件和持卡人数据的访问限制为只有工作需要访问这些数据的人 访问限制必须包括以下项目 : 将特权用户 ID 的访问权限限制为执行工作职责要求的最小权限 7.1 获取并检查数据控制书面政策, 并确认政策包含以下各项 : 确认特权用户 ID 的访问权限已限制为执行工作职责要求的最小权限 根据个人工作划分和职能分配权限 确认已根据工作划分和职能分配了权限 ( 也称为 基于角色的访问控制 或 RBAC) 要求管理层签署授权书以指明需要的权限 确认所有访问都提供了授权书, 必须指明了要求的权限, 并且必须由管理层签署 自动访问控制系统的实施 确认通过自动访问控制系统实施了访问控制 7.2 为多用户系统组件建立访问控制系统, 根据用户需要知道的数据限制访问, 并且设置为 禁止所有, 除非特别允许 此访问控制系统必须包含以下各项 : 7.2 检查系统设备和供应商记录, 以确认按以下方式实施了访问控制系统 : 覆盖所有的系统组件 确认所有的系统组件都采用了访问控制系统 根据工作划分和职能给个人分配权限 确认已配置了访问控制系统, 根据工作划分和职能将权限分配给个人 默认的 禁止所有 设置 确认访问控制系统有一个默认的 禁止所有 设置 注 : 一些访问控制系统被默认设置为 允许所有, 因此允许所有访问, 除非制定了专门禁止的规则 2008 PCI 安全标准委员会版权所有 第 29 页

31 要求 8: 为每位拥有计算机访问权限的用户分配唯一的 ID 为每位拥有访问权限的用户分配唯一的 ID 可确保每个人都能为其操作承担唯一责任 采用此责任制之后, 只有获得授权的已知用户才能操作重要数据和系统, 而且这种操作行为可以跟踪 PCI DSS 要求测试程序到位不到位目标日期 / 备注 8.1 在允许所有用户访问系统组件或持卡人数据之前为其分配唯一的 ID 8.2 除分配唯一的 ID 之外, 至少采用以下一种方法验证所有用户的身份 : 密码或口令 双因素验证 ( 例如令牌设备 智能卡 生物测定技术或公共密钥 ) 8.3 员工 管理员和第三方采用双因素验证以远程访问 ( 从网络外进行网络级的访问 ) 网络 使用远程拨入用户认证服务 (RADIUS) 带有令牌的终端访问控制器访问控制系统 (TACACS) 或带有个人证书的 VPN ( 基于 SSL/TLS 或 IPSEC) 等技术 8.4 在所有系统组件上进行传输和存储操作时, 采用强效加密术 ( 参照 PCI DSS 术语与缩略语 中的定义 ) 使所有密码不可读 8.5 确保在所有系统组件上都对非消费者用户和管理员都采用正确的用户身份认证和密码管理, 具体如下 : 8.1 确定已为所有使用者分配用于存取系统元件或持卡人资料的唯一 ID 8.2 如要使用唯一的 ID 和其他验证方法 ( 例如密码 ) 确定用户的身份已经过验证并可以访问持卡人数据环境, 请执行以下操作 : 获取描述所用验证方法的文件资料并进行检查 对于使用的每一种验证方法和每一种系统组件, 观察验证操作以确定其运作和归档的验证方法相一致 8.3 要确定是否所有的远程网络访问都实施双因素验证, 请检查员工 ( 例如管理员 ) 远程连接网络的操作并确定是否需要密码和其他的身份认证项目 ( 例如智能卡 令牌 PIN) 8.4.a 对于抽样的系统组件, 请检查密码文件, 以确定密码在传输和存储过程中不可读 8.4.b 仅对服务提供商来说, 请检查密码文件, 以确定用户口令已加密 8.5 通过实施以下操作审核程序和访问相关人员, 以确定实施了相应程序, 从而可确保正确的用户身份认证和密码管理 : 2008 PCI 安全标准委员会版权所有 第 30 页

32 PCI DSS 要求测试程序到位不到位目标日期 / 备注 控制用户 ID 凭据和其他识别对象的添加 删除和修改操作 a 抽样选取用户 ID, 包括管理员和普通用户的 ID 执行以下程序, 以确定每位用户是否获得授权并可根据公司政策使用系统 : 获取每个 ID 的授权表并予以检查 跟踪从授权表到系统的信息, 确定抽样的用户 ID 能够根据授权表 ( 包括根据指定的特权和所有获取的签名 ) 实施操作 重置密码前确定用户身份 检查密码程序, 观察安全人员, 以确保用户在通过电话 电子邮件 网络或其他非面对面方式请求重置密码时, 先确定用户身份再重置密码 为每位用户的初始密码设置唯一值, 第一次使用后立即更改 立即撤销任何已终止用户的访问权限 至少每 90 天撤除 / 停用一次非活跃的用户账户 仅在所需时段启用供应商用于远程维护的账户 向拥有访问持卡人数据权限的所有用户通报密码程序和政策 检查密码程序, 观察安全人员, 以确保每位新用户的初始密码都设有唯一值, 并且第一次使用后都会更改 抽样选择过去六个月中已终止的用户, 检查当前的用户访问列表, 以确定他们的 ID 已停用或撤除 确定处于非活跃状态超过 90 天的账户已撤除或停用 确定供应商用于支持和维护系统组件的所有账户仅在供应商需要时保持禁用或启用状态 ; 并且在使用时保持监控状态 根据抽样选择的用户 ID 访问用户, 以确保他们熟悉密码程序和政策 2008 PCI 安全标准委员会版权所有 第 31 页

33 PCI DSS 要求测试程序到位不到位目标日期 / 备注 不要使用组 共享或常规账户和密码 a 对于抽样选择的系统组件, 检查用户 ID 列表以确定以下内容 常规用户 ID 和账户已停用或撤除 用于系统管理活动和其他重要功能的共享用户 ID 已不存在 共享用户 ID 和常规用户 ID 不能用于管理任何系统组件 b 检查密码政策 / 程序, 以确定组密码和共享密码已明确禁止 c 访问系统管理员, 以确定未分配组密码和共享密码, 即使已有请求 至少每 90 天更改一次用户密码 对于抽样选择的系统组件, 获取系统配置设置并进行检查, 以确定设置的用户密码参数会要求用户至少每 90 天更改一次密码 仅对于服务提供商而言, 检查内部流程和客户 / 用户文件资料, 以确定客户密码需要定期更改, 并确定所有客户都会获得何时 在何种情况下必须更改密码的指导说明 密码必须至少有七个字符长 对于抽样选择的系统组件, 获取系统配置设置并进行检查, 以确定设置的密码参数会要求密码至少有七个字符长 仅对于服务提供商而言, 检查内部流程和客户 / 用户文件资料, 以确定系统要求客户密码必须符合最低长度要求 使用包含数字和字母字符的密码 对于抽样选择的系统组件, 获取系统配置设置并进行检查, 以确定密码参数已设置为要求密码包含数字和字母字符 仅对于服务提供商而言, 检查内部流程和客户 / 用户文件资料, 以确定系统要求客户密码必须包含数字和字母字符 2008 PCI 安全标准委员会版权所有 第 32 页

34 PCI DSS 要求测试程序到位不到位目标日期 / 备注 不允许个人提交和前四次使用过的任何密码相同的新密码 用户尝试次数达到六次后锁定该用户 ID, 以限制尝试反复访问 将锁定时长设置为至少 30 分钟或直到管理员启用用户 ID 为止 如果会话保持空闲状态超过 15 分钟, 则需要用户重新输入密码以重新激活终端 验证访问任何数据库 ( 其中包括持卡人数据 ) 的所有操作 这包括应用程序 管理员和所有其他用户的访问操作 对于抽样选择的系统组件, 获取系统配置设置并进行检查, 以确定设置的密码参数会要求新密码不能和前四次使用过的密码相同 仅对于服务提供商而言, 检查内部流程和客户 / 用户文件资料, 以确定客户的新密码不能和前四次使用的密码相同 对于抽样选择的系统组件, 获取系统配置设置并进行检查, 以确定设置的密码参数会要求用户在六次尝试登录失败后锁定该用户的账户 仅对于服务提供商而言, 检查内部流程和客户 / 用户文件资料, 以确定客户在六次尝试访问失败后暂时锁定该客户的账户 对于抽样选择的系统组件, 获取系统配置设置并进行检查, 以确定设置的密码参数会要求用户账户一旦锁定后会至少锁定 30 分钟, 或者直到系统管理员重置该账户才解除锁定 对于抽样选择的系统组件, 获取系统配置设置并进行检查, 以确定系统 / 会话的空闲状态超时时间已设置为 15 分钟或更少 a 检查数据库和应用程序配置设置, 以确定用户身份认证和数据库的访问包括以下内容 : 所有用户在访问前必须进行身份认证 所有的用户访问数据库 查询数据库和操作数据库 ( 例如移动 复制 删除 ) 行为必须只能通过编程方法 ( 例如, 通过存储的程序 ) 只有数据库管理员才能直接访问数据库或查询数据库 b 检查数据库应用程序和相关应用程序 ID, 以确定应用程序 ID 仅限应用程序 ( 而不是个人用户或其他流程 ) 使用 2008 PCI 安全标准委员会版权所有 第 33 页

35 要求 9: 限制对持卡人数据的物理访问 任何物理访问数据或存储持卡人数据的系统的操作都会为个人提供访问设备或数据从而删除系统或硬拷贝的机会, 这种行为应适当限制 PCI DSS 要求测试程序到位不到位目标日期 / 备注 9.1 使用适当的机构入口控制, 以在持卡人数据环境中限制和监控系统的物理访问 使用摄像头或其他访问控制机制, 以监控个人对敏感区域的物理访问 检查收集的数据并与其他入口相关联 至少保存三个月, 法律另有规定的除外 注 : 敏感区域 指的是任何数据中心 服务器室或任何放置可保存 处理或传输持卡人数据的系统的区域 它不包括仅仅只有销售点终端 ( 例如零售店的收银区域 ) 的区域 限制对公共网络插座交换机的物理访问 限制对无线访问点 网关和手持式设备的物理访问 9.1 确定持卡人数据环境中的每间计算机室 数据中心和其他带有系统的实体区域都有物理安全控制 确定已使用工卡读卡器或其他设备 ( 包括获得授权的工卡 锁和密钥 ) 控制访问 观察系统管理员试图在持卡人环境中登录随意选择的系统控制台时的操作, 确定这些控制台已 锁定, 以避免未经授权的使用 确定摄像头或其他访问控制机制已到位, 可监控敏感区域的入口 / 出口 应保护摄像头或其他机制, 以避免篡改或禁用操作 确定摄像头或其他机制已受到监控, 而且摄像头或其他机制中的数据可至少保存三个月 通过访问网络管理员并且通过观察, 以确定网络插座交换机仅在获得授权的员工需要时才会启用 例如, 在用来招待访客的会议室中, 就不应使用启用了 DHCP 的网络端口 另外, 在这些网络插座交换机处于活跃状态的区域, 应确定访客身边始终都有陪护人员 确定无线访问点 网关和手持式设备的物理访问操作都已适当限制 2008 PCI 安全标准委员会版权所有 第 34 页

36 PCI DSS 要求测试程序到位不到位目标日期 / 备注 9.2 制订相关程序, 以帮助所有员工迅速识别雇员和访客, 尤其是在可以查看持卡人数据的区域迅速识别雇员和访客 为明确这一要求, 雇员 指的是全职和兼职雇员 临时雇员和员工以及 常驻 在机构的承包商和顾问 访客 指的是供应商 雇员的客人 服务人员或任何需要进入机构作短暂停留 ( 一般不超过一天 ) 的任何人 9.2.a 检查向雇员和访客分配工卡的流程和程序, 并确定这些流程包括以下内容 : 发放新工卡 更改访问要求 撤销停职员工和过期访客的工卡 限制访问工卡系统 9.2.b 观察机构内的人员, 确定可以轻而易举地分辨雇员和访客 9.3 确保遵循以下程序处理所有访客 : 9.3 确定已布署雇员 / 访客控制, 具体如下 : 进入处理或维护持卡人数据的区域之前, 必须获得授权 提供可以将访客识别为非雇员而且使用后会过期的物理令牌 ( 例如工卡或访问设备 ) 要求访客在离开机构之前或在过期日交出物理令牌 9.4 使用访客日志, 以保持访客活动的实体核查记录 在日志上记录访客姓名 所属公司以及授权访客进行物理访问的员工 将该日志至少保存三个月, 法律另有规定的除外 9.5 将备份媒介存放在安全的地方, 最好存放在机构之外的场所, 例如其它场所或备用中心或商业性的存储机构 至少每年检查一次该场所的安全性 9.6 采用物理方式保护包含持卡人数据的所有纸质媒介和电子媒介 观察访客, 确定他们均已佩戴访客 ID 工卡 试图访问数据中心, 以确定凭访客 ID 工卡不能在没有陪护人员的情况下访问存放持卡人数据的实体区域 检查员工工卡和访客工卡, 以确定通过 ID 工卡能明确辨别雇员和访客 / 外来人员, 而且访客工卡使用后会过期 观察要离开机构的访客, 以确定公司会要求他们在离开时或工卡过期时交出 ID 工卡 9.4.a 确定已使用访客日志, 以记录机构 计算机室以及存放和传输持卡人数据的数据中心的物理访问活动 9.4.b 确定日志包含访客姓名 所属公司以及授权访客进行物理访问的员工, 并确定该日志至少保存三个月 9.5 确定每年检查一次存储场所, 以确保备份媒介的安全性 9.6 确定保护持卡人数据的程序包括使用物理方式保护纸质媒介和电子媒介 ( 包括计算机 可移动电子媒介 网络 通信硬件 电信线路 纸质收据 纸质报告和传真 ) 的控制 2008 PCI 安全标准委员会版权所有 第 35 页

37 PCI DSS 要求测试程序到位不到位目标日期 / 备注 9.7 始终严格控制在内部或外部分发任何类型的包含持卡人数据的媒介, 包括以下内容 : 将媒介分类, 以便将其标识为 机密 使用安全的快递服务或其他可准确跟踪的传送方式寄送媒介 9.8 将任何和所有包含持卡人数据的媒介从安全区域转移时 ( 尤其是当媒介发放给个人时 ), 务必确保管理层已同意 9.9 始终严格控制对媒介 ( 其中包含持卡人数据 ) 的存储和访问操作 正确保存所有媒介的盘存日志, 媒介至少每年盘存一次 9.10 包含持卡人数据的媒介由于业务原因或法律原因不再需要时应予以销毁, 具体如下 : 对硬拷贝材料进行粉碎 焚烧或打浆, 让持卡人数据无法复原 9.7 确定已制订相关政策, 可控制分发包含持卡人数据的媒介 ; 并确定此政策涵盖所有分发的媒介 ( 包括向个人分发的媒介 ) 确定所有媒介都已分类, 以便将其标识为 机密 确定所有发送到机构之外的媒介都已记录, 都已经过管理层授权, 而且寄送时都使用了安全的快递服务或其他可准确跟踪的传送方式 9.8 在最近几天的跟踪日志中抽样选择向机构外发送包含持卡人数据的所有媒介的记录, 确定日志中有跟踪详情和相应的管理层授权记录 9.9 获取控制存储和维护硬拷贝和电子媒介的政策并进行检查, 以确定此政策要求媒介定期盘存 获取媒介盘存日志并进行检查, 以确定媒介定期盘存至少每年执行一次 9.10 获取媒介定期销毁的政策并进行检查, 以确定该政策涵盖包含持卡人数据的所有媒介, 并确认以下项目 : a 确保对硬拷贝材料进行横切粉碎 焚烧或打浆, 以确保这些硬拷贝材料无法复原 b 检查用来销毁信息的存储容器, 以确保这些容器的安全性 例如, 确定 待碎料 容器上有锁, 可避免他人查看容器内的内容 使电子媒介上的持卡人数据不可恢复, 确保持卡人数据不可复原 使用符合行业标准的安全擦除程序进行安全删除, 或者使用其他物理方法销毁媒介 ( 例如消磁 ), 以确保电子媒体上的持卡人数据不可恢复 2008 PCI 安全标准委员会版权所有 第 36 页

38 定期监控网络和测试网络 要求 10: 跟踪和监控访问网络资源和持卡人数据的所有操作 记录机制和跟踪用户活动的功能对于预防 检测和消除数据泄漏的不良影响至关重要 在所有环境中使用日志可在出现问题时详细地跟踪 发出警报并进行分析 如果没有系统活动日志, 确定问题根源会变得异常困难 PCI DSS 要求测试程序到位不到位目标日期 / 备注 10.1 为每个个人用户建立一个可连接访问所有系统组件 ( 尤其是具有根权限等管理权限的访问 ) 的流程 10.2 针对所有系统组件实施自动核查记录, 以重建以下事件 : 10.1 通过观察和访问系统管理员, 确定核查记录已启用并处于活跃状态, 可用于系统组件 10.2 通过访问 检查核查日志和检查核查日志设置, 执行以下操作 : 对持卡人数据的所有个人访问 确定记录所有个人访问持卡人数据的操作 具有根权限或管理权限的任何个人实施的所有操作 确定记录具有根权限或管理权限的任何个人实施的操作 访问所有核查记录 确定记录所有核查记录的访问操作 无效的逻辑访问尝试 确定记录无效的逻辑访问尝试 使用身份认证和验证机制 确定记录身份认证和验证机制的使用情况 初始化核查日志 确定记录核查日志的初始化 创建和删除系统级对象 确定记录系统级对象的创建和删除 10.3 针对每个事件的所有系统组件至少记录以下核查记录条目 : 10.3 通过访问和观察, 针对每个核查事件 ( 参阅 10.2) 执行以下内容 : 用户身份认证 确定日志条目中包括用户身份认证 事件类型 确定日志条目中包括事件类型 2008 PCI 安全标准委员会版权所有 第 37 页

39 PCI DSS 要求测试程序到位不到位目标日期 / 备注 日期和时间 确定日志条目中包括日期和时间戳记 成功指示或失败指示 确定日志条目中包括成功指示或失败指示 事件起源 确定日志条目中包括事件起源 受损数据 系统组件或资源的特征或名称 10.4 同步所有重要的系统时钟和时间 确定日志条目中包括受损数据 系统组件或资源的特征或名称 10.4 获取和检查在机构内部取得和分配正确时间的流程, 同时获取针对抽样选择的系统组件的时间相关系统参数设置流程并进行检查 确定流程中包括以下内容并能够全部实施 : 10.4.a 确定进行时间同步时, 使用的是稳定的已知版本的网络时间协议 (NTP) 或类似技术并能根据 PCI DSS 要求 6.1 和 6.2 保持更新 10.4.b 确定内部服务器未从外部来源接收所有时间信号 [ 机构内的两三台中心时间服务器 [ 直接从特殊无线电 GPS 卫星或其他基于国际原子时和 UTC( 以前的 GMT) 的外部来源 ] 接收外部时间信号 ; 它们相互之间作比较以保持准确时间并和其他内部服务器共享时间 ] 10.4.c 确定已指定特定的外部主机, 时间服务器可通过该主机接受 NTP 时间更新 ( 以避免心怀恶意的个人更改时钟 ) 或者, 可使用对称密钥加密这些更新, 而且可创建访问控制列表, 以指定提供 NTP 服务的客户端机器的 IP 地址 ( 以避免未经授权方使用内部时间服务器 ) 请访问 以了解更多信息 10.5 保护核查记录, 以避免篡改 10.5 访问系统管理员并检查许可权限, 以确定核查记录已处于保护状态, 不能被篡改, 具体如下 : 仅限出于工作需要的人员查看核查记录 保护核查记录文件, 防止未经授权的修改操作 确定只有出于工作需要的个人才能查看核查记录文件 确定已通过访问控制机制 物理隔离和 / 或网络隔离保护当前核查记录文件, 以防止未经授权的修改操作 2008 PCI 安全标准委员会版权所有 第 38 页

40 PCI DSS 要求测试程序到位不到位目标日期 / 备注 将核查记录文件迅速备份到不易篡改的中心日志服务器或媒介 将外部式技术的日志写入外部 LAN 上的日志服务器 针对日志使用文件完整性监控软件或更改检测软件, 以确保现有的日志数据在不生成警报的情况下不会更改 ( 尽管添加新数据不会引发警报 ) 10.6 每天至少检查一次所有系统组件的日志 日志检查必须包括检查执行入侵检测系统 (IDS) 和验证 授权等安全功能的服务器以及记账协议 (AAA) 服务器 ( 例如 RADIUS) 注 : 可根据 要求 10.6 中的规定, 使用日志收集工具 分析工具和报警工具 10.7 核查历史记录至少保留一年, 至少可以立即准备 ( 例如在线 已归档或从备份中恢复 ) 三个月的历史记录以供分析 确定当前的核查记录文件已迅速备份到不易篡改的中心日志服务器或媒介 确定外部式技术 ( 例如无线 防火墙 DNS 邮件 ) 的日志已卸载或复制到安全的中心式内部日志服务器或媒介 检查系统设置 受监控的文件以及通过监控活动得出的结果, 以确定针对日志使用了文件完整性监控软件或更改检测软件 10.6.a 获取安全政策和程序并进行检查, 以确定它们包括至少每天检查一次安全日志的程序, 同时确定它们要求在特例的情况下进行跟踪 10.6.b 通过观察和访问, 确定所有系统组件都会执行常规日志检查 10.7.a 获取安全政策和程序并进行检查, 以确定它们包括保留核查记录的政策, 而且它们要求将核查日志至少保留一年 10.7.b 确定核查日志至少保留一年, 并且已制订流程可来恢复至少前三个月的日志, 以供立即分析 2008 PCI 安全标准委员会版权所有 第 39 页

41 要求 11: 定期测试安全系统和流程 心怀恶意的个人和研究者总是可以不断发现漏洞, 一些新软件也可以引发漏洞 因此应经常测试系统组件 流程和自定义软件, 以确保根据不断变化的环境不断实施安全控制 PCI DSS 要求测试程序到位不到位目标日期 / 备注 11.1 至少每季度使用一次无线分析仪或部署可识别所有在用无线设备的无线 IDS/IPS, 以测试无线访问点是否存在 11.1.a 确定至少每季度使用一次无线分析仪, 或确定已实施并配置无线 IDS/IPS, 以识别所有无线设备 11.1.b 如果已实施无线 IDS/IPS, 请确定其配置可为员工生成警报 11.1.c 确定机构的 事故响应计划 ( 请参阅 要求 12.9 ) 包括在检测到未经授权的无线设备时给予响应 11.2 至少每季度以及在网络有任何重大变动后 ( 例如安装新的系统组件 更改网络拓扑 修改防火墙规则 产品更新 ) 运行一次内部和外部网络漏洞扫描 注 : 每季度一次的外部漏洞扫描必须由支付卡行业安全标准委员会 (PCI SSC) 认证的授权扫描供应商 (ASV) 执行 网络变动后的扫描工作可由公司内部员工执行 11.2.a 检查最近四个季度中内部网络 主机和应用程序的漏洞扫描结果, 以确定持卡人数据环境中的设备会进行定期安全测试 确定扫描流程包括重新扫描, 直到获得通过结果为止 注 : 网络变动后的外部扫描工作和内部扫描工作可由公司内部的授权员工或第三方执行 11.2.b 确定外部扫描根据 PCI 安全扫描程序每季度执行一次 ; 通过检查最近四个季度外部漏洞扫描的结果确定 : 四个季度的扫描是在最近 12 个月期间内执行的 ; 每次扫描结果都符合 PCI 安全扫描程序 ( 例如未发现紧急 重大或高危漏洞 ); 执行扫描的是 PCI SSC 认可的授权扫描供应商 (ASV) 注 : 如果评估商确定以下内容, 则不要求必须完成四次通过性季度扫描才能获得初始的 PCI DSS 遵从性 :1) 最近一次的扫描结果成功通过 ;2) 机构已记录了要求季度扫描的政策和程序 ; 以及 3) 扫描结果中指出的漏洞在重新扫描时显示已纠正 第一次 PCI DSS 检查完成之后的年份中, 必须执行四次通过性季度扫描 11.2.c 通过检查上一年的扫描结果, 确定网络中有任何重大变动后都会执行内部和 / 或外部扫描 确定扫描流程包括重新扫描, 直到获得通过结果为止 2008 PCI 安全标准委员会版权所有 第 40 页

42 PCI DSS 要求测试程序到位不到位目标日期 / 备注 11.3 外部和内部穿透测试每年至少执行一次, 基础架构或应用程序有任何重大升级或修改后 ( 例如操作系统升级 环境中添加子网络或环境中添加网络服务器 ) 也应执行 此类穿透测试必须包括以下内容 : 11.3.a 获取最近的穿透测试的结果并进行检查, 以确定该穿透测试至少每年执行一次, 而且在环境有任何重大变动后都会执行 确定指出的漏洞都已纠正并且测试已重复执行 11.3.b 确定执行测试的是具有相关资质的内部人员或外部第三方, 如有可能, 还应确保测试方的机构独立性 ( 不需要为 QSA 或 ASV) 网络层穿透测试 确定穿透测试包括网络层穿透测试 此类测试应包括支持网络功能和操作系统的组件 应用程序层穿透测试 确定穿透测试包括应用程序层穿透测试 对于网络应用程序, 测试应至少包括 要求 6.5 中列出的漏洞 11.4 使用入侵检测系统和 / 或入侵防御系统, 以监控持卡人数据环境中的所有流量并在发现可疑威胁时提醒员工 随时更新所有入侵检测引擎和入侵防御引擎 11.4.a 确定已使用入侵检测系统和 / 或入侵防御系统, 并确定持卡人数据环境中的所有流量都处于监控之下 11.4.b 确定 IDS 和 / 或 IPS 已配置, 可在发现可疑威胁的情况下提醒员工 11.4.c 检查 IDS/IPS 配置并确定 IDS/IPS 设备已根据供应商的说明进行配置 维护和更新, 可确保最佳的防护性能 11.5 部署文件完整性监控软件, 如发现未经授权修改重要系统文件 配置文件或内容文件的操作将提醒员工 ; 配置该软件, 使其至少每周比较一次重要文件 注 : 对于文件完整性监控软件来说, 重要文件通常是不经常更改的文件, 但是修改此类文件会引发系统威胁或有可能造成威胁 文件完整性监控软件通常需要使用相关操作系统的重要文件进行预配置 其他的重要文件 ( 例如自定义应用程序的文件 ) 则必须由机构 ( 即商户或服务提供商 ) 来评估和定义 11.5 观察系统设置和受监控的文件, 同时检查监控活动结果, 以确定持卡人数据环境已使用文件完整性监控产品 需要监控的文件示例 : 系统可执行文件 应用程序可执行文件 配置文件和参数文件 集中存储的文件 历史或存档文件 日志文件和核查文件 2008 PCI 安全标准委员会版权所有 第 41 页

43 维护信息安全政策 要求 12: 维护针对雇员和承包商信息安全的政策 有效的安全政策不仅可以为整个公司设置安全基准, 还可告知雇员他们的职责 所有雇员应了解数据的敏感性以及他们有保护数据的责任 为明确这一要求, 雇员 指的是全职和兼职雇员 临时雇员和员工以及 常驻 在公司的承包商和顾问 PCI DSS 要求测试程序到位不到位目标日期 / 备注 12.1 建立 发布 维护和散发可实现以下标准的安全政策 : 12.1 检查信息安全政策, 确定该政策已发布并散发给所有相关系统用户 ( 包括供应商 承包商和业务合作伙伴 ) 处理所有 PCI DSS 要求 确定政策可处理所有 PCI DSS 要求 包括可识别威胁和漏洞的年度流程并能生成正式的风险评估 包括至少每年执行一次检查并在环境变动时予以更新 12.2 根据此规格中的要求制订每日操作安全程序 ( 例如用户帐户维护程序和日志查看程序 ) 12.3 针对面向员工的重要技术 ( 例如远程访问技术 无线技术 可移动电子媒介 笔记本电脑 个人数据助理 (PDA) 电子邮件使用和因特网使用 ) 制订使用政策, 以定义所有雇员和承包商正确使用这些技术的政策 确保此类使用政策要求以下内容 : 确定信息安全政策包括可识别威胁和漏洞的年度风险评估流程并能生成正式的风险评估 确定信息安全政策至少每年检查一次, 并在需要时进行更新以反映业务目标或风险环境的变动 12.2.a 检查每日操作安全程序 确定它们符合此规格, 并且包括管理程序和技术程序, 以符合每一种要求 12.3 获取面向员工的重要技术的政策并进行检查, 然后执行以下程序 : 管理层的明确许可 确定使用政策要求获得管理层的明确许可才能使用此类技术 使用技术的授权 确定使用政策要求所有技术在使用时必须获得授权, 取得用户 ID 和密码或其他授权项目 ( 例如令牌 ) 所有此类设备和获得访问权限的员工列表 确定使用政策要求提供所有设备和获授权可使用此类设备的员工列表 2008 PCI 安全标准委员会版权所有 第 42 页

44 PCI DSS 要求测试程序到位不到位目标日期 / 备注 给设备贴标签并注明所有者 联系信息和用途 确定使用政策要求给设备贴标签并注明所有者 联系信息和用途 可接受的技术使用方式 确定使用政策要求可接受的技术使用方式 可接受的技术网络位置 确定使用政策要求可接受的技术网络位置 公司许可的产品列表 确定使用政策要求公司许可的产品列表 非活跃状态达到特定时限后自动中断远程访问技术的会话 仅在供应商需要时为其激活远程访问技术, 并在使用后立即停用 通过远程访问技术访问持卡人数据时, 禁止将持卡人数据复制 移动和存储到本地硬盘和可移动电子媒介 12.4 确保安全政策和程序明确定义了所有雇员和承包商的信息安全职责 12.5 针对个人或团队分配以下信息安全管理职责 : 建立 记录和分配安全政策和程序 监控 分析安全警报和安全信息并将其分配给相关人员 创建 记录和分配安全事故响应程序和逐层上报程序, 以确保及时有效地处理所有情况 管理用户账户, 包括添加 删除和修改 确定使用政策要求非活跃状态达到特定时限后自动中断远程访问技术的会话 确定使用政策要求仅在供应商需要时激活其使用的远程访问技术, 并在使用后立即停用 确定使用政策禁止在通过远程访问技术访问持卡人数据时将此类数据复制 移动和存储到本地硬盘和可移动电子媒介 12.4 确定信息安全政策已明确定义雇员和承包商的信息安全职责 12.5 确定已向首席安全执行官或其他具有安全知识的管理层成员正式分配信息安全职责 获取信息安全政策和程序并进行检查, 确定已通过正式渠道明确分配了以下信息安全职责 : 确定创建 分配安全政策和程序的职责已正式分配 确定已正式分配监控 分析安全警报并将信息分配给相关信息安全部和业务部管理层人员的职责 确定创建 分配安全事故响应程序和逐层上报程序的职责已正式分配 确定管理用户账户和验证管理的职责已正式分配 2008 PCI 安全标准委员会版权所有 第 43 页

45 PCI DSS 要求测试程序到位不到位目标日期 / 备注 监控和控制所有的数据访问操作 确定监控和控制所有数据访问操作的职责已正式分配 12.6 实施正式的安全意识计划, 使所有雇员都能了解持卡人数据安全的重要性 雇员一经雇用后立即培训, 之后每年至少培训一次 12.6.a 确定已针对所有雇员部署了正式的安全意识计划 12.6.b 获取安全意识计划的程序和文件资料并进行检查, 然后执行以下各项 : a 确定安全意识计划可提供与雇员沟通安全意识 教育雇员的多种方式 ( 例如海报 信函 备忘录 基于网络的培训 会议和宣传 ) b 确定雇员在雇用后会参加意识培训, 而且此后每年会至少参加一次 要求雇员每年至少确认一次他们已阅读并了解公司的安全政策和程序 12.7 雇用员工前筛选应征者 ( 请参阅以上 9.2 中的 雇员 定义 ), 以尽量减少内部人员发起攻击的风险 对于门店收银员这样的员工, 这一要求仅作建议, 因为他们在交易时一次只能访问一个卡号 12.8 如持卡人数据与服务提供商共享, 应维护和实施管理服务提供商的政策和程序, 以包括以下各项 : 确定安全意识计划要求雇员每年至少确认 ( 例如通过手写方式或电子方式 ) 一次他们已阅读并了解公司的信息安全政策 12.7 询问人力资源部管理层, 确定在雇用可访问持卡人数据或持卡人数据环境的雇员之前已针对他们实施过背景调查 ( 符合本地法律规定 ) ( 背景调查的示例包括以前的雇用历史 犯罪记录 信用历史和证明人调查 ) 12.8 接受评估的机构如需与服务提供商 ( 例如磁带备份存储机构 网络托管公司或安全服务提供商等托管服务提供商或者接收数据用于分析欺诈模型的公司 ) 共享持卡人数据, 则应通过观察 检查政策和程序并检查支持的文件资料, 执行以下各项 : 保留服务提供商列表 确定服务提供商列表已保留 要求服务提供商出具书面协议, 由其确认对自己拥有的持卡人数据的安全性负责, 并保留此协议 确定书面协议包括服务提供商确认其负责保护持卡人数据的安全 2008 PCI 安全标准委员会版权所有 第 44 页

46 PCI DSS 要求测试程序到位不到位目标日期 / 备注 确保已建立雇用服务提供商的流程 ( 包括雇用前相应的尽职调查 ) 始终遵循计划, 以监控服务提供商的 PCI DSS 遵从性状态 12.9 实施事故响应计划 随时准备立即响应系统漏洞事故 创建 事故响应计划, 以便在发现系统漏洞时实施 确保计划至少可以处理以下各项 : 发生漏洞时的角色 职责和沟通策略以及联系策略, 至少包括通知支付品牌 特定的事故响应程序 业务恢复和业务连续性程序 数据备份流程 分析报告漏洞的法律要求 所有重要系统组件的范围和响应 来自支付品牌的参考或包涵事故响应程序 确定此政策和程序已记录并得到遵守 ( 包括雇用任何服务提供商之前相应的尽职调查 ) 确定接受评估的机构始终遵循循计划, 以监控其服务提供商的 PCI DSS 遵从性状态 12.9 获取 事故响应计划 和相关程序并进行检查, 执行以下各项 : 确定 事故响应计划 包括 : 发生漏洞时的角色 职责和沟通策略, 至少包括通知支付品牌 特定的事故响应程序, 业务恢复和业务连续性程序, 数据备份流程 分析报告漏洞的法律要求 ( 例如,California Bill 1386 要求任何公司其数据库中如有加州居民资料, 在真正发现实际数据泄漏或怀疑数据泄漏时, 必须通知受影响的消费者 ) 所有重要系统组件的范围和响应 参考或包括支付品牌的事故响应程序 至少每年测试一次计划 确定至少每年测试一次计划 指定一天 24 小时 一周 7 天随时准备响应警报的特定人员 针对负责响应安全漏洞的员工提供相应培训 通过查看和检查政策, 确定如有任何未经授权的活动的现象将提供一天 24 小时 一周 7 天的事故响应和监控范围, 同时还将一天 24 小时 一周 7 天探测未经授权的无线访问点 重要的 IDS 警报和 / 或报告重要系统文件或内容文件未经授权的更改情况 通过查看和检查政策, 确定负责响应安全漏洞的员工将定期培训 2008 PCI 安全标准委员会版权所有 第 45 页

47 PCI DSS 要求测试程序到位不到位目标日期 / 备注 包括来自于入侵检测系统 入侵防御系统和文件完整性监控系统的警报 根据以往的经验教训 结合行业发展情况制订有关修改和改进事故响应计划的流程 通过查看和检查流程, 确定 事故响应计划 包括监控和响应来自于安全系统 ( 包括探测到未经授权的无线访问点 ) 的警报 通过查看和检查政策, 确定流程包括根据以往的经验教训 结合行业发展情况修改和改进事故响应计划 2008 PCI 安全标准委员会版权所有 第 46 页

48 附录 A: 针对共享主机提供商的额外 PCI DSS 要求 要求 A.1: 共享主机提供商必须保护持卡人数据环境 根据 要求 12.8 中的规定, 所有可访问持卡人数据的服务提供商 ( 包括共享主机提供商 ) 必须遵守 PCI DSS 此外, 要求 2.4 指出共享主机提供商必须保护每个机构的托管环境和数据 因此, 共享主机提供商另外还必须遵守附录中的要求 PCI DSS 要求测试程序到位不到位目标日期 / 备注 A.1 根据 A.1.1 至 A.1.4, 保护每个机构 ( 即商户 服务提供商或其他机构 ) 的托管环境和数据 : 主机提供商必须满足这些要求和 PCI DSS 中所有其他相关章节中的要求 注 : 即使主机提供商可能会满足这些要求, 但使用主机的机构却不保证遵从性 每个机构必须遵守 PCI DSS 并证明其遵从性 ( 如适用 ) A.1 尤其是对共享主机提供商进行 PCI DSS 评估时, 如要确定共享主机提供商可保护机构 ( 商户和服务提供商 ) 的托管环境和数据, 请从托管商户和服务提供商的代表性样品中抽样选择服务器 (Microsoft Windows and Unix/Linux) 并执行以下从 A.1.1 到 A.1.4 中的内容 A.1.1 确保每个机构运行的流程仅包括访问该机构的持卡人数据环境 A.1.1 如果共享主机提供商允许机构 ( 例如商户或服务提供商 ) 运行他们自己的应用程序, 请确定使用这些机构唯一的 ID 运行此类应用程序的流程 例如 : 系统中的任何机构都不得使用共享的网络服务器用户 ID 机构使用的所有 CGI 脚本在创建和运行时都必须作为该机构唯一的用户 ID 附录 A: 针对共享主机提供商的额外 PCI DSS 要求 第 47 页

49 PCI DSS 要求测试程序到位不到位目标日期 / 备注 A.1.2 每个机构的访问权限和特权仅限访问他们自己的持卡人数据环境 A.1.2.a 确定任何应用程序流程的用户 ID 不为特权用户 ( 根权限 / 管理员权限 ) A.1.2.b 确定每个机构 ( 商户 服务提供商 ) 拥有的读取 写入或执行权限仅能用于其所属文件或目录或者必要的系统文件 ( 通过文件系统权限 访问控制列表 chroot jailshell 等加以限制 ) 注意: 机构的文件不能与组共享 A.1.2.c 入权限 确定机构用户对共享的系统二进制文件没有写 A.1.2.d 确定只有拥有日志条目的机构才能查看其条目 A.1.3 确保已启用日志和核查记录, 它们对每个机构的持卡人数据环境都是唯一的, 而且符合 PCI DSS 要求 10 A.1.4 启用在任何托管商户或服务提供商出现漏洞时及时提供取证调查的流程 A.1.2.e 为确保每个机构不会独占控制服务器资源继而利用漏洞 ( 例如错误 race 和重启会导致像缓冲区溢出这样的情况 ), 请确定已针对系统资源的使用情况部署了相关限制 : 磁盘空间 带宽 内存 CPU A.1.3.a 确定共享主机提供商已针对每个商户和服务提供商的环境启用日志, 具体如下 : 已针对第三方常规应用程序启用日志 日志在默认情况下处于活跃状态 只有拥有日志的机构才能查看其日志 日志位置已明确通知给拥有它的机构 A.1.4 确定共享主机提供商制订的书面政策包括在发现漏洞时及时提供相关服务器的取证调查流程 附录 A: 针对共享主机提供商的额外 PCI DSS 要求 第 48 页

50 附录 B: 补偿性控制 当实体由于合法的技术限制或文档的业务限制, 无法满足明确指定的要求, 但已通过实施其他措施或补偿性控制充分减轻了与此类要求相关的风险时, 对于大多数 PCI DSS 要求可能需要考虑补偿性控制 补偿性控制必须满足以下标准 : 1. 符合最初 PCI DSS 要求的主旨和严格程度 2. 提供和最初 PCI DSS 要求类似水平的防御机制, 使补偿性控制能充分减少最初的 PCI DSS 要求必须防御的风险 ( 请参阅 PCI DSS 导航, 以了解每则 PCI DSS 要求的主旨 ) 3. 超越 其他 PCI DSS 要求 ( 仅仅只是遵循其他 PCI DSS 要求并不构成补偿性控制 ) 评估补偿性控制的 超越 时, 请考虑以下各项 : 注 : 以下从 a) 到 c) 的各项为示例, 仅供参考 所有补偿性控制必须由执行 PCI DS 审核的评估商检查并确认其是否充分有效 补偿性控制的有效性取决于实施控制的环境的具体情况 相关的安全控制和控制的配置 公司应理解特定的补偿性控制并非在所有环境都有效 a) 现有的 PCI DSS 要求如果在审查时某个项目已经需要它, 则不能视为补偿性控制 例如, 非控制台管理访问的密码发送时必须加密, 以减少明文管理密码遭到拦截的风险 机构不得使用其他的旨在补偿缺少加密密码的 PCI DSS 密码要求 ( 入侵者锁定 复杂密码等 ), 因为这些其他的密码要求不能减少明文密码遭到拦截的风险 而且, 其他的密码控制在审查 ( 密码 ) 时已经是项目的 PCI DSS 要求 b) 现有的 PCI DSS 要求如果有其他区域需要它, 但审查时的项目不需要它, 则可视为补偿性控制 例如, 双因素验证是远程访问的 PCI DSS 要求 在不支持传输加密密码时, 来自于内部网络中的双因素验证可视为非控制台管理访问的补偿性控制 双因素验证如符合以下条件, 则会成为可接受的补偿性控制 :(1) 通过减少明文管理密码遭到拦截的风险, 以满足要求的最初目的 ; 以及 (2) 它是在安全的环境中正确设置的 c) 现有的 PCI DSS 要求可结合新的控制方法, 以成为补偿性控制 例如, 如果一家公司无法根据要求 3.4 使持卡人数据不可读 ( 例如通过加密 ), 则补偿性控制可包括设备或包括设备 应用程序和可处理以下各项的控制方法 :(1) 内部网络隔离 ;(2) IP 地址或 MAC 地址过滤 ; 以及 (3) 来自于内部网络中的双因素验证 4. 与不遵循 PCI DSS 要求而引发的其他风险相对应 评估商必须在每一次年度 PCI DSS 评估时仔细评估补偿性控制, 以证明每一个补偿性控制都能根据以上 1 至 4 项的内容充分减少最初的 PCI DSS 要求所要防御的风险 要保持遵从性, 则必须部署相关流程和控制, 以确保补偿性控制在评估完成后始终有效 附录 B: 补偿性控制 第 49 页

51 附录 C: 补偿性控制工作表 使用补偿性控制以满足 PCI DSS 要求时, 请使用此工作表针对任何要求定义补偿性控制 注意, 补偿性控制也应在相应 PCI DSS 要求部分的 遵从性报告 中予以记录 注 : 只有已采取风险分析并有合法的技术限制或归档的业务限制的公司才能考虑使用补偿性控制以实现遵从性 要求的编号和定义 : 所需信息 1. 限制列出除遵从最初的要求之外的限制 解释 2. 目的定义最初控制的目的 ; 确定通过补偿性控制可确定目的 3. 已确定的风险确定由于缺少最初的控制而导致的任何其他风险 4. 补偿性控制的定义定义补偿性控制并解释它们处理最初控制的目的以及不断减少风险的方式 ( 如有的话 ) 5. 补偿性控制的认证定义如何认证和测试补偿性控制 6. 维护定义如何部署流程和控制以维护补偿性控制 附录 C: 补偿性控制工作表 第 50 页

52 补偿性控制工作表 完成的示例 对于已勾选 是 并且在 特殊 栏中提及补偿性控制的任何要求, 请使用此工作表定义其补偿性控制 要求的编号 :8.1 所有用户在能够访问系统组件或持卡人数据之前是否已有唯一的用户名作为身份识别标志? 所需信息 1. 限制列出除遵从最初的要求之外的限制 2. 目的定义最初控制的目的 ; 确定通过补偿性控制可实现目的 3. 已确定的风险确定由于缺少最初的控制而导致的任何其他风险 4. 补偿性控制的定义定义补偿性控制并解释它们处理最初控制的目的以及不断减少风险的方式 ( 如有的话 ) 5. 补偿性控制的认证定义如何认证和测试补偿性控制 6. 维护定义如何部署流程和控制以维护补偿性控制 解释 XYZ 公司使用没有 LDAP 的独立 Unix 服务器 因此, 他们的每个用户都需要 根 登录 XYZ 公司不可能管理 根 登录, 也无法记录每个用户的 根 活动 要求唯一登录具有双重目的 首先, 从安全的角度来看, 共享登录凭据是不能接受的 其次, 共享登录无法明确规定每个人为自己的特定操作负责 如无法确保所有用户都有唯一的 ID, 无法确保可跟踪用户 ID, 则会给访问控制系统带来其他风险 XYZ 公司将要求所有用户使用 SU 命令从其桌面登录进入服务器 SU 使用户能访问 根 账户并在 根 账户下执行操作, 但其操作会记入 SU 日志目录 因此, 每位用户的操作可通过 SU 账户进行跟踪 XYZ 公司向评估商证明 : 已执行 SU 命令 ; 使用 SU 命令的个人都已经记录, 以确定他们执行操作时使用的是根权限 XYZ 公司记录流程和程序, 以确保 SU 配置没有更改 修改或删除, 个人用户在没有跟踪或记录的情况下不可能执行根命令 附录 C: 补偿性控制工作表 第 51 页

53 附录 D: 遵从性证明书 商户支付卡行业 (PCI) 数据安全标准 实地评估遵从性证明书 商户 1.2 版

54 提交说明 本文档必须由合格安全性评估商 (QSA) 或商户 ( 如果由商户的内部稽核人员执行认证 ) 填写, 以声明商户遵循 支付卡行业数据安全标准 (PCI DSS) 时的遵从性状态 填写所有适用部分, 然后提交给收单机构或要求的支付品牌 第 1 部分 : 合格安全性评估商的公司信息 公司名称 : QSA 主要联系人姓名 : 职务 : 电话 : 电子邮件 : 营业地址 : 城市 : 州 / 省 : 国别 : 邮编 : 网址 : 第 2 部分 : 商户的机构信息 公司名称 : DBA: 联系人姓名 : 职务 : 电话 : 电子邮件 : 营业地址 : 城市 : 州 / 省 : 国别 : 邮编 : 网址 : 第 2a 部分 : 商户的业务类型 ( 勾选所有适用项 ) 零售电信杂货店和超市 石油电子商务邮购 / 电话订购 旅游和娱乐其他 ( 请在此处写明 ): 列出 PCI DSS 检查中包括的机构和地点 : 第 2b 部分 : 关系 贵公司是否和一家或多家第三方代理机构 ( 例如网关公司 网络托管公司 航空订票代理机构 忠诚项目代理机构等 ) 有关系? 是否 贵公司是否和多家收单机构有关系? 是否 第 2c 部分 : 交易处理 在用的支付应用程序 : 支付应用程序版本 : 附录 D: 实地评估遵从性证明书 商户 第 53 页

55 第 3 部分 :PCI DSS 认证 根据 (date of ROC) 的 遵从性报告 ( ROC ) 结果,(QSA Name/Merchant Name) 于 (date) 对本文档第 2 部分所确定的机构的以下遵从性状态予以确认 ( 勾选一项 ): 4 遵从性 :ROC 中的所有要求均已被标注为 到位,PCI SSC 认可的授权扫描供应商 (ASV Name) 已完成通过性扫描, 因此 (Merchant Company Name) 证明完全遵守 PCI DSS (insert version number) 不符合 : ROC 中的某些要求被标记为 不到位, 导致在总体上获得不符合评级, 或者 PCI SSC 认可的授权扫描供应商无法完成通过性扫描, 因此 (Merchant Company Name) 不能证明完全遵守 PCI DSS 达到遵从性的预定日期 : 机构如果其状态为 不符合, 在提交该表格时可能需要填写本文档第 4 部分中的 行动计划 在完成第 4 部分之前请咨询您的收单机构或支付品牌, 因为不是所有的支付品牌都需要这一部分 第 3a 部分 : 遵从性状态确认 QSA/ 商户确认 : 根据 PCI DSS 要求和安全评估程序第 (insert version number) 版和其中的指示填写 ROC 上述 ROC 与本证明中的所有信息在一切重要方面均完全代表本次评估的所有结果 商户已于支付应用程序供应商确认其支付应用程序在获得授权后不会存储敏感的验证数据 商户已阅读 PCI DSS 并确定他们将始终完全遵守 PCI DSS 5 在评估过程中, 没有证据表明交易授权后在任何检查的系统中发现有存储的磁条 ( 例如磁道 ) 数据 CAV2 6 7 CVC2 CID 或 CVV2 数据或 PIN 数据 第 3b 部分 :QSA 和商户的确认书 主要 QSA 的签名 日期 : 主要 QSA 的名称 : 职务 : 商户执行官签名 日期 : 商户执行官姓名 : 职务 : 4 到位 的结果应该包括由 QSA 或商户内部稽核人员审查的补偿性控制 如果确定补偿性控制可充分减轻和要求相关的风险,QSA 应将要求标记为 到位 5 编译在磁条中的数据, 用于实卡交易中的授权 授权之后, 机构可能不会保留完整的磁条数据 磁道数据中可能会保留下来的仅有的要素是账号 失效期与姓名 6 印在支付卡签名方格内的三或四位数值, 用于验证无实卡交易 7 由持卡人在实卡交易时输入的个人识别码和 / 或出现在交易信息中的经加密的 PIN 数据块 附录 D: 实地评估遵从性证明书 商户 第 54 页

56 第 4 部分 : 行动计划和 不符合 状态 请为每个要求选择相应的 遵从性状态 如任何要求的回答是 否, 您必须提供公司将符合要求的日期, 并简要描述为满足要求将要采取的措施 在完成第 4 部分之前请咨询您的收单机构或支付品牌, 因为不是所有的支付品牌都需要这一部分 PCI 要求 描述 遵从性状态 ( 选择一项 ) 补救日期和措施 ( 如果遵从性状态为 否 ) 1 安装防火墙配置并予以维护, 以保护持卡人数据 是否 2 系统密码和其他安全参数不使用供应商提供的默认设置 是否 3 保护存储的持卡人数据 是否 4 在开放型的公共网络中传输持卡人数据时会加密 是否 5 使用杀毒软件并定期更新 6 开发 维护安全系统和应用程序 是否是否 7 8 只有出于业务需求的人才能访问持卡人数据 为每位拥有计算机访问权限的用户分配唯一的 ID 是否是否 9 限制对持卡人数据的物理访问 是否 10 跟踪和监控访问网络资源和持卡人数据的所有操作 是否 11 定期测试安全系统和流程 12 维护针对信息安全的政策 是否是否 附录 D: 实地评估遵从性证明书 商户 第 55 页

57 附录 E: 遵从性证明书 服务提供商支付卡行业 (PCI) 数据安全标准 实地评估遵从性证明书 服务提供商 1.2 版

58 提交说明 合格安全性评估商 (QSA) 和服务提供商必须填写此文档, 以声明服务提供商遵循 支付卡行业数据安全标准 (PCI DSS) 时的遵从性状态 填写所有适用部分, 然后提交给要求的支付品牌 第 1 部分 : 合格安全性评估商的公司信息 公司名称 : PA-QSA 主要联系人姓名 : 职务 : 电话 : 电子邮件 : 营业地址 : 城市 : 州 / 省 : 国别 : 邮编 : 网址 : 第 2 部分 : 服务提供商的机构信息 公司名称 : DBA: 联系人姓名 : 职务 : 电话 : 电子邮件 : 营业地址 : 城市 : 州 / 省 : 国别 : 邮编 : 网址 : 第 2a 部分 : 提供的服务 ( 勾选所有适用项 ) 授权忠诚项目 3-D 安全访问控制服务器 交换 IPSP( 电子商务 ) 处理磁条交易 支付网关结算和交收处理 MO/TO 交易 托管发卡处理其他 ( 请在此处写明 ): 列出 PCI DSS 检查中包括的机构和地点 : 第 2b 部分 : 关系 贵公司是否和一家或多家第三方服务提供商 ( 例如网关公司 网络托管公司 航空订票代理机构 忠诚项目代理机构等 ) 有关系? 是否 第 2c 部分 : 交易处理 贵公司如何存储 处理和 / 或传输持卡人数据? 处理能力如何? 在用的支付应用程序 : 支付应用程序版本 : 附录 E: 实地评估遵从性证明书 服务提供商 第 57 页

59 第 3 部分 :PCI DSS 认证 根据 (date of ROC) 的 遵从性报告 ( ROC ) 结果,(QSA Name) 于 (date) 对本文档第 2 部分所确定的机构的以下遵从性状态予以确认 ( 勾选一项 ): 8 遵从性 :ROC 中的所有要求均已被标注为 到位,PCI SSC 认可的授权扫描供应商 (ASV Name) 已完成通过检查的扫描, 因此 (Service Provider Name) 证明完全遵守 PCI DSS(insert version number) 不符合 : ROC 中的某些要求被标记为 不到位, 导致在总体上获得不符合评级, 或者 PCI SSC 认可的授权扫描供应商无法完成通过性扫描, 因此 (Service Provider Name) 不能证明完全遵守 PCI DSS 达到遵从性的预定日期 : 机构如果其状态为 不符合, 在提交该表格时必须填写本文档第 4 部分中的 行动计划 在完成第 4 部分之前请咨询支付品牌, 因为不是所有的支付品牌都需要这一部分 第 3a 部分 : 遵从性状态确认 QSA 和服务提供商确认 : 根据 PCI DSS 要求和安全评估程序第 (insert version number) 版以及其中的指示填写 ROC 上述 ROV 与本证明中的所有信息在一切重要方面均完全代表本次评估的所有结果 服务提供商已阅读 PCI DSS 并确定他们将始终完全遵守 PCI DSS 9 在评估过程中, 没有证据表明交易授权后在任何检查的系统中发现有存储的磁条 ( 例如磁道 ) 数据 CAV CVC2 CID 或 CVV2 数据或 PIN 数据 第 3b 部分 : QSA 和服务提供商的确认书 主要 QSA 的签名 日期 : 主要 QSA 的名称 : 职务 : 服务提供商执行官签名 日期 : 服务提供商执行官姓名 : 职务 : 8 到位 的结果应该包括由 QSA 审查的补偿性控制 如果确定补偿性控制可充分减轻和要求相关的风险,QSA 应将要求标记为 到位 9 编译在磁条中的数据, 用于实卡交易中的授权 授权之后, 机构可能不会保留完整的磁条数据 磁道数据中可能会保留下来的仅有的要素是账号 失效期与姓名 10 印在支付卡签名方格内的三或四位数值, 用于验证无实卡交易 11 由持卡人在实卡交易时输入的个人识别码和 / 或出现在交易信息中的经加密的 PIN 数据块 附录 E: 实地评估遵从性证明书 服务提供商 第 58 页

60 第 4 部分 : 行动计划和 不符合 状态 请为每个要求选择相应的 遵从性状态 如任何要求的回答是 否, 您必须提供公司将符合要求的日期, 并简要描述为满足要求将要采取的措施 在完成第 4 部分之前请咨询支付品牌, 因为不是所有的支付品牌都需要这一部分 PCI 要求 描述 遵从性状态 ( 选择一项 ) 补救日期和措施 ( 如果遵从性状态为 否 ) 1 安装防火墙配置并予以维护, 以保护持卡人数据 是否 2 系统密码和其他安全参数不使用供应商提供的默认设置 是否 3 保护存储的持卡人数据 是否 4 在开放型的公共网络中传输持卡人数据时会加密 是否 5 使用杀毒软件并定期更新 6 开发 维护安全系统和应用程序 是否是否 7 8 只有出于业务需求的人才能访问持卡人数据 为每位拥有计算机访问权限的用户分配唯一的 ID 是否是否 9 限制对持卡人数据的物理访问 是否 10 跟踪和监控访问网络资源和持卡人数据的所有操作 是否 11 定期测试安全系统和流程 12 维护针对信息安全的政策 是否是否 附录 E: 实地评估遵从性证明书 服务提供商 第 59 页

61 附录 F: PCI DSS 检查 - 界定和选择样品 附录 F: 界定和选择样品 第 60 页