扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
文档历史
版本 |
日期 |
作者 |
变更 |
|
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的相应内容了解全部变更细节。
本文适用于各支付行业的服务供应商、商户及收单行的技术和管理人员使用。为加深对新版本的理解，建议对原版本做相应的了解，原版本中未变化的部分在本文中不再罗列。本文所涉及的内容重点在PCI-DSS标准，并未对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”等均给出了更明确的定义。
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或无线的入侵检测系统对无线接入点进行检查。 |
添加了物理和逻辑监控、网络访问控制等方法进行检查，使得方法的选择更为灵活，明确只要达到有效探测到非授权设备即可。 |
