支付卡行业 (PCI) 数据安全标准 要求和安全评估程序 版 2018 年 5 月

Transcription

1 支付卡行业 (PCI) 数据安全标准 要求和安全评估程序 版 2018 年 5 月

2 文档变更记录 日期版本描述页码 2008 年 10 月 1.2 将 PCI DSS 1.2 版改称 PCI DSS 要求和安全评估程序, 以避免文档之间的重复, 并对 PCI DSS 安全审核程序 1.1 版做了综合和具体变更 如需完整信息, 请参阅 PCI DSS 1.1 版到 1.2 版的 PCI 数据安全标准变更汇总 增补 PCI DSS 1.1 版和 1.2 版之间被误删的句子 年 7 月 将测试程序 a 和 b 中的 随后 更正为 比 32 删除测试程序 6.5.b 中 到位 和 未到位 栏的灰色标记 33 在 补偿性控制工作表 - 完整示例 中, 修正页面顶部的用语, 改为 利用本工作表为通过补偿性控制备注为 到位 的任何要求定义补偿性控制 年 10 月 2013 年 11 月 2015 年 4 月 2016 年 4 月 2018 年 5 月 2.0 更新并实施 版的变更 请参阅 PCI DSS PCI DSS 版到 2.0 版的变更汇总 3.0 从 2.0 版更新 请参阅 PCI DSS PCI DSS 2.0 版到 3.0 版的变更汇总 3.1 从 PCI DSS 3.0 版更新 有关变更详情, 请参阅 PCI DSS PCI DSS 3.0 版到 3.1 版的变更汇总 3.2 从 PCI DSS 3.1 版更新 有关变更详情, 请参阅 PCI DSS PCI DSS 3.1 版到 3.2 版的变更汇总 从 PCI DSS 3.2 版更新 有关变更详情, 请参阅 PCI DSS PCI DSS 3.2 版到 版的变更汇总 确认通知 : 在所有使用目的和情况下,PCI SSC 网站上的英文文本应作为此文件的官方版本 当翻译文本和英文文本之间出现任何歧义和不一致之处时, 正确的内容应以该位置的英文文本为准 第 2 页

3 目录 文档变更记录... 2 简介和 PCI 数据安全标准概述... 6 PCI DSS 资源 7 PCI DSS 适用性信息... 8 PCI DSS 与 PA-DSS 的关系 PCI DSS 对 PA-DSS 应用程序的适用性 PCI DSS 对支付应用程序供应商的适用性 PCI DSS 要求的范围 网络分段 11 无线 12 采用第三方服务提供商 / 外包 在常规业务流程中实施 PCI DSS 的最优方法 对于评估商 : 企业设施 / 系统组件抽样 补偿性控制 遵从性报告的说明与内容 PCI DSS 评估流程 PCI DSS 版本 详细的 PCI DSS 要求和安全评估程序 建立并维护安全的网络和系统 要求 1: 安装并维护防火墙配置以保护持卡人数据 要求 2: 不要使用供应商提供的默认系统密码和其他安全参数 保护持卡人数据 33 要求 3: 保护存储的持卡人数据 第 3 页

4 要求 4: 加密持卡人数据在开放式公共网络中的传输 维护漏洞管理计划 44 要求 5: 为所有系统提供恶意软件防护并定期更新杀毒软件或程序 要求 6: 开发并维护安全的系统和应用程序 实施强效访问控制措施 要求 7: 按业务知情需要限制对持卡人数据的访问 要求 8: 识别并验证对系统组件的访问 要求 9: 限制对持卡人数据的物理访问 定期监控并测试网络 要求 10: 跟踪并监控对网络资源和持卡人数据的所有访问 要求 11: 定期测试安全系统和流程 维护信息安全政策 89 要求 12: 维护针对所有工作人员的信息安全政策 附录 A: PCI DSS 附加要求 附录 A1: 针对共享托管服务提供商的 PCI DSS 附加要求 附录 A2: 针对使用 SSL/ 早期 TLS 进行实卡 POS POI 终端连接的实体的 PCI DSS 附加要求 附录 A3: 指定实体补充认证 (DESV) 附录 B: 补偿性控制 附录 C: 补偿性控制工作表 附录 D: 网络分段与企业设施 / 系统组件抽样 第 4 页

5 第 5 页

6 简介和 PCI 数据安全标准概述 本支付卡行业数据安全标准 (PCI DSS) 旨在促进并增强持卡人的数据安全, 便于统一的数据安全措施在全球范围内的广泛应用 PCI DSS 为意在保护帐户数据的技术和操作要求提供了一个基准 PCI DSS 适用于参与支付卡处理的所有实体 包括商户 处理商 收单机构 发卡机构和服务提供商 PCI DSS 还适用于存储 处理或传输持卡人数据 (CHD) 和 / 或敏感验证数据 (SAD) 的所有其他实体 以下是对 12 条 PCI DSS 要求的主要概述 PCI 数据安全标准 主要概述 建立并维护安全的网络和系统保护持卡人数据维护漏洞管理计划实施强效访问控制措施定期监控并测试网络 1. 安装并维护防火墙配置以保护持卡人数据 2. 不要使用供应商提供的默认系统密码和其他安全参数 3. 保护存储的持卡人数据 4. 加密持卡人数据在开放式公共网络中的传输 5. 为所有系统提供恶意软件防护并定期更新杀毒软件或程序 6. 开发并维护安全的系统和应用程序 7. 按业务知情需要限制对持卡人数据的访问 8. 识别并验证对系统组件的访问 9. 限制对持卡人数据的物理访问 10. 跟踪并监控对网络资源和持卡人数据的所有访问 11. 定期测试安全系统和流程 维护信息安全政策 12. 维护针对所有工作人员的信息安全政策 本文档 PCI 数据安全标准要求和安全评估程序 将 12 条 PCI DSS 要求和相应的测试程序合并为一个安全评估工具 该工具在 PCI DSS 遵从性评估期间专门用作实体验证程序的组成部分 以下提供的详细指南和最优方法可协助实体准备 执行 PCI DSS 评估并汇报评估结果 PCI DSS 要求和测试程序自第 15 页开始 除当地 地区和行业法律法规外,PCI DSS 至少要包含一组帐户数据保护要求, 并通过制定附加控制措施和操作规程加以完善, 以进一步规避风险 另外, 立法或监管规定可能会要求对个人信息或其他数据元素 ( 例如持卡人姓名 ) 施以特殊保护 PCI DSS 不能取代当地或地区法律 政府法规或其他法律要求 第 6 页

7 PCI DSS 资源 PCI 安全标准委员会 (PCI SSC) 网站 ( 上提供有很多补充资源, 可用于协助组织完成 PCI DSS 评估和验证, 其中包括 : 文档库, 包括 : o PCI DSS PCI DSS 2.0 版到 3.0 版的变更汇总 o PCI DSS 快速参考指南 o PCI DSS 和 PA-DSS 术语 缩略词和首字母缩略词词汇表 注 : 增补信息对 PCI DSS 进行补充, 并明确规定满足 PCI DSS 要求的其他考虑因素和建议 ( 不能取代 代替或扩充 PCI DSS 或其中任何一项要求 ) o o o o o 增补信息和指南 PCI DSS 的优先方法遵从性报告 (ROC) 的报告模板和报告说明自我评估调查问卷 (SAQ) 以及 SAQ 说明和指南遵从性证明书 (AOC) 常见问题 (FAQ) 小商户网站中的 PCI PCI 培训课程和信息网络会议 合格的安全性评估商 (QSA) 和授权扫描服务商 (ASV) 列表 PTS 批准设备和 PA-DSS 认证支付应用程序列表有关这些及其他资源的信息, 请参阅 第 7 页

8 PCI DSS 适用性信息 PCI DSS 适用于参与支付卡处理的所有实体 包括商户 处理商 收单机构 发卡机构和服务提供商 PCI DSS 还适用于存储 处理或传输持卡人数据和 / 或敏感验证数据的所有其他实体 持卡人数据和敏感验证数据的定义如下 : 帐户数据 持卡人数据包括 : 敏感验证数据包括 : 主帐户 (PAN) 持卡人姓名 失效日 业务码 全磁道数据 ( 磁条数据或芯片上的等效数据 ) CAV2/CVC2/CVV2/CID PIN/PIN 数据块 主帐户是持卡人数据的决定性因素 如果持卡人姓名 业务码和 / 或失效日与 PAN 一起存储 处理或传输, 或以其他方式出现在持卡人数据环境 (CDE) 中, 则必须按照适用的 PCI DSS 要求予以保护 PCI DSS 要求适用于可存储 处理或传输帐户数据 ( 持卡人数据和 / 或敏感验证数据 ) 的组织 部分 PCI DSS 要求也可能适用于外包其支付操作或 CDE 管理的组织 1 此外, 将 CDE 或支付操作外包给第三方的组织有责任确保第三方按照适用的 PCI DSS 要求保护帐户数据 下页中的表格列举了持卡人数据和敏感验证数据的常用元素 是否允许存储各数据元素, 以及是否必须保护各数据元素 该表格的内容并非详尽无遗, 只用于列举适用于每种数据元素的不同类型的要求 1 遵循个人支付品牌遵从性计划 第 8 页

9 帐户数据 持卡人数据 敏感验证数据 2 数据元素 允许存储 按照要求 3.4 实现存储数据的不可读性 主帐户 (PAN) 是 是 持卡人姓名 是 否 业务码 是 否 失效日 是 否 全磁道数据 3 否 要求 3.2 规定不能存储 CAV2/CVC2/CVV2/CID 4 否 要求 3.2 规定不能存储 PIN/PIN 数据块 5 否 要求 3.2 规定不能存储 PCI DSS 要求 3.3 和 3.4 仅适用于 PAN 如果 PAN 与持卡人数据的其他元素一起存储, 仅 PAN 必须按照 PCI DSS 要求 3.4 实现不可读性 授权之后, 即使已加密, 也不允许存储敏感验证数据 即使环境中没有 PAN, 该规定仍适用 组织应直接联系其收单机构或个人支付品牌, 了解是否允许在授权前存储 SAD 可存储时间以及任何相关用法和保护要求 2 授权之后, 不允许存储敏感验证数据 ( 即使已加密 ) 3 磁条上的全磁道数据, 芯片或其他地方上的等效数据 4 印在支付卡正面或背面的三位或四位数值 5 数据持卡人在需要实卡交易中输入的个人识别码, 和 / 或出现在交易信息中已加密的 PIN 数据块 第 9 页

10 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 详细规定了支付应用程序必须满足的要求, 以促使客户遵守 PCI DSS 随着安全威胁持续演变, 不再受供应商支持的应用程序 ( 例如, 被供应商识别为 生命周期结束 的应用程序 ) 可能不具有与受支持版本相同的安全级别 在符合 PCI DSS 的环境中使用安全支付应用程序, 可最大限度减少潜在的安全漏洞, 从而防止 PAN 全磁道数据 卡片验证码与验证值 (CAV2 CID CVC2 CVV2) PIN 和 PIN 数据块遭受威胁并避免因安全漏洞所造成的严重欺诈行为 要确定 PA-DSS 是否适用于指定的支付应用程序, 请参阅 PA-DSS 程序指南, 该 指南 可在 上获取 PCI DSS 对支付应用程序供应商的适用性 如果支付应用程序供应商可存储 处理或传输持卡人数据, 或有权访问其客户的持卡人数据 ( 例如充当服务提供商的角色 ), 则 PCI DSS 可适用于该供应商 第 10 页

11 PCI DSS 要求的范围 本 PCI DSS 安全要求适用于持卡人数据环境中包含或与之连接的所有系统组件 持卡人数据环境 (CDE) 包含存储 处理 或传输持卡人数据或敏感验证数据的人员 流程和技术 系统组件 包括网络设备 服务器 计算设备和应用程序 系统组件示例包括但不限于 : 提供安全服务 ( 例如验证服务器 ) 方便分段 ( 例如内部防火墙 ) 或可能影响 CDE 安全性 ( 例如名称解析或 Web 跳转服务器 ) 的系统 虚拟化组件, 例如虚拟机 虚拟交换机 / 路由器 虚拟设备 虚拟应用程序 / 桌面和监控程序 网络组件, 包括但不限于防火墙 交换机 路由器 无线接入点 网络设备和其他安全设备 服务器类型, 包括但不限于 Web 应用程序 数据库 验证 邮件 代理 网络时间协议 (NTP) 和域名系统 (DNS) 应用程序, 包括所有购买和自定义的应用程序以及内部和外部 ( 例如互联网 ) 应用程序 位于 CDE 内或连接到 CDE 的任何其他组件或设备 PCI DSS 评估的第一步是准确确定审核范围 评估至少每年进行一次, 接受评估的实体应在年度评估前确认持卡人数据的所有位置和数据流, 并确认所有系统均连接到 CDE, 或者在其受到威胁时能够影响 CDE( 例如验证服务器 ), 以便确认实体 PCI DSS 范围的准确性, 从而确保它们包含在 PCI DSS 范围内 应将所有系统类型和位置视为范围界定流程的一部分, 包括备份 / 恢复站点和故障转移系统 若要确认被拒 CDE 的准确性, 请执行以下操作 : 接受评估的实体查找并记录其环境中存在的所有持卡人数据, 确认所有持卡人数据均包含在当前规定的 CDE 之内 在确定并记录持卡人数据的所有位置后, 实体可利用相关结果确认 PCI DSS 的范围是否适宜 ( 例如, 结果可能是一个关于持卡人数据位置的图表或目录 ) 实体应考虑任何属于 PCI DSS 评估范围和 CDE 组成部分的持卡人数据 如果实体发现当前未纳入 CDE 的数据, 应将这些数据安全地删除 迁移到当前规定的 CDE 内, 或重新界定 CDE 以纳入该数据 实体将保留有关说明如何确定 PCI DSS 范围的文档记录 这些文档记录留待评估商审核以及 / 或留作下一次年度 PCI DSS 范围确认活动的参考 针对每项 PCI DSS 评估, 评估商须验证已正确定义并记录了评估范围 网络分段 持卡人数据环境的网络分段或将持卡人数据环境与实体网络的剩余部分隔离 ( 分段 ) 并非 PCI DSS 的一项要求 但这种方法值得大力推荐, 因为它可以 : 缩小 PCI DSS 的评估范围 减少 PCI DSS 的评估费用 第 11 页

12 降低实施和维护 PCI DSS 控制的成本和难度 降低组织面临的风险 ( 通过将持卡人数据合并到更少 更易控制的位置来降低风险 ) 如果没有足够的网络分段 ( 有时也称为 扁平网络 ), 则整个网络均属于 PCI DSS 的评估范围 网络分段可通过若干物理或逻辑方法来实现, 例如正确配置的内部网络防火墙 带有严格访问控制列表的路由器或其他限制访问特定网络分段的技术 如果被视为不属于 PCI DSS 的评估范围, 则系统组件必须与 CDE 正确隔离 ( 分段 ), 这样即便该范围外系统组件受到威胁, 也无法影响 CDE 的安全性 要缩小持卡人数据环境的范围需满足一个重要的前提条件, 即清楚了解与持卡人数据的存储 处理或传输有关的业务需求和流程 通过消除不必要的数据和合并必要的数据将持卡人数据尽量限制在少数几个位置, 这可能需要对长期业务实践进行重建 通过数据流程图记录持卡人数据流有助于全面了解所有的持卡人数据流, 并确保任意网络分段在隔离持卡人数据环境时均有效 如果已设置网络分段并将其用于缩小 PCI DSS 的评估范围, 则评估商必须确认该分段足以缩小评估范围 处于高层级时, 充足的网络分段可将存储 处理或传输持卡人数据的系统与其他无法执行此类操作的系统隔离开来 然而, 就具体实施的网络分段而言, 其充足性非常多变并且取决于多种因素, 例如特定网络的配置 部署的技术以及可能已实施的其他控制措施 附录 D: 网络分段与企业设施 / 系统组件抽样提供了更多关于网络分段和抽样对 PCI DSS 评估范围所产生影响的信息 无线 如果采用无线技术存储 处理或传输持卡人数据 ( 例如销售点交易 快速结帐 ), 或者如果无线局域网 (WLAN) 是持卡人数据环境的一部分或与之连接, 则面向无线环境的 PCI DSS 要求和测试程序适用且必须执行 ( 例如要求 和 4.1.1) 在实施无线技术前, 实体应根据风险认真评估该技术的必要性 仅针对非敏感数据传输考虑部署无线技术 采用第三方服务提供商 / 外包 服务提供商或商户可通过第三方服务提供商代为存储 处理或传输持卡人数据, 或管理路由器 防火墙 数据库 物理安全和 / 或服务器等组件 在此情况下, 持卡人数据环境的安全性可能会受影响 各方应清楚确定服务提供商的 PCI DSS 评估范围内所包含的服务和系统组件 服务提供商规定的具体 PCI DSS 要求以及服务提供商的客户有责任纳入各自 PCI DSS 审核的任何要求 例如, 托管服务提供商应明确规定哪些 IP 地址应作为其季度安全漏洞扫描过程的一部分进行扫描, 哪些 IP 地址应由客户负责纳入各自的季度扫描 服务提供商负责证明自己遵守了 PCI DSS 的要求, 并且可能会应支付品牌的要求这么做 服务提供商应联系其收单机构和 / 或支付品牌, 以确定遵从性验证适用 第三方服务提供商验证遵从性时有两种选择 : 第 12 页

13 1) 年度评估 : 服务提供商可自行实施年度 PCI DSS 评估, 并向客户提供证据证明其遵从性 ; 或者 2) 多重按需评估 : 如果服务提供商不自行实施年度 PCI DSS 评估, 则须应客户要求实施评估, 并 / 或参加每个客户的 PCI DSS 审核, 并将每项审核结果提供给相应的客户 如果第三方自行接受 PCI DSS 评估, 则应向客户提供充分证据, 证明该服务提供商的 PCI DSS 评估范围涵盖客户适用的服务, 且相关 PCI DSS 要求已检查完毕并认定现已到位 服务提供商向客户提供的具体证据类型将取决于双方的现有协议 / 合同 例如, 提供 AOC 和 / 或服务提供商 ROC( 为保护任何机密信息而编写 ) 的相关部分有助于提供全部或部分信息 此外, 商户和服务提供商必须管理并监督所有有权访问持卡人数据的相关第三方服务提供商的 PCI DSS 遵从性 请参阅本文档中的要求 12.8 了解详情 第 13 页

