實踐之后，我們來談談如何做好威脅建模

對美團安全團隊來說，引入領先的安全技術設計能力，構建全方位、多維度智能防御體系，是我們不懈追求的目標，美團有眾多基礎設施，核心業務系統也需要以成熟的方法論進行威脅評審，本文將著重分享威脅建模是如何幫助美團安全團隊評估、發現大量安全設計的風險，以及互聯網企業應該如何大范圍地實施威脅建模并完整地進行落地，

• 1 寫在前面

  • 1.1 什么是威脅建模

  • 1.2 威脅建模的價值

  • 1.3 遇到的挑戰

• 2 準備威脅建模

  • 2.1 能力要求

  • 2.2 評估流程

• 3 實施威脅建模

  • 3.1 資料流關系圖都不準確，盡量有用而已

  • 3.2 識別威脅是互動程序

  • 3.3 處理威脅是重中之重

  • 3.4 驗證威脅達到倍訓

• 4 如何評價這件事做得好壞

• 5 經驗教訓

• 參考資料

1 寫在前面

1.1 什么是威脅建模

孫子兵法：知彼知己，百戰不殆；不知彼知己，一勝一負；不知彼不知己，每戰必殆，

微軟：威脅建模實踐使開發團隊可以在計劃的運行環境的背景下，以結構化的方式思考、記錄并討論系統設計的安全影響，威脅建模是幫助保護系統、應用程式、網路和服務的有效方法，這是一種工程技術，用于識別潛在的威脅和建議，以幫助降低風險并在開發生命周期的早期實作安全目標，

OWASP: identifying, communicating, and understanding threats and mitigations within the context of protecting something of value.

計算機發明后不久，人們就發現需要為這些資訊系統處理威脅，早在1994年，NSA和DARPA就提出了攻擊樹、威脅樹等概念，1999年微軟內部發表了題為《The threats to our products》的文章，為定義Windows全系產品面臨的安全威脅正式提出了STRIDE助記符，隨著2002年比爾·蓋茨著名的《可信任計算備忘錄》宣言發布，微軟承諾改善軟體產品的安全性，隨即正式在SDL（安全開發生命周期）中采用了威脅建模，

威脅建模數十年來不斷取得大家的認可，在業內也有STRIDE、Trike、OCTAVE等多種方法論實踐，安全行業的從業人員普遍認識到，在研發團隊的安全例行活動中，對于一些擁有重要資料資產、安全事件影響力大的系統除了要進行常規的滲透測驗、黑白盒代碼掃描之外，更應該系統地定期開展威脅建模活動并對業務賦能，

1.2 威脅建模的價值

• 識別體系化的結構缺陷：大多數安全問題是設計缺陷問題，而不是安全性錯誤，威脅建模能幫助識別這些設計缺陷，從而減少風險敞口，指導安全測驗，并降低因安全漏洞而造成的品牌損害或財務損失等可能性，

• 節約組織安全成本：通過對威脅進行建模，并在設計階段建立安全性需求，降低安全設計缺陷導致的修復成本，在需求管理和威脅分析階段，與業務開發團隊高效互動，釋放安全團隊的專業能力，專注于高性價比的安全建設，

• 落地DevSecOps文化：通過威脅建模跑通開發和安全工具的流程集成，把風險管理嵌入產品的完整生命周期，從而推動形成完整的DevSecOps工具鏈，

• 滿足合規要求：威脅建模是國際安全行業通用的方法論，通過向管理層和監管機構提供產品的風險管理活動的完整記錄，幫助團隊遵守全球法律法規要求，包括PCI DSS、GDPR、HIPAA、CSA STAR等，

1.3 遇到的挑戰

普及威脅建模流程和技術可以有效提升企業的安全建設水平，作為互聯網企業，要實施敏捷的軟體開發流程，威脅建模活動也應盡量便捷，但實際作業起來并不簡單，落地程序中也會遇到不少挑戰，按優先級排序，挑戰包括以下幾個方面：

1. 缺乏優秀的自動化建模工具；

2. 安全團隊沒有時間和精力對每個應用都實施建模；

3. 缺乏對威脅建模足夠的了解，知識庫涉及不同領域、專家經驗難以共享；

