摘  要：當前漏洞的數量快速增長，危險級別不斷提升。為了有效降低用戶面臨的風險，應深入研究美國國家電信和信息管理局和 FIRST（公共漏洞披露平臺的管理者）頒布的《漏洞多方協同披露指南與實踐》，從機制、舉措方面總結指南與實踐在不同情況下對漏洞協同披露的流程，歸納產生的原因及有效的應對措施，并結合我國的實際情況提出相應建議。

　　0

　　引言

　　目前，活躍的開源開發社區、bug 獎勵計劃的激增、供應鏈的日趨復雜，使得包含漏洞的部件存在多個產品共用的情況，影響范圍極廣，對漏洞的披露和修復帶來巨大的挑戰。已有的對漏洞協同披露主要依靠研究人員和供應商的直接溝通，存在覆蓋范圍不全、修復不及時等問題，使漏洞暴露的時間窗口加大，給用戶帶來巨大的安全隱患。現今，漏洞的披露迫切需要日益復雜的多方協同，像 Heartbleed 這樣的漏洞進一步凸顯了對多方協同披露的挑戰[1]。

　　美國作為互聯網的締造者和眾多權威漏洞披露平臺的所在國，國家電信和信息管理局（NTIA）、事件響應和安全團隊聯盟［FIRST，公共漏洞披露平臺（CVE）的管理者］在參考已有的披露機制基礎上，如多方利益相關者共同披露[2]、CERT 的協同披露指南[3]、ENISA 的漏洞披露最佳實踐指南[4]、ISO/IEC 的漏洞披露標準[5]、NIAC 的漏洞披露指南[6] 等，重點考慮供應鏈各元素如何在漏洞披露過程中的協同處理，共同頒布了《漏洞多方協同披露指南》[7]（以下簡稱“指南”）。它是管理者共同努力解決多方協同披露挑戰的結果，目的是幫助改善并建立不同利益相關者間的多方漏洞協同披露機制。該指南考慮了不同情況下漏洞的協同披露場景。

　　本文從相關概念及定義、基礎性工作、不同場景下披露流程等方面對《漏洞多方協同披露指南》進行梳理及分析研究，并對如何指導我國漏洞管理工作提出相關的建議舉措。

　　1

　　多方協同披露的相關概念及定義

　　在協同披露的流程中，不同參與者發揮的作用和需要采取的動作存在差異，因此對披露流程中其涉及的角色、動作等相關概念根據 ISO/IEC 29147:20143 中提供的定義做了最小程度的修改。

　　* 公告：聲明或公告，用于通知、建議和警告產品的漏洞。

　　* 協調人員：可選參與者，可協助產品供應商和漏洞發現者處理和披露漏洞相關信息。

　　* 防御者：負責防御攻擊的利益相關者。防御者可以是系統管理人員、供應商或防御技術及服務的提供者。防御者可以檢測易受攻擊的系統，對攻擊進行檢測和響應，并執行對漏洞的修復及管理。

　　* 披露：最早向不被認為存在漏洞的一方提供漏洞信息的行為。整個披露過程通常包括多個披露事件。

　　* 暴露：從發現漏洞到無法再利用漏洞之間的時間。

　　* 發現者：識別產品或服務中潛在漏洞的個人或組織。例如，發現者可以是外部安全研究人員。

　　* 緩解措施：降低漏洞被利用的可能性或可利用范圍的措施。

　　* 修復：補丁、修補、升級、配置或文檔變更，以移除或緩解漏洞。

　　* 供應商：開發產品、服務或負責維護產品的個人或組織。

　　* 對等供應商：處于供應鏈同一層級的供應商。對等供應商可以是相同技術（例如，OpenSSL 和 GnuTLS）的獨立實現者或相同上游技術（例如，Red Hat 和 SuSE）的下游用戶。

　　* 上游供應商：向下游供應商提供產品或技術的供應商。

　　* 下游供應商：從上游供應商處獲得產品或技術并用于下游供應商的產品、技術或服務的供應商。

