0x00、工作負載漏洞管理需求
在中大型政府或者企業安全治理過程當中，無法回避的一個問題就是承載業務系統的工作負載漏洞管理，無論是在平臺建設初期，上級監管部門對平臺等保合規的監管要求;還是護網重保期間或者日常安全運營的期間，防范來至犯罪集團APT攻擊。都需要針對工作負載做行之有效的漏洞運營管理。但是，在我接觸到的用戶中，安全運營團隊能充分利用安全產品，達到預期的效果用戶的不多。從工作負載漏洞管理價值角度思考，
一、安全防范效能提升工具
在CSO眼中，工作負載管理系統是安全防范效能提升工具，通過產品提供的能力，降低安全人員的時間投入，當您作為安全運營人員，負責上千臺或者上萬臺服務器的漏洞管理工作，你需要的是：
1、全網工作負載快速漏洞檢測
當你新到一家公司，無任何商業化的漏洞管理工具，這種情況，你只能在單機上通過傳統的腳本統計漏洞信息，然后匯總到一起，使用excel輸出漏洞報表。這種方法工時至少1人周。對于安全運營的投入ROI太低。
2、批量自動修復
檢測出來漏洞列表后，就需要修復，如果通過腳本修復，需要把修復不成功的原因上傳到服務端，同時，對修復過程中出現的各種各樣的問題，要及時處理。例如：物理機內核補丁修復，云主機內核漏洞修復失敗，容器內置組件。
二、工作負載漏洞運營另外一個價值點在于提升安全防范能力。
1、當有最新漏洞出現的時候，需要及時修復，防止公網和內網的0day入侵。
2、在護網/重保期間，由于業務系統組件迭代頻繁，導致很多新上的組件引入了新的漏洞，需要防止公網和內網的0day入侵。例如：主機上應用于本地提權的漏洞，web組件入侵常用的fastjson。
3、如果是政務云系統，那需要過合規這關，需要導出累積修復漏洞列表。
三、目標對象
目前，在公有云、私有云、混合云中，主要分兩部分，一是租戶側工作負載的漏洞管理，涉及到的對象，有虛擬主機、原生容器&K8s、用戶自建容器&K8s。虛擬主機是目前主流的工作負載，還有一些創新企業，為了，進一步提升資源利用率，開始嘗試容器平臺取代虛擬化平臺。所以自建容器&k8s需要支持。對于安全級別要求比較高的企業，容器平臺使用的原生容器(有精簡的操作系統做隔離)，這種場景也需要支持。對于平臺側安全，其實就是物理機、容器平臺。
0x01、產品設計
整體架構設計
業務流程，分為漏洞庫建設，客戶端采集軟件信息上傳對比，漏洞信息展示與修復。
1、通過各種線上漏洞數據源，定期下載相關文件，xml解析，同時根據需求把各個漏洞數據寫入到elasticsearch中。
2、同時下載yum/apt源數據，把yum/apt對應軟件的版本低于漏洞數據源期望的軟件版本，設置成不對用戶展示。對新增漏洞在測試環境中自動修復，返回修復失敗的軟件也設置對用戶不可見，實現漏洞庫準入管理。
3、前臺用戶點擊全局驗證時，通過服務器端任務管理系統，下發檢測命令，客戶端會上傳rpm、deb包數據。通過對比程序把存在漏洞的軟件寫入到漏洞展示庫elasticsearch中。
4、前臺用戶點擊自動修復時，通過服務器端任務管理系統，下發自動修復命令。由客戶端執行，并且反饋結果到elasticsearch中。
模塊1：漏洞庫建設
@1、需要獲得RSHA和USN漏洞相關資源，主要是根據開源操作系統提供的漏洞公告，關聯對應的CVE數據。然后通過CVE中CVSS對漏洞評級或者分類。中文部分調用自然語言學習API處理入庫。
https://oval.cisecurity.org/repository/download
http://cve.mitre.org/data/downloads/index.html
需要提取的字段
@2、提供產品調用OpenAPI
1、漏洞檢測OpenAPI
輸入：客戶端獲取到軟件名稱以及軟件版本，返回：以上所有字段
2、漏洞庫管理API
需要對漏洞庫實現準入機制;同時對入庫的各個字段進行編輯，包括：是否前端展示，中文描述，RHSA/USN安全公告中文，安全公告類型標識中文，安全公告類型標識英文
@3、提供增量更新機制
模塊2：客戶端采集數據
數據庫結構設計
rpm-qa獲取軟件包信息
yumdeplist
通過日志模塊上傳到logstash，寫入到elasticsearch服務器。
模塊3、漏洞展示&修復
數據展示部分：
通過主機視角、漏洞公告視角展示相關的漏洞信息。
同時通過漏洞安裝狀態返回，例如：依賴版本修復狀態，yum/apt源配置。
任務下發部分：
通過用戶界面觸發全局驗證、或者單臺驗證、或者單個漏洞驗證。通過任務控制模塊傳遞到客戶端，執行日志上傳模塊。
0x02、漏洞運營
無論產品易用性做的有多好，也需要人員來維護。產品方面盡量做到標準化，當然也會碰到異常情況。這時候就需要，產品研發團隊和用戶漏洞運營團隊齊心協力把問題解決。
如若轉載，請注明原文地址。
