中通作為一家集快遞、物流、電商、金融等業務於一體的大型集團公司，近些年業務爆發式增長、it人員飛速擴張，相對的整個安全攻擊面也在擴大，企業內的安全性漏洞也在新增。傳統的漏洞管理管道使用excel錶人工記錄並跟踪維護，隨著系統及漏洞的增多，這種管道暴露出統計困難、跟進困難的問題。這時候迫切需要一個系統來管理整個生命週期。

每家公司基本都有漏洞管理系統，但是對於該系統的理解及定位都不太一樣。大多數公司只是讓研發部門，開發了一個有漏洞錄入、追跡、統計等基礎功能的系統，少部分公司如宜信的洞察則是集成了資產管理、風險計算、安全知識庫等管理模塊對整個漏洞的生命週期進行管理。開源漏洞管理系統在一些細節上如接入統一認證，接入許可權系統沒有接入入口，為了定制化一些功能，需要對開源系統進行二次開發，現時開源的系統不是團隊熟練的科技棧，開發成本會增大。

• 將資料同步到安全管理運營平臺，向不同層級的人展示安全性漏洞情况

將資料同步到安全管理運營平臺，向不同層級的人展示安全性漏洞情况

• 開發了漏洞處理模塊，對產生的漏洞進行線上的錄入，分類，複測，歸檔，統計

開發了漏洞處理模塊，對產生的漏洞進行線上的錄入，分類，複測，歸檔，統計

• 使用不同種類的通知提醒管道，採用郵件、釘釘、統一認證APP、簡訊通知，將通知、提醒貫穿到整個漏洞管理生命週期中，讓開發及時收到漏洞資訊

使用不同種類的通知提醒管道，採用郵件、釘釘、統一認證APP、簡訊通知，將通知、提醒貫穿到整個漏洞管理生命週期中，讓開發及時收到漏洞資訊

• 豐富資產管理內容，將功能變數名稱、組件、中介軟體、web框架、應用連絡人等列入到資產管理中，在爆發出新的安全性漏洞時，可以快速定位出存在漏洞的業務並通知業務連絡人

豐富資產管理內容，將功能變數名稱、組件、中介軟體、web框架、應用連絡人等列入到資產管理中，在爆發出新的安全性漏洞時，可以快速定位出存在漏洞的業務並通知業務連絡人

結合現有資源及對漏洞管理的理解，開發了同安漏洞管理系統，貫穿整個軟體發展生命週期，幫助安全運營人員高效的處理日常的安全性漏洞。

系統採用react+go+mysql+etcd開發

• 對接系統：CMDB、品質控制中心、自動發佈

對接系統：CMDB、品質控制中心、自動發佈

• 對接安全工具：主動漏洞掃描、hunter被動掃描

對接安全工具：主動漏洞掃描、hunter被動掃描

• 對接安全產品：防火牆、Hids、Jumperserver、SOC

對接安全產品：防火牆、Hids、Jumperserver、SOC

整體架構圖如下：

圖1 漏洞管理系統整體架構圖

為我們主要開發了資產管理、安全測試申請、漏洞處理、通知提醒模塊。並基於產生的數據，針對不同層級的同事展示整個安全體系中安全性漏洞的概況。

資產管理模塊，是漏洞管理系統的主要支撐模塊。一個完善的資產管理模塊，可以幫助我們在發現漏洞時快速聯系到相關負責人，在爆發新漏洞時快速定位出問題系統。木桶理論是資訊安全的一個經典理論，防禦要面面俱到，隨便漏掉一個點就可能導致全盤崩潰，駭客往往攻擊的就是疏忽掉的資產。如果說滲透的本質是資訊收集，那甲方防守的要點就是對自身資產的管理。

那麼如何做好資產管理模塊呢？第一步當然要確定我們要收集的資產有哪些，基於經驗我們確定的資產應該有：功能變數名稱、ip、對外映射埠、帳號、authorized keys、內網埠、行程、軟體應用、web框架、組件、rpm、jar包、資料庫，以及對應資產所屬的人員、部門。

