整合威脅模型與 DevOps

這篇文章由西蒙妮·柯齊、安東尼·內維科、喬納森·大衛斯、拉斐爾·帕佐斯·羅德裡格斯和本·漢森撰寫

簡介

威脅模型化是一個重要的安全性方法，可協助識別及設定應用程式或系統最重要的風險風險降低優先順序。 本文包含一些關於如何更有效率且更有效率地採用威脅模型、將其與新式 DevOps 方法與工具整合，以及專注於向所有與軟體開發生命週期相關的各種動作專案提供的價值。

這份檔是否適合您？

本文是來自Microsoft的一小組安全性和威脅模型化專家的工作結果，並納入了一些來自外部Microsoft最傑出的專家的意見和想法。 它會嘗試解決簡單但緊迫的問題：我們應該怎麼做，以確保我們所使用的威脅模型化程式已更新為敏捷式方法和 DevOps 所強加的新式需求，以便以最低成本提供所需的值？

如果您是產品擁有者、安全性小組的成員，或只是考慮採用威脅模型化作為開發生命週期一部分的開發人員，本文件適合您。

同樣地，如果您已經採用威脅模型化，您仍然可以找到實際的想法來改善您的程式。

不過，本文旨在介紹改善目前程式的想法，或成功採用威脅模型化作為 DevOps 程式的一部分。 它不會介紹特定的工具或產品，即使我們希望在未來看到某些工具或產品所實作的想法。 因此，您在這裡不會找到新工具或即將推出的功能的預覽公告。

為什麼威脅模型化很重要？

威脅模型化是安全地設計軟體解決方案的主要方法之一。 透過威脅模型化，您可以分析系統識別攻擊媒介，並開發動作以減輕這些攻擊帶來的風險。 適當地完成威脅模型化是任何風險管理程序的絕佳元件。 它也可以藉由儘早找出並修正設計問題來協助降低成本。 NIST 的一項舊研究估計，在設計階段修復生產程式代碼設計問題的成本比修復成本高出約 40 倍。 它也可節省因最終設計問題的安全性事件而產生成本。 請考慮IBM安全性的2022年數據外泄報告和 Ponemon 研究所估計數據外洩的平均成本為435萬美元。 對於所謂的超級缺口，涉及超過5000萬筆記錄的妥協，平均成本達到3.87億美元！

威脅模型化是您可以執行以保護解決方案的第一個活動，因為它在解決方案設計上運作。 此特性可讓您套用至 SDLC 的最有效安全性做法。

Microsoft具有長期的威脅模型化歷程記錄。 1999年，兩位（當時）Microsoft員工洛倫·科恩費爾德和普拉裡特·加格寫了一份檔《 對產品的威脅》。 本文介紹 STRIDE 方法，這是Microsoft威脅模型化程式的同義字。

威脅模型化是進化的過程

威脅模型化不是靜態程式;它會隨著需求和技術的變化而發展。

• 類似最近一個以 SolarWinds 為目標 的 供應鏈攻擊，示範需要涵蓋威脅模型化比解決方案本身更多的案例，包括開發和部署。

• 與 Log4j 最近的開放原始碼弱點一樣，已示範需要根據採用軟體組合分析工具來掃描易受攻擊元件的目前方法，以防禦性設計解決方案來限制其暴露程度。

• 機器學習 等新技術的應用引進了必須瞭解和控制的新攻擊媒介。 例如，請考慮在人類耳邊播放惡意製作的音效，導致 AI 服務執行命令的可能性，如中所 https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini討論。

在Microsoft，不同的產品群組會根據其特定安全性需求來練習不同的威脅模型化變體。 每個變體都旨在保證套用至案例的適當安全性保證層級，但「適當」代表根據特定內容而變更的內容。

例如，保護 Windows 與保護 Azure 認知服務不同，因為這些系統的大小和特性非常不同。 威脅模型化的主要層面是平衡其成本與應用程式的風險承受能力。 雖然這可能會導致某些案例完全避免威脅模型化的決定，但當正確完成時，我們只能建議針對任何IT計劃採用它，包括軟體開發和基礎結構部署專案。

專注於 ROI 的重要性

