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控制平臺，對接到同一套引擎 (引擎相容設計變化較大的可能是任務排程、無害處理這方面)。