今天，我們回歸風險管理相應的內容，接下來的幾天我們也將援引英國國家網絡安全中心官網的內容，討論完這部分內容，不過今天你可以再在這個公眾號看到有關《英國國際戰略研究所：網絡能力與國家實力凈評估》這篇文章，讓我們看看網絡安全能力哪家強？當然這里不是山東找藍翔了，但是這篇公眾號文章還真是山東一家公司的原創。下面，我們討論引入組件驅動和系統驅動的風險評估，為風險管理續航。

　　關于組件驅動的方法

　　在網絡安全中，風險通常是根據系統的組成部分來描述的。在這種觀點中，風險被評估為給定系統組件的價值的某種組合，以及它以某種方式受到損害的可能性。更具體地說，這需要評估這些組件面臨的威脅、它們的漏洞以及入侵可能造成的業務影響。

　　這種類型的方法允許分析師識別系統內特定組件面臨的特定風險。然后，允許根據風險影響的嚴重程度或威脅利用漏洞的難易程度對這些風險進行優先級排序。以這種方式對風險進行優先排序的目的是在可能的情況下首先減輕最嚴重的風險。　

　　關于系統驅動的方法

　　另一種方法主要關注系統（而不是組件）的目標或目的。我們稱這種方法為系統驅動的風險視圖，因為它們主要關注整個系統，而不是單個組件。

　　系統驅動方法要求風險分析師首先說明系統的高級目的。從那里迭代地向該語句添加更多細節，作為設計如何實現高級目的的一種方式。重點是了解系統的各個部分如何相互交互。系統工程師和其他參與迭代設計技術的人會非常熟悉這樣的方法，因為這些想法很常見。

　　風險從何而來？除了思考的目的，一個系統應該服務，系統驅動的風險管理技術也將考慮高層次的目的，系統應該沒有服務。我們根據系統運行過程中可能發生的“損失”來討論這些。例如，如果正在設計一個控制自動安全門的系統，該系統的目的可能是讓人們進出，可能關心的損失是讓未經授權的人通過，或將人困在門的機械裝置中而受傷。

　　這種損失的概念似乎很明顯。然而，經驗表明，在項目生命周期的開始階段很少考慮系統不能做什么的這些高級描述，這與考慮的目的不同。損失通常只在系統設計相當成熟時才考慮，當已經了解系統的邏輯外觀時。這就是人們普遍抱怨安全性“是固定的，而不是內置的”的部分原因。

　　使用拉斯穆森的層次結構來區分風險評估技術

　　為了幫助檢查組件驅動和系統驅動技術如何相互關聯，可以借鑒 Jens Rasmussen 的抽象層次結構，如下所示。

　　該模型引入了這樣一種思想，即可以在不同抽象級別查看系統。僅考慮頂部的三層插圖就可以讓我們從概念上考慮系統。也就是說，將分析重點放在系統應該實現什么（而不是應該如何工作）上。組件驅動技術是關于分析在這個層次結構的底部兩層可能出現什么問題。在這里，關注物理上存在的事物或其表示，例如詳細說明特定技術決策的詳細架構圖。

　　另外，系統驅動技術考慮系統的高級目的和損失。目的是確定作為系統概念設計結果的損失的實現方式。在這個抽象級別，威脅和漏洞等概念在組件驅動的方法中使用時沒有意義。在這里，正在尋找系統可以實現任何損失的方法

　　引入這個框架的原因是為了證明組件驅動和系統驅動的風險管理技術以根本不同的方式分析風險，但它們相互支持。當應用于正確的問題時，它們都是有價值的風險管理工具。

　　何時使用組件和系統驅動技術

　　組件驅動和系統驅動的技術以不同的方式增加價值；兩者都不比另一個“更好”。但是，每種技術都更適合某些類型的風險管理問題：

　　組件驅動的方法對于探索已知技術漏洞的暴露情況非常有用。例如，組織中可能有一臺計算機由于操作原因無法修補或升級。這在某些類型的操作技術中很常見。組件驅動的風險分析可用于探索未打補丁的機器中的漏洞如何影響組織。這種分析可以確定可以圍繞這臺不可避免的易受攻擊的計算機采取的保護措施。

　　系統驅動方法在分析大型復雜系統時很有用。特別是，可以幫助探索交互失敗。當系統中的各個組件按其應有的方式精確工作時，就會發生這種情況，但是這些組件彼此交互的方式存在一些缺陷，這使得可能發生安全漏洞。

　　下表對此進行了總結。

　　組件驅動和系統風險管理技術可以一起使用。例如，可以使用系統驅動的方法來確保在做出任何特定技術決策之前從概念上識別安全風險，然后在承諾采用特定解決方案后切換到組件驅動分析。