第五章 系统方法---------基于业务驱动的企业安全架构（翻译，原作者John Sherwood）----仅学习使用

第 5 章：系统方法

安全架构的合理合理设计是通过采用系统方法来实现的。 这将确保最终结果与业务需求一致，并确保设计过程得到正确执行。 本书所提倡的系统方法基于成熟的系统工程原则。

在本章中，您将了解：
 “系统工程”一词的含义；
 系统方法中用于简化复杂性的基本技术，包括：子系统； 自顶向下分解、黑盒建模和逻辑流分析；
 系统方法所暗示的行为类型：良好的文档、同行评审和良好的沟通；
 系统方法的基本概念：目标、环境、资源、系统的各个部分、它们的活动、目标和绩效测量，以及系统管理；
 反馈控制回路的控制系统概念，用于许多安全子系统；
 高级系统建模技术：业务流程工程、依赖树建模和有限状态机建模。

5.1. 系统工程的作用

前面的章节讨论了企业内部信息系统结构化设计的必要性以及企业安全架构的后续实现。 这样的架构应该
 满足您定义的目标（要求）；
 在系统环境中成功运行；
 易于管理，系统性能可衡量。
 开发这样的架构要求您应该：
 清楚地了解您要保护的系统的边界；
 就如何实现架构做出合理且可追溯的决策；
 在开发过程中始终考虑系统的所有方面，以便在影响最小的情况下识别和纠正缺陷。

由于企业在数字商业世界中的生存可能取决于您安全地设计和实施系统的能力，因此您需要采用一种方法来支持您进行此练习。 最相关的方法是系统工程。 Boardman 将系统工程定义为“与解决工程规划、设计和运营中的复杂问题相关的决策的合理方法”。

定义和扩展系统工程及其相关技术的实践远远超出了本书的范围。 事实上，Checkland 在他对软系统方法论的 30 年回顾中指出：“SSM 的评论员对它的服务很差，其中许多人（原文如此）显然是基于对主要文献的粗略了解而写作的”。

作者当然不希望落入那个陷阱！ 在本章中，他们只是寻求促进系统思维的实践，引导安全架构师采用系统方法来考虑安全架构的分析和设计。
本章借鉴了几种系统工程实践，并扩展了那些为安全架构师提供令人满意的设计和实现的实践。

5.2. 为什么是系统方法？

5.2.1. 管理复杂性

几乎总是商业信息系统是高度复杂的。 一个复杂的领域是经常需要将新系统与遗留系统集成，而遗留系统本身自最初设计和实施以来经常有机地增长。 最重要的是，新系统本身通常非常复杂，尤其是随着对技术可以实现的期望一直在提高。 您必须拥有使这种复杂程度易于管理的技术。

5.2.2. 自顶向下分解

系统方法从根本上将整个系统视为由许多较小的子系统组成。 其中每一个（本身就是一个系统）都可以进一步分解为子系统，依此类推。 这被称为系统的自顶向下分解。 这提供了一种掩盖复杂性并在每个分解级别向架构师或设计师呈现相对简化的视图的方法。 建筑师或设计师可以专注于狭窄、简化的视野，而不会陷入忽略整体复杂性等更广泛问题的陷阱。 每个层次的分解都代表一个可管理的工作。 如果你想吃一头大象，那么唯一的办法就是把它分成小块，一次一个。

5.2.3. 黑盒建模

自上而下分解过程的另一个隐含结果是每个系统组件（每个子系统）都被视为一个黑匣子。 这意味着您看不到盒子里面的东西。 它的内部运作是隐藏的。 您只需看到盒子有输入和输出，并且盒子对输入执行一些定义的功能，将输入转换为输出（见图 5-1）。

图5-1 黑盒概念

这个黑盒概念还可以帮助您以更简单的方式看到复杂性。 您可以接受黑盒作为系统的一个组件，展示一个定义的功能，具有与其他类似组件（同一分解级别的其他黑盒）的定义接口。 在另一个时候，您可以查看盒子内部以检查下一个细节级别，在那里您可能会发现功能更精细的更小黑盒子，等等。

因此，通过自上而下分解成黑盒子系统，系统可以被分析成多个层次，每个层次都有不同的细节粒度，每个层次都为建筑师或设计师提供了一个简化的、集中的工作领域。

5.2.4. 逻辑流分析

接下来要认识到的是系统具有逻辑流程。 这种逻辑流的分析与已经描述的分解过程密切相关。 在每个分解级别得到的是一系列黑盒组件，每个组件都有功能和接口，以逻辑流模式链接在一起，使得一个盒子的输出成为下一个盒子的输入，依此类推。 图 5-2 提供了一个图形示例。

图 5-2：将系统分析为子系统的示例

这些是系统方法有助于简化复杂性并提供结构化框架来思考系统和设计系统解决方案的一些基本方法。

5.3. 系统方法让你做什么？

5.3.1. 记录想法

遵循系统方法可以让你做几件事 — 其中一件可能是描述起来最简单的任务，也是执行起来最具挑战性的任务——写下你真正需要的东西。

