应用检测和响应(ADR):我们亟需弥补的技术缺口
摘要:将 ADR 作为安全主要手段有很多充分的理由,而且还有更多理由说明其他技术无法满足应用程序的所有安全需求。
检测和响应的概念在网络安全中并不是什么新鲜事——事实上,它是NIST 网络安全框架(CSF) 的核心部分,也是任何健全的网络安全计划的基本组成部分。
无论威胁和恶意活动发生在何处,组织都必须能够检测它们并对其做出响应,这是当前检测和响应领域面临的最大挑战。
大多数检测和响应工具和功能都集中在终端、网络、服务器等设备上,所有这些都需要覆盖,留下了一个很大的空白:应用程序。随着我们看到应用程序在恶意活动中扮演的角色越来越重要,这一空白现在正日益成为攻击目标。
例如,最新的 Verizon 数据泄露调查报告(DBIR)指出,虽然凭证泄露和网络钓鱼窃取等传统攻击媒介占据主导地位,但漏洞利用比上一年度报告增长了 180%。Verizon 表示,漏洞利用现在占 DBIR 记录的所有事件的三分之一。
同样,Mandiant 的2024 年 M-Trend 报告指出,漏洞利用是入侵最普遍的初始攻击媒介,在 38% 的初始入侵中发挥了作用。
所有这些都凸显了对应用程序检测和响应 (ADR) 日益增长的需求,这有助于检测和缓解应用程序运行时可能发生的攻击和入侵。ADR 有助于发现组织在业务过程中推出的众多应用程序中的异常情况。
我们有针对检测和响应的整个安全产品类别,例如端点检测和响应(EDR)、托管检测和响应(MDR)和扩展检测和响应(XDR)。这是理所当然的,因为我们已经看到远程办公、自带设备 (BYoD) 等趋势的大幅增长,所有这些都值得关注端点。
重点关注网络、端点、云和数据等端点和目标,这是有道理的,但从上述报告可以看出,攻击者越来越多地瞄准应用程序及其相关漏洞进行攻击。这强调了对检测和响应能力的需求,将应用程序及其威胁作为优先事项。
AppSec 领域还存在一些挑战,需要进一步关注 ADR。这些挑战包括始终模糊的“共担责任模型”、分布式系统的复杂性以及不断加快的变化速度。
在共担责任模型中,不仅需要考虑底层云服务提供商 (CSP),还需要考虑外部 SaaS 集成、内部开发和平台团队,以及整个组织中的自主团队,这通常会导致系统不透明,责任的开始和结束不明确。除此之外,还需要考虑第三方外包团队、组件和漏洞。
更进一步说,现代系统的分布式特性为漏洞利用和滥用创造了更多机会。现代身份验证和身份提供商就是一个例子,它们都是潜在的攻击媒介,由于不拥有底层基础设施和日志记录,因此对它们的可见性有限。
最后,现实情况是,我们正面临着不断加快的变化。随着行业继续进一步采用 DevOps 和自动化,软件交付周期不断加快。随着 genAI 驱动的副驾驶的使用,这一趋势只会增加。由于无法区分良性和恶意行为应用程序活动,这使得安全工具难以检测和应对潜在攻击。
虽然诸如 Web 应用程序防火墙 (WAF) 和运行时应用程序自我保护(RASP) 之类的工具历来用于保护应用程序,但它们也有自己的缺点和挑战,例如维护复杂且不断变化的规则集或繁琐到可能影响应用程序性能。
现代应用程序可能非常复杂,涉及底层托管环境、基础设施即服务 (IaaS) 提供商、Kubernetes、容器、微服务和各种 API 调用。使用不考虑应用程序完整运行时上下文的工具很难解决所有这些复杂性。
利用应用程序上下文、服务交互、数据流和身份验证活动可以帮助安全团队识别意外和潜在的恶意行为,并且可以更好地准备快速遏制、缓解和补救恶意活动,最终限制安全事件的爆炸半径和影响。
基于上述关于误报和开发人员辛劳的评论,现实情况是绝大多数漏洞扫描工具缺乏运行时应用程序的完整上下文。我们从 Cyentia 等来源了解到,发现的所有漏洞中只有 4% 到 6% 真正被利用。
虽然一些现代工具(例如 SCA)正在添加一些功能来识别漏洞是否可通过利用 CISA 的已知被利用漏洞 (KEV) 目录等来源而被利用,或者是否可能通过使用漏洞预测评分系统 (EPSS) 而被利用,或者是否实际上可通过可达性分析等功能而被利用,但 ADR 平台带来了应用运行时更清晰的上下文。
大多数组织的应用安全资源已经捉襟见肘,开发人员的数量远远超过安全人员,而且他们更关注部署速度等相互竞争的利益。这进一步强调了关注重要事项的必要性——即真正对组织构成风险的因素、可以利用的因素以及可以降低组织风险的因素。
如果您在过去几年一直关注网络安全,我们就会发现“安全左移”的趋势十分强劲,其理论是,在软件开发生命周期的早期识别和修复漏洞更容易、更有效,因为它们不仅修复起来可能更容易,而且在漏洞进入生产运行时环境(恶意行为者可以利用这些漏洞)之前也更省事。
我们看到专注于这些活动的安全扫描工具大量涌现,例如静态/动态应用程序安全测试(SAST / DAST)、软件组合分析(SCA)、容器扫描等。
虽然所有这些工具都有各自的用处,但挑战在于运行时(也称为现实)通常与 SDLC 中的源代码或构建阶段有很大不同。Shifting Left 无法准确预测复杂应用程序在生产环境中运行时的工作方式。
此外,许多这些工具最终会产生数百或数千个发现,其中许多缺乏背景信息,需要工程和开发团队进行分析、讨论和解决。
这不可避免地会耗尽稀缺的资源,并增加关键指标的滞后时间,例如平均部署时间或开发人员将代码、功能和创新融入产品和应用程序的速度。毕竟,当我们向左看时,攻击者正在向右看——就在生产中。