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 遇到的挑戰
普及威脅建模流程和技術可以有效提升企業的安全建設水平，作爲互聯網企業，要實施敏捷的軟件開發流程，威脅建模活動也應儘量便捷，但實際工作起來並不簡單，落地過程中也會遇到不少挑戰。按優先級排序，挑戰包括以下幾個方面：
- 缺乏優秀的自動化建模工具；
- 安全團隊沒有時間和精力對每個應用都實施建模；
- 缺乏對威脅建模足夠的瞭解，知識庫涉及不同領域、專家經驗難以共享；
- 建模活動、輸出結果沒有融入業務的敏捷研發流程；
- 簡易的建模活動基於問卷或者表格記錄分析，並沒有實際的更新、積累和進一步分析。
2 準備威脅建模
2.1 能力要求
在進行復雜的威脅分析時，並不是SDL一個團隊就可以獨立完成的，還需要數據安全、IT安全、風控合規等安全團隊協作，評審活動也涉及到內容、網絡、隱私保護、法務、運維各個領域。各參與者最好提前建立對公司基礎設施、安全分工的認知，相對清楚各個產品的作用、特點、接入辦法、適用場景。建議實施威脅建模的參與人員都瞭解有關產品的設計、接入文檔材料，看不懂不用擔心，多瀏覽幾遍，逐步熟悉即可。
對於實施威脅建模的負責人有四個層面的基本技術能力要求，包括：
- 懂常用的安全技術、安全機制、攻擊方法、危害、加密算法；
- 懂業務、流程、內部技術服務、產品與產品之間、組件和組件之間的關係；
- 組織人員策略資源來推動項目實施；
- 將安全規劃、安全流程、治理模型組合來符合縱深防禦原則。
威脅評審，重點是評和審，對參與威脅評審的人員軟實力要求，包括：
- 一定程度瞭解業務；
- 合格的文檔編寫能力；
- 有意識地優化企業體系結構中的研發安全流程；
- 有意願傳播安全能力，以支持增強安全團隊話語能力。
2.2 評估流程
準備
實施威脅評估時，首先要取得業務團隊負責人的認同：不管有沒有事件驅動，安全團隊的參與都將爲業務系統提供產品競爭力。哪怕現階段安全並不能完全賦能給業務，但長期來看，威脅建模應該在業務技術迭代的每個環節都去自助實施。隨着技術的積累，業務團隊獨立完成威脅技術安全分析是有可能的。
團隊
參與團隊以“Two-Pizza Teams”團隊爲最佳，建立工作團隊後，按需引入相關人，以後這個工作組聚焦爲業務提供安全能力。保持溝通是構建產品安全的訣竅，實施威脅建模的效果深受團隊如何組織和交流的影響。
週期
實施這項活動的整個週期除了解決風險的階段稍長，從問卷調查到給出威脅評估報告，建議持續時間爲1到2周；如時間太短，團隊成員之間不能建立足夠的信任，不能充分給出安全評估的結果；如時間太長，會忘記之前討論的結果，耗費雙方團隊精力。威脅評估迭代的週期保持靈活，在人力充足的情況下以重大變更、功能模塊迭代的數月、半年一輪爲佳，人力不足的時候應儘量把評審過程由人力到工具化、自動化、服務化。
流程
安全架構評審的核心是威脅建模，詳細參考可以參考 《安全架構評審實戰》 一文。當然，傳統的建模流程太重了，雖然尊重業務的設計過程很複雜，威脅分析也沒有理由取巧走捷徑，是改善安全必須付出的成本，但應儘量在複用現有流程的同時針對敏捷開發做出適當精簡——通過問卷簡化核心安全要素的分析、通過組織流程優化溝通方式、通過融入研發流程快速閉環。總結出比較適合互聯網企業的評估工作流程如下：
- 首先是立項，增量儘量都覆蓋。存量根據攻防優先級選擇合適的重要系統開始評估，建議由業務方和安全一致的選擇目標範圍，一般建議從基礎設施系統自下而上，從IaaS/PaaS層開始比較合理。因爲基礎設施的安全狀況改進了，整個業務線都可以覆蓋接入受益。評審不僅僅需要安全方面投入資源，也需要業務團隊有人力參與問卷填寫、項目介紹、多輪訪談、覈對威脅、解決風險，需雙方共同意識到：達成安全目標需要業務人員共同參與進來，安全和業務都很專業。雙方建立的關係不應該是例行安全審計那樣的“你問我答”，氛圍可以儘量輕鬆。對齊發現的安全風險並不是哪個團隊做得不好，而是認清事實，及時止損，發現風險、解決技術債務，交付和設計安全的代碼也是開發的長期挑戰，雙方應着眼於改善產品未來的安全狀況。
- 第二步問卷調查或文檔填寫的目的是收集必要的業務信息。文檔/問卷應精心設計，不要採用過於專業的術語，目的是掃除業務方知識盲點，建立對產品初步的安全現狀認知。不清楚的問卷選項可以不填，填就儘量保證準確。建立工作羣后發出問卷調查要求，問卷是啓動威脅建模項目的起點，業務方認真填寫問卷是項目良好開展的前提。
- 同業務的訪談要反覆進行多次，安全團隊的風格要麼過於強硬，要麼容易臉皮薄，覺得和業務打交道要對方多次配合，不好意思打擾業務，這是錯的，需要糾正。
- 訪談由安全評審人主持，時間儘量控制在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工具的憑據，然後必須有鏡像倉庫操作寫的權限，然後部署惡意鏡像。
識別到威脅後對威脅進行幾個處理步驟：
- 標記詳情，附加參考材料、變更記錄；
- 威脅影響級別：從機密性、完整性、可用性，利用難度四個角度進行評估。衡量風險沒有必要強制按照DREAD、CVSS評分模型，很大程度依賴於參與的安全專家對攻擊者的視角、安全建設的成熟度、業務的可接受能力進行定級，一般給出高中低即可。
3.3 處理威脅是重中之重
經過上述的活動，我們獲取了一個大的威脅列表，下一步就是處置評估出來的每個風險，這方面的材料可以參考ISO27001和ISO31000的系列指導。分爲四個應對措施。
緩解
採取措施加大攻擊者的利用時間。就像Google Project Zero的原則“Make 0-Day Hard”。比如發現密碼猜解的威脅，採用二次認證、風控驗證碼的技術，緩解和解決風險的界限往往並不清晰。仔細想想大部分的日常安全工作都是緩解威脅，比如部署WAF、制定安全規章制度、監控和響應。
解決
完全解決該威脅。解決是最樂觀的情況，常見的安全方案是基於現有的代碼實現，比如防SQL注入組件，使用加密套件解決硬編碼問題。如果威脅建模是發生在編碼之前，可以使用現有的安全方案如Security SDK、密鑰管理服務、身份認證方案，當然也可以引用新的安全技術去建設。
轉移
轉移是將威脅承擔交由其他系統去處理，比如用戶協議和隱私條款、免責聲明，變更管理的二次認證、外包、購買網絡安全保險。但是安全也不能對業務給個方案說你得買一份保險，這需要找到安全和業務的平衡感。
接受
接受風險也是面對安全成本的一個合理處理方式，不同層級的業務負責人對待安全的視角是有不同考慮的。比如在物理安全領域，我們往往做得適度投入，背後的原因是接受了戰爭、核武器等不可抗拒因素。
依據上述的威脅定義補充是等級、優先級、修復成本、負責人、排期、安全測試結果、解決方案記錄結果，報告文字要規範，避免使用安全特定術語、縮略語如PoC、RCE、SSRF、HIDS字樣。給出前瞻性的安全方案是區分安全測試和威脅建模的主要區別。對於共性問題建立孵化安全解決方案，有安全專項的也進行標記，後續可以比對安全項目的效果。
解決威脅的抽象原則要區分出安全建設的原則縱深防禦、最小權限原則、默認（強制）安全並不一定適用於業務系統，業務更熟悉安全架構設計的5A原則：
- 身份認證（Authentication）：用戶主體是誰？
- 授權（Authorization）：授予某些用戶主體允許或拒絕訪問客體的權限。
- 訪問控制（Acccess Control）：控制措施以及是否放行的執行者。
- 可審計（Auditable）：形成可供追溯的操作日誌。
- 資產保護（Asset Protection）：資產的保密性、完整性、可用性保障。
5A的劃分容易讓業務理解到開發架構、邏輯架構、數據架構、技術架構、業務架構中，從而避免因爲安全緩解措施的影響導致原本的業務需求不能實現，或者性能、編碼、成本變更得太多。
完成威脅建模的標誌是雙方團隊對圖表沒有異議，可以依據數據流圖，複述清楚數據流向、攻擊面如何、已經做了什麼、存在哪些風險、應該做到什麼。讓業務沒有安全知識的提升的建模是失敗的，業務方應當是下一個產品迭代中安全提升的主動貢獻者。
以下是威脅列表的結果示例模板：
3.4 驗證威脅達到閉環
修復問題就是安全團隊複查威脅得到合理的處置，高標準就是合理。跟蹤威脅的解決不要拘泥於使用的安全內部的工單系統，在業務的研發管理系統記錄也是一個明智的選擇。同業務方制定單雙週的溝通會，確保每個風險在跟進按時解決。威脅建模並不是一次性活動，每次雙週溝通都簡短溝通，花5-10分鐘再一次實施建模：溝通下遇到什麼困難，有什麼安全需求，積累建模的習慣，通過反覆執行這個活動可以從設計層面識別大量的安全風險。
我們總是提安全要Shift Left（左移），建模給了產品團隊良好的“右移”機會。團隊之間的知識共享幫助大家理解安全的本質，知道安全這件事該如何做，從而逐步改善公司的安全狀況。Security by Design要求安全前置介入到需求和設計階段，真正讓介入需求階段，安全又總是無從下手，其實需求階段的安全活動包括用例驗證、資產識別、安全基線，將權限、日誌、操作安全、加密需求、編碼規範、基礎服務納入安全相關基線，設計階段主要有方案評審、安全特性設計，最重要的更是威脅建模。團隊互動的過程要以文檔的形式完整記錄，這種材料是給其他團隊下一次威脅建模的有效輸入。
4 如何評價這件事做得好壞
威脅建模不能立竿見影，建模沒有什麼特別的，對於業務方來說應該是同編碼、測試、交付一樣很普通的工作，安全也僅僅是日常工作的一部分。事情的主要目標是建立產品的安全屬性，可以通過最終的安全缺陷改進情況、評審覆蓋度、修復解決率作爲過程指標，安全成熟度、安全事故數作爲結果指標。實施投入威脅建模本身已經是一件技能很複雜的事情了，對參與人員引導做正確的事，不需要設置發現威脅數等硬性指標。
威脅建模在於對評估可能的風險、分析潛在攻擊者的手法、攻擊路徑，提升產品的抗攻擊韌性方面有獨特的優勢。這項方法論根本沒有什麼最佳實踐，沒有單一的“最好”或執行威脅建模的“正確”方法，而是爲了滿足解決這些威脅而實施的一系列複雜和多維度的權衡，唯有不斷修正迭代才能完善。但如果沒有威脅建模過程參與，組織不會清楚現有系統的安全現狀。不管怎樣，一旦你取得階段性的成果，組織內部就認識到這樣的協作可以對改善總體安全狀況產生較大的作用，是高性價的投入，就可以克服關於威脅建模耗費人力、週期長、難點大這些阻力的聲音，從而真正從事預防性的安全建設。
5 經驗教訓
美團內部實施威脅建模時，首先就設立了如下的目標：
- 覆蓋基礎設施相對重要的公共組件服務和重要管理平臺；
- 形成一套可複用的安全評審流程，知識庫和工具；
- 及時發現公司管理平臺的運營安全類風險，排期止損加固。
通過制定的威脅建模計劃同業務部門深入開展合作，團隊完成了數十個項目的評估，發現了數百個高危設計缺陷，從而試圖解決兩類核心問題：①人爲操作導致的安全風險；②安全融入基礎架構。識別提煉出孵化出特權賬戶管理平臺、服務鑑權、執行沙箱、全程票據、安全知識庫等安全子項目。當然建模的效果有好有壞，我們仍需學習、調整、迭代。我們總結了如下的經驗教訓：
- 關注真實的威脅，從技術威脅入手延伸到業務威脅；
- 安全沒有“銀彈”，使用其他應用安全措施補充威脅建模；
- 見木不見林，致力於高效的建模，而不糾結於細節；
- 關注安全的溝通協作，改善研發解決安全問題的思維方式，勝於投入精力在安全測試。
業界關於威脅建模的實施方法論在物聯網、機器學習、Serverless場景依舊很有生命力，說明在軟件工程領域這會是識別威脅真正有效的辦法。相信Threat Modeling Application 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
閱讀美團技術團隊更多技術文章合集
前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試
| 在公衆號菜單欄對話框回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
