企業安全建設進階

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

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

1、背景

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

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

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

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

2、幾年前的狀態

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

3、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...

4、洞察2.0

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

第一會優化以前的交互、功能、業務邏輯等提升易用性；

第二完善漏洞運營的數據，增強報表功能來關注總體的安全情況；

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

上圖展現的是原型圖，目前正在開發的過程當中，有須要的安全同行們能夠期待一下。

5、流沙平臺

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

數據來來自交換機的流量鏡像、日誌文件、各安全設備的syslog等。架構師設計實現了一套預處理程序，進行數據的接入配置、過濾、格式化、組裝、打標、脫敏等，核心代碼部分用go來編寫，來提高處理性能。

上圖是整個「流沙」平臺的架構，以及硬件資源、數據量、寫入速度等；有了數據，在應用場景，目前實現了包括資產發現、弱口令檢測、信息泄漏發現等等，基於簡單的規則就能夠實現，不須要很是複雜的計算。

具體參考：流沙：宜信安全數據平臺實踐

5.1 流沙應用：內控

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

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

第一知足審計業務運營系統的操做行爲，好比誰在何時訪問過哪些敏感數據，作記錄用於追溯；

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

上圖是咱們整理的關於用戶資產的信息。

6、自研的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黑名單、基於IPSID的單一接口訪問頻率的判斷，咱們也加入了算法來識別這類異常訪問。

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

好比上圖標記的，第一個IP訪問[2835]這個URL是86次，第二個IP則是訪問[2821，2832，2827]是14次，而後另外一個循環36次。這裏說明一下，路徑是根據時間排序的，不根據Referer，圖計算用的類庫NetworkX，感興趣的能夠了解下。上線後，咱們發現過爬取財經文章的、還有刷簽到的刷新手標的薅羊毛行爲，達到了咱們的預期。

7、目前在作的事

以上就是咱們這兩年在作的一些事情，以及我本身的一些體會：

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

今年，咱們也重點設置了幾個項目，除了上面說的洞察2.0，更多的是爲了貢獻開源社區。內部還有2個比較重要的項目。

第一個項目，代號「超級掃描器」，用各類手段（包括內部工單、CMDB、搜索引擎、CMS指紋等）來發現外部資產，實現GitLab、暗網、負面輿情的監控，以及提升安全測試效率、輔助SDL推廣的重任，複用了以前開發的分佈式安全服務編排服務「須彌」以及爬蟲服務。「像黑客同樣發現資產、深刻集成到SDL中」是項目創建的初衷。

第二個項目，代號「安全感知」，是對流沙、內控審計及辦公網安全系統的從新整合和擴展。數據安全愈來愈多地被單獨提起，成爲安全的核心問題之一。《數據安全法》已經進入立法階段，不論從安全建設、合規、仍是企業的戰略發展，不少走在行業前列的企業已經在向以「數據爲中心的安全策略」轉變。因此這個項目的重點就是圍繞數據安全來開展的，在應用層關注數據的使用，打通安全可用的各類信息，方便的配置關聯關係，每一類業務系統或場景設置本身的檢測模型，能夠把它看成一個智能審計的產品。固然，這個只是整個數據安全治理的一角，數據安全策略、數據安全委員會、數據分類分級、操做流程、獎懲制度、傳統數據庫脫敏、數據防泄漏、數據文件擺渡、數據地圖、大數據安全等放在一塊兒，才組成了數據安全的完整板塊，要作的事情不少、也很複雜。

做者：王哲

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