第二部分：商业观点

概述

安全投资是需要与商业决策者传达到位的，他们通常对于安全风险、措施的细节不熟悉，系统的厂商、集成商、操作员等需要建立足够支撑提供安全活动管理、计划、投资的程序，这些安全活动需要与商业目标、组织的风险策略达成一致。IIoT系统的安全投资需要能够规避系统down机、系统破坏、隐私数据泄露等安全风险，这些是需要额外投资的，并且还会在一定程度上牺牲部分客户体验，这些附加投资必须能说服利益相关方是值得的，花费是小于不做安全防护带来的商业风险以及损失恢复的。

工业系统安全工程的保护策略需要匹配保护目标、风险策略与商业优先级。安全评估框架需要能够协同安全投资优先级评估安全能力等级（内部用，非外部审计用）。风险管理通常由敌对模型、演进威胁模型以及最终定义安全控制手段、能力来管理系统生命周期内的风险，模型和决策需要考虑到系统中不同的多方角色。

风险管理

风险管理方式分类：完全消除所有风险是不现实的，需要根据评估风险的投入产出做出适当选择。风险管理主要有如下几种方式：

• 风险规避：试图完全消除风险，通常只能通过移除引起风险的功能来实现。
• 风险缓解：采取补偿措施来降低不可完全规避的风险的影响。是风险无法被规避时常用的策略，通过一系列安全、评审、补丁管理的系统方法实现。
• 风险转移：转移风险到第三方。通常以保险的形式付费转移风险，风险的特点是高影响、低频次、具有不可接受的高消减投入。风险转移也可以通过将成本转嫁给客户或作为外包的一个方面来实现。
• 风险接受：对于某些已识别的风险，决定承担这些风险并不采取任何措施来减轻或消除它们。通常在缓解的成本超出风险事件发生时的成本。
• 剩余风险：所有的安全措施都被采取之后剩余的风险。由于对系统安全、人员可信等的错误假定，一些未知的风险仍然存在。需要持续使用合适的指标检测跟踪剩余风险，采取高性价比、安全控制成本能够与有效性取得平衡的附加安全措施。

安全流程

NIST提出了保证系统安全的5个基本活动：

• 识别：制定对于管理系统、资产、数据和功能的安全风险的结构性理解。
• 保护：制定与实现合适的保护，确保关键基础设施服务的安全生产。
• 检测：制定与实现合适的活动，监控识别安全事件的出现。
• 响应：制定与实现合适的活动，以对检测到的安全事件采取行动。
• 恢复：制定与实现合适的活动，以维护系统复原能力，并恢复因安全事件而受损的的服务、功能。

风险评估

随着技术种类、复杂性增加，系统的暴露面与攻击路径也随之增加，加大了系统风险。攻击路径范围涉及很广，包括物理攻击、网络攻击、软件攻击、操作人员的攻击、供应链攻击等。每个行业都有特有的攻击路径技术集，影响取决于系统的行业、设计以及商业优先级。

现代攻击涵盖的可能的攻击路径与动机很广。常用的列举安全威胁、攻击路径的模型有OWASP、STRIDE：

OWASP：每个组织根据风险承受能力结合下表去理解判断哪种攻击路径比较匹配，然后结合静态分析、动态测试、模糊测试、渗透测试以及合适的评估指定出安全措施、缓解措施。Top10路径如下：

• 不安全的web界面
• 不充分的认证、授权
• 不安全的网络服务
• 传输加密缺失
• 隐私问题
• 不安全的云服务接口
• 不安全的移动接口
• 不充分的安全配置
• 不安全的软件、固件
• 物理安全差

STRIDE：STRIDE是微软提出来的对IT系统进行风险建模、威胁评估的模型，STRIDE也扩容包含了IoT的威胁以适用IIoT系统。包括如下几个元素：

