DAST 黑盒漏洞掃描器 第六篇：運營篇(終)

0X01 前言

轉載請標明來源：https://www.cnblogs.com/huim/
當專案功能逐漸成熟，同時需要實作的是運營流程和指標體系建設，需要工程化的功能逐漸少了，剩下的主要作業轉變成持續運營以及功能迭代優化，
個人認為，專案應該以運營為目的推動工程化，至少，安全和開發的需求五五開，分隔開，避免專案建設都投在了工程化上而忽略了產出、以及真正的確切需求，

有過一段時間，專注于各方面功能開發，但沒有著重在運營上，等季度末結算的時候，功能都已完成，但是漏洞產出卻要趕，有的功能雖然做了，但并不直接提升產出，
但也因此，大多數功能都已經趟過，產品功能也相對成熟，隨著人數的補充，重心從工程化開發轉移到運營，也不會因為過多不成熟的功能設計而造成阻攔，

掃描器涉及到運營的主要是規則和漏洞

0X02 規則運營工具類功能

提高運營效率

2.1 規則撰寫：規則SDK

各家產品規則格式不一致，但是開發規則的時候肯定不能拿著引擎做測驗，引擎太重了，
需要精簡引擎，抽取出能讓規則運行的核心代碼，如AWVS
http://www.acunetix.com/download/tools/WVSSDK.zip
又或者像xray 運算式類插件，有可視化的規則界面
https://phith0n.github.io/xray-poc-generation/
簡而言之，簡化規則撰寫的流程

2.2 規則測驗：測驗流程

規則的撰寫人員和漏洞的運營人員是分開的，
正式上線的規則產出的漏洞可以轉交給運營人員，這部分應該是誤報率極低、可人工運營的漏洞；
而測驗狀態的規則，比如新漏洞曝光、撰寫規則掃描全內網看看誤報率漏報率如何，這是是測驗狀態，漏洞不直接運營，
而測驗規則轉為正式規則，則需要清空測驗庫的漏洞結果、或者將測驗漏洞表的結果轉移到正式漏洞表，

2.3 規則迭代：歷史版本記錄與比對

新增一個規則，后續會不斷的隨著運營遇到的問題（業務用其他方式修復了但仍檢出的誤報、poc不全導致的漏報、漏洞結果體驗不夠友好等）而不斷優化規則，會在同一個規則上迭代不同版本，
不同版本的對比，應能逐行對比不同的部分，其實用gitlab等管理是挺好的，更新修改的部分展示明確、各方面的記錄都很齊全，免去很多不必要的開發量，

0X03 規則運營指標與規范

運營指標相關，在指標規范下，保證專案產出，專案本身已經有大指標了，落實到具體安全人員身上的是運營指標，

3.1 規則撰寫相關指標與規范

• 3.1.1 0day應急時間 <= n小時
  保證0day應急時間，0day應急其實是掃描器的一大重要功能，從攻擊者視角發現易受攻擊面的漏洞，高ROI的收斂風險，缺乏指標，可能0day出現后過一周兩周才有回應，已經過了應急的黃金時間，
  0day來源參考規則篇中的漏洞預警，每一個事件/漏洞計算處理時間、標記處理狀態，最后計算個人平均回應與處理時間，落實到個人指標上，
• 3.1.2 漏洞召回時間 <= n小時
  漏洞召回主要是對外部第三方提交的漏洞進行召回，如SRC/補天等，排查掃描流程與規則中的漏報原因，
  召回需要查看逐流程跟進流量走向，要么提供召回的標準，這點在實踐時對安全人員要求比較高，需要稍微熟悉掃描引擎的流程，才能根據檔案排查出原因；要么做自動化，自動查詢流量在每個步驟中的狀態，輸出沒有到規則這一步的原因，
  因白名單與規則原因漏報的指定運營人員處理；因bug問題導致缺流量、程序漏掉流量的指定開發人員排查，
  規定 n小時內回應排查出原因，n天內處理完畢可以掃描出該漏洞或者歸檔不可解決的漏報原因，
• 3.1.3 代碼規范
  對插件撰寫需要代碼規范，代碼風格詭異，沉淀下來的規則交接成本挺大，
  在代碼上傳處，可設定簡單的自動化代碼檢測功能，檢測到不符合規范的代碼，報錯拒收，

3.2 規則維護相關指標與規范

• 3.2.1 運行時長/請求量指標
  在性能篇中提過，計算規則每個任務的運行時長、http/socket的請求發送量，設定一個閾值，平均值超過則報出

主要針對有的規則比如nmap 掃描全埠指紋、sqlmap拉滿、socket沒有設定timeout會運行很長一段時間；有的弱口令設定檢測串列設定太過復雜(賬密使用頻率極低)，會有很多沒必要的請求，占用時間且可能對被掃描方造成壓力，

• 3.2.2 運行報錯指標
  規則報錯在n小時內處理，
  引擎端需要把報錯給出并通知(微信/內部通信軟體/短信等)，處理時間可以按照報錯首次和最后一次出現的時差計算，
  沒有明確指標情況下， 規則報錯但不處理的情況會有一些，影響產出，或者引擎性能，

0X04 漏洞運營工具類功能

4.1 漏洞去重

