開發人員威脅建模指南

從技術開始

第一個建議是至少一開始主要關注技術威脅，而不是廣泛的威脅。

• 廣泛的威脅和威脅來源包括駭客組織、惡意行為者、心懷不滿的員工、人為錯誤或新蠕蟲式惡意軟體的流行。這些類型的成因來自廣闊的世界，而且極其多樣、不確定和不可預測。它們與系統數據和服務對組織和其他人而言的價值有關。這些是與非技術人員容易談論的戲劇性風險。
• 技術威脅和漏洞的顆粒度更高，例如軟體中的特定弱點或缺少加密或授權等安全控制。這些類型的威脅源自於您的團隊正在建構的系統中固有的結構和資料流。通常，許多技術威脅會結合在一起，讓廣泛的威脅影響您的系統。

透過遵循本指南，您將主要專注於找出技術威脅。這有助於簡化闡述流程，因為系統的結構和資料流是您能確定的。但這也表示您可以從您作為軟體開發人員的既有優勢開始，了解技術方面。這是比您可能不太了解的威脅來源的高階風險分析更強而有力的基礎。

不過，別完全忘記整體情況。務實且基於風險地了解哪些廣泛的威脅是可能的，有助於將一個技術威脅優先於另一個。例如，單純的人為錯誤通常比國家攻擊更可能發生（請參閱側欄）。這種思考方式可以納入選擇要先檢查哪個安全範圍。當您先專注於找出技術威脅時，就能更容易將它們與更廣泛的威脅關聯起來，為修正和額外控制提供依據。

採取協作方式

第二個建議是採用協作的團隊導向方法。找出安全需求並不容易，而觀點的多元化將有助於做出更好的決策。總是有另一個漏洞或技術威脅需要找出，因此為演練帶來各種觀點，能讓集思廣益更穩健。這也會增加您找出最重要威脅的可能性。在小組中進行威脅建模有助於全面性地處理風險，並幫助整個團隊學習如何有效地思考和討論安全性。

從風險管理的角度來看，讓產品負責人參與進來是一個絕佳的機會。產品負責人對用戶行為和業務背景有深入的了解，而軟體開發人員根本沒有。他們應該了解特定服務對業務的價值，以及如果數據被洩露或丟失會產生什麼影響。當發生網路安全損失時，它們就是業務損失。如果最壞的情況發生，那麼原因很可能是你的組織和所使用的技術所特有的。網路安全問題不僅僅是勾選技術框，還包括做出良好的投資決策來保護業務。

威脅建模「少量且頻繁」

第三個建議是「經常少量」地開始威脅建模。與團隊的每次威脅建模會議都應該簡短且專注，以便快速消化成可以交付的東西。從分析系統中最薄的部分開始；僅分析你現在正在處理的部分。不要試圖預先分析整個系統，而是讓你的團隊逐漸建立威脅建模的肌肉記憶。

需要完全指定軟體設計的實務與敏捷團隊的工作方式不符。沒有理由威脅建模需要是詳盡的預先分析。團隊經常被威脅建模的全面且高度結構化的方法所淹沒[1]。我見過團隊嘗試這種方法，在發現任何真實威脅之前就耗盡了時間和耐心，更不用說交付修復了！

不要建立和維護詳盡的「威脅模型」文件，而要「經常少量」地進行威脅建模。當你這樣工作時，每次威脅建模會議都很小，影響很小。然而，這樣做的累積效應卻很大。當你知道你將在每次迭代中再次執行此操作時，嘗試一次性完成所有工作的誘因就會減少，而優先考慮當前最重要的工作的誘因就會增加。

三個關鍵問題

了解威脅建模會議的簡單結構，並做一些規劃，對於獲得良好的結果大有幫助。

要介紹的第一件事是威脅建模的簡單且靈活的結構[2]。這基於三個關鍵問題。它有助於將此結構記在腦海中。無論何時需要評估威脅，你都可以使用這三個問題結構作為指南。就像騎自行車一樣，一旦你掌握了基礎知識，你就可以應用和培養這些技能。

本指南遵循三個問題結構。在每個威脅建模會議中，您應花費約三分之一的時間回答每個問題。然後，您將得到有用的結果。本指南的其餘部分將把此基本結構分解為更詳細的步驟、指標和說明，以幫助您執行成功的威脅建模會議。

實際考量

在執行威脅建模會議之前，您需要先了解一些事項。下列指標應有助於您進行規劃。

面對面舉行會議與遠程舉行會議

面對面的威脅建模會議可以在會議室舉行，或者如果空間足夠，也可以在團隊的正常工作區域中較為非正式地舉行。典型的會議包括繪製圖表以說明和探討範圍、集思廣益威脅，然後優先處理待處理事項的修復。然而，面對面的會議並不總是可行的。