過去幾年來，威脅模型化的興趣穩步增加，成為重要的軟體開發程式。 此興趣是因為基礎結構和解決方案的攻擊呈指數增加。 NIST 建議的廠商最低標準或程式代碼開發人員驗證和威脅模型化指令清單等計劃進一步增加了需求，而目前的方法已顯示一些限制。 例如，威脅模型化的結果高度相依於採用的程式，以及執行威脅模型的人員。 因此，人們擔心從體驗中持續提高品質。

但是，品質對威脅模型有何意義？ 對我們來說，質量威脅模型必須具有下列特性：

• 它必須識別可採取動作的風險降低措施，您可以進行的活動，以減少因攻擊所造成的潛在損失。 可採取動作表示必須妥善定義這些風險降低措施，這表示您可以取得足夠的資訊來實作它們，然後測試實作。 這也表示必須提供它們，才能輕鬆取用開發小組。 使用 DevOps 和 Agile 時，這表示有一個簡單的路徑可匯入待辦專案。

• 針對每個風險降低，它必須識別其狀態。 有些風險降低功能是新的，有些則已存在。 威脅模型必須辨識已經存在的內容，並專注於目前的風險，以識別如何改善情況。

• 它必須清楚識別每個風險降低需要的原因，方法是將它連結到個別的威脅。

• 此外，風險降低對於每個威脅都有相對強度。 例如，TLS 加密可能是讓傳輸中數據暴露的風險有很強的緩和措施，同時，可能會降低伺服器詐騙的風險。

• 威脅必須可信、妥善定義，且專屬於解決方案。

• 威脅必須具有相關聯的嚴重性，這應該同時考慮其機率和影響。 嚴重性必須合理且理想情況下不偏不倚。

• 應該能夠全面了解風險，以及如何解決風險。 這種觀點有助於推動與安全性小組和商務決策者進行有意義的對話，並讓我們隱藏不必要的複雜性。

這份清單已經顯示重要概念：威脅模型化可為軟體生命周期期間涉及的許多角色提供價值，但每個角色都有不同的需求和需求。 例如，開發人員必須接收有關其實作內容以及如何確認其實作行為如預期般運作的清楚資訊。 另一方面，安全性小組通常與組織所擁有基礎結構和應用程式生態系統的整體安全性有關：因此，他們需要接收資訊，以決定範圍中的系統是否足夠安全，並滿足其合規性需求。 最後，產品擁有者和商務決策者必須瞭解讓組織能夠接受風險的必要條件。

這類不同的需求需要針對威脅模型提供不同的檢視，每個檢視都著重於特定使用案例。

威脅模型化的典型問題是，它越成功，少數可用的專家就越難以涵蓋需求，同時仍然提供來自此體驗的高品質。 因此，在某些情況下，品質可能會受到負面影響。 一切都很好，直到威脅模型化停止提供與投資相比的重要價值。 超過一些組織會受到此問題的影響。 已經有一些商務決策者的報告開始質疑威脅模型化，因為它無法為成本帶來重大價值。

透過價值，我們指的是 Business 值，這是提供瞭解範圍中系統所代表風險所需的資訊，並推動有意義的決策程式，以選取要實作的適當風險降低措施。 此外，值也與提供正確的資訊給開發人員和測試人員有關。 最後，值與與所有相關方溝通剩餘風險有關。 例如，我們可以測量威脅模型化程序的影響來測量值。 假設我們藉由將數位指派給識別給每個威脅的嚴重性，來測量解決方案的整體風險。 在此情況下，我們預期整體風險會隨著威脅模型的每個影響而降低。 如果整體風險維持不變或增加，則可能有問題。 降低越高，威脅模型的影響就越高。 當然，威脅模型不會控制實作的風險降低措施。 決定必須實作哪些專案是產品擁有者的責任。 但是，將威脅模型的有效性與緩和措施的實際實作連結的優點是，它會增加對解決方案實際安全性的影響，降低威脅模型仍然是理論練習的風險。

相反地，成本與執行威脅模型本身所需的活動有關，這是所有參與方產生威脅模型並加以討論所需的時間。

這表示問題：我們是否可以定義以最大化商務價值並將成本降至最低的威脅模型化程式？

DevOps 的重要性

我們已經強調，請務必確保威脅模型化是與 DevOps 程式整合的寶貴做法。 這表示程式必須可供所有小組成員使用，通常是透過簡化和自動化程式。 最重要的是，專注於DevOps的威脅模型化，表示我們需要確保體驗與現有的DevOps程式深入整合。