為什么有了流量去重，還要進行漏洞去重？
流量去重并不能替代漏洞去重，漏洞去重與漏洞狀態相關聯，
對于同一條流量或者同一個IP/埠資產，會進行不止一次的掃描，可能第一次掃描沒有漏洞，但之后這個介面因為某次上線多了一個注入，或者某個redis埠密碼改成了弱口令等，所以流量不能只掃描一次，url流量需要有去重快取視窗，資產漏洞掃描也需要有定時周期任務，
未修復狀態的漏洞(還沒確認/已確認未流轉到業務線/業務線收到但還沒修復)，重復時不產生新漏洞，只有已經修復了(漏洞又產生了)/已經忽略了(規則沒優化完全)才會產出重復漏洞，
漏洞重復的標準：
主機資產類漏洞， 去重根據 IP+埠+規則型別(規則型別可以是這個規則的唯一key、不管多少個迭代版本但唯一的key或token，也可以是這種漏洞的CWE型別)
url型別，去重根據 url去重歸一key+規則型別

4.2 漏洞自動確認

有部分規則產出的漏洞，誤報率極低，人工運營狀態下也不需要進行多少驗證操作，可以直接設定成漏洞自動確認狀態：漏洞產出后直接確認，
可以在規則串列頁里加一列滑動單選按鈕，
運營人員處理某類漏洞時，確定誤報率極低、人工驗證操作極少，點開就好了

4.3 漏洞自動發送

漏洞自動發送到業務線：需要注意兩個細節
1 漏洞對接到集群與處理人
有一套找集群的程式，url可以根據nginx找到最后轉發的集群，IP可以根據cmdb配置找到集群；再根據集群確定需要對接的漏洞處理人，
2 漏洞聚合發送
一個集群下可能存在多個機器，或者有一些重復流量對應到同一個介面，有時候漏洞往往是成復數出現，比如同一個redis集群下，每十分鐘掃描出一個redis弱口令，弱口令還都一樣，
面對這種情況，作為業務線其實并不希望漏洞一個一個發、訊息一個一個彈，
所以需要根據 集群+規則 作聚合，把這些漏洞都放到一個工單里，又因為一個集群的漏洞并不是一下子都出來，需要設定聚合時間視窗，比如每4小時/6小時/12小時/24小時聚合一次，時間長了漏洞利用時間可能延長，時間短了會有多個工單，視窗時長需自己衡量，

4.4 漏洞推修資訊

漏洞推送到業務線，需要讓業務知道漏洞有什么危害、可以怎么利用、怎么驗證，最重要是怎么修復，
poc的資訊有有一些是面對業務線的，有一些是給運營人員看的，比如側信道方式的漏洞，可能需要添加掃描子任務唯一標識uuid資訊，用于有問題需要詳細驗證的時候找找具體的流量，比如xss，可能需要添加xss的payload是針對那種html型別的編號，這種業務看不懂也不想看，而可利用的xss鏈接這種才是業務想直接看到的，
所以poc欄位可以設定兩種型別，一種會展示到業務可見的工單，一種業務不可見僅安全運營人員可見，
每一個規則都得有對應的漏洞型別，多對一的關系，每種漏洞型別，得有漏洞描述/漏洞利用場景/漏洞復現方式/漏洞修復方案，也就是需要一個漏洞文庫，用于與規則關聯，與工單關聯，沉淀團隊內的漏洞資訊，給業務線做漏洞展示，

4.5 漏洞自動復測

SRC的漏洞復測可能需要人工參與，而DAST的漏洞都可以做自動復測，業務提交復測需求后，由掃描器重放流量，測驗漏洞是否存在，不存在就直接關閉工單，
至此規則產出的漏洞可自動確認、自動發送工單、自動關閉工單，運營人員可專注于規則的撰寫，后續的流程都自動實作，

0X05 漏洞運營指標

漏洞需要流轉到業務線，并且修復，才能算作有用的產出

5.1 個人漏洞平均處理時長

有部分誤報率已經盡可能優化但還無法確保無誤報的規則，產出的漏洞需要人工驗證，所以需要計算分配到個人的漏洞從發現到處理的平均時間，設定個人指標 小于n小時，
大量堆積的待處理漏洞，超過半個月一個月，會有部分漏洞不存在了(比如機器關了、埠換了、介面下了)，發送給業務線就需要再確認一遍，而且沒發送給業務線的漏洞也就是單純自娛自樂用的，

5.2 個人漏洞處理率

漏洞發送到業務才計算處理時間，但不確認或者確認了不發工單不就好了， 所以需要處理率限制，以一個季度為準，季度結束時個人所分派的漏洞，需要100%確認/忽略，并且確認的漏洞需要通過工單的形式發送/流轉到業務，

0X06 系列終篇

至此自動化漏洞掃描器系列短暫結束了，陸陸續續寫了一個月，算了算大概一萬八千字，很早就想總結，終于寫完了，
從流量、規則，到引擎以及專案成熟穩定后的持續化運營，這3/4年涉及到的或多或少都有講述，算是對產品經驗的總結，
而完整做完一套產品，轉移到另一套產品，其實并沒有太大難度，有很多都是思考方式與設計方式都是相似的，比如流量+規則+引擎+結果運營的核心模式，
當然還有一部分沒有寫到，比如生態級互聯網企業中，把掃描器封裝成只提供服務的產品、給業務BP使用的相關功能(一般是SAAS模式)；把掃描器封裝成獨立部署的硬體產品相關功能，
不過核心思考都是這些方面，不變的是核心功能與流程，變化的是用戶互動界面功能，針對不同場景可以有不同的web控制平臺，對接到同一套引擎 (引擎兼容設計變化較大的可能是任務調度、無害處理這方面)，

標籤：訊息安全

上一篇：DAST 黑盒漏洞掃描器 第五篇：漏洞掃描引擎與服務能力

下一篇：物聯網5種無線傳輸協議特點大匯總