PCI DSS 2.0:解析PCI评估变更

安全 数据安全
PCI DSS(支付卡行业数据安全标准)和PA DSS(付款申请数据安全标准)的2.0版本即将登台亮相。在官方“发布”PCI DSS 2.0之前,人们可以通过查看该标准委员会的“更改情况摘要”文件对此次所做的改动进行了解。

PCI DSS(支付卡行业数据安全标准)和PA DSS(付款申请数据安全标准)的2.0版本即将登台亮相。在官方“发布”PCI DSS 2.0之前,人们可以通过查看该标准委员会的“更改情况摘要”文件对此次所做的改动进行了解。(编辑注:本文以更改情况摘要中的信息为蓝本。)

站在对 PCI(支付卡行业)进行评估的角度,在对标准所做更改的情况进行具体分析之前,在宏观层次上此次更改体现出两个特征:第一点,更改的幅度相对较小。这一点是人们所没预料到的;该领域不少的专家曾预测新的标准会采用“主要版本/次要版本”的模式来进行发布(与软件产品的发布情况类似)。2008年10月PCI DSS 1.2发布,此后许多人估计今年发布的2.0“主要版本”将会是彻底的改变,但结果却与人们预测的不符。该标准委员会把标准的成熟化作为改动相对较少的原因。因此,企业可以做出这样的预测:未来发布的标准改动将会更少。在过去的五年里,该标注的1.x版本反复出现,导致改动相当大,这使得一些企业遭受了沉重的打击,对他们而言出现上述情况也不失为一件好事。

第二点,更改的执行时间也很合理。换句话说,在企业被要求就它们如何实施了这些标准的更改而进行陈述前,企业还有充分的反应时间。因为这些标准的更改要到2011年才生效,留给他们还有一年的时间。在进行升级评估前,企业还有充分的时间来确保自身的环境处于良好的状态中。

但这些可以带来积极效果的进展不应该成为安全和规则遵从(compliance)管理人员偷懒的借口。尽管大部分的改动意味着控制范围的缩小,但一些较小部分反而会产生更大的冲击。因为这些小部分会涉及到企业目前的业务流程、规则遵从符合的范围,以及企业以往对控制的理解情况。所以,现在正是采取行动、查看更改、对企业的规则遵从计划进行调整的好时机。这时候采取行动将事半功倍。

PCI 2.0可能会使评估的影响轻微下降

总而言之,大部分的标准更改意味着PCI评估过程中工作量的减少。更改后的标准为评审员或企业都提供了额外的灵活度,从而可以缩小评估工作的范围,并允许进行有梯度的评估,适用于企业和QSA(质量体系评定)。梯度评估使得企业不会再为争论自己的部署是否符合苛刻的参数而花费大量时间;在和控制范围的描述说明结合在一起后,企业和服务提供商之间耗时巨大的讨价还价的情况就大大减少了,它还能减少质量体系评定时关于意图与实际意义的争论。下表列举了具有以下特点的领域:标准的更改对PCI评估工作没有影响,或者减轻了评估过程的工作强度。

 要求
 被提议的更改
 评估的影响
 PCI DSS简介
 说明: PCI DSS Requirements 3.3和3.4只适用于在PTS(虚拟终端)SRED(安全阅读和数据交换模式)下的 PAN. Align语言
 在大多数情况下,对评估工作会有极小的影响。如果企业或者企业的QSA在过去的评估中将3.3和3.4用于其他持卡人资料,有可能会造成在对工作量进行评估时,评估范围的缩小。
 评估的范围
 说明:所有岗位和持卡人资料的流动应该被确定和记录在文件中,确保对持卡人资料环境的准确界定。
 有可能存在影响的领域(如下所述)
 PCI DSS简介和各种不同的要求
 对系统组件定义的扩展,使其包括虚拟组件。对要求2.2.1进行更新,来说明“一台服务器,一项主要功能”的内涵,并使用虚拟化。
 有可能存在影响的领域(如下所述)
 PCI DSS要求1
 提供对互联网和持卡人资料环境之间的安全边界的说明。
 从描述中来看,还不清楚所谓的说明究竟是什么。不过,当前对将CDE(通用桌面环境)从互联网中分离出来所要进行的控制相对明晰了。这一要求只会带来极小的影响。
 PCI DSS要求3.2
 要认识到这一点,发行人存储敏感的认证数据要有合法的商业需求。 
 发行人的商业要求与对企业和服务提供商进行评估关系不大。对评估所需工作量影响极小。
 PCI DSS要求3.6
 对密钥的改变、废弃和替换的过程进行说明,并增加其灵活性,采用分裂控制(split control)和双重知识。
 从对更改情况的描述中,我们没有获得足够的信息来获悉这一点究竟如何改变。改变的目的是提高灵活性,这也意味着评估工作量的减少。
 PCI DSS要求6.2
 对要求进行更新,允许把不安全因素进行排列,并根据风险大小进行优先化处理。
 这一点使得要求与目前企业所进行的工作更加合拍;在评估过程中,这项要求的实现情况可以用梯度来进行展示。
 PCI DSS要求6.5
 将要求6.3.1融合进6.5 中,消除在对内部和面向Web的应用进行安全编码时的冗余。包括额外的安全编码标准,例如CWE和CERT。
 将这两个领域进行整合,可以带来评估工作量的减少。因为这样一来,对同样的控制,企业和QSA人员就不必进行两次了。
 PCI DSS要求12.3.10
 对要求进行更新,在远程访问时,要求提供对CHD进行复制,移动和储存的正当商业理由。
 这项改动意识到:企业在进行远程访问时,需要对持卡人的资料进行操作。因此,企业在进行这项操作时就不必书写补偿性控制了。

