近年來，網絡安全實戰演習受到各大關基單位的高度關注。對於網絡安全實戰演習的防守方，防火牆、Web應用防火牆、態勢感知、EDR、蜜罐等都是較為常見的防守工具，而網頁防篡改系統則鮮有露臉的機會——
很多人認為，網頁防篡改系統只是用來保護門戶網站的，特別是針對靜態門戶網站時，才有它的價值。
而在網絡安全實戰演習中，攻擊隊根本不會將火力指向網頁防篡改系統的保護對象。因此，網頁防篡改系統在這個場景下缺乏應用價值。
之所以產生這樣的觀念，和網頁防篡改產品的現狀有着很大的關系。目前，市場上大部分的網頁防篡改產品都着眼於在網頁篡改發生的前后，對篡改行為或篡改后果進行處置。這種“頭痛醫頭，腳痛醫腳”的思路讓網頁防篡改產品在不以篡改網頁為攻擊目標的場景中顯得缺乏實用價值。
一個 Web 應用之所以會發生文件被篡改的事件，通常是管理、運維、對抗能力等多方面原因共同促就的。所以把文件“鎖住”或是發現篡改即時恢復，是通過抑制篡改現象來實現狹義上的防篡改。而從安全治理的角度出發，就需要細究造成篡改的原因，立足於 Web 應用安全的整體視角，從管理、運維、對抗能力多個維度上入手治理 Web 應用系統的缺陷和隱患。
如果我們從攻擊者的視角來分析網頁篡改，就不難發現：實施一次篡改攻擊，其實意味着攻擊者已經擊穿了防守方的防線，而不只是在外圍隔靴搔癢。基於當下防守方在網絡安全實戰演習中的防護策略，任何外網應用系統上的網頁防篡改系統如果偵測到了篡改攻擊，那么必然意味着攻擊者已經掌握了該應用系統的控制權。即便攻擊者因為網頁防篡改系統的阻攔，並未成功實施篡改攻擊，但通過其所掌握的應用系統控制權會造成內網橫移等更嚴重的安全問題。
因此在網絡安全實戰演習中，網頁防篡改系統首先扮演了哨兵的角色。Web 應用系統作為防守的前沿陣地，所有的攻擊火力都是由此展開和深入的。及時判斷 Web 應用系統是否被攻陷，對於防守方來說是啟動應急處置時非常重要的信號。
網頁防篡改系統是網站安全的最后一道防線
防篡改既是終點 更是起點
對於一些財大氣粗的防守方來說，安全產品上的很全，因此，網頁防篡改系統的哨兵作用，就被態勢感知、HIDS 等其他產品所取代。但由於 HVV 范圍的擴大和常態化，很多防守方並沒有靠“銀彈”來打造防線的實力。而網頁防篡改系統是大部分等保3級以上單位必備的安全產品，因此，打破“網頁防篡改系統只能用來保護網頁”的固有觀念，將網頁防篡改系統部署到 HVV 涉及的 Web 應用系統上，保護各類能通過互聯網訪問到的文件，進而通過監測這些文件的異常變化來讓網頁防篡改系統成為 HVV 哨兵，不失為一種具有創意的利舊方案。
當然，網頁防篡改系統要能在 HVV 中扮演好哨兵的角色，還需要產品本身提供除了文件寫保護或文件恢復之外，更豐富的功能。例如，在 iGuard6.0 中，防護對象不再局限於網頁文件，中間件配置文件、上傳文件、應用系統相關文件 (在 iGuard6.0 中稱為動態文件) 等各種通過互聯網能夠接觸到的文件都能被當做防護對象監測並防護起來。同時，iGuard6.0 的防護機制也分為常態防護和對抗防護兩種類型。常態防護機制包括對 WebShell 的排查和清理、對文件完整性和合法駐留權進行定時檢查、檢查文件類型與內容是否一致等不依賴於攻擊而觸發的防護手段，因此只要通過 Lua 工具箱等輔助工具的靈活配置使用，就可以作為發現文件遭篡改后的應急處置手段。對抗防護機制不僅僅可以監測並阻止篡改，同時也對異常操作主體 (通常為進程) 詳細信息、異常操作行為詳情 (例如：被篡改文件快照) 等關鍵信息進行記錄，可以為事后的研判溯源提供數據支撐。
將 iGuard 作為 HVV 哨兵，在 2021 年的 HVV 中也得到了一些實際驗證。在 2021 年 HVV 期間，某大型企業在其近 500 台互聯網可訪問的服務器上部署了 iGuard，而在其中某一台服務器上產生了一次告警，引起該企業客戶的高度重視，隨即召集了與該服務器和應用系統相關的廠商以 iGuard 記錄的攻擊詳情為線索進行研判，最后成功追溯出攻擊者的攻擊路徑：攻擊者拿到了應用的內部賬號，繞過了交互驗證，成功登錄應用；應用系統內部有一個廢棄組件具有上傳功能，攻擊者利用該上傳功能上傳文件，被 iGuard 攔截並記錄了上傳文件的詳細信息。
網頁防篡改系統雖然並不是為 HVV 量身打造的安全產品，但如果應用得當，它在 HVV 中也能發揮不小的作用。在 HVV 常態化的未來，巧妙使用每一個安全產品，使之既能在平時穩定可靠地履行它本該履行的安全職責，又能在戰時發揮出奇兵的作用，才能讓每一筆安全上的投入都能產生出盡可能大的價值。（天存信息）