探索企業安全建設進階路徑

安全是個“無底洞”，沒有一個企業的安全負責人會說自己的系統是百分百安全的，安全也不是特別好衡量和量化，尤其是定量地評估出誰比誰做得好、好多少。有時候也會反思，或者說迷茫，“上了那麼多防護手段、到底能不能經得起對抗？”，“安全自研產品做了半年、用了半年、然後有一天它被廢棄掉了”，“SDL喊了好幾年了，怎麼就運營不下去呢？”，“業務主動過來尋求支撐，可是我們手裡沒有核武器。”......

本文將介紹宜信安全建設不同階段的思路和成果，每個階段遇到的挑戰、踩過的坑，以及收穫的心得和體會，分享宜信內部安全產品的發展，探索企業安全建設路徑。

一、背景

2013年，公司正式開始進行安全建設，投入資源成立專門的安全團隊、搭建基礎安全設施。宜信公司的安全建設自開始至今大致可分為三個階段：

2013年-2016年處於V1階段。V1階段主要實現了：基礎的安全環境（如防火牆、區域隔離、主機IDS、網路IDS、網路准入、防病毒等等）；在上市前後通過合規檢查工作逐步建立和完善了公司的資訊保安制度，通過了等保三級、ISO27001認證；在2016年建立了自己的安全應急響應中心。

2016-2018年處於V2階段。V2階段的主要成果是完善了安全技術，提高了安全工作覆蓋的範圍；參與了部分業務安全相關的工作（賬號安全、反爬蟲、簡訊介面攻擊、人機識別等）；確定了SDL的相關流程（沒有特意去實施，只是使用了其中一兩個方法）；開發了漏洞掃描、GitHub監控等一些安全工具。

當前處於V3階段，未來應該還會持續1-2年左右的時間。在這個階段，我們開始追求構建更加貼合企業長期發展、在某個點更專注更深入的安全能力，比如安全運營的能力、資料安全的能力。

二、幾年前的狀態

上圖是之前總結的行業裡資訊保安所處的狀態和發展情況，以及截止2016年我們在安全上完成的一些專案。那個階段在網路邊界、IT等方面的工作，打下了比較紮實的基礎，包括網路准入、終端DLP、防病毒等已經實施完成。在基礎安全尤其是終端安全效果尤為顯著，保證了內網、辦公網處於一個相對安全的環境，不用天天緊急應對木馬、勒索病毒、甚至APT這類安全事件，可以釋放更多的精力去做更有意義的事情。

三、SDL實踐

3.1 SDL流程

本階段我們重點參考、借鑑了唯品會安全團隊分享的SDL流程，挑選了適用我們現狀的幾個重點環節，包括培訓、安全編碼規範等，在公司進行推廣。重要的專案安全也會參與安全需求評審，與業務、產品、技術等團隊建立了很好的合作關係。

值得一提的是，在企業，與安全的合作可以分為兩種：一種屬於“免責甩鍋型”、一種屬於“合作共贏型”。兩種型別，遇到涉及安全的事情，表面上都會找到安全，但內在的動機卻是大相徑庭。第一種更多的是為了免責，事情我通報你了、問題我拋給你了，甚至為什麼要找安全、找安全解決什麼需求問題都不知道也不關心，剩下的都與我無關了，出了問題，安全來背鍋；第二種更多的是為了尋求安全的協作，我知道可能會有哪些安全風險、我有特別關注的業務上的安全需求，我需要和安全一起配合解決產品的安全問題，確保上線後系統、業務的安全性，兩個團隊相互促進和提升。

兩種型別在合作方式、日常互動、最終的安全效果上截然不同。造成這種局面可能有多種原因，包括：非安全人員的綜合能力和素質、安全培訓的有效性、安全團隊的專業性和影響力（安全是否真的幫別人解決過痛點、雙方是否一起扛過槍）。

3.2 SDL案例

