Web应用程序和API安全的新规则

事实上，大多数 Web 应用程序和 API 安全工具都是为一个截然不同的时代而设计的。那时，开发人员和安全从业人员还没有合作使用集成工作流程来发布安全软件。那时，应用程序还没有实现全球分布和基于 API。那时，工程师还未期望能够输入命令并立即进行全球更新。但正如我们的首席执行官 Joshua Bixby 所说：“攻击者也是开发人员。”而且，攻击者不会受到传统解决方案的限制。他们像以往一样灵活，使用现代工具和工作流程来构建和推进新的威胁。现在，改变的时机已经到来，这一点从未如此明显。因此，今天，我们制定了新的 Web 应用程序和 API 安全规则，这些规则尊重现代应用程序的构建方式。 

规则 1：工具必须对抗意图，而不是特定的威胁 

安全团队长期以来一直专注于对抗特定威胁。在评估新工具时，他们会问：“这能保护我免受 X 攻击吗？”这些威胁通常是重大新闻事件，如Stuxnet或最近的SolarWinds 黑客攻击。这种评估方式会引导从业者使用寻找特定威胁签名或“入侵指标”（IoC）的工具。IoC 包括已知攻击者的 IP 地址和与恶意软件针对的特定请求 URL 匹配的正则表达式等内容。 

基于签名的工具无法很好地区分合法流量和恶意流量，也无法跟上不断增加的威胁。它们又如何做到呢？最近的报告显示，每天有 超过350,000 个新的恶意软件变种被创建。

我们知道这种模式行不通。我们已经看到这种模式失败了，反病毒供应商无法防范入侵，传统的 WAF 提供商只关注 SQL 注入或跨站点脚本，而机器人缓解工具只关注请求浏览器的用户代理。 

Web 应用程序和 API 安全的新规则要求转向更智能的模型，该模型为安全工具链注入足够的信心，以便从业者可以放心地在有价值的流量前运行系统，而不必担心它会阻止合法尝试或允许恶意尝试通过。 

要实现这一目标，需要对安全技术提出新的要求。首先，从业者必须要求工具不仅检查流量的签名，还要检查其意图或行为。这意味着要考虑请求速度、时间和用户登录状态等因素。 

其次，构建者必须要求工具不仅能在监控模式下运行，还能在阻止模式下运行。由于担心误报而只能在监控模式下运行的工具会强化一个有缺陷的系统：当团队能够做出响应时，损害已经造成。想象一下，一个超级英雄站在街角大喊犯罪，然后等待执法部门的回应，而不是卷起袖子立即采取行动。安全和运营团队被警报淹没了。虽然检测和响应总是有需求的（我们将在稍后讨论可见性和控制时讨论），但团队需要一个工具基础，可以在威胁发生时自信地阻止威胁，而不是在入侵后诊断问题。  

最后，工具需要跟上现代威胁，而不会给安全和运营团队带来负担。借助现代云和 SaaS 解决方案，您可以充分利用产品安全团队的优势，随时应对威胁并主动提供更新。无需担心修补或担心最新威胁。

规则 2：没有可用性就没有安全性 

基于 SaaS 的工具中，直观的消费者式 Web 体验的兴起使得可用性成为大多数技术工具的首要考虑因素。然而，安全解决方案却远远落后。传统工具的设计目的是执行和控制，而不是实际操作。但现代团队希望与他们的工具建立关系。他们需要集成、观察和采取行动的能力。 

用户界面是操作员的第一道防线。不幸的是，这也是可用性被忽视的第一个地方。传统的用户界面可能很慢而且笨重。操作员通常需要登录多个用户界面来管理系统，即使使用来自同一家供应商的解决方案也是如此。糟糕的用户界面会带来多种风险：工具之间的政策和执行存在差距、对紧急威胁的响应缓慢且不协调，以及对整体安全生态系统的可见性不一致（或更糟的是，缺失）。 

安全解决方案应具有单一、直观、易于使用的界面，允许控制和查看整个解决方案。可观察性应包罗万象且集成到一起，以便一目了然地全面了解系统状态。重要的是，这些解决方案应该适用于安全和非安全团队，因为运营和工程部门的更多人员将有能力对抗威胁。 

其次，现代工具必须与现代应用程序设计相匹配。很多时候，工具集只是由提供商打包并一起出售，但实际上无法进行技术集成。我的一个朋友称之为“发票集成”。即使您的系统只是强迫您在选项卡之间切换以浏览解决方案，您在受到攻击时仍会浪费宝贵的时间和集成可见性。这种方法会造成技术和可见性方面的差距，从而削弱您的整体安全态势。提供商应默认提供自动化和集成，从完整的 API 控制开始。所有安全解决方案都应具有易于使用的 API，以公开系统的所有功能。解决方案不仅应易于彼此集成，还应易于与整个响应工具链集成，包括 Jira、PagerDuty、Slack 和 Splunk 等工具。它们还应提供实时日志和统计数据，以公开团队使用的任何安全监控或可观察性系统中的数据。集成所有解决方案可以更轻松地确定攻击者的真实意图。

