第1章 实现安全治理的原则和策略

1.1 安全101

安全的重要性经常被提及，但我们并非总能理解其中的缘由。

安全很重要，是因为当有人试图窃取组织的数据或破坏其物理或逻辑元素时，它有助于确保组织继续存在与运营。

安全应被视为业务管理的一个要素，而不仅是IT问题。事实上，IT和安全是不同的。

信息技术(IT)或信息系统(IS)是支持业务操作或功能的硬件和软件。

安全是一种业务管理工具，旨在确保IT/IS 的运行可靠且受到保护。

安全的存在是为了支持组织的目标、使命和宗旨。

通常，应该采用安全框架来为安全的实现提供一个起点。启动安全后，则通过评估来微调安全。

三种常见的安全评估类型：风险评估、漏洞评估和渗透测试（详见第2 章和第15章）。

·风险评估是识别资产、威胁和漏洞，然后使用这些信息来计算风险的过程。

一旦了解了风险，就可利用它来指导现有安全基础设施的改进。

·漏洞评估使用自动化工具来定位已知的安全弱点，这些弱点可通过添加防御措施或调整现有保护措施来解决。

· 渗透测试利用可信的个人对安全基础设施进行压力测试，以找出前两种方法可能发现不了的问题，其目标是在对手利用这些问题之前找到它们。

安全应具有成本效益。组织的预算不是无限的，因此必须适当地分配资金。

此外，组织预算不仅要包括员工工资、保险、退休金等的费用，还应包括用于安全的一定比例的资金，

就像大多数其他业务任务和流程需要资金一样。

应该选择以最低资源成本提供最大保护的安全控制。

安全应该是合法的。你所在辖区的法律是组织安全的后盾。

当有人侵入你的环境并破坏安全，尤其是当这些活动非法时，那么法庭诉讼可能是获取赔偿或了结事件唯一可用的途径。

此外，组织做出的许多决定都会涉及法律责任问题。

如果需要在法庭上为安全行动辩护，法律支持的安全将大大有助于使组织免于面临巨额罚款、处罚或过失指控。

安全是一段旅程，而不是终点线。这不是一个永远不会结束的过程。

彻底的防护是不可能实现的，因为安全问题总是在变化。

随着时间的推移，用户以及发现缺陷和利用漏洞的对手正在变化，部署的技术也在发生变化。

对昨天来说足够的防御，明天可能就不够了。

随着新漏洞的发现、新攻击手段的设计，以及新漏洞利用方式的构建，我们必须通过重新评估安全基础设施并进行适当的调整来予以响应。

1.2 理解和应用安全概念

安全管理的概念与原则是实施安全策略和安全解决方案的核心内容。

安全管理的概念与原则定义了安全环境中必需的基本参数，也定义了安全策略设计人员和系统实施人员为创建安全解决方案必须实现的目标。

保密性、完整性和可用性(confidentiality, integrity, and availability, CIA 三元组）经常被视为安全基础架构中主要的安全目标和宗旨（见图1.1) 。

安全控制评估通常用于评价这三个核心信息安全原则的符合情况。

脆弱性和风险的评估也基于它们对一个或多个CIA 三元组原则的威胁。

1.2.1 保密性confidentiality

CIA 三元组的第个原则是保密性。保密性指为保障数据、客体或资源保密状态而采取的措施。

保密性保护的目标是阻止或最小化未经授权的数据访问。

保密性在保护授权访问的同时防止泄露违反保密性的行为不仅包括直接的故意攻击，

也包括许多由人为错误、疏忽或不称职造成的未经授权的敏感或机密信息泄露。

违反保密性可能是因为最终用户或系统管理员的不当行为，也可能是因为安全策略中的疏漏或配置有误的安全控制。

许多控制措施有利于保障保密性以抵御潜在的威胁。

这些控制措施包括加密、填充网络流量、严格的访问控制、严格的身份认证程序、数据分类和充分的人员培训。

保密性的相关概念、条件和特征包括：

1.敏感性，指信息的特性，这种特性的数据一旦泄露就会导致伤害或损失。

2.判断力，是一种决策行为——操作者可影响或控制信息泄露，以将伤害或损失程度降至最低。

3.关键性，信息的关键程度是其关键性的衡量标准。关键级别越高，越需要保持信息的保密性。

4.隐藏 (concealment)，指藏匿或防止泄露的行为。通常，隐藏被看成一种掩盖、混淆和干扰注意力的手段。

与隐藏相关的一个概念是通过晦涩获得安全，即试图通过隐藏、沉默或保密来获得保护。

5.保密，是指对某事保密或防止信息泄露的行为。

6.隐私，指对个人身份或可能对他人造成伤害、令他人感到尴尬的信息保密。

7.隔绝(seclusion)，就是把东西放在不可到达的地方，可能有严格的访问控制。

8.隔离(isolation)，是使某些事物与其他事物保持分离的行为。

组织都需要评估其想要实施的具体保密性措施。

用于实现某种形式保密性的工具和技术可能不支持或不允许其他形式的保密性。

1.2.2 完整性integrity

完整性是保护数据可靠性和正确性的概念。完整性保护措施防止了未经授权的数据更改。

恰当实施的完整性保护措施允许合法修改数据，

同时可预防故意和恶意的未经授权的活动（如病毒和入侵）以及授权用户的误操作（如错误或疏忽）。

可从以下三个方面检验完整性：

·防止未经授权的主体进行修改。

·防止授权主体进行未经授权的修改，如引入错误。

·保持客体内外一致以使客体的数据能够真实反映现实世界，而且与任何其他客体的关系都是有效的、一致的和可验证的。

为在系统中维持完整性，必须对数据、客体和资源的访问设置严格的控制措施。

在存储、传输和处理中，客体完整性的维护和验证需要多种控制和监督措施。

许多攻击聚焦在破坏完整性上。

这些攻击包括病毒、逻辑炸弹、未经授权的访问、编码和应用程序中的错误、恶意修改、故意替换及系统后门。

人为错误、疏忽或不称职造成了很多未经授权修改敏感信息的案例。

遭受完整性破坏的原因也可能是安全策略中的疏漏或配置有误的安全控制。

许多控制措施可预防完整性受到的威胁。

控制措施包括严格的访问控制、严格的身份认证流程、入侵检测系统、客体／数据加密、哈希值验证、接口限制、输入/功能检查和充分的人员培训。

保密性和完整性相互依赖。没有客体完整性（换句话说，不能保证客体不受未经授权的修改），就无法维持客体保密性。

完整性依赖于保密性和访问控制。与完整性相关的其他概念、条件和特征包括以下几点。

·准确性：正确且精确无误。

·真实性：真实地反映现实。

·有效性：实际上（或逻辑上）是正确的。

·问责制：对行为和结果负有责任或义务。

·职  责：负责或控制某人或某事。

·完整性：拥有全部必需的组件或部件。

·全面性：完整的范围，充分包含所有必需的元素。

1.2.3 可用性availability

可用性意味着授权主体被授予实时的、不间断的客体访问权限。

通常，可用性保护控制措施提供组织所需的充足带宽和实时的处理能力。

如果安全机制提供了可用性，它就应该能保证数据、客体和资源可被授权主体访问。

可用性包括对客体的有效的持续访问及抵御拒绝服务(DoS)攻击的能力。