當你遠程舉行會議時，你只需要稍作不同的計畫，以便每個人都能虛擬參與。你需要視訊會議和協作工具。事先同意並設定這些工具。Thoughtworks 的團隊成功使用了各種工具，包括 Mural、Miro、Google Jamboard 和 Google Docs。

在會議之前熟悉你的工具，並讓參與者測試他們是否有權限。無論你選擇哪個工具，請確保你已獲得組織的安全核准來使用該工具。威脅建模輸出代表著敏感資訊，基於多種原因，必須受到保護。

以下是遠程工作時需要記住的一些其他事項

• 在練習之前非同步建立圖表可能會有幫助。這是因為在虛擬白板上繪製圖表可能會花費大量時間。
• 更注意建立對用於說明系統的概念和符號的共識。說明圖表符號、資料流箭頭和數位便利貼的顏色。
• 更用心確保每個人都參與練習。或許使用一些與安全性相關的腦筋急轉彎作為破冰方式。參閱遠端促進的更廣泛指南。
• 如果您有一大群人，將他們分成小組再合併產出可能是個好主意。幾個小場次會比一場大型場次更好、更能持續。
• 您將需要比面對面場次更多的休息時間。遠端工作很累人。

無論您的場次是遠端或面對面，您都應該準時結束。並有一些具體成果！這需要紀律 - 促進時程可以由交付經理或某個有經驗的人擔任，確保工作坊場次成功。

Thoughtworks Germany 的 Mona Fenzl 和 Sarah Schmid 使用一種稱為 Mural 的協作工具獲得了一些成功。他們使用它來建立威脅建模範本，以幫助其他團隊開始使用該工具。

界定會議範圍

決定場次的正確重點和詳細程度稱為「識別範圍」。在讓大家聚在一起執行活動之前，請務必決定好這一點。以目前最有價值的事物為指導。或許只是您在此次迭代中處理的使用案例？

不要一次嘗試涵蓋太多範圍！如果您嘗試一次威脅建模整個系統，您將在可用時間內找不到任何結果，或者您將大幅超時，而且沒有意願或預算再次執行。將威脅建模分為可管理的區塊，經常「少量多次」執行活動會好得多。

以下是一些效果良好的範圍範例

• 當前迭代中的範圍。
• 即將推出的安全性敏感功能，例如新的使用者註冊流程。
• 持續交付管道和交付基礎架構。
• 特定微服務及其協作服務
• 系統的高階概觀，以識別安全技術債務。

無論您的團隊選擇什麼範圍，請確保它不會太大，無法在可用時間內涵蓋。

範例：範圍

本指南的其餘部分使用實際功能來顯示威脅建模中涉及的具體步驟。一家零售組織有一個開發團隊正在建立一個平台，用於銷售送貨到府的食品雜貨。以下是他們在即將到來的衝刺中擁有的史詩

作為客戶，我需要一個頁面讓我可以看到我的客戶詳細資料，這樣我才能確認它們是正確的

如果你曾經使用過線上商店，你就能想像一個用來更新地址詳細資料，或許還能查看忠誠卡餘額的頁面。

根據經驗，這個大小的功能對於威脅建模會議來說是一個相當合理的範圍。

繪製「低保真」技術圖表

畫一張圖讓每個人都在同一頁面上。在開始思考威脅、風險和緩解措施之前，你需要對你正在處理的軟體或基礎設施有一個共同的技術理解。

一個範例：低保真度圖表

回到上面介紹的真實功能，讓我們看看團隊如何選擇說明新的「客戶詳細資料頁面」功能。他們繪製了以下圖表。

它說明了對系統的理解

• 基於微服務架構
• 已經有一個身份提供者，允許客戶進行驗證。
• 有一個用於客戶詳細資料的後端服務（使用 Java 編寫）
• 具有後端服務 (BFF) 和前端 UI（使用 Javascript 和 React 編寫）
• 有身為客戶的使用者，且想要編輯其個人資料

不需要對這些技術有詳細的了解即可遵循本指南，但這些事實說明了在繪製圖表時應討論的詳細程度。

顯示資料流向

加入詳細資料以顯示資料如何在系統中流動非常重要。

一個實際範例：顯示資料流

在我們的案例中，加入箭頭來說明資料流，從想要查看其詳細資料的客戶，到 UI，然後到 BFF 服務，再到客戶詳細資料資源伺服器以取得或更新資料。還有一個資料流到身分伺服器，該伺服器會發出授權階段的權杖。

由於使用者介面在網際網路上，而其他元件在組織的雲端主機中，因此也有一個授權界線。

實際範例：顯示你的資產

團隊將客戶服務儲存的個人可識別資訊 (PII) 和身分提供者中憑證儲存庫識別為具有最高商業價值的資產。

使用 STRIDE 協助