　　* 漏洞：軟件、硬件或服務中可被利用的脆弱點。

　　眾多利益相關角色之間的關系和通信路徑如圖 1 所示。

　　圖片

　　圖 1　利益相關角色及通信路徑

　　2

　　多方協同披露的基礎

　　指南討論了多方協同披露的實例，歸納起來，多方協同披露需要在統一的共識、遵循相關的原則、降低漏洞暴露的時間窗口、合理設定協調人員的介入時機等基礎上，對漏洞的協同披露做出及時的響應。

　　2.1　達成統一的共識

　　所有參與披露各方，特別是供應商，應建立并公布可采取行動的公開漏洞系統披露策略及預期，包括披露的時間表和閾值。各方應保持對等方和其他潛在利益相關者群體的危機意識。

　　供應商應預先建立上游和下游供應商關系和溝通渠道，以了解潛在影響和統一的協同披露時間表。此外，還應考慮跟蹤第三方組件的使用情況，以更好地開發庫存并了解上下游間的依賴。

　　2.2　漏洞披露應遵循的原則

　　漏洞披露前，各方的溝通應遵循以下原則。

　　第一，參與披露的各方應清楚、安全地溝通和協商預期和時間表。

　　第二，供應商應提供當前可接受的聯系機制。

　　第三，參與披露的各方應對每一次溝通進行確認。

　　第四，供應商或協調人員應與發現者保持頻繁溝通，包括狀態披露時間表的狀態更新和潛在影響。

　　第五，漏洞發現者應提供清晰的文檔和工具，以支持漏洞驗證。第五，漏洞發現者應提供清晰的文檔和工具，以支持漏洞驗證。

　　第六，供應商應明確記錄產品支持的時間表和限制。

　　第七，各方應避免個別通信故障點。

　　在漏洞披露后，各參與方應遵循以下原則。

　　第一，供應商應以人工和機器可讀格式提供與漏洞保護和緩解措施相關的明確建議和公告。

　　第二，除了通過通用電子郵件進行溝通，供應商還應為上游和下游利益相關者確定專門的聯系方式。如果需要，供應商應利用協調人員進行廣泛的溝通和協調。

　　第三，各方應利用通用漏洞的跟蹤和聚合能力，如 NIST 國家脆弱性數據庫（NVD）和通用漏洞披露（CVE）。

　　第四，所有各方，特別是CVE 編號機構（CNA），應遵循適當的指南來分配 CVE 編號和填充 CVE 條目。

　　第五，各方應提供信息，幫助其他利益相關者評估與漏洞相關的嚴重性、優先級和風險，如通用漏洞評分系統（CVSS）。

　　在對漏洞的披露做出響應時，應遵循以下原則。

　　第一，涉及的各方應采取措施確保通信和處理敏感信息的安全。

　　第二，供應商在安全許可發布之前必須對更新進行嚴格測試。

　　第三，供應商可以建立缺陷獎勵計劃，信用或安全港，以在發布前主動識別漏洞。

　　第四，各方應盡可能避免事態升級。利益相關者應鼓勵在相關法律框架內進行安全研究和協調披露。

　　2.3　盡量減少利益相關者的暴露

　　多方協同披露的目的是減少利益相關者暴露的時間窗口，為達到這一目標，需要注意的事項如下。

　　第一，供應商可以按照預先確定的時間表（例如，星期二修補）發布補丁。在可能的情況下，更新和補丁應只包括安全設施，而不包括新功能或者非安全缺陷域。如可能，供應商應為用戶提供自動更新流程，用戶應啟用供應商補丁自動更新功能。

　　第二，供應商應意識到，修補措施的發布可能披露其他供應商組件中存在的相同漏洞。

　　第三，供應商可以提供任何可用的緩解措施或變通辦法來降低漏洞的影響，即使它們可能導致一些服務降級。

　　第四，利益相關者應考慮部分的、初步的漏洞公開披露。在缺乏明確證據證明事先公開披露（包括積極利用）的情況下，利益相關者應向供應商提供合理的禁售期，以調查和開發修補。