可用性还意味着支撑性基础设施（包括网络服务、通信和访问控制机制）是可用的，并允许授权用户获得授权的访问。

要在系统上维护可用性，就必须有适当的控制措施以确保授权的访问和可接受的性能水平，

以快速处理通信的中断，提供冗余，维护可靠的备份，并防止数据丢失或受损。

可用性面临的威胁包括：

1.设备故障、软件错误和环境问题（过热、静电、洪水、断电等）。

2.聚焦于破坏可用性的攻击形式，包括DoS 攻击、客体破坏和通信中断。

许多破坏可用性的实例是由人为错误、疏忽或不称职造成的。

安全策略中的疏漏或配置有误的安全控制也会破坏可用性。

防御潜在的可用性威胁的控制措施包括：

·正确设计中转传递系统

·有效使用访问控制

·监控性能和网络流量

·使用防火墙和路由器防止DoS 攻击

·对关键系统实施冗余机制

·维护和测试备份系统

大多数安全策略以及业务连续性计划(BCP)关注不同级别的访问/存储/安全（即磁盘、服务器或站点）上的容错特性，

目标是消除单点故障，保障关键系统的可用性。

可用性依赖于完整性和保密性。没有完整性和保密性，就无法维持可用性。

与可用性相关的其他一些概念、条件和特征如下。

·可用性：容易被主体使用或学习，或能被主体理解和控制的状态。

·可访问性：保证全部授权主体可与资源交互而不考虑主体的能力或限制。

·及时性：及时、准时，在合理的时间内响应，或提供低时延的响应。

1.2.4 DAD、过度保护、真实性、不可否认性和AAA服务

除了CIA 三元组外，在设计安全策略和部署安全解决方案时，还需要考虑其他许多与安全相关的概念和原则。

这包括DAD三元组、过度保护的风险、真实性、不可否认性和AAA服务。

DAD三元组是与CIA三元组相反的一个有趣的安全概念。

DAD 三元组由泄露(disclosure)、修改(alteration)与破坏(destruction)组成。

它代表CIA 三元组中安全保护的失败。当安全机制失败时，可能需要识别要查找的内容。

当敏感或保密资料被未经授权的实体访问时，就会发生泄露，这是对保密性的破坏。

当数据被恶意或意外更改时，就会发生修改，这是对完整性的破坏。

当资源被破坏或授权用户无法访问时（技术上通常称之为拒绝服务），就会发生破坏，这就违反了可用性。

同样值得注意的是，过度的安全性也是有问题的。

过度保护保密性会导致可用性受限。

过度保护完整性也会导致可用性受限。

过度保护可用性会导致保密性和完整性受损。

真实性(authenticity)这个安全概念是指数据是可信的或非伪造的并源自其声称的来源。

这与完整性有关，但更重要的是验证它是否来自声称的来源。

当数据具有真实性时，接收者可以高度确信数据来自其声称的来源，并且在传输（或存储）过程中没有发生变化。

不可否认性(non-repudiation)确保事件的主体或引发事件的人不能否认事件的发生。

不可否认性可预防主体否认发送过消息，执行过动作或导致某个事件的发生。

标识、身份认证、授权、问责制和审计使不可否认性成为可能。

可使用数字证书、会话标识符、事务日志以及其他许多事务性机制和访问控制机制来实施不可否认性。

在构建的系统中，如果没有正确实现不可否认性，就不能证明某个特定实体执行了某个操作。

不可否认性是问责制的重要组成部分。

如果嫌疑人能够证明起诉不成立，他就不会被追究责任。

AAA服务是所有安全环境中的一个核心安全机制。

这三个A 分别代表身份认证(authentication)、授权(authorization)和记账(accounting)；最后一个A有时也指审计(auditing)。

尽管缩略词中只有三个字母，但实际上代表了五项内容：标识、身份认证、授权、审计和记账。

这五项内容代表以下安全程序。

·标识(identification)：当试图访问受保护的区域或系统时声明自己的身份。

·身份认证：证实身份。

·授权：对一个具体身份或主体定义其对资源和客体的访问许可（如允许/授予或拒绝）。

·审计：记录与系统和主体相关的事件与活动日志。

·记账（或问责制）：通过审查日志文件来核查合规和违规情况，尤其是违反组织安全策略的情况，以便让主体对自身行为负责。

虽然AAA 经常与身份认证系统关联在一起，但实际上，AAA是一个安全基础概念。

只要缺少这五个要素之一，安全机制就是不完整的。下面将分别讨论这五个要素，如图1.2所示。

1. 标识(identification)

主体必须提供身份标识来启动身份认证、授权和记账过程。

提供身份标识时可能需要：输入用户名，刷卡，摇动一台近场通信设备，说出－个短语，或将你的脸、手掌或手指放入摄像机或扫描设备。

如果没有身份标识，系统就无法将身份认证因素与主体相关联。

一旦主体被标识（即，一旦主体的身份被标识和验证），该身份标识就要对其接下来的所有行为负责。

IT系统通过身份标识（而不是通过主体本身）来跟踪活动。

计算机并不知道一个人与另一个人的区别，但它知道你的用户账户与其他所有人员的用户账户是不同的。

简单地声明身份并不意味着访问或授权。在使用之前，必须验证身份标识。这个过程就是身份认证。

2. 身份认证(authentication)

验证所声明的身份标识是否有效的过程即身份认证。身份认证要求主体提供与所要求的身份对应的附加信息。

最常见的身份认证形式是使用密码。

身份认证通过将一个或多个因子与有效的身份数据库（即用户账户）进行比较来验证主体的身份。

主体和系统对身份认证因子的保密能力直接反映了系统的安全级别。

通常在一个流程中完成标识和身份认证两个步骤。提供身份标识是第一步，提供身份认证因子是第二步。

如果不能同时提供，主体就不能访问系统——就安全性而言，单独使用任一身份认证因子时都不能起作用。

在某些系统中，看起来好像只提供了一个身份认证因子，但也获得了访问权限，例如在输入ID码或PIN码时。

其实在此类情况下，标识是通过另一种方式处理的，比如物理位置，或者以物理方式访问系统，从而完成身份认证。

标识和身份认证都会进行，但你可能不会像手动输入用户名和密码时那样意识到它们的存在。

每种身份认证技术或身份认证因子都有优缺点。因此，重要的是根据环境来评估每种身份认证机制的部署可行性。

对身份认证的深入探讨，见第13 章。

3. 授权(authorization)

一旦主体通过身份认证，就必须进行访问授权。

鉴于已通过验证的身份被赋予的权利和特权，授权过程确保被请求的活动或对客体的访问是可以实现的。

大多数情况下，系统评估与预期行为相关的主体、客体和所分配的权限。

如果特定行为是被允许的，则对主体进行授权。

如果特定行为不被允许，就不对主体进行授权。

请记住，不能仅因为主体已通过标识和身份认证过程，就认为主体已被授权执行任意功能或访问受控环境中的所有资源。

标识和身份认证体现了访问控制的全有或全无特性。

对于环境中的每个客体，授权在全部允许和全部拒绝之间有广泛的变化。

用户可读取文件但不能删除，可打印文档但不能更改打印队列，或者可登录到系统但不能访问任何资源。详见第13 章。

4. 审计(auditing)