14 在常规业务流程中实施 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) 如果发现这些技术未继续获得供应商的支持或不能满足实体的安全需求, 实体则应制定补救方案 更新或者甚至在必要时替换该技术 除上述实践外, 组织可能还想考虑对其安全职能部门实施职责分离, 以便将安全和 / 或审核职能部门从业务职能部门中分离出去 在一人负责多角 ( 例如管理和安全操作 ) 的环境中, 可分配职责, 这样便能确保在没有独立检查点时无人具备端对端的流程控制 例如, 配置职责和变更审批职责可以分配给不同的人员 第 14 页

15 注 : 对一些实体而言, 这些最优方法同时也是确保持续遵从 PCI DSS 的要求 例如,PCI DSS 将这些原则纳入到一些要求之中, 并且指定实体补充认证 (PCI DSS 附录 A3) 要求指定实体对这些原则进行验证 所有组织均应考虑将这些最优做法实施到其环境中, 即使在组织无需对其进行验证时也是如此 第 15 页

16 对于评估商 : 企业设施 / 系统组件抽样 如果企业设施和 / 或系统组件的数量很多, 评估商可选择采取抽样的方式简化评估流程 虽然可接受评估商对企业设施 / 系统组件进行抽样以作为实体 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 流程和控制, 以及 请同时参阅 : 附录 D: 网络分段与企业设施 / 系统组件抽样 解释样本适宜且在整体中具有代表性的原因 评估商必须在每次评估中重复验证抽样依据 如果要采用抽样法, 必须为每次评估选择不同的企业设施和系统组件样本 第 16 页

17 补偿性控制 评估商每年均须记录 审核和验证补偿性控制一次, 并同时提交遵从性报告, 具体遵照附录 B: 补偿性控制 和附录 C: 补偿性控制工作表 对于每项补偿性控制, 必须填写 补偿性控制工作表 ( 附录 C) 此外, 应在遵从性报告相应的 PCI DSS 要求栏内记录补偿性控制结果 如需了解更多关于 补偿性控制 的详情, 请参阅上述附录 B 和 C 第 17 页

18 遵从性报告的说明与内容 PCI DSS ROC 报告模板中提供有遵从性报告 (ROC) 的说明与内容 必须使用 PCI DSS ROC 报告模板作为创建遵从性报告的模板 接受评估的实体应遵守每个支付品牌各自的报告要求, 以确保各支付品牌确认实体的遵从状态 请与各支付品牌或收单机构联系, 确定报告要求和说明 PCI DSS 评估流程 PCI DSS 评估流程包括完成以下步骤 : 1. 确认 PCI DSS 的评估范围 2. 根据每项要求的测试程序执行环境 PCI DSS 评估 3. 根据适用的 PCI 指南和说明, 完成适用的评估报告 ( 即自我评估调查问卷 (SAQ) 或遵从性报告 (ROC)), 包括所有补偿性控制文档记录 4. 如果适用, 完成服务提供商或商户的遵从性证明书 遵从性证明书可从 PCI SSC 网站获取 5. 向收单机构 ( 商户 ) 支付品牌或其他申请机构 ( 服务提供商 ) 提交 SAQ 或 ROC 遵从性证明书以及任何其他要求的文档记录 ( 例如 ASV 扫描报告 ) 6. 如果需要, 请采取补救措施以处理不适用的要求, 并提供更新的报告 第 18 页

19 PCI DSS 版本 PCI DSS 3.2 版自本文档发布之日起生效, 有效期至 2018 年 12 月 31 日 ( 该日过后此版本将失效 ) 该日之后的所有 PCI DSS 验证均须针对 版或更高版本进行 下表提供了 PCI DSS 的版本汇总及相关日期 6 版本发布日期失效日期 PCI DSS 版 ( 本文档 ) 2018 年 5 月待定 PCI DSS 3.2 版 2016 年 4 月 2018 年 12 月 31 日 6 随新版本 PCI DSS 的发布随时变更 第 19 页

20 详细的 PCI DSS 要求和安全评估程序 以下提供了 PCI DSS 要求和安全评估程序 列标题的定义 : PCI DSS 要求 此列定义数据安全标准要求 ;PCI DSS 遵从性根据这些要求进行验证 测试程序 此列展示评估商用来验证 PCI DSS 要求是否满足且 到位 的流程 指南 此列说明每项 PCI DSS 要求的目的或安全目标 本列只包含指南, 旨在帮助读者理解每项要求的目的 本列中的指南并不替代或扩充 PCI DSS 要求和测试程序 注 : 如果未实施或计划在将来某个日期完成控制, 则认为 PCI DSS 要求不到位 在实体纠正任何未完成或不到位的项目后, 评估商会重新进行评估以验证是否完成纠正且满足所有要求 请参阅以下资源 ( 位于 PCI SSC 网站 ), 记录 PCI DSS 评估 : 有关完成遵从性报告 (ROC) 的说明, 请参阅 PCI DSS ROC 报告模板 有关填写自我评估调查问卷 (SAQ) 的说明, 请参阅 PCI DSS SAQ 说明和指南 有关提交 PCI DSS 遵从性验证报告的说明, 请参阅 PCI DSS 遵从性证明书 第 20 页

21 建立并维护安全的网络和系统 要求 1: 安装并维护防火墙配置以保护持卡人数据 防火墙是一种设备, 可以控制实体网络 ( 内部 ) 和不可信网络 ( 外部 ) 之间允许的计算机访问流量以及实体内部可信网络中较敏感区域的输入和输出流量 例如, 持卡人数据环境就是实体可信网络中的较敏感区域 防火墙会检查所有网络流量并阻止不符合指定安全标准的传输 无论是以电子商务方式通过互联网访问 员工经桌面浏览器访问互联网 员工电子邮件访问 专用连接 ( 例如企业对企业连接 ) 还是通过无线网络或其他来源进入系统, 都应避免任何系统受到来自不可信网络的非授权访问 通常, 连接到不可信网络和来自其的看似不显眼的路径会使关键系统遭受无保护的访问 防火墙是任何计算机网络的关键防护机制 只要符合要求 1 中规定的防火墙最低要求, 其他系统组件也能提供防火墙功能 如果在持卡人数据环境中使用其他系统组件来提供防火墙功能, 则这些设备必须纳入要求 1 的范围和评估中 1.1 建立并实施包含以下内容的防火墙和路由器配置标准 : 批准和测试所有网络连接以及防火墙和路由器配置变更的正式流程 识别持卡人数据环境和其他网络 ( 包括任何无线网络 ) 间所有连接的当 1.1 检查防火墙和路由器配置标准以及以下指定的其他文档记录, 并确认已按如下方式完成并实施这些标准 : a 检查书面程序, 确认存在测试和批准以下所有内容的正式流程 : 网络连接以及 防火墙和路由器配置变更 b 针对网络连接样本, 与负责人员面谈并检查记录, 确认网络连接已得到批准和测试 c 确定防火墙和路由器配置的实际变更样本, 将其与变更记录对比并与责任工作人员面谈, 以确认变更已得到批准和测试 a 检查图表并查看网络配置, 确认存在当前网络图且该图记录了持卡人数据的所有连接 ( 包括任何无线网络 ) 防火墙和路由器是控制网络输入和输出的架构的关键组件 是阻止非法访问并管理授权访问和退出网络的软硬件设备 配置标准和程序有助于确保组织的第一道数据防线始终强大 用于批准和测试所有连接以及防火墙和路由器变更的已记录和实施的流程有助于避免因网络 路由器或防火墙的错误配置导致的安全问题 如果不正式批准和测试变更, 变更记录可能无法得到更新, 从而导致网络文档记录和实际配置不一致 网络图说明了网络的配置方法, 并标识出所有网络设备的位置 第 21 页

22 前网络图 b 与负责人员面谈, 确认图表为最新 如果没有当前网络图, 设备可能遭到忽略并在无意 中被排除在对 PCI DSS 实施的安全控制之外, 因 而容易受到威胁 显示整个系统和网络中所有持卡人数据流的当前图表 各互联网连接以及任何非军事区 (DMZ) 和内部网络区域间的防火墙要求 网络组件管理群组 角色与责任的说明 使用所有获准服务 协议和端口的业务理由和许可文档记录, 包括对非安全协议实施安全功能的文档记录 检查数据流程图并与工作人员面谈, 确认图表 : 显示整个系统和网络中所有持卡人数据流 为最新且在出现环境变更时根据需要更新 a 检查防火墙配置标准, 并确认其包含针对位于各互联网连接处以及任何 DMZ 和内部网络区域间的防火墙的要求 b 确认当前网络图与防火墙配置标准一致 c 根据所记录的配置标准和网络图, 查看网络配置, 确认各互联网连接的防火墙以及任何非军事区 (DMZ) 和内部网络区域间的防火墙均已到位 a 确认防火墙和路由器配置标准包括网络组件管理群组 角色与责任的说明 b 与网络组件管理的负责人员面谈, 确认已根据文档记录分配角色与责任 a 确认防火墙和路由器配置标准包含所有服务 协议和端口的文档记录列表 ( 包括各自的业务理由和许可 ) b 识别获准的非安全服务 协议和端口 ; 确认已记录每个服务的安全功能 c 检查防火墙和路由器配置, 确认已对每个非安全服务 协议和端口实施有文档记录的安全功能 持卡人数据流程图标识出在网络中存储 处理或传输的所有持卡人数据的位置 网络和持卡人数据流程图通过显示持卡人数据在网络间以及单个系统和设备间的流动方式, 帮助组织了解并跟踪其环境的范围 通过在进入 ( 和退出 ) 网络的每个互联网连接以及任何 DMZ 和内部网络间使用防火墙, 组织可监控和控制访问并将恶意个人通过不受保护的连接访问内部网络的机率降到最低 角色说明和责任分配可确保工作人员知道所有网络组件的安全负责人, 并且组件指定管理人员了解自己的责任 如果角色与责任未进行正式分配, 则设备可能无人管理 威胁通常由不用或非安全的服务和端口导致, 这是因为此类服务和端口一般都存在已知的漏洞而很多组织不会修补不用服务 协议和端口的漏洞 ( 即使漏洞仍然存在 ) 通过明确界定和记录对业务所需的服务 协议和端口, 组织可确保禁用或删除所有其他服务 协议和端口 应由不受配置管理工作人员约束的工作人员授予许可 如果业务需要用到非安全的服务 协议或端口, 则组织应清楚了解并接受使用这些协议会带来的风险, 使用协议应有正当的理由, 且应记录并实施允许安全使用这些协议的安全功能 如果业务不需要用到这些非安全的服务 协议或端口, 则应加以禁 第 22 页

