SBOM喊话医疗器械网络安全：别慌，我罩你！Part Ⅱ
大家好！本文的上半篇，我们对SBOM在医疗器械行业中的应用有了一个大体的了解，同时还相对详细地探讨了制造商对于SBOM的收集、生成、分发、维护的一些注意事项分享，想要回顾的朋友可以点击下方链接查看：
而本篇作为Part Ⅱ，将为大家分享对于医疗机构来说SBOM获取和使用的一些注意事项以及SBOM的实际运用案例分享。在过去的十年里，医疗环境已经数字化，数字技术遍布医疗行业的每个部分。这种数字化转型让医疗领域在其行政和临床职能中依赖于软件和软件驱动的设备。不幸的是，这种数字化进程的快速发展也伴随着网络安全威胁的急剧上升。由于HCP领域越来越依赖于数字化和互联，这直接影响了不同的HCP组织和机构，包括大型医疗系统、小型农村医疗设施和日益增长的流动性医疗组织比如家庭护理。所以，对于HCP来说，SBOM的获取和管理是我们需要重点讨论的部分。
对于HCP来说，SBOM应该在其采购设备之初就纳入风险管理的一部分。HCP应要求制造商为任何会集成到其网络基础设施的设备提供SBOM。为了能够更好的使用SBOM，医疗机构应确保他们有能力获取和吸收SBOM。对HCP来说，拥有一份完整和准确的软件和硬件资产清单是至关重要的。这份清单应保持最新的状态，包含具有唯一设备标识符的医疗设备，以便与其他资产管理系统和资产内容数据源（如SBOM）相关联。HCP需要了解其网络上运行的硬件资产和相关软件。一旦获得了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。
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时可能使用的一些方法的优点和缺点：
SBOM在利益相关者中有着广泛的用途。就从HCP设备生命周期的这个角度来看，SBOM在部署、集成、配置、使用、维护和设备配置管理过程中都有所帮助。SBOM对于MDM的TPLC中，从设计到停产到结束支持阶段来说也是很有帮助的。总体来说，企业对SBOM的合理利用能让设备的整个生命周期中的安全风险大大降低。本节提供了SBOM作为辅助工具的使用案例，基于以下三大方向：
下面的章节对这些案例进行了高度概括。虽然后面的章节主要基于MDM或HCP的角度，但其中一些案例可能也适用于其他利益相关者。
IMDRF的网络安全指南（IMDRF/CYBER WG/N60FINAL:2020）第5.2节中描述了典型的风险管理活动。对于SBOM的生成，制造商需要考虑整个软件供应链。这也包括纳入设备中的其他组件。通过对外部漏洞信息库的查看或检索，SBOM可以协助识别这些组件中的现有漏洞。当发现有漏洞的组件时，它将基于该设备对这个有漏洞的组件的依赖性启动风险分析进程。它将结合软件的依赖项进行风险分析。这种依赖关系可以是（程序）库、操作系统、TCP/IP，也可以是软件运行状态所依赖的其他组件。下面列举了一些会受益于使用SBOM的风险管理清单：
-
风险评估：SBOM与外部的漏洞信息库相结合，可用于识别潜在的漏洞。SBOM提供关于可能存在的潜在漏洞的信息，包括其潜在的可利用性和影响。该漏洞信息可用于评估与某一特定漏洞相关的风险水平。
-
风险控制：监测并定期检查SBOM中所列组件的漏洞是否存在，有助于将风险保持在可接受的水平（另见3.2）。
-
评估和监测：随着设备新版本的更迭保持对SBOM的更新
-
生命周期的风险管理：在出售给HCP时提供机器可读的SBOM，作为产品安全文件的一部分，并在设备的整个生命周期内进行更新。（在设备接近EOS时，需提供最新的SBOM以方便医疗机构进行管理）。
HCP在采购之初就应当把SBOM的使用作为HCP风险管理的一部分。SBOM的存在提高了软件的透明度，从而能让我们尽早发现其中组件的潜在风险。这将使HCP更好地了解设备在其TPLC过程中的收益和风险，以及如何在设备生命周期中更有效地应用风险控制措施和修复策略。
漏洞管理是MDM产品上市后的一个重要方面，以确保医疗设备的风险状况处于相对稳定的区间。作为网络安全的一部分，MDM需要监控潜在威胁和漏洞信息的来源。SBOM是一项必不可少的资源能帮助MDM及时发现会随着时间推移而出现和变化的漏洞。通过SBOM，MDM可以根据相关漏洞信息中受影响的组件来找出可能受到漏洞影响的医疗设备。将医疗设备SBOM信息与受漏洞影响组件报告的信息进行自动比较，可以进一步提高漏洞识别的及时性和准确性。这提高了制造商风险评估的能力，能根据需要与HCP进行沟通和修复。进行风险评估的可能会导致由于一个有漏洞的组件被替换掉，进而需要对SBOM进行修订。
漏洞管理是一个重要的过程，使医疗机构能够持续检测、评估和补救IT环境中的漏洞。由于每天都有新的漏洞被发现，它是一种有效检测和及时修复关键漏洞的方法。本节将探讨各种SBOM用例，以协助HCP进行漏洞管理。以下列举了一些受益于使用SBOM进行漏洞管理的情况，虽不是详尽无遗的，但会对HCP进行漏洞管理提供一定帮助：
-
针对新出现的漏洞对医疗机构资产进行监测：SBOM可以和漏洞信息一起使用，以了解他们的医疗设备是否受到或如何受到新漏洞的影响。VEX（Vulnerability-Exploitability eXchange）可以作为一种漏洞的补充性数据的交换机制。
-
开展临时修复措施：SBOM信息使HCP能够在MDM仍在评估影响或进行漏洞修复的开发时，根据需要执行一定的临时修复措施。我们仍然建议HCP与MDM就临时修复措施进行沟通，因为MDM可能对临时修复措施如何影响设备的后续使用有更全面的理解。MDM可以使用VEX提供临时修复建议。
-
生命周期管理：SBOM有助于了解新设备和已使用设备中有哪些软件在被支持，有哪些软件已经无法获取支持。MDM如果能够提供对应产品的支持年限表是很有帮助的，如果HCP无法更换设备，他们有足够的时间来评估风险（无论是对病人还是企业都有极大好处）。
-
协助医疗机构自发开展安全活动：针对一些设备，比如嵌入式设备或SaMDs类设备，进行漏洞扫描非常难实现，SBOM可以作为补充手段来开展漏洞识别和安全监测。
MDM或HCP可以通过多种方式来了解那些会对医疗设备造成影响的安全事件。我们需要意识到，SBOM是其中一种非常重要的资源来帮助MDM和HCP在事故管理的五个阶段更好地对网络安全事件进行管理，特别是与强大的事件响应流程结合使用时，会发挥更大的作用。对于MDM来说，SBOM存储库可以减少识别和评估有风险设备的时间。对于HCP来说，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，而是利用一些可用的软件仓库来识别：
需要注意的是，除了大型商业化SCA工具之外，也有其他工具和插件可在代码构建测试期间使用，并产生类似的结果。虽然有些是免费的，并且也可以为各种规模的MDM提供自动化（的SBOM生成），但MDM应该谨慎选择最适合其需求的工具。
虚拟机和操作系统是医疗设备SBOM的重要组成部分。现有的第三方组件依赖于设备软件构建所使用的操作系统，包括数据库软件、应用程序框架以及其他重要功能的组件，例如安全软件、系统管理工具、远程支持软件和网络组件。
有几种选择可以自动发现和管理操作系统上的第三方组件。一些SCA供应商可以覆盖前面讨论的第三方组件及其他未直接嵌入专有软件的操作系统上的组件。但也有针对软件资产管理（SAM）的供应商，SAM是一种管理软件风险和保障其价值的方法。
如果MDM仍不想采用这些工具，则可以通过执行特定的脚本（例如Windows上的PowerShell脚本或Linux上的Bash脚本）来生成操作系统上的软件清单。另一个选择是使用漏洞扫描管理工具。后者的优点是它可以提供已知组件的漏洞信息。
第三方固件、嵌入式软件和PLC是医疗设备生命周期中最不容易发生更改的组件，除非发现漏洞。嵌入式软件是由板支持包、二进制驱动程序、SDK、CPU微码和其他库构建的。这可能包括大量依赖于开源软件。识别包含在最终产品中的所有组件非常重要。
由于这些类型的组件与设备的硬件相关，它们是医疗设备的常规BOM的一部分。BOM是制造设备所需的材料和组件的全面清单，因此包括的内容不仅仅是组件。因此，BOM为这些第三方组件的清单和管理提供了一个良好的起点。像SBOM一样，常规BOM可以从各种来源获取，包括MDM的开发活动或通过第三方提供的BOM。可以使用源代码管理系统和二进制软件组合分析的组合来自动化或验证生成这些信息。需要注意的是，任何使用的工具都应与嵌入式系统兼容。
如果通过产品生命周期管理（PLM）或企业资源规划（ERP）软件管理BOM，则可以使用导出功能提取组件。如果条件允许，也需尽可能的利用固件、软件或PLC供应商的上游SBOM为需要的第三方组件提供额外的深度。
如果这些组件是专有的，例如由医疗设备制造商开发的，则适用与第4.1节“第三方软件库”中描述的相同方法。
SBOM的存在是医疗器械行业软件透明度的重要保障，某种意义上，它是连接MDM和HCP的软件信息交流的“纽带”，也是医疗器械网络安全的底座。不难发现，无论是从MDM还是HCP的角度，SBOM要更快更好地发挥其效用，我们都应达成以下几点共识：
2. SBOM在基于MDM和HCP的供应链中的流转应是高效且敏捷的
3. SBOM的不断优化需要行业中各利益相关者的共同努力，缺一不可
至此，我们关于SBOM在医疗器械网络安全中应用原则及实践的讨论就告一段落了，希望本文基于SBOM的探讨能够为您带来一定的帮助。我们下期再见！
Principles and Practices for Medical Device Cybersecurity IMDRF/CYBER WG/N60: FINAL:2020 (April 2020) ：
https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity
Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity：
https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity
OASIS Profile 5: VEX：
https://docs.oasis-open.org/csaf/csaf/v2.0/csd01/csaf-v2.0-csd01.html#45-profile-5-vex
首页标题
ꄲ
技术博客
ꄲ
SBOM喊话医疗器械网络安全：别慌，我罩你！Part Ⅱ