• 身份识别（Spoofing identity）：这一类威胁包括某个人或设备使用其它个体的认证凭据（登录用户名、密码、伪造的设备ID等）
• 数据篡改（Tampering with data）：篡改关联设备或者在网络传输的数据
• 抵赖（Repudiation）：否认个人或设备参与了某项业务或事件。指的是追踪个人或者设备对于一件事件负责的能力。
• 拒绝服务（Denial of service）：通过资源消耗或者不可靠的执行等致使特定服务不可用。
• 权限提升（Elevation of privilege）：未授权用户获取了可以破坏整个系统的完全访问权限。随着特权提升，攻击者已经渗透了所有系统防御程威了可信系统本身的一部分，是个非常危险的状态。

风险传递

安全投资是需要与商业决策者传达到位的，他们通常对于安全风险、措施的细节不熟悉，这里有三种基本的风险传递方法：

定量风险评估：事件的风险=事件发生的概率 * 事件后果成本。适用于高频次低影响的事件场景，可以足够给出足够的统计学特征。不适用于低频次、高影响的事故。

定性风险评估：使用代数进行成本或概率估计，并将风险表示为这些代数的数学函数。

• 例如，法国ANSSI标准1通过为后果、可能性、系统复杂性/功能、连接性、暴露和可访问性中的每一个分配一个小整数评级来计算工业系统的重要性。这些排名被算术组合，产生一个在1到3之间的数字，描述工业控制系统的重要性，然后为每一类控制系统规定最低安全措施。其他定性系统为个人风险和事件类型分配和计算定性指标。
• 通过系统性方法开发了后果可能性模型、攻击可能性模型。故障树分析：用来理解低级别事件如何结合起来产生了重大的不良后果。攻击树分析：用来理解独立的IIoT系统组件是如何组合起来带来特定危害的。
• 低频、高影响事件而产生的风险对业务决策者来说可能很难评估。定性风险分数被广泛用于评估此类风险，但是这些分数仍难以与安全预算、投资回报、组织风险偏好产生很好的联系。有些安全团队选择使用有代表性的、显著不良后果的攻击场景与业务决策者做沟通传递，业务决策者发现特定的代表性的攻击场景比抽象的分数更容易让人理解，帮助其选择其认为能更好解决问题的安全程序，并比较升级安全系统与承担特定安全事件后果两者的成本。

持续商业关注

安全相关技术的更新往往被忽略，由于组织更容易聚焦关心期望的业务功能。系统使用过程中的关键系统特征需要在计划、资源、管理上充分投入、持续关注。

由于攻击会随着时间的推移而变化，因此安全性应定期接受审查。攻击的技术、成熟度和重点的变化率因各种类型的技术及其支持的业务部门和垂直行业而异。

可能需要定期重新评估和修改，以解决这些审查期间发现的问题。

根据新威胁的出现或监管变化，除了供应商发布软件修复和更新所驱动的运营更新和产品修订之外，可能需要更频繁地审查和更新安全对策。

定期安全审查应遵循与系统最初概念化、设计、创建和部署活动中使用的相同程序。

如有必要，应重新验证和更新对运营、可用性、安全和其他业务需求的重大威胁的原始清单。应根据当前的行业最佳做法重新验证现有的对策。

准确记录了为满足声称的能力而作出的原始设计决策，以及用于支持所做的结构、设计和技术选择的证据，这审查将花费最小的努力。

度量与关键指标

业务决策者应该构建从系统架构设计到生产运行全方位的监控指标，考虑到所有利益相关方、法律法规、各部门相关者的因素，将其放在与监控系统性能、吞吐量、成本与效率等同样重要的地位，并周期性审视、调整。

有些指标与衡量标准在垂直行业是通用的（例如监控尝试攻击的次数、成功攻击次数，以及值得分析的成功攻击、事故、准事故、策略违反、异常现象的特征），另一些在行业内是特殊的（比如在煤气、水电行业，远程读数以及监控传感器寿命很重要，通过监控能快速识别是意外还是恶意破坏。）。

安全指标准确清晰的表示能够是运营、业务人员参与改进业务决策，可通过提前规避错误节省成本并提供可量化评估的基础。

管理注意事项

风险管理平衡了针对lloT系统的威胁与抵消这些威胁及其所代表的风险的安全响应。风险管理包括持续性根据KPI、监控数据确定安全任务的优先级，并强烈建议建立一个反馈循环来证明安全问题被成功解决。

