如何满足PCI DSS要求6.6：Threat Stack一举两得的解决方案

F5生态系统 | 2019年9月04日

Threat Stack现已更名为F5 Distributed Cloud App Infrastructure Protection（AIP）。立即与团队一起开始使用Distributed Cloud AIP吧。

PCI DSS的当前版本为3.2.1，于2018年5月发布。要求6规定，必须“开发并维护安全的系统和应用程序”。当然，没问题。这完全清楚明了，至少对那些从未尝试过开发和维护安全系统及应用程序的人来说是这样！但对其他人而言，这可是一项艰巨的任务。

不过，该文档接着列出了一些相当明确的要求，其中大多已是安全软件开发生命周期的组成部分。应建立识别安全漏洞的流程，修复已知漏洞，采用编码最佳实践，将开发和测试环境及账户与生产环境安全隔离，开展代码审查，建立变更控制流程，并培训开发人员掌握安全编码技术等。这些要求都很合理。

进一步查看该顶层要求下的第6.5项要求，可以看到其中列出了应用应防范的多种具体漏洞。这些漏洞可谓OWASP TOP 10、SANS CWE Top 25、CERT Secure Coding等榜单中的“常见代表”，包括SQL注入、弱加密、XSS、缓冲区溢出等，基本符合预期。这些要求同样合理。攻击者通常会将此类漏洞作为初始攻击的切入点。

接下来是重头戏，即要求6.6：“对于面向公众的Web应用，应持续应对新的威胁和漏洞，并确保这些应用受到保护，免遭已知攻击。”哪些攻击？文中回答：“至少包括要求6.5中列出的所有漏洞。”不妨思考一下。仅这一项深藏在文档第64页的要求6.6，就会对我们构建和运营软件的方式产生重大影响！文中建议如何满足这项要求？答案分为两部分：

每年以及每次变更后，使用“手动或自动的漏洞安全评估工具或方法”审查应用
通过使用“可检测并防范基于Web的攻击的自动化技术解决方案”

因此，这会同时影响 Web 应用的构建阶段和运行阶段，实际上涉及两项完全不同的活动：

1. 审查应用，主动发现其中是否存在漏洞（并确保漏洞得到修复）

以及

2. 实时检测并阻止攻击

这项要求本身完全合理。正如指南所述：“面向公众的Web应用程序是攻击者的主要目标，而代码质量不佳的Web应用程序会让攻击者轻易访问敏感数据和系统。”我对此完全赞同。难点在于如何实际落实这项要求。

关于如何完成第一部分，即审查应用，指南并未提供太多说明。应“使用手动或自动化的漏洞安全评估工具或方法”审查应用。这个范围相当宽泛。

第二部分的建议稍微具体一些。您应在面向公众的Web应用前部署“一种能够检测并阻止基于Web的攻击的自动化技术解决方案（例如Web应用防火墙），以持续检查所有流量”。这让WAF供应商受益匪浅，因为对于希望满足要求6.6的团队而言，WAF突然成了一个只需“勾选复选框”即可完成的采购项。但WAF对满足该要求的第一部分并无帮助。WAF并非安全评估工具：它不了解应用的功能及其实现方式，只能识别发送到应用中的内容，却不知道应用可能会（或不会）如何处理这些信息。

这一切导致许多团队难以全面满足要求6.6。这项看似简单的要求包含两项重要且截然不同的需求。大多数团队会尝试使用WAF满足第二部分，并结合多种其他技术来满足第一部分（如手动代码审查、自动源代码分析等）。

不过，还有一种替代方案，可以通过单一解决方案满足要求6.6。您会注意到，PCI标准在提及WAF时使用了“例如”一词。这一点很重要（早期版本的标准中并未包含该表述）。这表明，只要其他技术“经过配置，能够阻止基于Web的攻击，或生成可立即调查的警报”，也可以保护应用。Application Security Monitoring是Threat Stack免费添加到其Cloud Security Platform®中的统一应用安全解决方案，可同时满足要求6.6在构建时和运行时两方面的要求。一个解决方案，应对这两大挑战。

在构建阶段，可以像添加其他第三方代码库一样，将Threat Stack微代理添加到应用中。开发人员会发现，这与使用APM解决方案对应用进行插桩非常相似。添加微代理后，无论是进行本地手动测试、夜间构建中的自动化测试、用户验收测试等，应用每次运行时都会接受评估。PCI规定，应用必须“至少每年审核一次，并在发生任何变更后进行审核”。Threat Stack在此基础上更进一步，可持续识别安全漏洞，而开发人员无需执行任何额外操作。无需编写测试，也无需管理服务器。

发现漏洞后，要求6.6还规定必须予以修复。必须确保“所有漏洞均已修复，并在修复后重新评估应用程序”。Threat Stack AppSec Monitoring会针对检测到的任何风险，为开发人员提供可操作的指导，包括说明风险、提供修复示例代码，并指出发现风险的确切模块、方法名称、文件位置和行号。开发人员修复漏洞后，无需执行任何特殊操作来“重新评估”，应用程序下次运行时将自动接受评估。

在运行时，相关要求是“持续检查所有流量”，以保护应用免受已知攻击。Threat Stack微代理同样可以满足这一要求。应用从开发环境部署到生产环境时，微代理也会随之部署（它已作为依赖项内置于应用中）。随后，微代理会分析发送到应用的所有Web有效负载，监测其中是否存在攻击迹象。如果确定某个有效负载具有恶意性质，可以立即阻止该请求。团队会通过Threat Stack门户、Slack或其他ChatOps渠道收到攻击通知。这直接满足了PCI关于“阻止基于Web的攻击，或生成警报并立即展开调查”的要求。

PCI 6.6涉及范围广泛。其中，“持续应对新的威胁和漏洞，并确保这些应用免受已知攻击”的要求涵盖软件开发生命周期的两个不同阶段（开发和生产），并涉及两项不同的任务（主动漏洞评估，以及实时攻击检测与防御）。这两项任务都很复杂，通常由不同的团队负责。但无需使用两种不同的工具来满足这些要求。Threat Stack的Application Security Monitoring通过单一解决方案同时满足这两项要求，且不会拖慢开发人员的工作。立即试用！

如果您希望了解更多信息或试用Application Security Monitoring，请注册参加Threat Stack Cloud Security Platform演示。我们的合规与安全专家将与您探讨具体需求。