SBOM 喊话医疗器械网络安全：别慌，我罩你！Part Ⅱ
1. 前文回顾
大家好！本文的上半篇，我们对 SBOM 在医疗器械行业中的应用有了一个大体的了解，同时还相对详细地探讨了制造商对于 SBOM 的收集、生成、分发、维护的一些注意事项分享。（想要回顾可查看我们发布的 Part Ⅰ）
而本篇作为 Part Ⅱ，将为大家分享对于医疗机构来说 SBOM 获取和使用的一些注意事项以及 SBOM 的实际运用案例分享。在过去的十年里，医疗环境已经数字化，数字技术遍布医疗行业的每个部分。这种数字化转型让医疗领域在其行政和临床职能中依赖于软件和软件驱动的设备。不幸的是，这种数字化进程的快速发展也伴随着网络安全威胁的急剧上升。由于 HCP 领域越来越依赖于数字化和互联，这直接影响了不同的 HCP 组织和机构，包括大型医疗系统、小型农村医疗设施和日益增长的流动性医疗组织比如家庭护理。所以，对于 HCP 来说，SBOM 的获取和管理是我们需要重点讨论的部分。
2. HCP 在获取和管理 SBOM 时需要注意的事项
对于 HCP 来说，SBOM 应该在其采购设备之初就纳入风险管理的一部分。HCP 应要求制造商为任何会集成到其网络基础设施的设备提供 SBOM。为了能够更好的使用 SBOM，医疗机构应确保他们有能力获取和吸收 SBOM。对 HCP 来说，拥有一份完整和准确的软件和硬件资产清单是至关重要的。这份清单应保持最新的状态，包含具有唯一设备标识符的医疗设备，以便与其他资产管理系统和资产内容数据源（如 SBOM）相关联。HCP 需要了解其网络上运行的硬件资产和相关软件。一旦获得了 SBOM，就应该对其进行管理，使组织和机构利益最大化。
2.1 获取和管理 SBOM 的注意事项
HCP 需要了解硬件资产和相关软件，以及在 HCP 网络环境中存在和运行的软件即医疗设备（SaMD）。HCP 可以使用既定的信息技术和资产管理来清点那些直接从开发商那里购买的软件或定制开发的软件。但是，对这些采购的现成设备中的软件进行清点是很不现实的。SBOM 增加了 MDM 和 HCP 之间共享信息的透明度。以下是一些针对外部来源的 SBOM 和医疗机构自身拥有的 SBOM 相关事项的讨论：
采购：在采购过程中供应商需要提供 SBOM，使 HCP 能够审查设备使用的组件。HCP 应该注意的是，SBOM 在采购和交付期间可能随时会发生变化。
标准格式交付：SBOM 的交付应基于标准的格式并尽可能实现自动化分发和有效的获取机制。这使得信息能够有效地被 HCP 获取，并储存在一个安全的地方以保护数据的完整性。可以考虑的三种主要格式是 CycloneDX、SPDX 和 SWID。
独特的设备标识符：由于 HCP 的设备会存在多个型号和版本，所以最好的方式是能让设备的 SBOM 有一个唯一标识符，以方便准确地定位到某个 SBOM 对应的是哪一台设备。如 IMDRF 应用指南所述，唯一标识符（UDI）在产品层面上就要运用起来，以确保正确地对应到设备和制造商，但也包括医疗设备软件的版本号或设备本身的版本号（如果适用）。由于缺乏标准化的软硬件唯一标识符，可能需要手动进行定位。
完整度：SBOM 的完整程度会影响到其可利用的程度。SBOM 里的元素至少应包括作者姓名（公司名称和/或个人姓名）、时间戳、组件供应商（供货商）、组件名称、组件版本、唯一标识符和相互关系。（见 PartⅠ3.2.1）。
沟通的及时性：当在 SBOM 中发现存在已知漏洞的组件时，强烈建议 MDM 和 HCP 进行及时的沟通，以确保 MDM 能为解决该漏洞做出相应的动作，如果必要，应得到相关行政机构的批准。
加强设备管理：HCP 需要有建立和管理内部 SBOM 库的能力，让内部的每个设备都能有与之对应的 SBOM，以加强对设备管理。举例如下：
【1】搜索和查询能力：存储库除了需要有搜索和查询功能外，最好也能实现对已知漏洞的查询，从而便于对 HCP 的大量设备进行风险管理。HCP 甚至可能需要对所采购设备中包含的嵌套软件（nested software）级别进行查询以了解是否存在漏洞。 【2】更新和维护：存储库需要支持在设备的整个生命周期对 SBOM 内容进行更新和维护，以确保获取最新的信息。为了确保可管理性，自动化的程序是非常必要的。由于格式和软件标识符可能会在设备和存储库的生命周期中发生变化，因此，在设备标识符和一些用于记录 SBOM 信息的任何格式的文件之间进行对应的能力是这种 SBOM 存储库的最重要特征（比如 SWID 标签）。
储存库的安全性：SBOM 存储库应该是安全的（例如，为医疗机构中需要使用的人提供基于角色的限制性访问），以防止信息被人恶意修改或被用来攻击 HCP 的网络或设备。
注意：上面的 a-f 项是基于 SBOM 的普遍考虑，我们在 Part Ⅰ也讨论过，因为这些方面也适用于 MDM。
2.2 获取和管理 SBOM 的方法
SBOM 可以通过手动或自动的程序来获取。然而，由于手工操作的繁琐性，建议各 HCP 采用自动化的程序，以减少管理负担。自动化也有助于今后对 SBOM 的管理，因为 SBOM 可能会随着时间的推移而更新。作为医疗机构运营的一环，HCP 还可以充分利用 SIEM（Security,Information, Event_Management）的产品或服务来收集、存储、汇总和分析来自设备及服务器的相关数据。如果 SIEM 工具可以读取 SBOM 的格式，这些 SIEM 就可以用来摄取 SBOM。
为了能让 SBOM 更长久的使用，一些医疗机构正在探索通过 CMDB（Configuration Management Database ）或 CMMS（Computerized Maintenance Management System）将 SBOM 连接或整合到 VRM（Vendor Risk Management）系统中。在某些情景下，医疗机构也在探索如何更加高效地将 SBOM 纳入到这些设备或系统中。定制开发的软件工具或脚本也可用于获取 SBOM。对于是直接获取还是使用定制工具获取，HCP 需要基于其数据管理系统的特点去考虑。
下表大致总结了 HCP 在获取和管理 SBOM 时可能使用的一些方法的优点和缺点：
表 2：部分 SBOM 获取和管理方法的优劣势
3. SBOM 的使用案例
SBOM 在利益相关者中有着广泛的用途。就从 HCP 设备生命周期的这个角度来看，SBOM 在部署、集成、配置、使用、维护和设备配置管理过程中都有所帮助。SBOM 对于 MDM 的 TPLC 中，从设计到停产到结束支持阶段来说也是很有帮助的。总体来说，企业对 SBOM 的合理利用能让设备的整个生命周期中的安全风险大大降低。本节提供了 SBOM 作为辅助工具的使用案例，基于以下三大方向：风险管理漏洞管理事故管理下面的章节对这些案例进行了高度概括。虽然后面的章节主要基于 MDM 或 HCP 的角度，但其中一些案例可能也适用于其他利益相关者。
3.1 风险管理
3.1.1 MDM 的视角
IMDRF 的网络安全指南（IMDRF/CYBER WG/N60FINAL:2020）第 5.2 节中描述了典型的风险管理活动。对于 SBOM 的生成，制造商需要考虑整个软件供应链。这也包括纳入设备中的其他组件。通过对外部漏洞信息库的查看或检索，SBOM 可以协助识别这些组件中的现有漏洞。当发现有漏洞的组件时，它将基于该设备对这个有漏洞的组件的依赖性启动风险分析进程。它将结合软件的依赖项进行风险分析。这种依赖关系可以是（程序）库、操作系统、TCP/IP，也可以是软件运行状态所依赖的其他组件。下面列举了一些会受益于使用 SBOM 的风险管理清单：
风险评估：SBOM 与外部的漏洞信息库相结合，可用于识别潜在的漏洞。SBOM 提供关于可能存在的潜在漏洞的信息，包括其潜在的可利用性和影响。该漏洞信息可用于评估与某一特定漏洞相关的风险水平。
风险控制：监测并定期检查 SBOM 中所列组件的漏洞是否存在，有助于将风险保持在可接受的水平（另见 3.2）。
评估和监测：随着设备新版本的更迭保持对 SBOM 的更新
生命周期的风险管理：在出售给 HCP 时提供机器可读的 SBOM，作为产品安全文件的一部分，并在设备的整个生命周期内进行更新。（在设备接近 EOS 时，需提供最新的 SBOM 以方便医疗机构进行管理）。
3.1.2 HCP 的视角
HCP 在采购之初就应当把 SBOM 的使用作为 HCP 风险管理的一部分。SBOM 的存在提高了软件的透明度，从而能让我们尽早发现其中组件的潜在风险。这将使 HCP 更好地了解设备在其 TPLC 过程中的收益和风险，以及如何在设备生命周期中更有效地应用风险控制措施和修复策略。
3.2 漏洞管理
3.2.1 MDM 的视角
漏洞管理是 MDM 产品上市后的一个重要方面，以确保医疗设备的风险状况处于相对稳定的区间。作为网络安全的一部分，MDM 需要监控潜在威胁和漏洞信息的来源。SBOM 是一项必不可少的资源能帮助 MDM 及时发现会随着时间推移而出现和变化的漏洞。通过 SBOM，MDM 可以根据相关漏洞信息中受影响的组件来找出可能受到漏洞影响的医疗设备。将医疗设备 SBOM 信息与受漏洞影响组件报告的信息进行自动比较，可以进一步提高漏洞识别的及时性和准确性。这提高了制造商风险评估的能力，能根据需要与 HCP 进行沟通和修复。进行风险评估的可能会导致由于一个有漏洞的组件被替换掉，进而需要对 SBOM 进行修订。
3.2.2 HCP 的视角
漏洞管理是一个重要的过程，使医疗机构能够持续检测、评估和补救 IT 环境中的漏洞。由于每天都有新的漏洞被发现，它是一种有效检测和及时修复关键漏洞的方法。本节将探讨各种 SBOM 用例，以协助 HCP 进行漏洞管理。以下列举了一些受益于使用 SBOM 进行漏洞管理的情况，虽不是详尽无遗的，但会对 HCP 进行漏洞管理提供一定帮助：
针对新出现的漏洞对医疗机构资产进行监测：SBOM 可以和漏洞信息一起使用，以了解他们的医疗设备是否受到或如何受到新漏洞的影响。VEX（Vulnerability-Exploitability eXchange）可以作为一种漏洞的补充性数据的交换机制。
开展临时修复措施：SBOM 信息使 HCP 能够在 MDM 仍在评估影响或进行漏洞修复的开发时，根据需要执行一定的临时修复措施。我们仍然建议 HCP 与 MDM 就临时修复措施进行沟通，因为 MDM 可能对临时修复措施如何影响设备的后续使用有更全面的理解。MDM 可以使用 VEX 提供临时修复建议。
生命周期管理：SBOM 有助于了解新设备和已使用设备中有哪些软件在被支持，有哪些软件已经无法获取支持。MDM 如果能够提供对应产品的支持年限表是很有帮助的，如果 HCP 无法更换设备，他们有足够的时间来评估风险（无论是对病人还是企业都有极大好处）。
协助医疗机构自发开展安全活动：针对一些设备，比如嵌入式设备或 SaMDs 类设备，进行漏洞扫描非常难实现，SBOM 可以作为补充手段来开展漏洞识别和安全监测。
3.3 事故管理
MDM 或 HCP 可以通过多种方式来了解那些会对医疗设备造成影响的安全事件。我们需要意识到，SBOM 是其中一种非常重要的资源来帮助 MDM 和 HCP 在事故管理的五个阶段更好地对网络安全事件进行管理，特别是与强大的事件响应流程结合使用时，会发挥更大的作用。对于 MDM 来说，SBOM 存储库可以减少识别和评估有风险设备的时间。对于 HCP 来说，SBOM 存储库可以帮助最前线的支持团队和网络安全团队采取行动。具体来说，存储库提高了系统收集、关联和评估信息的能力以检测与网络安全有关的事件，并最终一定程度上的改善事故结果。总的来说，这种改善能力可以减少不完整的风险评估和数据丢失导致的证据销毁所带来的风险。
4. 医疗行业与 SBOM
4.1 SBOM 中包含的组件类型和生成工具
SBOM 的内容的来源多样。下面提供了可能包含在其中的组件类型示例和生成一份 SBOM 可能使用到的工具。
第三方组件类型
SBOM 中包含的组件类型的范围可能取决于多种因素，包括但不限于：MDM 的能力、HCP 的期望、现有 SBOM 软件的成熟度以及未来可能出台的对于 SBOM 的相关法规要求。
然而在管理 SBOM 时，根据组件的不同，需要不同的方法和工具进行存储和操作管理，所以了解组件的不同类型是很重要的，以下是一些常见的类型：i. 与专有医疗设备软件相链接或嵌入其中的第三方软件库。ii. 虚拟机、操作系统和操作系统中的第三方组件，例如驱动程序、数据库、管理工具和应用程序框架。iii. 供应商的硬件所附带的第三方组件，例如固件、嵌入式软件和 PLC。接下来的部分将针对这些不同类型的组件，为大家详细说明 SBOM 库的管理、操作的管理、以及通用工具的使用。
第三方软件库
在现代软件开发中，使用第三方组件的代码量通常比由制造商的自研更多。通过确保 MDM 跟踪并输出一个所使用的开源组件的列表并在每一次软件更新之后进行相应的更新，这样就达到了创建和管理 SBOM 的能力。这种手动跟踪和更新 SBOM 的能力可以被认为是将 SBOM 的使用纳入其研发流程的第一步。随着组织机构的不断发展，可能会以自动化的方式实现，让这个过程更加高效和准确。比如利用现有的 DevOps 环境。具体来说，可以在 DevSecOps 中的一个或多个阶段中集成自动化工具或插件。
SBOM 的优势在于它能够尽早地识别第三方软件以及这些软件中的已知漏洞。越早检测到漏洞就能越早修复，相比于后期检测到漏洞，会节省更多成本。在软件开发的早期阶段更换脆弱的组件并替换为不易受攻击的组件，可以降低成本，因为软件开发早期的工作量远小于开发后期工作量。代码重构量也会减少，因为代码复杂度和架构关系会随着软件开发进程的增加而增加。此外，早期检测可以让在整个 SDLC 中管理 SBOM 成为可能。一般来说，只要对软件进行更改就会改变 SBOM 的构成。
这种工具或插件通过分析软件来检测嵌入或链接到的开源软件，有些可以检测商业第三方软件。它们通常能够识别已知的且已经有对应安全补丁库的漏洞。对漏洞的监测又将反馈到以下阶段的 SBOM 中：i. 编码：执行静态代码分析时。（利用工具进行非运行态的源代码漏洞检测）ii. 构建：当软件在 Sprint 结束时构建时。这个阶段通常会进行编译和链接，并可能进行测试，以确保其符合要求并能正常运行。iii. 测试：例如在执行静态应用程序安全测试（SAST）时。
这些工具或插件通常被称为软件成分分析（SCA），它们不需要手动输入来生成 SBOM，而是利用一些可用的软件仓库来识别：i. 组件名称 ii. 组件供应商 iii. 组件版本 iv. 组件哈希 v. 关系（一个或多个依赖层）vi. 组件漏洞 vii. 许可证模型和合规信息
需要注意的是，除了大型商业化 SCA 工具之外，也有其他工具和插件可在代码构建测试期间使用，并产生类似的结果。虽然有些是免费的，并且也可以为各种规模的 MDM 提供自动化（的 SBOM 生成），但 MDM 应该谨慎选择最适合其需求的工具。
操作系统组件
虚拟机和操作系统是医疗设备 SBOM 的重要组成部分。现有的第三方组件依赖于设备软件构建所使用的操作系统，包括数据库软件、应用程序框架以及其他重要功能的组件，例如安全软件、系统管理工具、远程支持软件和网络组件。
有几种选择可以自动发现和管理操作系统上的第三方组件。一些 SCA 供应商可以覆盖前面讨论的第三方组件及其他未直接嵌入专有软件的操作系统上的组件。但也有针对软件资产管理（SAM）的供应商，SAM 是一种管理软件风险和保障其价值的方法。
如果 MDM 仍不想采用这些工具，则可以通过执行特定的脚本（例如 Windows 上的 PowerShell 脚本或 Linux 上的 Bash 脚本）来生成操作系统上的软件清单。另一个选择是使用漏洞扫描管理工具。后者的优点是它可以提供已知组件的漏洞信息。
固件、嵌入式软件和 PLC
第三方固件、嵌入式软件和 PLC 是医疗设备生命周期中最不容易发生更改的组件，除非发现漏洞。嵌入式软件是由板支持包、二进制驱动程序、SDK、CPU 微码和其他库构建的。这可能包括大量依赖于开源软件。识别包含在最终产品中的所有组件非常重要。
由于这些类型的组件与设备的硬件相关，它们是医疗设备的常规 BOM 的一部分。BOM 是制造设备所需的材料和组件的全面清单，因此包括的内容不仅仅是组件。因此，BOM 为这些第三方组件的清单和管理提供了一个良好的起点。像 SBOM 一样，常规 BOM 可以从各种来源获取，包括 MDM 的开发活动或通过第三方提供的 BOM。可以使用源代码管理系统和二进制软件组合分析的组合来自动化或验证生成这些信息。需要注意的是，任何使用的工具都应与嵌入式系统兼容。
如果通过产品生命周期管理（PLM）或企业资源规划（ERP）软件管理 BOM，则可以使用导出功能提取组件。如果条件允许，也需尽可能的利用固件、软件或 PLC 供应商的上游 SBOM 为需要的第三方组件提供额外的深度。如果这些组件是专有的，例如由医疗设备制造商开发的，则适用与第 4.1 节“第三方软件库”中描述的相同方法。
5. 总结
SBOM 的存在是医疗器械行业软件透明度的重要保障，某种意义上，它是连接 MDM 和 HCP 的软件信息交流的“纽带”，也是医疗器械网络安全的底座。不难发现，无论是从 MDM 还是 HCP 的角度，SBOM 要更快更好地发挥其效用，我们都应达成以下几点共识：1. 肯定 SBOM 在医疗器械行业中的重要性 2. SBOM 在基于 MDM 和 HCP 的供应链中的流转应是高效且敏捷的 3. SBOM 的不断优化需要行业中各利益相关者的共同努力，缺一不可至此，我们关于 SBOM 在医疗器械网络安全中应用原则及实践的讨论就告一段落了，希望本文基于 SBOM 的探讨能够为您带来一定的帮助。我们下期再见！
参考文献：
Principles and Practices for Medical Device Cybersecurity IMDRF/CYBER WG/N60: FINAL:2020 (April 2020) ：
Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity：
OASIS Profile 5: VEX：
正本清源，不止于安全。 2022-05-20 加入
安势信息致力于解决软件供应链中的安全和合规问题。安势信息以行业领先的SCA （软件组成分析）产品作为切入点，围绕DevSecOps 流程，着力于从工具到流程再到组织，坚持持续创新，打造独具特色的端到端最佳实践。
评论