4. 建模活動、輸出結果沒有融入業務的敏捷研發流程；

5. 簡易的建模活動基于問卷或者表格記錄分析，并沒有實際的更新、積累和進一步分析，

2 準備威脅建模

2.1 能力要求

在進行復雜的威脅分析時，并不是SDL一個團隊就可以獨立完成的，還需要資料安全、IT安全、風控合規等安全團隊協作，評審活動也涉及到內容、網路、隱私保護、法務、運維各個領域，各參與者最好提前建立對公司基礎設施、安全分工的認知，相對清楚各個產品的作用、特點、接入辦法、適用場景，建議實施威脅建模的參與人員都了解有關產品的設計、接入檔案材料，看不懂不用擔心，多瀏覽幾遍，逐步熟悉即可，

對于實施威脅建模的負責人有四個層面的基本技術能力要求，包括：

• 懂常用的安全技術、安全機制、攻擊方法、危害、加密演算法；

• 懂業務、流程、內部技術服務、產品與產品之間、組件和組件之間的關系；

• 組織人員策略資源來推動專案實施；

• 將安全規劃、安全流程、治理模型組合來符合縱深防御原則，

威脅評審，重點是評和審，對參與威脅評審的人員軟實力要求，包括：

• 一定程度了解業務；

• 合格的檔案撰寫能力；

• 有意識地優化企業體系結構中的研發安全流程；

• 有意愿傳播安全能力，以支持增強安全團隊話語能力，

2.2 評估流程

準備

實施威脅評估時，首先要取得業務團隊負責人的認同：不管有沒有事件驅動，安全團隊的參與都將為業務系統提供產品競爭力，哪怕現階段安全并不能完全賦能給業務，但長期來看，威脅建模應該在業務技術迭代的每個環節都去自助實施，隨著技術的積累，業務團隊獨立完成威脅技術安全分析是有可能的，

團隊

參與團隊以“Two-Pizza Teams”團隊為最佳，建立作業團隊后，按需引入相關人，以后這個作業組聚焦為業務提供安全能力，保持溝通是構建產品安全的訣竅，實施威脅建模的效果深受團隊如何組織和交流的影響，

周期

實施這項活動的整個周期除了解決風險的階段稍長，從問卷調查到給出威脅評估報告，建議持續時間為1到2周；如時間太短，團隊成員之間不能建立足夠的信任，不能充分給出安全評估的結果；如時間太長，會忘記之前討論的結果，耗費雙方團隊精力，威脅評估迭代的周期保持靈活，在人力充足的情況下以重大變更、功能模塊迭代的數月、半年一輪為佳，人力不足的時候應盡量把評審程序由人力到工具化、自動化、服務化，

流程

安全架構評審的核心是威脅建模，詳細參考可以參考 《安全架構評審實戰》 一文，當然，傳統的建模流程太重了，雖然尊重業務的設計程序很復雜，威脅分析也沒有理由取巧走捷徑，是改善安全必須付出的成本，但應盡量在復用現有流程的同時針對敏捷開發做出適當精簡——通過問卷簡化核心安全要素的分析、通過組織流程優化溝通方式、通過融入研發流程快速倍訓，總結出比較適合互聯網企業的評估作業流程如下：

1. 首先是立項，增量盡量都覆寫，存量根據攻防優先級選擇合適的重要系統開始評估，建議由業務方和安全一致的選擇目標范圍，一般建議從基礎設施系統自下而上，從IaaS/PaaS層開始比較合理，因為基礎設施的安全狀況改進了，整個業務線都可以覆寫接入受益，評審不僅僅需要安全方面投入資源，也需要業務團隊有人力參與問卷填寫、專案介紹、多輪訪談、核對威脅、解決風險，需雙方共同意識到：達成安全目標需要業務人員共同參與進來，安全和業務都很專業，雙方建立的關系不應該是例行安全審計那樣的“你問我答”，氛圍可以盡量輕松，對齊發現的安全風險并不是哪個團隊做得不好，而是認清事實，及時止損，發現風險、解決技術債務，交付和設計安全的代碼也是開發的長期挑戰，雙方應著眼于改善產品未來的安全狀況，