审计是一种程序化的过程通过追踪和记录主体的操作，在验证过的系统中让主体为其行为负责。

审计也是对系统中未经授权的或异常的活动进行检测的过程。

审计不仅记录主体及其客体的活动，还记录应用和系统功能的活动。

日志文件为重构事件、入侵或系统故障的历史记录提供了审计踪迹。

我们需要通过审计来检测主体的恶意行为、入侵企图和系统故障，以及重构事件，为起诉提供证据，生成问题报告和分析结果。

审计通常是操作系统、大多数应用程序和服务的内置功能。因此，配置系统功能来记录特定类型事件的审计信息的过程非常简单。

5. 记账（或问责制）(accounting)

组织的安全策略只在有问责制的情况下才能得到适当实施。

换句话说，只有当主体对他们的行为负责时，才能保持安全性。

有效的问责制依赖于检验主体身份及追踪其活动的能力。

通过安全服务和审计、身份认证、授权和身份标识等机制，将人员与在线身份的活动联系起来，进而建立问责制。

因此，人员的问责制最终取决于身份认证过程的强度。

如果没有强大的身份认证过程那么当发生不可接受的活动时，我们将无法确定与特定用户账户相关联的人员是不是实际控制该用户账户的实体。

为了获得切实可行的问责制，你必须能够在法庭上为你的安全决策及实施提供依据。

如果不能在法律上证实安全方面的努力，就不太可能让某人对与用户账户有关的行为负责。

如果只使用密码进行身份认证，这显然值得怀疑。

密码是最不安全的身份认证形式，有数十种不同类型的攻击可破坏这种身份认证形式。

不过，如果使用多因素身份认证，例如将密码、智能卡和指纹扫描组合起来使用，

那么其他人几乎不可能通过攻击身份认证过程来假冒代表特定用户账户的人员。

1.2.5 保护机制

理解和应用安全控制的另一个方面是保护机制或保护控制。

并不是所有安全控制都必须具有这些机制，但许多控制通过使用这些机制提供了保密性、完整性和可用性。

这些机制的常见示例包括纵深防御、抽象、数据隐藏和加密技术的使用。

1. 纵深防御(layering)

纵深防御也被称为分层(layering)防御，指简单使用一系列控制中的多个控制。

没有哪个控制能防范所有可能的威胁。多层防护解决方案允许使用许多不同的控制措施来抵御随时都可能出现的威胁。

在设计分层防护安全解决方案时，一个控制的失效不会导致系统或数据暴露。

应使用串行层，而不是并行层，这很重要。

在串行层中执行安全控制意味着以线性方式连续执行一个又一个控制。

只有通过串行层的配置，安全控制才能扫描、评估或减轻每个攻击。

在串行层的配置中，单个安全控制的失败并不会导致整个解决方案失效。

如果安全控制是并行实现的，威胁就可通过一个没有处理其特定恶意活动的检查点，进而使整个解决方案失效。

串行配置的范围很窄，但层级很深；并行配置的范围很宽，但层级很浅。

并行系统在分布式计算应用程序中很有用，但在安全领域中，并行机制往往不是一个有用的概念。

在纵深防御的语境中，除了级别、多级和分层，与此概念相关的其他常用术语还有分类、分区、分域、隔离、孤岛、分段、格结构和保护环。

2. 抽象(abstraction)

抽象是为了提高效率。相似的元素被放入组、类或角色中，作为集合被指派安全控制、限制或许可。

抽象使你可将安全控制分配给按类型或功能归类的客体集，由此简化安全。

因此，可将抽象的概念应用到对客体进行分类或向主体分配角色的场景中。

抽象是面向对象编程领域背后的基本原则之一。

未知环境理论认为，对象（或操作系统组件）的用户不一定需要知道有关对象如何工作的细节；

他门只需要知道使用对象的正确语法以及将作为结果返回的数据类型（即，如何发送输入和接收输出）。

这在很大程度上涉及对数据或服务的间接访问，

例如，当用户模式应用程序使用系统调用请求管理员模式服务或数据（并根据请求者的凭证和权限允许或拒绝该请求），

而不是获得直接的、无中介的访问时。

抽象应用于安全的另一种方式是引入对象组（有时称为类），其中访问控制和操作权限的分配是基于对象组（而不是每个对象）的。

这种方法允许安全管理员轻松定义和命名组（名称通常与工作角色或职责相关），并且有助于更容易地管理权限和特权（当将对象添加到类时，就

已授予权限和特权，而不必单独为每个对象设置权限和特权）。

3. 数据隐藏

顾名思义，数据隐藏是指将数据存放在主体无法访问或读取的逻辑存储空间以防止数据被泄露或访问。

这意味着不仅数据是不可见的，而且主体不能看致或者访问数据。

数据隐藏的形式包括：

·防止未经授权的访问者访问数据库

·限制安全级别较低的主体访问安全级别较高的数据

·阻止应用程序直接访问存储硬件

数据隐藏通常是安全控制和编程中的关键元素。隐写术是数据隐藏的个范例（见第7 章）。

数据隐藏是多级安全系统的一个重要特征。

它确保存在于某一安全级别的数据对于运行在不同安全级别的进程是不可见的。

从安全的角度来看，数据隐藏需要将对象放置在不同于主体所占用的安全容器中，以向那些不必了解对象或访问对象的人隐藏对象详细信息。

在这里，“通过隐匿(obscurity)保持安全”似乎是一个相关的术语，但它是另一种概念。

数据隐藏是指故意将数据存放在未授权主体无法查看或访问的位置，而通过隐匿保持安全是指不将客体的存在告知主体，以使主体不发现该客体。

换句话说，在通过隐匿保持安全时，主体只要能够找到数据，就可以访问数据。

这是数据版的捉迷藏游戏。通过隐匿保持安全的做法实际上并没有提供任何形式的保护。

它只是希望通过保持重要事物的保密性以免其泄露。

通过隐匿保持安全的一个实例是：虽然程序员知道软件代码中存在缺陷，但他们还是发布了产品，并希望没人会发现和利用代码中存在的缺陷。

4. 加密(encryption)

加密科学旨在对非预期的接收者隐藏通信的真实含义或意图。

加密有多种形式并适用于各种类型的电子通信与存储。有关加密的内容将在第6~7 章中详细讨论。

1.3 安全边界

安全边界是具有不同安全要求或需求的任意两个区域、子网或环境之间的交界线。

安全边界存在于高安全区域和低安全区域之间，例如局域网和互联网之间。

重要的是识别网络和物理世界中的安全边界。

一旦确定了安全边界，就必须部署机制来控制跨该安全边界的信息流。

安全区域之间的划分可以采取多种形式。

例如，对象可能有不同的分类。

每个分类都定义了哪些主体可以对哪些客体执行哪些功能。不同的分类之间就是安全边界。

物理环境和逻辑环境之间也存在安全边界。要提供逻辑安全，就必须提供不同于那些用于提供物理安全的安全机制。

物理安全和逻辑安全都必须存在，以提供完整的安全结构，并且两者都必须在安全策略中得到体现。

当然，物理安全和逻辑安全是不同的，必须作为安全解决方案的不同元素进行评估。

应始终明确定义安全边界，例如受保护区域和未受保护区域之间的边界。

重要的是在安全策略中明确安全控制的终点或起点，并在物理环境和逻辑环境中确定该位置。

