运行时应用自保护（RASP）应该是什么样子的

近些年来，应用安全界见证了运行时应用自保护（RASP）技术的兴起。正如咨询公司Gartner所描述的，RASP是集成到应用程序或其运行时环境中的一种安全技术，能够实时控制和防止攻击。遗憾的是，很多Web应用防火墙（WAF）公司趁机利用了这个术语，在网络层引入了“类RASP”代理，但这种代理并未完全反映RASP技术的定义。

与之相反，真正的RASP技术运行在应用层，具有用户、应用逻辑和域信息的完整上下文。利用这一上下文，RASP能够就应用安全做出明智决策，及时遏阻漏洞利用造成损害。因此，真正的RASP应该是零误报和低延迟的，能够即时提升性能。真正的RASP需要一系列不可改变的规则，这些规则靠上下文洞悉何时引入了新漏洞，并据此采取相应的措施。这种不可改变性是可以达到的，只要规则内置进应用层代码库中，且部署后无需任何变更。

RASP出错的三个方面

1、吠犬问题：大多数警报都是误报

WAF的问题在于运行在网络层，作为应用执行指标而言滞后了。由此造成上下文匮乏，导致误报率高、等待时间长和性能低下，因为WAF只能基于自己此前获得的信息来猜测漏洞性质。

可以想象一下院子里的看门狗一听到围墙外面有点什么动静就开始吠叫的场景。这些声响可能是入侵者接近的声音，但也可能只是汽车路过的声音。看门狗无法准确判断其间差异，也就无法提示这些动静的危险程度，住在房子里的主人当然也就无从判断哪些警报是真的，而哪些又仅仅是误报。这种场景基本反映了标准RASP提供的功能。

2、999个坏人问题：只能测试样本

不管你信不信，如果你只保护一个样本量的规模，有些供应商会让你只在生产环境中运行他们的安全解决方案。这意味着，解决方案会抽取一个样本（可能是每1000个请求中抽1个），然后测试这个样本，坐等其他999个会发生什么。也就是说，如果样本是良性的，样本特征码会获准放行。但无论接下来999个请求是否含有恶意，它们都会获准放行。这种一致性的缺乏完全是因为基于WAF的RASP无法应对必须测试每个请求的性能要求。

3、“等得太久”问题：延迟影响性能

使用基于WAF的RASP肯定会增加延迟，因为它压根儿就不触及应用程序的代码库。同时，广为使用的RASP必须将所有文本载荷发往其Web分析器，然后等待其返回，这就很耗时间了。如果你的客户正等着付款，这么长的等待时间可能会让他们转投别家。

改善这一过程有点类似于代码优化。创建列表的时候，开发人员会在列表的开头插入新项目，而不是在末尾。这一优化操作可以防止虚拟机每次添加新项目都重新构建整个列表，避免随着列表变长而增加延迟。编译工程师在本世纪初就通过实现即时编译（JIT）解决了这些问题，该技术可基于给定语言的细微差异自动优化代码。

RASP的定义为什么被淡化了？

开发RASP技术要求综合利用安全工程和软件工程技术。RASP开发人员必须深入了解应用的架构和所用编程语言的细微差别。具备这一领域专业知识的安全专业人员可不多。

真正的RASP可以优化代码的性能和安全性

由于大多数RASP平台搞得像WAF一样，开销过于巨大，导致只能以采样模式运行。相反，真正的RASP平台在运行时执行实际保护。

这些操作发生在内存，非常高效，而且因为与应用处于同一空间，性能也是非常高的。在运行时执行保护，就不需要限制速率或以样本量规模执行保护，因为实际操作只需要几毫秒。

无论应用做了哪些更改，高性能安全保持不变。这种理念与基础设施即代码的理念相符，你可以定义所需的基础设施状态，无论环境中发生什么，基础设施的状态都维持原样。

从定义上讲，RASP的很多原则都与基础设施即代码非常相似。这种相似性可能出自对应用及其构建语言的深度上下文感知。与基础设施即代码一样，真正的RASP方法能够也应该利用不可改变性来确保无论代码库发生什么变化都能应用规则。

这种不变性是可以实现的，只要在首次调用函数时即检查其输出，并用受保护的功能替换掉任何有害功能，从而确保应用在运行时始终健康即可。

这种方法可以使安全无关部署，并且不需要更改、调整应用代码，也无需等待部署窗口。

在运行时执行保护，修复应用所有运行实例上即时保护的结果，就可以避免频繁误报，消除未来发生漏洞利用的风险。

RASP可以且应该达到更高标准

简而言之，RASP应该达到更高的标准。以更高标准实现RASP，就可以保护无数应用，降低WAF的总拥有成本，帮助防止安全团队过劳崩溃。