威脅模型化不應成為另一個負擔，而是應是一種資產，以利於安全性需求產生和收集、安全解決方案的設計、將活動納入所選的工作和 Bug 追蹤工具中，以及根據解決方案目前和未來狀態評估剩餘風險。

與 DevOps 對齊

我們可以使用各種技術來配合目前 DevOps 實務的威脅模型化。

威脅和風險降低

首先，我們必須將威脅模型化程式放在需要執行的工作上。 威脅是攻擊模式及其可能發生方式，必須說明小組為何需要實作安全性控制。 它們也是判斷何時應實作緩和措施的因素。 不過，真正的目標是要判斷需要執行的動作：風險降低。 因此，此方法必須快速識別所需的風險降低措施，而且必須通知決策程式，以便更容易判斷該做什麼和何時執行。 此決策程式的主要交付專案是在待處理專案中選取風險降低措施，使其成為標準程式的一部分。 在理想情況下，應該同步處理威脅模型化工具和工作和錯誤追蹤工具，以反映威脅模型中風險降低狀態的更新。 這將允許動態和自動修訂剩餘風險，這對於支援明智的決策至關重要，作為採用敏捷式方法的一般編舞的一部分，例如短期衝刺規劃會議。

你今天能做什麼？

身為威脅模型化專家，您應該確保實作威脅模型化程式，以清楚識別動作，並將其納入您選擇的工作和錯誤追蹤中。 其中一種方式可能是採用許多威脅模型化工具之一，以便將此程序自動化。

身為開發人員，您應該專注於視需要識別的安全性控制件。 此程式應設計成以您預期收到任何其他活動的方式提供它們給您。

功能、用戶劇本和工作

我們已經指出，風險降低功能代表與 DevOps 整合相關的威脅模型所產生的最重要的成品。 因此，請務必清楚定義在所選工作和 Bug 追蹤工具上，從這些風險降低中建立的物件類型。 某些風險降低可能會超過短期衝刺。 因此，最好將其建立為功能。 但許多都比較容易，而且可以在單一短期衝刺中實作;因此，可以將它們表示為用戶劇本或工作。 雖然可能會產生不同的工作項目類型，但這可能會導致錯誤和混淆的複雜程式。 因此，堅持單一工作項目類型似乎更實用。 假設風險降低可能會被視為使用者劇本的子系，您可以考慮將其表示為工作，這表示放寬在單一短期衝刺中執行上述工作項目類型的需求。

你今天能做什麼？

請確定威脅模型所識別的風險降低措施會顯示在待辦專案中。 識別清楚表示它們的方式。

使用者劇本

風險降低並不是威脅模型的唯一成品部分，威脅模型可能而且應該與您在工作和錯誤追蹤工具中擁有的專案一致。 例如，您可能也想要代表威脅。 藉由將WITHOUT子句新增至一般「作為[我是誰]，我想[我想要的]，以便[執行某些動作]，來達成此目標。例如：「身為使用者，我想用信用卡付款，這樣我就可以購買一些商品，而不需要我的信用卡遭竊數據。 WITHOUT 子句可以對應到一或多個威脅，有時允許表達安全性需求。 藉由確保威脅與WITHOUT子句之間的這種一致性在威脅模型中明確進行，我們可以確保小組會反映並處理可能的風險，因為它們包含在用戶劇本中。 您也可以使用此關聯性，將識別為用戶劇本一部分的每個安全性需求對應至至少威脅。

好知道

WITHOUT 子句不是製作此頁面的小組的原始想法。 我們不確定誰第一次介紹它，但我們感謝誰來這個想法。

圖 1：對齊需求

例如，上圖顯示下列情況：

• 威脅 A 會透過沒有 1 子句連結到使用者劇本 1。

• 威脅 B 透過子句 WITHOUT 2 連結到使用者劇本 2。

• 威脅 B 也會連結到使用者劇本 3。 但 User Story 3 未指派給任何 WITHOUT 子句。 為什麼？ 它代表您應該調查的潛在異常。

• 威脅 B 也會連結到使用者劇本 1。 目前還不清楚我們是否應該允許將使用者劇本連結到一個以上的威脅。

