通過SDL和SecDevOps實現(xiàn)軟件應(yīng)用的原生安全_第1頁
通過SDL和SecDevOps實現(xiàn)軟件應(yīng)用的原生安全_第2頁
通過SDL和SecDevOps實現(xiàn)軟件應(yīng)用的原生安全_第3頁
通過SDL和SecDevOps實現(xiàn)軟件應(yīng)用的原生安全_第4頁
通過SDL和SecDevOps實現(xiàn)軟件應(yīng)用的原生安全_第5頁
已閱讀5頁,還剩43頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、通過SDL和SecDevOps實現(xiàn)軟件應(yīng)用的原生安全技術(shù)創(chuàng)新,變革未來AgendaSDL是什么SDL的安全實踐SDL和DevOps的融合SDL是什么什么是安全開發(fā)周期?是什么!通過最佳實踐來提高軟件開發(fā)生命周期的過程,以提高軟件安全性試圖解決安全問題并減少不安全軟件的成本的嘗試。不是什么!SDL并非無所不能,徹底的治本!Microsoft安全歷史比爾蓋茨在2002 年初撰寫“可信賴 計算”備忘錄 memo early 2002全推送和FSR擴展 到其他產(chǎn)品高級領(lǐng)導(dǎo)團隊同 意對所有產(chǎn)品要 求SDL面臨重大風(fēng)險和/ 或處理敏感數(shù)據(jù)添加了SDL增強功 能“模糊測試”,代 碼分析,密碼設(shè) 計要求隱私,

2、禁止的危 險函數(shù)等Windows Vista是 第一個通過完整 SDL的操作系統(tǒng)更廣泛的宣傳,開發(fā)統(tǒng)一知識庫系統(tǒng)一合規(guī)系統(tǒng)的介 紹和開發(fā)安全性已完全集成 到 DevOps( DevSecOps)中更多的安全自動化 工具輕量化通過反饋,分析 和自動化來優(yōu)化 流程開始對外宣傳SDL為什么采納SDL網(wǎng)絡(luò)犯罪演變局域網(wǎng)第一臺PC病毒 動機:損害19861995互聯(lián)網(wǎng)時代 “大蠕蟲” 動機:損害19952003操作系統(tǒng),數(shù)據(jù)庫攻擊 間諜軟件,垃圾郵件 動機:財務(wù)2004+針對性攻擊 社會工程學(xué) 金融+政治2006+2007 Market prices:Credit Card Number$0.50 -

3、$20Full Identity$1 - $15Bank Account$10 - $1000 Cost of U.S. cybercrime: $100BSource: U.S. Government Accountability Office (GAO), FBI關(guān)鍵基礎(chǔ)設(shè)施攻擊 間諜網(wǎng)絡(luò)戰(zhàn)2009+Design1 XDevelopmentStatic AnalysisTestingSystem/AcceptanceTestingIntegration Testing15XDeploymentApplication In the FieldUp to 100X交付安全應(yīng)用程序必須成為一項強

4、制性要求在集成過程中修復(fù)缺陷的成本要比在設(shè) 計時檢測和消除缺陷的成本高15倍,而在發(fā) 布時則要高達100倍。6.5XSource: IDC and IBM Systems Sciences Institute被動安全的代價“如果在生產(chǎn)之前僅消除了50的軟件漏洞,那么成本將降低75”-Gartner“應(yīng)用程序級別的安全性”SDL的安全實踐實踐#1 - 提供培訓(xùn)安全是每個人的工作。開發(fā)人員、服務(wù)工程師以及計劃和產(chǎn)品經(jīng)理必 須了解安全基礎(chǔ)知識,并知道如何將安全性構(gòu)建到軟件和服務(wù)中,使 產(chǎn)品更安全,同時仍滿足業(yè)務(wù)需求并提供用戶價值。有效的培訓(xùn)將補充和重新實施安全策略、SDL 實踐、標(biāo)準和軟件安全 要求

5、,并遵循通過數(shù)據(jù)或新可用的技術(shù)能力獲得的見解。盡管安全是每個人的工作,但重要的是要記住,不是每個人都需要成 為安全專家,也不是努力成為熟練的滲透測試人員。但是,確保每個 人都了解攻擊者的觀點、目標(biāo)以及可能的藝術(shù)將有助于吸引每個人的 注意力,并提高集體知識標(biāo)準。實踐#2 - 定義安全要求需要考慮安全和隱私是開發(fā)高度安全的應(yīng)用程序和系統(tǒng)的一個基本方 面,無論使用何種開發(fā)方法,都必須不斷更新安全要求,以反映所需 變化功能和威脅環(huán)境的變化。顯然,定義安全要求的最佳時間是在初 始設(shè)計和規(guī)劃階段,因為這允許開發(fā)團隊以最小化中斷的方式集成安 全性。影響安全要求的因素包括(但不限于)法律和行業(yè)要求、內(nèi)部標(biāo)準和

