医疗器械安全与获得监管部门批准

　　如今，医疗设备的安全性变得极其重要，以确保与您的设备交互的客户和患者，他们的健康和个人信息得到认真对待。在全球范围内，监管机构越来越多地要求并验证设备在产品发布前后尽可能安全。在美国，食品和药物管理局（FDA）发布了指南，概述了医疗器械的要求，这些要求要求涉及器械开发和维护的多个方面。

　　安全漏洞

　　安全漏洞是一种编程错误（或缺陷或错误），它打开设备以受到某些意外的外部或内部应用程序的影响。每个产品都存在安全漏洞，包括医疗设备。通过认识到这一点并为这种必然性做好准备，嵌入式开发人员可以限制这些漏洞可能引入的风险和潜在损害。

　　识别和缓解这些潜在问题的过程中最重要的部分称为常见漏洞和披露 （CVE）。CVE 最初定义于 1999 年，是产品中存在（或存在）的已知可利用安全问题的存储库。CVE 由 MITRE 公司和美国国家漏洞数据库 （NVD） 共同发布和维护，该数据库由美国国土安全部维护。从Heartbleed（CVE-2014-060）到Shellshock（CVE-2014-6271）再到URGENT/11（2019年发现的11个CVE），每个重大安全漏洞都被记录为CVE。

　　这些 CVE 的发现要么是由于造成的损害（在事后分析时，发现了潜在的问题，要么是由于尽职尽责的工程师发现了潜在的漏洞利用。好消息是，大多数漏洞利用都是在不造成损害的情况下被发现的;坏消息是，一旦漏洞通过CVE过程传达给世界，它很容易被全球黑客利用，因此时间至关重要。幸运的是，CVE 流程为产品或软件开发人员提供了在全球公布漏洞之前修复漏洞的时间，以便他们可以迅速采取行动实施设备安全。

　　一旦发现 CVE，就会为其分配一个 CVE 标识 ID。如果 CVE 被确定为问题，NVD 会为其分配漏洞分数。这是一个介于 1 和 10 之间的数字;数字越大，受影响设备的漏洞就越严重。NVD 还包含有关该问题的任何其他已知信息，以及指向进一步描述该问题的相关站点的链接 - 以及可用的现有修复程序。

　　CVE 报告流程的主要好处是了解问题、潜在修复以及问题可能对您的产品造成的严重性和风险。安全漏洞可能会使您的设备、客户和您自己面临多种不良后果，包括：

　　丢失或修改患者关键数据，可能对患者或医务人员造成伤害

　　泄露客户或最终用户数据，这可能导致身份盗用、违反 HIPAA 和其他严重后果

　　恶意行为者渗透设备，可能导致注入恶意软件、禁用设备、感染医院或临床医生网络的其他部分等。

　　安全问题和产品设计

　　在开发尽可能安全的设备时，重要的是要考虑潜在安全问题的不同来源：

　　开发设备时社区已知的问题

　　设备发布后发现的问题

　　由于预防性开发技术不足，专门为设备编写的软件引入的问题

　　针对已知问题的设备保护

　　如前所述，黑客用来闯入设备的许多潜在漏洞已被全球安全社区所知，并且已经得到修复。不幸的是，医疗设备通过设备发布时已经修复的问题被利用。防止这种情况发生需要付出努力，但这种努力将节省时间，保护您的声誉，并在发生漏洞利用时限制成本和潜在的法律风险。此外，监管机构要求设备开发人员在设备发布之前考虑这一点。在美国，这是FDA关于网络安全管理上市前提交内容的指南的一部分。这是过程。

　　每个显示为漏洞利用的 CVE 都可以在 NVD 和 CVE 数据库中搜索 - 按组件名称、CVE ID 或任何感兴趣的关键字进行搜索。例如，假设您的设备使用某些 Linux 发行版。通过搜索 Linux 漏洞，您会发现许多问题;作为具体示例，请考虑 CVE-201911683。这是一个严重的严重性问题，不应该出现在您的产品中，因为它是众所周知的，并且允许远程拒绝服务攻击或“未指定的其他影响”。查看此缺陷的条目，它在 Linux 内核版本 5.0.13 或更高版本中已解决，这意味着如果您的 Linux 内核是早期版本，则应在产品中升级到该版本。