这是一个不言而喻的事实，如果你不能把它写下来，你就没有考虑清楚。 经常有人会在演示中遇到在规划的早期阶段描述新项目的情况，而演示者并没有真正理解他们提出的系统的范围和相互依赖性。 写下这些早期想法的简单行为会迫使您识别系统的整个上下文并识别问题区域。

“写下来”是指使用上述基本建模技术的系统的描述性文本、项目符号列表和图解表示的混合体。 有时需要更高级的建模技术，本章稍后将更详细地探讨其中的一些技术。

5.3.2. 同行评审

一旦模型和描述被开发成初稿，问题区域就会被识别出来。

系统方法还提供了解决这些问题并管理其解决方案的机制。

结构化审查和反馈是一个允许识别问题、可能的解决方法和细化系统目标的过程。 这是一个同行评审过程，审查一个人或团队的所有综合，使其接受另一个具有类似专业地位的人或团队的分析和建设性批评。 这种方法使整个团队的思维更加敏锐，并积极促进协作团队合作。

5.3.3. 交流想法

通过正确定义和记录系统，系统方法允许您将您的想法和方法传达给需要在项目规划和执行中考虑它们的其他人。 建模技术是这个沟通过程的关键部分。 关键的描述性信息不仅可以在短期内保存，而且还可以以有利于后续项目和现有项目审查的形式保存。

本书后面的章节将向您展示如何在开发安全架构时逐步遵循系统方法。

5.4. 安全架构中对系统工程的需求

正如博德曼所展示的，系统工程提供了对由大规模系统引起的复杂问题的平衡调查和解决。

随着企业在 21 世纪初的发展，企业变革背后的主要技术影响是电信的重大改进带来的全球化水平的提高。 企业现在可以通过互联网在全球范围内与他们从未见过的各方实时进行商业交易。 电信的这种爆炸性增长带来了所使用机制的日益复杂性。

如果不能清楚地理解流程和机制的相互依赖性，这种复杂性可能会破坏业务的稳定性。 这适用于整个系统，尤其适用于安全架构。 毫无疑问，这些新的业务系统规模庞大，并且在设计、实施和运营中产生了复杂的问题。
系统工程可以提供一种严谨而连贯的方法来理解这些复杂的问题及其适当的解决方案。

5.4.1. 一些基本概念

系统的概念意味着组件的集合，这些组件以某种方式共同作用以实现一组（声明的）目标。 在思考系统的意义时，Boardman 给出了一组五个基本考虑因素：
 总体系统目标；
 系统环境；
 系统资源；
 系统的各个部分、它们的活动、目标和绩效衡量标准；
 系统管理

目标
您将系统目标表达为系统应满足的业务需求。 在制定这些要求时，最重要的是要适当考虑如何测量系统的性能，以证明系统满足这些要求的程度。 如果你不能衡量你是否达到了目标，那么你就没有充分管理解决方案 — 后面的部分会详细介绍。

根据作者的经验，系统设计人员经常从一组技术要求开始，这些要求不能准确反映业务需求，也不能轻松进行合规性测量。
如果陈述系统目标的任务没有正确完成，那么最终的设计和实现可能充其量是足够的，最坏的情况是完全无用。

环境
如果您认为您正在设计的系统是有界的，并且您可以控制边界内的那些元素，那么环境代表系统边界之外但系统必须在其中运行并且对其运行有影响的区域。 图 5-3 以图解方式显示了这一点。 系统设计者虽然无法控制环境，但必须认识到其影响并设计系统以对其做出适当响应。

资源
系统资源位于系统边界内，是系统运行和实现其目标的手段。 例如，在简单的信息系统术语中，它们由处理信息的机器、它们的操作员和用户、驱动它们的动力以及它们使用的消耗品来表示。

图 5-3：系统及其环境

系统的组成部分：子系统
子系统作为超系统的组成部分的概念已经在本章前面部分介绍过。 系统工程中的一项主要活动是将大型系统分解为较小的组件（子系统），其行为可以根据整个系统的目标进行建模和测量。 通过承担这项任务，系统架构师能够降低整个系统建模的复杂性，从而更容易理解系统行为。

根据作者的经验，在委派子系统的设计和实施时维护整体系统目标经常被忽视。 这可能会导致子系统的开发在满足其整个设计概要的同时无法满足业务期望。 正是这种错误可以通过勤奋地使用系统工程来避免。

管理
为了管理一个系统，您首先必须能够根据系统目标来衡量它的性能。 这意味着一组可测量的系统参数以及测量和报告它们的方法。 测量和度量将在下一节中更详细地讨论。

系统管理包括广泛的活动：
 设定系统目标；
 针对这些目标收集系统性能指标；
 分析和评估指标；
 制定和实施决策（设计决策和运营决策）
 基于分析和评估；
 如有必要，审查和重新设定目标

因此，系统的运行和性能计划应确保其实现其目标，并进行适当的审查以确保系统保持最佳性能。

