一、前言

这是一篇由灯塔实验室团队在《IEC TR 62443-2-3:2015》标准为基础原型，结合实际国内工控现场进行优化改进的技术分析报告，而非标准，旨在解决工业自动化和控制系统（IACS）安全问题。《IEC TR 62443-2-3:2015》是由ISA99委员会06工作组开发，是IEC 62443系列众多标准中的一个部分。结合根据工作经验和工控现场的特殊需求，本技术报告描述了有关补丁交换过程中，涉及的状态信息和适用性属性，并为工控用户（用户）和供应商（厂商）组织产品规划和建立补丁管理程序提供指导。

1.1 范围

本技术报告推荐了一种通用格式，用于分发从用户到工控厂商有关安全补丁的信息属性，定义与工控厂商开发补丁相关的一些活动信息，以及由用户部署补丁的方式。既可以用于安全相关的补丁信息，也可以适用于与安全无关的补丁或更新，即不区分是否是为操作系统（OS），应用程序或设备提供的补丁，也不区分提供基础设施组件或工控应用程序的厂商，这些方法可以为适用于工控的所有补丁提供指导。此外，补丁的类型可以用于解决bugs，可靠性问题，可操作性问题或安全漏洞。

1.2 引用标准

以下参考文件对于本报告的应用是必不可少的。

ANSI/ISA-TR62443-1-2（TR99.01.02）–工业自动化和控制系统的安全性，第1-2部分：术语和缩写术语表
ISA-62443-2-1（99.02.01）–工业自动化和控制系统的安全性：第2-1部分：工控安全管理体系的要求
工业和信息化部关于印发《工业控制系统信息安全防护指南》2016-10-19 中的第二章《配置和补丁管理》
GB/T 32919-2016 《信息安全技术 工业控制系统安全控制应用指南》

1.3 相关术语

Bug（缺陷）: 软件原始开发中的缺陷（例如安全漏洞），导致其以非预期的方式执行或表现（例如，引起可靠性或可操作性问题）。
Patch（补丁）: 为了解决安全漏洞，bug，可靠性或可操作性问题，或添加新功能的增加的软件变更。注：补丁(Patches)还可以称为软件更新，软件升级，固件升级，服务包，热修复，基本输入输出系统（BIOS）更新和其他数字电子程序更新。
Patch lifecycle（补丁的生命周期）: 补丁被推荐或创建到废弃的时间段。
Patch Management （补丁管理）：补丁管理是用于监控补丁发布，决定哪些补丁应部署到哪个产品上。补丁是否应在产品部署之前进行测试，在哪个指定时间部署补丁，以及成功部署后的跟踪等一系列过程。

二、工控系统补丁概述

2.1 工控面临的补丁问题

用户在尝试为工控资产实施补丁管理时面临许多挑战，为工控资产打补丁意味着改变原有环境，对其安全性、可操作性或可靠性产生不确定的负面影响。就像很多流行的工控安全攻防比赛，作为组织方，很难决定是否同意选手对目标防护系统打补丁，因为那样将改变比赛环境，影响比赛规则，甚至可能导致预先设置好的攻防场景失效。而实际的工控现场也同样，不兼容的更新补丁很有可能会对业务造成中断，影响企业的生产运行，并造成损失。

因开发成本、研发能力和标准不统一等因素，工业自动化和控制产品在设计之初并未考虑用户对安全的需求，导致用户在修复工控资产需要额外的资源和工具，如工控系统的虚拟化仿真测试环境、业务应用仿真测试环境、工控靶场等。而工业自动化厂商和产品众多，每个补丁对应许多不同型号的产品，工控安全管理人员需要收集并分析每个设备的补丁信息，在工控靶场上进行安装和验证，确保在创建之前和之后进行备份，在安装或重新启动系统之前再次确保进行测试运行，最后跟踪所有的变更记录。

考虑到对工控资产打补丁可能造成的影响，多数用户只能选择在例行停产维护期间（通常每年一到两次）进行补丁更新，一些非常关键的、需要连续运行的系统甚至可能没有停产窗口期，从而没有机会更新补丁。

同时，更新补丁对企业决策者来说，是一种高风险的安全决策。如果风险一旦大于使用补丁的成本，那工作可能会补延迟，或者使用其他安全措施来减轻风险，甚至干脆停用。

注：关于使用“其他安全措施”不在本报告的论述范围。
错误的补丁更新可能包括：

• 系统补丁和控制系统软件之间不兼容；
• 病毒和反恶意软件误报；
• 测试不足导致的系统性能、可靠性和可维护性降低。