那麼如何收集上述這些資產呢？業內主要的幾種做法有主動探測、被動流量監測、主機agent、配置管理資料庫cmdb。基於現有資源，我們現時採用了主動探測、主機agent、CMDB、資產申請審批。

圖2資產收集

主動探測，我們外網主要使用外網安全掃描系統（資產發現模塊），內網掃描集成傳統的masscan+nmap工具，保證掃描速度及埠服務準確判斷。

有這方面功能的主要是Hids，開源的ossec和基於osssec的wazuh等項目，如果要放到線上大規模使用需要投入人力研究和維護，現時暫時沒有專人做這塊。為了彌補這方面的空缺我們購買了商用主機防護，在採購階段就看中其資產清單的功能，收集的資訊包括帳號、authorized、keys、埠、行程、軟體應用、web框架、組件、rpm、jar包。以上資訊均可以通過api介面獲取，可以很好的與資產管理模塊進行打通。

CMDB（configuration management database，配置管理資料庫），獲取應用的基礎數據，包含功能變數名稱應用、ip、負責人等應用基礎數據。為了滿足安全部門需求，讓運維開放了功能變數名稱解析記錄的api，可以實时獲取外網新增功能變數名稱。

流程審批現時包括了埠映射申請、協力廠商系統採購安全風險評估申請。

一些協力廠商系統的開發商不重視安全，購買來的協力廠商系統經常出現安全性漏洞。基於過往的慘痛教訓，我們的做法是在採購階段就會對協力廠商系統進行安全評估，如果所要交付的系統屬於“骰子系統“（漏洞很多）且沒有安全相關的投入，安全將使用一票否决權不與其合作。

通過以上手法匯總出了我們最終想要的資產數據。除了對資產資訊的日常管理外，我們還需要做一個重要的事情【新增資產的快速安全介入】，要知道外網是被人實时盯著的，現在就需要比一比“攻防“科技了，誰發現新增資產安全問題的速度快。

我們的做法有：

• 新增的功能變數名稱、ip自動添加外網安全掃描  

新增的功能變數名稱、ip自動添加外網安全掃描  

• 對新增資產進行安全測試  

對新增資產進行安全測試  

• 優先處理新增資產的各類安全告警（包括漏掃、waf、入侵偵測）

優先處理新增資產的各類安全告警（包括漏掃、waf、入侵偵測）

圖3新增功能變數名稱提醒

資訊安全部門作為甲方中的乙方，安全測試是為集團、業務提供的一項重要安全服務。隨著資訊安全侵入業務開發流程，業務部門也越來越重視業務系統的安全性。當開發、產品、QA意識到某些功能或系統存在安全隱患時，可以通過同安漏洞管理系統申請安全測試。

圖4自主進行安全測試申請

圖5安全測試申請清單

系統上線前的安全測試是甲方安全中尤為重要的一環。為了能讓安全測試覆蓋的更廣，漏洞管理系統和星雲自動發佈平臺、品質控制中心打通，將安全測試嵌入系統上線流程中，所有系統發佈必須要通過安全測試。

首先由品質工程師在品質控制中心提測，相關資料同步給同安漏洞管理系統，由安全測試人員進行安全測試、漏洞錄入，當存在超危、高危漏洞時不修復系統無法發佈上線。

圖6安全測試准出流程

現時中通線上漏洞的主要來源有菜鳥應急回應中心、中通應急回應中心、內部安全測試、外網安全掃描、安全眾測。涉及眾多集團業務，除了收到集團自身產品的安全性漏洞外，還有整個中通生態圈的漏洞，如中通雲倉、中通商業、中通快運、大譽國際等。

圖7線上漏洞的處理流程

1.從各種管道同步漏洞資訊

2.安全人員確認漏洞後，將在系統上提交漏洞，分配安全性漏洞

3.開發確認漏洞進行修復，修復完成後提複測，複測申請必須寫明漏洞產生的原因及直接負責人

