構建高效漏洞生命周期管理流程的四個典型框架
個性化、復雜性流程正在制約漏洞管理能力
當前，漏洞管理已成為網絡安全管理不可或缺的手段，其生命周期閉環管理運營流程的優劣性直接影響漏洞管理能力。而不同組織的漏洞生命周期管理流程充滿了個性化、復雜性的特點。
首先，國家/行業/區域漏洞管理、漏洞公開披露、眾測漏洞管理、常規安全運維中的漏洞管理、應用安全漏洞管理、DevSecOps漏洞管理、供應鏈漏洞管理、安全加固服務外包漏洞管理等不同場景中，出發點、管理對象、工作內容、側重點有差異，且不同組織可能會交叉存在多個管理場景。其次，不同組織企業文化、管理方式、技術能力的不同也是造成個性化、復雜性的重要因素。
兼容并蓄，降低流程個性化、復雜性程度
如何構建貼合組織實際情況的管理流程，并能夠在運行過程中持續優化和提升成為挑戰。方法就是借鑒和吸收通用性框架，逐步降低個性化、復雜性程度。
縱觀業內眾多的各類漏洞管理流程通用性框架，攝星科技結合多年為國家監管、行業監管、重要關基企業、安全運維外包服務商提供漏洞管理流程建設服務經驗，選取有代表性的、可借鑒性強的四個典型框架進行分享。這四個框架各有其側重點、適用范圍，用戶可根據自身實際需求取其精華，兼容并蓄，形成貼合自身的運營流程。
1.《信息安全技術 網絡安全漏洞管理規范》（GBT30276-2020）
《信息安全技術 網絡安全漏洞管理規范》（GBT30276-2020）適用于網絡產品和服務的提供者、網絡運營者、漏洞收錄組織、漏洞應急組織等開展的網絡安全漏洞管理活動，其適用對象較廣。
規定了網絡安全漏洞管理流程各階段(包括漏洞發現和報告、接收、驗證、處置、發布、跟蹤)的管理流程、管理要求以及證實方法。
所定義的流程和階段如下:
階段 | 工作內容 |
漏洞發現和報告 | 漏洞發現者通過人工或自動的方法對漏洞進行探測、分析，證實漏洞存在的真實性，并由漏洞報告者將獲得的漏洞信息向漏洞接收者報告 |
漏洞驗證 | 收到漏洞報告后，進行漏洞信息技術驗證;滿足相應要求終止后續漏洞管理流程 |
漏洞處置 | 對漏洞進行修復，或制定并測試漏洞修復或防范措施，可包括升級版本、補丁、更改配置等方式 |
漏洞發布 | 通過網站、郵件列表等渠道將漏洞信息向社會或受影響的用戶發布 |
漏洞跟蹤 | 漏洞發布后跟蹤監測漏洞修復情況、產品或服務穩定性等；視情況對漏洞修復或防范措施做進一步改進；滿足相應要求終止漏洞管理流程 |
2. CISA網絡安全事件及漏洞響應手冊（Federal Government Cybersecurity Incident and Vulnerability Response Playbooks）
CISA網絡安全事件及漏洞響應手冊用以改善和標準化美聯邦機構識別、修復漏洞，以及從網絡安全事件和漏洞事件中恢復的方法。
響應手冊定義的漏洞管理流程如下，包括識別、評估、修復和報告漏洞四個階段。
CISA認為，確定漏洞響應優先級并保護自己不受損害的最直接有效的方法之一就是關注那些已經被積極在野利用的漏洞。為此，專門建立了CISA已知被積極利用漏洞目錄（Known Expolited vulnerabilities calalog）。攝星科技已同步在官網發布“關鍵漏洞目錄”。
流程規范了應對緊急和高優先級漏洞時應遵循的高級進程。它不是現有漏洞管理程序的替代品，而是建立在現有漏洞管理實踐的基礎上。
階段 | 方法 | 目標 |
識別 Identification | 監測威脅源，主動識別在野被積極利用漏洞報告，包括不限于： CISA資源：CISA/-CERT國家網絡意識系統(NCAS)、CISA綁定操作指令(BOD)22-01 外部威脅或漏洞資源，如NIST國家漏洞庫 在FCEB機構之外的在野利用漏洞 內部SOC監控到的被利用漏洞。捕獲有關漏洞其他信息，如漏洞嚴重程度、易受影響軟件版本、IOCs或其它用于確定漏洞是否被利用證據 | |
評估 Evaluation | 使用利益相關者特定漏洞分類SSVC確定環境中是否存在漏洞，以及底層軟件或硬件資產的關鍵程度 使用現有修補程序和資產管理工具自動化漏洞檢測過程 如存在漏洞，則處理漏洞并確定漏洞是否被利用。如果被利用，立即按照手冊開始事件響應 | 在評估階段結束時，要了解環境中每個系統的狀態： 不受影響。不存在漏洞 易受影響。系統存在漏洞但沒有發現被利用跡象，修復工作已經開始 受到損害。系統存在漏洞且發現利用漏洞跡象，已開始對事件進行響應和漏洞修復 |
修復 Remediation | 及時修復所有被積極利用漏洞。多數情況下，應使用補丁程序。如果補丁不存在、尚未測試或不能立即應用，采取其它緩解措施，包括： 禁用服務 配置更改 限制準入 配置防火墻/IPS阻止訪問 增加監控監測漏洞利用 隔離易受攻擊系統、應用、服務、配置文件或其他資產 一旦補丁可用并可以安全的應用，應刪除緩解措施并應用補丁 | 當系統被修復時，跟蹤其狀態。每個系統都應該能夠被描述為以下類別之一： 已修復。已應用修補程序或配置更改，系統不再易受攻擊 已緩解。其他補償性控制已經到位，漏洞的風險已經降低 易受影響/受到損害。沒有采取任何行動，系統仍然易受影響或受到損害 |
報告 Reporting | 共享有關漏洞如何被利用的信息 | 幫助聯邦政府的網絡安全維護者了解哪些漏洞對修補程序最關鍵 幫助其他機構了解漏洞影響，縮短披露和利用漏洞之間的時間 |
3. OWASP漏洞管理指南（OWASP Vulnerability Management Guide (OVMG) ）
OWASP漏洞管理指南的目標是通過將復雜的漏洞管理問題分解為更易于管理的可重復動作（檢測、報告和修復）。側重于在漏洞生命周期中構建可重復的過程。
OVMG實施時，建議從“小”開始，然后在“生命周期”中逐步細化每個任務和子任務。使業務通過漏洞管理計劃的實施而變得更具彈性。
OVMG的管理流程由檢測（Detection）、報告（Reporting）、修復（Remediation）三個閉環組成。
每個閉環包含四個主要流程。每個流程都是一個包含待辦事項的任務列表。所有任務都有“輸入”和“輸出”。
漏洞管理的周期性意味著持續的流程改進，單個流程如何融入其它流程、任務如何跨三個閉環相互關聯對流程建立和改進至關重要。
(1) 檢測閉環（Detection Cycle ）
檢測閉環定義了誰、時間、地點、原因和方式執行漏洞測試的任務。
檢測閉環包含的流程、目標、任務列表如下：
流程 | 目標 | 任務列表 |
定義漏洞檢測范圍 Scope | 完成范圍任務，能夠向管理層和同事解釋為什么需要進行漏洞檢測及它為業務帶來好處，同時了解漏洞檢測的邊界 | 了解企業風險 了解合規要求 了解技術限制 區分主要資產與次要資產 漏洞管理流程嵌入企業流程 獲得管理層支持 |
優化檢測工具 Tools | 優化檢測工具能夠覆蓋到Scope中定義的資產范圍 | 確定測試/掃描的類型，如DAST、SAST、IAST等 確定安全檢測頻率 確保工具更新到最新的漏洞 檢查是否存在漏洞異常 測試掃描工具覆蓋面完整性 優化工具設置模板 |
執行漏洞檢測 Run Tests | 按照計劃執行漏洞檢測 | 掃描公共IP地址 掃描專用子網 掃描/測試web應用程序 掃描/測試移動應用 測試用戶(網絡釣魚、社會工程培訓) |
確認掃描結果 Confirm Findings | 了解漏洞檢測結果；使用收集的數據調整漏洞掃描工具的準確性 | 測試結果是否包含有價值數據 在測試中了解系統/設備指紋 確定運行的服務 找出不符合特征漏洞并調查原因 隨機選擇漏洞并使用工具或手動確認 |
(2) 報告閉環（Reporting Cycle ）
報告閉環的目標是幫助組織以可衡量的方式了解漏洞。側重于學習、分類和創建組織性、有意義的指標，這些指標將成為漏洞管理報告的基礎。
報告閉環包含的流程、目標、任務列表如下：
流程 | 目標 | 任務列表 |
資產分組 Asset Groups | 充分了解資產環境及管理方式，以便資產提供類別和分組管理 | 確定功能資產組 按環境類型確定資產組 按系統類型確定資產組 根據CVE編號或基礎技術確定組 按漏洞類型確定組 |
度量指標 Metrics | 為漏洞報告創建（并隨后修改）度量指標。這些指標應該是一致的，并且對報告的受眾（管理層和負責修復工作的團隊）來說是有意義的 | 確定脆弱資產的數量和百分比 根據嚴重程度和CVSS確定脆弱資產的數量和百分比 確定新漏洞的數量和百分比： -按嚴重程度 -按功能組 -按環境類型 -按系統類型 -CVE編號 -按漏洞類型 根據漏洞的嚴重程度及百分比，比較和分析老化數據： -企業范圍內 -在所有其他脆弱資產中 -按功能組 -按環境類型 -按系統類型 -CVE編號 -按漏洞類型 利用對風險和法規遵從性至關重要的KPI，按數量和百分比繪制趨勢 按嚴重程度確定脆弱資產可利用性；指定計數、百分比、減少或增加 |
審計跟蹤 Audit Trail | 為補救工作創建審計跟蹤。為負責漏洞修復（代碼重寫、配置修復等）的人員分配工作或培訓 | 使用工單系統 提供問題摘要 基于工具的報告輸出 通知/分配/工單給負責團隊或個人 確保管理層/CISO對情況的了解 |
報告 Reports | 以簡明易懂的形式總結安全掃描結果。與所有需要了解的人分享報告。保持漏洞報告的格式和交付一致性 | 保持一致的報告頻率，并使用它來跟蹤變化 聚合和處理收集的資產和漏洞數據 使用CVSS，將獨特環境特征應用于漏洞分析 全局脆弱性趨勢 用一句話表述這些趨勢 在報告中添加您的建議 將數據敏感性分類應用于報告 制作一份簡短的報告（1-2頁） 將兩個版本提交給管理者/CISO 為內外部審計創建并維護自己的漏洞數據庫 能夠解釋漏洞檢測和報告過程細節 |
(3) 修復閉環（Remediation Cycle）
修復閉環的目標是減少或消除修復漏洞的工作，或提供證據說明特定漏洞不是威脅的原因。側重于確定修復工作的優先事項和條款，討論和記錄誤報，以及處理異常情況。
修復閉環包含的流程、目標、任務列表如下：
流程 | 目標 | 任務列表 |
優先級排布 Prioritize | 創建基于數據的漏洞優先級論證 | 使用報告 使用趨勢分析 使用其它來源的信息，如最新威脅情報 應用其他環境因素 與利益相關者溝通 |
漏洞修復 Remediation | 完成漏洞修復工作，識別并記錄所有無法補救的漏洞實例 | 找到負責修復工作的利益相關者 通過工具和流程傳達發現的漏洞 確定修補、重寫代碼、重新培訓人員的頻率和范圍 建立專門用于修復測試的資產 向利益相關者報告測試結果 使用工單系統或變更管理系統解決修復管理問題 分配修復工作，包括責任人、利益相關者，以及需要了解未解決問題的人 利用報告周期的頻率跟進未解決問題 |
識別誤報 Investigate False Positives（FP） | 建立如何將漏洞評估為誤報的基本規則。逐案審查證據。定期復查和糾正誤報案例。這個過程應該是透明的，不應被濫用 | 確保聲明的完整性 構建可重復業務流程 記錄所有FP提交 找到能夠同意或提出誤報肯定的第三方 設置重新評估FP的時間框架 記錄每個FP并存儲在可審核的存儲庫中 創建適當的策略 將此政策傳達給所有員工 |
漏洞例外 Exceptions | 確保所有不符合項都得到高級管理層的批準，并記錄在公司范圍的存儲庫中。 漏洞例外還須有一個到期日期，在此之后應進行修改。 漏洞例外必須包括防止漏洞利用的補償控制 | 找到一個執行機構能夠批準網絡安全例外 建立漏洞例外的基本規則 定期審查例外情況 建立可接受補償控制 記錄每個例外情況并將其存儲在公司的審計系統中 創建適當的策略 將此政策傳達給所有員工 每次漏洞例外請求都需批準 |
4. SANS漏洞管理成熟度模型（Vulnerability Management Maturity Model）
敏捷開發、DevOps、云技術和虛擬化使組織能夠以極快的速度構建和部署系統。同時，陳舊繁瑣的安全性和合規性測試方法無法跟上新技術發展。因此，漏洞管理人員需要了解并使用開發人員和工程師正在使用的相同工具和技術，能夠快速且經常性的生成測試結果，從而不會影響整個組織業務發展的速度。
大多數大型組織面臨的突出問題是漏洞數量巨大，所有組織都在努力應對基礎架構和應用程序中層出不窮的新漏洞。當以越來越快的速度向內部和外部客戶提供系統、應用程序和功能時，安全性也應得到切實保障。
SANS漏洞管理成熟度模型提供了流程、成熟度級別劃分，資產、漏洞、威脅的上下文信息以及關鍵度量指標（Key Metrics）?？蓞⒖即四Ｐ蛠硗晟坡┒垂芾沓绦?。
SANS漏洞管理成熟度模型將生命周期管理流程分為準備（Prepare）、識別（Identify）、分析（Analyze）、交流（Communicate）、處置（Treat）五個環節。每個環節又劃分為Initial（Level 1）、Managed（Level 2）、Defined（Level 3）、Quantitatively Managed（Level 4）、Optimizing（Level 5）五個成熟度級別。
