PCI DSS 3.0对于商家最重要的五方面影响

安全
PCI DSS 3.0版的变更主要是说明和增补信息,基于这些变化的范围,本文将介绍最受商家关注的五个方面。

遵守PCI合规的大多数安全专家肯定已经知道,PCI安全标准委员会(SSC)已经发布了支付卡行业数据安全标准(PCI DSS)3.0版。

正如在过去所做的那样,SSC发布了PCI DSS 2.0版到3.0版的变更汇总。如果你是商家或者评估者,从现在到1月份,这两份文件(这个概要以及新版本本身)都应该列在你的阅读清单中,因为1月份新要求将会生效。

当在2010年推出PCI DSS 2.0版时,该委员会预计,该标准的不断成熟化会减少对变更的需要,换句话说,随着标准不断演变,以及新版本的推出,对新要求的需求应该会减少。因此,并不奇怪的是,PCI DSS 3.0版的变更主要是说明和增补信息,(大部分)并不是新要求。

这就是说,与从PCI DSS 1.2.1版到2.0版的过渡不同,3.0版只有一些变更的(新)要求,这些变更反映了商家和攻击者的技术使用方式的变化。具体来说,从PCI DSS 1.2.1版到PCI DSS 2.0版只有两个变更,从2.0版到3.0版则包含20个。当然,我们不能深入讲解每个变更,基于这些变化的范围(在新要求和增补信息或说明之间),我们试图总结了最受商家关注的五个方面。具体来说,对于大部分商家(还有评估人员)来说,下面是可能带来最大影响的五个变更。

第一个方面:穿透测试

也许对现有要求的最明显的变更是穿透测试要求(11.3),包括验证用于隔离持卡人数据环境(CDE)和其他环境的方法的要求(11.3.4)。这一变化的适用范围我们已经在其他文章中讨论过,这部分更新可能给商家带来的挑战在于这个要求:穿透测试活动(内部和外部)现在应该“以行业认可的穿透测试法为基础”,例如专门提到的NIST SP 800-115(《信息安全测试与评估技术指导》)。

好消息是,要求11.3到2015年6月30日才生效,商家们还有一段时间来适应这个变更。坏消息是,很多商家可能难以遵守这个要求,至少在最初阶段。为什么这么具有挑战性呢?主要是因为穿透测试是一个专门的学科,很多商家(特别是较小型商家)没有内部人员能够有效执行穿透测试。商家通常会利用外部服务提供商来满足穿透测试要求;很多这些服务提供商(不点名)的产品并没有基于任何规范的方法。当然,也有服务提供商利用了侧重过程的标准,例如SP 800-115,其中详细说明了在测试阶段需要遵守的具体程序,或者利用以执行为重点的技术标准,例如Penetration Testing Execution Standard或者(对于应用)OWASP Testing Guide(提供技术指导);但总的来说,这并不是规范的情况。

正因为如此,商家必须要谨慎选择穿透测试服务以确保他们选择的供应商采用的程序遵守行业认可的方法。作为首要工作,所有准备PCI DSS 3.0合规计划的商家都应该采用行业认可的方法(你企业认为合适的方法)作为穿透测试请求建议。

第二个方面:系统组件清单

虽然在媒体方面没有很多讨论,但从实际角度来看,另一个可能带来潜在巨大影响的新要求(2.4)是:“保留一份PCI DSS范围内系统组件的清单。”这里的“系统组件”在该标准的第10页(PCI DSS要求的范围)有详细介绍,但本质上它是指持卡人数据环境内的所有硬件(虚拟或物理主机及网络设备),以及软件组件(自定义或商业产品、现成的应用,无论是内部还是外部)。

该要求的测试程序明确要求评估员“检查系统清单,确认已保留一份软硬件组件列表,并包含各自的功能/用途描述”;也就是说,商家不仅需要记录持卡人数据环境中所有组件,还需要描述这些组件的功能以及用途。11.1.1要求(与此相关)现在要求商家“保留一份授权的无线接入点清单,包括业务理由记录”。

我们都知道,保持清单的更新并不容易。历来,商家对保持清单(包括持卡人数据位置、可以访问加密密钥和持卡人数据的人员,以及防火墙规则和描述)的要求一直难以满足。为什么呢?因为这种清单经常变化,经常需要手动工作来准确反映环境实际组件情况。因此,在没有自动化的大型或复杂的环境,维持硬件和软件组件的可靠清单几乎成为不可能完成的任务(任何曾经试图努力维护过这种清单的人都能证明这一点),至少是不容易。

当涉及虚拟化(因为系统组件也包括虚拟镜像)或者当环境分布在多个地理位置(大多数分布式零售店都是这样)时,更是加剧了这种复杂性。同时,当专有的供应商提供的系统是由外部人员(例如应用供应商或系统集成商)维护时,也会提高复杂性。对于一个本身就难以满足的要求,这些因素无疑是雪上加霜。毫无疑问,商家们的IT和合规团队将需要花大量时间来开发和钻研方法以创建和管理这种清单。

第三个方面:供应商关系

12.8.5和12.9要求现在要求明确由各个服务提供商和实体管理的PCI DSS的信息。例如,如果企业使用托管数据中心供应商,该数据中心的物理访问限制可能由该供应商管理,而对这些位置访问权的管理方面可能是由客户企业管理。在这种情况下,PCI DSS 3.0要求商家明确同意并以书面形式确认这种与供应商或服务供应商的职责分配。

