這篇文章由西蒙妮·柯齊、安東尼·內維科、喬納森·大衛斯、拉斐爾·帕佐斯·羅德裡格斯和本·漢森撰寫
簡介
威脅模型化是一個重要的安全性方法，可協助識別及設定應用程式或系統最重要的風險風險降低優先順序。 本文包含一些反思，關於如何更有效率且更有效地採用威脅模型、將其與現代 DevOps 方法和工具進行整合，並專注於提供給所有相關軟體開發生命週期的各個角色的價值。
這份論文適合您嗎？
本文是來自Microsoft的一小組安全性和威脅模型化專家的工作結果，並納入了一些來自外部Microsoft最傑出的專家的意見和想法。 它會嘗試解決簡單但緊迫的問題：我們應該怎麼做，以確保我們所使用的威脅模型化程式已更新為敏捷式方法和 DevOps 所強加的新式需求，以便以最低成本提供所需的值？
如果您是產品擁有者、安全性小組的成員，或只是考慮採用威脅模型化作為開發生命週期一部分的開發人員，本文件適合您。
同樣地，如果您已經採用威脅模型化，您仍然可以找到實際的想法來改善您的程式。
不過，本文旨在介紹改善目前程式的想法，或成功採用威脅模型化作為 DevOps 程式的一部分。 它不會介紹特定的工具或產品，即使我們希望在未來看到某些工具或產品所實作的想法。 因此，您在這裡不會找到新工具或即將推出的功能的預覽公告。
為什麼威脅模型化很重要？
威脅模型化是安全地設計軟體解決方案的主要方法之一。 透過威脅模型化，您可以分析系統識別攻擊媒介，並開發動作以減輕這些攻擊帶來的風險。 如果適當執行，威脅建模是任何風險管理過程中的重要部分。 它也可以藉由儘早找出並修正設計問題來協助降低成本。 NIST 的一項舊研究估計，在生產程式代碼中修復設計問題的成本約為在設計階段修復的 40 倍。 它還有助於節省由於涉及設計問題的安全性事件而可能產生的成本。 請考慮由 IBM Security 和 Ponemon 研究所發布的《2022年資料外洩成本報告》估計，資料外洩的平均成本為 435 萬美元。 對於所謂的「巨型資料外洩事件」，涉及超過5000萬筆記錄的外洩，平均成本達到3.87億美元！
威脅模型化是您可以執行以保護解決方案的第一個活動，因為它在解決方案設計上運作。 此特性可讓您套用至 SDLC 的最有效安全性做法。
Microsoft具有長期的威脅模型化歷程記錄。 1999年，兩位（當時）Microsoft員工洛倫·科恩費爾德和普拉裡特·加格寫了一份檔《 對產品的威脅》。 本文介紹 STRIDE 方法，這是Microsoft威脅模型化程式的同義字。
威脅模型化是進化的過程
威脅模型化不是靜態程式;它會隨著需求和技術的變化而發展。
最近針對 SolarWinds 的供應鏈攻擊展示出，威脅建模需要涵蓋的不僅僅是解決方案本身，還應包括開發和部署等更多情境。
像最近的 Log4j 一樣，開放原始碼的弱點已經顯示出需要在現有方法之外，補充採用軟體組成分析工具來掃描易受攻擊的元件，並透過防禦性設計來限制其暴露。
新技術的應用，如機器學習引入了必須理解與控制的新攻擊向量。 例如，請考慮在對人耳而言無法聽見的情況下播放惡意設計的聲音，以導致 AI 服務執行命令的可能性，如所討論。
在Microsoft，不同的產品群組會根據其特定安全性需求來練習不同的威脅模型化變體。 每個變體都旨在保證將適當的安全性保證層級應用於情境中，但「適當」的意義會根據具體情境而有所變化。
例如，保護 Windows 與保護 Azure Cognitive Services 不同，因為這兩者的系統大小與特性差異很大。 威脅模型化的主要層面是平衡其成本與應用程式的風險承受能力。 雖然在某些情況下，這可能會導致完全避免使用威脅模型的決策，但當正確實施時，其效果非常顯著，因此我們強烈建議在任何IT計劃中採用，無論是軟體開發或基礎設施部署專案。
專注於 ROI 的重要性
過去幾年來，威脅模型化的興趣穩步增加，成為重要的軟體開發程式。 這種關注是因為對基礎設施和解決方案的攻擊呈指數級增加。 引領潮流的計劃，如 NIST 推薦的廠商或開發者驗證程式代碼最低標準 和 威脅模型宣言，進一步增加了需求，已使目前的方法顯示出一些局限。 例如，威脅模型化的結果高度相依於採用的程式，以及執行威脅模型的人員。 因此，人們擔心能否從體驗中獲得穩定且更高的品質。
但是，品質對威脅模型有何意義？ 對我們來說，質量威脅模型必須具有下列特性：
它必須識別可採取動作的風險降低措施，您可以進行的活動，以減少因攻擊所造成的潛在損失。 可採取動作表示必須妥善定義這些風險降低措施，這表示您可以取得足夠的資訊來實作它們，然後測試實作。 這也表示必須提供這些資源，以便開發團隊可以輕鬆取用。 使用 DevOps 和 Agile 時，這表示有一個簡單的途徑，可將補救措施匯入待辦清單。
針對每個緩解措施，它必須識別其狀態。 有些風險降低功能是新的，有些則已存在。 威脅模型必須辨識已經存在的內容，並專注於目前的風險，以識別如何改善情況。
必須清楚地說明為何需要每個緩解措施，並將它們與相應的威脅連結起來。
此外，緩解措施對於每個威脅都有相對效果。 例如，TLS 加密可能是對於在傳輸中數據遭泄露的強效緩解措施，同時，它幾乎可以完全緩解伺服器被偽裝的風險。
威脅必須可信、妥善定義，且專屬於解決方案。
威脅必須具有相關聯的嚴重性，這應該同時考慮其機率和影響。 嚴重性必須合理且理想情況下不偏不倚。
應該能夠全面了解風險，以及如何解決風險。 這種觀點有助於推動與安全性小組和商務決策者進行有意義的對話，並讓我們隱藏不必要的複雜性。
這份清單已經顯示重要概念：威脅模型化可為軟體生命周期期間涉及的許多角色提供價值，但每個角色都有不同的需求和需求。 例如，開發人員必須接收到有關他們需要實施的內容以及如何確認其實施行為符合預期的清楚資訊。 另一方面，安全性小組通常與組織所擁有基礎結構和應用程式生態系統的整體安全性有關：因此，他們需要接收資訊，以決定範圍中的系統是否足夠安全，並滿足其合規性需求。 最後，產品擁有者和商務決策者必須瞭解讓組織能夠接受風險的必要條件。
這類不同的需求需要針對威脅模型提供不同的檢視，每個檢視都著重於特定使用案例。
威脅建模的一個典型問題是，它越成功，少數可用的專家就越難以滿足需求，同時仍然保持這種經驗所期望的高品質。 因此，在某些情況下，品質可能會受到負面影響。 一切都很好，直到威脅模型化停止提供與投資相比的重要價值。 超過一些組織會受到此問題的影響。 已經有一些商務決策者的報告開始質疑威脅模型化，因為它無法為成本帶來重大價值。
透過價值，我們指的是商業價值，這是提供所需的資訊，以瞭解範圍內系統代表的風險，並推動有意義的決策流程，以選擇適當的風險降低措施進行實施。 此外，值也與提供正確的資訊給開發人員和測試人員有關。 最後，值與與所有相關方溝通剩餘風險有關。 例如，我們可以通過測量威脅建模過程的影響來評估其價值。 假設我們透過將每個威脅的嚴重性賦予一個分數來測量解決方案的整體風險。 在此情況下，我們預期整體風險會隨著威脅模型的每個影響而降低。 如果整體風險維持不變或增加，則可能有問題。 減少越急劇，威脅模型的影響就越大。 當然，威脅模型不會控制實作的風險降低措施。 決定必須實作哪些專案是產品擁有者的責任。 但是，將威脅模型的有效性與緩和措施的實際實作連結的優點是，它會增加對解決方案實際安全性的影響，降低威脅模型仍然是理論練習的風險。
相反地，成本與執行威脅模型本身所需的活動有關，這是所有參與方產生威脅模型並加以討論所需的時間。
這表示問題：我們是否可以定義以最大化商務價值並將成本降至最低的威脅模型化程式？
DevOps 的重要性
我們已經強調，務必確保威脅建模是一項寶貴的做法，需整合到 DevOps 過程中。 這表示程式必須可供所有小組成員使用，通常是透過簡化和自動化程式。 最重要的是，專注於DevOps的威脅模型化，表示我們需要確保體驗與現有的DevOps程式深入整合。
威脅模型化不應成為另一個負擔，而是應是一種資產，以利於安全性需求產生和收集、安全解決方案的設計、將活動納入所選的工作和 Bug 追蹤工具中，以及根據解決方案目前和未來狀態評估剩餘風險。
與 DevOps 對齊
我們可以使用各種技術來配合目前 DevOps 實務的威脅模型化。
威脅和風險降低
首先，我們必須將威脅模型化程式放在需要執行的工作上。 威脅是攻擊模式及其可能發生方式，必須說明小組為何需要實作安全性控制。 它們也是判斷何時應實作緩和措施的因素。 不過，真正的目標是判斷需要採取的緩解措施。 因此，此方法必須快速識別所需的風險降低措施，而且必須通知決策程式，以便更容易判斷該做什麼和何時執行。 此決策程式的主要交付專案是在待處理專案中選取風險降低措施，使其成為標準程式的一部分。 在理想情況下，應該同步處理威脅模型化工具和工作和錯誤追蹤工具，以反映威脅模型中風險降低狀態的更新。 這將允許動態和自動修訂剩餘風險，這對於支持明智的決策至關重要，作為採用敏捷式方法的一般活動的一部分，例如衝刺規劃會議。
你今天能做什麼？
身為威脅模型化專家，您應該確保實作威脅模型化程式，以清楚識別動作，並將其納入您選擇的工作和錯誤追蹤中。 其中一種方式可能是採用許多威脅模型化工具之一，以便將此程序自動化。
身為開發人員，您應該專注於已識別為必要的安全性控制件。 此流程應設計成以與您期望接收其他活動相同的方式提供相關資訊或內容給您。
功能、使用者故事和任務
我們已經指出，風險降低功能代表與 DevOps 整合相關的威脅模型所產生的最重要的成品。 因此，請務必清楚定義在所選工作和 Bug 追蹤工具上，從這些風險降低中建立的物件類型。 某些緩解措施可能會持續超過一個短衝程。 因此，最好將其建立為功能。 但許多都比較容易，而且可以在單一Sprint中實作，因此，可以將它們表示為使用者故事或工作。 雖然可能會產生不同的工作項目類型，但這可能會導致流程複雜，從而引發錯誤和混淆。 因此，堅持單一工作項目類型似乎更實用。 假設緩解措施可能會被視為使用者故事的子系，您可以考慮將其表示為任務，這意味著可以放寬在單一短衝中執行上述工作項目類型的需求。
你今天能做什麼？
請確定威脅模型所識別的風險降低措施會顯示在待辦專案中。 找出一種明確表示它們的方式。
使用者故事
威脅模型中的成品不僅僅是緩解措施。此外，威脅模型可能而且應該與您在任務與錯誤追蹤工具中擁有的項目保持一致。 例如，您可能也想要呈現威脅。 藉由將WITHOUT子句新增至一般「作為[我是誰]，我想[我想要的]，以便[執行某些動作]」來達成此目標。例如：「身為使用者，我想用信用卡付款，這樣我就可以購買一些商品，而不會讓我的信用卡資料被竊。 WITHOUT 子句可以對應到一或多個威脅，有時允許表達安全性需求。 藉由確保在威脅模型中明確地表達威脅與WITHOUT子句之間的這種一致性，我們可以確保小組會考慮並處理可能的風險，因為這些風險已包括在用戶故事中。 您也可以使用此關聯性，將作為用戶故事的一部分而識別出的每個安全條件對應至至少一個威脅。
好知道
WITHOUT 子句並不是製作此頁面的小組的原創想法。 我們不確定是誰首次介紹它，但我們感謝提出這個想法的人。
該圖表會將威脅與用戶故事對應起來，但不包含子句。
圖 1：對齊需求
例如，上圖顯示下列情況：
威脅 A 透過名為 WITHOUT 1 的子句連結到使用者故事 1。
威脅 B 透過子句「WITHOUT 2」連結到使用者故事 2。
威脅 B 也會連結到使用者故事 3。 但 User Story 3 未指派給任何 WITHOUT 子句。 為什麼？ 它代表您應該調查的潛在異常。
威脅 B 也會連結到使用者故事 1。 目前還不清楚我們是否應該允許將使用者故事連結到一個以上的威脅。
威脅 C 與用戶故事 4 相關聯，而用戶故事 4 又與 WITHOUT 3 和 WITHOUT 4 相關。 目前尚不清楚我們是否應該允許存在多個WITHOUT子句。
威脅 D 不會連結到任何使用者案例。 我們缺少用戶劇本或WITHOUT子句嗎？
User Story 5 已連結至 WITHOUT 子句，但它沒有相關聯的威脅。 我們是遺漏了一個威脅，還是只是使用者故事與威脅之間的連結？
我們很少將安全性需求識別為威脅模型的一部分。 因此，WITHOUT 子句引進了將威脅模型與安全性需求延伸，並將其與相關使用者案例連結，以進一步整合體驗的機會。 這種方法在將威脅建模體驗從需重複進行的評估演變成DevOps的安全設計工具方面，會扮演重要角色。
你今天能做什麼？
開始在您的使用者故事中使用WITHOUT子句。
將您識別出的威脅對應到具有WITHOUT子句的使用者故事，反之亦然。
整合式體驗
您可以將相同的想法套用至其他案例。 例如，威脅模型可以將安全性需求與威脅模型本身內的成品連結，例如威脅和風險降低，以及追蹤和錯誤追蹤工具中的成品。 例如，實作監視以識別進行中的攻擊的需求，應對應至與監視相關的所有風險降低措施，然後對應到Task & Bug Tracking 工具中的對應成品。 因此，很容易找出安全性需求未實現的情況：事實上，它不會與任何項目連結。
您可以使用 Task & Bug Tracking 工具中的工件與威脅模型所識別的威脅和減緩措施之間的相同連結，來促進安全活動的優先順序制定。 安全性通常最後實作，有時用來解決某些工具或滲透測試所識別的被動弱點。 相對而言，將緩解措施與相關的使用者故事或功能一起實施會最有效。 當您應該實作信用卡詳細數據以及相關的付款功能時，為什麼要等到實作控件來保護信用卡詳細數據？ 威脅模型應該醒目提示這些關聯性，並提供簡單的方法來判斷在短期衝刺期間實作某些功能時，需要實作一些相關的安全性功能。 例如，在短期衝刺規劃會議期間，這項資訊可用來進行有意義的討論，並推動明智的優先順序。 機制很簡單。 假設我們負責的專案的產品擁有者決定在下一次的短衝規劃一個使用者故事。 上述使用者故事有一個與威脅有聯繫的 WITHOUT 條款。 威脅模型會識別相同威脅的數個防護功能。 因此，我們可以立即推斷，我們應該優先處理一或多個已識別的風險降低措施。
此圖顯示威脅與風險降低之間的連結如何用來設定安全性優先順序。
圖 2：重設安全性優先順序
例如，在上圖中，我們可以看到使用者劇本 1 連結到威脅 1，而威脅 1 接著會連結到風險降低 A 和 B。因此，我們也應考慮實作其中一或兩種風險降低措施。
你今天能做什麼？
使用威脅模型作為參考，將具有WITHOUT子句的使用者故事連結至對應的所選風險降低措施的工作項目。 在規劃下一個 Sprint 時，請務必在實作包含 WITHOUT 子句的用戶故事時，優先處理相關的安全性活動。
整合功能以突出顯示未對齊之處
一旦開始思考如何連結構成威脅模型的成品與 Task & Bug Tracking 工具中的成品，就更容易識別改善兩者質量的機會。 關鍵是利用其關聯性來醒目提示差異，並利用其中一個中的資訊來補充、整合和解譯另一個中存在的資訊。 如上所述，您可以這麼做，而不會大幅影響小組的運作方式。 這是因為此方法依賴現有的資訊，並建立不同世界中各種對象之間的關聯性。 因此，威脅模型會成為解決方案安全性的真相來源。 同時，待辦事項會不斷與解決方案的狀態保持一致。
你今天能做什麼？
定期確認所有威脅和用戶故事中沒有出現 "WITHOUT" 子句的情況。
威脅建模與作業
所有這些想法主要著重於 DevOps 的開發端。 我們可以執行一些動作來改善作業嗎？ 我們確實這麼認為。 例如，您可以使用威脅模型化作為工具來輔助根本原因分析，因為它從安全性觀點提供系統的完整檢視，因此可以進一步瞭解某些攻擊的影響。 若要達成此目的，必須整合威脅模型與所選監視工具中現有的摘要。 這種方法可以作為選定的 SIEM 的補充。
將威脅模型化與 Operations 整合的另一個概念，是先使用前者來推動後者如何發生的設計。 其中一個範例是解決方案的事件設計。 威脅模型化可識別可能的攻擊，我們可以使用該知識來識別當這些攻擊失敗時，範圍中解決方案可能會引發的事件。 如果您進行嚴格的輸入驗證，惡意攻擊者在成功之前需要幾次嘗試。 一開始，嘗試會失敗，其中一個嘗試最終會成功。 藉由引發每個失敗的事件，並在達到某些閾值時觸發警示，您可以偵測攻擊並採取動作來補救它們。 如果您限制自己監視基礎結構，則很少偵測到這些情況。 因此，必須包含自定義事件，小組必須先設計和實作這些事件，SOC 才能運用它們。
此外，後者可能對解決方案知之甚少。 因此，SOC 可能無法判斷輸入驗證失敗時如何回應。 不幸的是，當數據外泄發生時，必須快速做出反應，以減少直接損害和最終罰款的機率和實體。
因此，我們需要事先規劃需要監視的專案、在哪些情況下可能會有問題，以及在何時發生時該怎麼做。 識別這些事件的最佳方式是依賴威脅模型。 因此，利用它來產生標準化成品，以引導和加速實作必要的設定，以推動監視和稽核，並協助事件回應。
你今天能做什麼？
主動使用威脅模型來識別您可以針對每個威脅引發的事件。 這些事件可能是由基礎結構提供，或應用程式必須引發的一些事件。 在您的待辦清單中納入工作項目，以確保這些事件得以實施。
請積極與您的營運與安全小組合作，包括 SOC 小組，確保透過事件提高警示並識別安全性事件。
對 ROI 的影響
您可能想知道為什麼這些技術可能會對威脅模型化ROI產生積極影響。 從我們的觀點來看，它們對於提高DevOps小組的威脅模型化價值至關重要。 我們反覆看到的問題是，這些小組認為安全性是一種成本，可提供有限的價值，而且需要許多無法預見的工作。 有時，目前還不清楚為什麼他們應該投入這麼多時間來修復安全性。 因此，安全性會成為問題，而不是成為機會。 威脅模型化有可能克服這些問題，因為它提供實作安全性的原因。 此外，它可以在開發過程的早期啟動，進而避免那些如果未被及時偵測出來可能會帶來高昂代價的設計錯誤。 上述技術旨在更好地整合威脅模型化與 DevOps。 這可確保商務決策者和開發人員將威脅模型化視為開發和作業程式的自然補充。 因此，採用威脅模型化所收到的值會增加，而且其成本會因為與已使用的各種工具整合而降低。
簡化威脅模型設計者的工作
改善威脅模型化 ROI 的另一個重要層面，與降低其成本並增加能夠交付的人員數目，同時維持更同質的品質等級有關。
许多努力試圖解決人才短缺的问题。 其中一些是以整個 DevOps 小組參與威脅模型化練習為基礎。 確認倡議的領導者，此人應該是對流程具有中級知識但不一定是專家，並讓她引導與其他團隊成員的討論。 這個方法由威脅模型化宣言的簽署者積極認可。
我們確實同意這種方法能夠取得良好的價值，並代表對目前情況的改善。 它也提供良好的見解，並讓小組能夠成長其安全性文化。 然而，它不是沒有缺點，因為它只涵蓋幾個問題，排除了很多。 這造成了一致性問題，因為很容易沉溺於次要問題，浪費寶貴的時間而忽略重要的問題。 領導人的經驗將在防止這些情況發生方面發揮重要作用。 此外，此方法需要所有小組成員花很多時間討論每個問題。
因此，即使在此練習中每短期衝刺花費數小時，也可能代表大量投資。 每個人都知道，大多數小組通常會浪費時間參加涉及每個人的大型會議，而那些威脅模型化會話不會例外。 不過，這種方法非常適合小型產品，小組包含少數資深成員。
不同的方法
根據先前方法的限制，我們偏好限制會議數目、其長度和參與者數目。 因此，威脅模型化工具的責任會更加重要：不僅要領導面試，還要建立和維護威脅模型本身。 這種方法需要更顯著的能力和專業知識。 威脅建模者可能由安全性擁護者或內部安全性團隊的成員代表。 大部分的組織會選擇第一個選項，因為安全性團隊通常行程已經排滿。
安全性擁護者是 DevOps 小組的成員，對安全性特別感興趣。 他們絕不是專家，但他們有基本知識，並願意改善小組的安全性狀態。 其概念是建立安全倡導者與內部安全性小組之間的密切連結，使安全倡導者能夠協助小組正確完成任務，同時內部安全性小組可以減輕工作負擔。 透過威脅模型化，安全性擁護者會充當威脅模型化者，而內部安全性小組將負責引導他們並檢閱其工作。
你今天能做什麼？
調查採用安全性擁護者計劃的可能性，並利用它進一步加強您的安全軟體開發生命週期。
知識庫 的角色
威脅模型化的重大問題在於確保無論誰執行威脅模型，體驗的品質和 DevOps 小組的價值都很高。 有了安全擁護者，這個問題變得更加緊迫。 解決此問題的想法是提供 知識庫 來推動建立威脅模型。 威脅模型化的知識庫是特定內容的相關信息套件：它們包含與該內容相關的實體定義、這些實體的可能攻擊模式，以及可套用的標準風險降低措施。 知識庫可讓組織取得更好且更一致的結果，因為它們代表以規範方式引導威脅模型工具的參考數據。 知識庫應該有規則，可讓我們自動將威脅和風險降低套用至系統。 此自動化可讓我們克服某些威脅模型化工具可能沒有判斷是否應套用威脅或某些風險降低是否有效所需的經驗。
知識庫不是新概念：許多目前的威脅模型化工具已以某種形式支持它們。 但許多目前的實作有顯著的缺點。 例如，您應該能夠輕鬆地維護 知識庫。 其可維護性是仍未解決的問題。 例如，識別用來建置資訊的最佳來源並不容易。 此外，維護通常是手動的。 建立和維護 知識庫 應該是組織內部安全性小組的責任。 我們希望公司能夠開始為最常見的威脅模型化工具提供 知識庫，以減輕客戶未來的一些負擔。 這些 知識庫 應具有彈性，即使最成熟的組織也需要調整上述 知識庫，才能支持和促進其採用。
你今天能做什麼？
請考慮將集中式安全性小組用於開發 知識庫 的一部分的可能性，這些 知識庫 可供各種開發小組用來加速威脅模型化。
取用 知識庫
知識庫 的另一個問題是，有時它們太複雜而無法取用。 其中許多人試圖通過包括基本和較不重要的問題來全面。 不幸的是，並非所有系統都需要它們。 當您分析的系統很小且不會處理敏感數據時，您會想要採用更簡單的方法。 相反地，如果系統很複雜，且處理 PII 和高商務價值數據，您會想要更深入。 因此，視內容而定，應該可以套用不同版本的知識，或將某些攻擊模式和相關聯的風險降低標示為「TOP」。 如此一來，威脅模型化工具就能夠決定他們是否想要全面體驗，或輕鬆輕鬆，並將所需的工作降到最低。
說起效率，請務必確保盡可能簡化和自動化活動，以減少所需的工作量。 我們認為，對於中等規模解決方案進行威脅建模，對威脅建模師來說工作量應該是1天。 只有在選擇的工具提供加速器以允許削減所需的時間時，才能產生這類結果。 例如，如果工具在 100 個不同位置套用 20 種不同類型的風險降低功能，而且系統會要求針對其中每一種風險降低類型指定其狀態，則專注於第一個，而不是後者會更有效率 5 倍。 選擇的工具應該提供這項功能，同時仍授與在必要時執行更徹底的工作的可能性。
你今天能做什麼？
如果您目前使用的知識庫不支援「TOP」威脅和緩解措施的概念，請考慮移除很少必要或有用的項目的可能性，以便更好地專注於真正重要的事項。
有時候問題在於採用的 知識庫 會嘗試為泛型，並涵蓋多個案例。 您可以透過使它們更加專業化來改善情況。
詢問正確的問題
在分析期間，我們已考慮使用工具來支援問題架構，以推動分析的第一個階段。 我們注意到，大多數缺乏經驗的威脅模型工具無法詢問正確的問題，以取得其分析所需的資訊。 我們的一些專家已經證明，可以根據範圍內的系統圖表來判斷一些關鍵問題。 這些問題甚至可以根據某些生成規則自動地套用。 問題是，這種方法可能不會提供它似乎承諾的價值。 這是因為您需要瞭解每個問題背後的理由。 否則，您將無法評估答案，並判斷其是否令人滿意。 不過，自動化問題生成可能會為較不專業的威脅模型師提供顯著價值，以改善他們對在研究範圍內系統的瞭解。
你今天能做什麼？
採用結構化方法來詢問問題。 例如，我們的小組藉由採用Microsoft STRIDE 作為參考，取得了良好的結果。 您可以藉由詢問解決方案問題的每個元件來執行此動作，例如：
假冒：元件如何向其使用的服務和資源進行認證？
竄改：元件會驗證收到的訊息嗎？ 驗證是否寬鬆或嚴格？
否認：元件是否記錄稽核記錄中的互動？
資訊洩漏：傳入和傳出元件的流量是否已加密？ 允許哪些通訊協議和演算法？
阻斷服務攻擊：元件是否設定為高可用性？ 它是否受到 DDoS 攻擊的保護？
提高許可權：使用者是否獲指派所需的最低許可權？ 解決方案是否將針對一般使用者和高許可權使用者的程序代碼混合在一起？
這樣的技巧可以教授，並隨著經驗而改進。 因此，請務必實作持續學習方法，其設計目的是收集學習，並將其散佈在組織內。
對 ROI 的影響
總之，可以識別出許多想法來提高威脅建模體驗的效率和質量，並最終提高投資回報率。 不過，這項工作應被視為一個持續的過程，應引導至這種做法的不斷提高。
結論
威脅模型化是改善組織安全性的絕佳方法。 如果正確完成，它可以為非常合理的成本提供價值。 我們已經識別出一些可能對提升威脅模型在保護現代解決方案上的價值有必要的技術，包括：
將威脅模型與您的 DevOps 做法一致
專注於緩和措施
使用使用者故事連結緩解措施
突顯威脅模型與工作待辦事項之間的差異
使用威脅模型來推動更全面的安全性監視和稽核
簡化威脅模型的建立，並增加結果的一致性
仰賴安全性專責人員
採用 知識庫 來自動化威脅和風險降低的識別
建立更好的 知識庫
提供自動化支援的問題架構
希望您選擇的威脅建模工具中已經包含其中的部分項目。 其他專案將在未來納入其中。 我們知道，將威脅建模的投資回報率（ROI）最大化是一項需要長期努力的工作，而這項工作需要一些我們仍未獲得的答案。 我們也知道，一些問題仍然未知。 本文應該提供一些思考的啟發，希望協助您改善威脅建模的方式。 我們希望它能成為你我共同的燈塔，並在未來幾年中指引我們的努力方向。