介绍
本节解释了系统驱动风险分析的核心概念、这些技术可以增加哪些价值以及它们在哪些方面不太有用。
- 本介绍的目的并不是为您提供实现此类技术的蓝图。但是，一旦您了解了这些基础知识，您应该能够使用系统驱动的标准或框架（因为它们基于类似的风险视角），并了解它们与组件驱动的风险管理技术有何不同。
- 如果您还没有这样做，请在阅读本节之前先阅读介绍组件和系统驱动的风险评估的部分。
系统驱动的风险分析有什么用处？
系统驱动的风险分析最适合识别因系统组件之间的交互而出现的风险。这些风险可以在没有任何单个组件损坏或受到损害的情况下发生，因此它们可以识别组件驱动方法无法识别的风险。
在小型、简单的系统中，无需任何特别正式的方法就可以识别这些交互风险。然而，对于更大、更复杂的系统来说，这是不可行的，而这正是系统驱动方法增加真正价值的地方。系统驱动的方法最适合在某些新场景中使用，特别是在项目或交付框架的设计和概念开发阶段，以及您可能需要识别系统组件之间的交互所出现的风险的情况。
这种技术的最终产品是您正在分析的系统的一组安全要求。系统驱动的风险管理技术应该使您能够将这些要求追溯到您试图避免的特定结果，这有助于您确定潜在安全改进的优先顺序。
什么是系统？
就本指南而言，“系统”一词是指旨在实现特定功能的事物。这一功能可以通过技术来实现，但同样，“系统”可以是一群人、一座建筑物或自然发生的天气模式。因此，谈论“系统”而不提及其功能或目的是没有意义的。使用这个定义，在分析系统时，由您（和您的利益相关者）在分析之前定义您正在查看的系统的功能。
例如，您可以在组织的网站上执行风险评估。您的站点所在的服务器将是该系统的重要组成部分，但它并不能代表整个系统。允许您的组织托管网站的系统将包括一系列其他内容，包括（但不限于）：
- 你的互联网连接
- 维护网站的人
- 作为网站一部分保存客户记录的数据库
- 管理网站管理方式的组织政策
在此示例中，您感兴趣的系统不仅仅是网站；还包括网站。该系统允许您的客户和合作伙伴通过互联网了解您的组织。定义系统功能是系统驱动风险分析的核心部分。
定义“功能”
如果您正在谈论系统，那么首先必须说明您要分析的功能。否则，您可能最终只分析单个系统组件（例如上例中的网站服务器）而忽略其余部分。系统功能的示例可能是：
- 让客户能够使用互联网购买您的产品
- 使人们能够在一小时内从伦敦到达伯明翰
- 使组织的员工能够协作制作和共享文档
系统驱动的风险管理方法的定义特征之一是，它们需要在开发的早期阶段明确说明系统的功能。此阶段的一个常见错误是将系统的功能与系统有助于解决的问题的陈述相混淆。
例如，您可能会说销售网站的功能是“提高组织的销售数字”。严格来说，网站的功能应该是“让客户能够在网上识别并购买你的产品，并让你的物流部门能够及时发货”。该功能将有助于解决“提高销量”的问题，但并不能彻底解决该问题，其他解决方案也会对解决该问题产生影响。
良好的功能陈述必须是可实现的，并且必须能够验证您是否已经实现了它。正确执行此功能声明是进行系统驱动风险分析的重要组成部分。
定义系统的“损失”
在系统和组件驱动技术的介绍中，我们了解了系统不应实现（或有助于实现）的高级目的如何被称为损失。为了执行系统驱动的风险分析，您需要枚举您不希望在系统运行中发生的高级结果。在这种情况下，我们只关心损失的实际结果。
在这里，我们谈论的是组织非常关心的高层损失。如果您识别出少量非常重大的损失，而不是大量相对较小的损失，那么这种方法最有效。
损失的例子包括：
- 受伤或死亡
- 针对您的组织的大规模欺诈
- 触犯法律
- 关键的组织流程被破坏
任何系统驱动的风险分析的一个重要部分是清楚、准确地定义您在操作或设计的系统背景下担心哪些损失。重要的是，我们不是在讨论实现损失的方式，而是在讨论结果本身。此阶段的结果应该是您确定与您的系统相关的损失列表。
将这些原则付诸实践
在网络安全中，系统驱动的风险分析技术远没有组件驱动的技术那么成熟。因此，形式化技术较少，而且它们之间的差异较大。本指南介绍了 NCSC 认为这些技术的共同特征，并解释了它们可以增加哪些价值。
任何系统驱动的风险分析技术都应该从功能的阐明以及您希望避免的损失开始。您通常期望看到一个迭代过程，通过将功能语句分解为子系统（每个子系统都有自己的功能）并演示这些子系统如何相互控制和通信，从而增加该功能语句的复杂性。在每个迭代阶段，您将探索任何可能的损失风险，在此过程中，您将制定安全要求以避免这些风险。
谈论技术系统的网络安全风险的一个重大障碍是组织和分析师在正确分析系统级别之前快速转向组件级别思考的诱惑。这就是为什么我们建议组织通过在系统和组件级别上了解网络安全风险来获得对其所面临的网络安全风险的最佳视角。
常用的系统驱动的网络风险管理方法和框架
本节简要描述一些系统驱动的网络风险管理方法和框架。
- 我们提供了每种技术的具体指南的链接。这些提供了有关每种技术如何工作以及它们如何增加价值的更多详细信息。
- 还有更多应用这些原则的技术（此处未列出）。下面包含的三个（我们认为）最好地说明了这些类型的技术之间的差异。
STPA
STPA（系统理论过程分析）是 STAMP 框架的一部分，它是对事故原因进行建模的技术集合。它是由麻省理工学院的 Nancy Leveson 教授和她的同事开发的。虽然 STPA 最初专注于安全，但后来它已适应许多其他环境，其中一些适应网络安全要求。
托加夫
TOGAF（The Open Group Architectural Framework）是 The Open Group 开发的商用架构框架。虽然它本身不是一种风险管理技术，但它借鉴了许多与系统驱动的风险分析框架（例如 STPA）相同的想法。它是一种企业架构标准，旨在提高业务效率和管理风险，例如寻求提供更好的投资回报、减少管理费用和改进采购流程。该框架基于迭代过程模型，可以单独或与其他框架集成在整个组织的不同级别实施。TOGAF 支持我们的指南中描述的自上而下（系统驱动）和自下而上（组件）的风险管理方法。
南非标准协会
南非标准协会是一个业务驱动的安全架构框架，高度关注组织如何为利益相关者创造价值。正如 TOGAF 所指出的，虽然 SABSA 主要不是一种风险分析技术，但它借鉴了许多相同的系统概念。从组织价值链的独特配置开始，SABSA 框架帮助分析师将流程分解为多个业务架构层。这些层依次向下发展为业务能力、业务流程、业务服务，并从那里向下进入技术服务。SABSA 要求分析师解决每一层的风险，以便在“堆栈”顶部定义的需求能够向下继承并在每一层得到解决。