筆記：

同樣重要的是要記住，這種方法不會立即突出整個系統(tǒng)中風險的出現(xiàn)。這只是將適當?shù)娜罩驹匆肽?SOC 系統(tǒng)，此時可以考慮系統(tǒng)范圍的風險。有關識別系統(tǒng)范圍風險的更多信息，請參閱檢測。

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

威脅建模流程

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

成分

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

• 用戶與您的系統(tǒng)交互
• 數(shù)據(jù)流入或流出您的系統(tǒng)

這通常稱為系統(tǒng)的攻擊面。

識別用戶、數(shù)據(jù)流和攻擊面將使您能夠開始識別系統(tǒng)上的潛在風險和攻擊。

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

圖片

風險

簡而言之，下一步就是找出可能出現(xiàn)問題的地方。會發(fā)生什么情況會影響系統(tǒng)的安全？

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

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

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

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

攻擊圖V1

圖片

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

威脅者

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

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

攻擊圖V2

圖片

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

攻擊

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

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

攻擊圖V3

圖片

日志來源

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

攻擊圖V4

圖片

檢測

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

圖片

概括

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

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