隨著越來越多的應用程式開發團隊將安全性整合到工作流程中，他們正從應用程式管線，工作流程和效能的角度來審視安全性對應用程式的影響。
由於合規性要求，Web應用程式和API保護(WAAP)通常部署在應用程式堆棧中。 但是，隨著組織將工作負載遷移到雲並開始將安全性嵌入其應用程式的結構中，WAAP的角色也在不斷髮展。 組織需要能夠擴展和適應不斷變化的雲架構和不斷增長的安全威脅的WAAP平臺。
在本文中，我們將回顧如何調整WAAP引擎(更具體地說，是專為該引擎而構建的規則集)，以擴展至雲工作流，提高Web應用程式的性能，同時保持對線上威脅的強大保護。
考慮WAAP引擎及其ruleset
WAAP應該是應用程式堆棧和網路安全程序的重要組成部分。 傳統上，WAAP與應用程式開發斷開連接，被視為應用程式外部的安全層。 但現代WAAP架構和工具幫助SecOps在CI/CD流程中與DevOps協作，包括在開發應用程式時創建規則和進行測試。 當正確使用WAAP引擎來分析遍歷應用程式基礎架構的流量時，WAAP引擎及其規則集在完成分析的速度，以及作為整體應用程式架構的一部分所產生的稽核與封鎖決策的執行狀況方面，扮演著重要的角色。
與汽車的發動機，計算機和傳動系統一樣，WAAP引擎，其規則集以及它保護的應用程式都應該經過設計和優化，以便協同工作。 汽車製造商並不將引擎設計成氣泡。 它必須針對汽車的其餘框架和組件進行優化，以達到全面的最佳性能和效率。 WAAP引擎及其規則集也應如此。 不考慮這些變量的WAAP可能會導致工作過度和過載，最終會降低Web應用程式的性能和用戶體驗。
減少WAAP工作負載以提高速度和effectiveness
Edgio WAAP使用開放原始碼，行業和專有簽名的組合來為其規則集提供資訊。 我們仔細評估每個簽名對整體規則集性能的影響。
在我們設計和優化WAAP引擎時，我們發現通過收集和使用開放源碼和行業規則集而無需任何修改，幾乎需要在流量跨越線路時對每個規則進行分析。 此模型在WAAP中相當常見，因此可以“輕鬆”查看流量發生的變化。 但它還強制WAAP執行每個規則以評估與通信相關的風險。 這給WAAP帶來了不必要的繁重工作量，隨著規則集的增長，這種工作量會進一步加重。
當然，速度並不總是如此。 WAAP中的一個關鍵要素是它能夠確定與流量相關的風險(危害)與獎勵(成功交易)，並決定是否將流量標記為惡意，可疑或良性。 WAAP將向團隊發送警報(審計/警報模式)，如果認為流量風險太大，無法通過(生產/阻止模式)，則阻止或重新路由流量。
在檢查所植入的開放原始碼和行業規則集時，這種分析成為一個更大的挑戰。 在製造這些產品時，不太可能考慮到市場中每一種可能的WAAP引擎的速度和效率。 這並不意味著他們的表現不好，只是意味著他們首先關注風險，而將性能留作事後考慮。 換句話說，還有改進的餘地。
由於首先創建了完整和準確的規則集，許多WAAP發現它們無法在兩種模式(審計和阻止)中處理要分析的流量，迫使InfoSec團隊選擇一種模式：從審計模式開始，將其移至生產模式，或直接進入生產模式，幾乎沒有實際測試，這使得它們容易遭受錯過的威脅和誤報。
Edgio如何增強WAAP rulesets
用於規則集的開源OWASP ModSecurity模型提供了一種標準，一致的方式，可通過該方式開發和實施WAAP規則集。 為了補充這一點，OWASP提供了行業通用規則集，遵循此模型的WAAP可以吸收該規則集。
但是，當我們的團隊實施規則集時，他們意識到正在攝取的規則集雖然完整且準確，但確實阻礙了WAAP引擎。 因此，團隊決定檢查規則集的結構和處理方式。 我們發現，許多規則會一次又一次地通過相同的數據，循環檢查以確定通過WAAP的流量的風險性，這對任何WAAP管理員來說都不會感到意外。
某些協議實施規則相當簡單，不必“活在”規則集生態系統中。 為了解決這一問題，我們首先開發了規則集，通過以非ModSecurity格式將OWASP規則集直接實施到WAAP引擎中，從而有效地削減了這些規則集。 這會導致早期執行和更快的檢測。
接下來，我們將目標定位在分析請求主體的規則。 我們構建了一個緩存層，可以降低重新計算規則中相同表達式的性能開銷。 以XML格式正文為例，我們搜尋了表達式“XML:/*”出現在OWASP CRS規則集中的次數，以查看在處理不帶暫存層的單個請求時，XPath可以重新計算多少次，該數字是有意義的。
最後，在執行大量宏擴展/字元串替換和顯式搜尋的地方，我們從規則集中識別並刪除了這些規則，並在引擎中使用更好的查找和搜尋算法(如HashMap查找和短語匹配(pm)運算符，而不是regex (Rx)運算符)實現這些規則。
我們的WAAP引擎使用規則集的結構進行不同的操作，使用更快的數據結構和開放標準格式(如JSON)，這些格式更易於配置和執行。 這不僅在速度方面，而且在準確性方面，都能帶來更好的性能：
- 低誤報：Edgio以確保準確性的方式排列和控制規則集
- 增強的引擎性能：Edgio WAAP引擎以避免引擎負擔過重的方式執行規則集
例如，對於OWASP IP阻止列表策略規則，ModSecurity引擎使用自己的“msc_tree”算法來查看錯誤的IP列表。 或者，Edgio WAAP引擎使用另一種更快的算法。 以下測試結果顯示了Edgio WAAP如何對照ModSecurity執行。 ModSecurity在大型IP列表上執行一百萬次查詢時，增加了大約200毫秒到500毫秒的延遲。 Edgio WAAP每天通過其網路處理大約10B個請求。 這些小數字在如此大的規模上很重要。
避免警報與阻止取捨
更好的WAAP引擎和規則集組合還意味著組織可以獲得更快的性能，並且可以在雙模式(塊模式和審計模式)下執行WAAP。 這使安全營運團隊能夠在審計/警報模式下試驗針對生產流量的新規則，並在將規則集升級為WAAP上的阻止模式之前對規則進行微調。
高度自定義的Edgio規則集允許管理員在任何地方切片和跳躍，並在雙模式下執行規則集。 將相同的規則應用到不同的設定後，管理員可以在不影響性能的情況下執行它們兩次，這部分歸功於智能引擎和規則集實施。
這裡的價值超越了WAAP管理團隊。 許多Edgio客戶將此選項集成到其DevOps生命週期中，使業務部門，工程團隊和IT安全團隊能夠在將規則應用到生產阻止模式之前，在審計模式中進行協作和測試。
此兩步流程允許IT安全小組在啟動防火牆配置更改之前對其進行審核，從而為團隊提供數據以測試實際生產流量的更改，從而在規則集投入生產後減少誤報。 一旦規則集經過驗證，更新的配置將在幾秒鐘內部署。 如有必要，可在幾分鐘內進行回滾。 這使得有意義的規則集試驗變得更現實，更動態，更有影響力，更有效並支援業務目標。
Edgio雙WAF模式方法還進一步提高了性能。 智能規則集可確保快速阻止已知的惡意流量，從而為WAF提供一定的呼吸空間，以便它能夠處理其餘不斷出現的流量。 這反過來又使管理員有更多時間專注於獲得預測性可見性；換句話說，他們可以在應用程式部署到生產站點之前通過審核模式查看應用程式中的內容。
如果您的企業需要能夠適應不可預測的工作負載並提供高度安全的體系結構的應用程式堆棧，請考慮WAAP引擎和規則集設計。 經過優化後，這些因素可以提高Web應用程式的性能。
有關Edgio WAAP智能引擎和規則集如何快速準確地保護您的Web應用程式的更多資訊，現在就聯繫我們吧。