2. 第二步問卷調查或檔案填寫的目的是收集必要的業務資訊，檔案/問卷應精心設計，不要采用過于專業的術語，目的是掃除業務方知識盲點，建立對產品初步的安全現狀認知，不清楚的問卷選項可以不填，填就盡量保證準確，建立作業群后發出問卷調查要求，問卷是啟動威脅建模專案的起點，業務方認真填寫問卷是專案良好開展的前提，

3. 同業務的訪談要反復進行多次，安全團隊的風格要么過于強硬，要么容易臉皮薄，覺得和業務打交道要對方多次配合，不好意思打擾業務，這是錯的，需要糾正，

• 訪談由安全評審人主持，時間盡量控制在40分鐘以內，人數最小是4人左右，第一次訪談可以從問卷的內容開始，就每一個問卷選項進行交流，確保業務正確理解問卷中提到的問題，確保問卷的填寫結果是業務想要表達的意思，確保業務不清楚的、有分歧的可以通過討論給出一致結論，問卷訪談時不用過于討論技術細節、系統不足和實際修復方案，主要是了解業務的基本安全情況，訪談的第二個議題是邀請業務方對軟體設計檔案、架構圖進行講解，最后的總結5分鐘左右，會后遺留三項To Do：①填寫應用資訊收集表，包括技術檔案地址、代碼倉庫地址、域名、CI\CD發布項、技術堆疊、測驗環境賬戶；②下一次溝通時間；③安全對接專人，

• 第二次訪談之前，安全人員應多閱讀業務方的檔案、代碼，進行適度的安全測驗，這次訪談希望有業務方架構師、代碼開發負責人參與，對于安全前期整理的所不理解的呼叫關系問題、現有的安全控制措施問題、流程細節、組件、認證方式等其他技術細節進行討論，分歧點和討論結果通過檔案記錄方便查閱，

• 日常發現的疑問可以多次隨時溝通，評審是一項“開卷考試”，很多黑白盒發現的安全風險無需花大精力執行安全測驗，通過向業務方咨詢就能得到確認，

• 訪談的物件通過產品、架構設計、開發人員型別的不同視角可以發現業務自身的訛誤，業務如有不清楚的地方或歷史遺留問題，不用在這里卡殼，先弄懂能弄清楚的來逐步拼接“拼圖”，

• 最簡單的威脅建模，就是關于威脅的“頭腦風暴”而已，訪談的原則要把自己作為業務的CISO，從產品安全負責人的角度考慮：這個產品賣出去，可以提供什么安全能力？出現安全事故事前該怎么做？

• 開展架構評審中威脅建模的幾個子程序，包括定義資產、識別威脅、評估風險、給出緩解措施等，將在下面的 “實施威脅建模”章節詳細展開說，

• 威脅建模的階段性成果交付物會是不同形式，如安全白皮書、安全設計指導、威脅評估報告，業務團隊可以從安全給出的長期修復方案和安全規劃中獲益，最終報告最好有安全團隊內部雙人復核機制，不同安全專家視角里對威脅的理解是不一樣的，雙人復核的另一個好處是可以減少作業量，比如分工區分A-管理端、B-Agent、A-代碼、B-設計實作或者A-評審、B-復查分工，給出威脅建模結果前一定要同業務團隊再次溝通，確認哪些風險是安全視角被錯誤理解的，哪些是已經在業務視野中，哪些是業務團隊認知不到位的，修復方案要區分接受、緩解、轉移、處理風險四種情況，溝通時對應報告每個威脅項要求業務方給出明確的排期，短期可以走安全工單，長期納入業務的規劃排期中，識別出的共性安全問題作為安全專項制定范訓相應的安全工具和專案，補全安全建設的藍圖，