　　对于产品中的开源组件，有许多工具可用于确定软件中是否包含重要的 CVE，其中最重要的称为 cve-check 。此工具会生成报告，其中包括哪些软件包包含通过执行版本检查在您使用的版本中未解决的 CVE。此信息可用于确定在将商品图片视为完整之前是否需要采取任何先发制人的措施。

　　制造商不想进行这种检查和更新，因为他们的首要任务是尝试设计和开发产品。大多数设备制造商宁愿让他们的工程师解决产品问题，而不是管理和维护Linux发行版。但是，开源提供的极端功能，稳定性和社区是有代价的（您想编写SSL层还是使用世界各地设备中使用的SSL层？设备制造商必须承担此任务，或者使用商业 Linux 发行版并要求其供应商负责为他们完成这项工作。

　　监控并确保解决已知漏洞并不是现阶段唯一要考虑的事情。如果不加以解决，可能会导致您的设备被利用的其他一些问题包括：

　　访问控制 – 您是否设计了定义可以访问各种类型数据（用户级别、管理级别、维护级别等）的角色的功能，并且是否确定只有授权角色才能访问数据？与对设备的物理访问相比，来自互联网的更高级别的访问控制是否难以访问数据？设备的身份验证方法是否难以利用？是否管理默认帐户和密码，使其无法在现场被利用？Linux 至少提供了两种方法来管理访问控制：1） 自由裁量 （DAC），标准的 Linux 访问控制模型，以及 2），强制 （MAC），它更复杂、更安全——SELinux 包的一部分。

　　加密 – 存储在您设备上的数据（内存和存储中）以及您的设备与其他设备之间的传输，是否受到保护和加密，以便只有那些想要看到它的人才能破译？许多允许外部参与者查看数据的潜在漏洞仍然需要适当的密钥来解密数据。开发人员需要确保必须克服不同的机制来访问密钥，而不仅仅是访问加密内存。

　　硬件安全协助 – 现代处理器的许多功能有助于确保设备和应用程序的安全性，但系统设计人员有责任利用它们。诸如TrustZone，加密加速，可信平台模块（TPM）等功能位于现代微处理器上，旨在加速和协助安全设计的开发。但是，如果您不使用这些功能，则仅在硬件中拥有这些功能是无用的。

　　保护未来的设备

　　一旦您的产品发布，您的工作就没有完成，因为已知漏洞的数量是一个不断变化的目标，每天都在增加。2019 年，创建了 12，174 个 CVE，每天超过 30 个。其中大多数都不是问题，而且，在那些问题中，许多不适用于您的设备，因为许多CVE是针对旧版本的开源组件报告的，或者将针对您不使用的组件。也就是说，即使针对 Linux 内核，2019 年也发布了 170 个 CVE，其中一些会导致针对您的设备的潜在漏洞利用。

　　虽然没有办法防止这种情况发生，但您需要知道它会发生，并且您需要确保您的设备已准备就绪。为将来准备设备的时间是在开发期间，以便您可以准备设备，以便在发现并修复新的漏洞（和重大产品缺陷）时进行更新。监管机构在这个问题上采取了比过去强硬得多的立场，并要求将管理计划作为设备上市后计划的一部分（在美国，如医疗器械网络安全上市后管理指南中所述）。

　　需要管理的不仅仅是 CVE;例如，在2016年，一个通常被称为Mirai僵尸网络的漏洞通过接管网络摄像头和路由器等小型物联网设备，并使用它们对美国和法国的Web基础设施提供商执行分布式拒绝服务攻击（DDoS攻击），从而破坏了大部分互联网。这些受感染设备的大多数所有者都不知道他们的系统已被感染，而Mirai（及其衍生产品）今天仍然是一个威胁。甚至今天制造的设备也容易受到它的影响，即使根本原因很简单，就像尝试访问具有 64 个众所周知的默认登录名/密码（例如用户/用户或用户/密码）的根级访问帐户一样简单。由于这些设备的大多数用户不知道或无法更改这些简单的默认值，因此Mirai僵尸网络能够控制这些系统。