6、 編碼實踐、對以前事件的審查以及已知的威脅。這些要求應(yīng)通過工作 跟蹤系統(tǒng)或通過從工程管道派生的遙測來跟蹤。跟蹤看板、積壓工作、團隊儀表板和自定義報告的工作將拖放沖刺 (sprint) 規(guī)劃和 靈活的工作項目跟蹤與全面的可 追溯性相結(jié)合,為您的所有想法(大大小?。┨峁┩昝赖募摇嵺`#3 - 定義指標(biāo)和合規(guī)性報告必須確定可接受的安全質(zhì)量最低級別,并讓工程團隊負責(zé)滿足這些標(biāo) 準。盡早定義這些可幫助團隊了解與安全問題相關(guān)的風(fēng)險,在開發(fā)過 程中識別和修復(fù)安全缺陷,并將標(biāo)準應(yīng)用于整個項目。設(shè)置有意義的 Bug 欄需要明確定義安全漏洞的嚴重性閾值(例如,使用嚴重或重 要嚴重級別發(fā)現(xiàn)的所有已知漏洞都必須在指定

7、的時間范圍內(nèi)進行修 復(fù)),并且在設(shè)置后永遠不會放松它。為了跟蹤關(guān)鍵性能指標(biāo) (KPI) 并確保安全任務(wù)的完成,組織(如 Azure DevOps)使用的錯誤跟蹤和/或工作跟蹤機制應(yīng)允許安全缺陷 和安全工作項明確標(biāo)記為安全,并標(biāo)有相應(yīng)的安全嚴重性。這允許準 確跟蹤和報告安全工作。向Azure DevOps/TFS添加bugbarSDL 安全bagbar(示例)創(chuàng)建安全流程時需要考慮的基本 標(biāo)準SDL 隱私錯bugbar(示例)創(chuàng)建隱私過程時需要考慮的基本 標(biāo)準添加或修改字段以跟蹤工作Azure DevOps 服務(wù)器 2019|TFS 2018 |TFS 2017 |TFS2015 |TFS 20

8、13練習(xí)#4 - 執(zhí)行威脅建模威脅建模應(yīng)在存在有意義的安全 風(fēng)險的環(huán)境中使用。威脅建???以在組件、應(yīng)用程序或系統(tǒng)級別 應(yīng)用。這種做法允許開發(fā)團隊考 慮、記錄和(重要)在其計劃的 運營環(huán)境中和結(jié)構(gòu)化方式討論設(shè) 計的安全影響。將結(jié)構(gòu)化方法應(yīng)用于威脅方案有 助于團隊更有效、更便宜地識別 安全漏洞,確定這些威脅的風(fēng) 險,然后進行安全功能選擇并建 立適當(dāng)?shù)木徑獯胧?。微軟威脅建模工具Microsoft 威脅建模工具通過可 視化系統(tǒng)組件、數(shù)據(jù)流和安全邊 界的標(biāo)準表示法,使所有開發(fā)人 員的威脅建模更加輕松。它還可 幫助威脅建模人員根據(jù)軟件設(shè)計 的結(jié)構(gòu)識別他們應(yīng)該考慮的威脅 類別。我們設(shè)計了該工具時考慮 到了

9、非安全專家,通過提供創(chuàng)建 和分析威脅模型的明確指導(dǎo),使 所有開發(fā)人員都更容易進行威脅 建模。實踐#5 - 建立設(shè)計要求SDL 通常被視為幫助工程師實現(xiàn)安全功能的保證活動,因為功能在 安全性方面經(jīng)過精心設(shè)計。為此,工程師通常依賴于安全功能,如加 密、身份驗證、日志記錄等。在許多情況下,安全功能的選擇或?qū)崿F(xiàn) 已證明非常復(fù)雜,以至于設(shè)計或?qū)崿F(xiàn)選擇可能會導(dǎo)致漏洞。因此,至 關(guān)重要的是,在一致地應(yīng)用這些保護時,必須始終如一地應(yīng)用這些保 護。實踐#6 - 定義和使用加密標(biāo)準隨著移動和云計算的興起,確保所有數(shù)據(jù)(包括安全敏感信息以及管 理和控制數(shù)據(jù))在傳輸或存儲時受到保護,防止意外泄露或更改至關(guān) 重要。加密

10、通常用于實現(xiàn)此目的。在使用加密的任何方面時做出錯誤 的選擇可能是災(zāi)難性的,最好制定明確的加密標(biāo)準,提供有關(guān)加密實 現(xiàn)的每個元素的詳細說明。這應(yīng)該留給專家。一個好的一般規(guī)則是只 使用行業(yè)審查的加密庫,并確保它們實現(xiàn)的方式允許在需要時輕松替 換它們。實踐#7 - 管理使用第三方組件的安全風(fēng)險如今,絕大多數(shù)軟件項目都是使用第三方組件(商業(yè)和開源)構(gòu)建 的。選擇要使用的第三方組件時,了解其中的安全漏洞可能對集成它 們的大型系統(tǒng)的安全性產(chǎn)生的影響非常重要。準確清點第三方組件, 并在發(fā)現(xiàn)新漏洞時制定響應(yīng)計劃,將大有作為,以減輕這種風(fēng)險,但 應(yīng)考慮進行額外的驗證,具體取決于組織的風(fēng)險偏好,使用的組件類 型以

11、及安全漏洞的潛在影響。開源的好處將開源軟件作為開發(fā)過程的一部分有很多好處,其中一些包括:增加上市時間。通過將現(xiàn)有組件連接在一起,而不是從零開始實現(xiàn)所 有組件,更快地創(chuàng)建軟件。質(zhì)量更高。所有軟件組件都可能包含缺陷,但專注于專用軟件組件通 常比讓許多工程師多次單獨解決相同問題更高質(zhì)量。社區(qū)。通過貢獻新功能、報告 Bug 或與所使用的開源項目進行交互, 您可以分擔(dān)代碼庫的成本和收益。正確管理此風(fēng)險必須采取的最低步驟。庫存開源了解正在使用哪些開源組件以及在哪里使用。執(zhí)行安全分析確保所有已識別的組件沒有安全漏洞。使開源保持最新使開源組件保持最新。調(diào)整安全響應(yīng)流程準備一種與您的整體安全響應(yīng)計劃保持一致的方

12、法。實踐#8 - 使用已批準的工具定義并發(fā)布已批準的工具及其關(guān)聯(lián)的安全檢查的列表,例如編譯器/ 鏈接器選項和警告。工程師應(yīng)努力使用最新版本的已批準工具(如編 譯器版本),并利用新的安全分析功能和保護;開發(fā)團隊只需要關(guān)注自己的開發(fā)任務(wù),而開發(fā)工具、編譯器等的選擇 讓專業(yè)的工具團隊來完成,工具團隊通過自己的研究會有更專業(yè)的指 導(dǎo)和選擇,然后提供給開發(fā)團隊;iPhong XCode Ghost蘋果手機病毒事件的教訓(xùn);SDL推薦的工具 代碼安全性用漏, 微軟威脅建模全問題的設(shè)計Roslyn分析器 分析),但也 Roslyn 分析的 微軟DevSkim中提供內(nèi)聯(lián)安本 微軟安全風(fēng)險安全風(fēng)險檢測 技術(shù)。 攻

13、擊表面分析態(tài)、運行時參夠識別憑據(jù)泄和建議。ps 時提供合,這些腳 全需求。peScript,使您能于Visual Studio等的插件憑據(jù)掃描程序(CredScan)*由 Microsoft 開發(fā)和維護的工具,用于 如源代碼和配置文件中的憑據(jù)泄漏。工具通過傳達其系統(tǒng)的安全設(shè)計、使用經(jīng)過驗證的方法分析潛在安以及建議和管理安全問題的緩解措施,創(chuàng)建和分析威脅模型的工具。BinSkim驗證工具,用于分析二進制文件,確保它們符合 SDL 要求*分析器用于在生成時分析代碼,如靜態(tài)代碼分析(如果啟用了代碼 C/C+的代碼分析*安裝 Visual Studio 團隊系統(tǒng)開發(fā)版或 Azure DevO可以在鍵入

14、時進行實時分析。如果啟用完整的解決方案分析,器還可以提供編輯器中未打開的代碼文件的設(shè)計時間分析。靜態(tài)分析器,可幫助檢測和更正代碼缺陷。*IDE 擴展和語言分析器的框架,在開發(fā)人員編寫代碼時在開發(fā)環(huán)境 為 Azure 提供安全 DevOps 工具包腳本、工具、擴展和自動化的集 全分析。工具、擴展和自動化支持開發(fā)操作團隊的端到端 Azure 訂閱和資源安檢測*微軟獨特的模糊測試服務(wù),用于查找軟件中的安全關(guān)鍵錯誤。可幫助客戶快速采用過去 15 年在 Microsoft 進行實戰(zhàn)測試的實踐和 TSLint + tslint-微軟-contrib其他 Microsoft 為流行的免費 TSLint Ty

15、linter 編寫了安全規(guī)則。器用于突出顯示 Windows、Linux 或 MacOS 操作系統(tǒng)上的系統(tǒng)狀 應(yīng)用程序檢查器跨平臺工具,通過分析源代碼識別有趣的特性和特征 數(shù)和可安全對象的變化的工具。更好地了解程序的功能。實踐#9 - 執(zhí)行靜態(tài)分析安全測試 (SAST)在編譯之前分析源代碼提供了一種高度可擴展的安全代碼審查方法, 有助于確保遵循安全編碼策略。SAST 通常集成到提交管道中,以便 每次構(gòu)建或打包軟件時識別漏洞。但是,某些產(chǎn)品集成到開發(fā)人員環(huán) 境中,以發(fā)現(xiàn)某些缺陷,例如存在不安全或其他被禁止的功能,并在 開發(fā)人員正在積極編碼時用更安全的替代方法替換這些缺陷。沒有一 種尺寸適合所有解

16、決方案,開發(fā)團隊?wèi)?yīng)決定執(zhí)行 SAST 的最佳頻率, 并可能部署多種策略,以平衡生產(chǎn)率和足夠的安全覆蓋范圍。VSTS安全工具市場實踐#10 - 執(zhí)行動態(tài)分析安全測試 (DAST)對完全編譯或打包的軟件執(zhí)行運行時驗證檢查功能,這些功能僅在集 成和運行所有組件時才明顯。這通常是使用一套預(yù)先構(gòu)建的攻擊工具 或工具實現(xiàn)的,這些工具專門監(jiān)視應(yīng)用程序行為以查找內(nèi)存損壞、用 戶特權(quán)問題和其他關(guān)鍵安全問題。與 SAST 類似,沒有一刀切的解決 方案,雖然某些工具(如 Web 應(yīng)用程序掃描工具)可以更容易地集 成到連續(xù)集成/連續(xù)交付管道中,但其他 DAST 測試(如模糊化)需要 不同的方法。實踐#11 - 執(zhí)行滲

17、透測試滲透測試是一種軟件系統(tǒng)的安全分析,由模擬黑客操作的熟練安全專 業(yè)人員執(zhí)行。滲透測試的目的是發(fā)現(xiàn)編碼錯誤、系統(tǒng)配置錯誤或其他 操作部署弱點導(dǎo)致的潛在漏洞,因此測試通常發(fā)現(xiàn)最廣泛的漏洞。滲 透測試通常與自動和手動代碼審查結(jié)合執(zhí)行,以提供比通??赡芨?的分析級別。使用白盒模糊功能進行自動滲透測試安全研究人員和黑客越來越多地使用模糊作為查找漏洞的主要技術(shù)之 一。黑客通常練習(xí)黑盒模糊 -生成數(shù)據(jù)的各種排列,而實際上不會將 其與分析數(shù)據(jù)的代碼相關(guān)聯(lián)。模糊是一種系統(tǒng)的方法來查找代碼中的錯誤,這些缺陷是安全錯誤最 嚴重的原因。模糊化能夠查找遠程代碼執(zhí)行(緩沖區(qū)溢出)、永久拒 絕服務(wù)(未處理的異常、讀取

18、 AV、線程掛起)和臨時拒絕服務(wù)(泄 漏、內(nèi)存峰值)。模糊不僅發(fā)現(xiàn)緩沖區(qū)邊界驗證的缺陷,還發(fā)現(xiàn)狀態(tài)機邏輯、錯誤處理 和清理代碼中的故障。攻擊表面分析器攻擊表面分析器的核心功能是在安裝軟件組件之前和之后分散操作系統(tǒng)的安全配置的能力。這 一點很重要,因為大多數(shù)安裝過程都需要提升權(quán)限,一旦授予,可能會導(dǎo)致意外的系統(tǒng)配置更 改。攻擊 Surface 分析器當(dāng)前報告對以下操作系統(tǒng)組件的更改:文件系統(tǒng)(提供靜態(tài)快照和實時監(jiān)視)用戶帳戶服務(wù)網(wǎng)絡(luò)端口證書注冊 表COM 對象(新!事件日志(新建!防火墻設(shè)置(新建!實踐#12 - 建立標(biāo)準事件響應(yīng)流程制定事件響應(yīng)計劃對于幫助解決隨時間而出現(xiàn)的新威脅至關(guān)重要。它

19、應(yīng)與組織的專用產(chǎn)品安全事件響應(yīng)團隊 (PSIRT) 協(xié)調(diào)創(chuàng)建。該計劃 應(yīng)包括在發(fā)生安全緊急情況時與誰聯(lián)系,并建立安全服務(wù)協(xié)議,包括 從組織內(nèi)其他組繼承的代碼和第三方代碼的計劃。在需要之前,應(yīng)測 試事件響應(yīng)計劃!SDL和DevOps的融合安全 DevOps使安全原則和實踐成為 DevOps 不可或缺的一部分,同時保持更高的效率和生產(chǎn)率從一開始,Microsoft SDL 就確定安全性需要成為每個人的工作,并在 SDL 中包括項目經(jīng)理、開 發(fā)人員和測試人員的做法,所有這些都旨在提高安全性。此外,它認識到一個大小并不適合所有 開發(fā)方法,因此描述了經(jīng)過驗證的靈活實踐和活動,這些實踐和活動使用經(jīng)典瀑布或

20、較新的敏捷 來提高軟件應(yīng)用程序在開發(fā)每個階段的安全性方法。但是,除了考慮生產(chǎn)環(huán)境外,SDL 還不包括 操作工程師的活動。DevOps 方法改變了這一點?,F(xiàn)在,開發(fā)和操作已緊密集成,以便快速、持續(xù)地向最終用戶交付 價值。DevOps 已取代孤立的開發(fā)和運營,以創(chuàng)建多學(xué)科團隊,與共享和高效的實踐、工具和 KPI 協(xié)同工作。要在這種快速移動的環(huán)境中提供高度安全的軟件和服務(wù),安全以相同的速度移動至關(guān) 重要。實現(xiàn)此目的的一個方法是在開發(fā) (SDL) 和操作 (OSA) 流程中構(gòu)建安全性。實踐#1 提供培訓(xùn)培訓(xùn)對成功至關(guān)重要。確保每個人都了解攻擊者的觀點、目標(biāo),以及 他們?nèi)绾卫镁幋a和配置錯誤或體系結(jié)構(gòu)弱

21、點,將有助于吸引每個人 的注意力,并提高集體知識標(biāo)準。實踐#2_定義需求建立考慮到安全性和合規(guī)性控制的最低安全基準。確保這些已烘焙到 DevOps 流程和管道中。至少,確?;€考慮到實際威脅,如 OWASP 前 10 名或SANS 前 25 名以及已知存在或可能由您選擇的技 術(shù)堆棧中的人為錯誤引起的行業(yè)或法規(guī)要求和問題。實踐#3 定義指標(biāo)和合規(guī)性報告通過定義推動行動和支持合規(guī)性目標(biāo)的特定指標(biāo),與工程師一起推動 您想要的行為。實踐#4 使用軟件組合分析 (SCA) 和治理選擇第三方組件(商業(yè)和開源)時,了解組件中的漏洞可能對系統(tǒng)整 體安全產(chǎn)生的影響非常重要。SCA 工具可幫助進行許可暴露,提供組

22、 件的準確清單,以及使用引用的組件報告任何漏洞。在使用高風(fēng)險的 第三方組件時,您也應(yīng)該更加有選擇性,并考慮在使用它們之前執(zhí)行 更徹底的評估。實踐#5_執(zhí)行威脅建模雖然威脅建模DevOps 中可能具有挑戰(zhàn)性,因為它感知到速度緩慢, 是任何安全開發(fā)過程的關(guān)鍵組成部分。在大多數(shù)情況下,將結(jié)構(gòu)化方 法應(yīng)用于威脅方案有助于團隊更有效、更便宜地識別安全漏洞,確定 這些威脅的風(fēng)險,然后進行安全功能選擇并建立適當(dāng)?shù)木徑獯胧?。?少,在存在有意義的安全風(fēng)險的環(huán)境中,應(yīng)使用威脅建模。實踐#6使用工具和自動化使用經(jīng)過精心挑選的工具和智能自動化,這些工具和智能自動化已集成到工程師的世界(如集成開 發(fā)環(huán)境)。在現(xiàn)代工程領(lǐng)域,很容易假設(shè)自動化是解決方案,自動化是關(guān)鍵,但在選擇工具時必須 有選擇性,并在部署工具時要小心。目標(biāo)是解決問題,而不是使工程師在日常工程經(jīng)驗之外使用太 多的工具或外星流程來超載。用作安全 DevOps 工作流一部分的工具應(yīng)遵循以下原則:工具

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論