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

huim發表於2022-06-27

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

相關文章