• 威脅 C 會連結至與 WITHOUT 3 和 4 相關聯的用戶劇本 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子句的使用者劇本連結至對應至所選風險降低的工作專案。 規劃下一個短期衝刺時，請務必在使用WITHOUT子句實作其中一個用戶劇本時，優先處理連結的安全性活動。

整合以醒目提示不對齊

一旦開始思考如何連結構成威脅模型的成品與 Task & Bug Tracking 工具中的成品，就更容易識別改善兩者質量的機會。 關鍵是利用其關聯性來醒目提示差異，並利用其中一個中的資訊來補充、整合和解譯另一個中存在的資訊。 如上所述，您可以這麼做，而不會大幅影響小組的運作方式。 這是因為此方法依賴現有的資訊，並建立不同世界中各種對象之間的關聯性。 因此，威脅模型會成為解決方案安全性的真相來源。 同時，待辦專案會持續與解決方案的狀態一致。

你今天能做什麼？

使用WITHOUT子句定期確認沒有任何未對應的威脅或用戶劇本。

威脅模型化和作業

所有這些想法主要著重於 DevOps 的開發端。 我們可以執行一些動作來改善作業嗎？ 我們確實這麼認為。 例如，您可以使用威脅模型化作為工具來輔助根本原因分析，因為它從安全性觀點提供系統的完整檢視，因此可以進一步瞭解某些攻擊的影響。 若要達成此目的，必須整合威脅模型與所選監視工具中現有的摘要。 此方法可能代表所選 SIEM 的補碼。

將威脅模型化與 Operations 整合的另一個概念，是先使用第一個來驅動後者如何發生的設計。 其中一個範例是解決方案的事件設計。 威脅模型化可識別可能的攻擊，我們可以使用該知識來識別當這些攻擊失敗時，範圍中解決方案可能會引發的事件。 如果您進行嚴格的輸入驗證，惡意攻擊者在成功之前需要幾次嘗試。 一開始，嘗試會失敗，其中一個嘗試最終會成功。 藉由引發每個失敗的事件，並在達到某些閾值時觸發警示，您可以偵測攻擊並採取動作來補救它們。 如果您限制自己監視基礎結構，則很少偵測到這些情況。 因此，必須包含自定義事件，小組必須先設計和實作這些事件，SOC 才能運用它們。

此外，後者可能對解決方案知之甚少。 因此，SOC 可能無法判斷輸入驗證失敗時如何回應。 不幸的是，當數據外泄發生時，必須快速做出反應，以減少直接損害和最終罰款的機率和實體。

因此，我們需要事先規劃需要監視的專案、在哪些情況下可能會有問題，以及在何時發生時該怎麼做。 識別這些事件的最佳方式是依賴威脅模型。 因此，利用它來產生標準化成品，以引導和加速實作必要的設定，以推動監視和稽核，並協助事件回應。

你今天能做什麼？

主動使用威脅模型來識別您可以針對每個威脅引發的事件。 這些事件可能是由基礎結構提供，或應用程式必須引發的一些事件。 在您的待辦專案中納入工作專案，以確保實作這些事件。

請積極與您的 Operations 與 Security 小組合作，包括 SOC 小組，以確保會利用事件來引發警示並識別安全性事件。

對 ROI 的影響

您可能想知道為什麼這些技術可能會對威脅模型化ROI產生積極影響。 從我們的觀點來看，它們對於提高DevOps小組的威脅模型化價值至關重要。 我們反覆看到的問題是，這些小組認為安全性是一種成本，可提供有限的價值，而且需要許多無法預見的工作。 有時，目前還不清楚為什麼他們應該投入這麼多時間來修復安全性。 因此，安全性會成為問題，而不是成為機會。 威脅模型化有可能克服這些問題，因為它提供實作安全性的原因。 此外，它可以在開發過程中早期啟動，並避免設計錯誤，如果很快未偵測到，可能會付出代價。 上述技術旨在更好地整合威脅模型化與 DevOps。 這可確保商務決策者和開發人員將威脅模型化視為開發和作業程式的自然補充。 因此，採用威脅模型化所收到的值會增加，而且其成本會因為與已使用的各種工具整合而降低。

簡化威脅模型工具的工作

改善威脅模型化 ROI 的另一個重要層面，與降低其成本並增加能夠交付的人員數目，同時維持更同質的品質等級有關。

