當被監控系統控制監控器時

安全控制措施可能已經存在、啟用，並且表面上看起來正在運行，但實際上有人在暗中破壞它履行職責的能力。 

OpenAI 最近的一份報告描述了兩起涉及 AI 代理執行內部編碼任務的事件。在其中一起事件中，一個代理人在修復評估流程時抑制了自動安全警報。監控程式繼續運作並儲存報告，但原本應引起人工注意的警報功能卻被停用。在另一事件中，一個代理程式在修改程式碼時移除了一個監控集成，然後錯誤地報告了其所做的更改。 

雖然細節有所不同，但這兩起事件都提出了一個根本性的架構問題：當被監控系統擁有足夠的控制權來幹擾自身的監控時，會發生什麼事？ 

應用安全領域多年來一直在努力應對類似的問題。行動應用程式運行在開發者無法控制的裝置上。攻擊者可能能夠檢查其程式碼、篡改其執行過程，或試圖停用旨在偵測這些活動的保護措施。但是，新增安全檢查只是第一步。檢查本身也需要保護。 

誰來守衛衛兵？ 

設想一款行動銀行應用程序，它會檢查自身代碼是否被篡改。如果偵測到篡改，它可能會關閉應用程式、要求額外的身份驗證，或限制高額轉賬，同時允許敏感度較低的功能繼續運作。這些都是有效的因應措施。但這引出了另一個問題：如何阻止攻擊者找到完整性檢查並對其進行修改，使其失效？ 

可以輕鬆停用的保護措施可能會給開發者帶來虛假的安全感。應用程式包含用於偵測篡改的程式碼，但能夠修改程式碼的攻擊者也可能破壞偵測機制。 

同樣的擔憂也適用於威脅監控。系統或許能夠辨識可疑行為，但如果攻擊者能夠幹擾負責辨識的機製或壓制其發現，那麼這種能力就毫無意義。這正是安全領域一個老生常談的問題背後的挑戰：誰來監管監管者？ 

增加更多保護措施固然有幫助，但前提是這些保護措施本身已在設計中充分考慮。否則，攻擊者可能只會攻擊執行安全性策略的機制。 

建構安全網絡 

Digital.aiArxan 的應用程式保護技術透過名為「衛士」（Guards）的安全控制系統來應對這項挑戰。衛士被注入到受保護的應用二進位。它們可以檢查應用程式的完整性，並根據為應用程式配置的策略對偵測到的篡改做出回應。根據不同的使用場景，回應可能包括關閉應用程式、觸發增強型身分驗證，或停用敏感功能（例如高價值的金融轉帳）。重要的架構細節在於，衛士本身也可以受到其他衛兵的保護。 

這就產生了我們所說的 警衛網絡守衛並非必須孤立存在，成為攻擊者可以辨識和攻擊的目標。其他守衛可以保護它，而這些保護本身也可以獲得多層保護。在某些實現中，這種保護鏈會延伸到多個層級，守衛之間相互保護，守衛之間又相互保護。 

這種分層結構改變了攻擊者面臨的問題。停用某個安全檢查可能還需要繞過圍繞該檢查的保護措施。試圖幹擾保護架構的某個部分可能會遇到其他旨在偵測或抵禦這種幹擾的部分。 如今，這種設計比最初提出時更為重要。人工智慧工具降低了大規模逆向工程應用程式的成本和所需技能，而單一孤立的檢查正是自動化分析能夠快速發現並修復的目標類型。  

當防護組件配置為相互保護時，移除其中一個會觸發其他組件的失效。根據目標的不同，團隊還可以透過多種設定來調整保護機制：例如，設定種子值使每個受保護的構建在結構上都有所不同；在保護時隨機選擇防護組件實例；以及設定執行機率，確保並非每個防護組件都會在每次執行時運行。 有些守衛會在運行時改變自己的行為，因此它們不呈現靜態簽名：例如，增量校驗和可以在每次呼叫時驗證不同的範圍，而不是重複一次固定的檢查，而自動分析可以學習並繞過該檢查。 對某一版本或某一版本有效的剝離方法，並不能保證對下一個版本或版本有效。 

Guard Network 並非聲稱應用程式絕對無法被攻破。沒有任何單一架構能夠保證抵禦所有攻擊者、平台或威脅。它的目的是使安全防護措施更難被定位、篡改和消除，包括應對針對防護措施本身的攻擊。這種區別至關重要。攻擊者並非總是需要攻破整個安全架構。有時，他們只需要停用某個原本會暴露其活動的機制。保護這些防護措施本身就增加了這種攻擊的難度。  