规则 3：实时攻击需要实时反应   

恶意软件是一种软件系统。软件系统由开发人员构建。因此，攻击者也是开发人员。认识到这一点，我们就能更容易理解为什么威胁会超越传统安全模型。敏捷的攻击者正在采用先进的 DevOps 工作流来快速尝试、调整和部署新方法。在一次攻击中，这种情况可能发生数百次。如果你不能以同样的速度做出反应，你怎么可能保护你的应用程序呢？要明确的是：反应时间不受大脑运作速度的限制。它取决于你的安全解决方案的速度。让我们将其分解为可见性速度和控制速度。

可见速度 

如果要花几分钟或几小时才能发现攻击，那就太晚了。攻击者会尝试一次攻击，如果失败，他们会再尝试一次。所有这些都发生在几分钟内。当您的安全解决方案能够将数据传送到自身或 SIEM 或监控系统时，损害已经造成。实时可见性（以秒为单位）适用于自动和手动工作流程。它允许系统实时应用逻辑进行威胁检查，并为操作员提供对需要人工干预的警报做出反应的能力。在这两种情况下，可见性都必须与控制齐头并进。 

控制速度 

一旦您或您的系统能够发现威胁，响应或补救的速度就至关重要。更智能、基于意图的缓解方法需要多个数据流来做出决策。基于意图的系统作为自学习和自修复系统运行。它们不断分析模式和行为以预测新的或不断发展的威胁，因此它们不仅必须能够实时查看和解释流量，而且还必须能够部署新规则以应对不断变化的威胁。 

值得注意的是，可见性和控制速度不能局限于单一部署或地理位置。分布式系统（多区域和多云部署，或需要保护的分布式劳动力）的盛行需要能够跨物理位置或边界采取行动。我们已经看到一些安全解决方案，只要检测和保护只在一个位置进行，它们就很快。世界不再是那样运作的了——软件和人员部署在全球各地，安全必须跟上。有关此规则的更多信息，请参阅点播网络研讨会“ API-First 安全，实现实时攻击响应”中 API 支持的安全如何实现快速事件响应。

规则 4：无论是开发、安全还是运营，每个人都必须像工程师一样思考 

我们共同见证了从各自为政的团队独立（且痛苦地）开发软件到通过安全的 DevOps 模型实现安全、工程和运营的统一的演变。但我们距离实现任务完成还很远。虽然许多安全和工程领导者认为弥合团队之间的技术和文化鸿沟将带来更快、更安全的应用程序开发周期，但过时的做法和工具仍然阻碍着团队的发展。  

一个值得注意的限制是，安全的 DevOps 更多的是性能艺术而不是真正的集成。将安全操作员及其首选工具固定在部署管道的末端并不意味着您正在进行安全的 DevOps——而且它不会让您的软件交付更快。真正的安全 DevOps 将安全验证和漏洞扫描直接构建到自动化测试和部署框架中。它为安全团队提供了一条作为开发团队的组成部分出现的途径——而不是在最后一刻引入的一道门槛，提交漏洞列表并希望在系统上线前修复它们。反过来，开发人员使用安全的开发实践编写代码，自动化 CI/CD 管道不仅测试功能，还测试常见的安全漏洞。最后，如果自动化系统遗漏了任何东西，安全团队就有技能和权力进行深入的安全审计。 

为了使安全的 DevOps 兑现其承诺，安全从业者、运营专业人员和开发人员都必须采用工程思维，专注于交付安全软件。让我们消除管理安全产品和功能的辛苦，以便安全专业人员可以从操作员转变为工程师。这不仅使整个系统更加可靠和安全，还为员工提供了更充实的职业道路。

更好的安全性对于构建更好的软件至关重要

亚马逊推出 AWS 并启动向云迁移的进程已经十五年了。在这段时间里，我们看到（并且我们中的许多人已经采用了！）数百种新的框架、语言、服务和工具，用于构建更快、更以用户为中心的应用程序。老实说，这很有趣。但是，快速安全地交付软件之间的摩擦仍然是一个症结，原因我们今天实际上可以解决。

减少这种摩擦的途​​径必须包括满足现代团队需求的安全解决方案——将安全性作为构建软件的文化和技术方面不可或缺的一部分。快速交付软件是不够的。我们必须安全地交付高质量的软件。就我们而言，我们将专注于构建符合我们今天概述的规则的Web 应用程序和 API 安全解决方案。

文章来源：The new rules for web app and API security