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