23 用或删除 有关服务或被视为不安全的端口的指南, 请参阅行业标准和指南 ( 例如,NIST ENISA OWASP 等 ) 审核防火墙和路由器规则集 ( 至少每半年一次 ) 的要求 1.2 构建防火墙和路由器配置, 以限制不可信网络与持卡人数据环境中任意系统组件之间连接 注 : 不可信网络 是指受审核实体所属网络之外的网络, 和 / 或不受实体控制或管理的网络 将输入和输出流量限制到持卡人数据环境所需的范围, 并明确拒绝所有其他流量 a 确认防火墙和路由器配置标准规定至少每半年审核一次防火墙和路由器规则集 b 检查与规则集审核相关的文档记录并与负责人员面谈, 确认至少每半年审核一次规则集 1.2 检查防火墙和路由器配置并执行以下操作, 确认不可信网络与持卡人数据环境中系统组件间的连接受限 a 检查防火墙和路由器配置标准, 确认其规定了持卡人数据环境所需的输入和输出流量 b 检查防火墙和路由器配置, 确认输入和输出流量限制在持卡人数据环境所需的范围 c 检查防火墙和路由器配置, 确认已明确拒绝所有其他输入和输出流量, 例如, 使用明确的 拒绝所有 或在允许声明后含蓄地表达拒绝之意 通过该审核, 组织能至少每半年清除一次不需要 过时或错误的规则, 并确保所有规则集只允许使用与有文档记录的业务理由相符的授权服务和端口 防火墙和路由器规则集出现大量变更的组织会希望通过实施更频繁的审核来确保规则集继续满足业务需要 在内部可信网络以及任何外部和 / 或不受实体控制或管理的不可信网络之间安装网络防护很重要 如果无法正确实施本措施, 实体将容易遭受恶意个人或软件的非授权访问 要使防火墙功能生效, 则必须进行正确配置, 从而控制和 / 或限制进出实体网络的流量 通过检查所有入站和出站连接, 可根据源地址和 / 或目标地址检查并限制流量, 从而避免不可信和可信环境之间未过滤的访问 这样可以防止恶意个人通过非授权的 IP 地址访问实体网络, 或以非授权的方式使用服务 协议或端口 ( 例如, 将从实体网络中获取的数据发送到不可信服务器 ) 实施规则以拒绝任何非特别所需的输入和输出流量有助于避免因疏忽造成的漏洞, 防止输入或输出意料之外和可能有害的流量 第 23 页

24 1.2.2 保护并同步路由器配置文件 a 检查路由器配置文件, 确认其不会遭受非授权访问 当运行 ( 或活动 ) 中的路由器配置文件包含当前安 b 检查路由器配置并确认其已同步, 例如, 运行 ( 或活动 ) 配置与启动配置 ( 启动电脑时使用 ) 匹配 全设置时, 启动文件 ( 重启或启动路由器时使用 ) 必须更新为相同的安全设置, 才能确保在启动配置运行时应用这些设置 由于启动配置文件只是偶尔运行, 因此通常会被遗忘且不进行更新 当路由器重启并且加载的启动配置未更新为与运行配置相同的安全设置时, 可能会导致规则减弱, 进而允许恶意个人访问网络 在所有无线网络和持卡人数据环境间安装外围防火墙, 并配置这些防火墙以拒绝流量或 ( 如果业务需要流量 ) 仅允许无线环境和持卡人数据环境间的授权流量 1.3 禁止互联网与持卡人数据环境中任何系统组件之间的直接公共访问 实施 DMZ, 仅向提供授权服务 协议和端口 ( 支持公共访问 ) 的系统组件输入流量 仅向 DMZ 内的 IP 地址输入互联网流量 a 检查防火墙和路由器配置, 确认所有无线网络和持卡人数据环境间均已安装外围防火墙 b 确认防火墙拒绝流量或 ( 如果业务需要流量 ) 仅允许无线环境和持卡人数据环境间的授权流量 1.3 检查防火墙和路由器配置 ( 包括但不限于互联网中的阻塞路由器 DMZ 路由器和防火墙 DMZ 持卡人分段 外围路由器以及内部持卡人网段 ) 并执行以下操作以确定互联网和内部持卡人网段中的系统组件之间并无直接访问 : 检查防火墙和路由器配置, 确认已实施 DMZ 以仅向提供授权服务 协议和端口 ( 支持公共访问 ) 的系统组件输入流量 检查防火墙和路由器配置, 确认仅向 DMZ 内的 IP 地址输入互联网流量 采用已知 ( 或未知 ) 的方法来执行和利用网络中的无线技术是恶意个人访问网络和持卡人数据的常用方法 如果在实体不知情时安装了无线设备或网络, 则恶意个人可 悄无声息 地轻松进入网络 如果防火墙不限制无线网络对 CDE 的访问, 则非授权访问无线网络的恶意个人可轻松连接到 CDE 并威胁帐户信息的安全性 无论无线网络连接到的环境有何用途, 所有无线网络和 CDE 之间都必须安装防火墙 其中包括但不限于公司网络 零售店 客户网络 仓库环境等 虽然可能存在允许 DMZ 系统使用不可信连接 ( 例如, 允许公共访问网络服务器 ) 的正当理由, 但此类连接应永不授予内部网络中的系统 防火墙主要用于管理并控制公共系统和内部系统 ( 特别是存储 处理或传输持卡人数据的系统 ) 之间的所有连接 如果允许公共系统和 CDE 之间进行直接访问, 则恶意个人会跳过防火墙提供的保护, 并使存储持卡人数据的系统组件受到威胁 DMZ 属于网络的一部分, 管理着互联网 ( 或其他不可信网络 ) 与组织需向公众提供的服务 ( 如 web 服务器 ) 之间的连接 该功能旨在阻止恶意个人通过互联网访问组织的内部网络或以非授权的方式使用服务 协议或端口 第 24 页

25 1.3.3 实施反欺骗措施以检测并阻止伪造的源 IP 地址进入网络 ( 例如, 阻止带内部源地址的互联网流量 ) 禁止从持卡人数据环境到互联网的非授权出站流量 检查防火墙和路由器配置, 确认已实施反欺骗措施, 例如内部地址无法从互联网进入 DMZ 检查防火墙和路由器配置, 确认从持卡人数据环境输出到互联网的流量有明确授权 通常, 数据包包含最初发送它的计算机的 IP 地址, 因此网络中的其他计算机知道数据包的来源 恶意个人经常会试图假冒 ( 或模仿 ) 发送的 IP 地址, 以使目标系统相信数据包来自可信来源 过滤进入网络的数据包的作用之一是确保数据包不会遭到 假冒, 而看似来自组织自身内部的网络 从持卡人数据环境输出的所有流量都应进行评估以确保其遵守已制定和授权的规则 应检查连接, 仅允许授权通信的流量 ( 例如, 通过限制源 / 目标地址 / 端口, 和 / 或阻止内容 ) 仅允许 已建立 连接进入网络 将存储持卡人数据的系统组件 ( 例如 : 数据库 ) 放置在与 DMZ 以及其他不可信网络隔离的内部网络区域中 检查防火墙和路由器配置, 确认防火墙仅允许已建立连接进入内部网络, 并拒绝未与之前建立的会话相关联的任何入站连接 检查防火墙和路由器配置, 确认存储持卡人数据的系统组件放置在与 DMZ 以及其他不可信网络隔离的内部网络区域中 通过维持经过防火墙的每个连接的 状态 ( 或称现状 ), 防火墙可知道对之前连接作出的明显响应是有效的授权响应 ( 因为防火墙会保存每个连接的状态 ) 还是尝试骗取防火墙连接许可的恶意流量 如果持卡人数据位于 DMZ 中, 则外部攻击者更容易访问此信息, 这是因为要穿透的层数更少 存储持卡人数据的系统组件应放置于通过防火墙与 DMZ 以及其他不可信网络隔离的内部网络区域中, 以防止非授权网络流量到达系统组件 注 : 本要求不适用于易失性存储器中暂时存储的持卡人数据 第 25 页

26 1.3.7 不要将私人 IP 地址和路由信息泄露给非授权方 注 : 掩盖 IP 地址的方法包括但不限于 : 网络地址转换 (NAT) 将包含持卡人数据的服务器放置在代理服务器 / 防火墙中, 删除或过滤针对采用注册地址的专用网络的路由器广告, 在内部使用 RFC1918 地址空间而非注册地址 a 检查防火墙和路由器配置, 确认防止私人 IP 地址和路由信息从内部网络泄漏到互联网的方法到位 b 与工作人员面谈并检查文档记录, 确认针对外部实体的任何私人 IP 地址和路由信息的披露都经过授权 限制内部或私人 IP 地址的泄漏对于防止黑客 得知 内部网络的 IP 地址并使用该信息访问网络很关键 根据所使用的特定网络技术, 可采用不同的方法来实现本要求的目的 例如,IPv4 和 IPv6 网络可使用不同的控制措施来满足本要求 1.4 在可在网络外连接互联网且可用于访问 CDE 的任何便携式计算设备 ( 包括公司和 / 或员工所有的便携式计算设备, 例如, 员工使用的笔记本电脑 ) 上安装个人防火墙软件或等效功能 防火墙 ( 或等效功能 ) 配置包括 : 定义了具体的配置设备 个人防火墙 ( 或等效功能 ) 正在活跃运行 便携式计算设备用户无法更改个人防火墙 ( 或等效功能 ) 1.5 确保用于防火墙管理的安全政策和操作程序已记录 使用, 并为所有相关方所了解 1.4.a 检查政策和配置标准, 确认 : 可在网络外部连接互联网且可用于访问 CDE 的所有便携式计算设备 ( 包括公司和 / 或员工所有的便携式计算设备, 例如, 员工使用的笔记本电脑 ) 均需配备个人防火墙软件或等效功能 已为个人防火墙 ( 或等效功能 ) 定义了具体的配置设备 已配置个人防火墙 ( 或等效功能 ), 以便其活跃运行 个人防火墙 ( 或等效功能 ) 已配置为不允许便携式计算设备用户进行更改 1.4.b 检查公司和 / 或员工所有设备的样本, 验证 : 个人防火墙 ( 或等效功能 ) 已根据组织的具体配置设置进行安装和配置 个人防火墙 ( 或等效功能 ) 正在活跃运行 便携式计算设备用户无法更改个人防火墙 ( 或等效功能 ) 1.5 检查文档记录并与工作人员面谈, 确认用于防火墙管理的安全政策和操作程序 : 已记录 使用, 并 为所有相关方所了解 允许从公司防火墙外部连接互联网的便携式计算设备更易遭受基于互联网的威胁 使用防火墙功能 ( 例如, 个人防火墙软件或硬件 ) 有助于防止设备遭受基于互联网的攻击, 一旦设备重新连接网络, 这类攻击便可利用来访问组织的系统和数据 由组织确定具体的防火墙配置设置 注 : 本要求适用于员工自有和公司所有的便携式计算设备 无法通过公司政策管理的系统会带来外围漏洞并为恶意个人提供可利用的机会 允许不可信系统连接组织的 CDE 可导致向攻击者和其他恶意用户授予访问权限 工作人员需了解并遵守安全政策和操作程序, 确保始终对防火墙和路由器进行管理, 从而防止对网络的非授权访问 第 26 页

27 要求 2: 不要使用供应商提供的默认系统密码和其他安全参数 恶意个人 ( 实体的外部和内部 ) 经常使用供应商默认密码和其他供应商默认设置来威胁系统安全 黑客团体十分了解并可通过公共信息轻松确定这些密码和设置 2.1 始终更改供应商提供的默认值并于在网络中安装系统之前删除或禁用不必要的默认帐户 此要求适用于所有默认密码, 包括但不限于操作系统 提供安全服务的软件 应用程序和系统帐户 销售点 (POS) 终端 支付应用程序 简单网络管理协议 (SNMP) 社区字符串等使用的默认密码 对于连接到持卡人数据环境或传输持卡人数据的无线环境, 在安装时更改所有无线供应商的默认值, 包括但不限于默认的无线密钥 密码和 SNMP 社区字符串 2.1.a 选择系统组件样本并尝试使用供应商提供的默认帐户和密码登录 ( 在系统管理员的帮助下 ) 设备和应用程序, 以确认所有默认密码 ( 包括操作系统 提供安全服务的软件 应用程序和系统帐户 POS 终端以及简单网络管理协议 (SNMP) 社区字符串使用的默认密码 ) 均已修改 ( 使用供应商手册和互联网资源找到供应商提供的帐户 / 密码 ) 2.1.b 针对系统组件样本, 确认所有不必要的默认帐户 ( 包括操作系统 安全软件 应用程序 系统 POS 终端 SNMP 等使用的帐户 ) 均已删除或禁用 2.1.c 与工作人员面谈并检查支持文档记录, 确认 : 在网络中安装系统前, 已更改所有供应商默认值 ( 包括操作系统 提供安全服务的软件 应用程序和系统帐户 POS 终端 简单网络管理协议 (SNMP) 社区字符串等使用的默认密码 ) 在网络中安装系统之前, 所有不必要的默认帐户 ( 包括操作系统 安全软件 应用程序 系统 POS 终端 SNMP 等使用的帐户 ) 均已删除或禁用 a 与负责人员面谈并检查支持文档记录, 确认 : 密钥默认值在安装时已更改 知道密钥的任何人离职或更换岗位时即更改密钥 b 与工作人员面谈并检查政策和程序, 确认 : 默认的 SNMP 社区字符串必须在安装时更改 访问点的默认密码 / 口令必须在安装时更改 c 在系统管理员的帮助下检查供应商文档记录并登录无线设备, 确认 : 未使用默认的 SNMP 社区字符串 恶意个人 ( 组织外部和内部 ) 经常使用供应商默认设置 帐户名和密码来破坏操作系统软件 应用程序以及安装这些软件和程序的系统 由于这些默认设置通常会对外发布且黑客团体对此十分了解, 因此更改这些设置会降低系统受到攻击的可能性 即使不打算使用默认帐户, 将默认密码修改为独一无二的强效密码并禁用帐户也能防止恶意个人重新启用帐户, 并用默认密码进行访问 如果无线网络未实施充分的安全配置 ( 包括更改默认设置 ), 则无线嗅探器可窃听流量 轻松捕获数据和密码并轻易进入并攻击网络 另外, 用于旧版本 x 加密 ( 有线等效加密或 WEP) 的关键交换协议已失效且会导致加密无效 应更新设备固件以支持更多安全协议 第 27 页

28 未使用访问点的默认密码 / 口令 d 检查供应商文档记录并查看无线配置设置, 确认已更新无线设备的固件以支持以下操作的强效加密 : 无线网络验证 无线网络传输 e 检查供应商文档记录并查看无线配置设置, 确认其他与安全有关的无线供应商默认值均已更改 ( 如果适用 ) 第 28 页