正如你所看到的,除了两个已经提及的领域,该表格中所列项目对评估所造成的影响都相对较小。反而是另外的两个领域,商人和服务供应商或许更乐于保持警惕。

两个需要注意的领域

最值得注意的改变是对PCI评估范围的说明(在上面更改清单的第二个条款里)。然而,该条款还不太明确,特别是如何在最终的文件中体现出范围的改变。但有一点可以肯定,最终文件里需要保留充分的记录,从而让参加评估的人能对范围的改变有所注意。可以明确的是,在上述情况中持卡人的数据流图表应该包括所有岗位和所有领域。

这对许多企业来说是个难题。实际情况表明,许多企业在这一点上并没有满足要求。乍一看,出示企业各个领域的最新持卡人数据流图表并非难事。但是,在一个大型的、具有多种不同业务部门的零售环境中,数据流图表可能只会涉及到一个业务部门,或者是整个企业付款流程系统的一部分。因此,评估范围的改变会促使不同业务部门间加强流动信息的共享(因为一个过程可能关系到多个业务部门),并确保所有的付款流程都在文件材料上体现出来。在进行评估时,相关文件的不足总是主要的问题之一。所以,这项改变也更凸显了原来就存在的一个老问题。

第二点,表面上看对虚拟化进行升级没什么危害,可是我们中的大多数一直面临着这么一个问题,即虚拟化如何与要求联系,例如“一台服务器需具备一项功能”(Requirement 2.2.1)。然而,将“系统组件”的定义扩展,使其包括虚拟化组件,从深层来看似乎有悖于Requirement 2.2.1,而且还会影响到其他的要求。例如,有些要求和测试步骤特别指出所涉及的是“所有系统组件”(Requirements 10.6指出, “系统组件的日志至少要每天检查一次”,Requirement 2.2,“所有的系统组件都需制定配置标准”)。

为“所有系统组件”进行定位的Requirements含蓄地表示,系统组件包括虚拟环境,测试步骤也是如此。因此,测试步骤2.2.a(“检查企业所有类型系统组件的系统配置标准,并核实这些标准是否与行业接受的硬性标准相一致”)意味着不仅企业本身要有一套与虚拟化环境相关的硬性标准,企业的评审员也要拥有和参考那套标准。而在以前的评估中,情况并非如此。

总的来说,对企业和服务提供商而言,该标准的这一版本意味着评估过程的精简,能够从某种程度上减轻由于实施PCI DSS规则遵从而带来的负担。不过,系统组件包括虚拟化组件和升级所需的文件材料又使评估过程变得复杂了。所以,在企业第一次进行PCI DSS 2.0标准评估时,一定要向评审员说明上述两点的情况。不过,从现在就开始对企业现有的控制部署还不能覆盖的领域进行规划仍是一个很不错的策略。

作者:Ed Moyle

责任编辑:佚名 来源: TechTarget中国
相关推荐

2011-02-22 14:32:24

2012-12-11 14:53:11

2010-09-07 12:12:29

2009-06-05 08:39:12

PCI数据安全atsec

2014-07-18 14:44:13

2010-12-13 13:43:16

PCI DSS数据泄漏

2021-06-02 08:37:33

HTTPSPCI DSS合安全检测

2013-08-13 11:26:55

华为eSight华为

2011-12-06 13:23:00

2014-03-25 17:26:19

2014-10-23 13:09:53

2009-09-25 11:03:35

PCI DSS数据完整数据安全

2015-06-11 10:15:01

2011-11-28 16:26:52

SafeNetPCI-DSS

2015-06-03 09:28:33

2014-09-22 10:25:56

应用安全PCI DSSPA-DSS

2014-03-24 10:32:04

携程信息泄露PCI DSS

2010-04-27 12:05:47

2015-12-01 11:12:15

令牌化技术PCI DSS合规

2014-03-24 17:17:10

点赞
收藏

51CTO技术栈公众号