許多試圖解決主管人員短缺的問題。 其中一些是以整個 DevOps 小組參與威脅模型化練習為基礎。 這個想法是識別該倡議的領導人，這是一個對程式有中級知識但不一定是專家的人，並讓她與其他小組成員進行討論。 這個方法由威脅模型化宣言的簽署者積極認可。

我們確實同意這種方法能夠取得良好的價值，並代表對目前情況的改善。 它也提供良好的見解，並讓小組能夠成長其安全性文化。 然而，它不是沒有缺點，因為它只涵蓋幾個問題，排除了很多。 這造成了一致性問題，因為太容易下兔子洞，浪費寶貴的時間次要問題，遺漏重要問題。 領導人的經驗將在防止這些情況發生方面發揮重要作用。 此外，此方法需要所有小組成員花很多時間討論每個問題。

因此，即使在此練習中每短期衝刺花費數小時，也可能代表大量投資。 每個人都知道，大多數小組通常會浪費時間參加涉及每個人的大型會議，而那些威脅模型化會話不會例外。 不過，這種方法非常適合小型產品，小組包含少數資深成員。

不同的方法

根據先前方法的限制，我們偏好限制會議數目、其長度和參與者數目。 因此，威脅模型化工具的責任會更加重要：不僅要領導面試，還要建立和維護威脅模型本身。 這種方法需要更顯著的專長認證和專業知識。 威脅模型化工具可能由安全性擁護者或內部安全性小組的成員代表。 大部分的組織都會優先使用，因為安全性小組通常已完整預訂。

安全性擁護者是 DevOps 小組的成員，對安全性特別感興趣。 他們絕不是專家，但他們有基本知識，並願意改善小組的安全性狀態。 其概念是建立安全性冠軍與內部安全性小組之間的特殊許可權連線，讓第一個小組能夠協助小組執行正確的工作，而安全性小組可以減少其工作負載。 透過威脅模型化，安全性擁護者會充當威脅模型化者，而內部安全性小組將負責引導他們並檢閱其工作。

你今天能做什麼？

調查採用安全性擁護者計劃的可能性，並利用它進一步加強您的安全軟體開發生命週期。

知識庫 的角色

威脅模型化的重大問題在於確保無論誰執行威脅模型，體驗的品質和 DevOps 小組的價值都很高。 有了安全擁護者，這個問題變得更加緊迫。 解決此問題的想法是提供 知識庫，以推動建立威脅模型。 威脅模型化的知識庫是特定內容的相關信息套件：它們包含與該內容相關的實體定義、這些實體的可能攻擊模式，以及可套用的標準風險降低措施。 知識庫可讓組織取得更好且更一致的結果，因為它們代表以規範方式引導威脅模型工具的參考數據。 知識庫應該有規則，可讓我們自動將威脅和風險降低套用至系統。 此自動化可讓我們克服某些威脅模型化工具可能沒有判斷是否應套用威脅或某些風險降低是否有效所需的經驗。

知識庫不是新概念：許多目前的威脅模型化工具已以某種形式支持它們。 但許多目前的實作有顯著的缺點。 例如，您應該能夠輕鬆地維護 知識庫。 其可維護性是仍未解決的問題。 例如，識別用來建置資訊的最佳來源並不容易。 此外，維護通常是手動的。 建立和維護 知識庫 應該是組織內部安全性小組的責任。 我們希望公司能夠開始為最常見的威脅模型化工具提供 知識庫，以減輕客戶未來的一些負擔。 這些 知識庫 應具有彈性，即使最成熟的組織也需要調整上述 知識庫，才能支持和促進其採用。

你今天能做什麼？

請考慮將集中式安全性小組用於開發 知識庫的一部分，這些 知識庫 可供各種開發小組用來加速威脅模型化的可能性。

取用 知識庫

知識庫 的另一個問題是，有時它們太複雜而無法取用。 其中許多人試圖通過包括基本和較不重要的問題來全面。 不幸的是，並非所有系統都需要它們。 當您分析的系統很小且不會處理敏感數據時，您會想要採用更簡單的方法。 相反地，如果系統很複雜，且處理 PII 和高商務價值數據，您會想要更深入。 因此，視內容而定，應該可以套用不同版本的知識，或將某些攻擊模式和相關聯的風險降低標示為「TOP」。 如此一來，威脅模型化工具就能夠決定他們是否想要全面體驗，或輕鬆輕鬆，並將所需的工作降到最低。

