懸鏡 DevSecOps 智適應(yīng)威脅管理解決方案

0引言現(xiàn)在越來越多的企業(yè)重視開發(fā)安全工作，也開始建立了相應(yīng)的SDL（安全開發(fā)生命周期）流程及體系，但應(yīng)用系統(tǒng)上線后安全漏洞卻依然頻繁出現(xiàn)。經(jīng)過大量的SDL服務(wù)項目實踐和深入思考分析，將原因歸納為以下幾點:企業(yè)缺乏合理的開發(fā)安全質(zhì)量考核,企業(yè)員工安全能力和安全經(jīng)驗不足,流程表單工具缺乏或不夠完善,企業(yè)未能形成SDL管理流程的閉環(huán),敏捷開發(fā)模式下SDL體系難以應(yīng)用。為解決傳統(tǒng)SDL解決方案的痛點，懸鏡DevSecOps智適應(yīng)威脅管理解決方案應(yīng)運而生。1DevSecOps簡介1.1

SDL

與DevSecOps

的異同在理念上SDL與DevSecOps相同，都是將安全前置，覆蓋到軟件開發(fā)的各個階段[1]。但SDL與DevSecOps所覆蓋的階段不同，存在重合點，SDL更加前置從需求開始，DevSecOps則延伸到運維部分，流程如圖1所示。在落地實踐方面，兩者差別更大：SDL依靠人工+安全產(chǎn)品配合，甚至可以完全丟棄安全產(chǎn)品；而DevSecOps更依賴安全工具，要求安全產(chǎn)品能夠集成CI/CD平臺，集成DevOps工具鏈中的開發(fā)運維工具，符合DevSecOps一體化的概念。1.2DevOps

與DevSecOps如果說DevOps促進的是開發(fā)和運營流程的自動化與協(xié)作，那么DevSecOps則解決的是安全與開發(fā)團隊之間的歷史遺留問題，使開發(fā)、安全與運營不再相互分割獨立[3]。DevSecOps整個流程中所有工作人員都對軟件的安全負責，目標是在不以犧牲安全性為代價的情況下，用最快的速度和規(guī)模將安全策略分配至每個流程中的關(guān)鍵人員加以執(zhí)行。圖1DevSecOps流程（圖源：Gartner）1.3

適合DevSecOps

的安全產(chǎn)品傳統(tǒng)的安全產(chǎn)品在DevSecOps中往往水土不服，那么適合DevSecOps的產(chǎn)品必須滿足哪些特性呢？我們給出以下建議：（1）便于與CI/CD工具鏈集成（2）專業(yè)程度低（3）盡可能減少誤報（4）安全檢測時間盡可能短（5）安全檢測透明化（6）

漏洞信息可集成到開放測試人員常用平臺（7）

盡可能提供自動化完成安全檢查和結(jié)果展示接口（8）