上面兩張圖展示的是我們做得比較好的地方，稱之為SDL或DevSecOps都可以，是自動化嵌入到釋出過程的，重點解決了第三方元件的安全問題，既可以快速在釋出過的軟體製品裡檢索出包含的第三方元件，也可以定義規則直接在構建過程中對包含存在嚴重漏洞的元件直接阻斷。這部分工作可以完全實現自動化，支援Maven、Gradle、Docker等，並且不會影響持續交付的能力。統一的資產管理、程式碼庫、軟體倉庫、CICD平臺實施起來會更加便捷，維護成本也最低，當然這離不開DevOps團隊的能力支援。

3.3 SDL威脅建模

今年我們也嘗試了SDL威脅建模，設計了適合我們的建模規則，包括重點關注的資料安全需求、審計需求等。這部分工作目前還在小規模試點、探索階段，從流程到工具都還有很多要解決和優化的事情，等到實際成熟，我們再考慮投入更多的安全測試、安全服務人員在公司大範圍推廣。

3.4 SDL白盒掃描

在白盒程式碼審計方面，我們也投入了少量的資源進行嘗試，封裝了程式碼審計平臺，核心依賴於Sonarqube和Findbugs Security，也支援自己編寫規則，實現了觸發掃描、上傳原始碼掃描等方式，自動提交漏洞。但是這部分最大的消耗還是對規則的運營、對誤報的消除等，目前也沒有找到更優的解決辦法，聽到比較多的思路也是簡化規則，初期“寧可漏報，不要誤報”。目前主要的使用方式：安全人員臨時任務需要上傳原始碼進行掃描、對一些接入的專案每週掃描傳送檢測報告。

3.5 SDL被動掃描

SDL的另外一個嘗試是在被動掃描，基於流沙平臺收集的測試環境流量進行回放。大致的思路之前很多人都分享過，通過替換cookie、request-param重點用於測試發現未授權訪問、垂直越權、水平越權等安全問題。難點也是優化規則、整理收集公司業務的共性（比如錯誤頁提示等）。之前利用這個掃描發現過幾個高危的問題，投入產出比還是挺高的。但是想做到較高的掃描準確率、提高自動化程度、達到可持續運營的效果，要投入的人力就比較大了。具體看團隊的取捨吧，最近也看到一些國內外利用AI來提高安全測試效率、甚至替換人來進行手工安全測試的專案，不評判短期內是否能很好的落地，但是認同一句話“人是會疲勞的，但是機器卻不會”。

3.6 SDL漏洞管理

漏洞管理主要依賴於洞察平臺，包括應用資產系統的管理、漏洞生命週期的管理、安全知識庫的管理。洞察平臺在去年進行了開源，使用者比我們預期的要多，從社群微信群平時的交流諮詢來看，使用者多是1-5人的安全團隊，並且有網際網路、製造、物流等多個行業。每次有人加我們微信尋求洞察平臺部署配置以及功能使用上的幫助時，雖然佔用了我們一些工作的時間來解答或者解決問題（我們會檢討軟體質量問題），但還是很開心能夠真正幫助到安全同行。

這件事也讓我有些反思：

其一很多企業在安全上的投入有限，的確需要好的開源解決方案；

其二產品落地需要一些乙方的思維，產品有時候需要做減法，大而全未必是每個人都需要的，而且好用的前提是好部署好配置。

洞察insight開源地址：https://github.com/creditease-sec/insight

四、洞察2.0

今年我們將開源洞察的2.0版本。

第一會優化之前的互動、功能、業務邏輯等提高易用性；

第二完善漏洞運營的資料，加強報表功能來關注整體的安全狀況；

第三也是最大的更新，合併了SRC前、後臺的功能，讓企業可以自定義地來建立自己的安全應急響應中心，並且統一了各個來源的漏洞管理。

上圖展示的是原型圖，目前正在開發的過程中，有需要的安全同行們可以期待一下。

五、流沙平臺

另外一個最近一年聽到比較多的各甲方團隊在討論的就是SOC和SIEM，有商業化的安全大資料產品、也有類似Splunk這樣的平臺（Splunk Enterprise Security）、還有基於ELK的開源方案。我們選擇的是第三種，當前階段比較好地實現了資料的採集、儲存，以及一些不是非常複雜的計算。

