漏洞治理平臺的設計與實現
幾個月前筆者曾經梳理過技術方面的漏洞處理的心得，經過幾個月的實踐和迭代，我們在公司內推出了漏洞治理的概念，並進行實踐中。本文就漏洞治理體系的設計和實現的各個環節做個詳細的闡述。
適用場景：
業務系統邏輯複雜，部門間關係較複雜，對網路安全敏感性高的環境。（當然內部環境簡單的企業也可以採用，但會感覺方案太重）
整體架構：
整體架構從 資產發現 開始，第二個階段是 漏洞掃描 ，第三個階段是 漏洞處理 ，第四個階段是 資料分析和展示 。我們逐個展開一下：
一、資產發現
對於安全和運維工作來講，資產是一切的基礎，其重要性怎麼強調都不過分。但大部分企業資產管理工作都不是安全部門的職責，如果運維部門能提供準確、全面的資產資訊，那是非常幸福的事，此段可以直接略過。但從筆者瞭解的情況看，很多企業這方面的工作都或多或少的有所欠缺尤其是經歷了快速增長期和漫長建設期的企業更是如此。
1.1 IP&服務資產
為了安全檢查的全面性，安全部門的資產發現至少要確認IP、埠和服務，至於業務線和負責人的資訊可以交給相關資產管理部門來完善。具體方法如下：
技術選型： 經過多方面考慮我們還是選擇功能非常成熟的nmap，通過排程程式啟動多個nmap程序，並將任務分解後下發給不同nmap；
使用方法：
① 第一步還是 探活 ，我們用-sn完成探活，這裡需要說明一下，很多文章講-sn的時候都說僅僅是ICMP探測，但通過抓包我們發現實際策略是ICMP+80+443。
圖1：抓包中的發現
圖2：原始碼中的發現
為了增加準確度，我們進一步將nmap原始碼中探活策略修改為更多常用埠（如：增加22、3389、3306等），具體埠資訊可以根據企業實際情況酌情處理，但不要增加太多，以免影響效率。
② 探活之後就是 全埠和服務發現 ，這部分就用nmap原生功能就沒問題。
③ IP&服務下線策略 ，實際掃描中我們發現nmap會由於各種原因導致漏報，所以不能在新一輪掃描沒發現某個服務就直接判斷該服務失效。我們的策略是連續三次掃描中都沒發現該服務才會將該服務判定為下線。
1.2 url資產
相對於IP資產，url資產是比較麻煩的，單獨用一種手段很難完全滿足需求。我們基本上通過兩種手段：爬蟲和流量解析，稍稍展開一下。
①爬蟲：我們是通過改造幽靈蛛（ https://github.com/henrylee2cn/pholcus ）實現的，目前效率還可以接受，一臺sever限制一個主域爬15層，2個小時內完成140萬個連結的任務。
②流量解析：爬蟲的諸多侷限性不用多說，所以我們將訪問流量解析出的url與url資產列表比對，有新增的加入到資產表中。另一個角度說，如果沒有請求，就算這個url存在我們也不必要去檢查漏洞，因為根本沒人訪問（包括黑客）。但流量解析涉及到每秒幾十萬使用者請求的情況下如何快速去重，我們還在實驗中。
二、漏洞發現
有了資產資訊，下一步就是漏洞發現了，漏洞發現我們通過三類邏輯實現：資產資訊匹配，商業掃描器，自主開發掃描器。
2.1 資產資訊匹配
這類方法主要適用於0day漏洞爆發，在沒有驗證指令碼的情況下，通過版本資訊來判斷漏洞影響範圍。這個比較好理解，就是前端頁面設計的時候注意搜尋條件的填寫就好。這類方法檢查漏洞是有一定缺陷的，所以我們還要用掃描器完成外部掃描工作。
2.2 商業掃描器
商業掃描器大家都比較熟悉，優勢是技術成熟、漏洞資訊全面、部署簡單；但缺點也很明顯：
-
掃描速度很慢，我們的經驗是約6000臺sever需要三週
-
大量漏洞資訊需要忽略，導致整理報告時間很長
-
漏洞更新需要依賴廠商，無法自定義
2.3 自主開發掃描器
為了解決商業掃描器的上述問題，我們設計並開發了自己的掃描工具，這裡簡述一下實際執行邏輯，具體的實現方法暫不過多展開，我會用單獨一篇文章闡述。
核心掃描元件： 我們分別用java、python和Go做了分散式框架，目前看Go的效果最佳，但Python的適配性最好。基本方法是將資產資訊拆分成以服務為單位的條目（如：一個IP開了三個服務，就是三條資產資訊），存在Redis中，掃描程序啟動時會先載入 POC庫，在逐條獲取Redis中的資產資訊，完成匹配後開始掃描工作。需要注意的是這類高併發掃描邏輯要考慮被掃描資產的承載能力，儘量把壓力分散到不同被掃描裝置上，分散方法有很多，比如將POC和資產一一對應後隨機進入掃描任務，或者以POC為核心邏輯，POC1下所有IP掃描完成後再掃描POC2等等，總之 不要盯著一個IP玩命掃 就是了。
這裡可以優化的點是：由於我們的掃描節點和控制節點是分開的，所以獲取資產資訊的時候可以同時獲取一組，避免網路延時對效率的影響，這還要看具體資料。
圖3：分散式掃描邏輯示意圖
漏洞掃描元件與資產發現元件的配合： 我們打破了傳統掃描器中資產掃描和漏掃序列的方式，將資產掃描和漏掃非同步進行，可以隨意調整，基於此我們設計瞭如下邏輯：
① 資產掃描後針對新增資產進行漏洞掃描，比較特殊的情況是：系統第一次執行所有資產都是新增的，所以第一次漏掃是全網掃描。之後每次資產掃描後，只針對新增資產進行漏掃。重點來了，這個邏輯將迴圈執行，我們起名叫“永不停歇模式”。
② 根據資產列表中的資產資訊，做定期的全資產掃描。這個掃描週期我們設定的是三天。
基本邏輯說完了，解釋一下這麼做的 理由 ：按經驗來說漏洞的高發區域就是新增的資產和服務，所以我們將資產發現和新增資產漏掃的工作執行了“ 永不停歇模式 ”。資產資訊不變不代表漏洞情況不變，但屬於較低概率事件，所以進行週期掃描。這麼做的另外一個好處是，執行POC會產生很多系統日誌，雖然我們寫了一些過濾指令碼，但也有很多過濾不完全的系統還是會產生大量垃圾日誌。但資產掃描的情況就會好很多，所以週期執行資產掃描，定期執行全網漏洞掃描可以有效減少垃圾日誌的產生。
三、漏洞處理
我們日常安全管理的一個很重要的工作就是督促整改，但從筆者瞭解的情況看，很多企業都遇到過修復漏洞工作推進十分困難的情況，這也直接導致了安全團隊與運維和開發團隊的對抗情緒。
筆者團隊一直致力於讓非安全部門更主動的修改漏洞，我們在去年（2017）根據實際情況建設了“漏洞管理平臺”，主要實現如下三個層面的能力：
① 便捷 ：任何產品級系統便捷性都是最基礎、最重要的事。所以，驅動業務使用安全部門“平臺”的最低要求就是--不能比處理郵件麻煩。這個要點就是前端頁面設計和通知手段的多樣化。
② 驅動 ：比便捷更穩妥的方式是讓系統有驅動力，驅動力的來源是領導們的關注，這個層面我們是通過資料分析和展示系統給領導看來解決驅動力的問題。
③ 主動 ：驅動畢竟有一定強制的成分在，所以比驅動更高的一個層次是讓運維和開發主動來看，這要求“平臺”的內容對運維和開發有吸引力。這個層面的問題我們也在實驗中，比如積分制，配合一些精神和物質的獎勵等。
具體實現邏輯如下：
圖4：漏洞管理系統邏輯
上面的邏輯圖看起來複雜，簡化來說有如下三個階段，就可以實現基礎能力：
① 漏洞入庫
商業掃描 器掃描結果有人工篩選後分別進入兩個庫：一是流轉庫，走漏洞修復流程，下面會說；二是“低危庫”，我們私下也叫垃圾庫。 商業掃描器的掃描結果會有大量這類的資訊， 是我們認為不需要修復的漏洞資訊。那為什麼我們還要存呢？這是個很實際的問題，很多企業應該都會遇到過上級檢查單位下發的漏洞整改通知，這些漏洞很多都是不必要整改的，但報告發到領導手上就會比較緊張。所以 “低危庫”就是告訴領導：我們發現過，但是經過判斷不用整改。
自研掃描器 的結果由於是自己寫（或蒐集）的POC的檢測結果，這裡沒有低危資料，所以自研掃描器的結果直接入流轉庫。
② 漏洞流轉
漏洞流轉的方式和目前大部分開源的漏洞管理系統流程非常相似，都是對漏洞做全生命週期管理，基本設計到5個關鍵點的把控：發現、通知、整改、複查、復發。前面四個階段都好理解，這裡面最難定位的就是復發，我們也一直在研究復發的定義、定位和處理方式。目前比較容易的是弱密碼和一些系統漏洞，web漏洞復發定位相對難一些。另外一個小亮點是“ 自動複查 ”，一旦漏洞狀態變成“已整改待複查”後，會出發掃描器自動複查。除非恰巧碰到掃描佇列裡有任務，正常情況下單IP、單服務、單POC的執行速度是非常快的。
③ 流程資料儲存
這些資料主要用於後面的分析及展示，建議能想到的資料都留存下來，資料量不會很大。資料應用主要通過下一部分來介紹。
四、資料分析及展示
我們做資料分析的最初訴求是基於業務做狹義的風險評估，以此督促業務整改漏洞。但現在看來，這部分的工作至少還有兩方面的用途：一是體現安全部門工作量；二是積累相關資料為必將到來的機器學習做資料積累。資料展示方面的內容不太具備通用性，我們基本通過如下三個維度做資料分析：
① 漏洞概況分析 ，包括一些比較通用的統計，如：各類漏洞的佔比，高危漏洞的業務分佈，新增漏洞趨勢等；
② 督促性分析 ，以業務為單位的未修復漏洞超時時間總和排名，最近一個月新增漏洞整改率排名，漏洞高危漏洞平均修復時間排名等；
③ 內部（外包）團隊工作效果評估 ，因為所有漏洞資訊（包括 無需整改的漏洞 ）都在系統中存在，所以一旦有外部（包括上級單位，兄弟單位，SRC等）提交的漏洞資訊，可以馬上有針對性的對團隊能力進行評估。
因為筆者的開發團隊沒有UI設計能力，所以上述的視覺化呈現都是以餅圖和柱狀圖的形勢呈現，比較醜，就不截圖了 
五、展望未來
目前筆者團隊已經基本完成上述平臺的設計的所有功能，但我們認為這僅僅是個開始，漏洞治理工作還有很多事情要做，未來我們希望在下面幾個層面進一步深入：
-
特殊系統漏洞目前還無法掃描 ：一些專業裝置不能識別，尤其是一些閹割版的Linux系統。筆者遇到過不止一次遇到接收畸形包就自殺的裝置。針對這類裝置我們需要進一步的識別，識別出來之後只能先忽略，專用裝置的漏洞實在無力去跟蹤，只能寄希望於廠商。
-
自研掃描器的POC跟蹤 ：自主研發這件事說起來跟牛X，但具體落地會面臨很多問題。POC實時跟蹤對我們來說就是一個難點，我們目前只能實現對開放POC的改寫和嵌入，目前還沒有根據利用程式碼形成POC的能力。我們希望日後一方面加強團隊能力，另一方面可以通過一些商業合作補充這方面的不足。
-
從機器漏掃到機器滲透 ：提到機器滲透目前我們要做的並不是要替代所有滲透測試工作，只是能說清楚邏輯，能通過簡單程式碼實現的滲透工作一點一點的積累，從而替代一些比較初級的滲透工作，筆者認為邁出這一步跟重要。
-
從機器滲透到機器學習滲透 ：這裡沒有用“智慧滲透”或“AI滲透”的名字，但意思是一樣的。這是從量變到質變的過程，現在已經有商業公司實現了產品化（但不太瞭解效果）。這個昇華的門檻在於現在是AI大火的時代，人才緊缺。另外就是如何將滲透邏輯模型化在不同決策點做積累不同資料進行不同訓練，這也要很專業的人才才能搞定。所以目前筆者團隊對此暫時只能想象，期待有大神級的技術或產品出現。
-
自動修復漏洞 ：這也是我們想象的一部分，雖然大量漏洞都有修復建議，但自動修復這件事還是有太多問題存在，但如果我們把一些能工具化的操作都固化下來，配合一些自動化運維的手段是否可以實現一些這方面的能力呢？我們還在思考。不過最簡單的情況，發現弱密碼後自動改成強壯的密碼，再發給業務，應該是可行的，不過我們沒做過。
寫在最後
這篇文章準備的時間確實長了點，但沒想到會寫這麼長。能看到這裡的小夥伴們辛苦了！！對漏洞做這麼多工作主要是日常痛點太多，才不得不花費精力搞一套系統，希望能一勞永逸。這套系統設計的根本理念，就是想把比較複雜和繁雜的工作放到後臺，能工具化的全面工具化。讓不懂安全，甚至不懂技術的人能方便的處理漏洞。我們會朝著這個方向繼續努力，希望得到更多大神支援，對這方面工作有興趣的小夥伴歡迎關注我的公眾號或加我微信（微訊號：huangle0914）深入探討。