如果你的團隊開始進行威脅建模，STRIDE 是完美的選擇。STRIDE 是一個非常輕量的架構，可以讓你開始集思廣益安全威脅。它是一個助記符，每個字母都代表一個安全概念。重點不在於分類你發現的內容，而是幫助你有效地集思廣益。

在開始之前，花一些時間與團隊了解和討論六個安全概念。為了幫助學習，Thoughtworks 建立了一組 STRIDE 提示卡。這六張卡片連結在正下方。它們的反面也包含範例清單。

在網際網路上，沒有人知道你是一隻狗

資料會不會溢位並變成指令？

如果沒有證據，很容易否認它曾經發生

還有誰可能會在尋找？

服務會不會被關閉？

繞過防護措施有多容易？

邪惡集思廣益

想出攻擊、破壞或阻礙特定軟體的方法就是威脅建模的精髓。它也可以非常有趣！

實際範例：已識別的威脅

使用先前建立的圖表，團隊使用 STRIDE 協助集思廣益系統中的每個資料流程。

當我們在軟體機制中發現潛在威脅時，請將它們寫在便利貼上並註解在低保真度圖表中。

以下是他們在集思廣益部分的會議結束時提出的內容

資料流程

威脅

客戶→身分服務

• 驗證基於密碼，沒有兩階段驗證

客戶→使用者介面

• 基於 DOM 的跨網站指令碼 (XSS) 攻擊

使用者介面→後端服務

• 身分驗證令牌驗證不存在或很弱
• 注入攻擊，例如 SQL 注入、儲存的 XSS
• 缺乏呼叫者身分記錄
• TLS 傳輸加密設定錯誤
• 生產環境中啟用設定錯誤的 graphQL 內省
• 來自殭屍網路的網路層流量洪水
• 無法防止經過驗證的使用者存取其他人的詳細資料
• 缺乏定期修補程式可能會導致遠端程式碼執行

後端服務→客戶服務

• 「伺服器到伺服器」驗證不存在或很弱
• 缺乏呼叫者身分記錄
• 過於寬鬆的安全群組允許從網際網路存取客戶服務
• 無法防止經過驗證的使用者存取其他人的詳細資料

請注意，許多威脅發生在資料流程從網際網路跨越授權邊界進入系統時。然而，瀏覽器為基礎的使用者介面和後端網路中也已識別出威脅。

根據風險優先處理威脅

i. 分享有助於優先順序的知識

它有助於對我們對系統風險概況的了解達成共識。花費不超過 5 分鐘即可完成。大致而言，在優先處理威脅時，有兩種知識類型會有所幫助。產品所有人或安全團隊通常有極佳的見解可以分享。

• 商業價值 - 哪種損失會讓組織的目標面臨危險？是客戶資料庫被竊嗎？由於業務損失而造成的聲譽影響嗎？
• 更廣泛的威脅 - 對於這個組織而言，由於網路安全問題而導致損失的可能根本原因是什麼？我們擔心的是詐騙嗎？惡意內部人員嗎？特別有能力的黑客嗎？

如果小組中沒有人對更廣泛的風險有任何見解，那也沒關係。存取此知識並非先決條件。您可以僅根據技術風險進行優先順序排序，並仍然從威脅建模中獲得極大的好處。

ii. 每個人都投票選出風險最高的威脅！

對於之前在回顧或工作坊中進行過「點狀投票」的任何人來說，這應該很熟悉。每個人都會獲得一些選票，並將其投給風險最高的威脅。第一次會議時，或許可以從每人三票開始。但這取決於小組中有多少人，以及您發現了多少威脅。目標是逐步縮小範圍，找出最有價值的威脅。請記住，風險不僅與威脅的可能性有關，還與潛在損失的規模有關。

根據自己對風險的認知，每個人都使用點狀投票。

每個人都需要在便利貼上標記點狀投票。每個人都會獲得固定數量的選票。如果您認為這樣做是正確的，在同一個威脅上投票多次是可以的。

以這種方式投票將為低投資帶來良好的風險決策，反映小組中不同的觀點。人們對風險有直覺，並且能夠在最少的提示下投票。

iii. 找出風險最高的威脅

您需要計算每個威脅的得票數，並以某種方式標記得票數最高的威脅。或許可以用筆圈出風險最高的威脅。

我經常被問到我們應該在一個會議中找出多少威脅。第一次時，三個會是一個不錯的數字。這為投資的時間提供了良好的平衡。但請運用您的判斷力和進行實驗。可能有一項非常有風險的項目 - 現在解決該項目的時機恰到好處。同樣地，一個會議中可能會出現四或五個威脅。

iv. 拍攝註解圖表的相片，並記錄威脅