在这种情况下，“绩效”有一个非常广泛的解释，意思是“实现所有系统目标”。 有明显可衡量的性能属性，例如吞吐量、延迟、响应时间、正常运行时间百分比等，但在这个更广泛的解释中，还包括了许多其他属性，这些属性通常不会与性能概念相关联。 例如，维护业务信息的机密性、保护其完整性以及让用户对其行为负责，这些都是您可能期望被指定为安全架构的一部分的系统目标。 因此，系统管理还意味着对系统在实现这些和其他类似目标方面的表现感兴趣。

抽象系统属性的概念在本书描述的 SABSA ® 方法中被广泛使用。 在第 6 章中，您将遇到这种类型的大量业务属性的完整定义。 这种技术不仅允许您将任何实际业务模型规范化为基于标准抽象业务属性的概念模型，而且它还提供了一种机制，您可以通过该机制根据目标来衡量性能。 对于每个业务属性，都建议了合适的度量标准和衡量这些指标的方法（参见第 6 章）。 由此，您可以评估安全架构是否确实满足了既定目标，以及是否需要以某种方式对其进行更改以更好地执行。

5.4.2. 控制系统概念

在任何管理得当的系统中，都有某种类型的控制回路。 控制系统的研究本身就是一门复杂的学科，包括反馈控制回路、前馈控制回路和许多其他更先进的控制系统概念。

本章只介绍其中最简单的一个 — 反馈控制回路 — 因为它是迄今为止你会遇到的最常见的控制概念。 图 5-4 显示了一个非常简单的反馈控制回路的示例。

图 5-4：系统中的反馈控制回路

在此示例中，系统包括三个子系统（可能还有其他子系统，但本次讨论仅关注反馈控制回路）。 这些是：
 控制子系统 - 施加控制（例如，在加热系统中，通过打开或关闭加热，或通过增加或减少热输出速率来控制产生多少热量的组件）
 监控和测量子系统 - 测量系统的状态，而系统状态又受到控制子系统的影响（例如，在加热系统中，测量温度的组件）；
 决策子系统 - 根据测量子系统提供的测量结果做出决策（例如，在加热系统中，决定温度是高于还是低于设定点的组件）；

信息不断反馈。 控制系统更改某些系统参数并将它们设置为某些级别。 由于此操作，系统状态会发生变化。 监控测量子系统测量并报告新的状态。 该信息被馈送到决策子系统，该决策子系统决定新状态是否是所需状态（设定点）。 如果是，那么它将调用控制子系统不做任何事情。 如果报告的状态不令人满意，那么它会调用控制子系统带来更多的状态变化，直到达到设定点。 测量值被反馈给决策模块，决策模块将指令反馈给控制模块——因此称为“反馈回路”。

这种控制回路概念对于管理业务系统的安全性至关重要。 在后面的章节中，您将看到许多应用这个基本系统概念的例子。

5.5. 在安全架构中使用系统方法

通过专注于帮助您理解系统的关键概念，您将被引导考虑在设计时相关的领域，例如，新的安全业务应用程序。

5.5.1. 广泛的战略目标

应用程序的目标（业务需求）应与发起组织的整体战略业务需求保持一致。 应用程序的简介往往是狭隘的，并迫使设计进入一个僵化的、战术性的实现，随后无法更改以提供最初预期的真正好处。 例如，与其他系统的互操作性和用户界面的一致性是更广泛的战略需求类型，如果项目规范具有非常战术性的重点，这些需求往往会被忽视。 正是通过一系列目标范围太窄的“战术项目”，企业往往发现自己面临着多样化的技术环境和高昂的总体拥有成本。

5.5.2. 环境影响

系统周围环境中的某些元素可能超出系统架构师的控制范围，但对系统实现其目标的能力有重大影响。 对于建筑师来说，仅仅因为它们超出了他或她的控制范围而忽略这些元素是一个严重的缺点。 必须认识到这些元素的存在，并且必须将它们包含在系统建模中，因为系统必须对它们做出响应并在它们施加的约束内运行。

例如，可能使系统安全面临风险的威胁是系统环境的属性——它们来自外部。 但是，可能被威胁利用的漏洞是系统本身的属性——构建或操作方式的弱点。 系统设计者必须认识到存在的威胁，并且作为响应必须设计一个系统，在该系统中对这些威胁的脆弱性在一定的成本限制内被最小化。 如果您忽略这些威胁，就不可能了解可能存在哪些漏洞。

5.5.3. 简化复杂性

通常情况下，系统的各种组件可以分解为更小的自包含子系统。 通过这个过程，系统架构师可以确保逻辑上相关的功能一起实现，从而允许单独测试子系统以确认其目标的符合性。 通过这种类型的操作，可以简化整个系统测试的复杂性。

5.5.4. 根据目标衡量绩效

该系统的管理是其运营成功的核心。 该功能的一个关键方面是收集性能数据，以确保系统按照目标运行。 重要的是在管理过程中包括足够的有意义的监控和测量，以允许进行这种调节。