29 2.2 制定适合所有系统组件的配置标准 确保这些标准能解决所有已知的安全漏洞并与行业认可的系统强化标准一致 行业认可的系统强化标准来源包括但不限于 : 互联网安全中心 (CIS) 国际标准化组织 (ISO) 美国系统网络安全协会 (SANS) 国家标准与技术研究所 (NIST) 2.2.a 检查组织所有类型系统组件的系统配置标准, 确认系统配置标准与行业认可的系统强化标准一致 2.2.b 检查政策并与工作人员面谈, 确认在识别新的安全漏洞问题时系统配置标准已经更新, 具体规定请参阅要求 c 检查政策并与工作人员面谈, 确认在配置新系统时已应用系统配置标准并且在网络上安装系统前已确认到位 2.2.d 确认系统配置标准包含以下适合所有类型系统组件的程序 : 更改供应商提供的所有默认值, 并清除非必要的默认帐户 每台服务器仅执行一项主要功能, 以防需要不同安全级别的功能并存于同一台服务器上 仅启用系统功能所需的必要服务 协议 守护进程等 对于任何被视为不安全的必要服务 协议或守护进程, 均执行附加安全功能 配置系统安全参数, 以防滥用 删除所有非必要功能, 例如脚本 驱动程序 特性 子系统 文件系统和不必要的网络服务器 很多操作系统 数据库和企业应用程序都存在已知的漏洞, 同时也拥有已知的方法可用于配置这些系统, 从而修补安全漏洞 为帮助非安全专家人士, 很多安全组织提出了系统强化指南和建议, 就如何修复此类漏洞提供指导建议 有关配置标准的指南来源包括但不限于 : 和产品供应商 系统配置标准必须保持最新, 以确保在网络上安装系统前已修复新发现的漏洞 第 29 页

30 2.2.1 每台服务器仅执行一项主要功能, 以防需要不同安全级别的功能并存于同一台服务器上 ( 例如 Web 服务器 数据库服务器和 DNS 均应在单独的服务器上执行 ) 注 : 如果使用虚拟化技术, 每个虚拟系统组件仅执行一项主要功能 仅启用系统功能所需的必要服务 协议 守护进程等 针对任何被视为不安全的必要服务 协议或守护进程实施附加安全功能 a 选择系统组件样本, 并检查系统配置, 以确认每台服务器仅实施一项主要功能 b 如果采用虚拟化技术, 检查系统配置, 确认每个虚拟系统组件或设备仅执行一项主要功能 a 选择系统组件样本, 并检查已启用的系统服务 守护进程和协议, 以确认仅启用必要的服务或协议 b 找出任何已启用的不安全服务 守护进程或协议, 并与工作人员面谈, 确认已根据书面配置标准判断其实属合理 检查配置设置, 确认已针对所有不安全的服务 守护进程或协议记录并执行安全功能 如果需要不同安全级别的服务器功能位于同一台服务器上, 由于存在安全性较低的功能, 需要较高安全性的功能其安全级别将因此而降低 此外, 安全级别较低的服务器功能可能会给同一台服务器上的其他功能带来安全漏洞 作为系统配置标准和相关流程的一部分, 通过考虑不同服务器功能的安全需求, 组织可以确保需要不同安全级别的功能不会并存于同一台服务器上 正如要求 所述, 企业需要 ( 或已通过默认值启用 ) 的很多协议常被恶意个人利用, 对网络造成威胁 纳入本要求以作为组织配置标准和相关流程的一部分可确保仅启用必要的服务和协议 在部署新服务器前启用安全功能将防止服务器被安装在具有不安全配置的环境中 确保所有不安全的服务 协议和守护进程均通过相应的安全功能得到充分的安全保护, 令恶意个人更难以利用网络内常用的威胁点 有关强效加密法和安全协议 ( 例如,NIST SP 和 SP OWASP 等 ) 的信息, 请参阅行业标准和最优方法 注 :SSL/ 早期 TLS 不视为强效加密法, 不得用作安全控制, 但对于已证实不易受已知漏洞影响的 POS POI 终端及其连接到的终端点 ( 如附录 A2 中所规定 ) 例外 配置系统安全参数, 以防滥用 a 与系统管理员和 / 或安全经理面谈, 确认其了解系统组件的常用安全参数设置 b 检查系统配置标准, 确认其中包含常用的安全参数设置 系统配置标准和相关流程应特别针对常用安全设置和参数 ( 对使用中的每类系统具有已知的安全影响 ) 为实现安全的系统配置, 负责配置和 / 或系统管理的工作人员必须了解适用于该系统的具体安全参数和设置 c 选择系统组件样本, 并检查常见的安全参数, 确认已按照配置标准对其进行适当设置 删除所有非必要功能, 例如脚 a 选择系统组件样本, 并检查配置, 确认所有非必非必要功能可为恶意个人提供更多访问系统的机会 在 第 30 页

31 本 驱动程序 特性 子系统 文件系统和不必要的 Web 服务器 要功能 ( 例如, 脚本 驱动程序 特性 子系统 文件系统等 ) 均已删除 b. 检查文档记录和安全参数, 确认已启用的功能具有文档记录并且支持安全配置 c. 检查文档记录和安全参数, 确认抽选的系统组件样本上仅出现具有文档记录的功能 删除非必要功能后, 组织可专注于必要功能的安全, 降低未知功能被利用的风险 将此要求纳入服务器强化标准和流程可解决涉及非必要功能的具体安全问题 ( 例如如果服务器不执行这些功能, 可通过删除 / 禁用 FTP 或 web 服务器来解决 ) 2.3 使用强效加密法对所有非控制台管理访问进行加密 2.3 选择系统组件样本, 并确认非控制台管理访问已通过执行以下操作加密 : 2.3.a 在管理员登录到每个系统时进行查看, 并检查系统配置, 确认在要求提供管理员密码前已调用强效加密法 2.3.b 审核系统上的服务和参数文件, 确定不存在可访问非控制台的 Telnet 及其他不安全的远程登录命令 2.3.c 在管理员登录到每个系统时进行查看, 确认已采用强效加密法对管理员进入任何基于 web 的管理界面的访问权进行加密 2.3.d 检查供应商文档记录并与工作人员面谈, 确认已根据行业最优方法和 / 或供应商建议对所使用技术实施强效加密法 如果非控制台 ( 包括远程 ) 管理未采用安全认证和加密通信, 敏感管理或操作级信息 ( 例如管理员的 ID 和密码 ) 便可能泄露给窃听者 恶意个人可利用这些信息访问网络, 变身为管理员, 然后窃取数据 明文协议 ( 例如 HTTP telnet 等 ) 不会对流量或登录详情加密, 所以窃听者很容易便能截取这类信息 要称得上 强效加密法, 应在适用于所使用技术类型的情况下具备行业认可的具有适当密钥强度和密钥管理的协议 ( 请参阅 PCI DSS 和 PA-DSS 术语 缩略词和首字母缩略词词汇表中的 强效加密法, 以及行业标准和最优方法, 例如 NIST SP 和 SP OWASP 等 ) 注 :SSL/ 早期 TLS 不视为强效加密法, 不得用作安全控制, 但对于已证实不易受已知漏洞影响的 POS POI 终端及其连接到的终端点 ( 如附录 A2 中所规定 ) 例外 2.4 保留一份 PCI DSS 范围内系统组件的清单 2.4.a 检查系统清单, 确认已保留一份软硬件组件列表, 并包含各自的功能 / 用途描述 2.4.b 与工作人员面谈, 确认书面清单保持为最新 保留一份所有系统组件的最新列表能使组织准确有效地界定其实施 PCI DSS 控制的环境范围 如果没有清单, 则可能会遗忘一些系统组件, 并在无意中将其排除在组织配置标准之外 第 31 页

32 2.5 确保已记录 正在使用且所有相关方了解用于管理供应商默认设置及其他安全参数的安全政策和操作程序 2.6 共享托管服务提供商必须保护每个实体的托管环境和持卡人数据 这些提供商必须符合附录 A1 中详述的具体要求 : 针对共享托管服务提供商的 PCI DSS 附加要求 中详述的具体要求 2.5 检查文档记录并与工作人员面谈, 确认用于管理供应商默认设置及其他安全参数的安全政策和操作程序均 : 已记录 使用, 并 为所有相关方所了解 2.6 执行附录 A1 中详述的测试程序 A1.1 至 A1.4: 以确认共享托管服务提供商确实会保护其实体 ( 商户和服务提供商 ) 的托管环境和数据 工作人员需了解并遵守安全政策和日常操作程序, 确保始终对供应商默认设置及其他安全参数进行管理, 从而避免不安全的配置 本要求适用于在同一台服务器上为多个客户提供共享托管环境的托管服务提供商 当所有数据都位于同一台服务器上且处于单一环境控制下时, 这些共享服务器的设置通常不由单个客户管理 这样会使客户添加可影响所有其他客户环境安全的不安全功能和脚本, 从而让恶意个人能轻易破坏某个客户的数据, 并访问所有其他客户的数据 请参阅附录 A1 了解详细要求 第 32 页

33 保护持卡人数据 要求 3: 保护存储的持卡人数据 诸如加密 截词 掩盖和散列等保护方法都是持卡人数据保护的重要组成部分 即使入侵者绕过其他安全控制并获得加密数据的访问权, 但如果没有正确的加密密钥, 仍不能读取或使用这些数据 此外, 也应考虑使用其他保护已存储数据的有效方法, 以降低潜在风险 例如, 最大限度地降低风险的方法包括 : 如非绝对必要则不存储持卡人数据, 如不需要完整 PAN 则截词持卡人数据, 不使用终端用户消息传递技术 ( 例如电子邮件和即时消息 ) 发送未受保护的 PAN 请参阅 PCI DSS 和 PA-DSS 术语 缩略词和首字母缩略词词汇表 中 强效加密 和其他 PCI DSS 术语的定义 3.1 通过实施数据保留和处理政策 程序和流程最大限度地减少持卡人数据存储, 对所有持卡人数据 (CHD) 存储而言, 这些政策 程序和流程至少应包含以下方面 : 将数据存储量和保留时间限制在法律 法规和 / 或业务要求的范围内 持卡人数据的具体保留要求 不再需要时安全删除数据的流程 按季度查找并安全删除所存储的超过规定保留期限的持卡人数据的流程 3.1.a 检查数据保留罗和处理政策 程序与流程, 确认对于所有持卡人数据 (CHD) 存储而言包含以下方面 : 将数据存储量和保留时间限制在法律 法规和 / 或业务要求的范围内 保留持卡人数据的具体要求 ( 例如因 Y 业务原因, 需将持卡人数据保留 X 的时间 ) 因法律 法规或业务原因而不再需要时安全删除持卡人数据的流程 按季度查找并安全删除所存储的超过规定保留期限要求的持卡人数据的流程 3.1.b 与工作人员面谈, 确认 : 数据保留和处理流程中包含所有位置的已存储持卡人数据 现有按季度执行的自动或人工流程可用于查找并安全删除存储的持卡人数据 针对所有位置的持卡人数据按季度执行自动或人工流程 3.1.c 对于存储持卡人数据的系统组件样本 : 检查文件和系统记录, 确认存储的数据未超出数据保留政策中的要求 查看删除机制, 确认数据已安全删除 正式的数据保留政策明确规定了需要保留的数据和数据存储的地方, 以便能在不再需要这些数据时将其安全地销毁或删除 授权后可存储的唯一持卡人数据为主帐户或 PAN ( 令其不可读取 ) 失效日 持卡人姓名和业务码 必须了解持卡人数据的存储位置, 以便能适当保留或在不再需要时予以适当处理 要对保留要求作适当规定, 实体首先需要了解自己的业务需求 适用于其行业以及 / 或被保留的数据类型的所有法律或法规义务 识别并删除已超过指定保留期限的存储数据可防止不必要地保留不再需要的数据 该过程可以自动或由人工完成, 或二者相结合 例如, 可以执行程控程序 ( 自动或手动 ) 来查找和删除数据, 以及 / 或人工审核数据存储区 采用安全删除方法可确保当不再需要时无法检索到 第 33 页

34 数据 记住, 如果不需要, 则不存储! 3.2 授权之后, 不要存储敏感验证数据 ( 即使已加密 ) 如果收到敏感验证数据, 在完成验证流程后使所有数据不可恢复 在下列情况下, 允许发卡机构和支持发卡服务的公司存储敏感验证数据 : 有正当的业务理由且 数据存储安全 敏感验证数据包括下文要求 至 中列举的数据 : 3.2.a 对于发卡机构和 / 或支持发卡服务并存储敏感验证数据的公司, 需审核政策并与工作人员面谈, 确认具备存储敏感验证数据的有文档记录的正当业务理由 3.2.b 对于发卡机构和 / 或支持发卡服务并存储敏感验证数据的公司, 需检查数据存储和系统配置, 以确认敏感验证数据的安全性 3.2.c 对于所有其他实体, 如果收到敏感验证数据, 需审核政策和程序, 并检查系统配置, 以确认这些数据并非在授权后保留 3.2.d 对于所有其他实体, 如果收到敏感验证数据, 需审核程序并检查安全删除数据的流程, 以确认这些数据不可恢复 敏感验证数据包括全磁道数据 卡验证代码或值以及 PIN 数据 禁止在授权后存储敏感验证数据! 这类数据对恶意个人非常重要, 因为他们可借此生成假冒支付卡, 进行欺诈性交易 发行支付卡的实体或者提供或支持发行服务的实体通常会将创建和控制敏感验证数据作为发行功能的一部分 提供 促进或支持发行服务的公司仅在有存储敏感验证数据的合理业务需求时方可存储此类数据 应当注意, 所有 PCI DSS 要求均适用于发卡机构, 对发卡机构和发卡机构处理商而言, 唯一的例外就是在有正当理由时方可保留敏感验证数据 正当理由指发卡机构履行职能时必需的理由, 而非因便所需理由 凡此类数据均须安全存储, 并且遵守所有 PCI DSS 要求和具体的支付品牌要求 非发卡实体不得在授权后保留敏感验证数据 第 34 页

35 3.2.1 切勿在授权后存储卡片背面磁条上任何磁道的完整内容 芯片或其他地方上的等效数据 此类据也可称为全磁道 磁道 磁道 1 磁道 2 和磁条数据 注 : 在正常业务过程中, 以下磁条数据元素可能需要保留 : 持卡人姓名 主帐户 (PAN) 失效日 业务码为将风险降至最低, 只存储业务所需的数据元素 对于系统组件样本, 需检查包括但不限于以下方面的数据源, 并确认在授权后未存储卡片背面磁条上任何磁道的完整内容或芯片上的等效数据 : 输入的交易数据 所有日志 ( 例如交易 历史 除错 错误 ) 存档文件 跟踪文件 几种数据库架构 数据库内容 如果已存储全磁道数据, 恶意个人在获得这些数据后便可借此复制支付卡, 完成欺诈性交易 切勿在授权后存储用于确认无实卡交易的卡验证代码或值 ( 印在支付卡正面或背面的三或四位数值 ) 授权后, 请勿存储个人识别码 (PIN) 或经加密的 PIN 数据块 对于系统组件样本, 需检查包括但不限于以下方面的数据源, 并确认在授权后未存储印在卡片正面或签名栏上的三或四位卡验证代码或值 (CVV2 CVC2 CID CAV2 数据 ): 输入的交易数据 所有日志 ( 例如交易 历史 除错 错误 ) 存档文件 跟踪文件 几种数据库架构 数据库内容 对于系统组件样本, 需检查包括但不限于以下方面的数据源, 并确认在授权后未存储 PIN 和已加密的 PIN 数据块 : 输入的交易数据 所有日志 ( 例如交易 历史 除错 错误 ) 存档文件 跟踪文件 几种数据库架构 数据库内容 卡验证代码主要用于保护消费者和卡都不在交易现场的 无实卡 交易 互联网或邮件命令 / 电话命令 (MO/TO) 交易 如果这些数据被盗, 恶意个人便能实施互联网和 MO/TO 欺诈交易 仅持卡人或发卡银行可知道这些数值 如果这些数据被盗, 恶意个人便能实施基于 PIN 的欺诈性借方交易 ( 例如 ATM 取款 ) 第 35 页