• 發現風險總是容易，解決風險才是這項作業的價值，級訓發現的威脅可能需要業務重新設計，需要排除萬難達成目標，不然評審過的系統帶來的虛假安全感，還不如沒有安全感，一個有趣的現狀是解決威脅時對于安全團隊是業務在修復漏洞，對于業務是在滿足安全團隊提出安全需求，安全團隊以往的視角總是急迫希望業務立即去修復，其實大可不必著急，不妨就按照安全需求去溝通，評審發現的問題不少是架構和設計方面的問題，比如認證、鑒權、資料安全方面，需要業務方進行大的設計變更，要建設對應的公共基礎服務，要理解業務（反正風險已經存在很長時間了，敬畏業務的修復成本，尊重技術客觀規律），只要能解決問題即可，好的修復方案一定是考慮性價比的，而且可行性大于必要性，每個團隊的資源都不是無限的，按照處理的優先級進行排序作業，對識別出暫時不能解決的問題可以做出對應的監控、審計手段，如果要介入培訓此時也是好的階段，優秀的工程師總是想掌握到不同的知識，培訓不是被動地聚在一起講PPT，而是互動交流，建立安全文化的積極性，

• 在業務方確定處置風險完畢后，安全團隊復查修復是否完成，修復是否引入新的問題，業務方是否對方案理解到位，這個程序要和業務團隊保持互動，安全評審并不是單純安全測驗，而是指導安全能力的提升，結束時可以給業務積極的反饋，保持健康的安全文化，

• 威脅評估的活動最好定期重復進行，安全防護為什么要與時俱進？第一，隨著制度法規的完善，對業務的安全性提出更高的要求；第二，企業安全基礎設施能力不斷提升，可為業務提供的公共安全能力不斷增強；第三，業務系統可能隨著時間的變化，安全現狀有質的改變，隨著資訊系統所承載的業務完善或穩定，業務有取消合并的迭代，

3 實施威脅建模

繪制資料流圖，識別定義威脅、處置威脅、驗證風險得到正確處理是威脅建模的四個常用步驟，

3.1 資料流關系圖都不準確，盡量有用而已

為什么我們需要建模？因為實施威脅建模時往往系統并未完整構建，模型會幫助思考系統的設計，以攻擊者和防守方的方式思考對應的安全威脅，

經過初步問卷和訪談后，安全團隊也收集到大量業務反饋的資訊，產品和應用安全團隊聚在一起討論軟體架構和潛在的安全問題，使用威脅建模工具、審查資料流圖、威脅模型的目標都是為了達成更充分討論的目的而服務，建議安全團隊基于業務的流程圖、呼叫關系同業務一起繪制DFD資料流圖，一般常見的資料流形式有：①白板上作為會議隨堂討論的示意圖，輔助提高溝通效率，一般用于說明系統層級架構；②業務現有檔案中的時序圖、UML圖輔助理解復雜問題和技術細節，

畫系統架構的目標是解決利益相關者的關注點，業務實作安全功能，安全實作安全設計，大家普遍反映實施威脅建模時都在畫架構圖時遇到最大的困難，糾結于用什么工具，在繪制DFD圖的工具選擇上：

• 微軟的Microsoft Threat Modeling Tool工具的優點是，適合初學者接觸熟悉了解外部物體、資料流、程序、存盤、信任邊界的基本概念，缺點是除了Windows應用程式和Azure示例之外沒有合適的威脅模板，

• OWASP Threat Dragon的優點是表達方式更豐富，但是不能支持動態拖拽和自動匯出威脅串列，大家沒有必要將整理資料流圖視為困難，實戰中威脅建模能力只能通過多練習、反復挑戰的方法熟悉技能，

回過頭看早期的一些對威脅模型的判斷往往不準確的，沒有關系，畢竟你曾經“實施”過威脅建模了，繪制資料流的程序可以理解業務、確保安全視角沒有遺漏，威脅建模完全自動化基本是偽需求，沒有足夠多的業務產品需要持續進行建模評審、大量的原始資訊來自于檔案、架構師的經驗、場景和知識極其復雜，建議盡快上手可以使用系統自帶的流程圖，使用Visio和Draw.io最方便，

資料流的細粒度也難以抉擇，謹慎地選擇資訊的層級和粒度并不是一件容易的事情，初學者剛開始的時候總是覺得每個功能都得拆分，每個功能都要求加密，靈活程度取舍于所使用的架構模型、架構師的經驗和系統的復雜度，根據筆者的經驗，一種C4 Model結合微軟威脅模型圖例的方法容易取得合作方業務架構師的認同，以下給大家做個簡單的示例，

系統背景關系圖（System Context Diagram）