安全產(chǎn)品可開放所有功能API2方案概況結(jié)合多年的開發(fā)安全實踐經(jīng)驗，懸鏡安全探索出了一套基于原創(chuàng)專利級“工具+平臺+服務(wù)”的懸鏡DevSecOps智適應(yīng)威脅管理解決方案，如圖2所示，它從構(gòu)筑之初就注重技術(shù)落地的柔和低侵入性，從驅(qū)動DevSecOpsCI/CD管道持續(xù)運轉(zhuǎn)的幾大關(guān)鍵實踐點入手，通過對威脅建模、風險發(fā)現(xiàn)、威脅模擬及檢測響應(yīng)等關(guān)鍵技術(shù)創(chuàng)新賦能政企組織現(xiàn)有人員，幫助企事業(yè)單位建立起更加高效完善的安全開發(fā)和安全運營體系，并根據(jù)各流程頻現(xiàn)的漏洞類型、研發(fā)人員知識盲區(qū)等再次提供針對性培訓(xùn)，最終針對性制定規(guī)章制度，實現(xiàn)制度精準逆推落地。圖2懸鏡DevSecOps智適應(yīng)威脅管理體系3創(chuàng)新設(shè)計3.1風險管理閉環(huán)為了實現(xiàn)規(guī)模化、體系化、自動化地解決安全問題的目標，懸鏡DevSecOps智適應(yīng)威脅管理解決方案創(chuàng)新地基于獨創(chuàng)的風險管理閉環(huán)設(shè)計理念，風險管理閉環(huán)包含的活動如圖3所示。圖3風險管理閉環(huán)3.2定義安全策略定義的安全策略充當安全團隊和研發(fā)團隊之間的協(xié)議，雙方都應(yīng)完全明確在安全方面對他們的期望。此策略還可作為指導(dǎo)，指導(dǎo)應(yīng)用程序安全測試的結(jié)果首先修復(fù)哪些漏洞。定義安全策略與DevSecOps緊密相關(guān)，這些策略對于衡量DevSecOps的總體成功度至關(guān)重要。3.3自動化和集成企業(yè)組織在這里將安全測試解決方案集成到構(gòu)建和開發(fā)環(huán)境中，以確保安全測試過程完全自動化。沒有自動化，企業(yè)就無法實現(xiàn)高效率。每個企業(yè)組織都可以選擇希望實現(xiàn)自動化的程度，因為安全保障應(yīng)該結(jié)合實際的使用場景和企業(yè)本身資源儲備，通過個性化的方式和形式來實現(xiàn)。但最終企業(yè)組織需要確保以某種固定的流程來檢測應(yīng)用程序。最好的方法是在構(gòu)建環(huán)境和開發(fā)環(huán)境中自動執(zhí)行掃描。3.4識別漏洞一旦完成了前面描述的自動化和集成安全測試的活動，下個步驟就是執(zhí)行具體的應(yīng)用安全測試。我們可以用自動化的方式使用IAST、SCA和PTE，這些測試方法能夠檢測軟件應(yīng)用程序中的各種漏洞。關(guān)鍵是在不減慢軟件應(yīng)用程序的開發(fā)、交付和部署的前提下，盡早發(fā)現(xiàn)可能導(dǎo)致漏洞的編碼錯誤，確保有效地保障應(yīng)用開發(fā)的敏捷性。3.5關(guān)聯(lián)結(jié)果相關(guān)性背后的思想是提高應(yīng)用安全測試在發(fā)現(xiàn)高危漏洞方面的可信度和優(yōu)先級，尤其是能夠?qū)碜圆煌踩珳y試的相同發(fā)現(xiàn)關(guān)聯(lián)起來時。例如，如果DAST在黑盒測試期間發(fā)現(xiàn)了一個SQL注入漏洞，并且IAST在交互式測試期間確認了相同的發(fā)現(xiàn)，那么如果您能夠?qū)⑦@兩個發(fā)現(xiàn)關(guān)聯(lián)起來，可信度會更高。當組織有多個應(yīng)用程序，并且他們的應(yīng)用安全測試檢測到數(shù)千個潛在的漏洞時，如果組織能夠?qū)?shù)據(jù)進行關(guān)聯(lián)，就能更好地確定修復(fù)工作的優(yōu)先級，將有限的漏洞修復(fù)精力投入在最嚴重、影響最廣泛的漏洞上。3.6修復(fù)漏洞沒有開發(fā)人員能夠處理成千上萬個所發(fā)現(xiàn)的漏洞。需要確保以一種開發(fā)人員能夠消化它們的方式對所有這些漏洞進行優(yōu)先排序。開發(fā)人員需要能夠?qū)Ｗ⒂谧钪匾膬?nèi)容，并首先致力于修復(fù)風險最大的漏洞。如果開發(fā)人員收到關(guān)于如何修復(fù)某個漏洞的修復(fù)建議，并獲取到具體的修復(fù)位置，則可以使他們能夠快速高效地修復(fù)漏洞并讓修復(fù)數(shù)量最大化?；诘谝徊剑ǘx安全策略）中規(guī)定的策略，團隊知道需要修復(fù)什么，下一個問題就是如何修復(fù)。對此，安全培訓(xùn)可以提供很大的幫助。安全培訓(xùn)可以將安全能力從工具固化到人本身的認知上。3.7管理和監(jiān)控管理和監(jiān)控是組織跟蹤其應(yīng)用程序安全計劃的關(guān)鍵性能指標（KPI）的地方。這使組織能夠看到，隨著時間的推移，漏洞的數(shù)量是否在減少，引入新漏洞的比率是否在降低，嚴重漏洞的比率是否也在降低。組織使用各種各樣的KPI來查看其安全計劃是否有效。盡可能自動化地進行KPI監(jiān)控、跟蹤和報告有助于企業(yè)的安全團隊和研發(fā)團隊更好地獲得全局信息。4自動化工具圖4各階段安全工具應(yīng)用4.1需求和架構(gòu)階段各階段安全工具應(yīng)用如圖4所示。本階段進行威脅建模（TM），通過威脅建模針對性提出安全方案，用于后續(xù)研發(fā)等環(huán)節(jié)的解決或規(guī)避。對開發(fā)人員進行安全編碼培訓(xùn)，懸鏡提供從框架流程到編碼細節(jié)的應(yīng)用系統(tǒng)開發(fā)各個階段的安全開發(fā)全流程落地安全培訓(xùn)服務(wù)，幫助應(yīng)用系統(tǒng)開發(fā)流程中的各個角色人員具備安全開發(fā)全流程中的安全意識，了解DevSecOps的實施方法，使得相關(guān)人員掌握DevSecOps流程理念和DevSecOps落地能力，幫助DevSecOps體系在企業(yè)研發(fā)流程中的順利落地。4.2軟件編碼階段進行靜態(tài)應(yīng)用安全測試（SAST），開源組件檢測（OSS），軟件成分分析（SCA）。通過階梯式檢測方案，在研發(fā)不同階段介入最為合適的檢測方式和最優(yōu)檢測規(guī)則，確保在每個流程上都只檢出真實漏洞。所有需要確認的漏洞，交由IAST過程使用真實漏洞攻擊代碼進行檢測，確保更為有效的真實漏洞檢出概率并降低誤報導(dǎo)致的人工分析成本和落地阻力。4.3軟件測試階段交互式安全測試（IAST），IAST通過獲取功能測試人員測試交互流量，并以此取代DAST的自行構(gòu)造模式?；谀：郎y試（fuzz）思想對流量進行攻擊代碼隨機插入和攻擊流量構(gòu)建，自動化對被測程序進行安全測試，并在測試過程中借助插樁監(jiān)控平臺對被測程序的運行軌跡進行實時跟蹤和介入。一旦攻擊流量觸發(fā)安全問題，插樁平臺不僅可以第一時間捕獲安全問題，還能夠精確定位到漏洞所在的代碼文件、行數(shù)、函數(shù)及參數(shù)。通過這種方式，交互式應(yīng)用安全測試既能保證檢出漏洞的有效性，有效降低誤報，還能夠精準定位漏洞，幫助研發(fā)人員更好進行漏洞修復(fù)和回歸，有效提升測試過程安全檢測能力。通過IAST的新型測試模式，其還可以覆蓋更多傳統(tǒng)DAST無法觸及的安全范疇，包括邏輯類漏洞檢測自動化、雙向加密數(shù)據(jù)獲取等，實現(xiàn)更為良好的安全檢測能力。4.4上線迭代階段進行動態(tài)應(yīng)用安全測試（DAST），自動化滲透測試（Automated-PT）,運行時應(yīng)用自保護（RASP），終端檢測與響應(yīng)（EDR）。常態(tài)化安全運營、風險管理（RM）貫穿所有階段，對項目上線后所在的服務(wù)器資產(chǎn)、中間件以及項目本身進行7*24小時周期性安全檢查，相當于有一個安全團隊或滲透測試工程師全天候管理線上資產(chǎn)、站點以及中間依賴的安全問題，有效確保安全健康性。4.5平臺部分懸鏡DevSecOps智適應(yīng)威脅管理解決方案可通過統(tǒng)一平臺，將上述各流程的介入工具檢測結(jié)果進行統(tǒng)一展示和操作，方便用戶閉環(huán)安全問題、發(fā)現(xiàn)高頻安全盲區(qū)以及進行安全量化統(tǒng)計等。夫子（Xfuse）