5.6. 案例分析

这里介绍的是一个客户端应用程序的描述，在该应用程序中，由于缺乏系统方法导致设计人员采取了错误的行动方案，未能提供符合业务需求的好处。

5.6.1. 概述

IBFS 的证券交易部门（见第 4 章）运行了一个金融交易应用程序，市场分析师用来收集和整合证券市场的信息。 最近的一次例行内部审计显示，最初在本地连接终端上的主系统处理器上进行的系统管理已经升级，允许管理员从任何用户终端远程登录。

由于系统现在已改为在国际范围内运行（以前的设计仅限于一个办公室），远程管理员的登录凭据（用户 ID 和密码）正在通过不受信任的网络以明文形式发送。 事实上，所有其他用户的登录凭据也在同一个网络上以明文方式传输。

在网络上传输的应用程序数据不被认为是敏感的，因为它被认为是公司正在后处理和合并以供内部使用的公共领域材料。

审计观察强调，公司安全政策要求所有用户密码在通过不受信任的通信链路发送时都进行适当加密。 因此，客户计划的补救措施是在网络的所有入口点安装硬件加密设备，以便对这些凭证可以通过的所有路径进行加密，从而防止它们在传输过程中受到损害。

本案例研究从一个咨询团队的角度进行了审查，该咨询团队被要求提供支持，以帮助规划该全球加密方案的设计和实施，正如审计报告所建议的那样。

5.6.2. 初步观察

首先注意到要保护的数据路径的范围在全球范围内扩展。 通过加密整个数据传输带宽来保护这个网络将非常昂贵并且在操作上不切实际。 网络的动态特性意味着网络路由会随着时间而改变，因此加密设备几乎需要持续维护。 以系统的方式考虑问题揭示了一些有趣的信息：

5.6.3. 系统范围

一个有趣的问题 — 应该如何“绑定”这个系统？ 事实证明，最初的应用程序设计者的任务是制作一个应用程序：

在桌面上为市场分析师提供来自三个来源的综合财务信息；
允许市场分析师访问公司历史财务信息的研究数据库；
在英国境内运营，使用现有的通信基础设施，但能够在国际上扩展；
是根据公司的标准安全操作实践开发的。

顾问们首先尝试评估出了什么问题。 是什么导致了不利的审计报告？

 缺点分析

1. 该系统没有结构化或正式的规范。 它是使用快速应用程序开发 (RAD) 方法在相应较短的开发时间内构建的。 系统文档仅限于管理和用户手册。
2. 很明显，最初的设计者将系统的原始范围仅视为金融交易应用程序。 他们交付了一个系统，根据他们有限的职权范围，该系统是成功的。 然而，通过仅考虑这组有限的功能，他们提供了一个单点解决方案，虽然单独为这个应用程序工作，但并没有为整个组织带来最大的利益。 它当然没有为支持未来扩展的业务需求提供任何灵活性。
3. 系统边界的最初概念是短视的。 将系统边界扩展到整个公司，并考虑与金融交易应用程序相关的真实业务需求，提供了截然不同的观点。
   咨询团队现在重新定义业务需求，采取更具战略性的观点并寻找超越当前战术需求的更广泛的业务需求。

 业务需求
该应用程序带来的真正商业利益是通过整合大量实时财务数据以及存储在公司自己的数据库和其他研究数据源中的历史趋势信息。 为交易者提供如此全面的画面，增强了他们根据最完整和最及时的可用数据做出合理交易判断的能力。 主要的业务需求很简单：

1. 该公司通过在相关市场上及时交易各种证券来赚钱，因此希望最大限度地提高成功机会。 它的交易范围受到限制，并希望扩大到全球市场的交易，而不是当时对其开放的有限市场。
2. 它目前的主要贸易区办公空间成本高昂，它希望更好地利用它在该国其他地区已经拥有的设施。
3. 它希望确保它使用最新和正确的信息作为其交易的基础，以最大限度地提高回报。
4. 它希望降低运行其计算机网络的间接成本，因为这开始主导其运营费用。
5. 它希望尽快通过使用额外的训练有素的员工来增加其进行的交易数量。
   接下来，通过采访管理团队，顾问从这些广泛的战略业务需求中得出一些新的特定系统目标。

5.6.4. 总体系统目标

该系统应：
 以最小的延迟向市场分析师提供实时财务信息。 在任何情况下，这种延迟都不应超过信息提供者提供的 5 秒。
 确保市场分析师收到的信息正确、完整。
 在分析师承诺在其屏幕上进行交易后的 5 秒内，根据用户请求进行交易。
 支持 100 个并发用户而不降低性能，最多支持 150 个用户，响应时间减少不超过 30%。
 能够增强和升级以支持更多用户，而无需更改基本系统架构。
 在正常工作周内 99.99% 的时间都有空（定义为周一在亚洲开展业务，周五在美国结束业务）。
 在正常工作周内，公司全球任何办事处的任何授权用户都可以完全访问。
 根据公司合规监控的需要进行操作，包括通过提供所有交易者行为的防篡改审计跟踪来为所有交易提供全面责任。
 使用最具成本效益的计算和通信基础设施，而不会影响公司安全策略中定义的安全性。