在這一層級中細節并不重要，只顯示系統概況，重點應該放在人員（角色）和軟體系統上，而不是技術，協議和其他低層級細節上，從而使非技術人員也能夠看得懂，這個圖也是明確需求的重要圖示，這表示一個應用和其他系統的下轄有呼叫關系，不需要完整表示資料的流向，只要大致描述清楚系統的周邊關系，不遺漏關鍵步驟，

上述這個層級的示范是微軟Azure的威脅建模的資料流圖，優點是通過數字表示了流程順序，

應用圖（Application Diagram）

應用是可單獨運行/可部署的單元（例如，單獨的行程空間）執行代碼或存盤資料，應用圖顯示了軟體體系結構的高層結構以及如何分配職責，它還顯示了主要的技術選擇以及容器之間的通信方式，

一個應用包含多個服務，如果一個系統有多個子系統，應該對每個子系統都進行分析，通過威脅建模應該嘗試了解整體情況，包含應用本身、資料庫、互動、部署場景、云服務、接入的基礎服務，下圖是模擬一個支付應用的示例，

服務圖（Service Component diagram）

服務圖顯示了服務如何由多個“組件”組成，每個組件是什么，它們的職責以及技術/實作介面（API）或者細節，這個細粒度的分解是建模最大的作業量，為分解的各個通用組件創建的威脅模型結果可以復用在其他應用上，比如Kubernetes被分為Kube-Proxy、ETCD、Kubelet、Kube-APIServer、Scheduler、Container、Pods等，

代碼層級

這一層是可選的，可以使用UML類圖、物體關系圖、函式呼叫關系或類似的圖，對于分析特定代碼層級的漏洞很方便，推薦使用白盒掃描工具、IntelliJ IDEA的依賴矩陣、Diagrams、Flow插件進行分析，

資料流圖這項技術本身存在的不足是：關注組件的交付是還是相對偏資料流動視角，不少人的互動場景如釣魚、敏感功能誤操作不能表示出來；不能完全遍歷出程式的全部功能（除非圖足夠復雜）；基于程式設計圖之上繪制卻又丟失了設計細節，無法自動化；資料流會額外顯示出基礎設施引起的風險，并不僅僅是業務自身的安全，

3.2 識別威脅是互動程序

威脅建模是一種協作行為，一類結構化的思維方式，一項實踐的科學，以軟體程式為中心的威脅建模、列舉威脅、解決威脅、驗證來解決四個問題：具體業務是什么？哪些地方可能出現風險？如何規避解決？是否覆寫完整，

所以識別威脅的第一步是靈活定義攻擊者的目標，組織要保護的資產和信任級別，如：S3存盤、源代碼、主機、資料庫、憑據、行級資料，知識產權等，公有云、私有云不同的責任共擔模型就清晰給出了不同的業務需要關注哪些資產的示例，云上資產的建模更關注安全的信任邊界，

第二步給出明確的攻擊路徑，定義攻擊者：比如惡意內部員工、外部攻擊者，競爭對手、好奇者等，攻擊路徑的抉擇直接影響攻擊面和信任邊界的劃定，

第三步即威脅評估的程序不能缺少架構分類思維，一般使用 ASTRIDE（隱私、欺騙、篡改、資訊泄露、否認性、拒絕服務和特權提升）和攻擊樹模型作為常用的威脅建模技術指導原則，

| ASTRIDE (Advanced STRIDE )

微軟已經不再維護STRIDE，采用ASTRIDE更符合面向消費者的網路安全行業的發展，

將系統分解為相關的組件，分析每個組件對應的威脅，有個技巧是從外部物體逐次開始，關注有互動的行程，沒有互動的行程一般沒有威脅，

上圖中，資料存盤僅是保存日志資訊時才有抵賴的威脅，

分析威脅模型和業務互動時，按照上面的兩張表考慮每個元素對應的威脅，實施時要對照進行思考當做Checklist來分類，ASTRIDE是幫助認識歸類威脅的工具，而不是分類定義，某些威脅比如沒有啟用HTTPS，從中間人攻擊的角度分析實際的風險既是資料泄露，也屬于篡改、隱私分類，有的威脅如IoT設備的爆炸、丟失不屬于以上任一分類，沒有必要強行去分類，反正已經發現記錄威脅了，另外，信任邊界很重要，安全本質是信任問題，攻擊面的定義直接影響威脅的劃分，