逻辑安全边界是组织在法律上负有责任的设备或服务的电子通信接口点。

大多数情况下，该接口被明确标记，并告知未授权的主体无权访问。如试图获得访问，将导致起诉。

物理环境中的安全边界通常与逻辑环境的安全边界相对应。

大多数情况下，组织在法律上负责的区域决定了安全策略在物理领域的范围。

这些可以是办公室的围墙、建筑物的围墙或校园周围的围栏。

在安全环境中，张贴警告标志，表明禁止未经授权的访问，试图进入者将受到阻止，并导致起诉。

将安全策略转化为实际控制时，必须分别考虑每个环境和安全边界。

简要推断出哪些可用的安全机制可为特定环境和形势提供最合理、最具成本效益和最有效的解决方案。

不过，对于所有安全机制，你都必须权衡其与要保护的对象的价值。

部署成本高于受保护对象价值的对策是没有意义的。

1.4 评估和应用安全治理原则

安全治理是与支持、评估、定义和指导组织安全工作相关的实践集合。

最理想的情况是，安全治理由董事会执行，

但在规模较小的组织，可仅由首席执行官(CEO)或首席信息安全官(CISO)执行安全治理活动。

安全治理旨在将组织内所使用的安全流程和基础设施与从外部来源获得的知识和见解进行比对。

因此，董事会通常由来自不同背景和行业的人构成。

董事会成员可以使用他们丰富的经验和智慧为其监督的组织提供改进指导。

安全治理原则通常与公司和IT治理密切相关。

这三类治理的工作目标一般是相同的或相互关联的，例如持续存在并努力实现增长和韧性。

组织迫于法律和法规的要求必须实施治理，也必须遵守行业指南或许可证要求。

所有形式的治理（包括安全治理）都应不时进行评估和验证。

由于政府法规或行业最佳实践，可能存在各种审计和验证要求。

当不同国家的法律不－致或实际上存在冲突时，这个难题更难解决。

组织作为一个整体应该具备方向、指导和工具，以提供有效的监督和管理能力，解决威胁和风险；

重点是缩短停机时间，并将潜在的损失或损害降至最低。

正如你看到的，安全治理通常是较严格和高层次的内容。

最终，安全治理指实施安全解决方案以及与之紧密关联的管理方法。

安全治理直接监督并涉及所有级别的安全。安全不完全是IT事务，也不应该仅被视为IT事务。

相反，安全会影响组织的方方面面。

安全是业务运营事务，是组织流程而不仅是IT极客在后台实施的事情。

这里使用术语“安全治理”指出安全需要在整个组织中进行管理和治理，而不只是在IT部门，就是为了强调这一点。

有许多安全框架和治理指南，包括NIST SP 800-53 或NIST SP 800-100。

虽然NIST主要应用在政府和军事行业，但它经过调整后也可供其他类型的组织采用。

许多组织采用安全框架，以标准化和有序方式组织那些复杂且混乱的活动，即努力实现可接受的安全治理。

1.4.1 第三方治理

第三方治理是可能由法律、法规、行业标准、合同义务或许可要求强制执行的外部实体监督系统。

实际的治理方法可能各有不同，但通常会涉及外部调合员或审计员。

这些审计人员可能由管理机构指定，也可能是目标组织聘请的顾问。

第三方治理的另一个方面是对组织所依赖的第三方应用进行安全监督。

许多组织选择外包其业务运营的各个方面。外包业务可以包括安保、维护、技术支持和审计服务。

上述各方都需要遵守组织的安全立场。否则，他们会给组织带来额外的风险和漏洞。

第三方治理侧重于验证其是否符合声明的安全目标、需求、法规和合同义务。

现场评估可以提供一个地点所采用安全机制的第一手资料。

执行现场评估或审计的人员需要遵循审计协议，例如信息和相关技术控制目标(COBIT) ，并根据一份具体需求清单进行调查。

在审计和评估过程中，目标机管理机构都应参与全面、公开的文件交换和审查。

组织需要了解其所必须遵守的所有要求的全部细节。组织应将安全策略和自我评估报告提交给管理机构。

这种开的文件交换确保相关各方就所有关注的问题达成共识，减少了未知需求或不切实际的期望出现的可能。

文件交换不会随着文书工作或电子文件的传输而结束，而是贯穿于档审查过程。

有关第三方连接的讨论，详见第12 章。

1.4.2 文件审查

文件审查是查看交换材料并根据标准和期望对其进行验证的过程。又件审查通常发生在

现场检查之前。如果所交换的文件充分并且满足期望（或至少满足需求），那么现场审查将集

中审查其与所声明文件是否相符。但是，如果所交换的文件不完整、不准确或不充分，现场

审查将推迟到文件被更新或更正后进行。这个步骤非常重要，因为如果文件不合规，那现场

也可能不合规。

许多情况下，特别是与政府或军事札构或承包商相关的情况卜，如果未能提供足够的文

件以满足第三方治理的要求，可能导致操作授权(ATO) 的丢失或失效。元整且充分的文件通

常可以维护现有的ATO 或提供临时的ATO (TATO) 。但是，一旦ATO 丢失或撤销，通常需要

进行完整的文件审查和现场审查，表明其完全符合要求，以重新建立ATO 。

文件审查的一部分是根据标准、框架和合同义务对业务流程和组织策略进行逻辑和实际

的调查。这种审查确保声明和实现的业务任务、系统和方法是实用的、高效的和具有成本效

益的，最重要的是（至少在安全治理方面），他们通过减少漏洞与规避、减少或减轻风险来支

持安全目标。风险管理、风险评估和风险处置是执行流程／策略评审时所使用的方法与技术。

1.5 管理安全功能

安全功能是业务运营的一个方面，专注于随着时间的推移评估和改进安全性的任务。

为管理安全功能，组织必须实施恰当与充分的安全治理。

通过执行风险评估以推动安全策略的行为是有关安全功能管理的最清晰与最直接的示例。

第2 章将讨论风险评估的过程。

安全必须是可衡量的。可衡量的安全意味着安全机制的各个方面都发挥作用，

提供明显的收益，并有一个或多个可以进行记录与分析的指标。

与性能度量类似，安全度量是测量安全特性操作相关的性能、功能、操作、行为等。

当实施安全对策或保护措施后，安全指标应显示出意外事件数量的减少或尝试检测事件数量的增加。

测量和评估安全指标的行为可以评估安全计划的完整性和有效性。

这还应包括根据通用安全准则对安全计划进行测量，并跟踪其控制措施的成功与否。

安全指标的跟踪和评估是有效安全治理的一部分。

安全功能包括信息安全战略的开发和实施。

CISSP考试的大部分内容和本书都涉及信息安全战略开发与实施的各个方面。

1.5.1 与业务战略、目标、使命和宗旨相一致的安全功能

安全管理计划确保正确地创建、执行和实施安全策略。

安全管理计划使安全功能与业务战略、目标、使命和宗旨相一致。

这包括基于业务场景、预算限制或资源稀缺性来设计和实现安全。

业务场景通常是文档化的参数或声明的立场，用于定义做出决策或采取某类行为的需求。

创建新的业务场景是指演示特定业务需求，以修改现有流程或选择完成业务任务的方法。

业务场景常被用来证明新项目（特别是与安全相关的项目）的启动是合理的。