在此階段使用手機相機拍照，以捕捉腦力激盪和優先順序的輸出。如果您使用遠端工具，則可以截取螢幕畫面或匯出。將影像上傳到您的 Wiki 或將其儲存在某處的儲存庫中非常有意義。

將修正新增至待辦事項清單

團隊的投入時間對於後續工作至關重要。軟體團隊已經具備一種強大的方式來表示和排序活動以交付軟體：積壓工作。現在是時候找出您實際上需要哪些修正來降低風險。使用團隊現有的流程和工作方式來支援這一點（請參閱側欄）。

反思並持續改進

回饋和持續改進是風險管理的核心。正如我在本指南開頭所強調的，我們建構的系統和它們所面臨的威脅都不是簡單的。而且每個團隊都不同，具有不同的技能、工具、限制和個性。威脅建模沒有單一的方法，本指南僅提供一些基礎知識讓您入門。就像測試驅動開發或持續傳遞一樣，威脅建模會帶來投資回報。

一旦執行了一些會議，改善方法之一就是對威脅建模工作進行回顧。詢問哪些地方進行得很好，哪些地方可以改進。時機是否正確？範圍是否過於詳細？不夠詳細？您使用的位置或遠端工具如何？會議後出現了哪些問題？範圍需要多長時間才能傳遞？透過詢問這些問題，團隊將會適應並隨著時間建立精通，加倍努力於有效的工作，並捨棄價值不大的工作。

隨著時間推移，您可以發展出最適合您的團隊或組織的最佳實務。以下僅提供一些後續步驟的想法

• 嘗試使用不同類型的圖表。對於 OAUTH2 驗證流程之類的東西，UML 順序圖可能比簡單的元件圖更好。
• 使用特定於網域的威脅函式庫。有許多資源可以幫助您集思廣益威脅。OWASP 有一些關於行動裝置或 API 的絕佳資源。最近對使用 ATT&CK 架構產生了濃厚的興趣。
• 沒有萬靈丹。威脅建模並非找出基本編碼或依賴關係問題的有效方法。在軟體傳遞管線中使用自動化工具來補充威脅建模。
• 就像軟體中的其他所有事物一樣，如果不進行測試，就無法認為它已完成。使用威脅建模來找出要測試的失敗條件。
• 針對系統的風險概況執行一個階段。這種分析通常著重於您正在處理的資料類型以及您的服務對他人的價值，在安全術語中，深入探討您「資產」的商業價值。
• 針對您的系統執行一個階段，以找出更廣泛的威脅。根據最佳可用資訊（例如威脅情報、實際攻擊技術的文件和類似系統的實際事件）來分析潛在攻擊者的能力和動機是很常見的。
• 加入威脅建模社群，例如 OWASP Slack 上的威脅建模頻道，或關注威脅建模 SubReddit。在 Twitter 上關注其他從事威脅建模的人。

結論

安全中的許多「解決方案」似乎旨在讓開發人員遠離安全。這並不表示它們是糟糕的解決方案。管線中的自動化檢查對於找出漏洞非常有效，您應該使用它們。滲透測試可以找出您自己無法發現的問題。具有安全預設值的平台可以消除許多常見威脅。然而，每個「解決方案」只針對有限類型的威脅。雖然網路風險並非簡單的事物，但它具有多面性且不斷變化。了解此風險是有效管理風險方法的核心。

威脅建模的殺手級應用程式是促進整個團隊對安全的了解。這是讓安全成為人人有責的第一步。就像業務成果、品質、整合和基礎架構一樣，安全可以成為團隊思考軟體傳遞方式的核心。而不是在最後才加上去。根據我的經驗，具備威脅建模肌肉記憶的團隊是一個主動管理網路風險的團隊。

我記得有人告訴我，威脅建模對大多數開發團隊來說太難了。我根本不願意接受這種說法。我了解如何改善開發人員處理安全的方法。從那時起，我幫助許多團隊開始使用威脅建模，並踏上正確了解安全的旅程。我從未遇過認為威脅建模或安全太難的團隊。特別是當以平易近人的方式解釋時。這正是我試圖在本指南中所做的。

我相信威脅建模是軟體開發團隊的一種變革性實務。一種協作且基於風險的實務，可以持續應用。如果您是軟體團隊的一員，請將本文寄給您的團隊，並建議進行威脅建模階段。或轉發給貴組織負責軟體安全的任何人。透過撥出一些時間來執行一個階段，您可以開始著手進行。透過開始了解系統所需的威脅、風險和安全修復，您正在朝著有效的網路安全邁進一步。

我希望本指南能幫助您的團隊開始威脅建模。至少一個階段應該可以立即提供價值，並將良好的安全故事和驗收標準新增到您的待辦事項中。此方法已幫助 Thoughtworks 客戶的許多開發團隊採用全面的網路安全方法。我希望對您也有幫助。