筆記：

同樣重要的是要記住，這種方法不會立即突出整個系統中風險的出現。這只是將適當的日志源引入您的 SOC 系統，此時可以考慮系統范圍的風險。有關識別系統范圍風險的更多信息，請參閱檢測。

需要注意的是，執行威脅建模的方法有很多種，這只是有關如何開始組件級分析的指南。它大致遵循攻擊樹方法，但重點是識別最有價值的日志源和適當的檢測用例。

威脅建模流程

上圖描述了使組織能夠系統地分析系統潛在風險、識別攻擊向量和日志源的過程。然后，該信息也可以用作創建一套檢測的基礎。我們將在下面詳細探討每個步驟。

成分

威脅建模的第一步是確定：

• 用戶與您的系統交互
• 數據流入或流出您的系統

這通常稱為系統的攻擊面。

識別用戶、數據流和攻擊面將使您能夠開始識別系統上的潛在風險和攻擊。

作為一個非常簡單的示例，Web 服務器具有驗證和提交信息的用戶。它存儲敏感數據并面向公眾。因此，該服務器將被視為對攻擊者有吸引力的攻擊目標。這意味著該服務器將被視為潛在的攻擊媒介。

圖片

風險

簡而言之，下一步就是找出可能出現問題的地方。會發生什么情況會影響系統的安全？

機密 性、完整性和可用性 (CIA) 模型在這里很有用，它為您提供了一種枚舉潛在風險的簡潔方法。同樣，您還可以應用其他方法對威脅或攻擊類型進行分類，例如STRIDE 模型，以獲得更深入的效果。

將 CIA 模型應用到我們之前的 Web 服務器示例中是有啟發性的。我們發現，由于 Web 服務器處理客戶數據，因此如果服務器遭到破壞，該數據的機密性就會面臨風險。

如果身份驗證控制失敗，那么除了獲得未經授權的訪問并損害存儲數據的機密性之外，攻擊者還可以利用該訪問權限對數據進行未經授權的更改，損害其完整性或刪除存儲的數據，使其對授權用戶不可用。

這種風險分析至關重要，因為它可以合理化組織內特定組件的監控。突出的風險還可以幫助指導檢測用例的開發。（有關更多信息，請參閱檢測）。

攻擊圖V1

圖片

注意：還可以擴展風險分析，以涵蓋風險發生后對您業務的潛在影響。這可以幫助利益相關者了解潛在的結果，并幫助確定入職行動的優先順序。

威脅者

接下來，您應該設法了解可能嘗試攻擊或惡意影響您的系統的用戶或參與者。

每一類參與者都會以不同的方式與系統進行交互。例如，專家攻擊者有能力發起比新手更復雜的攻擊。同樣，與特權管理員相比，典型用戶將具有不同級別的訪問權限。

攻擊圖V2

圖片

攻擊圖的這一部分還認為，保護性監控的級別應與組織的威脅狀況成比例（如操作模型部分中所述）。如果您確定您的系統不會受到最復雜的攻擊者的攻擊，則不應專注于嘗試檢測它們。相反，請專注于您的系統更有可能遇到的攻擊。

攻擊

此時您可以客觀地探索每一個抽象風險。這是詳細說明攻擊“如何”的地方。然后可以使用它將風險鏈接到日志源。

例如，如果風險是用戶數據泄露，您只需詳細說明這種情況在您的系統中如何發生。它不必非常詳細，并且仍然可以非常抽象，因為目標是識別日志源。此時，使用MITRE ATT&CK 框架也非常有用，因為它可以幫助識別對手可以使用的特定技術，并幫助您找到最合適的日志源。

攻擊圖V3

圖片

日志來源

威脅分析的倒數第二部分及其主要輸出是日志源的識別。在這里，您可以識別并列出任何可用的日志源，這些日志源可用于指示您確定的系統內可能發生的任何攻擊。

攻擊圖V4

圖片

檢測

一旦完成了威脅建模過程，您就應該擁有一個模型，其中詳細說明了多個日志源、系統風險以及各種攻擊。然后可以使用該模型來開發檢測用例或確保您已經擁有適當的覆蓋范圍。（有關用例的更多信息，請參閱檢測）

圖片

概括

威脅建模應該是周期性的，并且您生成的模型應該隨著系統或其面臨的威脅的變化而進行審查。

確定了最有價值的日志數據源后，現在應該可以開始工程流程，將這些信息源引入到 SOC服務中。