在大多数组织中，资金和资源（如人员、技术和空间）都是有限的。

由于这些资源的限制，任何努力都需要获得最大利益。

最能有效处理安全管理计划的一个方法是自上而下方法。

上层、高级或管理部门负责启动和定义组织的策略。

安全策略为组织架构内的各个级别提供指导。

中层管理人员负责将安全策略落实到标准、基线、指导方针和程序。

操作管理人员或安全专业人员必须实现安全管理文档中规定的配置。

最终用户必须遵守组织的所有安全策略。

安全管理是上层管理人员的责任，而不是IT人员的责任，它也被认为是业务操作问题，而不是IT管理问题。

在组织中，负责安全的团队或部门应该是独立的。

信息安全(InfoSec)团队应由指定的首席信息安全官(CISO)领导，CISO直接向高级管理层（如CIO、CEO或董事会）汇报。

若将CISO和CISO团队的自主权置于组织典型架构之外，可改进整个组织的安全管理。

这还有助于避免跨部门问题和内部问题。首席安全官(CSO)有时等同于CISO, 不过在很多组织中，CSO是CISO的下属职位，主要关注物理安全。

另一个可能替代CISO的术语是信息安全官(ISO)，但ISO也可以是CISO的下属职位。

安全管理计划的内容包括：定义安全角色，规定如何管理安全、由谁负责安全以及如何检验安全的有效性，

制订安全策略，执行风险分析，要求对员工进行安全教育。

这些工作都通过制订管理计划来完成。

如果没有高级管理人员批准这个关键过程，那么再好的安全计划也毫无用处。

没有高级管理层的批准和承诺，安全策略就不会取得成功。

策略开发团队的责任是充分培训高级管理人员，使其了解策略中规定的安全措施被部署以后仍然存在的风险和责任。

安全策略的制订和执行体现了高级管理人员的应尽关心与尽职审查。

如果一家公司的管理层在安全方面没有进行应尽关心与尽职审查，管理者就存在疏忽，并应对资产和财务损失负责。

安全管理计划团队应该制订三种类型的计划，如图1.3 所示。

·战略计划(strategic plan)是一个相对稳定的长期计划。

它定义了组织的安全目的，也定义了安全功能，并使其与组织的目标、使命和宗旨相一致。

如果每年进行维护和更新，战略计划的有效期大约是5年。战略计划也可被视为愿景规划。

战略计划中讨论了未来的长期目标和愿景。战略计划还应包括风险评估。

·战术计划(tactical plan)是中期计划。

为战略计划中设定的目标提供更多细节，该计划也可根据不可预测的事件临时制订。

战术计划通常在一年左右的时间内有用，通常规定和安排实现组织目标所需的任务。

战术计划的一些示例包括项目计划、收购计划、招聘计划、预算计划、维护计划、支持计划和系统开发计划。

·操作计划(operational plan)是在战略计划和战术计划的基础上制订的短期、高度详细的计划。

操作计划只在短时间内有效或有用。

操作计划必须经常更新（如每月或每季更新），以保持其与战术计划的一致性。

操作计划阐明了如何实现组织的各种目标，包括资源分配、预算需求、人员分配、进度安排与细化或执行程序。

操作计划包括执行流程与组织安全策略的合规性细节。操作计划的示例包括培训计划、系统部署计划和产品设计计划。

安全是一个持续的过程。因此，安全管理计划的活动可能有－个确定的起点，但其任务和工作永远无法彻底完成或实现。

有效的安全计划关注具体和可实现的目标、预测变化和潜在问题，并充当整个组织决策的基础。

安全文档应该是具体的、定义完善的和明确说明的。

为使安全计划有效，必须开发、维护和实际使用安全计划。

1.5.2 组织的流程

安全治理需要关注组织的方方面面，这包括收购、资产剥离和治理委员会的组织流程。

收购与兼并会提升组织的风险等级。

这些风险包括不恰当的信息泄露、数据丢失、停机或未能获得足够的投资回报率(return on investment, ROI) 。

除了所有兼并与收购中的典型业务和财务方面，为了降低在转型期间发生损失的可能性，良好的安全监督和加强的审查通常也是极其重要的。

同样，资产剥离或任何形式的资产减少或员工裁减都会增加风险，进而增加组织对集中安全治理的需求。

应对资产进行净化以防止数据泄露。

应该删除和销毁存储介质，因为介质净化处理技术不能保证残留数据不会被恢复。

对于不再负责相关事宜的员工，应询问其工作完成情况，该过程通常称为离职面谈。

这一过程通常包括审查所有保密协议以及其他任何在雇佣关系终止后仍继续生效的约束合同或协议。

如果在未考虑安全性的情况下进行收购和兼并，那么所收购产品的固有风险将在整个部署生命周期中一直存在。

若将收购元素的固有威胁最小化，将减少安全管理成本，并可能减少安全违规行为。

重要的是评估与硬件、软件和服务相关的风险。

集成了韧性、安全性的产品和解决方案通常比那些没有安全基础的产品和解决方案更昂贵。

然而，与处理不良设计产品安全缺陷的费用相比，这种额外的初始费用通常更具有成本效益。

因此在考虑兼并/收购成本时，重要的是考虑产品部署的整个生命周期内的总成本，而不只是考虑初始购买和实施费用。

收购不仅涉及硬件和软件，也包括外包、与供应商签订合同、聘请顾问等内容。

与外部实体协同工作时，不仅要重视集成的安全性评估，而且要确保在设计产品时考虑了安全性，二者同等重要。

许多情况下，可能需要持续的安全监控、管理和评估。这可能是行业最佳实践或监管要求。

这种评估和共同监督可能在组织内部进行，也可由外部审计人员完成。

当使用第三方评估和监控服务时，请记住，外部实体需要在其业务操作中体现出安全意识。

如果外部组织无法在安全的基础上管理自身的内部操作，他们又将如何为你提供可靠的安全管理功能呢？

在为安全集成评估第三方时，请考虑以下过程：

·现场评估

到组织现场进行访谈，并观察工作人员的操作习惯。

·文件交换和审查

调查数据和文件记录交换的方式，以及执行评估和审查的正式过程。

·过程/策略审查

要求提交安全策略、过程\程序，以及事件和响应文件的副本以供审查。

·第三方审计

根据美国注册会计师协会(AICPA) 的定义，拥有独立性的第三方审计机构可根据SOC报告，

对实体的安全基础设施进行公厅的审查。有关SOC 审计的更多信息，请参见第15 章。

为所有收购设立最低限度的安全要求。这些要求应以现有安全策略为模板。

新的硬件、软件或服务的安全而求应该始终满足或超过现有某础设施的安全性。

在使用外部服务时，定要检查服务水平协议(SLA) ，确保服务合同中包含有关安全的规定。

当外部供应商正在制作软件或提供服务时，可能需要定义服务级别需求(SLR)。

SLR是对供应商产品（或服务）的服务和性能期望的说明。

通常，SLR是由客户在SLA建立之前提供的（如果供应商希望客户签署协议，应使朸议包含SLR) 。

1.5.3 组织的角色与责任

安全角色是个人在组织内的安全实施和管理总体方案中扮演的角色。

安全角色不是固定或静止的，所以并不需要预先在工作内容中说明。

熟悉安全角色对于在组织内建立通信和支持结构是很有帮助的。