36 3.3 显示 PAN 时予以掩盖 ( 最多显示前六位和后四位数字 ), 以便仅限具有正当业务需要的工作人员查看除前六位 / 后四位以外的 PAN 注 : 该要求不能取代现行更严格的有关持卡人数据显示的要求, 例如法律或支付卡品牌对销售点 (POS) 收据的要求 3.3.a 检查关于掩盖 PAN 显示的书面政策和程序, 确认 : 已记录需要访问除前六位 / 后四位以外的 PAN( 包括完整的 PAN) 显示的角色列表, 以及每个角色拥有该访问权的正当业务需要 显示 PAN 时必须予以掩盖, 以便仅限具有正当业务需要的工作人员查看除前六位 / 后四位以外的 PAN 未特别授权可查看完整 PAN 的所有角色须仅可查看被掩盖的 PAN 3.3.b 检查系统配置, 确认仅向具有书面业务需求的用户 / 角色显示完整的 PAN, 对所有其他请求均掩盖 PAN 在计算机显示屏 支付卡收据 传真或纸质报告等物品上显示完整的 PAN 可能导致此类数据被无授权个人获取并用于欺诈 确保仅向具有合理业务需求查看完整 PAN 的人员显示完整的 PAN 可最大限度地减少未授权人员获取 PAN 数据访问权限的风险 掩盖方法应始终确保必要时仅显示尽可能少的位数, 以便履行特定业务职能 例如, 如果仅需要后四位数即可履行业务职能, 则可掩盖 PAN, 以便履行该职能的个人仅查看后四位数 再如, 如果某项职能出于发送目的需要访问银行识别号 (BIN), 则在履行该职能期间可选择仅取消掩盖 BIN 数字 ( 一般为前六位数 ) 3.3.c 检查 PAN 的显示 ( 例如显示在屏幕 纸质收据上的 PAN), 确认在显示持卡人数据时掩盖了 PAN, 且仅有正当业务需要者能够查看除前六位 / 后四位数字以外的 PAN 该要求涉及保护在显示屏 纸质收据 打印材料等上面显示的 PAN, 切勿与要求 3.4 中在文件 数据库等内存储时保护 PAN 的要求相混淆 第 36 页

37 3.4 通过采取下列任一方法使所有位置 ( 包括便携式数字媒介上 备份媒介上和日志中 ) 存储的 PAN 均不可读 : 基于强效加密法的单向散列函数 ( 散列必须要有完整的 PAN) 截词 ( 不能用散列代替 PAN 被截词的部分 ) 索引令牌与索引簿 ( 索引簿必须安全地存储 ) 具有相关密钥管理流程和程序的强效加密法 注 : 对恶意个人而言, 如果能访问被截词和散列的 PAN, 要重建原始 PAN 数据是件相当轻松的事 如果在实体环境中出现同一个 PAN 的散列版本和截词版本, 则须采取额外控制措施, 确保散列版本和截词版本不能被相互关联, 用于重建原始 PAN 如使用磁盘加密 ( 而不是文件级或列级数据库加密 ), 则逻辑访问必须得到单独管理并独立于本地操作系统的验证和访问控制机制 ( 例如, 不使用本地用户帐 3.4.a 检查关于 PAN 保护系统的文件记录, 包括供应商 系统 / 流程类型以及加密算法 ( 若适用 ), 确认已通过使用下列任一方法令 PAN 不可读取 : 基于强效加密法的单向散列函数, 截词 索引记号与索引簿 ( 索引簿存储安全 ) 具有相关密钥管理流程和程序的强效加密法 3.4.b 检查数据储存库样本中的几个表格或文件, 确认 PAN 不可读 ( 即, 未以纯文本形式存储 ) 3.4.c 检查可移动媒介 ( 例如备份磁带 ) 样本, 确认 PAN 不可读 3.4.d 检查检查日志 ( 包括支付应用程序日志 ) 样本, 确认已使 PAN 不可读, 或未显示在日志中 3.4.e 如果在此环境中出现同一个 PAN 的散列版本和截词版本, 请检查已实施的控制, 确认散列版本和截词版本无法相互关联, 用于重建原始 PAN a 如果采用磁盘加密, 需检查配置并查看验证过程, 确认实现加密文件系统逻辑访问所使用的机制与本地操作系统的验证机制分离 ( 例如不使用本地用户帐户数据库或普通网络登录凭证 ) 存储在主要存储区 ( 数据库或诸如文本文件和电子表格等平面文件 ) 和非主要存储区 ( 备份 检查日志 异常或故障排除日志 ) 的 PAN 均须得到保护 可采用基于强效加密法的单向散列函数令持卡人数据不可读取 在无需检索原始数字时适于采用散列函数 ( 单向散列不可逆 ) 在进行散列前, 建议 ( 当前并不要求 ) 向持卡人数据另增一个随机输入值, 以降低攻击者将这些数据与预先计算的散列值表相比较并从中推算出 PAN 的可能性 截词的目的在于永久删除某个 PAN 数据段, 以便仅存储部分 ( 通常不超过前六位和后四位数 ) 的 PAN 索引记号是根据特定索引用一个不可预测的值替代 PAN 的密码符号 一次性索引簿是一个系统, 在这个系统中, 使用 ( 只可使用一次 ) 随机生成的私人密钥为消息加密, 然后使用匹配的一次性索引簿和密钥为消息解密 强效加密法 ( 请参阅 PCI DSS 和 PA-DSS 术语 缩略词和首字母缩略词词汇表 中的定义 ) 的目的是根据经行业测试并认可的算法 ( 非专有或 自行开发 的算法 ) 采用强效加密密钥进行加密 通过关联特定 PAN 的散列版和截词版, 恶意个人可轻易推算出 PAN 的原始值 防范此类数据相互关联的控制措施有助于确保原始 PAN 始终不可读 本要求旨在实现磁盘级加密对于实现持卡人数据不可读的可接受性 磁盘级加密可对计算机上的整个磁盘 / 分区加密, 并在授权用户请求时自动解密信息 许多磁盘加密解决方案会拦截操作系统的读 / 第 37 页

38 户数据库或通用网络登录凭证 ) 解密密匙决不能与用户帐户关联 注 : 除了所有其他 PCI DSS 加密和密钥管理要求外, 此要求也适用 b 查看流程并与工作人员面谈, 确认加密密钥存储安全 ( 例如存储在通过严格访问控制提供充分保护的可移动媒介上 ) c 检查配置并查看流程, 确认存储在可移动媒介上任何位置的持卡人数据均已加密 注 : 如果未使用磁盘加密法对可移动媒介加密, 则需通过一些其他方法使存储在该媒介上的数据实现不可读 写操作, 并且无需用户执行任何特殊操作便可实施相应的加密转换, 而不是在系统启动或会话开始时提供密码或口令 根据磁盘级加密的这些特点, 如要符合本要求, 则不能 : 1) 使用与操作系统相同的用户帐户验证器, 或 2) 使用与系统本地用户帐户数据库或普通网络登录凭证相关联或源于此的解密密钥 全盘加密有助于在磁盘丢失时保护数据, 因此可适用于存储持卡人数据的便携设备 3.5 记录并实施保护程序, 以保护用于防止存储的持卡人数据被泄露和滥用的密钥 : 注 : 本要求适用于用来为存储的持卡人数据加密的密钥, 也适用于用来保护数据加密密钥的密钥加密密钥, 这些密钥加密密钥至少须与数据加密密钥一样强效 仅针对服务提供商的额外要求 : 维护包含以下内容的加密架构文档描述 : 用于保护持卡人数据的所有算法 协议和密钥的详情, 包括密钥强度和到期日 每个密钥主要用途的说明 用于进行密钥管理的任何 HSM 和其他 SCD 的清单 仅极少数必需的保管人有密钥访问权 3.5 检查密钥管理政策和程序, 确认已针对保护用于为持卡人数据加密以防泄露和滥用的密钥制定专门的流程, 这些流程至少应包括以下方面 : 密钥访问权仅限极少数必需的保管人 密钥加密密钥至少要与其保护的数据加密密钥一样强效 密钥加密密钥与数据加密密钥单独存储 尽量减少密钥安全存储的地方和形式 与责任工作人员面谈并审核文档, 确认存在描述加密架构的文档, 描述的内容包括 : 用于保护持卡人数据的所有算法 协议和密钥的详情, 包括密钥强度和到期日 每个密钥主要用途的说明 用于进行密钥管理的任何 HSM 和其他 SCD 的清单 检查用户访问列表, 确认密钥访问权仅限极少数必需的保管人 必须大力保护加密密钥, 因为获得密钥访问权者能够解密数据 为确保适当保护为数据加密的密钥和用该密钥加密的数据, 密钥加密密钥 ( 如使用 ) 至少须与数据加密密钥一样强效 本要求旨在防止密钥泄露和滥用, 适用于数据加密密钥和密钥加密密钥 由于一个密钥加密密钥可允许访问很多数据加密密钥, 所以需要对密钥加密密钥实施强效的保护措施 注 : 仅当评估对象为服务提供商时, 本要求才适用 维护加密架构的当前文档记录可让实体了解用于保护持卡人数据的算法 协议和密钥, 以及生成 使用和保护密钥的设备 这样实体便能够与对其架构造成的不断演变的威胁保持同步, 以便其在不同算法 / 密钥强度所具有的保证级别变更时制定更新计划 维护此类文档记录还可以便于实体检测损失或缺失的密钥 / 密钥管理设备, 并识别对其加密架构的非授权补充 应只有极少数人能访问密钥 ( 降低非授权方可见持卡人数据的可能性 ), 通常仅限具有密钥保管责任的人员 第 38 页

39 3.5.3 存储用于始终以下面的一种 ( 或多种 ) 形式加密 / 解密持卡人数据的机密密钥和私人密钥 : 使用至少与数据加密密钥一样强效且与数据加密密钥分开存储的密钥加密密钥进行加密 在安全加密设备 ( 例如, 硬件 ( 主机 ) 安全模块 (HSM) 或 PTS 批准的交互点设备 ) 内 根据行业认可的方法, 作为至少两个全长密钥组分或密钥共享 注 : 公共密钥不要求以这些形式存储 a 检查书面程序, 确认用于加密 / 解密持卡人数据的密钥须始终仅以下面的一种 ( 或多种 ) 形式存在 使用至少与数据加密密钥一样强效且与数据加密密钥分开存储的密钥加密密钥进行加密 在安全加密设备 ( 例如, 硬件 ( 主机 ) 安全模块 (HSM) 或 PTS 批准的交互点设备 ) 内 根据行业认可的方法, 作为密钥组分或密钥共享 b 检查系统配置和密钥存储位置, 确认用于加密 / 解密持卡人数据的密钥始终以下面一种 ( 或多种 ) 形式存在 用密钥加密密钥进行加密 在安全加密设备 ( 例如, 硬件 ( 主机 ) 安全模块 (HSM) 或 PTS 批准的交互点设备 ) 内 根据行业认可的方法, 作为密钥组分或密钥共享 c 无论密钥加密密钥用于何处, 均需检查系统配置和密钥存储位置以确认 : 密钥加密密钥至少要与其保护的数据加密密钥一样强效 密钥加密密钥与数据加密密钥单独存储 须安全存储密钥, 以防发生可导致持卡人数据暴露的非授权或非必要访问 原本并不打算对密钥加密密钥进行加密, 但将按照要求 3.5 中的规定对它们予以保护, 防止其遭到泄露和误用 若使用密钥加密密钥, 在与数据加密密钥有物理和 / 或逻辑区别的位置存储密钥加密密钥可降低对两种密钥的非授权访问风险 尽量减少密钥存储的地方 检查密钥存储位置并查看流程, 确认已尽量减少密钥存储的地方 尽量减少密钥存储的地方有助于组织跟踪并监控所有密钥位置, 并将非授权方获取密钥的可能性降到最低 3.6 充分记录并实施用于持卡人数据加密的所有密钥管理流程和程序, 包括 : 注 : 包括 NIST( 可在 找到 ) 在内的各种资源均提供有大量密钥管理方面的行业标准 3.6.a 仅针对服务提供商评估的附加测试程序 : 如果服务提供商与客户共享传输或存储持卡人数据的密钥, 则需要检查服务提供商向客户提供的文档记录, 以确认已根据下文要求 至 在文档记录中包含了安全传输 存储并更新客户密钥的方法指南 3.6.b 检查用于持卡人数据加密的密钥管理程序和流程并执行以下操作 : 密钥的管理方式是确保加密解决方案持续安全的关键部分 良好的密钥管理流程作为加密产品的一部分, 无论是手动还是自动均以行业标准为基础并涵盖要求 至 中的所有密钥要素 指导客户如何安全地传输 存储并更新密钥有助于防止密钥管理不善或泄露给非授权实体 本要求适用于用来加密所存储持卡人数据的密钥以及任何相关的密钥加密密钥 注 : 测试程序 3.6.a 是一个附加程序, 并且仅在受评估实体为服务提供商时适用 第 39 页

