從使用“發現的風險”作為關鍵績效指標，轉向使用“補救的風險”作為衡量成功的真正標準，這一變化改變了安全團隊的激勵機制，促使他們專注于風險補救。為了在規模上實現這一點，企業必須在降低風險方面擺脫“救火”模式——這意味著他們必須停止追逐最新的關鍵問題--并變得更加積極主動。
以下是你可以采取的七個步驟，將你現有的漏洞和風險管理流程和工作流程從消防轉變為主動管理大規模風險降低。
步驟1：收集-創建一個積壓工作來管理所有積壓工作
對你的安全測試工具采用基于調查結果的方法意味著你的典型補救過程從登錄到每個工具的儀表板開始。當然，這需要學習每個工具的不同功能，并理解每個工具的調查結果語言。
要過渡到基于修復的方法，請從創建單個待辦事項開始。第一步是將來自所有測試工具的所有結果收集到一個集中位置，無論是電子表格、數據庫還是其他系統。
第2步：整合-標準化、重復數據消除和利用上下文進行豐富
現在你有了單一的積壓，向前邁進一步，將所有調查結果標準化，以便它們使用統一的術語，從而使你能夠統一地執行你的補救流程。畢竟，如果你想衡量結果，你需要對所有發現執行相同的過程。這一標準化的積壓調查結果現在是所有后續活動的支柱。
你將看到你現在標準化的列表有重復的發現。刪除多余的內容以縮短積壓工作的長度。
標準化列表還使你能夠識別影響同一資源的不同調查結果。在這一點上，你應該用所有權背景來豐富調查結果，這是你未來需要的。例如，從配置管理數據庫(CMDB)收集元數據，以在以后分析誰擁有易受攻擊的計算機。
第3步：選擇-決定執行什么、誰、如何以及在哪里執行補救行動
所有調查結果標準化后，你現在可以選擇如何通過多維優先排序方法進行補救，其中包括：
A.內容：選擇是要根據外部上下文(例如，已知的自然漏洞利用)還是根據內部上下文(例如，它所在的域-云、代碼等)來確定發現的優先級。
B.誰：選擇補救項目的發送對象。要確定合適的團隊，請分析你在步驟2中收集的資源元數據。
C.如何：通過圍繞補救行動進行匯總，確定結果而不是問題的優先順序。這意味著，如果你對不同的資源或不同的問題有相同的解決方案，則只會生成一個補救項目。
D.在哪里：選擇在哪個項目下為補救團隊打開工單(例如，在Jira、ServiceNow或修復者使用的任何其他工單系統中)。
步驟4：路線-將補救項目送到補救團隊手中
既然你知道誰將執行修復以及要發送它們的補救操作列表，你就可以開始發送它們了。
在這個階段，你將意識到你能夠并行地進行補救，而不是像今天通常所做的那樣以順序的方式進行。
作為一個簡單的示例場景，假設你有兩個補救團隊，Engineering和DevOps，并且你有150個關鍵發現。接下來，讓我們假設前100個調查結果都由Engineering修復，其余50個由DevOps修復。按順序完成列表將意味著工程團隊的修復程序超負荷，而DevOps團隊則未得到充分利用。但是，一旦你基于補救操作處理列表，并且你知道將進行補救工作的團隊，你就可以并行地補救部分積壓。
步驟5：面向接收的解決方案，而不是依賴于安全
這是使你能夠真正擴展的步驟：通過創建程序化工作流來自動化積壓管理。實現這一點的關鍵是與其他企業流程同步，并在補救團隊需要安全數據時使其可用，而不是在發現發現時提供。
首先，在補救項目和每個不同的補救團隊使用的票務系統之間應該有一個工作流程。這樣，當發現問題時，票證將自動打開并定向到正確的團隊，如步驟3中所定義。你甚至可以更進一步，為每個票務系統創建統一的模板。
你的自動化工作流程應該是雙向的，以便在票務系統中關閉票證時，你可以使用下一次測試掃描的結果進行驗證。如果發現任何差異，請通過在補救團隊的工作流工具中重新打開帶有相關詳細信息的票據來突出顯示它。
步驟6：補救-完成艱苦工作的地方
這是為補救安全問題而進行的實際修復、緩解或風險接受。這是補救過程中的關鍵部分，但作為安全團隊，它不在你的直接控制范圍之內。
第7步：報告-衡量實際績效、效率和風險降低
擁有將補救操作發送給正確的補救團隊的自動路由流程，使你可以立即查看整個積壓及其狀態，而不僅僅是它是否得到了補救。這使你能夠跟蹤和衡量你的風險降低過程。
有了這些數據，你可以衡量績效，還可以比較企業內不同團隊或組之間的補救績效。例如，你可以分析和比較不同的應用程序在關鍵發現、總發現以及團隊如何處理他們的罰單方面。
你現在還可以向利益相關者提供有關企業補救計劃的報告，使每個人都能夠了解該計劃的節奏和性能，以及統計數據，如新發現與已解決發現的比率、補救的平均時間和總體積壓狀態。
這種跟蹤使你能夠識別補救流程本身中的任何問題，并為安全團隊提供數據，他們可以使用這些數據與相應的補救團隊更緊密地協作，以增強其流程并解決任何需要改進的領域。
正是這種從產出轉移到結果的方法，應該在消除安全成為補救過程中的瓶頸并使過程能夠擴展方面發揮帶頭作用。