这种结构能够支持安全策略的部署和执行。

典型安全环境中存在的常见安全角色：

·高级管理者

组织所有者（高级管理者）角色被分配给最终对组织安全的维护负责及最关心资产保护的人员。

高级管理者必须在所有策略问题上签字。如果缺少高级管理者的授权和支持，安全策略就无法生效。

高级管理者将对安全解决方案的总体成功或失败负责，而且在为组织建立安全方面有责任实施应尽关心和尽职审查。

尽管高级管理者最终负责安全，但他们很少直接实施安全解决方案。

大多数情况下，这种责任被分配给组织内的安全专业人员。

·安全专业人员

安全专业人员、信息安全官(InfoSec)或计算机事件响应小组(computer incident response team, CIRT) 的角色被分配给受过培训和经验丰富的网络、系统和安全工程师们，他们负责落实高级管理者下达的指示。

安全专业人员的职责是保证安全性，包括编写和执行安全策略。

安全专业人员可被称为IS/IT功能角色，不过相比于功能，他们更关注安全保护。

安全专业人员角色通常由一支团队担任，该团队负责根据已批准的安全策略设计和实现安全解决方案。

安全专业人员不是决策者，而是实施者。所有决策都必须由高级管理者定夺。

·资产所有者(asset owner)

资产所有者角色将被分配给在安全解决方案中负责布置和保护信息分类的人员。

资产所有者通常是高级管理人员，他们最终对资产保护负责。

然而，资产所有者通常将实际数据管理任务的责任委托给托管员。

·托管员(custodian)

托管员角色被分配给负责执行安全策略与高级管理者规定的保护任务的人员。

托管员执行所有必要的活动，为实现数据的CIA三元组（保密性、完整性和可用性）提供充分的数据支持，并履行上级管理部门委派的要求和职责。

这些活动包括执行和测试备份、验证数据完整性、部署安全解决方案以及基于分类管理数据存储。

·用户

用户（最终用户或操作者）角色被分配给任何能访问安全系统的人员。

用户的访问权限与他们的工作任务相关并受其限制，因此他们只有足以执行工作岗位所需的任务的访问权限（最小特权原则）。

用户有责任遵守规定的操作程序并在规定的安全参数内进行操作，从而理解和维护组织的安全策略。

·审计人员(auditor)

审计人员负责审查和验证安全策略是否被正确执行，以及相关的安全解决方案是否完备。

审计人员出具由高级管理者审核的合规性和有效性报告。

高级管理者将在这些报告中发现的问题当作新的工作内容分配给安全专业人员或托管员。

所有这些角色都在安全环境中发挥着重要作用。这些角色有助于确定义务和责任以及确定分级管理和授权方案。

1.5.4 安全控制框架

安全规划步骤中的第一步（也是最重要的一步），就是考虑组织所希望的安全解决方案的总体安全控制框架或结构。

信息和相关技术控制目标(COBIT，Control Objectives for Information and related Technology)，是应用最广泛的安全控制框架之一。

COBIT是由信息系统审计和控制协会(ISACA)编制的一套记录IT最佳安全实践的文档。

它规定了安全控制的目标和需求，并鼓励将IT安全思路映射到业务目标。

COBIT基于六个关键原则进行企业IT治理和管理。

·原则1: 为利益相关方创造价值

·原则2: 采用整体分析法

·原则3: 动态地治理系统

·原则4: 把治理从管理中分离出来

·原则5: 根据企业需求量身定制

·原则6: 采用端到端的治理系统

COBIT不仅可用于计划组织的IT安全，还可作为审计人员的工作指南。

COBIT是一个得到广泛认可与重视的安全控制框架。

IT安全还有很多其他的标准和指南，如下所示：

·NIST SP 800-53 Rev.5“信息系统和组织的安全和隐私控制”

包含了美国政府为组织安全提供的通用性建议。

·互联网安全中心(CIS)

提供针对操作系统、应用程序和硬件的安全配置指引。

·NIST风险管理框架(RMF)

对联邦机构制定了强制性要求。RMF分为六个阶段：分类、选择、实施、评估、授权和监控。

·NIST网络安全框架(CSF)

为关键基础设施和商业组织而设计，由识别、保护、检测、响应和恢复这五个功能构成。

它是对将在持续进行基础上执行的业务活动的规定，以便随着时间的推移支持和改进安全。

·IS0/IEC 27000系列

国际标准，可作为实施组织信息安全及相关管理实践的基础。

·信息技术基础设施库(Information Technology Infrastructure Library, ITIL)

最初由英国政府制订，是一套被推荐的优化IT服务以支持业务增长、转型和变革的最佳实践。

ITIL的重点是理解IT和安全需求如何与组织目标进行集成并保持一致。

当在已建立的基础设施中制订IT安全解决方案时，ITIL和操作流程通常被用作起点。

1.5.5 应尽关心和尽职审查

为什么计划安全如此重要？

原因之一是需要进行应尽关心和尽职审查。

应尽关心是指制订计划、策略和流程以保护组织的利益。

尽职审查指的是实践那些维持应尽关心工作的活动。

对于考试，

应尽关心是指制订一种正式的安全框架，其中包含安全策略、标准、基线、指南和程序。

尽职审查是指将这种安全框架持续应用到组织的IT基础设施上。

运营安全指组织内的所有责任相关方持续实施应尽关心和尽职审查。

应尽关心是知道应该做什么并为此制订计划，而尽职审查是在正确的时间采取正确的行动。

在当今的商业环境中，谨慎是必需的。

在发生安全事故时，拿出应尽关心和尽职审查的证据是证明没有疏忽的唯一方法。

高级管理者必须在安全事故发生时出示应尽关心和尽职审查的记录以减少他们面临的处罚和应该承担的罪责。

1.6 安全策略、标准、程序和指南

对大多数组织来说，维护安全是业务发展的重要内容。

为降低安全故障出现的可能性，实施安全的流程在某种程度上就是按照组织架构确定的文档。

通过开发和实现文档化的安全策略、标准、程序和指南，可以生成可靠的、可依赖的安全基础设施。

1.6.1 安全策略

规范化的最高层级文件被称为安全策略。

安全策略定义了组织所需的安全范围，讨论需要保护的资产以及安全解决方案需要提供的必要保护程度。

安全策略是对组织安全需求的概述或归纳，它定义了战略性安全目标、愿景和宗旨，并概述了组织的安全框架。

安全策略用于分配职责、定义角色、明确审计需求、概述实施过程、确定合规性需求和定义可接受的风险级别。

安全策略常用于证明高级管理者在保护组织以使其免受入侵、攻击和灾难时已经执行了应尽关心工作。

安全策略是强制性的。

很多组织使用多种类型的安全策略来定义或概述其总体安全策略。

组织安全策略关注与整个组织相关的问题。

特定问题的安全策略专注于特定的网络工作服务、部门、功能或有别于组织整体的其他不同方面。

特定系统的安全策略关注单个系统或系统类型，并规定经过批准的硬件和软件，

概述锁定系统的方法，甚至强制要求采用防火墙或其他特定的安全控制。

从安全策略可引出完整安全解决方案所需的其他很多文档或子元素。

策略是一种概述，而标准、基线、指南和程序包括关于实际安全解决方案的更具体、更详细的信息。

标准处于安全策略的下一级别。