幾個安全概念的區別

• 威脅是應用潛在存在的安全弱點，

• 漏洞是對威脅的利用，產品實作了預期之前的功能，影響了安全性，

• Bug是未實作的功能，

• 風險是發生的，對資產有危害的可能性，

• 風險=（威脅+漏洞）*可能性，

舉個例子：存在新冠肺炎病毒是“威脅”，沒帶口罩是“漏洞”，存在感染病毒可能是“風險”，人體不能解決病毒是“Bug”，主動免疫是安全需求，

對于威脅的判斷來源，可以參考：

• 業界同類產品的安全白皮書，如各家公有云的材料相對比較全，要思考這些同類產品都有哪些安全功能，有沒有安全需求，能不能實作，

• 通過內部工單系統搜索該部門名下的歷史漏洞：經常一個產品歷史出現過越權漏洞，是因為整個產品都沒有鑒權；一個介面不符合編碼規范，同一份代碼的另一個介面出現安全問題的風險高，

• 開源產品的安全設計方案，歷史漏洞，

• 專利、論文、行業知識庫，對于新的技術的如人臉識別、機器學習、大資料業務這方面的材料很寶貴，

以上舉個簡單的例子，場景是租戶通過第三方開放平臺登錄后通過微服務處理業務，

對于API網關，存在的威脅包括：

• 認證和授權

  • 未強制HTTPS

  • 缺失二次認證措施

• 日志和監控

  • 缺失日志記錄和審計模塊

  • 日志本地留存

對于IAM服務服務器，存在的威脅包括：

• 資訊泄露：用戶身份資訊泄露

• 認證

  • 暴力破解對外發送的管理平臺Token

  • 授權策略繞過

• 可用性

  • 單機實體，誤操作可導致宕機風險

對于MySQL服務，部分存在的威脅包括：

• 認證：攻擊者獲取憑據后可以直接訪問、修改、洗掉業務資料

• 權限提升：攻擊者可以從普通用戶提升至Root，獲取資料庫完全控制權限

• 資訊泄露：SQL注入導致所保存的業務資料泄露

評估風險結果沒有列出來有些是自動認可忽略的，有些是放在基線等安全控制措施，大多數的威脅發現都是基于參與者的經驗，可以從安全最佳實踐、加固指導、歷史案例形成知識庫積累下來，具體實施的程序目前沒有完全的自動化工具，但是檢測項一般有共識：比如從域名系統查看是否啟用強制HTTPS、S3物件存盤查看是否啟用服務器端加密、硬編碼問題、是否加入FIDO等，

雖然威脅建模的一個要點是避免關注漏洞而不是威脅，但基本沒有一個系統是從零搭建的，新的專案也會大量引入框架、組件、第三方服務，適當的安全測驗是必要，原則是聚焦發現設計方面高層次的風險，但如果參與人員具備一些實際攻防能力，可以將其他安全工具發現的問題納入一起解決，百利而無一害，本身建模的一個目標就是指導安全測驗的方向，測驗時要注意常見的攻防案例是影響機密性，也要考慮攻擊者破壞應用的可用性和完整性，

| 攻擊樹模型

安全專家大都熟悉實戰中通過哪些攻擊手段可以損害資產，很多網路上的滲透測驗報告就是以攻擊鏈路形成的思維導圖為例，可以據此細化出一個產品的攻擊樹，攻擊樹模型有兩種方法：自下而上和Use Case型，前者是全部覆寫到實作目標的入口，后者基于前者的細節，在確定攻擊的前提下展示出實際的攻擊，涉及大量用例的、業務邏輯復雜的、有互動程序的、系統已經設計完成的，通過攻擊樹很容易發現安全威脅，攻擊樹模型一般遵循以下的定義圖例：

通過下面舉個例子，攻擊者嘗試持久化在Kubernetes集群內部執行命令，可以通過部署惡意鏡像、容器內執行命令、提權控制宿主機多種方法，在部署惡意鏡像這一步，自下而上瀏覽首先要具備訪問Kubernetes API權限的認證資訊或Kubelet工具的憑據，然后必須有鏡像倉庫操作寫的權限，然后部署惡意鏡像，