最后两个要求是接受采访的业务经理认为与安全相关的唯一要求——实际上所有要求都与安全有关，但只有最后一个反映了最初要求团队审查项目的原因（密码问题 ）。 事实证明，作为适当的整体系统设计的一部分，这个问题很容易解决。

5.6.5. 设计审查：识别的功能问题

1. 根据对要求的审查，很明显原始设计没有洞察信息交付及时性的必要性。 事实上，对操作系统的审查表明，财务信息在需要后两分钟就被传送到桌面。
2. 在英国以外的地区没有计划扩展该系统。 最初的申请似乎是通过一位业务经理的部门研究基金资助的，并且不鼓励她花费超过她绝对需要的费用来满足部门的需求。
3. 该系统的硬编码最多为 64 个用户。
4. 尽管正在处理的信息的正确性和完整性被用来驱动交易过程，但系统内没有检查以确保所传递的关键业务信息的完整性。
   回顾本章前面关于需要考虑系统环境以及系统本身以及系统可用资源的讨论，咨询团队发现这些是与设计背后的原始思维有关的主要问题 这个系统的。

5.6.6. 设计审查：系统环境

该系统使用了第三方供应商提供的通信基础设施。 公司与供应商之间似乎没有服务水平协议。 从未讨论过支持所需交易周转的网络响应时间。

5.6.7. 设计审查：系统资源

托管交易应用程序的硬件由许多应用程序共享。 有一种简单的循环形式的任务调度，可确保所有任务都按顺序运行，并且它们都获得了一些可用的处理和 I/O 份额。 主处理器配备了不间断电源 (UPS) 和容错硬盘。

交易员的台式机没有配备 UPS 或任何形式的容错存储。 但是，该应用程序使用交易者机器上的本地存储来缓存发送到主处理器和从主处理器接收的信息。
咨询团队现在着眼于如何管理设计的复杂性以及如何衡量目标的实现情况。

5.6.8. 设计审查：子系统、它们的活动、目标和绩效衡量标准

系统文档没有说明设计是如何分解为最高级别子系统以外的任何其他系统的——主要是主处理器和交易者的处理器。

在简化用户界面方面已经做了大量工作，以确保向分析师提供的信息清晰明确。

没有尝试为主处理器组件或交易者组件生成任何形式的性能模型或可用性模型。

5.6.9. 设计审查：系统管理

系统管理员负责系统的管理。 文档中定义的主要管理任务是管理用户帐户（添加、修改、删除）并将系统数据定期备份到磁带上。

没有可用的性能测量工具可以显示系统的运行情况，也没有简单的审计工具可以显示用户在系统上处理交易时的行为。

咨询团队现在拥有分析和报告原始系统设计问题所需的所有信息。

5.6.10. 设计的关键缺陷

在审查业务需求时，最明显的是对该系统的高性能、高可靠性和高完整性的压倒性需求。 在之前的任何阶段，公司都没有看到需要生成任何形式的系统性能或可用性模型来审查它如何满足规范和业务需求。

特别令人感兴趣的是外包（外部）通信基础设施的安排。 使用这项第三方服务的决定是由信息系统部做出的，目的是降低成本并使业务能够专注于核心业务。 这符合公司的整体业务战略，但由于没有与供应商签订正式的服务水平协议，这意味着该系统组件的性能完全不在公司的控制范围内。 此外，没有审查过该决定如何给使用基础设施的应用程序带来业务风险。

咨询团队的建议是，应根据适当的系统方法进行全面的重新设计，同时考虑到组织的更广泛要求。

5.6.11. 使用系统方法重新设计系统

IBFS 并未完全致力于遵循系统方法来重新设计整个业务（这种情况经常发生），但准备使用反映高级需求的系统方法来赞助交易系统的重新设计 的业务作为一个整体。

留给读者比较和对比实际业务需求与初始实现中考虑的业务需求有何不同，以及早期的结构化工作可能会有什么不同。

5.6.12. 结论

很明显，最初的应用程序在设计和实现时具有非常有限的界限。 特别是没有适当考虑系统在整个业务范围内的作用。 结果，完整的应用程序实现了其原始规范（作为业务子系统）的精神，但如果它是系统思考的主题并且业务具有 采用了系统方法。然而，公平地指出，这种额外的严格可能会对整个项目预算产生影响，但您通常不会得到比您准备支付的更多的费用。

5.7 高级建模技术

对于那些具有深厚技术背景或兴趣的人，这里包含了有关一些更高级的系统建模技术的部分。 如果您的前景不是特别专业，那么您可以选择跳过其中的一些材料。 这三个部分按难度递增的顺序排列：业务流程工程、依赖树建模和有限状态机。 在每种情况下，该部分仅提供简要概述。 如果您想进一步研究这些技术，那么您将需要寻找有关每个主题的专业文本。

