PCIDSS数据安全标准V2.0变更分析
文档历史
| 版本 | 日期 | 作者 | 变更 |
| 0.1 | 2011-01-19 | Xiangdong Gao | Draft |
| 1.0 | 2011-02-09 | Xiangdong Gao | Revise according to Yan and Jinyun suggestion, and release. |
前言
在2010年10月， PCI安全标准委员会发布了新版本的PCI-DSS和PA-DSS标准。作为周期性的新版本发布，该版本主要基于PCI标准在使用过程中各种信息反馈，对数据安全的要求进行完善，并未产生重大的变化。PCI标准主要是卡品牌（Card brand）从持卡人数据所存在安全风险的角度，制定了覆盖数据安全所涉及的各个方面的安全标准。
对于新版本所引入的变更，本文旨在通过新版本与旧版本变化的角度，对新版本所涉及的主要变化进行解读，使读者能较快地理解和掌握标准变更的主要方面。如需要了解所有的变更，感兴趣的读者可通过PCI标委会网站所提供的"Summary of Changes from PCI DSS Version 1.2.1 to 2.0"以及PA-DSS的相应内容了解全部变更细节。
1 变更概述
PCI 安全标准委员会（PCI SSC）最近发布了关于PCI-DSS和PCI PA-DSS的更新版本V2.0。该版本的发布，经过了近两年从客户和厂商收集，并将审议的结果体现于新版本中。值得注意的是，V2.0并未引入新的重大要求。下载地址如下：https://www.pcisecuritystandards.org/security_standards/updates.php
1.1 新标准产生的影响
对于PCI-DSS的变更，整体上趋向于更合理、更严格，同时也更多地引用和借鉴了业界的标准和实践。（具体内容请参照下一章节）
在原版本的PCI PA-DSS中，频繁地引用至PCI DSS，使得客户和评估人员在完成PCI PA-DSS审核时要同时打开两个标准。由此，在PA-DSS的新版本中投入了大量工作以消除PCI-DSS和PA-DSS这两个标准间的信息冗余。
1.2 新标准的转换日期
对于PCI DSS和PA-DSS这两个标准的转换日期是一致的，如下表所示：
|
日 期 |
所应用的标准 |
|
2010年12月31日前 |
V1.2.1 版本用于评估。在2010年不可使用V2.0版本。 |
|
在2011年 |
可使用V1.2.1或V2.0用于评估。V2.0于2011年1月1日正式生效。 |
|
在2012年 |
评估中必须使用V2.0。 |
|
2012年7月1日 |
自该日起，PCI-DSS要求6.2、6.5.6和11.1变为正式要求。在之前，这三个条款为最佳实践。 |
对于当前正基于V1.2.1版本进行评估的用户，意味着还有大约11个月的时间完成评估。客户也可选择在2011年使用V2.0展开评估。总之，在2011年，客户可基于新版本或旧版本展开评估，但在2012和2013年，所有评估必须使用V2.0版本。
atsec在此建议需要通过PCI-DSS标准的组织尽早展开新版本的转换工作，以减少合规建设过程中对信息系统的影响。对于正在开展PCI-DSS合规的组织，推荐使用新版本进行PCI 合规。
2 PCI DSS的变更
以下内容主要侧重于pci-dss的主要变化，因篇幅原因未能覆盖所有变化。
注：本章内容所描述的"原版本"指的是PCI-DSS的V1.2.1版本，"新版本"指的是PCI-DSS的V2.0版本。
2.1 适用性更强
为适应于组织的发展和合规的要求，在新版本中将所涉及适用范围和合规要求方面进行了更加明确的描述，使得某些概念更清晰、要求更明确。同时，也更多地引用了大量的业界标准和最佳实践，使得组织在合规过程中有更多的依据可寻。具体来看，适用性的变化主要体现在如下方面：
2.1.1 引用概念的变化
为更灵活地适应各种组织形式、组织规模以及组织的架构，新版本通过相应的概念变化使得组织在合规过程中的范围更清晰、要求更明确。
|
变化的方面 |
概念的变化 |
备 注 |
|
合规所涉及对象的变化 |
评估对象由旧版本的company变更为新版本的entity。 |
这使得标准所适用的组织范围更广。 |
|
合规所涉及人员的变化 |
组织所涉及的人员由employee变更为personnel。 |
该变化将组织的外部和相关人员均纳入到PCI-DSS的要求之中，通用性更强。 |
|
授权管理人员的变化 |
对管理过程的授权人员由management变更为authorized party。 |
这使得授权和批准过程的管理更适用。 |
除此之外，新版本对PCI DSS所涉及的"介质media"、"现场人员onsite personnel"、"访客visitor"等均给出了更明确的定义。#p#
2.1.2 部分要求的合理化
在原版本的技术要求中，有些要求的通用性不高，使得组织在合规过程中的可选措施较少。新版本更多地关注于技术措施的有效性，在某些点不再局限于具体的某一种技术，使得组织在合规建设中的可选措施的范围更广一些。新版本主要对地址隐藏、帐号安全性要求、公共网络上的信息传输等方面提出了更为合理的技术要求，并在服务器的功能分布方面进行了合理化。主要的变化如下：
|
要求所在的条目 |
原版本的要求 |
新版本的要求 |
|
外向流量的访问（Requirement 1.3.5） |
限制内网到互联网的访问。只能访问到DMZ，由后者转发至互联网。 |
允许内网流量在经过授权的前提下访问到互联网。（访问还需满足requirement 1.3.3非直接连接的要求） |
|
地址隐藏方法（Requirement 1.3.8） |
明确要求使用NAT和使用私有地址空间来隐藏地址。 |
添加了将持卡人数据环境置于代理服务器和内容缓存之内、删除和过滤路由通告等方法以隐藏地址空间。 |
|
“每台服务器一个主要功能”的解释（requirement2.2.1） |
对 “每台服务器一个主要功能”有明确要求，未给出过多解释，使得组织在认证过程中对该要求有较多争议。 |
明确主要功能是处于同一安全级别的功能，这使得在合规过程中服务器上的主要功能的分布更加合理。 同时，明确了虚拟化的系统也视同于一台服务器，以适应于技术的发展和变化。 |
|
特定情况下的敏感认证数据存储（requirement3.2） |
原版本中不允许在任何情况下存储敏感认证数据。 |
允许发卡行或支持发卡服务的公司在业务需要的情况下安全存储CHD。 这使得标准的适用性更强。 |
|
提供公共访问的服务（requirement4.1） |
对于提供公共访问的服务，必须支持最新的补丁版本，使得组织必须频繁地关注于公开服务的最新补丁。 |
要求这些公共访问的服务仅使用安全的配置，并且不支持不安全的版本。这使得公共服务的安全维护更合理，减少了不必要的补丁更新。 |
|
通过公共网络传输主帐号信息的安全措施（requirement4.2） |
在使用消息协议（requirement如邮件、即时消息等）通过公共网络传输主帐号信息时，要求使用强加密对主帐号进行保护。 |
除可使用强加密措施外，也可以使用其它措施把主帐号变得不可读来达到标准的要求。 |
|
分离了WEB程序和常规程序的安全漏洞（requirement6.5） |
WEB和常规程序的安全要求未分离。 |
新版本更新了OWASP更新的TOP10漏洞，并将WEB程序和常规程序的漏洞检查要求分开，使得检查的要求更明确。 |
|
对计算机的访问人员分配唯一的帐号（requirement8） |
未明确不涉及帐号要求的情况，使得帐号管理成为PCI-DSS合规中的难点之一。 |
明确帐号唯一性的所有要求适用于所有管理帐号，包括POS帐号以及用于访问持卡人数据的帐号。此处明确要求所涉及的范围是非客户的用户（non-consumer user），使得组织在合规过程中的技术措施更有针对性。 明确对处理单笔交易用户帐号的适用范围，明确部分要求（包括8.1分配唯一帐号、8.2认证方法、8.5.8不允许组密码、8.5.9每季度更改口令、8.5.10密码长度要求、8.5.11密码复杂度、8.5.12密码历史、8.5.13帐号锁定、8.5.14锁定周期和8.5.15闲置会话超时)不适用于该类帐号，使得帐号的安全要求更合理。 |
|
时间同步的来源（requirement10.4） |
外部更新时间源为特定调频、GPS卫星以及UTC等。 |
明确为特定的、业界可接受的时间源，使得标准的适用性更强。 |
|
无线访问点的检查（requirement11.1） |
要求使用Wireless Analyzer或无线的入侵检测系统对无线接入点进行检查。 |
添加了物理和逻辑监控、网络访问控制等方法进行检查，使得方法的选择更为灵活，明确只要达到有效探测到非授权设备即可。 |
|
入侵检测系统的监控位置（requirement11.4） |
对于持卡人环境的入侵检测和响应，原版本要求监控持卡人环境的所有流量。 |
要求进行边界的检查，并对持卡人环境的关键点进行检查。该变化使得入侵检测系统的监控范围更为合理。 |
|
文件完整性监控的软件要求（requirement11.5） |
使用文件完整性监控软件对关键文件的完整性进行监控。 |
将“软件”的要求变更为“工具”，使得一些系统自带的完整性监控工具也同样可用于标准的合规。 |
|
远程访问时对持卡人数据的操作（requirement12.3） |
明确要求远程访问时禁止拷贝、移动和存储持卡人数据，不存在例外。 |
通过明确业务的需求论证和授权，并对数据进行安全保护的前提下，可对持卡人数据进行授权的操作。 |
|
安全意识教育（requirement12.6.1） |
未提出更明确的要求。 |
明确可基于组织的不同角色及访问持卡人数据的级别进行不同的培训和教育，使得安全意识教育的开展更灵活。 |
#p#
2.1.3 对业界实践的广泛借鉴
在新版本的标准中，更多地借鉴了优秀的业界标准和实践。主要体现在：
|
所在的条目 |
原版本的参照标准 |
新版本的参照标准 |
|
密钥管理流程（requirement3.6） |
要求以至少每年一次的频率定期执行密钥变更。 |
定义了密钥周期（cryptoperiod）的概念，要求组织参照业界实践NIST SP 800-57以及厂商的应用建议制定更新周期。 |
|
安全编码的实践引用（requirement6.5） |
在安全编码方面要求的是参照OWASP。 |
除引用OWASP指导外，还包括SANS CWE top25，CERT secure coding等优秀业界实践的引用。 |
|
风险管理实践的借鉴（requirement12.1.2） |
未定义风险评估所使用的方法论。 |
明确所推荐的风险评估方法论指导，包括OCTAVE、ISO 27005及NIST SP 800-30等。这使得组织在制定适用于自身的风险管理过程有更多的实践参考。 |
2.2 要求更严格
在新版本的要求中，除更加适用外，还对组织的安全措施和审核方面提出了更高要求。为便于进行说明，从组织的安全要求和QSA审核要求两个方面进行展开。
2.2.1 对组织的要求更严格
新版本在漏洞管理流程、系统配置标准的应用、主密钥的替换条件以及无线网络的识别等过程提出了更高要求。其中的主要要求变更包括：
|
所在的条目 |
原版本的要求 |
新版本的要求 （加粗字体为主要的变化） |
|
记录并论证不安全协议的使用（requirement1.1.5） |
原版本仅明确FTP协议作为不安全的协议。 |
而在新版本中，所要求的“不安全协议” 包括了FTP、Telnet、POP3、IMAP、SNMP等存在明文口令传输、漏洞较多的协议。 |
|
互联网与持卡人数据环境间的访问（requirement1.3.1-1.3.7） |
要求明确的网络分段分隔互联网、DMZ区和持卡人数据区域，并且访问是业务所需要的。 |
在论证是业务所必须的前提下，添加要求所有的入站和出站要经过相应的授权。 |
|
对于持卡人数据系统组件的分段，明确要求独立于DMZ区域。 |
对于持卡人数据系统组件的分段，明确要求独立于DMZ区域和不可信网络区域。 |
|
|
地址隐藏方法（requirement1.3.8） |
无相应要求。 |
新版本要求在向外部透露内部地址和路由信息时，必须经过授权。 |
|
个人防火墙的安装范围（requirement 1.4.b） |
要求移动用户须安装个人防火墙软件。 |
添加要求，员工自有的电脑也应使用个人防火墙软件。 |
|
安全配置标准（requirement2.2.b和2.2.d） |
未明确配置标准在何时需要更新。 |
明确在组织识别到新的安全漏洞时，需要进行配置标准的更新，以应对新的安全威胁。 |
|
要求对现有系统应用配置标准。 |
要求除现有系统外，对于新的系统也要应用安全配置标准。 |
|
|
PCIDSS数据安全标准V2.0变更分析
攀枝花网站建设、攀枝花网站运维推广公司-贝锐智能，是专注品牌与效果的网络营销公司；服务项目有等 声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 贝锐智能 贝锐智能技术为您推荐以下文章
|