資料來來自交換機的流量映象、日誌檔案、各安全裝置的syslog等。架構師設計實現了一套預處理程式，進行資料的接入配置、過濾、格式化、組裝、打標、脫敏等，核心程式碼部分用go來編寫，來提升處理效能。

上圖是整個“流沙”平臺的架構，以及硬體資源、資料量、寫入速度等；有了資料，在應用場景，目前實現了包括資產發現、弱口令檢測、資訊洩漏發現等等，基於簡單的規則就可以實現，不需要非常複雜的計算。

具體參考： 流沙：宜信安全資料平臺實踐

5.1 流沙應用：內控

基於流沙安全大資料平臺，如何滿足更復雜的安全分析、關聯分析場景，也是我們後續要重點開發的。

上圖是之前做的用於滿足內控的一個上層應用，同事也在QCon上分享過，實時收集公司內部業務系統的登入、查詢操作、辦公網員工的上網行為（自定義規則）、DNS、GitLab、WiKi、DLP告警等。

第一滿足審計業務運營系統的操作行為，比如誰在什麼時候訪問過哪些敏感資料，做記錄用於追溯；

第二進行分析，比如某個人的操作異於該崗位的其他人員，聚類定位高危人員，做重點關注。

上圖是我們整理的關於使用者資產的資訊。

六、自研的WAF產品

逐步替換商業化的WAF產品，

• 具備傳統WEB安全防禦能力  

• 具備CC攻擊防護能力  

• 具備爬蟲防護能力  

• 具備資訊洩露防護能力  

• 具備資料分析識別異常流量能力

6.1 宜人盾

重點說一下我們自研的WAF產品：宜人盾，前後大概花了一年半左右的時間，迭代了3個大版本，投入了8名安全團隊的人員負責系統設計、開發、防護規則收集，1名運維同事負責安裝包製作和部署工作，2名測試工程師協助進行壓力測試。

我們之前採用的是商業化WAF裝置，Gartner象限裡排第一的，這幾年採購了有10臺左右。產品本身很好，大家使用的比較熟練也比較穩定，但也存在一些不足：

• 第一，產品對傳統基於規則的惡意請求的防護強、但對爬蟲這種有時間視窗上下文的訪問防護比較弱、並且開啟這部分功能會損耗整體的硬體效能；
• 第二，需要以硬體的形式串入到網路中，遇到實施新的業務、新的網路區域時，就需要上架新的裝置，實施週期長；
• 第三，水平擴充套件的能力不是很強，單點遇到瓶頸時只能選擇擴容或者拆分流量，動靜很大。

綜上，我們還是選擇在有商業化產品的前提下，自研了宜人盾，符合SDS軟體定義安全的趨勢（感謝公司和領導的大力支援）。宜人盾基於OpenResty擴充套件，分為閘道器、大資料分析平臺、運營後臺管理端三大部分，所有配置通過Redis共享讀取。宜人盾具備WEB防護、CC防護、黑名單防護、語義識別防護、敏感資料防護、AI防護。產品設計和開發按照商業化產品標準：精選100多條基礎規則、可新增自定義規則、規則黑白名單等均分全域性與域名、並且每個域名的每項防護開關都可獨立開啟、報表分析和每個攔截事件的查詢均按域名區分，在產品易用性和互動上做了打磨。

平臺特點

• 軟體定義、水平擴充套件  
• 快速接入

當前進度及運營情況

• 持續迭代一年半左右  
• 目前已經全線接入宜人貸  
• 壓力測試峰值流量：5000qps（2C8G）

宜人盾目前已經全線接入了宜人貸，因為屬於閘道器產品，對效能和穩定性要求比較高，所以前期在2名測試同事的支援下做了很多的壓力測試。2C8G的虛擬機器上執行宜人盾，QPS在5000左右，可以滿足我們的要求。同時，我們對每項服務（MQ、Flink、計數服務、Redis、完整穿行等）都進行了監控，在運營後臺裡專門設定了檢視系統狀態的功能，可以看到每個宜人盾節點的域名接入狀態、以及節點是有錯誤告警。在每條防護事件的查詢上，我們也做了比較多的優化，確保在攔截比較多的情況下仍可以快速進行查詢。