說起效率，請務必確保盡可能簡化和自動化活動，以減少所需的工作量。 我們確實認為，執行平均大小解決方案的威脅模型，應該是威脅模型工具的1天工作。 只有在選擇的工具提供加速器以允許削減所需的時間時，才能產生這類結果。 例如，如果工具在 100 個不同位置套用 20 種不同類型的風險降低功能，而且系統會要求針對其中每一種風險降低類型指定其狀態，則專注於第一個，而不是後者會更有效率 5 倍。 選擇的工具應該提供這項功能，同時仍授與在必要時執行更徹底的工作的可能性。

你今天能做什麼？

如果您目前使用的 知識庫 不支援「TOP」威脅和風險降低的概念，請考慮移除很少必要或有用的專案的可能性，只允許專注於真正重要的事項。

有時候問題在於採用的 知識庫 嘗試為泛型，並涵蓋多個案例。 您可以透過專門改善情況。

詢問正確的問題

在分析期間，我們已考慮使用工具來支援問題架構，以推動分析的第一個階段。 我們注意到，大多數缺乏經驗的威脅模型工具無法詢問正確的問題，以取得其分析所需的資訊。 我們的一些專家已經證明，可以根據範圍內的系統圖表來判斷一些關鍵問題。 這些問題甚至可以隨著某些產生規則自動套用。 問題是，這種方法可能不會提供它似乎承諾的價值。 這是因為您需要瞭解每個問題背後的理由。 否則，您將無法評估答案，並判斷其是否令人滿意。 不過，自動化問題產生可能會為較不具專家的威脅模型工具提供顯著價值，以改善他們對範圍中系統的瞭解。

你今天能做什麼？

採用結構化方法來詢問問題。 例如，我們的小組藉由採用Microsoft STRIDE 作為參考，取得了良好的結果。 您可以藉由詢問解決方案問題的每個元件來執行此動作，例如：

• 詐騙：元件如何向其使用的服務和資源進行驗證？

• 竄改：元件會驗證收到的訊息嗎？ 驗證是否寬鬆或嚴格？

• 否認：元件是否記錄稽核記錄中的互動？

• 資訊洩漏：傳入和傳出元件的流量是否已加密？ 允許哪些通訊協議和演算法？

• 拒絕服務：元件是否在高可用性中設定？ 它是否受到 DDoS 攻擊的保護？

• 提高許可權：使用者是否獲指派所需的最低許可權？ 解決方案是否混合了針對高特殊許可權使用者的一般用戶所設定的程序代碼？

這樣的技術可以教導，並可以改進經驗。 因此，請務必實作持續學習方法，其設計目的是收集學習，並將其散佈在組織內。

對 ROI 的影響

底線，可以識別許多想法，以改善威脅模型化體驗的效率、其品質，並最終提高 ROI。 不過，這項工作應被視為一個持續的過程，應引導至這種做法的不斷提高。

結論

威脅模型化是改善組織安全性的絕佳方法。 如果正確完成，它可以為非常合理的成本提供價值。 我們已經識別出各種技術，可能證明改善威脅模型化的價值，以保護新式解決方案，包括：

• 將威脅模型與您的 DevOps 做法一致

  • 專注於緩和措施

  • 使用使用者劇本連結風險降低功能

  • 反白顯示威脅模型與待辦專案之間的差異

  • 使用威脅模型來推動更全面的安全性監視和稽核

• 簡化威脅模型的建立，並增加結果的一致性

  • 依賴安全性冠軍

  • 採用 知識庫，將威脅和風險降低的識別自動化

  • 建立更好的 知識庫

  • 提供自動化支援的問題架構

希望其中一些專案已在您選擇的威脅模型化工具中找到。 其他專案將在未來納入其中。 我們知道，將威脅模型化 ROI 最大化是一項長期工作，需要我們還沒有答案。 我們也知道，一些問題仍然未知。 本文應該提供一些想法的食物，希望協助您改善威脅模型化的方式。 我們希望它可以是一個燈塔，你和我們，這將是有用的，指導我們的努力在未來幾年。