快速高效进行安全响应是多维度的复杂挑战。需要具备：

1. 适应性（能够根据需要适应不断变化的威胁和系统配置）
2. 响应性（提供响应对安全威胁确实发生时将对lloT系统的影响降至最低）
3. 协作性（能够使不同的组织协同努力确保尽早识别安全威胁）

IIoT生命周期的信任渗透

IIoT系统一般是由多个子系统整合起来的复杂系统，系统的可信性包括整体、各部分子系统以及相互间交互的可信。信任渗透跨越了整个生命周期，不仅仅是运行阶段。从采购、调试、调配、定期使用以及报废等都必须仔细监控来确保系统可信贯穿始终。

系统生命周期

像医院、核电站等行业，信任需要被准确描述、验证、控制、限制，不能只靠信任背书，要进行实际的验证。

系统运营者需要将安全需求传递给系统构建者，系统构建者再分解到各个组件构建者，组件构建者确保交付的组件符合安全需求，系统构建者按照安全需求集成后交付给系统运营者。定义交付方要交付的能力的过程存在诸多挑战：

• 需求可能对于罕见场景下难以显现、被描述。
• 需求可能会在设计阶段或系统生命周期内发生变化。
• 背景知识、技术术语、语言等可能因不同而产生混淆。
• 在为子组件定义需求上的小错误可能会扩大为整个IIoT系统的大问题。

由ISO、IEEE、UL、IEC以及政府组织制定了很多标准简化了交流过程，需求、能力被清晰的定义在标准中。需求主要有两类：显性需求（业务需求，比如空调温度可以被显形控制）、隐性需求（非业务需求，空调温度远程控制不能被黑客攻击，以及其它DFX需求）。需求接收方往往倾向于关注显形需求、忽略隐性需求，这也是为什么在定义标准时要引入参考标准的另一个原因。

交付方提供的能力是否满足安全可信要求，需要接收方在类生产环境上进行严格验证，或者通过第三方验证。接收者往往由于缺乏时间、资源而忽略系统性的验证，信任就只能取决于跟交付方的关系，历史的好名声了。

信任渗透的角色

组件构建者：提供特定能力的标准化产品、服务的硬件供应商、软件开发商和服务开发商。

系统构建者：系统集成商、解决方案提供商。

运营用户：是系统的所有者、运营者，使用这些组件、解决方案或者服务满足预期用途。

上层对下层提要求，上层递归依赖下层的安全可信并做可信集成；有些情况下角色之间的界限是模糊的，可能同时承担多个角色。

组件构建者可信

需要递归保证子组件的可信以及集成可信。

软件的补丁、维护等会有厂家不再维护的风险，即使有源码也很难维护修改bug。

API的继承性需要看护保证。

更新软件、替换硬件等过程会有被非法复制、恶意篡改、不合规硬件等风险，需要进行完整性的可信保障。

系统构建者的可信

处于成本收益考虑，系统构建者通常建立体系允许集成在平台上的多种多种技术组件能够在许多设备所有者之间大规模转售。

系统构建者的设计相对更定制化，可以通过间接消减的方式解决安全问题，比如防火墙、严格的访问控制、网络入侵检测、行为异常检测等。

系统构建者需要在整个生命周期负责整个系统的安全可信，不仅包括设计、安装、运行，也包括后期的替换失败的组件、保持对整个系统的把控。

运营用户角色可信

运营用户是可信渗透的起始点，需要周期审视如下：

• 系统满足利益相关方的需求
• 部署系统的所有威胁得到评估
• 部署系统的风险被量化、认可
• 在整个生命周期对风险管理的措施（更新、安全措施、缓解控制等）

系统的可信是受约束在各个组件提供的特定能力基础上的，运营者不可随意拆解组件移做他用，会破坏系统可信。

运营者承担最终的风险，历史表明大部分系统经营者承担的损害、收入损失、诉讼付款、严重伤害私网责任，源于对于交付的信任太高，又没有提出足以让交付方负责人的足够明确的需求。