利用機器學習識別高低頻爬蟲

• 序列化訪問的URL  
• 按時間形成訪問路線  
• 用圖提取出環的迴圈次數  
• 聚類找出異常的IP、SID

識別傳統規則不易發現的CC攻擊、爬蟲行為，也是宜人盾重點要實現的目標。除了UA、IP黑名單、基於IP\SID的單一介面訪問頻率的判斷，我們也加入了演算法來識別這類異常訪問。

舉例說一下我們使用的“路徑聚類模型”，這部分在宜人盾的資料分析平臺實現：定期提取上一時間段的訪問、序列化訪問的URL、形成訪問路徑、用圖提取出環（迴圈，單獨一個點也是環）次數、聚類找出異常的IP和SID。

比如上圖示記的，第一個IP訪問[2835]這個URL是86次，第二個IP則是訪問[2821，2832，2827]是14次，然後另一個迴圈36次。這裡說明一下，路徑是根據時間排序的，不根據Referer，圖計算用的類庫NetworkX，感興趣的可以瞭解下。上線後，我們發現過爬取財經文章的、還有刷簽到的重新整理手標的薅羊毛行為，達到了我們的預期。

七、目前在做的事

以上就是我們這兩年在做的一些事情，以及我自己的一些體會：

• 專案制有利於安全開發的迭代，明確了產出和目標效率能提高不少；
• 壞計劃好過沒有計劃，在計劃的過程中，比如頭腦風暴大家可以貢獻更多的創新、思路，計劃還要關注一下風險點，比如可以持續投入多久、會不會面臨專案被叫停的風險，核心的人員是不是穩定、選用的架構或者開發語言是不是團隊擅長的諸如此類，避免出現爛尾工程。
• 在安全產品層面，更多乙方的產品越來越貼合甲方的實際需求，落地效果也越來越好，細分的產品都能找到比較合適的解決方案，除了少數大廠，有些東西要不要自研得再三考慮，需要結合短期中期長期的各種變化，儘量貼合企業的長期發展需求。
• 在安全服務、攻防對抗、SDL等貼近傳統安全的方面，很多公司都還有很多可以實踐和優化的地方，近期也能看到大家對這方面的討論比較多，比如ATT&CK Matrix，比如滴滴持續對SDL的建設。

今年，我們也重點設定了幾個專案，除了上面說的洞察2.0，更多的是為了貢獻開源社群。內部還有2個比較重要的專案。

第一個專案，代號“超級掃描器”，用各種手段（包括內部工單、CMDB、搜尋引擎、CMS指紋等）來發現外部資產，實現GitLab、暗網、負面輿情的監控，以及提高安全測試效率、輔助SDL推廣的重任，複用了之前開發的分散式安全服務編排服務“須彌”以及爬蟲服務。“像黑客一樣發現資產、深入整合到SDL中”是專案建立的初衷。

第二個專案，代號“安全感知”，是對流沙、內控審計及辦公網安全系統的重新整合和擴充套件。資料安全越來越多地被單獨提起，成為安全的核心問題之一。《資料安全法》已經進入立法階段，不論從安全建設、合規、還是企業的戰略發展，很多走在行業前列的企業已經在向以“資料為中心的安全策略”轉變。所以這個專案的重點就是圍繞資料安全來開展的，在應用層關注資料的使用，打通安全可用的各種資訊，方便的配置關聯關係，每一類業務系統或場景設定自己的檢測模型，可以把它當作一個智慧審計的產品。當然，這個只是整個資料安全治理的一角，資料安全策略、資料安全委員會、資料分類分級、操作流程、獎懲制度、傳統資料庫脫敏、資料防洩漏、資料檔案擺渡、資料地圖、大資料安全等放在一起，才組成了資料安全的完整板塊，要做的事情很多、也很複雜。

作者：王哲

首發：宜信安全應急響應中心

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69918724/viewspace-2650362/，如需轉載，請註明出處，否則將追究法律責任。