5.7.1. 业务流程工程

业务流程工程或业务流程再造是将系统方法应用于业务本身的架构。 业务流程是一个系统（或子系统），它接受输入并将其转换为对业务有价值的输出。
业务流程示例如下：
 用原材料制造食品；
 用零部件和子组件组装汽车；
 针对客户银行账户的主数据库处理交易数据。

在涉及业务流程工程练习的任何典型企业中，您可能希望它们定义某些常见的流程。 这些可能包括：
 获取客户订单；
 履行客户订单；
 从客户那里收取收入；
 制造产品；
 获取和储存原材料；
 支付供应商。

还将至少有一个特殊的流程本身用于管理业务流程。 这样的进程管理进程称为元进程。 有时，最高级别的流程被简单地表达为：销售流程或制造流程，在某些文本中，这些也被称为元流程。

使用已经讨论过的自上而下的分解方法，这些高级过程中的每一个都可以被分析为子过程，并且在每个分解层次上，都有可能将分解进一步细化。 分解级别的确切数量将取决于企业实际需要什么才能成功设计流程。

为什么这个这么重要？ 业务流程工程的当前时尚是由业务功能模型的明显失败以及在引入新技术时使用技术解决方案复制手动流程根本行不通的事实推动的。 新技术的引入为围绕技术彻底重新设计业务流程提供了机会和动力，从而发挥其真正的力量。

首先考虑业务的功能模型与流程模型。 功能模型根据人们的工作来组织企业。 有销售部、生产部、财务部等，各有不同的职能。 这种模式的问题在于，没有一个部门可以监督业务运作的真实方式。 真正的业务是一系列流程，每个流程在此过程中调用不同的功能。 因此，称为履行客户订单的流程可能涉及多个部门职能：

销售部门有客户订购的信息；
 生产部门必须生产；
 质量保证部门必须检查；
 仓库部门必须保管；
 物流部门必须安排发货。

哪个部门有整体控制权？ 他们都没有！ 这就是问题所在。

另一方面，在结束基础之上，如果业务是按业务流程组织的，那么有一个流程负责人负责监督每个流程的成功运行，确保各个功能相互协调，从而端到端地交付流程。

这对业务连续性管理有重大影响，详情见第 17 章。

5.8. 业务流程失败案例研究

5.8.1. 出租车失踪案

一家电视广播机构的工作室位于首都，距中央政府办公室和议会大楼数公里。 时事节目要求政客定期访问制片厂进行采访，通常是在短时间内响应突发新闻。 大多数政客往返工作室的方式是乘坐出租车。

运行时事项目的整个业务流程涉及到许多职能部门，但它并未被视为一个业务流程，其对组织整体成功的关键性也未得到评估。 更具体地说，流程中各个功能的重要性没有被理解，没有人拥有整个流程的所有权。

一位位于工作室大楼地下室的女秘书执行一项特定职能。 她过去常常安排将政客们送进和送出大楼的出租车。 她在设施经理工作，这是一个职能部门，负责管理大楼的整体工作并负责大部分辅助服务——比如叫出租车。

在注重成本的世界中，每项工作都需要进行审查——真的需要吗？ 设施经理查看了他的员工人数。 有一个女人，她唯一的工作就是叫出租车！ 如果有的话，这肯定是过度的奢侈——人们可以自己订出租车——所以她被“放弃”了。
发生了什么？ 让政客准时到演播室接受采访的整个过程分崩离析。 时事版块的核心业务目的一夜之间就被破坏了。

教训是……确保端到端关键业务流程中的每一个功能都具有与其支持的整个流程相同的关键级别。 您只需要在流程中间的一个功能失败，整个流程就被破坏了。 此外，在业务流程工程不是文化的一部分的环境中管理业务连续性的任何尝试都具有值得怀疑的成功机会。

 业务流程工程方法的一些主要好处是：

1. 为流程的每个阶段提供成本核算的能力：
2. 计算过程的总成本；
3. 识别高成本子流程；
4. 通过自动化、集成、重新排序或外包寻找替代的、成本更低的子流程实施方案。

 对每个流程进行价值链分析的能力：

1. 了解企业在哪里增加了真正的价值（即核心业务）；
2. 了解哪些活动或子流程可以外包，因为它们没有增加真正的价值（即不是核心业务）。

 进行过程分析的能力：

1. 测试重新排序子流程是否可以节省执行时间或运营成本；
2. 评估每个级别的子流程失败的风险，从而寻找更健壮的易受攻击的子流程的实现；
3. 识别过程中的重要控制点；
4. 消除隐藏的不必要的复杂性；
5. 为了确保所有决策点清晰，决策参数在决策时是已知的，并且决策标准是明确定义的。

5.8.1.1 依赖树建模

这种技术提供了一种方法来检查系统行为受一系列相互依赖性影响的方式。 高级系统（或超系统）依赖于低级子系统的功能。 但是，这些依赖项的工作方式取决于它们的组合方式——串联或并联。

