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

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

SDL

與DevSecOps

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

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

適合DevSecOps

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

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

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

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

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

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