40 3.6.1 生成强效密钥 a 确认密钥管理程序详细列明强效密钥的生成方式 加密解决方案须根据 密钥生成 部分下的 PCI b 查看密钥生成程序, 确认已生成强效密钥 DSS 和 PA-DSS 术语 缩略词和首字母缩略词词汇表中定义生成强效密钥 使用强效密钥可显著提高 已加密持卡人数据的安全级别 安全的密钥分配 a 确认密钥管理程序详细列明如何安全分配密钥 加密解决方案必须对密钥进行安全分配, 这表示密 b 查看密钥的分配方法, 确认密钥已安全分配 钥只会以掩盖的方式分配给要求 中指定的保管人 安全的密钥存储 a 确认密钥管理程序详细列明如何安全存储密钥 加密解决方案必须对密钥进行安全存储, 例如, 使 b 查看密钥存储方法, 确认密钥已安全存储 用密钥加密密钥对其进行加密 密钥存储未得到适当保护时会为攻击者提供访问通道, 进而导致解密 并暴露持卡人数据 根据相关应用程序供应商或密钥所有人的规定并基于行业最优方法和指南 ( 例如, NIST 特别出版物 ), 在密钥周期结束时 ( 例如, 指定期限过后和 / 或给定密钥产生一定量的密文后 ) 对密钥进行的变更 密钥的完整性变弱 ( 例如, 知道明文密钥部分的员工离职 ) 或怀疑密码遭受威胁时, 认为有必要注销或替换 ( 例如, 存档 销毁和 / 或撤销 ) 密钥 注 : 如果需要保留注销或替换的密钥, 则必须对其进行安全存档 ( 例如, 使用密钥加密密钥进行存档 ) 存档的密钥只能用于解密 / 验证 a 确认密钥管理程序包含使用中的每种密钥的指定密钥周期, 并定义密钥在指定密钥周期结束时的变更流程 b 与工作人员面谈, 确认已在指定密钥周期结束时更改密钥 a 确认密钥管理程序详细列明以下各方面的流程 : 当密钥的完整性减弱时, 注销或替换密钥 替换确定或怀疑受到威胁的密钥 注销或替换后保留的任何密钥均不用于加密 b 与工作人员面谈, 确认已实施以下流程 : 密钥的完整性变弱时 ( 包括知道密钥的人离职时 ), 根据需要注销或替换密钥 确定或怀疑密钥受到威胁时替换密钥 注销或替换后保留的任何密钥均不用于加密 密钥周期是指特定密钥用于指定目的的时间段 定义密钥周期要考虑的因素包括但不限于基础算法的强度 密钥的大小或长度 密钥遭受威胁的风险以及被加密数据的敏感性 加密密钥必须在加密周期结束后定期更改, 这样可将他人获取加密密钥并用其解密数据的风险降到最低 不再使用或需要的密钥或者确定或怀疑受到威胁的密钥应予以撤销和 / 或销毁, 以确保不再使用 若需要保留这种密钥 ( 例如, 用来支持已存档的加密数据 ), 则应为其提供强效保护 加密解决方案应规定并简化已到期或者确定或怀疑受到威胁的密钥的替换流程 第 40 页

41 3.6.6 若使用手动明文密钥管理操作, 则必须使用分割知识和双重控制来管理这些操作 注 : 手动密钥管理操作示例包括但不限于 : 密钥生成 传输 加载 存储和销毁 a 确认手动明文密钥管理程序详细列明使用以下管理方法的流程 : 密钥的分割知识, 即密钥的组成部分至少由两个人控制, 每个人只知道自己那部分的密钥 ; 和 密钥的双重控制, 即至少需要两个人执行密钥管理操作且他们无法访问对方的验证材料 ( 例如, 密码或密钥 ) b 与工作人员面谈并 / 或查看流程, 确认使用以下方法管理手动明文密钥 : 分割知识和 双重控制 密钥的分割知识和双重控制确保没人知道完整的密钥 此控制适用于手动密钥管理操作或加密产品未实施密钥管理的情况 分割知识是由两个或更多人分别掌握部分密钥的一种方法, 每个人只知道自己的密钥部分, 且根据单个密钥部分无法得知原始密钥 双重控制需要两个或更多的人共同完成且他们无法访问或使用对方的验证材料 防止密钥的非授权替换 a 确认密钥管理程序详细列明防止对密钥进行非授权替换的流程 加密解决方案不允许或接受来自非授权来源或意外流程的密钥替换 有关密钥保管人正式确认理解并接受密钥保管责任的要求 3.7 确保已记录 正在使用且所有相关方了解用于保护所存储持卡人数据的安全政策和操作程序 b 与工作人员面谈并 / 或查看流程, 确认已防止密钥的非授权替换 a 确认密钥管理程序详细列明密钥保管人确认 ( 以书面或电子形式 ) 理解并接受密钥保管责任的流程 b 查看表明密钥保管人已确认 ( 以书面或电子形式 ) 理解并接受密钥保管责任的文档记录或其他证据 3.7 检查文档记录并与工作人员面谈, 确认用于保护所存储持卡人数据的安全政策和操作程序均 : 已记录 使用, 并 为所有相关方所了解 该流程有助于确保密钥保管人承诺担任该角色并且理解和接受其责任 工作人员需了解并遵守用于持续管理持卡人数据安全存储的安全政策和书面操作程序 第 41 页

42 要求 4: 加密持卡人数据在开放式公共网络中的传输 在恶意个人可轻松访问的网络中传输敏感信息时必须进行加密 错误配置的无线网络和旧版加密及验证协议中的漏洞仍然是恶意个人攻击的目标, 他们利用这些漏洞来获取持卡人数据环境的访问特权 4.1 使用强效加密法和安全协议来保护经由公开 公共网络传输的敏感持卡人数据, 包括 : 只接受可信的密钥和证书 使用的协议只支持安全的版本或配置 加密强度适合所使用的加密方法 开放式公共网络包括但不限于 : 互联网 无线技术, 包括 和蓝牙 蜂窝技术, 例如, 全球移动通信系统 (GSM) 码分多址 (CDMA) 通用分组无线业务 (GPRS) 卫星通信 4.1.a 识别通过公开 公共网络传输或接收持卡人数据的位置 检查书面标准并与系统配置对比, 确认在所有位置均已使用安全协议和强效加密法 4.1.b 审查书面政策和程序, 确认已详细列明以下方面的流程 : 只接受可信密钥和 / 或证书 所使用的协议仅支持安全的版本和配置 ( 不支持非安全版本和配置 ) 根据所使用的加密方法实施适当的加密强度 4.1.c 在出现入站和出站传输时选择并查看其样本 ( 例如, 通过查看系统流程或网络流量 ), 确认已在传输时使用强效加密法对所有持卡人数据进行了加密 4.1.d 检查密钥和证书, 确认仅接受可信密钥和 / 或证书 在公共网络中传输的敏感信息必须予以加密, 这是因为恶意个人通常会在数据传输过程中轻松拦截和 / 或转移数据 要实现持卡人数据的安全传输需使用可信密钥 / 证书 安全传输协议以及用于持卡人数据加密的合适加密强度 对于不支持所需加密强度以及会导致非安全连接的系统发出的连接请求不予以接受 注意 : 有些协议的实施 ( 例如 SSL SSH 1.0 版本和早期 TLS) 存在攻击者可用于控制受影响系统的已知漏洞 无论使用哪种安全协议, 确保已将其配置为仅使用安全的版本和配置, 防止使用非安全连接, 例如, 通过仅使用可信证书和仅支持强效加密 ( 不支持较弱的非安全协议或方法 ) 来实现 确认证书可信 ( 例如, 未过期且由可信来源发布 ) 有助于确保安全连接的完整性 4.1.e 检查系统配置, 确认实施的协议仅使用安全的配置且不支持非安全版本或配置 ( 接下页 ) 4.1.f 检查系统配置, 确认已针对所使用的加密方法实施了合适的加密强度 ( 核对供应商建议 / 最优方法 ) 第 42 页

43 4.1.g 对于 TLS 的实施, 检查系统配置, 确认无论何时传输或接收持卡人数据均启用 TLS 例如, 对于基于浏览器的实施 : HTTPS 作为浏览器统一记录定位器 (URL) 协议, 且 仅当 HTTPS 作为 URL 的一部分时才需要持卡人数据 通常, 网页网址应以 HTTPS 开头, 并且 / 或者 Web 浏览器在浏览器窗口某处显示挂锁图标 很多 TLS 证书供应商还会提供高度可见的验证标记 ( 有时称为 安全标记 安全站点标记 或 安全信任标记 ), 并且可能提供点击标记后即显示网站信息的功能 有关强效加密法和安全协议 ( 例如,NIST SP 和 SP OWASP 等 ) 的信息, 请参阅行业标准和最优方法 确保传输持卡人数据或连接到持卡人数据环境的无线网络使用行业最优方法, 以对验证和传输实施强效加密 4.2 不要使用终端用户通讯技术 ( 例如, 电子邮件 即时通讯 短信 聊天等 ) 来传送不受保护的 PAN 4.3 确保已记录 正在使用且所有相关方了解用于加密持卡人数据传输的安全政策和操作程序 识别传输持卡人数据或连接到持卡人数据环境的所有无线网络 检查书面标准并与系统配置设置对比, 确认找到所有无线网络的以下内容 : 使用行业最优方法以对验证和传输实施强效加密 弱加密 ( 例如,WEP SSL) 未用作验证或传输的安全控制 4.2.a 如果终端用户通讯技术用于发送持卡人数据, 则请查看 PAN 的发送程序, 并在出现出站传输时检查其样本, 以确认无论何时通过终端用户通讯技术发送 PAN,PAN 均呈现不可读或受强效加密法保护的状态 4.2.b 审查书面政策, 确认已有不会通过终端用户通讯技术传送不受保护的 PAN 方面的政策规定 4.3 检查文档记录并与工作人员面谈, 确认用于加密持卡人数据传输的安全政策和操作程序 : 已记录 使用, 并 为所有相关方所了解 注 :SSL/ 早期 TLS 不视为强效加密法, 不得用作安全控制, 但对于已证实不易受已知漏洞影响的 POS POI 终端及其连接到的终端点 ( 如附录 A2 中所规定 ) 例外 恶意用户使用可轻松获取的免费工具来窃听无线通信 使用强效加密法可限制无线网络中敏感信息的泄漏 对于持卡人数据的验证和传输, 必须使用强效加密法来防止恶意用户访问无线网络或利用无线网络访问其他内部网络或数据 电子邮件 即时通讯 短信和聊天在内部和公共网络中传送时, 可通过数据包嗅探轻松拦截 除非这些通讯工具配置后可提供强效加密, 否则勿用其传送 PAN 此外, 如果某一实体通过终端用户通讯技术请求 PAN, 则该实体应在传输前提供工具或方法, 通过强效加密法保护这些 PAN, 或使这些 PAN 不可读 工作人员需了解并遵守用于持续管理持卡人数据安全传输的安全政策和操作程序 第 43 页

44 维护漏洞管理计划 要求 5: 为所有系统提供恶意软件防护并定期更新杀毒软件或程序 恶意的软件通常称为 恶意软件 ( 包括病毒 蠕虫病毒和特洛伊木马 ), 可在很多业务许可活动 ( 包括员工电子邮件以及互联网 移动计算机和存储设备的使用 ) 中进入网络, 从而利用系统漏洞 经常受恶意软件影响的所有系统均必须使用杀毒软件, 以避免系统经受当前和不断进化的恶意软件的威胁 此外, 也可以考虑将其他反恶意软件解决方案作为对杀毒软件的补充 ; 但此类附加解决方案无法取代对适当杀毒软件的需求 5.1 在经常受恶意软件影响的所有系统 ( 特别是个人电脑和服务器 ) 中部署杀毒软件 确保杀毒程序能检测 删除并阻止所有已知类型的恶意软件 对于通常不受恶意软件影响的系统, 需要执行定期评估以确定并评估不断进化的恶意软件威胁, 从而确认这些系统是否仍不需要使用杀毒软件 5.1 对于系统组件样本 ( 包括经常受恶意软件影响的所有操作系统类型 ), 确认如果存在适用的杀毒技术则部署杀毒软件 审查供应商文档记录并检查杀毒配置, 确认杀毒程序能 : 检测所有已知类型的恶意软件 删除所有已知类型的恶意软件, 并 阻止所有已知类型的恶意软件 恶意软件类型包括病毒 特洛伊木马 蠕虫病毒 间谍软件 广告软件和 Rootkit 内核型病毒 与工作人员面谈, 确认已针对目前认为通常不受恶意软件影响的系统, 监控并评估不断进化的恶意软件威胁, 从而确认这些系统是否仍不需要使用杀毒软件 目前存在利用广泛发布的威胁持续攻击其他安全系统的情况, 通常称为 零日漏洞攻击 ( 利用之前未知的漏洞进行的攻击 ) 如果没有定期更新的杀毒解决方案, 这些新型恶意软件便会攻击系统 禁用网络或威胁数据 阻止所有类型和形式的恶意软件很重要 通常, 大型机 中型电脑 ( 例如 AS/400) 和类似系统当前可能通常不是恶意软件攻击的目标或不受其影响 然而, 恶意软件的行业趋势变化迅速, 因此组织需要了解会影响其系统的新的恶意软件, 例如, 通过密切监控供应商安全公告和杀毒新闻组, 确定其系统是否会受到不断进化的新恶意软件的威胁 恶意软件的发展趋势应包含在新安全漏洞的识别流程中, 而处理新趋势的方法应根据需要并入公司的配置标准和保护机制中 第 44 页

45 5.2 确保所有杀毒机制按如下方式维护 : 保持为最新, 执行定期扫描 生成检查日志 (PCI DSS 要求 10.7 规定保留 ) 5.2.a 检查政策和程序, 确认已规定杀毒软件和相关定义需要保持为最新 5.2.b 检查杀毒配置 ( 包括软件的主体安装 ), 确认杀毒机制 : 配置为执行自动更新, 且 配置为执行定期扫描 5.2.c 检查系统组件样本 ( 包括经常受恶意软件影响的所有操作系统类型 ), 确认 : 杀毒软件和相关定义为最新 已执行定期扫描 5.2.d 检查杀毒配置 ( 包括软件的主体安装和系统组件的样本部分 ), 确认 : 已启用杀毒软件日志生成功能, 且 日志根据 PCI DSS 要求 10.7 进行保留 如果不用最新的安全更新 签名文件或恶意软件防护进行维护并保持为最新, 那么即使是最佳杀毒解决方案的效力也会受限 检查日志可监控病毒和恶意软件活动以及反恶意软件的效果 因此, 反恶意软件解决方案必须配置为可生成检查日志且这些日志必须根据要求 10 进行管理 第 45 页

46 5.3 确保杀毒机制积极运行且无法被用户禁用或更改, 除非管理人员根据具体情况做出有时间限制的明确授权 注 : 只有存在合理的技术需要且根据具体情况经管理人员批准时, 才能暂时禁用杀毒解决方案 如果出于特定目的需要禁用杀毒保护, 必须获得正式授权 杀毒保护禁用期间, 可能还需要实施其他安全措施 5.4 确保已记录 正在使用且所有相关方了解为系统提供恶意软件防护的安全政策和操作程序 5.3.a 检查杀毒配置 ( 包括软件的主体安装和系统组件的样本部分 ), 确认杀毒软件正在活跃运行 5.3.b 检查杀毒配置 ( 包括软件的主体安装和系统组件的样本部分 ), 确认用户无法禁用或更改杀毒软件 5.3.c 与负责人员面谈并查看流程, 确认除非管理人员根据具体情况做出有时间限制的明确授权, 否则用户无法禁用或更改杀毒软件 5.4 检查文档记录并与工作人员面谈, 确认为系统提供恶意软件防护的安全政策和操作程序均 : 已记录 使用, 并 为所有相关方所了解 持续运行且无法更改的杀毒软件可提供持久的恶意软件防护 根据政策对所有系统实施控制, 可确保反恶意软件保护无法更改或禁用, 从而防止系统漏洞被恶意软件利用 病毒防护禁用期间, 需要实施其他安全措施, 例如, 在禁用病毒防护时断开不受保护的系统与互联网间的连接并在重新启用病毒防护后运行全盘扫描 工作人员需了解并遵守安全政策和操作程序, 确保始终为系统提供恶意软件防护 第 46 页

