實踐以後，咱們來談談如何作好威脅建模

時間 2021-04-10

標籤 html 前端 git github 算法數據庫後端安全服務器網絡欄目 HTML 简体版

原文原文鏈接

1 寫在前面

1.1 什麼是威脅建模

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

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

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

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

威脅建模數十年來不斷取得你們的承認，在業內也有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 經驗教訓

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

覆蓋基礎設施相對重要的公共組件服務和重要管理平臺；
造成一套可複用的安全評審流程，知識庫和工具；
及時發現公司管理平臺的運營安全類風險，排期止損加固。

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