　　第五，下游供應商應考慮在上游供應商推薦一個新版本后盡快更新其組件。

　　在漏洞披露的過程中，需要對早期披露迅速做出快速的反應以最大限度地降低漏洞的影響范圍。在漏洞的早期披露時期，供應商可分析情況并制定優先補救時間表，應向用戶提供關于漏洞信息及潛在的緩解措施。在可能的情況下，供應商可以聯系漏洞發現者確定早期披露的范圍并實現損壞控制。

　　2.4　協調人員介入的時機

　　協調人員之間應建立并保持聯系，以促進披露工作的進行。當涉及多個協調人員時，為避免混亂，應該有一個協調人員被選為負責人來主導協調工作。

　　協調人員可以幫助聯系研究人員、供應商和其他利益相關者，當涉及多方（供應商）或無法聯系一方（供應商）時，這一點尤為關鍵。此外，還可借助其他力量，為研究人員、供應商和其他利益相關者提供額外的技術、影響和范圍分析，特別是在一些技術點存在分歧時。

　　3

　　不同場景下多方協同披露漏洞的流程

　　由于漏洞的披露通常偏離預期的或理想的過程，每個應用場景示例中可能存在諸多特殊情形，指南對此也進行詳細的闡述，包括產生的原因、如何響應及預防措施等。

　　涉及多方的漏洞協同披露，根據受影響的用戶、披露的時機、公開細節內容的程度，包括不存在受影響的用戶、漏洞的協同披露、修復前公開有限的漏洞信息、在供應商發現前公開信息或利用漏洞四種典型的應用場景。

　　3.1　不存在受影響的用戶

　　沒有用戶的軟件或硬件漏洞是一個安全漏洞，不會以任何方式影響其他人，如圖 2 所示。這種情況的例子包括非生產性、實驗性、內部或個人使用、從未出版或出售或者正在開發的產品。

　　圖片

　　圖 2　產品存在漏洞但不存在受影響的用戶

　　3.2　漏洞的多方協同披露流程

　　在協同披露過程中，以下利益相關者扮演某些角色：漏洞的發現者，使用標準漏洞報告渠道與供應商聯系；供應商，當供應商修補漏洞時，在適當的時間，與上游和下游供應商進行溝通，并根據需要發布公告；防御者，制定緩解措施或簽名，以檢測和保護用戶免受漏洞的影響，而不包含或暗示可能有助于潛在攻擊者的信息，同時要求供應商提供相關測試用例，以檢測基于重現的高級威脅；用戶（user），盡快部署供應商提供的補丁程序或緩解措施。

　　在漏洞信息未公開的情況下，協同披露的一般流程如圖 3 所示。

　　圖片

　　圖 3　漏洞的協同披露時序圖

　　在漏洞的協同披露時，會存在上游供應商之間無法聯系的情況，此種情況下需要協調人員的介入，介入后的披露過程如圖 4 所示。在這種情況下，協調人員稱為溝通的中心節點。

　　圖片

　　圖 4　上游供應商之間無法通信

　　相對于漏洞信息的完全公開，大多數情況下是發現者發布了一些關于該漏洞的信息，但沒有給出如何利用該漏洞的提示。作為全面公開披露和私下協調披露之間的一種中間方式，發現者或供應商可以發布一些關于漏洞的存在及其披露時間表的初步通知。所披露的信息可能包含易受攻擊的產品或組件的名稱、最壞情況的影響以及未來公告的鏈接，但不提供關于如何利用該漏洞的任何提示，例如源代碼更改或漏洞類型。這種情況在漏洞影響范圍較廣、保密性存在較大困難時比較常見。這種情況下的漏洞協同披露時序及用戶面臨的風險如圖 5所示。

　　圖片

　　圖 5　修復前的協同披露時序及用戶面臨的風險