47 要求 6: 开发并维护安全的系统和应用程序 恶意个人会利用安全漏洞获得系统访问特权 很多此类漏洞可通过供应商提供的安全补丁修复, 而负责管理系统的实体必须安装这些补丁 所有系统均须具备所有适当的软件补丁, 以防恶意个人和恶意软件利用 破坏持卡人数据 注 : 适当的软件补丁指已通过充分评估和测试确定不会与现有安全配置相冲突的补丁 对于内部开发的应用程序, 很多漏洞均可通过采用标准系统开发流程和安全编码技术加以避免 6.1 制定相关流程, 通过使用良好的外部信源获取安全漏洞信息来识别安全漏洞, 并为新发现的安全漏洞指定风险等级 ( 例如 高 中 或 低 ) 注 : 风险等级应以行业最优方法和潜在影响考虑为依据 例如, 漏洞分级标准可能包括对 CVSS 基础得分的考虑及 / 或供应商的分类及 / 或相关系统的类型 根据组织的环境和风险评估策略不同, 评估漏洞和指定风险等级的方法也不尽相同 风险等级至少应标识出所有被视为对环境具有 高风险 的漏洞 除风险等级外, 如果安全漏洞即将对环境造成威胁 影响关键系统且 / 或如果不解决可能会造成潜在危害, 则可被视为 重要 关键系统示例可能包括安全系统 面向公众的设备和系统 数据库以及其他存储 处理或传输持卡人数据的系统 6.2 通过安装供应商提供的适用安全补丁, 确保所有系统组件和软件均杜绝已知漏洞 在发布后一个月内安装关键的安全补丁 注 : 应按照要求 6.1 中规定的风险分级流程标识关键安全补丁 6.1.a 检查政策和程序, 确认已规定以下流程 : 识别新的安全漏洞 为漏洞指定风险等级, 包括识别所有 高风险 和 重要 漏洞 使用良好的外部信源获取安全漏洞信息 6.1.b 与负责人员面谈并查看流程, 确认 : 已识别新的安全漏洞 已为漏洞指定风险等级, 包括对所有 高风险 和 重要 漏洞的识别 用于识别新安全漏洞的流程包含使用可信外源获取安全漏洞信息 6.2.a 检查与安全补丁安装相关的政策和程序, 确认已规定以下流程 : 在发布后一个月内安装供应商提供的适用关键安全补丁 在适当的时间范围内 ( 例如三个月内 ) 安装供应商提供的所有适用安全补丁 本要求旨在让组织能及时更新可能影响其环境的新漏洞 漏洞信息来源应当可信, 并且通常包含供应商网址 行业新闻组 邮件列表或 RSS 反馈 当组织发现可能影响其环境的漏洞后, 必须评估该漏洞产生的风险并确定风险等级 因此, 组织必须有适当的方法可对漏洞进行持续评估并为这些漏洞指定风险等级 这并非通过一次 ASV 扫描或内部漏洞扫描就能实现, 而是需要制定积极监控漏洞信息行业来源的流程 组织能够通过风险分类 ( 例如 高 中 或 低 ) 更快地识别和优先解决风险最高的项目, 降低风险最大的漏洞被利用的可能性 目前存在利用广泛发布的威胁持续攻击其他安全系统的情况, 通常称为 零日漏洞攻击 ( 利用之前未知的漏洞进行的攻击 ) 如未尽快在关键系统上应用最新补丁, 恶意个人便可能利用这些漏洞攻击或禁用系统, 或获得敏感数据的访问权 第 47 页

48 6.2.b 对于系统组件和相关软件样本, 对照各系统上已安装的安全补丁列表与最新的供应商安全补丁列表, 确认 : 供应商提供的适用关键安全补丁已在发布后一个月内安装 供应商提供的所有适用安全补丁已在适当的时间范围内 ( 例如三个月内 ) 安装 为关键基础架构确定补丁优先次序可确保高优先级系统和设备在补丁发布后尽快得到漏洞防护 考虑确定补丁安装的优先次序, 以便关键系统或高危系统的安全补丁能在 30 天内安装, 其他风险较低的补丁在 2-3 个月内安装 此要求适用于所有已安装软件的适用补丁, 包括支付应用程序 ( 通过和未通过 PA-DSS 验证的支付应用程序 ) 6.3 遵照如下要求安全地开发内部和外部软件应用程序 ( 包括基于 Web 的应用程序管理访问 ): 按照 PCI DSS( 例如安全验证和记录 ) 基于行业标准和 / 或最优方法 信息安全并入整个软件开发生命周期 注 : 该要求适用于所有内部开发的软件以及由第三方开发的定制软件 在激活或向客户发布应用程序前, 删除开发 测试和 / 或自定义应用程序帐户 用户 ID 和密码 6.3.a 检查书面软件开发流程, 确认这些流程以行业标准和 / 或最优方法为基础 6.3.b 检查书面软件开发流程, 确认信息安全已纳入软件开发的整个生命周期 6.3.c 检查书面软件开发流程, 确认软件应用程序的开发符合 PCI DSS 6.3.d 与软件开发人员面谈, 确认已实施书面软件开发流程 检查书面软件开发程序并与负责人员面谈, 确认在应用程序投入生产前或向客户发布前已删除预生产和 / 或自定义应用程序帐户 用户 ID 和 / 或密码 如果未在软件开发的要求定义 设计 分析和测试阶段纳入安全考虑, 安全漏洞则会被无意或恶意地带入生产环境 了解应用程序如何处理敏感数据 ( 包括何时存储 传输, 以及何时添加到内存中 ) 有助于识别需保护的数据所在的位置 在应用程序启动前或向客户发布前, 应自生产代码中删除开发 测试和 / 或自定义应用程序帐户 用户 ID 和密码, 因为这些项目可能泄露有关该应用程序功能的信息 持有这类信息会让应用程序和相关持卡人数据更易遭受威胁 第 48 页

49 6.3.2 为识别任何潜在的编码漏洞 ( 采用人工或自动流程 ), 请在投入生产或向客户发布前审核自定义代码, 至少包括 : 由代码原作者以外人员以及熟悉代码审核方法和安全编码实践的人员审核代码变更 代码审核可确保代码的开发符合安全编码指南 发布前已进行适当修正 代码审查结果在发布前已由管理人员审核并批准 a 检查书面软件开发程序并与负责人员面谈, 确认所有自定义应用程序代码变更均必须按照以下要求进行审核 ( 采用人工或自动流程 ): 代码变更由代码原作者以外人员以及熟悉代码审核方法和安全编码实践的人员进行审核 代码审核可确保代码的开发符合安全编码指南 ( 请参阅 PCI DSS 要求 6.5) 发布前已进行适当修正 代码审查结果在发布前已由管理人员审核并批准 恶意个人通常会利用自定义代码中的安全漏洞来获取对网络的访问权并对持卡人数据构成威胁 审核流程应有一名熟悉代码审核方法并具备相关经验的人员参与 为确保进行独立客观的审核, 代码审核应由代码开发人员以外的人员执行 也可采用自动化工具或流程代替人工审核, 但要记住, 自动化工具可能难以甚至不可能识别某些编码问题 在将代码部署到生产环境或发布给客户之前修正编码错误可避免代码暴露在可能被利用的环境下 另外, 在部署或发布到生产环境后处理错误代码的难度会更大, 花费也更高 管理人员在发布前进行正式审核并签字有助于确保代码通过审批, 并已按政策与程序进行开发 ( 接下页 ) 注 : 这项代码审核要求适用于所有自定义代码 ( 内部代码和面向公众的代码 ), 可作为系统开发生命周期的组成部分 代码审核可由熟悉这方面工作的内部人员或第三方负责 面向公众的 Web 应用程序还应受到附加控制措施的约束, 以应对实施后不断出现的威胁和漏洞, 具体规定请参见 PCI DSS 要求 系统组件的所有变更均须遵守变更控制流程和程序 该流程必须包括如下内容 : b 选择最近的一批自定义应用程序更改样本, 确认已根据上述要求 a 审核自定义应用程序代码 6.4 检查政策和程序, 确认已规定下列内容 : 开发 / 测试环境独立于生产环境, 并设置适当访问控制, 确保两者的分离 对分配到开发 / 测试环境与生产环境中的人员的职责进行分离 在测试或开发过程中不使用生产数据 ( 实时 PAN) 在激活生产系统前, 已经删除测试数据与帐户 有关实施安全补丁和软件修改的变更控制程序已用文档记录 如果没有适当记录和实施的变更控制措施, 安全属性则可能被无意或有意忽略或者被设定为不可操作, 而且可能发生违规处理情形或引入恶意代码 第 49 页

50 6.4.1 开发 / 测试环境独立于生产环境, 并借助访问控制确保两者分离 开发 / 测试环境与生产环境中的职责分离 在测试或开发过程中不使用生产数据 ( 真实的 PAN) 在激活系统 / 系统投入生产前, 删除系统组件中的测试数据和帐户 a 检查网络文档记录和网络设备配置, 确认开发 / 测试环境独立于生产环境 b 检查访问控制设置, 确认已实施访问控制来确保开发 / 测试环境与生产环境已分离 查看流程, 并与分配到开发 / 测试环境的人员和分配到生产环境的人员面谈, 确认开发 / 测试环境与生产环境之间已实现职责分离 a 查看测试流程, 并与工作人员面谈, 确认现已实施相关程序, 确保在测试或开发过程中不使用生产数据 ( 真实的 PAN) b 检查一批测试数据样本, 确认测试或开发过程中未使用生产数据 ( 真实的 PAN) a 查看测试流程, 并与工作人员面谈, 确认在生产系统启动前已删除测试数据和帐户 b 检查一批来自最近安装或更新的生产系统的数据和帐户样本, 确认在系统启动前已删除测试数据和帐户 由于开发和测试环境会不断变化, 所以其安全性往往低于生产环境 如果环境之间没有充分分离, 则生产环境和持卡人数据可能会因测试或开发环境中不够严格的安全配置和可能存在的漏洞而受到威胁 减少有权访问生产环境和持卡人数据的人数可最大限度地降低风险, 有助于确保访问权仅限于有业务知情需要的个人 本要求旨在确保开发和测试职能与生产职能相分离 例如, 开发人员可使用在开发环境中享有较高特权的管理员级帐户, 并同时拥有可对生产环境进行用户级访问的独立帐户 测试或开发环境中的安全控制措施通常不够严格 使用生产数据会为恶意个人提供非法访问生产数据 ( 持卡人数据 ) 的机会 应在系统组件激活 ( 投入生产 ) 前删除测试数据和帐户, 因为这些项目可能会泄露应用程序或系统功能的相关信息 持有这类信息会让系统和相关持卡人数据更易遭受威胁 第 50 页

51 6.4.5 变更控制程序须包含 : a 检查书面变更控制程序, 确认已规定以下方面的程序 : 影响记录 被授权方的变更审批记录 功能测试, 以确认该变更未对系统安全造成不利影响 取消程序 如果管理不当, 系统变更 ( 例如硬件或软件更新和安全补丁安装 ) 的效果可能无法完全实现, 并且可能造成无法预料的后果 b 对于系统组件样本, 请与责任工作人员面谈, 确定最近变更 这些变更可追溯到相关变更控制文档记录 每次检查变更时, 执行下列步骤 : 影响记录 确认每次抽取的变更样本的变更控制文档记录已包含影响记录 被授权方的变更审批记录 确认每次抽取的变更样本都有被授权方的审批记录 应记录变更影响, 以便所有相关方能针对任何处理中的变更制定相应计划 获被授权方批准表明该变更是组织认可的经批准的合法变更 功能测试, 以确认该变更未对系统安全性造成不利影响 a 对于每次抽取的变更样本, 确认已执行功能测试, 以证实该变更未对系统安全性造成不利影响 b 对于自定义代码变更, 确认在将其部署到生产环境前, 所有更新均经过测试符合 PCI DSS 要求 6.5 通过执行全面的测试, 确认环境的安全性未因实施变更而降低 应通过测试确认在环境发生任何变更后, 所有现行安全控制措施仍然有效 为同样有力的控制措施取代或得到加强 取消程序 确认每次抽取的变更样本都有取消程序 每次变更都应有取消程序的书面记录, 如果变更失败 或对某个应用程序或系统的安全产生不利影响, 即可 将系统恢复到之前的状态 第 51 页

52 6.4.6 完成重要变更后, 须对所有新的或变更的系统和网络实施所有相关的 PCI DSS 要求, 并在适当情况下更新文档记录 对于重大变更样本, 请检查变更记录 与工作人员面谈, 并查看受影响的系统 / 网络, 确认已实施适用的 PCI DSS 要求, 并更新作为变更一部分的文档记录 通过流程分析重大变更有助于确保所有适当的 PCI DSS 控制均已应用于范围内环境中任何已添加或变更的系统或网络 将此验证嵌入变更管理流程中有助于确保设备清单和配置标准保持最新, 并在需要时应用安全控制 变更管理流程应包括能够证明已实施或者通过迭代过程保留 PCI DSS 要求的支持性证据 可能受影响的 PCI DSS 要求示例包括但不限于 : 更新网络图以体现变更 按照系统标准配置系统, 更改所有默认密码并禁用不必要的服务 通过必要的控制 ( 例如, 文件完整性监控 (FIM) 杀毒 补丁 检查日志 ) 保护系统 未存储敏感验证数据 (SAD), 记录了所有持卡人数据 (CHD), 并将其并入数据保留政策和程序中 将新系统包含在季度漏洞扫描流程中 第 52 页