4.安全人員收到複測申請驗證漏洞，漏洞未修復將駁回並通知

其中根據《中通快遞安全風險處理流程》，超危漏洞修復期限為1天，高危漏洞修復期限為2天。如果超過了修復期限將會影響責任部門及個人的績效考核。每個月還會由安全部門牽頭，把產生線上漏洞的部門經理、開發及SQA拉到一起，複盤安全性漏洞產生的原因，避免該類事件的再次發生。

系統上線前的漏洞與線上漏洞的處理主要差別在於，系統上線前的超、高漏洞修復期限是上線前，不修復無法上線。

圖8系統上線前漏洞處理

圖9 安全測試結果必須為通過才能發佈

其中在系統上線前的安全測試中，我們認為所有測試數據都是有價值的，所以開發了burp挿件，將安全測試中的所有請求包、響應包都存到es中並關聯安全測試申請單，這樣做的好處有以下幾種：

• 安全測試可回溯。如果經過安全測試過的系統，上線後發現了高危漏洞，這個時候就有的踢皮球了，是因為安全沒測到呢？還是由於業務部門做了手脚呢？我們可以回溯當時安全測試的數据包，找出是安全人員測試方法存在問題，還是開發在安全測試完成後做了其他改動導致的。如果是安全人員測試方法或科技存在問題，將影響安全測試人員績效考核，安全部門負主要責任，如果是開發人員未遵守發佈規範導致，將由業務部門承擔主要責任，安全負連帶責任。

安全測試可回溯。如果經過安全測試過的系統，上線後發現了高危漏洞，這個時候就有的踢皮球了，是因為安全沒測到呢？還是由於業務部門做了手脚呢？我們可以回溯當時安全測試的數据包，找出是安全人員測試方法存在問題，還是開發在安全測試完成後做了其他改動導致的。如果是安全人員測試方法或科技存在問題，將影響安全測試人員績效考核，安全部門負主要責任，如果是開發人員未遵守發佈規範導致，將由業務部門承擔主要責任，安全負連帶責任。

• 收集到的請求url、參數、響應包內容，可做黑盒的“暴力猜解”。黑盒的安全測試多是基於功能測試，有些隱藏介面是沒放到功能、js中的，除了我們的白盒程式碼稽核、安全網關外能獲取到之外，這個黑盒的“暴力猜解”由於簡單粗暴的特性也是安全測試的一個利器。

收集到的請求url、參數、響應包內容，可做黑盒的“暴力猜解”。黑盒的安全測試多是基於功能測試，有些隱藏介面是沒放到功能、js中的，除了我們的白盒程式碼稽核、安全網關外能獲取到之外，這個黑盒的“暴力猜解”由於簡單粗暴的特性也是安全測試的一個利器。

• 同一類漏洞有一定的共同的特徵，某系統存在問題的介面是queryXXbyXXid，再比如常見的url跳轉、ssrf、檔案讀取，參數名可能是uri，url，file等，遇到這類情况可以直接在es中査詢歷史資料，直接把匹配到請求包拉出來輔助進行安全測試。

同一類漏洞有一定的共同的特徵，某系統存在問題的介面是queryXXbyXXid，再比如常見的url跳轉、ssrf、檔案讀取，參數名可能是uri，url，file等，遇到這類情况可以直接在es中査詢歷史資料，直接把匹配到請求包拉出來輔助進行安全測試。

• 某個漏洞爆發時，如果有一定特徵，這裡也是可以定位的一個部分。可以做的做法如：如果是請求包，響應包中有特徵的直接匹配特徵（如：某漏洞存在於特定的目錄下）

某個漏洞爆發時，如果有一定特徵，這裡也是可以定位的一個部分。可以做的做法如：如果是請求包，響應包中有特徵的直接匹配特徵（如：某漏洞存在於特定的目錄下）

通知提醒的目的在於：

• 提醒開發修復漏洞  

提醒開發修復漏洞  

• 讓相關領導知曉漏洞及危害，協調資源修復漏洞

讓相關領導知曉漏洞及危害，協調資源修復漏洞

