風險管理之引入系統和組件驅動的風險管理方法
系統和組件驅動的風險管理技術的概述。
關于組件驅動方法
在網絡安全中,風險通常用系統的組成部分來描述,例如硬件(計算機、服務器等)或軟件。我們將這種方法稱為自下而上或組件驅動的風險技術。按照這種觀點,風險被評估為給定系統組件的價值及其以某種方式受到損害的可能性的某種組合。更具體地說,這需要評估這些組件面臨的威脅、它們的漏洞以及妥協可能造成的業務影響。
這種方法允許分析師識別系統內特定組件面臨的特定風險。然后,它允許根據風險影響的嚴重程度(或威脅利用漏洞的難易程度)對這些風險進行優先級排序。以這種方式確定風險優先級的目的是在可能的情況下首先減輕最嚴重的風險。
關于系統驅動方法
補充方法主要關注系統(而不是組件)的目標或用途。我們將此類方法稱為自上而下或系統驅動的風險技術,因為它們主要關注整個系統,而不是單個組件。自上而下的技術考慮系統各個方面之間的交互,包括人員、業務流程和技術。
這些方法要求風險分析師首先陳述系統的高級目的。從那里,您可以迭代地向該陳述添加更多細節,作為設計如何實現高級目標的一種方式。重點是理解系統的各個部分如何相互作用。像這樣的方法對于系統工程師和其他涉及迭代設計技術的人來說是非常熟悉的,這些想法在這些技術中很常見。
風險從何而來?除了考慮系統應該服務的目的之外,自上而下的風險管理技術還會考慮系統不應該服務的高級目的。我們用系統運行過程中可能發生的“損失”來討論這些問題。例如,如果您正在設計一個控制自動安全門的系統,該系統的目的可能是讓人們進出。您可能發現的損失可能是讓未經授權的人員通過,或者將人員困在門的機械裝置中而受傷。
這種損失的概念似乎是顯而易見的。然而,我們的經驗表明,在項目生命周期開始時很少考慮系統不能做什么的這些高級描述(與考慮的目的不同)。通常只有當系統的設計相當成熟時才會考慮損失(因此您已經了解系統在邏輯上可能是什么樣子)。這就是人們普遍抱怨安全性“是用螺栓固定的,而不是內置的”的部分原因。
使用拉斯穆森層次結構來區分風險評估技術
為了幫助檢查自下而上和自上而下的技術如何相互關聯,我們可以借鑒Jens Rasmussen 的抽象層次結構,如下所示。
圖片
該模型引入了這樣的想法:您可以查看不同抽象級別的系統。僅考慮插圖的前三層使我們能夠從概念角度思考該系統。也就是說,我們的分析重點是系統應該實現什么(而不是它應該如何工作)。自下而上或組件驅動的方法 是分析該層次結構的底部兩層可能出現的問題。在這里,您關心的是物理存在的事物或其表示形式,例如詳細說明特定技術決策的詳細架構圖。
另外,自上而下或系統驅動的方法 考慮系統的高級目的和損失。目的是確定因系統概念設計而可能造成損失的方式。在這個抽象級別,威脅和漏洞等概念在組件驅動方法中使用時沒有任何意義。在這里,您正在尋找系統可以實現任何損失的方法。
引入該框架的原因是為了證明組件驅動和系統驅動的風險管理技術以根本不同的方式分析風險,但它們相互支持。當應用于正確的問題時,它們都是有價值的風險管理工具。
何時使用系統和組件驅動技術
這些技術可以相互結合使用,以提供對風險的補充視角。例如,您可以使用自上而下的方法來識別最關鍵的系統、交互或漏洞,然后切換到自下而上的分析來詳細探索這些關鍵領域。
他們以不同的方式增加價值;兩者都不比另一個“更好”。然而,每種技術更適合某些類型的風險管理問題:
- 組件驅動的方法對于探索已知技術漏洞的暴露程度非常有用。例如,您的組織中可能有一臺計算機由于操作原因而無法修補或升級。這在某些類型的操作技術中很常見。組件驅動的風險分析可用于探索未修補的計算機中的漏洞如何影響您的組織。這種分析可以確定可以在這臺不可避免的易受攻擊的計算機周圍實施的保護措施。
- 系統方法在分析大型復雜系統時非常有用。特別是,它們可以幫助您探索 交互失敗。 例如,系統的正確和安全操作可能取決于組成系統的多個組件或子系統之間的交互。當系統內的各個組件按照其應有的方式精確工作時,就會發生這種情況,但存在一些問題這些組件相互交互的方式存在缺陷,從而有可能發生安全漏洞。一個很好的例子可能是針對在線支付系統的欺詐風險,其中組件驅動的觀點可能會忽略客戶系統對整個系統安全的重要性。
下表總結了每種技術的優勢:
適合 | |
自上而下的方法 |
|
自下而上的方法 |
|
組件驅動技術和系統風險管理技術可以一起使用。例如,您可以使用系統驅動的方法來確保在做出任何特定技術決策之前從概念上識別安全風險,然后在您致力于采用特定解決方案后切換到組件驅動的分析。