53 6.5 按照以下方式处理软件开发流程中常见的编码漏洞 : 至少每年对开发人员进行一次最新安全编码技术方面的培训, 包括如何避免常见编码漏洞 根据安全编码指南开发应用程序 注 : 在本版本 PCI DSS 发布时, 已采用行业最优方法将 到 中列举的漏洞保持为最新 但当有关漏洞管理的行业最优方法 ( 例如 OWASP 指南 前 25 大高危软件错误 CERT 安全编码等 ) 出现更新时, 这些要求必须采用当下最新的最优方法 6.5.a 检查软件开发政策和程序, 确认已要求开发人员至少每年参加一次基于行业最优方法和指南的安全编码技术方面的培训 6.5.b 检查培训记录, 确认软件开发人员至少每年接受一次关于安全编码技术的最新培训, 包括如何避免常见编码漏洞 6.5.c 确认设有适当的流程, 至少能够防止应用程序存在以下漏洞 : 应用层是高风险层, 可能成为内部和外部威胁的目标 要求 至 属于应具备的最低控制要求, 组织还应纳入其环境中特定技术适用的相关安全编码实践 应用程序开发人员应经过适当培训, 从而识别并解决与这些 ( 及其他 ) 常见编码漏洞相关的问题 拥有熟悉安全编码指南的员工能够最大限度地减少通过拙劣编码实践引入的安全漏洞数量 针对开发人员的培训可由内部或第三方提供, 且应适用于所采用的技术 随着行业认可的安全编码实践变更, 组织编码实践和开发人员培训也应相应地更新, 以解决新威胁 ( 例如, 内存刮擦攻击 ) 至 中确定的漏洞提供最低基准 与漏洞趋势保持同步并将适当的措施并入安全编码实践取决于组织 注 : 下文的要求 至 适用于所有应用程序 ( 内部或外部 ) 注入攻击, 特别是 SQL 注入 同时还须考虑 OS 命令注入 LDAP XPath 等其他注入攻击 检查软件开发政策和程序并与责任工作人员面谈, 确认已通过以下编码技术解决了注入攻击 : 验证输入, 以确认用户数据无法修改命令和查询的意思 利用参数化查询 注入攻击, 特别是 SQL 注入, 是破坏应用程序的一种常用方法 当用户提供的数据作为命令或查询的一部分被发送到解释器时, 就发生了注入 攻击者的恶意数据会诱导解释器执行非计划的命令或修改数据, 并允许攻击者通过应用程序攻击网络内的组件, 以发起攻击 ( 例如缓冲区溢出 ), 或泄露机密信息和服务器应用程序的功能 信息在发送到应用程序前应经过验证 ( 例如, 通过检查所有字母字符 字母与数字混合字符等 ) 第 53 页

54 6.5.2 缓冲区溢出 检查软件开发政策和程序并与责任工作人员面谈, 确认已通过以下编码技术解决了缓冲区溢出 : 验证缓冲区边界 截取输入字符串 非安全加密存储 检查软件开发政策和程序并与责任工作人员面谈, 确认已通过以下编码技术解决了非安全加密存储 : 防止密码攻击 采用强效加密算法和密钥 非安全通信 检查软件开发政策和程序并与责任工作人员面谈, 确认已通过对所有敏感通信进行适当验证和加密的编码技术解决了非安全通信 不正确的错误处理 检查软件开发政策和程序并与责任工作人员面谈, 确认不正确的错误处理可采用不会通过错误消息泄露信息的编码技术解决 ( 例如通过返回一般而非具体的错误详情 ) 当应用程序在其缓冲区空间上没有适当的检查范围时, 则发生缓冲区溢出 这可能造成缓冲区内的信息被挤出缓冲区存储空间, 而进入可执行的存储空间 当发生这种情形时, 攻击者能在缓冲区的末端插入恶意代码, 并通过促使缓冲区溢出将该恶意代码推入可执行的存储空间 随后, 攻击者将执行该恶意代码并经常借机远程访问该应用程序和 / 或被感染的系统 未适当利用强效加密功能存储数据的应用程序受到威胁 泄露验证凭证和 / 或持卡人数据的风险会增大 如果攻击者能够利用薄弱的加密流程, 他们便能获得加密数据的明文访问权 未采用强效加密法对网络流量进行充分加密的应用程序受到威胁和泄露持卡人数据的风险会增加 如果攻击者能利用薄弱的加密流程, 他们或许便能控制应用程序, 甚至获得加密数据的明文访问权 应用程序可能会无意中泄露关于其配置或内部工作方式的信息, 或通过不正确的错误处理方法泄露专用信息 攻击者会利用这一漏洞窃取敏感数据, 或威胁整个系统 如果恶意个人能够创建应用程序未正确处理的错误, 他们便能获得详细的系统信息 创建拒绝服务中断 引起安全故障, 或导致服务器崩溃 例如, 提供的密码不正确 这一消息就在告诉攻击者其提供的用户 ID 是正确的, 他们应该只关注攻击密码 使用较通用的错误消息, 例如 数据无法验证 漏洞识别流程中确认的所有 高风险 漏洞 ( 具体规定请参阅 PCI DSS 要求 6.1) 检查软件开发政策和程序并与责任工作人员面谈, 确认编码技术可按照 PCI DSS 要求 6.1 中的规定, 解决任何可影响应用程序的 高风险 漏洞 所有通过组织漏洞风险等级流程 ( 具体规定请参阅要求 6.1) 确定为 高风险 的漏洞以及可能影响应用程序的漏洞均应在应用程序开发期间识别并解决 第 54 页

55 注 : 下文的要求 至 适用于网络应用程序和应用程序接口 ( 内部或外部 ): 跨站脚本 (XSS) 检查软件开发政策和程序并与责任工作人员面谈, 确认已通过以下编码技术解决了跨站脚本 (XSS) 所有参数在应用前均进行验证 利用上下文相关的转义 面向内部和外部 ( 公众 ) 的网络应用程序因其架构特性具有独特的安全风险, 较易受到威胁 每当应用程序接收用户提供的数据并在未首先验证或编译内容的情况下将其发送到一个 Web 浏览器时, 便会发生 XSS 攻击 攻击者可通过 XSS 在受害人的浏览器中执行脚本, 从而劫持用户会话 破坏网站外观, 并可能引入蠕虫等 不正确的访问控制 ( 例如不安全的直接对象引用 未能限制网址访问 目录遍历和未能限制用户的功能访问 ) 检查软件开发政策和程序并与责任工作人员面谈, 确认不正确的访问控制 ( 例如不安全的直接对象引用 未能限制网址访问和目录遍历 ) 可通过以下编码技术解决 : 正确的用户验证 净化输入 不向用户暴露内部对象引用 不允许访问未授权功能的用户界面 当开发人员将引用作为 URL 或形式参数暴露给内部执行对象 ( 例如文件 目录 数据库记录或密钥 ) 时, 则发生直接对象引用 攻击者可利用这些引用在未授权的情况下访问其他对象 始终对所有 URL 执行表示层和业务逻辑的访问控制 通常, 应用程序保护敏感功能的唯一方式是防止向未授权用户显示链接或 URL 攻击者可利用这一漏洞, 通过直接访问此类 URL 来访问和执行未授权的操作 攻击者或许能列举并导航一个网站的目录结构 ( 目录遍历 ), 从而获得未授权信息的访问权并进一步洞悉网站的运行方式, 以供以后利用 如果用户界面允许访问未授权的功能, 则该访问可能导致未经授权的个人获得专用凭证或持卡人数据的访问权 仅允许授权用户获取对敏感资源的直接对象引用 限制数据资源的访问权有助于防止向未授权资源显示持卡人数据 跨站请求伪造 (CSRF) 检查软件开发政策和程序并与责任工作人员面谈, 确认跨站点请求伪造 (CSRF) 可通过确保应用程序不信任由浏览器自动提交的授权凭证和令牌的编码技术来解决 CSRF 攻击会迫使已登录的受害者浏览器向一个存在漏洞的 web 应用程序发送预先验证的请求, 随后攻击者便能执行受害人获准执行的任何状态变更操作 ( 例如更新帐户明细 买入, 甚至验证该应用程序 ) 第 55 页

56 失效的验证与会话管理 检查软件开发政策和程序并与责任工作人员面谈, 确认失效的验证和会话管理已通过通常包含以下方面的编码技术解决 : 安全验证和会话管理可防止未授权个人破坏合法的帐户凭证 密钥或会话令牌, 如若不然, 入侵者可能会占用授权用户的身份 6.6 对于面向公众的网络应用程序, 应不断解决新的威胁和漏洞, 并通过以下任一方法确保这些应用程序不会受到已知攻击 : 利用手动或自动应用程序漏洞安全评估工具或方法审核面向公众的网络应用程序, 至少每年一次并在有任何变更后进行 注 : 本评估与要求 11.2 中规定执行的漏洞扫描不同 在面向公众的 Web 应用程序前安装可检查和防范网页式攻击的自动化技术解决方案 ( 例如 Web 应用程序防火墙 ), 用以不断检查所有流量 6.7 确保已记录 正在使用且所有相关方了解用于开发和维护安全系统和应用程序的安全政策和操作程序 将会话令牌 ( 如 Cookie) 标记为 安全 不要暴露 URL 中的会话 ID 成功登录后添加适当超时和轮换会话 ID 6.6 对于面向公众的网络应用程序, 确保以按如下方式采用以下任一方法 : 检查流程文档记录 与工作人员面谈并检查应用程序安全评估记录, 确认面向公众的网络应用程序已按以下方式审核 ( 采用手动或自动漏洞安全评估工具或方法 ): - 至少每年执行一次 - 在任意变更之后 - 由专注于应用程序安全的组织进行 - 至少要求 6.5 中的所有漏洞均包含在评估中 - 所有漏洞均已修复 - 修复漏洞后重新评估应用程序 检查系统配置设置并与负责人员面谈, 确认已按如下方式采用可检测并防范网页式攻击的自动化技术解决方案 ( 例如, 网络应用程序防火墙 ): - 位于面向公众的 web 应用程序之前, 用以检查并防范网页式攻击 - 积极运行且为最新 ( 若适用 ) - 可生成检查日志 - 配置为阻止网页式攻击, 或生成需立即调查的警报 6.7 检查文档记录并与工作人员面谈, 确认用于开发和维护安全系统和应用程序的安全政策和操作程序均 : 已记录 使用, 并 为所有相关方所了解 面向公众的网络应用程序是攻击者的主要目标而编码不良的网络应用程序使攻击者能轻松访问敏感数据和系统 要求审核应用程序或安装 web 应用程序防火墙的目的在于减少不良编码或应用程序管理实践对面向公众的 web 应用程序造成的威胁数量 手动或自动漏洞安全评估工具或方法可用于审核和 / 或测试应用程序中的漏洞 Web 应用程序防火墙可过滤并阻止应用层的非关键流量 正确配置的 web 应用程序防火墙与基于网络的防火墙配合使用, 可防止应用程序编码不当或配置不当时的应用层攻击 这可以通过将技术和流程相结合来实现 基于流程的解决方案须具有能够促进及时响应警报的机制, 以满足此要求的目的, 即防止攻击 注 : 专注于应用程序安全的组织 可以是第三方公司或是内部组织, 只要审核者专注于应用程序安全并表现出不依赖开发团队的独立工作能力即可 工作人员需了解并遵守安全政策和操作程序, 始终确保系统和应用程序的安全开发和漏洞防护 第 56 页

57 实施强效访问控制措施 要求 7: 按业务知情需要限制对持卡人数据的访问 为确保仅被授权人员能访问关键数据, 必须根据知情需要和工作职责, 通过适当的系统和流程来限制访问 知情需要 只授权访问执行工作所需的最低限度的数据量和权限 7.1 仅有工作需要的个人才能访问系统组件和持卡人数据 为每个角色定义访问需要, 包括 : 每个角色依据工作职能需要访问的系统组件和数据资源 访问资源所需的权限级别 ( 例如用户 管理员等 ) 将特权用户 ID 的访问权限限制为执行工作职责所需的最小权限 7.1 检查访问控制的书面政策, 并确认该政策包含如下要求 至 7.1.4: 为每个角色定义访问需要和权限分配 将特权用户 ID 的访问权限限制为执行工作职责所需的最小权限 基于个人的工作分类和职能分配访问权限 被授权方对所有访问的审批记录 ( 电子或书面形式 ), 包括获批的特定权限列表 选择角色样本, 确认已定义每个角色的访问需求, 包括 : 每个角色依据工作职能需要访问的系统组件和数据资源 确定每个角色执行工作职能所需的权限 a 与负责分配访问权限的工作人员面谈, 确认对特权用户 ID 的访问权限 : 只分配给明确需要此类特权访问的角色 限制为执行工作所需的最小权限 b 抽样选择具有特权访问权限的用户 ID 并与相关管理人员面谈, 确认所分配的权限 : 为其工作职能所需 限制为执行工作所需的最小权限 访问持卡人数据的人越多, 用户帐户遭受恶意使用的风险便越高 只为具有正当业务理由的人提供访问权限有助于组织避免因经验不足或恶意企图导致的持卡人数据错误处理 为了只允许有需要的个人访问持卡人数据, 首先要定义每个角色 ( 例如, 系统管理员 呼叫中心人员 店员 ) 的访问需要 每个角色需要访问的系统 / 设备 / 数据, 以及每个角色有效执行所分配任务所需的权限级别 明确角色和相应的访问需求后, 便可以相应地向个人授予访问权限 分配特权 ID 时, 应仅为个人分配执行工作所需的权限 ( 即 最小权限 ) 例如, 不得为数据库管理员或备份管理员分配与整体系统管理员一样的权限 分配最小权限可帮助预防对应用程序不甚了解的用户错误地或意外地更改应用程序配置或更改其安全设置 执行最小权限还能在非授权人员访问用户 ID 时最大限度地缩小损失范围 第 57 页

58 7.1.3 基于个人的工作分类和职能分配访问权限 需要指定所需权限的被授权方作出的书面批准 抽样选择用户 ID 并与相关管理人员面谈, 确认已基于个人的工作分类和职能分配权限 抽样选择用户 ID 并对比书面批准文档记录, 确认 : 已分配权限具备书面批准文档记录 由被授权方进行批准 指定的权限与分配给个人的角色匹配 为用户角色定义访问需要 ( 根据 PCI DSS 要求 7.1.1) 之后, 可根据工作分类和职能, 使用已创建的角色轻松授予个人访问权限 书面批准文档记录 ( 例如, 以书面或电子形式 ) 可确保有访问权限的人员为管理人员所知晓并授权, 且其访问为工作职能所需 7.2 为系统组件建立访问控制系统, 以根据用户的知情需要限制访问, 并将系统设为 全部拒绝, 特别允许访问时除外 该访问控制系统必须包含以下内容 : 7.2 检查系统设置和供应商文档记录, 确认按以下方式实施访问控制系统 : 所有系统组件范围 确认所有系统组件的访问控制系统均已到位 基于工作分类和职能为个人分配权限 确认访问控制系统配置为基于工作分类和职能执行个人权限分配 如果没有根据用户知情需要限制访问的机制, 则可能会在无意中授权用户访问持卡人数据 访问控制系统自动执行限制访问和分配权限的流程 另外, 默认的 全部拒绝 设置可以确保除非建立特别授权访问的规则, 否则无人能获得访问授权 为管理用户访问, 实体可具有一个或多个访问控制系统 注 : 有些访问控制系统默认设为 全部允许, 因此除非建立特别拒绝访问的规则, 否则会允许访问 将 全部拒绝 设为默认设置 7.3 确保已记录 正在使用且所有相关方了解用于限制持卡人数据访问的安全政策和操作程序 确认访问控制系统具备默认的 全部拒绝 设置 7.3 价差文档记录并与工作人员面谈, 确认用于限制持卡人数据访问的安全政策和操作程序均 : 已记录 使用, 并 为所有相关方所了解 工作人员需了解并遵守安全政策和操作程序, 始终确保访问得以控制并以知情需要和最小权限为依据 第 58 页