风险管理之引入组件驱动和系统驱动的风险评估

今天，我们回归风险管理相应的内容，接下来的几天我们也将援引英国国家网络安全中心官网的内容，讨论完这部分内容，不过今天你可以再在这个公众号看到有关《英国国际战略研究所：网络能力与国家实力净评估》这篇文章，让我们看看网络安全能力哪家强？当然这里不是山东找蓝翔了，但是这篇公众号文章还真是山东一家公司的原创。下面，我们讨论引入组件驱动和系统驱动的风险评估，为风险管理续航。

关于组件驱动的方法

在网络安全中，风险通常是根据系统的组成部分来描述的。在这种观点中，风险被评估为给定系统组件的价值的某种组合，以及它以某种方式受到损害的可能性。更具体地说，这需要评估这些组件面临的威胁、它们的漏洞以及入侵可能造成的业务影响。

这种类型的方法允许分析师识别系统内特定组件面临的特定风险。然后，允许根据风险影响的严重程度或威胁利用漏洞的难易程度对这些风险进行优先级排序。以这种方式对风险进行优先排序的目的是在可能的情况下首先减轻最严重的风险。

关于系统驱动的方法

另一种方法主要关注系统（而不是组件）的目标或目的。我们称这种方法为系统驱动的风险视图，因为它们主要关注整个系统，而不是单个组件。

系统驱动方法要求风险分析师首先说明系统的高级目的。从那里迭代地向该语句添加更多细节，作为设计如何实现高级目的的一种方式。重点是了解系统的各个部分如何相互交互。系统工程师和其他参与迭代设计技术的人会非常熟悉这样的方法，因为这些想法很常见。

风险从何而来？除了思考的目的，一个系统应该服务，系统驱动的风险管理技术也将考虑高层次的目的，系统应该没有服务。我们根据系统运行过程中可能发生的“损失”来讨论这些。例如，如果正在设计一个控制自动安全门的系统，该系统的目的可能是让人们进出，可能关心的损失是让未经授权的人通过，或将人困在门的机械装置中而受伤。

这种损失的概念似乎很明显。然而，经验表明，在项目生命周期的开始阶段很少考虑系统不能做什么的这些高级描述，这与考虑的目的不同。损失通常只在系统设计相当成熟时才考虑，当已经了解系统的逻辑外观时。这就是人们普遍抱怨安全性“是固定的，而不是内置的”的部分原因。

使用拉斯穆森的层次结构来区分风险评估技术

为了帮助检查组件驱动和系统驱动技术如何相互关联，可以借鉴 Jens Rasmussen 的抽象层次结构，如下所示。

该模型引入了这样一种思想，即可以在不同抽象级别查看系统。仅考虑顶部的三层插图就可以让我们从概念上考虑系统。也就是说，将分析重点放在系统应该实现什么（而不是应该如何工作）上。组件驱动技术是关于分析在这个层次结构的底部两层可能出现什么问题。在这里，关注物理上存在的事物或其表示，例如详细说明特定技术决策的详细架构图。

另外，系统驱动技术考虑系统的高级目的和损失。目的是确定作为系统概念设计结果的损失的实现方式。在这个抽象级别，威胁和漏洞等概念在组件驱动的方法中使用时没有意义。在这里，正在寻找系统可以实现任何损失的方法

引入这个框架的原因是为了证明组件驱动和系统驱动的风险管理技术以根本不同的方式分析风险，但它们相互支持。当应用于正确的问题时，它们都是有价值的风险管理工具。

何时使用组件和系统驱动技术

组件驱动和系统驱动的技术以不同的方式增加价值；两者都不比另一个“更好”。但是，每种技术都更适合某些类型的风险管理问题：

• 组件驱动的方法对于探索已知技术漏洞的暴露情况非常有用。例如，组织中可能有一台计算机由于操作原因无法修补或升级。这在某些类型的操作技术中很常见。组件驱动的风险分析可用于探索未打补丁的机器中的漏洞如何影响组织。这种分析可以确定可以围绕这台不可避免的易受攻击的计算机采取的保护措施。

• 系统驱动方法在分析大型复杂系统时很有用。特别是，可以帮助探索交互失败。当系统中的各个组件按其应有的方式精确工作时，就会发生这种情况，但是这些组件彼此交互的方式存在一些缺陷，这使得可能发生安全漏洞。

下表对此进行了总结。

组件驱动和系统风险管理技术可以一起使用。例如，可以使用系统驱动的方法来确保在做出任何特定技术决策之前从概念上识别安全风险，然后在承诺采用特定解决方案后切换到组件驱动分析。

参考来源：英国国家网络安全中心官网