• 相關漏洞處理流程走郵件可以通知到相關人員

相關漏洞處理流程走郵件可以通知到相關人員

為了提升通知、提醒的及時率，我們採用多種方式通知、提醒：

• 郵件

郵件

• 中通統一認證APP

中通統一認證APP

• 釘釘應用通知

釘釘應用通知

• 釘釘機器人通知

釘釘機器人通知

• 簡訊通知

簡訊通知

為了保障漏洞可以按時修復，在漏洞錄入時，除了會通知默認配寘好的連絡人，還會自動根據漏洞級別通知到相應級別領導，高危會抄送到經理級別，超危會抄送到總監級別。

在整個安全測試、漏洞處理的過程中均會發處正式的郵件通知。無需正式通知的會以釘釘、統一認證APP通知的形式提醒，如：漏洞申請複測，漏洞駁回。

圖10 安全測試申請

圖11 收到系統上線前漏洞處理郵件

圖12 每日進行線上未修復漏洞通知

圖13 釘釘通知

圖14漏洞知識庫設計

漏洞知識庫的組成部分有：漏洞類型、漏洞名稱、產生原因、危害、修復建議、利用管道、案例、中通真實案例。其中”中通真實案例”由錄入的漏洞修復後脫敏選取。

漏洞知識庫有幾種用途：

• 開發、測試、產品可以自助學習漏洞知識庫的內容，瞭解漏洞原理及修復方法

開發、測試、產品可以自助學習漏洞知識庫的內容，瞭解漏洞原理及修復方法

• 在定期對開發的安全開發技術培訓中會選取相應內容及案例

在定期對開發的安全開發技術培訓中會選取相應內容及案例

• 在定期對質量的安全測試培訓中會選取相應內容及案例

在定期對質量的安全測試培訓中會選取相應內容及案例

• 當開發在開發某功能時，可以查看會出現哪些漏洞。如：登入、注册、密碼找回等

當開發在開發某功能時，可以查看會出現哪些漏洞。如：登入、注册、密碼找回等

有了原理的介紹和真實的案例，開發可以更容易理解自己程式碼中的安全隱患，從而提升開發的安全技能。

未來我們將繼續提升漏洞管理的自動化等級，支持接入協力廠商漏洞報告平臺（如src、補天、漏洞盒子），支持漏洞自動化複測。同時我們還希望將漏洞管理系統開放給生態圈，通過漏洞管理系統輸出安全能力，包括簡單的易上手的資產收集模塊，幫助生態圈內的公司更加快速的收集自己的資產資訊，通過共亯沉澱的漏洞知識，幫助生態圈內的企業提高安全知識水准。以漏洞管理系統作為輸出點為整個中通生態圈進行安全賦能。

作者簡介

opop，中通快遞資訊安全工程師，主要負責中通快遞資訊安全事件的分析和應急處理，參與資訊安全測評和安全加固，開展日常的風險評估工作和滲透測試工作。

團隊介紹

中通安全團隊是一個年輕、向上、踏實以及為夢想而奮鬥的大家庭，我們的目標是構建一個基於海量數據的全自動資訊安全智慧感知響應系統及管理運營平臺。我們致力於支撐中通快遞集團生態鏈全線業務（快遞、快運、電商、傳媒、金融、航空等）的安全發展。我們的科技棧緊跟業界發展，前有React、Vue，後到Golang、Hadoop、Spark、TiDB、AI等。全球日均件量最大快遞公司的數據規模也將是一個非常大的挑戰。我們關注的方向除了國內一線互聯網公司外，也關注Google、Facebook、Amazon等在基礎安全、資料安全等方面的實踐。

加入我們

如果您對我們的團隊或者我們做的事有興趣，也希望在工程技術領域有所成就，非常歡迎加入我們，我們需要資訊安全、分佈式平臺開發、大數據、風控、產品、運營等方面的人才，Base上海，工作地點任選虹橋萬科中心及中通總部。簡歷投遞地址：[email protected]。