2.2 补丁应用对工控管理影响

“道高一尺，魔高一丈”，面临信息和网络安全的挑战，厂商需要不断保持系统及时更新，而当漏洞一旦被披露，压力就立刻转移到了用户，他们需要尽快使用补丁。用户如果因为各种原因不能立即应用这些减轻漏洞风险的补丁，那么决策者就可能需要承担由此引发额外风险的责任。当然消除所有软件漏洞是不现实的，但用户决策者还是需要评估漏洞的风险，并确定何时和如何使用补丁程序。

错误的工控补丁管理很可能会给工控系统造成损失，或引发更多的风险。与企业办公系统不同，工控现场的损坏可能会影响系统安全、操作人员的人身安全、生产产品的质量、生产产品的安全性以及生产产品的可用性。

2.3 已停产的工控系统补丁缓解管理

工控用户可能会遇到供应商不再支持产品但被第三方报告了漏洞的情况，但这些系统还正在被使用，甚至短期内没有更新/更换的计划。工控系统通常已经在企业生产中运行了数十年，这些旧系统将是更加脆弱的，当决策者无法使用补丁程序解决问题时，用户只能考虑其他缓解措施。

一般这些缓解措施包括但不限各种终端防护手段，如杀毒软件、白名单软件、工业防火墙、工业网闸、工业IDS等。每一种防护手段都有各自的优势和弊端，用户需要从兼容性、功能性、可靠与稳定性、可维护性和性价比等方面综合考虑，并做出最适合企业的防护方法。

2.4 补丁的生命周期

对于一个有效的工控补丁管理过程，了解所有可用补丁的状态才是重要的。表1中定义了补丁的生命周期状态。

补丁程序定义了一个生命周期状态模型。其生命周期涵盖了从可用到授权，再到是否有效和安装。并非所有可用的补丁都与工控相关，并且并非所有补丁都与工控应用程序兼容。

表1 补丁生命周期状态

补丁状态	补丁状态定义	管理者
可用（Available）	补丁由第三方或工控供应商提供，但尚未经过测试。	用户 厂商
在测试中（In Test）	补丁正在由工控供应商进行测试	厂商
未批准（Not Approved）	补丁未通过工控供应商的测试，不应使用。	厂商
不适用的（Not Applicable）	该补丁已经过测试，但与工控的使用无关。	厂商
批准的（Approved）	该补丁已通过工控供应商的测试。	厂商
发布（Released）	补丁已发布供工控供应商或第三方使用，或者补丁可由用户直接应用于其内部开发的系统。	用户 厂商
内部测试中（In Internal Test）	补丁是由用户测试小组测试。	用户
未授权（Not Authorized）	补丁内部测试失败或可能不适用。	用户
已授权（Authorized）	补丁由用户发布，并满足公司关于可更新设备的标准或通过检查不需要测试。	用户
有效的（Effective）	补丁由协助所有者发布以供使用。	用户
已安装（Installed）	补丁已经安装在系统上。	用户

生命周期状态的状态模型如图1所示。工控厂商需要维护的补丁生命周期状态位于深灰色区域。工控用户维护的状态在浅灰色区域。状态之间的转换是用户或厂商的活动，如本报告其他部分所定义。

图1 补丁状态模型

三、 补丁属性信息管理

3.1 引言

定义补丁属性信息是必需的，因为一个完整的工控系统通常基于操作系统，应用系统（如分布式控制系统（DCS），实时/历史数据库（RTDB）和制造执行系统（MES）），以及使用IT工具（如关系数据库和非关系库）的应用程序和特定的软件程序组成。所有这些软件元素都需要定期更新，以修正新发现的错误或新发现的安全缺陷。

部署一个系统来管理补丁需要知道哪些补丁可用，补丁是否适用于已安装的系统，补丁是否针对已安装的产品进行过测试，以及工控厂商是否建议安装补丁。

确定补丁的兼容性可能是一项复杂的任务。工控厂商针对操作系统和库补丁进行产品测试，以确定补丁是否应该与其自动化产品一起使用。由于自动化产品与补丁不兼容而导致自动化产品的失败，可能导致生命、财产或产品的损失。所通常要求所有相关的自动化产品在补丁安装之前，需要对所有相关的自动化产品进行测试。

工控用户在他们的设施中经常有各种不同品牌的工控厂系统，因此管理来自多个工控厂商的补丁兼容性信息是困难的。因为补丁信息通常情况下，每个工控厂商的补丁格式都是基于自家特定格式的。而本章节定义了用于交换补丁信息的标准格式，用于标识产品，补丁和补丁状态。交换的信息属性包括：

