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

PCI DSS 的当前版本是 3.2.1，于 2018 年 5 月发布。 要求 6 指出您必须“开发和维护安全的系统和应用”。  当然，没问题。 这是非常清楚和简单的 — — 至少对于那些从未尝试开发和维护安全系统和应用的人来说是这样！ 对于我们其他人来说，这是一个艰巨的任务。 

但该文件接下来列出了一些相当简单的要求——这些要求已经是大多数安全软件开发生命周期的组成部分。 您应该建立一个流程来识别安全漏洞、解决已知漏洞、采用编码最佳实践、将开发和测试环境及账户与生产环境安全地分开、进行代码审查、进行变更控制流程、培训开发人员安全编码技术等等。 一切都很合理。 

在该顶级要求下更深入一点 - 在要求 6.5 中 - 列出了应用应受到保护的许多特定漏洞。 这些是 OWASP TOP 10、SANS CWE Top 25、CERT 安全编码等的“热门内容”，都是您所期望的 — SQL 注入、弱加密、XSS、缓冲区溢出等。 再次，合理。 攻击者可靠地将这些类型的漏洞作为初始攻击点。 

然后，在要求 6.6 中，最重要的是： “对于面向公众的网络应用，要持续解决新的威胁和漏洞，并确保这些应用受到保护，免受已知攻击。” 哪些攻击？ 它回答说：“至少，要求 6.5 中的所有漏洞。” 想一想。 这个单一要求 - 6.6 - 深埋在第 64 页的文档中，对我们构建和操作软件的方式有着重大影响！ 他们建议如何满足这一要求？ 答案分为两部分：

• 每年检查一次应用程序，并在任何更改后进行检查——使用“手动或自动漏洞安全评估工具或方法”
• 通过使用“检测和阻止基于网络的攻击的自动化技术解决方案” 

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

1. 审查应用以主动发现漏洞的存在（然后确保漏洞得到纠正）

- 和 - 

2. 实时检测并阻止攻击

这根本不是一个坏要求。 正如指南所述，“面向公众的网络应用是攻击者的主要目标，而编码不良的网络应用为攻击者提供了获取敏感数据和系统的便捷途径。” 我非常同意。 挑战在于该要求的实际执行。 

对于如何完成第一部分——审查应用程序，没有提供太多指导。 应该“使用手动或自动漏洞安全评估工具或方法”来审查应用程序。这个范围很广。 

第二部分有一个更具体的建议。 您应该在面向公众的 Web应用前安装“一种可检测并防止基于 Web 的攻击的自动化技术解决方案（例如，Web 应用程序防火墙），以持续检查所有流量”。 这对 WAF 供应商来说是一个福音，他们突然发现自己对于希望满足要求 6.6 的团队来说是一个“复选框”购买。 但是 WAF 对于满足要求的第一部分没有帮助。 WAF 不是安全评估工具： 它不知道应用做什么或如何做。 它只了解发送到应用的内容 — — 而不知道应用可能会（或可能不会）用这些信息做什么。

所有这些都使得许多团队难以解决 6.6 的总体问题。 这一小小的要求包含两个重要且截然不同的需求。 大多数人会尝试使用 WAF 来满足第二部分，并组合许多其他技术来解决第一部分（手动代码审查、自动源代码分析等）。 

但是还有一种替代方案可以通过单一解决方案满足要求 6.6。 您会注意到，PCI 标准在提到 WAF 时包含短语“例如”。 这很重要（并且它没有包含在标准的早期版本中）。 它承认，只要“配置为阻止基于网络的攻击，或生成立即调查的警报”，其他技术也可以保护应用。  应用安全监控是 Threat Stack 免费添加到其 Cloud Security Platform® 的统一应用安全解决方案，解决了要求 6.6 的构建时和运行时方面。 解决这两个重大挑战的一个解决方案。 

在构建时，您可以像任何其他第三方代码库一样将 Threat Stack 微代理添加到您的应用中。 开发人员发现这与使用 APM 解决方案来检测他们的应用程序非常相似。 一旦添加了微代理，应用每次运行时都会进行评估——无论是通过本地手动测试、夜间构建的自动测试还是用户验收测试等等。 PCI 规定应用程序必须“至少每年一次以及在发生任何变化后”接受审查。 Threat Stack 的功能远不止于此，它可以持续识别安全漏洞 — — 而开发人员无需做任何额外的工作。 无需编写测试，也无需管理服务器。

一旦发现漏洞，要求 6.6 还指示必须解决该漏洞。 您必须确保“所有漏洞都已得到纠正，并且在纠正之后重新评估应用”。 Threat Stack AppSec Monitoring 为开发人员提供针对检测到的任何风险的可操作指导 - 解释风险、提供有关如何修复风险的示例代码，并指导开发人员找到发现它的确切模块和方法名称以及文件位置和行号。 一旦开发人员修复了漏洞，就不需要做任何特别的事情来“重新评估”——应用将在下次运行时自动进行评估。 

在运行时，要求是“持续检查所有流量”以保护应用免受已知攻击。 相同的 Threat Stack 微代理也会执行此操作。 当应用从开发部署到生产环境时，微代理也会随之部署（它作为依赖项嵌入到应用中）。 从那里，它会分析发送到应用的所有网络负载，以观察是否有攻击迹象。 如果确定有效载荷是恶意的，则可以立即停止该请求。 团队通过 Threat Stack 门户、Slack 或其他 ChatOps 频道收到有关攻击的通知。 这直接满足了 PCI 要求，即“要么阻止基于网络的攻击，要么生成立即调查的警报”。

PCI 6.6 很大。 “持续解决新威胁和漏洞并确保这些应用免受已知攻击”的任务涵盖软件开发生命周期的两个独立阶段（开发和生产），并涉及两个独立的任务（主动漏洞评估和实时攻击检测与预防）。 两者都很复杂，并且通常涉及不同的团队。 但您不需要两个单独的工具来解决这些问题。 Threat Stack 的应用安全监控通过一个不会减慢开发人员速度的解决方案满足了这两个要求。 今天就试试吧！   

如果您有兴趣了解更多信息或想要试用application安全监控，请注册 Threat Stack 云安全平台的演示。 我们的合规和安全专家将很乐意讨论您的具体要求。