如图 5-5 中的简单系统。 它包括两个串联运行的子系统。 子系统 A 和子系统 B 都必须运行才能使整个系统正常工作。 该系统依赖于 A 和 B 的功能。

图 5-5：串联的子系统 – AND 关系

如图 5-6子系统是并联的。 如果这些子系统中的任何一个正在运行，那么整个系统正在运行。 系统依赖于 A 或 B。

图 5-6：并行子系统 - OR 关系

系统故障，因为如果一个组件发生故障，另一个组件将继续为系统提供服务并使其继续运行。

这些基本思想已由 Concept Laboratories Limited 的 John Gordon 教授开发成复杂的依赖建模工具集。 它的主要应用之一是计算复杂系统中的风险。

5.8.1.2 有限状态机模型

考虑一组交通灯。 系统可以处于以下三种状态之一：红色、琥珀色或绿色。 您一次只有一个状态，它们是互斥的，并且有有限数量的可能状态，所有这些都可以描述。 从一种状态变为另一种状态称为状态转换。 从一种状态到另一种状态的转换是由事件引起的。 在交通信号灯的情况下，当进入新状态时，会设置一个内部计时器。 当计时器用完时，灯光将变为下一种颜色。 在每个稳定状态下，系统都会等待一个事件。 在更复杂的交通信号灯系统中，车辆接近也可能产生事件。 状态转换图可用于表示状态序列和状态转换。 请参见图 5-7。

图 5-7：交通灯的状态转换图

状态转移图在外观上与本章前面讨论的逻辑系统流程图相似，但在这种情况下，图的含义完全不同。 以下部分解释了术语和含义。

当一个系统被建模为一个有限状态机时，它被概念化为一系列稳定的状态，在这些稳定状态中，系统可以不时被发现存在。 在任何给定时间，系统仅处于这些可能状态之一。 每个状态由多个状态变量的值描述。 （在交通灯的情况下，会有一个名为 lightColour 的状态变量，它具有三个可能的值：红色、琥珀色或绿色）。 系统从一个状态改变到另一个状态，由事件触发，例如外部中断或内部定时器到期。 状态的变化称为状态转换。 在改变状态时，部分或全部状态变量的值会发生变化。

使用术语“有限状态机”是因为，对于给定的系统，它只能找到有限数量的状态。 因此，在开发有限状态机模型时，设计人员应首先确定所有可能的状态。

一些传入事件可能会导致许多可能的传出事件。 适当的传出事件的选择由一个或多个谓词的值控制。 这些是布尔变量，其值为 true 或 false。 通过 AND、OR、NOT、NOR 和 XOR 操作组合这些谓词的逻辑表达式被评估以确定要选择哪个传出事件。

响应传入事件所需的一些操作是本地的，而不是传出事件。 这些被称为“具体行动”。 它们可以包括诸如“启动计时器”或“增量计数器”之类的操作。

有限状态机以“原子”模式运行。 这意味着状态是不可分割的。 系统处于一种或另一种状态，但不能介于两种状态之间。 这也意味着当发生将导致状态转换的事件时，必须完整处理与该事件关联的所有函数，然后才能接受另一个事件进行处理。 在此处理完成之前，任何进一步的事件都必须排队。

什么类型的系统应该被建模为有限状态机？ 这种建模最常见的候选类型是两个或多个子系统之间的交互式通信协议。 事实上，如果这样的系统在设计时没有产生有限状态机模型，很可能在某个阶段系统会失败，因为它进入了设计者没有预见到的状态，也没有计划采取的行动！

您在安全架构中发现的交互式通信协议示例包括：
 加密协议；
 身份验证协议（例如密码协议）；
 握手协议；
 分布式数据库中的两阶段提交协议；
 用于分发、复制或复制某些安全相关的任何协议
 数据（可能用于备份目的）；
 两个应用子系统之间的任何同步协议。

5.8.2. 有限状态机案例研究

5.8.2.1 密码认证协议

考虑一个简单的密码验证协议，用户通过该协议登录到计算机应用程序。 为绝对简单起见，这种安排被概念化为具有两个子系统的系统：证明者（必须证明其身份）和必须验证证明者身份的验证者。

有一个初始注册协议，通过该协议将新的证明者引入验证者并在验证者的已知证明者数据库中注册。 这个协议本身需要被建模为一个有限状态机，以确保它是完整和健壮的。 然而，这里假设这已经实现并且验证器已经拥有已知证明者的数据库。 图 5-8 显示了所描述的系统。

现在考虑证明者。 这个子系统有多少种可能的状态？ 必须包括以下状态：
 IDLE空闲状态——什么都不做；
 WFLP 状态——等待一个传入的“登录提示”事件后传出的“唤醒”事件；
 WFID 状态 - 在“登录”后等待传入的“用户输入 ID”事件提示”事件；
 WFPP 状态 – 等待传入的“密码提示”事件后‘用户输入ID’事件；
 WFPW 状态 – 等待“用户输入密码”事件后“密码提示”事件；
 WFLC 状态——在“用户进入”后等待“登录完成”事件密码事件；
 WFLO 状态——在“登录完成”事件后登录并工作，因此等待“注销”事件或“活动超时”事件或“会话超时”事件。

