系统和组件驱动的风险管理技术的概述。
关于组件驱动方法
在网络安全中，风险通常用系统的组成部分来描述，例如硬件（计算机、服务器等）或软件。我们将这种方法称为自下而上或组件驱动的风险技术。按照这种观点，风险被评估为给定系统组件的价值及其以某种方式受到损害的可能性的某种组合。更具体地说，这需要评估这些组件面临的威胁、它们的漏洞以及妥协可能造成的业务影响。
这种方法允许分析师识别系统内特定组件面临的特定风险。然后，它允许根据风险影响的严重程度（或威胁利用漏洞的难易程度）对这些风险进行优先级排序。以这种方式确定风险优先级的目的是在可能的情况下首先减轻最严重的风险。
关于系统驱动方法
补充方法主要关注系统（而不是组件）的目标或用途。我们将此类方法称为自上而下或系统驱动的风险技术，因为它们主要关注整个系统，而不是单个组件。自上而下的技术考虑系统各个方面之间的交互，包括人员、业务流程和技术。
这些方法要求风险分析师首先陈述系统的高级目的。从那里，您可以迭代地向该陈述添加更多细节，作为设计如何实现高级目标的一种方式。重点是理解系统的各个部分如何相互作用。像这样的方法对于系统工程师和其他涉及迭代设计技术的人来说是非常熟悉的，这些想法在这些技术中很常见。
风险从何而来？除了考虑系统应该服务的目的之外，自上而下的风险管理技术还会考虑系统不应该服务的高级目的。我们用系统运行过程中可能发生的“损失”来讨论这些问题。例如，如果您正在设计一个控制自动安全门的系统，该系统的目的可能是让人们进出。您可能发现的损失可能是让未经授权的人员通过，或者将人员困在门的机械装置中而受伤。
这种损失的概念似乎是显而易见的。然而，我们的经验表明，在项目生命周期开始时很少考虑系统不能做什么的这些高级描述（与考虑的目的不同）。通常只有当系统的设计相当成熟时才会考虑损失（因此您已经了解系统在逻辑上可能是什么样子）。这就是人们普遍抱怨安全性“是用螺栓固定的，而不是内置的”的部分原因。
使用拉斯穆森层次结构来区分风险评估技术
为了帮助检查自下而上和自上而下的技术如何相互关联，我们可以借鉴Jens Rasmussen 的抽象层次结构，如下所示。
图片
该模型引入了这样的想法：您可以查看不同抽象级别的系统。仅考虑插图的前三层使我们能够从概念角度思考该系统。也就是说，我们的分析重点是系统应该实现什么（而不是它应该如何工作）。自下而上或组件驱动的方法是分析该层次结构的底部两层可能出现的问题。在这里，您关心的是物理存在的事物或其表示形式，例如详细说明特定技术决策的详细架构图。
另外，自上而下或系统驱动的方法考虑系统的高级目的和损失。目的是确定因系统概念设计而可能造成损失的方式。在这个抽象级别，威胁和漏洞等概念在组件驱动方法中使用时没有任何意义。在这里，您正在寻找系统可以实现任何损失的方法。
引入该框架的原因是为了证明组件驱动和系统驱动的风险管理技术以根本不同的方式分析风险，但它们相互支持。当应用于正确的问题时，它们都是有价值的风险管理工具。
何时使用系统和组件驱动技术
这些技术可以相互结合使用，以提供对风险的补充视角。例如，您可以使用自上而下的方法来识别最关键的系统、交互或漏洞，然后切换到自下而上的分析来详细探索这些关键领域。
他们以不同的方式增加价值；两者都不比另一个“更好”。然而，每种技术更适合某些类型的风险管理问题：
- 组件驱动的方法对于探索已知技术漏洞的暴露程度非常有用。例如，您的组织中可能有一台计算机由于操作原因而无法修补或升级。这在某些类型的操作技术中很常见。组件驱动的风险分析可用于探索未修补的计算机中的漏洞如何影响您的组织。这种分析可以确定可以在这台不可避免的易受攻击的计算机周围实施的保护措施。
- 系统方法在分析大型复杂系统时非常有用。特别是，它们可以帮助您探索交互失败。例如，系统的正确和安全操作可能取决于组成系统的多个组件或子系统之间的交互。当系统内的各个组件按照其应有的方式精确工作时，就会发生这种情况，但存在一些问题这些组件相互交互的方式存在缺陷，从而有可能发生安全漏洞。一个很好的例子可能是针对在线支付系统的欺诈风险，其中组件驱动的观点可能会忽略客户系统对整个系统安全的重要性。
下表总结了每种技术的优势：
适合 | |
自上而下的方法 |
|
自下而上的方法 |
|
组件驱动技术和系统风险管理技术可以一起使用。例如，您可以使用系统驱动的方法来确保在做出任何特定技术决策之前从概念上识别安全风险，然后在您致力于采用特定解决方案后切换到组件驱动的分析。