1.6.2 安全标准、基线和指南

一旦设定主要的安全策略，就可在这些策略的指导下编制其他安全文档。

标准对硬件、软件、技术和安全控制方法的一致性定义了强制性要求。

标准提供了在整个组织中统一实施技术和程序的操作过程。

基线定义了整个组织中每个系统必须满足的最低安全级别。

基线是一种更注重操作的标准形式。

所有不符合基线要求的系统在满足基线要求之前都不能上线生产。

基线建立了通用的基础安全状态，在此之上可实施所有额外的、更严格的安全措施。

基线通常是系统特定的，一般参考行业或政府标准。

指南是规范化安全策略结构中基线的下一级元素。

指南提供了关于如何实现标准和基线的建议，并且是安全专业人员和用户的操作指南。

指南具有灵活性，所以可针对每个特定的系统或环境分别制订指南，并可在新程序的创建中使用指南。

指南说明应该部署哪些安全机制，而不是规定特定的产品或控制措施，并详细说明配置。

指南概述了方法，包括建议的行动，但并非强制性的。

1.6.3 安全程序

程序是规范化安全策略结构的最底层元素。

程序或标准操作程序(standard operating procedure, SOP)是详细的分步实施文档，描述了实现特定安全机制、控制或解决方案所需的具体操作。

程序可讨论整个系统部署操作，或关注单个产品或方面。

程序必须随着系统硬件与软件的演进而不断更新。

程序旨在通过标准化与一致件的结果来确保业务流程的完整性。

在规范化安全策略文档结构中，顶层的文档较少，因为它们一般是对观点和目标的广泛讨论。

在规范化安全策略文档结构的下层有很多文档（即指南和程序），因为它们包含了对数量有限的系统、网络、部门和领域的特定详细信息。

将这些文档作为独立实体保存，可获得以下好处：

·并非所有用户都需要知道所有安全分类级别的安全标准、基线、指南和程序。

·当发生更改时，可以较方便地只更新和重新分发受影响的策略，而不必更新全部策略并在整个组织中重新分发。

许多组织只是努力完成基本安全参数的定义，对日常活动每个方面的详细描述较少。

然而在理论上，详细和完整的安全策略能以针对性的、高效的和特定的方式支持现实世界的安全。

如果安全策略文档相当完整，就可用于指导决策、培训新用户、响应问题以及预测未来的发展趋势。

1.7 威胁建模

威胁建模是识别、分类和分析潜在威胁的安全过程。

威胁建模可被当作设计和开发期间的一种主动措施来执行，也可作为产品部署后的一种被动措施来执行。

这两种情况下，威胁建模过程都识别了潜在危害、发生的可能性、关注的优先级以及消除或减少威胁的手段。

威胁建模不是个独立事件。

组织通常在系统设计过程的早期就开始进行威胁建模，并持续贯穿于系统的整个生命周期。

例如，微软使用安全开发生命周期(SDL)过程在产品开发的每个阶段考虑和实现安全。

这种做法支持“设计安全，默认安全，部署和通信安全”（也被称为SD3+C）的座右铭。

这一过程有两个目标：

·降低与安全相关的设计和编码的缺陷数量。

·降低剩余缺陷的严重程度。

防御式威胁建模发生在系统开发的早期阶段，特别是在初始设计和规范建立阶段。

这种方法基于在编码和制作过程中预测威胁和设计针对性防御措施。

大多数情况下，集成的安全解决方案成本效益更高而且比后期追加的安全解决方案更有效。

虽然还没成为一个正式的术语，但这个概念被认为是一种主动式威胁管理方法。

1.7.1 识别威胁

可能存在的威胁几乎是无限的，所以有必要使用结构化的方法来准确地识别相关的威胁。

例如，有些组织使用以下三种方法中的一种或多种。

·关注资产

该方法利用资产评估结果，试图识别有价值的资产面临的威胁。

·关注攻击者

有些组织能识别潜在攻击者，并能根据攻击者的动机、目标或者策略、技术和程序(TTP)来识别其所代表的威胁。

·关注软件

如果组织开发了软件，就需要考虑软件受到的潜在威胁。

通常将威胁与脆弱性结合起来，以识别能够利用资产并对组织带来重大风险的威胁。

威胁建模的最终目标：是对危害组织有价值资产的潜在威胁进行优先级排序。

当尝试对威胁进行盘点和分类时，不妨使用指南或参考，这通常很有帮助。

STRIDE 的威胁分类方案（         微软）：

·欺骗(Spoofing)

通过使用伪造的身份获得对目标系统的访问权限的攻击行为。

当攻击者将他们的身份伪造成合法的或授权的实体时，他们通常能够绕过针对未授权访问的过滤器和封锁。

·篡改(Tampering)

对传输或存储中的数据进行任何未经授权的更改或操纵的行为。

·否认(Repudiation)

用户或攻击者否认执行动作或活动的能力。

否认攻击还可能导致无辜的第三方被指责违反安全规定。

·信息泄露{Information Disclosure)

将私有、机密或受控信息泄露或发送给外部或未经授权的实体。

·拒绝服务(DoS)

该攻击试图阻止对资源的授权使用。这类攻击可通过利用缺陷、过载连接或爆发流量来进行。

·特权提升(Elevation of Privilege)

该攻击是将权限有限的用户账户转换为具有更大特权、权利和访问权限的账户。

攻击模拟和威胁分析过程(PASTA，Process for Attack Simulation and Threat Analysis)是一种由七个阶段构成的威胁建模方法。

PASTA 方法以风险为核心，旨在选择或开发与要保护的资产价值相关的防护措施。

PASTA 的七个阶段：

·阶段1: 为风险分析定义目标

·阶段2: 定义技术范围(Definition of the Technical Scope, DTS)

·阶段3: 分解和分析应用程序(Application Decomposition and Analysis, ADA)

·阶段4: 威胁分析(Threat Analysis, TA)

·阶段5: 弱点和脆弱性分析(Weakness and Vulnerability Analysis, WVA)

·阶段6: 攻击建模与仿真(Attack Modeling & Simulation, AMS)

·阶段7: 风险分析和管理(Risk Analysis & Management, RAM)

PASTA的每个阶段都有该阶段需要完成的目标和交付物的特别目标清单。

可视化、敏捷和简单威胁(Visual, Agile, and Simple Threat, VAST)是一种基于敏捷项目管理和编程原则的威胁建模概念。

VAST的目标是在可扩展的基础上将威胁和风险管理集成到敏捷编程环境中，详见第20 章。

上述这些只是由社区团体、商业组织、政府机构和国际协会提供的多种威胁建模概念和方法中的一小部分。

组织受到的潜在威胁是多种多样的。公司面临着源于自然环境、技术和人员的威胁。

应始终考虑组织的活动、决策和交互行为可能带来的最佳结果与最糟结果。

识别威胁是设计防御以帮助减少或消除停机、危害和损失的第一步。

1.7.2 确定和绘制潜在的攻击

威胁建模的下一步是确定可能发生的潜在攻击。

这通常通过创建事务中的元素图表及数据流和权限边界来完成（见图1.4) 。

这是一个数据流的示意图显示了系统的每个主要组件、安全区域之间的边界以及信息和数据的潜在流动或传输。

这是高层次的概述，而不是对编码逻辑的详细评估。