　　當在已部署的產品中發現漏洞時，發現者通過在互聯網上發布、郵件列表、學術論文或會議等方法，使任何人都可以獲得該漏洞的所有信息。披露的信息可能包括有缺陷的產品和版本、能夠觸發或證明漏洞的驗證代碼，以及缺陷或攻擊方法的詳細解釋。在不等待開發或部署修復或緩解措施的情況下進行漏洞信息的公開披露，被稱為“全面披露”或“零日”。這種情況下的漏洞協同披露時序及用戶面臨的風險如圖 6 所示。

　　圖片

　　圖 6　在供應商發現前公布或利用漏洞

　　3.3　制定網絡軍控的發展路線

　　指南中對上面提到的不同場景的用例可能存在的情況進行分析，主要是針對協同過程中可能出現的種種情況進行列舉，并對每種情況下產生的原因、應該如何進行預防和響應給出了詳細的解答。

　　產生的原因，從漏洞發現者的動機、供應商的響應、用戶的敏感度等方面進行了分析，歸納起來有以下幾點。

　　第一，漏洞發現者在修復之前便公布細節信息。

　　第二，   漏洞發現者為了某種利益直接公布信息，導致漏洞被利用，用戶面臨極大的風險。

　　第三，供應商之間的溝通協調機制不通暢。

　　第四，供應商或協同人員在漏洞修復前公布細節。

　　第五，供應商對報告的漏洞未采取任何補救措施。

　　第六，供應商未將漏洞信息通報給所有受影響的產品供應商。

　　第七，用戶對漏洞修復信息不夠重視。

　　為了將用戶的風險降到最低，指南對上面提到的不同原因產生的場景如何預防做了詳細的指導，總結看有以下幾方面。

　　在產品生產的全周期內進行安全審計，一是確保不存在已公開的漏洞，二是避免堆棧溢出、引用過界等明顯漏洞的出現。

　　加快供應商的漏洞修復節奏，縮短漏洞利用的時間窗口。

　　自動更新機制的引入，避免由于用戶薄弱的安全意識而帶來的風險。

　　產品供應鏈上的供應商應建立完善、順暢的協同機制，使得漏洞的修復可以在最短的時間內完成。

　　漏洞的修復應盡可能擺脫對產品的依賴，降低修復的難度。

　　4

　　結　語

　　漏洞已對當前的網絡帶來嚴重的安全隱患，日趨復雜的產品供應鏈為漏洞的修復帶來了巨大的挑戰，為最大限度地降低漏洞暴露的時間窗口，NTIA 和 FIRST 頒布了協同披露指南。指南中，對不同情形下的漏洞協同披露、如何預防以及回應給出了詳細流程和應對措施，為我國漏洞的管理組織給出了參考與借鑒。

　　圍繞降低漏洞暴露的時間窗口和“零日”漏洞的應對，可以加強以下四方面的工作：

　　充分發揮國家互聯網應急中心的統籌作用。國家互聯網應急中心作為對國內互聯網安全事件的應急響應中心，可以統籌網絡安全廠商的先進技術，對已有的漏洞進行常態化的檢測預警，并設置相應的修復機制，將用戶的風險盡可能地降低。

　　充分發揮我國國家漏洞庫的協調作用。國家漏洞庫是由國家互聯網應急中心聯合國內重要信息系統單位、基礎電信運營商、網絡安全廠商、軟件廠商和互聯網企業建立的國家網絡安全漏洞庫。可以充分利用國家平臺的優勢，聚焦減少影響范圍，通過行政、技術雙重手段，發布漏洞的協同響應機制，及時跟蹤處理國際平臺的最新漏洞披露信息，盡可能降低我國受影響產品暴露的時間窗口。

　　充分調動國家網絡安全人才團隊的技術力量。暢通地方網絡安全人才的技術支持渠道，充分利用地方網絡安全的強大技術實力，通過協同披露機制，協調服務提供商，對發現的漏洞進行及時修補，將漏洞的暴露時間降到最低。

　　加強網絡行為審計工作。從前面的介紹中可以看出，“零日”漏洞的危害是最大的，需要加強網絡行為的審計工作，尤其是關鍵基礎設施，將行為審計作為常態化的工作。通過異常行為的發現，反溯、定位漏洞的位置及類型，及時修補。