查看原文
其他

PCI DSS 3.2第三方支付行业安全性提升指南

2016-05-04 E安全 E安全

PCI SSC(全称Payment Card Industry (PCI) Data Security Standard,第三方支付行业(支付卡行业PCI DSS)数据安全标准)日前发布了PCI DSS 3.2,即针对各企业及供应商在客户信用卡及借记卡交易处理方面必须遵循的最新版本技术安全要求。

出现于3.1版本(2015年4月15日发布)一年后的最新升级方案在安全成熟度方面得到极大提升,具体包括敦促系统管理员采用多因素验证机制、要求利用更多渗透与检查手段实现安全控制弹性,并延长了由SSL及早期TLS版本迁移至更新TLS版本的期限。

这一新的客户信用卡与借记卡数据保护标准显示,攻击者正利用窃取或者由社交工程方式骗取的登录凭证轻松接入企业系统内以进一步掠夺客户数据。这些失窃凭证允许攻击者在持卡人数据环境(简称CDE)下冒充合法用户任意妄为而无需担心被发现。

持卡人数据环境(简称CDE)代表用于处理、存储及/或传输持卡人数据的一套计算机系统或IT系统联网体系。其中还包含有任意直接接入或者用于支持这套网络的组件,例如防火墙、交换机、接入点、安全设备、销售点系统、Web服务器、应用服务器、全部应用程序以及虚拟组件等等。


扩展多因素验证机制的使用范

PCI DSS的上个版本要求使用多因素验证以保护指向CDE的远程访问,旨在预防基于接入的数据泄露攻击活动。

而新的多因素验证标准8.3版本则迎来进一步扩展,包括要求任意系统管理员以本地方式接入CDE并强制使用多因素验证——无论是第三方抑或内部多因素机制。系统管理员可以在网络之内变更系统及其它凭证,从而有效防止攻击者肆虐甚至夺取企业系统控制权。

新版本建议大家在企业内部为每位用户添加多因素验证机制。攻击者通常还会将目标设定为非权限用户,包括立足于内部环境进行追踪并搜索可资利用的客户数据。这意味着大家需要为市场营销、人力资源、销售以及其它团队提供与系统管理员相对等的保护措施。

单因素验证(例如用户名加密码)已经无法实现CDE的远程接入,PCI SSC首席技术官Troy Leach介绍称。另外,其描述也由双因素验证变更为多因素验证,旨在声明流程中可引入两种以上验证因素。


如何面向新的8.3子要求标准做好准备

那么企业该如何应对这些变更?根据PCI SSC的官方博客所言,迎接PCI DSS 3.2应做好如下准备:

· 审查现有CDE验证管理方式

· 审查现有管理员角色与访问机制

· 评估新要求提出的验证变更可能造成哪些影响


检测并报告安全控制问题

新的PCI DSS要求10.8及子要求10.8.1要求服务供应商检测并报告其关键性安全控制系统中的问题(将于2018年2月1日起全面生效)。这些控制系统包括防火墙、IDS/IPS(即入侵检测/保护系统)、杀毒、物理与逻辑访问控制、审计登录机制以及细化控制等。

PCI DSS 3.2指出:此举旨在确保相关系统能够警告企业关系性控制机制问题,从而避免因入侵活动未被发现而引发的系统入侵及数据窃取后果。


渗透测试检查与平衡

根据新的子要求11.3.4.1,为了确保弹性,服务供应商现在需要至少每六个月进行一次针对细化控制方案的渗透测试。PCI SSC还添加了一项测试规程11.3.4,旨在确保渗透测试工作由合格的内部或者外部第三方负责执行。


强化安全事务中的人为因素

其它要求则希望确保涵盖安全工作中的管理层面——12.4要求企业高管确保安全政策及规程面向每一位员工的具体信息安全责任实现确切定义。

与此同时,子要求12.4.1还要求高管团队肩负保护持卡人数据及遵循PCI DSS合规计划的责任。

要求12.6要求建立正式的安全意识培训项目,旨在确保企业中的每位个人充分了解持卡人数据安全策略与规程。


迁移至TLS?大家将有更多时间

PCI DSS 3.2现在对SSL/早期版本TLS的迁移时限做出延后,希望增加两周时间以降低面向更安全TLS版本(1.1或者更高)的过渡难度——企业现在需要在2018年7月1日之前迁移至TLS新版本


不受支持的旧应用被视为安全因素

此次要求还提出新的条目,用于限定PCI DSS与PA-DSS(即支付应用数据安全标准)间的关系以约束相关应用程序对持卡人数据的存储、处理或者传输。

“随着安全威胁不断演进,不再受到供应商支持的应用程序(例如已经被供应商确定为‘生命周期结束’)将无法提供与受支持版本相对等的安全性水平。”

这项意见基本上是将任何过时或者不受支持应用程序划为不合格的敏感财务数据载体,这也反映出如今安全威胁开始越来越多地针对旧版本中的已知安全漏洞。

零日威胁几乎很少被作为实际攻击手段——攻击者往往会选择难度更低且更加有效的陈旧bug作为突破口。Windows XP以及IE 10等早期软件版本正是生命周期结束项目的典型代表,这些已经不再拥有官方补丁支持的技术方案在安全性方面自然无法与新版本相提并论。

大家最好的选择是利用软件供应商发布的补丁进行常规升级或者紧急修复,从而确保自身不存在明显的安全缺口。利用Duo公司的Device Insight功能,大家可以找出任何已经过期的设备,甚至利用Endpoint Remediation策略及控制功能将其屏蔽,直到其被升级至最安全版本。


其它PCI DSS 3.2资源

这里还要强调3.2版本制定的时间表:《PCI DSS 3.2计划:关键日期》。其中一项重要日期在于3.1版本的淘汰时间,即2016年10月——3.2版本发布的六个月之后。这意味着一切合规审计评估都将在那时遵循新的3.2版本标准。

大家可查看PCI DSS 3.2的完整版本以及由3.1到3.2版本的变更内容汇总

关于由SSL及TLS早期版本迁移至TLS新版本的概述内容及完整常见问题解答,请查看PCI SSC方面提供的《SSL与TLS早期版本迁移公告:资源指南》(PDF格式)。

上述标记的所有源文件请在E安全微信公众号内回复“PCIDSS”获取。

E安全/文 转载请注明E安全

E安全——全球网络安全新传媒

E安全微信公众号: EAQapp

E安全新浪微博:weibo.com/EAQapp

E安全PC站点

E安全客服&投稿邮箱:eapp@easyaq.com

点击下方”阅读原文“即可下载安装E安全app

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存