图 5-8：密码认证系统

这个相当基本的状态模型是您可能遇到的状态类型的一个很好的例子。 您可能还想包含其他内容，因为这里没有对错误条件（例如不正确的 ID 或密码）或任何中间状态的个别超时进行分析。 为了构建一个真正强大的系统，必须识别每个可能的状态和每个可能的事件并将其包含在模型中。 这个例子保持简单，以展示该技术的某些方面，它并不是关于有限状态机建模的综合教程。
状态转换图如图 5-9 所示：可以直观地展示事件、状态以及从一种状态到另一种状态的转换之间的关系。

除了状态转换图，模型的其他方面也通过一系列表格记录下来。 这些表格包括：
 传入事件表——描述事件名称、接收事件的接口及其含义；
 传出事件表——描述事件名称、发送事件的接口及其含义；
 状态表——描述状态及其含义；
 谓词表——描述谓词名称及其含义和值；
 特定动作表——描述本地特定动作；
 状态变量表——定义状态变量、它们的数据类型和它们的取值范围；
 事件/状态表，将所有可能的事件映射到所有可能的状态，并在每个状态上显示每个事件的结果。

图 5-9：状态转换图

现在考虑验证器子系统。 这个这里就不详细分析了，但是可以很快的看出 Verifier 有一套比较复杂的状态和状态变量需要维护。 验证器必须处理密码的到期，然后需要更改密码，这涉及要建模的另一个协议。 验证者还必须处理帐户到期、帐户被阻止（因为已经进行了三次以上的尝试以获取正确密码），并且必须处理所有可能出现的错误情况，等等。

有限状态机建模技术提供了可以系统地、系统地和完全地完成此任务的工具。
有限状态机建模是一个非常强大和先进的工具。 它为系统工程师和架构师提供了精确分析交互式系统中非常复杂的交互的方法。 如果没有这种技术，人们是否能够构建这种类型的健壮交互式系统是值得怀疑的。 使用这种方法，设计人员可以建立交互式系统的详细模型，其中需要对其功能进行高度保证。

几种类型的系统需要高水平的保证：
 安全关键系统，故障可能导致生命或伤害；
 高安全性系统，故障可能会对业务产生巨大影响；
 基本的基础设施系统（如数据通信网络），支持广泛的业务应用程序，是业务运营连续性的基础。

5.8.2.2 详尽的模型检查

为了获得最高级别的保证，系统应首先建模为有限状态机。 然后应该通过自动模型检查器处理模型，该检查器将检查每个可能的状态和每个可能的事件，以确保模型真正健壮。 但是，如果模型不正确（例如，缺少特定状态或事件），则模型检查器通常无法检测到。 可能需要其他技术（例如正式规范语言）来证明模型本身的正确性，但这些都超出了本书的范围。

本章介绍了有限状态机建模的主题并解释了它的主要概念，但这并不是关于如何使用有限状态机模型的全面教程。 建议那些希望进一步研究的人参考有关该主题的文献。 大多数关于数据通信协议的严肃文本都包含处理这种方法的部分。

5.8.2.3 其他高级建模技术

在本书中，本章描述的许多系统建模技术都应用于各种环境。 后面的章节将介绍一些非常特定于安全架构建模的新的高级技术。 这些包括信任建模和安全域建模。 当您遇到这些方法时，您会发现与已经讨论过的材料的相似之处。 作为一门学科，安全架构的大部分进步取决于新的和创新的建模技术和工具的开发，这些技术和工具使您能够解决新型复杂问题。

5.8.3. 总结：一种系统方法

系统方法意味着对您的思维采取全面结构化的方法，确保考虑系统行为的所有方面及其影响，从而确保最大程度地交付业务利益。

为此，您必须：
 了解系统边界；
 做出理性、可追溯的决策；
 考虑系统的所有方面。

系统方法的特点是通过以下方式解决复杂性和简化复杂性：
 自顶向下分解；
 黑匣子概念；
 逻辑流分析。

系统方法意味着架构师或设计师的某些行为：
 把它写下来；
 结构化同行评审；
 交流和保存想法。

系统工程的基本概念是：
 系统目标；
 系统环境；
 系统资源；
 子系统；
 系统管理。

安全系统和子系统通常使用具有三个子系统的反馈控制回路的控制系统概念：
 控制子系统；
 测量子系统；
 决策子系统。

在开发安全架构时使用系统方法需要设计人员考虑：
 广泛的业务目标；
 环境因素；
 降低复杂性；
 有意义的监测和测量。

还有许多高级建模技术可用于开发安全架构。 这些包括：
 业务流程工程；
 依赖树建模；
 有限状态机模型；
 本书后面章节中介绍的其他高级建模技术，例如信任建模和安全域建模。