a）提供产品的工控厂商的标识

b）工控供应商提供的产品的标识

c）提供补丁的厂商的标识（例如提供操作系统的公司）

d）补丁供应商产品的标识（如操作系统版本）

e）补丁供应商对补丁的识别

f）补丁是否适用于工控产品

g）对工控产品的补丁测试状态的指示

h）显示对工控产品的补丁测试结果

该信息允许最终用户在决策安装补丁之前做出明智的决定。属性信息定义了来自操作系统厂商提供的特定补丁是否已经针对特定版本的自动化软件进行了测试，以及测试补丁是否能与自动化软件协同工作的标识。

3.2 补丁属性信息格式

最小补丁兼容性信息的格式可基于可扩展标记语言（XML）技术，并使用XML架构定义（XSD）文件格式。补丁属性信息可用.VPC作为后缀的文件进行标识存储。

3.3 补丁兼容性信息文件名约定

VPC文件的文件名应该按照以下语法定义：
<filename> = <vendor_name> “_patch_compatibility_” <date> “_” <number> “.xml”
<vendor_name> 工控公司的公认的简称
<date> 兼容性文件由工控厂商发布的日期（根据IS0 8601 [18]格式化）
<number> 如果工控厂商在单一日期上发布多个文件，则标识该文件的编号
例1：SomeCompany_patch_compatibility_2017-12-08_01.xml
例2：OtherCompany_patch_compatibility_2017-12-08_02.xml

3.4 VPC文件架构

VPC格式允许在同一交换文件中交换有关多个补丁和工控厂商产品的补丁信息。图2说明了VPC文件模式定义。

图2  VPC文件架构

图3说明了VPC文件模式图格式

图3VPC文件模式图格式

VPC文件元素定义

表2定义了VPC XSD文件中的每个元素。交换文件中只应使用“定义”列中定义的适用性，测试结果和测试状态的枚举。

表2 VPC XSD文件元素

VPC XSD 补丁数据文件元素

元素	类型	定义
厂商名称	标识符类型	包含提供补丁信息的供应商名称的必需字符串。
描述	文本类型	一个可选的字符串，包含对供应商信息的描述。

 

VPC XSD 补丁供应商文件元素

元素	类型	定义
补丁厂商名称	标识符类型	包含提供补丁信息的供应商名称的必需字符串。
描述	文本类型	一个可选的字符串，包含对供应商信息的描述。

 

VPC XSD 补丁文件元素

元素	类型	定义
补丁产品	标识符类型	一个包含补丁厂商的产品名称的补丁所需的目标字符串。 例子：”SQL Server”, “Microsoft Windows”
补丁产品版本	标识符类型	一个必需的字符串，包含该补丁所需要的产品的版本。 例子：”Service Pack 2″, “7.15”, “A”, “R23.9”
补丁标识符1	标识符类型	一个包含补丁厂商的必需字符串，定义了补丁的主要标识。
补丁标识符2	标识符类型	一个可选的包含补丁厂商的字符串，定义了补丁的二级标识
补丁版本	标识符类型	一个可选的字符串，包含补丁的版本号。 例子：”1″, “1.0”, “1.2” 注意，如果由于前一个补丁版本中的错误而发布了多个版本，那么可能需要这个补丁。
发布时间	日期时间型	包含补丁发布日期的必需字符串。 例子：”2014-01-17″ 注意：按照ISO 8601格式化这个字符串
严重程度	代码类型	一个可选的字符串，包含补丁的严重程度。该值应是以下标准枚举之一:： 严重：应该安装补丁程序。它纠正了无需用户交互即可利用代码执行的漏洞。这些情况包括自我传播的恶意软件（例如网络蠕虫），或者在没有警告或提示的情况下执行代码的不可避免的常见使用场景。 重要：应该安装补丁程序。该补丁修正了一个漏洞，该漏洞的利用可能会损害数据的机密性，完整性或可用性，或者处理资源的完整性或可用性，但需要用户采取措施。 可选：可能安装了补丁程序。该修补程序纠正了需要独特或不常见的用户操作的漏洞。
更新类型	代码类型	包含修补程序类型的必需字符串值。 该值应该是下列标准枚举之一： 不安全：此更新涉及与安全无关的问题，并更新与安全性无关的已知问题。 安全：这个更新与安全问题有关，并且修复了已知的安全问题。
描述	文本类型	一个可选字符串值，其中包含更新和/或补丁的描述。
补丁状态	代码类型	包含修补程序状态的必需字符串值。 该值应该是下列标准枚举之一：： 已弃用：此修补程序不再是系统所需的更新。 当前的：这个补丁是最新的，应安装在所有的 “合格产品”产品中。
替换补丁	文本类型	一个可选的字符串值，它包含被替换的补丁的描述。 例子：KB12345 Windows 2008 64位。
配置	代码类型	包含修补程序状态的必需字符串值。 该值应该是下列标准枚举之一： 主要：这个补丁是一个主要的补丁，它有相关的补丁。 依赖：这个补丁依赖于一个主要的补丁和/或其他补丁。 独立：这是一个独立的补丁，不依赖任何更新。
参考信息	文本类型	一个可选的字符串值，该值包含用于进一步细节的更新的URL。
合格产品	标识符类型	一个可选的字符串值，包含引用特定于厂商的产品的<供应商产品> <产品ID >。这是通过此更新通过测试的产品列表中的项目。
不合格产品	标识符类型	一个可选的字符串值，包含引用特定于厂商的产品的<供应商产品> <产品ID >。这是一个产品列表中的项目，它在这个更新中测试失败。
保持产品	标识符类型	一个可选的字符串值，包含引用特定于厂商的产品的<供应商产品> <产品ID >。这是一个产品列表中的项目，它在这个更新中推迟测试。
未测试产品	标识符类型	一个可选的字符串值，包含引用特定于厂商的产品的<供应商产品> <产品ID >。这是暂停使用此更新进行测试的产品列表中的项目
评论	文本类型	一个可选的字符串，包含更新的评论。

 

