1. 程式人生 > >有了漏洞掃描器,如何用好?一點不成熟的小總結

有了漏洞掃描器,如何用好?一點不成熟的小總結

準備 class 毅力 工具 創作 之前 域名 人力 昨天

有了漏洞掃描器,如何用好?一點不成熟的小總結

2017-02-09 18:09 程序設計

技術分享圖片

*本文原創作者:安惞,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載

昨天晚上做夢,夢見不知道在之前還是現在的哪家公司,跟同事老板談hc,說到,當前最大的問題是,人力問題,是人力不夠。只有人力解決了,這個team才能運轉下去。

我就問,那你們團隊是做啥的呢?他說做掃描器和漏洞運營。夢裏就開始回想在以前公司中,各種方法有效的效率提高和人力節省措施,我就回了一句,人力當然重要,不然事情做不起來,同時在有一定人力的情況下,方法更重要。

接著,就開始就掃描器的使用高談闊論了起來。

啥?掃描器不就一個工具麽?有幾個人不會用?

這裏就講一講在甲方互聯網公司,掃描器在具體實踐中的用法,個人淺見,歡迎交流分享……頭次發文,不知道會被噴到多慘……

一、掃描器哪裏來?

以前就職的兩家公司裏,黑盒掃描器都是自研,白盒掃描器只有其中一家有。直到有一次某M公司來做分享,才知道,原來他們的黑白盒掃描器都是靠購買的,乙方提供產品和售後支持。

當時納悶兒,如果是乙方提供,就不怕到時候也不知道代碼,添加規則的時候不能滿足需求嗎?

M公司的專家解釋,以前M也是自研掃描器,但是發現的問題是,掃描器的開發維護團隊的目標,很多時候和具體運營的安全團隊是不一致的,更新規則的效率效果也比較不好說;而乙方由於提供給多家服務,樣本也更多,產品更專業,提供的服務也更好一些。

回想起原來就職的兩家公司裏,除非掃描器的開發運維和安全工程師就在一個小團隊,否則這其中的多個環節也確實很難保證掃描器的快速叠代。

除了比較大的公司,如果是初創公司或者是快速增長期的公司,購買一款質量有保證,售後服務好的掃描器產品都是個不錯的選擇。當然如果能挖到專業的掃描器大牛過來,進行產品開發,不僅少走很多彎路,還便於內部產品對接,就更好了。

二、掃描器誰來用?

剛入行的時候,發現掃描器定期通過全流量,域名或ip,進行掃描,然後推送到SOC上,安全工程師來進行報警運維,以及後續漏洞的分發。這是對掃描器最早的用戶的認識。

隨著時間的增長,遇到了一群群特別牛叉的小夥伴兒,見識了,除了常規安全工程師運維,還可以將安全工程師以外的員工動員起來,畢竟,安全不僅僅是一個安全團隊的事情,而是一個公司,甚至還有公司外部人員一起來構建的生態。

三、掃描器怎麽用? 1. 常規黑盒掃描

收集和維護公司流量,ip和域名信息,對這些資產進行定期全量和增量掃描。

全量掃描,重點在於,要收集和維護公司的資產,並對資產進行有效的去重策略。周期要比增量掃描的周期長一些,這裏的重點在於全,而不是快。去重也需要一套完整的策略,不過此處不作過多展開。

增量掃描,對比原有資產庫,一旦發現有新增資產,立即進行掃描,這裏的重點在於要快。因為如果在歷史漏洞能夠有效修復的情況下,新增資產出現新漏洞或高危漏洞的可能性更大,需要盡快發現並處理。

2. 黑盒插件掃描

據Net Market Share 的7月份數據,占據全球瀏覽器排行榜首位的是Chrome瀏覽器,總市場份額為48.65%。實際工作中,也確實不少的程序員喜歡用Chrome瀏覽器。甚至於,不少瀏覽器直接使用的是Chrome的內核。

在這個前提下,開發Chrome瀏覽器掃描插件成為了可能。

由於黑盒掃描基於URL即可掃描發現漏洞的特性,只要通過Chrome或其內核瀏覽器瀏覽過的URL,都可以通過插件進行收集抓取,並進一步進行黑盒掃描。

只要安全工程師將插件開發成功,並推廣到公司的開發和測試安裝使用,那麽開發和測試在線下環境中就可以自行檢測出漏洞,只要安全工程師準備好相應漏洞的修復方案,開發即可自行修復上線。

無需等待產品上線,將安全風險暴露到外面後,外部或安全工程師再倒推給開發修復。不僅是降低了安全風險,也節省了安全工程師的工作成本。

3. 黑盒自助掃描

