1、寫在前面
? 1.1? 什么是威脅建模？
? 1.2 威脅建模的價值
- 識別體系化的結構缺陷：大多數安全問題是設計缺陷問題，而不是安全性錯誤。威脅建模能幫助識別這些設計缺陷，從而減少風險敞口，指導安全測試，并降低因安全漏洞而造成的品牌損害或財務損失的可能性。
- 節約組織安全成本：通過對威脅進行建模，并在設計階段建立安全性需求，降低安全設計缺陷導致的修復成本。在需求管理和威脅分析階段與業務開發團隊高效互動，釋放安全團隊的專業能力，專注于高性價比的安全建設。
- 落地DevSecOps文化：通過威脅建模跑通開發和安全工具的流程集成，把風險管理嵌入產品的完整生命周期，從而推動形成完整的DevSecOps工具鏈。
- 滿足合規要求：威脅建模是國際安全行業通用的方法論，通過向管理層和監管機構提供產品的風險管理活動的完整記錄，幫助團隊遵守全球法律法規要求如PCI DSS、GDPR、HIPAA、CSA STAR等。
??1.3 遇到的挑戰
- 缺乏優秀的自動化建模工具；
- 安全團隊沒有時間和精力對每個應用都實施建模；
- 缺乏對威脅建模足夠的了解，知識庫涉及不同領域、專家經驗難以共享；
- 建模活動、輸出結果沒有融入業務的敏捷研發流程；
- 簡易的建模活動基于問卷或者表格記錄分析，并沒有實際的更新、積累和進一步分析。
2、準備威脅建模
? 2.1? 能力要求
- 懂常用的安全技術，安全機制，攻擊方法，危害，加密算法；
- 懂業務，流程，內部技術服務，產品與產品之間，組件和組件之間的關系；
- 組織人員策略資源來推動項目實施；
- 將安全規劃，安全流程、治理模型組合來符合縱深防御原則。
威脅評審，重點是評和審，對參與威脅評審的人員軟實力要求有：
- 一定程度了解業務；
- 合格的文檔編寫能力；
- 有意識地優化企業體系結構中的研發安全流程；
- 有意愿傳播安全能力，以支持增強安全團隊話語能力。
? 2.2? 評估流程
- 準備
實施威脅評估時，首先要取得業務團隊負責人的認同：不管有沒有事件驅動，安全團隊的參與都將為業務系統提供產品競爭力。哪怕現階段安全并不能完全賦能給業務，但長期來看，威脅建模應該在業務技術迭代的每個環節都去自助實施，隨著技術的積累，業務團隊獨立完成威脅技術安全分析是有可能的。
- 團隊
參與團隊以”two-pizza teams”團隊最佳，建立工作團隊后，按需引入相關人，以后這個工作組聚焦為業務提供安全能力。保持溝通是構建產品安全的訣竅，實施威脅建模的效果深受團隊如何組織和交流的影響。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 周期
實施這項活動的整個周期除了解決風險的階段稍長，從問卷調查到給出威脅評估報告，建議持續時間為1到2周，如時間太短，團隊成員之間不能建立足夠的信任，不能充分給出安全評估的結果；如時間太長，會忘記之前討論的結果，耗費雙方團隊精力。威脅評估迭代的周期保持靈活，在人力充足的情況下以重大變更、功能模塊迭代的數月、半年一輪為佳，人力不足的時候應盡量把評審過程由人力到工具化、自動化、服務化。
- 流程
安全架構評審的核心是威脅建模，詳細參考可以參考?《安全架構評審實戰》?,當然傳統的建模流程太重了，雖然尊重業務的設計過程很復雜，威脅分析也沒有理由取巧走捷徑，是改善安全必須付出的成本，盡量復用現有流程的同時針對敏捷開發做出適當精簡——通過問卷簡化核心安全要素的分析、通過組織流程優化溝通方式、通過融入研發流程快速閉環。總結出比較適合互聯網企業的評估工作流程如下：
- 訪談由安全評審人主持，時間盡量控制在40分鐘以內，人數最小是4人左右。第一次訪談可以從問卷的內容開始，就每一個問卷選項進行交流，確保業務正確理解問卷中提到的問題，確保問卷的填寫結果是業務想要表達的意思，確保業務不清楚的、有分歧的可以通過討論給出一致結論。問卷訪談時不用過于討論技術細節、系統不足和實際修復方案，主要是了解業務的基本安全情況。訪談的第二個議題是邀請業務方對軟件設計文檔、架構圖進行講解。最后的總結5分鐘左右，會后遺留三項todo：一、填寫應用信息收集表，包括技術文檔地址、代碼倉庫地址、域名、CI\CD發布項、技術棧、測試環境賬戶；二、下一次溝通時間；三、安全對接專人。
- 第二次訪談之前，安全人員應多閱讀業務方的文檔，代碼，進行適度的安全測試。這次訪談希望有業務方架構師、代碼開發負責人參與，對于安全前期整理的所不理解的調用關系問題、現有的安全控制措施問題、流程細節、組件、認證方式等其他技術細節進行討論，分歧點和討論結果通過文檔記錄方便查閱。
- 日常發現的疑問可以多次隨時溝通，評審是一項“開卷考試”，很多黑白盒發現的安全風險無需花大精力執行安全測試，通過向業務方咨詢就能得到確認。
- 訪談的對象通過產品、架構設計、開發人員類型的不同視角可以發現業務自身的訛誤、業務如有不清楚的地方或歷史遺留問題，不用在這里卡殼，先弄懂能弄清楚的來逐步拼接“拼圖”。
- 最簡單的威脅建模，就是關于威脅的頭腦風暴而已。訪談的原則要把自己作為業務的CISO，從產品安全負責人的角度考慮：這個產品賣出去，可以提供什么安全能力？出現安全事故事前該怎么做？
4. 開展架構評審中威脅建模的幾個子過程，包括定義資產、識別威脅、評估風險、給出緩解措施等，將在下面的 “實施威脅建模”章節詳細展開說。
5. 威脅建模的階段性成果交付物會是不同形式，如安全白皮書、安全設計指導、威脅評估報告。業務團隊可以從安全給出的長期修復方案和安全規劃中獲益。最終報告最好有安全團隊內部雙人復核機制，不同安全專家視角里對威脅的理解是不一樣的，雙人復核的另一個好處是可以減少工作量，比如分工區分A-管理端,B-Agent，A-代碼，B-設計實現或者A評審-,B復查分工。給出威脅建模結果前一定要同業務團隊再次溝通，確認哪些風險是安全視角被錯誤理解的，哪些是已經在業務視野中，哪些是業務團隊認知不到位的。修復方案要區分接受、緩解、轉移、處理風險四種情況。溝通時對應報告每個威脅項要求業務方給出明確的排期。短期可以走安全工單，長期納入業務的規劃排期中，識別出的共性安全問題作為安全專項制定孵化相應的安全工具和項目，補全安全建設的藍圖。
6.?發現風險總是容易，解決風險才是這項工作的價值。減緩發現的威脅可能需要業務重新設計，需要排除萬難達成目標，不然評審過的系統帶來的虛假安全感，還不如沒有安全感。一個有趣的現狀是解決威脅時對于安全團隊是業務在修復漏洞，對于業務是在滿足安全團隊提出安全需求。安全團隊以往的視角總是急迫希望業務立即去修復，其實大可不必著急，不妨就按照安全需求去溝通。評審發現的問題不少是架構和設計方面的問題，比如認證、鑒權、數據安全方面，需要業務方進行大的設計變更，要建設對應的公共基礎服務，要理解業務（反正風險已經存在很長時間了，敬畏業務的修復成本，尊重技術客觀規律），只要能解決問題即可。好的修復方案一定是考慮性價比的，而且可行性大于必要性，每個團隊的資源都不是無限的，按照處理的優先級進行排序工作。對識別出暫時不能解決的問題可以做出對應的監控、審計手段，如果要介入培訓此時也是好的階段，優秀的工程師總是想掌握到不同的知識，培訓不是被動地聚在一起講PPT，而是互動交流，建立安全文化的積極性。
7. 在業務方確定處置風險完畢后，安全團隊復查修復是否完成，修復是否引入新的問題，業務方是否對方案理解到位。這個過程要和業務團隊保持互動，安全評審并不是單純安全測試，而是指導安全能力的提升，結束時可以給業務積極的反饋，保持健康的安全文化。
8. 威脅評估的活動最好定期重復進行。安全防護為什么要與時俱進？
一、隨著制度法規的完善，對業務的安全性提出更高的要求；
二、公司安全基礎設施能力不斷提升，可為業務提供的公共安全能力不斷增強；
三、業務系統可能隨著時間的變化，安全現狀有質的改變，隨著信息系統所承載的業務完善或穩定，業務有取消合并的迭代。
3、實施威脅建模
? 3.1 數據流關系圖都不準確，盡量有用而已
- 微軟的Microsoft Threat Modeling Tool工具優點是適合初學者接觸熟悉了解外部實體、數據流、過程、存儲、信任邊界的基本概念，缺點是除了Windows應用程序和Azure示例之外沒有合適的威脅模板。
- Owasp threat-dragon的優點是表達方式更豐富，但是不能支持動態拖拽和自動導出威脅列表。大家沒有必要將整理數據流圖視為困難，實戰中威脅建模能力只能通過多練習、反復挑戰的方法熟悉技能。
回過頭看早期的一些對威脅模型的判斷往往不準確的，沒有關系，畢竟你曾經“實施”過威脅建模了。繪制數據流的過程可以理解業務、確保安全視角沒有遺漏。 威脅建模完全自動化基本是偽需求，沒有足夠多的業務產品需要持續進行建模評審、大量的原始信息來自于文檔、架構師的經驗、場景和知識極其復雜。建議盡快上手可以使用系統自帶的流程圖，使用Visio和draw.io最方便。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
? 3.2 識別威脅是互動過程
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 業界同類產品的安全白皮書，如各家公有云的材料相對比較全，要思考這些同類產品都有哪些安全功能，有沒有安全需求，能不能實現。
- 通過內部工單系統搜索該部門名下的歷史漏洞：經常一個產品歷史出現過越權漏洞，是因為整個產品都沒有鑒權；一個接口不符合編碼規范，同一份代碼的另一個接口出現安全問題的風險高。
- 開源產品的安全設計方案，歷史漏洞。
- 專利、論文、行業知識庫，對于新的技術的如人臉識別、機器學習、大數據業務這方面的材料很寶貴。
以上舉個簡單的例子，場景是租戶通過第三方開放平臺登錄后通過微服務處理業務。
- 認證和授權：未強制HTTPS缺失二次認證措施
- 日志和監控：缺失日志記錄和審計模塊日志本地留存
對于IAM服務服務器，存在的威脅有：
- 信息泄露：用戶身份信息泄露
- 認證：暴力破解對外發送的管理平臺憑據授權策略繞過
- 可用性：單機實例，誤操作可導致宕機風險
對于MySQL服務，部分存在的威脅有：
- 認證：攻擊者獲取憑據后可以直接訪問、修改、刪除業務數據
- 權限提升：攻擊者可以從普通用戶提升至root獲取數據庫完全控制權限
- 信息泄露：SQL注入導致所保存的業務數據泄露
評估風險結果沒有列出來有些是自動認可忽略的，有些是放在基線等安全控制措施，大多數的威脅發現都是基于參與者的經驗，可以從安全最佳實踐、加固指導、歷史案例形成知識庫積累下來。 具體實施的過程目前沒有完全的自動化工具，但是檢測項一般有共識：比如從域名系統查看是否啟用強制HTTPS、S3對象存儲查看是否啟用服務器端加密，硬編碼問題、是否加入FIDO等。
雖然威脅建模的一個要點是避免關注漏洞而不是威脅，但基本沒有一個系統是從零搭建的，新的項目也會大量引入框架、組件、第三方服務，適當的安全測試是必要，原則是聚焦發現設計方面高層次的風險，但如果參與人員具備一些實際攻防能力，可以將其他安全工具發現的問題納入一起解決，百利而無一害，本身建模的一個目標就是指導安全測試的方向。測試時要注意常見的攻防案例是影響機密性，也要考慮攻擊者破壞應用的可用性和完整性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 標記詳情，附加參考材料、變更記錄；
- 威脅影響級別：從機密性、完整性、可用性，利用難度四個角度進行評估。衡量風險沒有必要強制按照DREAD、CVSS評分模型，很大程度依賴于參與的安全專家對攻擊者的視角、安全建設的成熟度、業務的可接受能力進行定級，一般給出高中低即可。
? 3.3 處理威脅是重中之重
- 緩解
采取措施加大攻擊者的利用時間。就像Google Project Zero的原則“make 0-day hard”。比如發現密碼猜解的威脅，采用二次認證、風控驗證碼的技術，緩解和解決風險的界限往往并不清晰。仔細想想大部分的日常安全工作都是緩解威脅，比如部署WAF、制定安全規章制度、監控和響應。
- 解決
完全解決該威脅。解決是最樂觀的情況，常見的安全方案是基于現有的代碼實現，比如防SQL注入組件，使用加密套件解決硬編碼問題。如果威脅建模是發生在編碼之前，可以使用現有的安全方案如Security SDK、密鑰管理服務、身份認證方案，當然也可以引用新的安全技術去建設。
- 轉移
轉移是將威脅承擔交由其他系統去處理，比如用戶協議和隱私條款、免責聲明，變更管理的二次認證、外包、購買網絡安全保險。但是安全也不能對業務給個方案說你得買一份保險，這需要找到安全和業務的平衡感。
- 接受
接受風險也是面對安全成本的一個合理處理方式，不同層級的業務負責人對待安全的視角是有不同考慮的。比如在物理安全領域，我們往往做得適度投入，背后的原因是接受了戰爭、核武器等不可抗拒因素。
依據上述的威脅定義補充是等級、優先級、修復成本、負責人、排期、安全測試結果、解決方案記錄結果，報告文字要規范，避免使用安全特定術語、縮略語如PoC、RCE、SSRF、HIDS字樣。給出前瞻性的安全方案是區分安全測試和威脅建模的主要區別。對于共性問題建立孵化安全解決方案，有安全專項的也進行標記，后續可以比對安全項目的效果。
解決威脅的抽象原則要區分出安全建設的原則縱深防御、最小權限原則、默認（強制）安全并不一定適用于業務系統，業務更熟悉安全架構設計的5A原則：
- 身份認證（Authentication）：用戶主體是誰？
- 授權（Authorization）：授予某些用戶主體允許或拒絕訪問客體的權限。
- 訪問控制（Acccess Control）：控制措施以及是否放行的執行者。
- 可審計（Auditable）：形成可供追溯的操作日志。
- 資產保護（Asset Protection）：資產的保密性、完整性、可用性保障。
? 3.4 驗證威脅達到閉環
4、如何評價這件事做得好壞
5、經驗教訓
- 覆蓋基礎設施相對重要的公共組件服務和重要管理平臺；
- 形成一套可復用的安全評審流程，知識庫和工具；
- 及時發現公司管理平臺的運營安全類風險，排期止損加固。
通過制定的威脅建模計劃同業務部門深入開展合作，團隊完成了數十個項目的評估，發現了數百個高危設計缺陷，從而試圖解決兩類核心問題：1、人為操作導致的安全風險，2、安全融入基礎架構。識別提煉出孵化出特權賬戶管理平臺、服務鑒權、執行沙箱、全程票據、安全知識庫等安全子項目。當然建模的效果有好有壞，我們仍需學習、調整、迭代。總結了如下的經驗教訓：
- 關注真實的威脅，從技術威脅入手延伸到業務威脅；
- 安全沒有銀彈，使用其他應用安全措施補充威脅建模；
- 見木不見林，致力于高效的建模，而不糾結于細節；
- 關注安全的溝通協作，改善研發解決安全問題的思維方式，勝于投入精力在安全測試。
業界關于威脅建模的實施方法論在物聯網、機器學習、ServerLess場景依舊很有生命力，說明在軟件工程領域這會是識別威脅真正有效的辦法。相信Threat modeling Application Security Testing（威脅模型驅動的應用安全測試）將成為應用安全的又一主流安全測試方法。
參考資料：
https://michenriksen.com/blog/drawio-for-threat-modeling/?ref=hackernoon.com
https://github.com/cncf/financial-user-group/tree/master/projects/k8s-threat-model
http://ceur-ws.org/Vol-413/paper12.pdf
https://community.iriusrisk.com/
https://threatdragon.org/login
http://mozilla.github.io/seasponge/#/
https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
http://www.owasp.org.cn/owasp-project/OWASP_Top_10_Proactive_Controls_V3v1.1.pdf
http://www.woshipm.com/it/1663882.html
https://developer.ibm.com/zh/components/redhat-openshift-ibm-cloud/articles/threat-modeling-microservices-openshift-4/
https://docs.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach
https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
https://csrc.nist.gov/publications/detail/sp/800-154/draft?ref=wellarchitected
https://github.com/google/end-to-end/wiki/Threat-model
來源：安全客