運行時應用自保護 (RASP) 應該是什么樣子的
責編：gltian ｜2023-05-12 15:13:51近些年來，應用安全界見證了運行時應用自保護（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的總擁有成本，幫助防止安全團隊過勞崩潰。
來源：數世咨詢