毫无疑问,美国运通、Visa和万事达等公司建议达成的目前唯一存在的统一政策PCI DSS,确实是巨大的进步。在PCI DSS出现之前,很难找到两家金融机构都统一的标准,或者说很难找到主要支付行业公司为商家提出的标准要求。
PCI确实让支付行业变得更加规范了,但是很多情况下,该标准做得还不够,仍然需要改进。
本文将讨论PCI规范的不利之处,并试图寻找改进PCI的方法,也就是对PCI机构和实践者的建议。
实用主义
很多人认为PCI标准是种实用标准,并且起着警醒的作用。警醒作用确实存在,但是实用主义的功能却不能苟同。
现在的PCI DSS还没有形成有效的“系统”,只是尽量满足安全政策的要求,涉及所有PCI DSS要求。
虽然PCI DSS标准的很多章节都采取了必要的措施(例如定义防火墙要求等),但笔者相信还需要继续改进,PCI应该努力控制“关键系统”(涉及持卡人数据的系统)和“关键网络”。
建议1:为PCI DSS创建新的技术性的附加标准,以补充不足。
建议2:对PCI创建两个独立的审计功能,一个政策层面的功能,另一个是单独的技术审计功能。
现实世界
现在的PCI DSS标准看起来更像是单独的安全政策清单,至少需要能够建立单独环境:一个环境为持卡人相关的数据,另一个单独的环境来承载其他。
例如PCI DSS标准6.1所说:“确保所有的系统组件和软件都更新了供应商提供的罪行安全修补程序,在关键安全补丁发布一个月内务必进行安装。”
为什么不是3天?为什么不是30个月,为什么不是经过彻底的测试呢?
建议3: 重新定义这些章节,清楚明确的指出需要进行定期更改控制程序。
更糟糕的是:“每台服务器只部署一个主要功能”
这里并不是规模问题,每个主要操作系统供应商都为其服务器版本产品系列推出了灵活和全面的功能。每个CIO不仅在宣传其服务器灵活度为系统带来的好处,并且开始使用虚拟工具以追求更高的性能和更高的投资回报。此外,仅使用一个主要功能是完全不切实际的,只会造成混乱。
没有任何研究能够证明一个服务器一种功能能够减少或者增加其安全风险,目前饱受争议的话题就是,最大的安全泄漏都是由值得信赖的人造成的,这个事实并不会因为服务器功能的数量或者类型而改变。
建议4:重新编写与计算现实不相符的章节。
加密
PCI的倡导者和构建者确实迈出了大胆的一步,他们在PCI中加入了数据保留这个问题,但是为什么要这样定义“保持持卡人数据存储为最低限度”?以及另外一个很模糊的定义“限制存储量和保留时间,以符合商业、法律或者监管机构的要求”。
建议5: 这里讨论的信用卡数据,应该明确告诉企业应该符合那些规则。
另一个很好的例子是关于加密的:
首先,在PCI章节3.5是这样:“保护用于加密持卡人数据的密钥,以防泄漏和滥用。”
那么到底什么是密钥?应该如何适当使用密钥来持卡人数据?也都没有说清楚。
建议6: 在技术章节,最好应该定义加密。明确指出哪些允许哪些不允许,以及如何部署加密和规定加密使用的主要法律。
传输加密
另外一个有问题的章节是关于传输加密(Transmittal Encryption):“要求4:对通过开放公开网络的持卡人数据传输进行加密。”
安全人士会发现这里面有两个主要问题:
首先,为什么不再我们的封闭网络中加密呢?我们知道,大多数数据泄漏是有内部人员造成的,这条规定有意义吗?
第二,为什么这里用的是“公开”呢?这可能适用于互联网,但是对于无线连接到公司笔记本电脑的无线接入点呢?网络既不是开放也不是公开的,这里的定义明显是不合适的。
现在再看看对要求4的进一步解释,PCI 4.2:“永远不要使用最终通讯技术(如电子邮件、即时消息、聊天工具等),发送未加密PAN。
这个要求太不清除也有误导性,例如,为什么可以使用其他技术(FTP或者自动化工具)来发送未加密PAN呢?此外,为什么可以使用通讯工具发送掩饰的PAN呢?第二部分不就是意味着可以通过通讯工具发送加密PAN和解密密钥吗?
建议7:修改要求4,能够保证技术上的正确性。
清单
目前PCI DSS准则最大的缺陷在于形式的过于简单,虽然这样能够让很多非技术人员也能看懂,但是安全毕竟不只是列表,虽然有时候审计需要清单,但也需要对技术进行详细说明。
总结
在所有PCI DSS审查中有相当多的技术安全点,希望能够更全面的对技术进行讨论。
虽然说,PCI DSS无疑是向正确的方向迈进了一大步,但是仍然需要改进。应该分为技术和非技术部分,更好地涵盖所有问题。
PCI确实让支付行业变得更加规范了,但是很多情况下,该标准做得还不够,仍然需要改进。
本文将讨论PCI规范的不利之处,并试图寻找改进PCI的方法,也就是对PCI机构和实践者的建议。
实用主义
很多人认为PCI标准是种实用标准,并且起着警醒的作用。警醒作用确实存在,但是实用主义的功能却不能苟同。
现在的PCI DSS还没有形成有效的“系统”,只是尽量满足安全政策的要求,涉及所有PCI DSS要求。
虽然PCI DSS标准的很多章节都采取了必要的措施(例如定义防火墙要求等),但笔者相信还需要继续改进,PCI应该努力控制“关键系统”(涉及持卡人数据的系统)和“关键网络”。
建议1:为PCI DSS创建新的技术性的附加标准,以补充不足。
建议2:对PCI创建两个独立的审计功能,一个政策层面的功能,另一个是单独的技术审计功能。
现实世界
现在的PCI DSS标准看起来更像是单独的安全政策清单,至少需要能够建立单独环境:一个环境为持卡人相关的数据,另一个单独的环境来承载其他。
例如PCI DSS标准6.1所说:“确保所有的系统组件和软件都更新了供应商提供的罪行安全修补程序,在关键安全补丁发布一个月内务必进行安装。”
为什么不是3天?为什么不是30个月,为什么不是经过彻底的测试呢?
建议3: 重新定义这些章节,清楚明确的指出需要进行定期更改控制程序。
更糟糕的是:“每台服务器只部署一个主要功能”
这里并不是规模问题,每个主要操作系统供应商都为其服务器版本产品系列推出了灵活和全面的功能。每个CIO不仅在宣传其服务器灵活度为系统带来的好处,并且开始使用虚拟工具以追求更高的性能和更高的投资回报。此外,仅使用一个主要功能是完全不切实际的,只会造成混乱。
没有任何研究能够证明一个服务器一种功能能够减少或者增加其安全风险,目前饱受争议的话题就是,最大的安全泄漏都是由值得信赖的人造成的,这个事实并不会因为服务器功能的数量或者类型而改变。
建议4:重新编写与计算现实不相符的章节。
加密
PCI的倡导者和构建者确实迈出了大胆的一步,他们在PCI中加入了数据保留这个问题,但是为什么要这样定义“保持持卡人数据存储为最低限度”?以及另外一个很模糊的定义“限制存储量和保留时间,以符合商业、法律或者监管机构的要求”。
建议5: 这里讨论的信用卡数据,应该明确告诉企业应该符合那些规则。
另一个很好的例子是关于加密的:
首先,在PCI章节3.5是这样:“保护用于加密持卡人数据的密钥,以防泄漏和滥用。”
那么到底什么是密钥?应该如何适当使用密钥来持卡人数据?也都没有说清楚。
建议6: 在技术章节,最好应该定义加密。明确指出哪些允许哪些不允许,以及如何部署加密和规定加密使用的主要法律。
传输加密
另外一个有问题的章节是关于传输加密(Transmittal Encryption):“要求4:对通过开放公开网络的持卡人数据传输进行加密。”
安全人士会发现这里面有两个主要问题:
首先,为什么不再我们的封闭网络中加密呢?我们知道,大多数数据泄漏是有内部人员造成的,这条规定有意义吗?
第二,为什么这里用的是“公开”呢?这可能适用于互联网,但是对于无线连接到公司笔记本电脑的无线接入点呢?网络既不是开放也不是公开的,这里的定义明显是不合适的。
现在再看看对要求4的进一步解释,PCI 4.2:“永远不要使用最终通讯技术(如电子邮件、即时消息、聊天工具等),发送未加密PAN。
这个要求太不清除也有误导性,例如,为什么可以使用其他技术(FTP或者自动化工具)来发送未加密PAN呢?此外,为什么可以使用通讯工具发送掩饰的PAN呢?第二部分不就是意味着可以通过通讯工具发送加密PAN和解密密钥吗?
建议7:修改要求4,能够保证技术上的正确性。
清单
目前PCI DSS准则最大的缺陷在于形式的过于简单,虽然这样能够让很多非技术人员也能看懂,但是安全毕竟不只是列表,虽然有时候审计需要清单,但也需要对技术进行详细说明。
总结
在所有PCI DSS审查中有相当多的技术安全点,希望能够更全面的对技术进行讨论。
虽然说,PCI DSS无疑是向正确的方向迈进了一大步,但是仍然需要改进。应该分为技术和非技术部分,更好地涵盖所有问题。
pci_dss Says:
2009/10/25 21:46
6.1 为什么是一个月,个人意见是给你足够的时间来验证这个补丁是否对于你的业务安全,如果对你的业务有干扰,你可以给出补偿措施。对于PCI,其实在中国,其实真正完整实施下来,难度是很大的,只是目前国内做PCI审核的两家公司,对有些问题,都放松了!
分页: 1/1
1
1
[转]PCI-DSS合规
标准的PCI决策支持系统