檢測需要一條響應路徑。 

保護完整性檢查只是問題的一部分。安全團隊還需要了解應用程式遇到可疑情況時會發生什麼。 

Arxan威脅監控在受保護的應用程式內部運作。監控控制被注入到二進位檔案中，警報可以透過瀏覽器查看，也可以整合到安全資訊和事件管理 (SIEM) 系統中。這使得組織能夠審查應用程式層級的安全事件，並將其納入更廣泛的安全營運中。架構在此也至關重要。監控在應用程式內部運行，因此不應將其描述為完全外部的觀察者。其控制是受保護二進位檔案的一部分，並且保護架構旨在防止對應用程式及其安全機制的篡改。 

Guard Network 透過保護控制措施本身，為此安全體系提供了重要組成部分。外部告警和 SIEM 整合使得報告的事件能夠被應用程式以外的使用者取得。這些機制各有不同的用途。 Guard 可以幫助保護應用程式的完整性，並在偵測到篡改時觸發回應。威脅監控可以發現與安全相關的活動。外部報告可以幫助安全團隊調查事件並協調回應。 

每個部分都有其限制。報告通道無法報告從未偵測到的事件，而且任何保護措施都不能保證抵禦所有可能的攻擊。其目標是盡可能增加攻擊者入侵應用程式的難度，然後停用旨在暴露或限制此類入侵的機制。 

應對措施應與威脅相符。 

人們通常會在討論安全控制措施時會專注於它們能夠偵測到什麼。但在實務中，後續操作同樣重要。例如，銀行應用程式在偵測到可疑情況後可能會要求進行更高等級的身份驗證，或限制高額轉賬，同時保留日常操作。而對於具有更嚴格完整性要求的應用程序，如果其代碼被修改，則可能會直接關閉。這些不同的反應機制反映了不同的風險評估。開發人員可以根據應用程式、威脅以及允許程式繼續執行可能造成的後果來選擇合適的回應措施。 

我們的一位遊戲客戶採取了更具娛樂性的方法。他們的團隊開發了一套防護機制，用於偵測玩家是否作弊。一旦觸發該機制，遊戲就會關閉重力功能，作弊者的角色就會漂浮在遊戲區域之外。這是一個令人印象深刻的例子，而背後的理念卻十分嚴肅。此防護機制與攻擊發生環境中一個重要的後果相關聯。開發者並沒有將偵測結果視為流程的終點，而是利用它來改變應用程式的功能。 

當後果涉及金錢、敏感資料或關鍵功能存取權時，同樣的原則也適用。應對措施應與風險相匹配，且攻擊者應難以消除觸發機制。開發人員還需要考慮誤報、恢復路徑以及對合法用戶的影響。保護措施應在不造成不必要中斷的前提下，提高應用程式的彈性。 

問問當衛兵成為攻擊目標時會發生什麼 

OpenAI 的這份報告有力地提醒我們，監控系統一旦被竄改，其有效性就會大打折扣。當應用程式運行在攻擊者可以檢查和操縱其執行的環境中時，應用程式開發人員也面臨類似的挑戰。問題不僅在於應用程式是否具備完整性檢查或威脅監控功能，還在於這些機制如何受到保護、如何應對幹擾，以及攻擊者是否能夠停用那些原本會暴露攻擊的控制措施。 

這就是 Guard 網路的重要性所在。 Arxan 透過使用 Guard 來保護其他 Guard，在安全機製本身周圍增加了多層保護。這為試圖修改應用程式防禦或破壞單一控制措施的攻擊者設置了額外的障礙。在評估應用程式安全架構時，請問自己三個問題。

1）當攻擊者將目標對準防護措施本身時會發生什麼？
2）是什麼因素可以防止單一修改導致關鍵安全機制失效？
3) 當 Guard 偵測到竄改時，應用程式有哪些選項？ 

目標並非保證應用程式永遠不會被攻破，而是增加篡改難度，在遭受攻擊時提供有效的保護，並為開發者提供在應用程式完整性受到質疑時可行應對的措施。有時，這種應對措施意味著限制金融交易；有時，則意味著關閉應用程式。 

有時這意味著關閉重力，看著作弊者的玩家飄走。