PCI DSS Requirement 2规定企业必须修改供应商提供的默认密码，但是只有50%的企业合规。专家Mike Chapple在本文中解释了这一现象的原因。

根据Verizon2014年的PCI DSS合规报告，48.9%的企业未能完全满足PCI DSS Requirement 2标准的要求。Requirement 2标准看起来似乎可以简单地概括为“不要使用供应商提供的默认系统密码和其它安全参数”。但是，现在谁不会修改默认密码？如果只是这么简单的要求，为什么这么多机构会被判定为PCI不合规？

事实是，Requirement 2标准的要求比简单地修改默认密码要复杂地多。PCI DSS合规性标准包括相当多的条件，如开发系统配置标准，将每个主要功能部署在不同服务器上，删除不必要的功能，以及加密非控制台管理员的访问操作。Requirement 2标准全文整整六页，对于商家的操作提出了非常详细的要求。

本文将回顾Requirement 2标准中提出的要求及涵盖范围，分析组织需要什么样的技术创建什么样的程序来识别系统的默认密码，进行更并有效地改管理整个过程。

真正的挑战是什么？

认真阅读Verizon的报告，可以发现其对于Requirement 2标准提供了有趣的见解。本节中的32个要求中，只有2个从合规角度的要求列入了管控标准。这两个管控标准都涉及限制使用不必要和不安全的服务，以及记录业务需求。它们都是同样的条款--PCI DSS requirement 2.2.2的具体实施, 其中规定企业必须“确保系统中只启用了标准中必要的服务，协议，进程等”。

这两个管控标准首先指示了审计师“选择系统组件样本，检查启用的系统服务，进程和协议来验证是否只有必要的服务或协议已启用”。在Verizon的分析报告中，只有55.4%的企业符合这一要求。这里的关键是文档。审计人员寻找证据来验证合规性。如果一家公司已经仔细评估过系统上每个服务的必要性，它应该有文件存档来做后盾。如果一家公司没有文档，审计人员就会假定它没有评估业务需求，当然就会不合规。

商家在标准的下半部分2.2.2.b表现得更差，仅有51.5%达标。该标准指示审计人员“识别出任意已启用的不安全的服务，程序或者协议，然后和工作人员核实，这些已启用的不安全服务的配置标准都是合理的，且有文档评估证明”。如果您的组织运行了不安全的协议，如telnet, FTP等，那么它们需要有文档来说明其使用的业务理由。而且该理由必须具有有说服力的论据。

商家应该采取什么措施？

首先，商家必须确保它执行的操作都符合PCI DSS要求。特别注意那些在系统上运行，可能会被审计人员考虑为不安全的服务，为其陈述业务必要性。文档陈述不需要很复杂，可以将其作为配置标准的一部分。例如，如果一个公司在其环境内的每个系统上都运行了一组管理服务，那么配置标准可能包含“所有系统必须运行X, Y, Z管理服务，以促进自动化系统管理任务”这样的内容。关键是，一定要有文档来证实所运行的服务的必要性。

然而，不要只关注文档工作。文档只有能实际支持系统配置时，才是真正有用的。定期依据标准，手动或自动进行系统评估是一个好主意。如果您的组织正在运行一个未记录的服务，那么就应该发现这个服务，为其配备文档或停用它，而不是等到审计人员来发现。

从别人的错误中进行学习

Verizon的PCI合规报告给商家和服务提供商提供了一个难得的机会，可以从别人的错误中进行学习。通过研究别人在PCI合规性旅程中的失足，企业可以避免犯同样的错误。