作為懸鏡DevSecOps智適應(yīng)威脅管理體系的全流程管理平臺，不僅聚焦開發(fā)早期需求分析、架構(gòu)設(shè)計階段的威脅建模，還重點解決當下軟件應(yīng)用漏洞管理中普遍存在的漏洞發(fā)現(xiàn)能力孤立、漏洞管理難閉環(huán)、開發(fā)流程難管控等核心痛點問題。它的核心定位就是從開發(fā)源頭開始將專家團隊的安全能力持續(xù)賦能給傳統(tǒng)IT項目人員，使安全思想注入DevSecOps全生命周期，幫助企業(yè)組織流程化、自動化、持續(xù)化地保障業(yè)務(wù)安全。5保障服務(wù)5.1普及性賦能DevSecOps建設(shè)前期為各研發(fā)環(huán)節(jié)人員進行普及性安全知識賦能，培養(yǎng)各環(huán)節(jié)技術(shù)人員相關(guān)安全意識，并使其了解其安全職責，為后續(xù)向其提供工具落地其賦能知識提供理念基礎(chǔ)。5.2

針對性賦能DevSecOps建設(shè)后期根據(jù)SAST、IAST等環(huán)節(jié)經(jīng)常出現(xiàn)的漏洞類型、研發(fā)人員知識盲區(qū)進行針對性賦能培訓(xùn)，最終還可根據(jù)上述數(shù)據(jù)針對性制定規(guī)章制度，實現(xiàn)制度的針對性逆推落地。5.3常態(tài)化安全咨詢在DevSecOps建設(shè)各環(huán)節(jié)，懸鏡DevSecOps智適應(yīng)威脅管理解決方案均向客戶提供保姆式常態(tài)化安全咨詢，有效協(xié)助分析和解決DevSecOps落地難點，并實現(xiàn)對不同行業(yè)線的安全痛點的針對性建議和定制化DevSecOps建設(shè)方案規(guī)劃。5.4安全駐場服務(wù)懸鏡DevSecOps智適應(yīng)威脅管理解決方案可提供陪伴式安全駐場，通過派遣專業(yè)安全人員進駐客戶一線研發(fā)團隊，幫助客戶解決研發(fā)安全落地過程中的技術(shù)、流程困境，協(xié)助解決研發(fā)安全落地痛點，并提供有效行為措施和數(shù)字材料。6落到案例某國有銀行建設(shè)前采用傳統(tǒng)SDL研發(fā)模式，安全工作獨立于研發(fā)體系，無法融合于研發(fā)過程，導(dǎo)致效果差、效率低下，如圖5所示。質(zhì)量反饋體系不包含安全內(nèi)容，安全質(zhì)量無法持續(xù)改進。建設(shè)后采用懸鏡DevSecOps智適應(yīng)威脅管理解決方案，安全工作與DevOps流程無縫結(jié)合，深度整合在研發(fā)過程的每一個環(huán)節(jié)當中，侵入感低、效果好、效率高，如圖6所示。安全漏洞與BUG一同成為質(zhì)量反饋常規(guī)內(nèi)容的一部分，安全質(zhì)量持續(xù)改進。圖5某國有銀行傳統(tǒng)SDL