識別到威脅后對威脅進行幾個處理步驟：

1. 標記詳情，附加參考材料、變更記錄；

2. 威脅影響級別：從機密性、完整性、可用性，利用難度四個角度進行評估，衡量風險沒有必要強制按照DREAD、CVSS評分模型，很大程度依賴于參與的安全專家對攻擊者的視角、安全建設的成熟度、業務的可接受能力進行定級，一般給出高中低即可，

3.3 處理威脅是重中之重

經過上述的活動，我們獲取了一個大的威脅串列，下一步就是處置評估出來的每個風險，這方面的材料可以參考ISO27001和ISO31000的系列指導，分為四個應對措施，

緩解

采取措施加大攻擊者的利用時間，就像Google Project Zero的原則“Make 0-Day Hard”，比如發現密碼猜解的威脅，采用二次認證、風控驗證碼的技術，緩解和解決風險的界限往往并不清晰，仔細想想大部分的日常安全作業都是緩解威脅，比如部署WAF、制定安全規章制度、監控和回應，

解決

完全解決該威脅，解決是最樂觀的情況，常見的安全方案是基于現有的代碼實作，比如防SQL注入組件，使用加密套件解決硬編碼問題，如果威脅建模是發生在編碼之前，可以使用現有的安全方案如Security SDK、密鑰管理服務、身份認證方案，當然也可以參考新的安全技術去建設，

轉移

轉移是將威脅承擔交由其他系統去處理，比如用戶協議和隱私條款、免責宣告，變更管理的二次認證、外包、購買網路安全保險，但是安全也不能對業務給個方案說你得買一份保險，這需要找到安全和業務的平衡感，

接受

接受風險也是面對安全成本的一個合理處理方式，不同層級的業務負責人對待安全的視角是有不同考慮的，比如在物理安全領域，我們往往做得適度投入，背后的原因是接受了戰爭、核武器等不可抗拒因素，

依據上述的威脅定義補充是等級、優先級、修復成本、負責人、排期、安全測驗結果、解決方案記錄結果，報告文字要規范，避免使用安全特定術語、縮略語如PoC、RCE、SSRF、HIDS字樣，給出前瞻性的安全方案是區分安全測驗和威脅建模的主要區別，對于共性問題建立范訓安全解決方案，有安全專項的也進行標記，后續可以比對安全專案的效果，

解決威脅的抽象原則要區分出安全建設的原則縱深防御、最小權限原則、默認（強制）安全并不一定適用于業務系統，業務更熟悉安全架構設計的5A原則：

1. 身份認證（Authentication）：用戶主體是誰？

2. 授權（Authorization）：授予某些用戶主體允許或拒絕訪問客體的權限，

3. 訪問控制（Acccess Control）：控制措施以及是否放行的執行者，

4. 可審計（Auditable）：形成可供追溯的操作日志，

5. 資產保護（Asset Protection）：資產的保密性、完整性、可用性保障，

5A的劃分容易讓業務理解到開發架構、邏輯架構、資料架構、技術架構、業務架構中，從而避免因為安全緩解措施的影響導致原本的業務需求不能實作，或者性能、編碼、成本變更得太多，

完成威脅建模的標志是雙方團隊對圖表沒有異議，可以依據資料流圖，復述清楚資料流向、攻擊面如何、已經做了什么、存在哪些風險、應該做到什么，讓業務沒有安全知識的提升的建模是失敗的，業務方應當是下一個產品迭代中安全提升的主動貢獻者，

以下是威脅串列的結果示例模板：

3.4 驗證威脅達到倍訓

修復問題就是安全團隊復查威脅得到合理的處置，高標準就是合理，跟蹤威脅的解決不要拘泥于使用的安全內部的工單系統，在業務的研發管理系統記錄也是一個明智的選擇，同業務方制定單雙周的溝通會，確保每個風險在跟進按時解決，威脅建模并不是一次性活動，每次雙周溝通都簡短溝通，花5-10分鐘再一次實施建模：溝通下遇到什么困難，有什么安全需求，積累建模的習慣，通過反復執行這個活動可以從設計層面識別大量的安全風險，