仍基於拿到URL即可掃描或爬取漏洞的特性,可以將掃描器後臺功能,開發成前臺產品,供對漏洞了解並未達到專業程度的開發或測試使用。

產品形態可以就是簡單的輸入框,用戶輸入URL,點擊掃描,即可對該URL進行黑盒漏洞掃描。

對於更深度的用戶,也研發定期,批量,爬蟲或接口掃描等功能……可以做的事情就很豐富了。

4.服務器掃描

這個原理是,抓取開發或測試的服務器上的日誌,推到掃描器,進行定期自動化掃描。好處是一旦配置了,就能準確的收集到最新變動的代碼的日誌,並且中途無須人工進行更多的操作,只需等待結果即可。

需要註意的是,要盡量開發封裝的agent,而不僅僅是接口,因為封裝的agent在開發或者測試接入的時候成本更低,推廣起來也更容易。如果公司內webserver類型不統一,那麽可能需要開發Apache,Ngnix,lighttpd等多個適用版本來進行接入。

5. 白盒代碼掃描

白盒的代碼掃描,理論上也可以運用方法3中,輸入代碼路徑的方式進行自主掃描。還有一種方案就是,將白盒代碼掃描,封裝成一個腳本或者包,推廣給開發,在開發常規開發的時候,跑一遍腳本或者包,顯示哪裏的代碼可能會產生安全漏洞。

這個方案的難點有兩點。

一是,如果公司開發使用的是多種語言,那麽包的適配和開發上可能就需要花比較多的心思。

二是,白盒掃描本身產生的誤報,想做好控制也比較難,這就要在漏報和誤報間做好權衡,至少選擇添加誤報達到某一基準線的規則,並做好引導說明,否則容易敗RP。

6. 上線平臺掃描

如果是比較專業的公司,代碼上線,一般都會有上線的平臺或者系統做支撐。

如果在上線前接入黑盒白盒掃描,並對漏洞進行修復,更是事半功倍。

需要註意的幾個事情是:

第一,要和上線的平臺打通,取得相應平臺,以及平臺的用戶的支持,這部分建議還是先走試點然後逐步推開。

第二,接入黑白盒掃描,不要等到最終上線那一刻再去掃描,而是盡量將掃描的步驟提前,進行預掃描,加快速度,提高用戶體驗。

第三,對於掃描的結果,哪些可以不修復就上線,哪些必須修復後上線,必須制定相應的策略,明確不修復上線的風險確認方式。

第四,對於掃描器掃描規則的維護,需要在安全自己的系統中,而不是上線的平臺。這樣添加規則,設置白名單,能夠不受上線平臺的影響,自己掌握主動權。

最後,任何一種掃描器都不能解決所有的問題,有必要的情況下,對於重點業務可以通過設定策略,添加人工測試。

四、掃描器怎麽維護?

衡量掃描器好壞最簡單的就是漏報和誤報率,如何盡量降低漏報和誤報,是掃描器安全上的最主要目標。當然,穩定性,效率,速度不可忽視,不過此處不做詳細說明。

1.漏報

漏報是難免的,重要的是每次發現漏報後能夠更好的處理和解決,並且和誤報做好平衡取舍。漏洞一旦通過各種非掃描器的渠道上報後,要有專門的人對該漏洞進行分析和規則添加。

這其中,疑似漏報的漏洞的通知規則和方式,根據漏洞類型進行初步的過濾和篩選,以及後續的規則添加都可以進行策略制定,這些都可以提高工作的效率。

此外,對於基礎資產,包括但不限於流量,域名,ip,代碼路徑相關信息,進行收集和維護,也是減少漏報的重要途徑。不過,大公司資產分布較多,初創公司基礎建設又有可能不完整,收集資產都是個不易的任務。

根據過往有限的經驗,如果安全團隊有人力的話,最有質量的方案,是將資產梳理和資產數據,通過各種方式,匯總到自己的平臺上,自己進行維護。

如果依賴其他平臺運維,後續無論是工作對接上,還是保證數據準確性上,都會有無窮無盡的麻煩。梳理資產確實是個比較需要耐心,恒心,毅力和溝通能力的工作。

2.誤報

這裏涉及到的是添加規則。如果是自研掃描器,非常非常建議,添加規則是通過動態配置,而非更新代碼。因為規則本身就是不斷變化的,如果每次規則變化都依賴開發,後續的麻煩,你懂的。

最後,安全不是一個團隊的事情,而是聯合公司內外各種力量建立起來的生態。

任何一種掃描器也無法掃描出全部的漏洞。

向奮鬥在第一線的安全從業人員致敬

有了漏洞掃描器,如何用好?一點不成熟的小總結