VPC XSD 供应商产品文件要素

替换补丁	文本类型	定义
产品ID	标识符类型	用于将产品的名称和版本映射到与更新相关的测试结果的必需字符串标识符。
名称	文本类型	包含产品名称的必需字符串。
操作系统	文本类型	包含产品操作系统描述的必需字符串。
版本	文本类型	包含产品版本的必需字符串。
发布日期	日期时间型	包含产品版本发布日期的必需字符串。
评论	文本类型	一个可选的字符串，包含对产品和版本信息的注释。

四、 用户补丁管理

工控用户往往容易忽视的一个义务，即通过为工控的资产打补丁，来维护其运营业务的可靠性、可操作性、安全性和产品质量，实现网络安全保障。

工控用户应：

a）建立和维护与工控相关的所有资产的目录清单。该清单可以通过修改其功能、配置、操作、软件、固件、操作代码等来保持更新。这些设备应当被标注为“可更新”设备；

b）建立并保持对每个设备当前安装版本的准确记录，称为“已安装”版本；

c）定期确定每个设备可用的升级和更新，称为“最新”版本；

d）定期确定由工控厂商认定为兼容的，升级和更新的“发布版本”，并满足用户的“可更新”设备标准；

e）部署和应用与实际场景相类似的仿真补丁测试环境，以便在安装补丁时不会对工控的可靠性和可操作性产生负面影响。已成功通过这些测试的补丁称为“授权补丁”；

f）在系统设计（例如：冗余，容错，安全）和运行要求（例如，计划外停机，计划中断，进程等）的约束条件下，在下一次可用的机会下安排安装授权和有效的补丁；

g）按照计划的时间间隔至少每季度更新记录，更新可更新设备及其安装版本的列表，授权和有效版本以及发布版本；

h）确定一个例行的时间点，例如何时有可用补丁或至少每年一次；

i）实施补丁或缓解对策来减少工控中存在的安全漏洞。

注：具体更加详细的细节管理请关注灯塔实验室的后续文章。

五、 厂商补丁管理

对于正在运行的设备，工控安全性是非常重要的，并且需要采取主动措施来减少工厂被损害的可能性，因此确定哪些补丁适用，并且应用在产品上之前，进行详细测试是工控厂商的责任。

工控厂商应该：

a）提供描述所提供的产品及其系统的软件修补策略的文档；

b）通过分析和验证补丁（包括由操作系统供应商和工控产品使用的第三方软件发布的补丁），验证所有补丁的适用性和兼容性；

c）提供所有补丁及其批准状态的清单，包括描述的信息和数据格式；

d）定期和理想情况下，在操作系统或第三方软件制造商发布补丁后30天内，通知用户并更新上述补丁列表;

e）对达到最大使用年限的组件提供足够的预警（至少两年前）。

f）向工控用户提供有关支持工控产品（包括安全更新）政策的信息。

注：具体更加详细的细节管理请关注灯塔实验室的后续文章。