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 和…