但对十较复杂的系统，可能需要创建多个图表，关注不同的焦点并对细节进行不同层级的放大。

一旦绘制出图表，就要确定涉及的所有技术。接下来，要确定针对图表中每个元素的攻击。

请记住，要考虑到各种攻击类型，包括逻辑/技术、物理和社会攻击。

这个过程将引导你进入威胁建模的下一阶段：执行简化分析。

1.7.3 执行简化分析

威胁建模的下一步是执行简化分析。

简化分析也被称为分解应用程序、系统或环境。

这项任务的目的是更好地理解产品的逻辑、内部组件及其与外部元素的交互。

无论是应用程序、系统还是整个环境，都需要被分解为更小的容器或单元。

如果关注的是软件、计算机或操作系统那么这些可能是子程序、模块或客体；

如果关注的是系统或网络，这些则可能是协议；

如果关注的是整个业务基础结构，那么这些可能是部门、任务和网络。

为理解输入、处理、信息安全、数据管理、存储和输出，应该对每个已识别的子元素进行评估。

在分解过程中，必须确定五个关键概念。

·信任边界

信任级别或安全级别发生变化的位置。

·数据流路径

数据在两个位置之间的流动。

·输入点

接收外部输入的位置。

·特权操作

需要比标准用户账户或流程拥有更多特权的任何活动，通常需要修改系统或更改安全性。

·安全声明和方法的细节

关于安全策略、安全基础和安全假设的声明。

将系统分解成各个组成部分后，能够更容易地识别每个元素的关键组件，并注意到脆弱性和攻击点。

对程序、系统或环境的操作了解得越清楚，就越容易识别出它们面临的威胁。

一旦识别出威胁，就应该定义威胁的手段、目标和后果以对其进行完整记录。

要考虑实施漏洞利用所需的技术并列出可能的安全对策和防护措施。

1.7.4 优先级排序和响应

在完成文档记录后，下－步要对威胁进行排序或定级。

可使用多种技术来完成这个过程，如”概率＊潜在损失”排序、高/中/低评级或DREAD系统。

“概率＊潜在损失”排序技术会生成一个代表风险严重程度的编号。

编号范围为1~100，100代表可能发生的最严重风险；初始值范围为1~10，其中，1最低，10最高。

这些排名在某种程度上有些武断和主观，但如果由同4个人或团队为组织指定数字，仍会产生相对准确的评估结果。

高/中/低(1/2/3 或者绿/黄/红）评级过程更简单。

它创建了一个基本的风险矩阵或风险热图（见图1.5) 。

与任何风险评估方法一样，其目的是帮助确定关键优先级。

通过使用风险矩阵，可以为每个威胁分配一个概率和一个损害级别。

然后，当对这两个取值进行比较时，可以得到一个组合取值，该值位于九个方格中的某一位置。

HH（高概率/高损害级别）区域中的威胁是应该优先关注的，而LL（低概率/低损害级别）区域中的威胁是最后关注的。

DREAD 评级系统旨在提供一种灵活的评级解决方案，它基于对每个威胁的五个主要问题的回答。

·潜在破坏：如果威胁成真，可能造成的损害有多严重？

·可再现性：攻击者复现攻击的过程有多复杂？

·可利用性：实施攻击的难度有多大？

·受影响用户：有多少用户可能受到攻击的影响（按百分比）？

·可发现性：攻击者发现弱点有多难？

一旦确定了威胁优先级，就需要确定对这些威胁的响应。

要考虑解决威胁的技术和过程，并对成本与收益进行权衡。

响应选项应该包括对软件架构进行调整、更改操作和流程以及实现防御性与探测性组件。

这个过程类似于第2 章中讨论的风险评估过程。

区别在于威胁建模的重点是威胁，而风险评估的重点是资产。

1.8 将基于风险的管理理念应用到供应链

将基于风险的管理理念应用到供应链的方法旨在使安全策略更加可靠与成功，适合在所有规模的组织中运用。

供应链是一种概念，意指大多数计算机、设备、网络、系统甚至云服务都不是单个实体构建的。

事实上，我们所知道的大多数计算机和设备制造商都只进行最终组装，而不是生产所有单个部件。

通常CPU、内存、驱动控制器、硬盘驱动器、SSD卡和显卡都由其他第三方供应商生产。

即便是这些商品供应商，也不太可能自行开采金属，将石油加工成塑料或蚀刻芯片的硅。

因此，任何已完成的系统都有一段漫长而复杂的生产历史，这也使供应链得以存在。

供应链风险管理(SCRM)旨在确保供应链中的所有供应商或环节都是可靠的、值得信赖的、信誉良好的组织，

这些组织向业务伙伴（尽管不一定向公众）披露他们的实践和安全需求。

供应链中的每个环节都是可靠的，并对下一个环节负责。

每一次交接都经过适当的组织、记录、管理和审核。

安全供应链旨在确保成品质量，满足性能和操作目标，并提供规定的安全机制，

且在整个过程中，没有任何伪造或遭受未经授权或恶意操纵或破坏的节点。

在评估组织风险时，要考虑可能影响组织的外部因素，特别是与公司稳定性和资源可用性相关的外部因素。

供应链可能是一个威胁载体，当从一个本应可信的来源获得材料、软件、硬件或数据时，

该来源背后的供应链可能已被破坏，资产可能已中毒或被修改。

应评估组织的供应链以确定其带来的风险。

组织是不是在按时交付的基础上运营的？

材料是在生产之前交付的还是在生产需要时才交付的？

如果交货延误，在供应链运营重组时，是否有多余或缓冲的材料可用于维持生产？

大多数组织都依赖于其他实体生产的产品。

这些产品大多是作为一个漫长而复杂的供应链的一部分生产的。

对供应链的攻击可能导致产品出现缺陷或可靠性降低，或者可能允许远程访问或监听机制嵌入其他功能正常的设备中。

供应链攻击是一个难以解决的风险。

组织可以选择检查所有设备，以降低修改后的设备进入生产网络的可能性。

然而，随着芯片的微型化，几乎不可能在设备主板上发现额外的芯片。

此外，操作有可能是通过固件或软件（而不是硬件）进行的。

组织可以选择从值得信赖和信誉良好的供应商那里采购产品，甚至尝试使用在国内生产其大部分产品的供应商。

许多情况下，可能需要持续的安全监控、管理和评估。

这可能是行业最佳实践或监管要求。

这种针对供应链的评估和监控可能由供应链中的第一个或者最后一个组织进行，也可能需要外部审计人员参与完成。

当使用第三方评估和监控服务时，请记住，每个供应链实体都需要在其业务操作中体现出安全意识。

如果组织无法在安全的基础上管理自身的内部操作，他们又如何能够提供可靠的供应链安全管理功能呢？

如果可能，应为供应链中的每个实体设立最低安全要求。

对新的硬件、软件或服务的安全要求应该始终满足或超过对最终产品安全性的预期。

通常需要详细审查SLA、合同和实际执行情况。这是为了确保服务合同中包含有关安全的规定。

当供应链组件供应商正在制作软件或提供服务时，可能需要定义服务级别需求(SLR) 。

SLR是对供应商产品（或服务）的服务和性能期望的说明。

通常，SLR是由客户在SLA 建立之前提供的（如果供应商希望客户签署协议，应使协议包含SLR) 。