我們總是提安全要Shift Left（左移），建模給了產品團隊良好的“右移”機會，團隊之間的知識共享幫助大家理解安全的本質，知道安全這件事該如何做，從而逐步改善公司的安全狀況，Security by Design要求安全前置介入到需求和設計階段，真正讓介入需求階段，安全又總是無從下手，其實需求階段的安全活動包括用例驗證、資產識別、安全基線，將權限、日志、操作安全、加密需求、編碼規范、基礎服務納入安全相關基線，設計階段主要有方案評審、安全特性設計，最重要的更是威脅建模，團隊互動的程序要以檔案的形式完整記錄，這種材料是給其他團隊下一次威脅建模的有效輸入，

4 如何評價這件事做得好壞

威脅建模不能立竿見影，建模沒有什么特別的，對于業務方來說應該是同編碼、測驗、交付一樣很普通的作業，安全也僅僅是日常作業的一部分，事情的主要目標是建立產品的安全屬性，可以通過最終的安全缺陷改進情況、評審覆寫度、修復解決率作為程序指標，安全成熟度、安全事故數作為結果指標，實施投入威脅建模本身已經是一件技能很復雜的事情了，對參與人員引導做正確的事，不需要設定發現威脅數等硬性指標，

威脅建模在于對評估可能的風險、分析潛在攻擊者的手法、攻擊路徑，提升產品的抗攻擊韌性方面有獨特的優勢，這項方法論根本沒有什么最佳實踐，沒有單一的“最好”或執行威脅建模的“正確”方法，而是為了滿足解決這些威脅而實施的一系列復雜和多維度的權衡，唯有不斷修正迭代才能完善，但如果沒有威脅建模程序參與，組織不會清楚現有系統的安全現狀，不管怎樣，一旦你取得階段性的成果，組織內部就認識到這樣的協作可以對改善總體安全狀況產生較大的作用，是高性價的投入，就可以克服關于威脅建模耗費人力、周期長、難點大這些阻力的聲音，從而真正從事預防性的安全建設，

5 經驗教訓

美團內部實施威脅建模時，首先就設立了如下的目標：

• 覆寫基礎設施相對重要的公共組件服務和重要管理平臺；

• 形成一套可復用的安全評審流程，知識庫和工具；

• 及時發現公司管理平臺的運營安全類風險，排期止損加固，

通過制定的威脅建模計劃同業務部門深入開展合作，團隊完成了數十個專案的評估，發現了數百個高危設計缺陷，從而試圖解決兩類核心問題：①人為操作導致的安全風險；②安全融入基礎架構，識別提煉出范訓出特權賬戶管理平臺、服務鑒權、執行沙箱、全程票據、安全知識庫等安全子專案，當然建模的效果有好有壞，我們仍需學習、調整、迭代，我們總結了如下的經驗教訓：

• 關注真實的威脅，從技術威脅入手延伸到業務威脅；

• 安全沒有“銀彈”，使用其他應用安全措施補充威脅建模；

• 見木不見林，致力于高效的建模，而不糾結于細節；

• 關注安全的溝通協作，改善研發解決安全問題的思維方式，勝于投入精力在安全測驗，

業界關于威脅建模的實施方法論在物聯網、機器學習、Serverless場景依舊很有生命力，說明在軟體工程領域這會是識別威脅真正有效的辦法，相信Threat Model Driven Approach for Security Testing（威脅模型驅動的應用安全測驗）將成為應用安全的又一主流安全測驗方法，

參考資料

• https://michenriksen.com/blog/drawio-for-threat-modeling/

• 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://aws.amazon.com/marketplace/pp/ThreatModeler-ThreatModeler/B07S65ZLPQ

• 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

• https://github.com/google/end-to-end/wiki/Threat-model

閱讀更多

---

前端 | 演算法 | 后端 | 資料

安全 | Android | iOS | 運維 | 測驗

---------- END ----------

也許你還想看

| 云原生之容器安全實踐

| 互聯網企業：如何建設資料安全體系？

| 互聯網公司資料安全保護新探索