这种要求意味着,现在商家不仅需要维护供应商清单(这是3.0之前的要求),以及当其服务与其CDE交互时追踪其合规状态(也是3.0之前的要求),而且要明确对于PCI DSS要求,每个适用的供应商的相应的责任分配,还必须与供应商签署书面协议。

维持和管理这些不同的要求在实践中可能具有挑战性。为什么呢?主要有两个原因:首先,它涉及检查所有CDE相关的供应商(理想情况下,商家有这个清单,因为他们应该在追踪供应商的PCI合规状态);第二,它涉及准确分析每个特定供应商的使用情况。在实践中,商家必须明确知道供应商或服务供应商在做什么(以确定其范围),控制职责应该如何划分,以及如何创建文档来描述这些事情。接下来是有趣的部分:让相关的服务供应商(注意,他们看待问题的方式可能与你不同)同意并签署书面协议。曾经参与过供应商协商的人会告诉你,协商这些问题(特别是在已经与服务供应商签署合同后)将是耗时的工作,而且可能会出现争议(这取决于供应商)。

第四个方面:反恶意软件

要求5.1.2现在要求商家:“对于通常不受恶意软件影响的系统,需要执行定期评估以确定并评估不断进化的恶意软件威胁”。这意味着,如果你使用的系统通常不会受到恶意软件感染(例如大型机或Unix服务器),你需要部署一个程序确保保持这种状态,如果这些平台出现一些恶意软件,你需要知道这个情况。要求5.3现在要求必须从管理层获得明确授权,才能禁用或更改杀毒机制的运作,并且,这种授权是有时间限制的。

对于不同的企业,这些要求可能会有一定的影响,特别是第二个要求。在PCI DSS 2.0中,该标准仅要求部署防病毒软件,并且它是运行的,还有更新或最新版本,且必须具有生成日志的能力。这些要求是可以满足的,无论谁安装这个工具,它是如何被安装(在合理范围内,只要它不影响上述要求)或如何被配置。但现在事情不是这样了。现在,商家必须防止用户禁用或更改杀毒机制(这可能需要特定的配置),并需将杀毒系统配置为利用这种能力。这可能同时需要更高水平的技术规划(因为这可能会影响防病毒工具和OS配置)以及部署策略来在整个CDE验证这种能力。毫无疑问,大多数商家将会通过更多文书工作来满足这一要求,但这种变化并不会像上述要求那么难以应对。

第五个方面:物理访问和PoS机

9.3要求现在要求商家控制现场人员对敏感区域的物理访问,这种访问必须获得授权,且根据个人的工作职能,同时,当访问终止时,访问权应随即被撤销。9.9要求现在要求商家“保护通过直接接触卡本身便可捕获支付卡数据的设备,以避免设备被篡改和替换”。大多数商家可能已经在试图满足9.9要求,但如果有商家仍然在零售点使用服务器机柜来存放纸巾,现在可能是时候停止这种行为了。

不过,满足9.9要求可能有点麻烦。为什么呢?试想一下,从商家的角度来看,哪里最有可能适用:零售点、餐馆、医生办公室、食品车、出租车和其他独特的零售环节。这些零售商习惯于“定期检查”销售点终端设备(PoS)吗?例如检查序列号以确保设备没有被更换。不太可能。想象一下,对跨多个地理位置分散的零售点进行这种检查需要付出多少努力。同样地,用于该要求的测试程序特别明确验证政策/程序包含“保存一份设备列表”。有多少商家现在有自己的PoS设备列表?虽然这肯定是一个很好的做法,但现实是,很少有商家这样做。对于站点管理员或零售场所管理者,这一切很可能是全新的概念,可能需要相当多的社会化、准备和人员培训来全面展开。

总结

正如你所知道的,对于这些新的和更新的要求,有些商家需要做很多工作。请注意,上述这些并不是唯一的变化,当然,具体使用环境和企业文化将会影响企业对这些要求的满足。然而,这些是对商家影响最大的PCI DSS 3.0变化,至少在过渡期内是这样。在某些情况下,这些影响是很明显的(例如穿透测试),可能对于有些人来说,只有在着手执行这些要求(例如盘点系统组件)时,才会意识到这些影响。无论如何,商家必须现在开始规划以确保他们已经准备好应对这些变化。否则,在2014年或2015年的第一次PCI DSS 3.0评估可能不会是一次愉快的经历。

责任编辑:蓝雨泪 来源: TechTarget中国
相关推荐

2011-11-09 09:26:55

虚拟化云计算vSphere 5.0

2009-10-16 11:15:38

Windows 7

2011-11-10 09:32:41

虚拟化vSphere 5.0存储I

2015-11-13 09:50:17

数据中心运营

2009-12-09 11:40:02

Linux防火墙

2013-05-03 17:00:26

云架构师SOA云计算

2021-07-12 18:11:41

5GVR医疗发展

2015-01-06 15:25:12

DockerDocker Volu数据容器

2013-01-09 10:52:29

云架构师架构师云计算

2019-02-13 14:26:00

2023-03-23 10:53:38

5G物联网

2015-12-01 11:12:15

令牌化技术PCI DSS合规

2009-07-09 08:14:54

Chrome操作系统上网本Google

2023-06-27 10:21:14

2010-12-16 11:03:07

2015-06-03 09:28:33

2012-12-11 14:53:11

2013-09-13 10:19:27

iOS 7IT

2014-01-23 09:36:12

云计算合规PCI DSS 3.0云计算
点赞
收藏

51CTO技术栈公众号