　　在开发过程中应考虑许多因素，以使设备面向未来，但最重要的是能够安全地更新系统。支持此方法的方法和设施很多且复杂，超出了本文的范围。有关详细信息（请参阅本文末尾），提供了涉及此重要主题的资源。

　　应用预防性开发技术

　　如果您使用 Linux 和其他开源软件作为产品设计的一部分，那么当您发布设备时，您的设备中将存在您（或其他任何人）知道的漏洞。因此，您不仅希望在发布时消除尽可能多的已知漏洞，而且还必须假设，在某些时候，某些不良行为者将能够未经授权访问设备。发生这种情况时，您希望使他们尽可能难以利用该访问权限获利。对于掌握设备漏洞知识的坚定黑客来说，没有完美的防御措施，但您希望让他们尽可能困难地做到这一点。您无法保护自己免受正在使用的开源模块中的缺陷的影响，但您可以控制自己的应用程序中的潜在缺陷。当然，您应该考虑上述技术来设计更好的保护，但是您的应用程序的开发方式呢？

　　如上所述，开源和应用软件中的大多数漏洞都是由于反复发生的开发缺陷造成的。诸如 NULL 指针取消引用、释放已释放的内存、溢出固定长度缓冲区等都是黑客很容易利用的编码错误来破坏您的设备。但是，有几种方法可以用来提供帮助。具体技术超出了本文的范围，但可以从以下地方开始寻找：

　　静态（和动态）分析。您可能会看到的第一个静态分析是来自编译器的警告。令人惊讶的是，有多少组织在错误地急于发布某些东西时忽略了这个有价值的诊断工具。除此之外，开源社区提供了几个有用的静态分析工具，如cppcheck和clang，并且有许多商业解决方案可用。所有这些都将检测代码审查中容易遗漏的问题，并且只要管理这些工具的报告，您就可以防止应用程序中的几个主要类别的潜在漏洞利用。

　　使用编码标准。通常，MISRA 编码标准 是这些标准的金牌标准，并为保护您的应用程序提供了许多经过深思熟虑的建议。虽然它的起源来自汽车行业和安全领域，但它没有任何特定于汽车（或安全）的内容，任何希望保护其应用的设备制造商都应该考虑MISRA。请注意，大多数静态分析工具也大大简化了应用程序与MISRA规则的检查。虽然还有其他可用的编码标准，但MISRA将常识与良好实践相结合，可以由各种规模的组织实施。

　　另一个有用的编码标准来自卡内基梅隆大学软件工程学院;已知 SEI 证书 C。这和MISRA之间有很大的重叠，但SEI标准超越了C和C++，延伸到Android，Java和Perl。

　　在开发安全软件时，还有许多其他有用的信息来源需要考虑，但是如果您尚未使用上述技术，请从那里开始，并在拥有智能编码标准和静态分析范式后考虑扩展您的思维。

　　结论

　　在本文的开头，我们讨论了医疗设备中连接的激增，以及这种连接给我们的生活带来的好处和安全风险。我们还讨论了美国FDA等监管机构对这些设备内置和维护安全性的日益严格的审查。此外，我们还讨论了如何在医疗设备的设计、开发和维护中克服这些挑战。按照本文中的指导，您的产品将：

　　更难成功利用

　　在发布时防止已知和未知的攻击

　　更新速度更快，以关闭任何新发现的漏洞

　　更安全，让您的客户确信即使出现问题，他们也受到保护。

　　最后一点特别重要。客户知道，没有设备是完全没有错误的。他们想知道的是，您如何最大限度地减少缺陷及其影响，以及在不可避免地出现问题时做好的准备情况。本文中的方法不会阻止所有潜在的未来安全问题，但它们将使您处于有利地位，以便在这些问题出现时快速解决这些问题。

　　通过接近安全性并限制被利用的风险，您的设备将不易受到攻击，更好地准备保护患者数据，并且更有可能顺利获得监管批准并改善全球患者的医疗结果。

　　审核编辑：郭婷