UL2900-2-1标准中文版-2018卫生保健系统网络可连接部件的特定要求

参考中文标准软件可联网产品的网络安全，第2-1部分：医疗保健系统的网络可连接组件的特殊要求2018年6月1ANSI/CAN/UL3内容前言4介绍2规范性引用文件4C3词汇表4D4产品文档4D5流程文档4D6产品使用4D文档6.2说明58访问控制，用户身份验证和用户授权59远程通讯510密码学511产品管理7产品评估12与安全相关的安全风险管理712.2风险评估812.3风险控制812.4安全分析和测试的范围913已知漏洞测试1214恶意软件测试1215格式错误的输入测试1216结构化渗透测试1317软件弱点分析1418静态源代码分析1419静态二进制和字节码分析1420生命周期安全流程1420.1质量管理流程1420.2一般采购流程1420.3采购风险管理流程1520.4产品更新发行和补丁管理过程1520.5退役过程1520.6包装和运输164ANSI/CAN/UL2018年6月1这是ANSI/CAN/UL2900-2-1(可联网产品的软件网络安全标准)的第一版，第2-1部分：医疗保健系统的网络可连接组件的特殊要求。UL获得了美国国家标准协会(ANSI)和加拿大标准委员会(SCC)的认可，成为标准制定组织(SDO)。此ANSI/CAN/UL2900-2-1安全标准正在持续维护中，其中每个修订版本在发布时均经过ANSI/CAN认可。如果未进行修订，则本标准的审查将在发布之日起5年内开始。在加拿大，有两种官方语言，英语和法语。所有安全警告必须使用法语和英语。请注意，某些加拿大当局可能会要求使用两种官方语言的附加标志和/或安装说明。本标准仅使用公制SI度量单位。如果要在测量值后面加上括号中其他单位的值，则第二个值可能是近似值。第一个规定的值是要求。有关标准任何部分的修订意见或建议可随时提交给UL。提案应通过位于上的UL在线协作标准制定系统(CSDS)中的提案请求提交。UL的安全标准受UL版权保护。本标准的印刷版或电子版均不得以任何方式更改。UL的所有标准以及与这些标准有关的所有版权，所有权和权利仍将是UL的唯一专有财产。要购买UL标准，请访问Comm2000,网址为/help/how_to_order.aspx或致电该版本的标准已由UL标准技术小组(STP)于2900,可联网产品的软件网络安全STP2900正式批准。当该标准的最后文本被选票时，该列表代表STP2900成员资格。从那时起，成员资格可能已发生更改。2018年6月1ANSI/CAN/UL4A美国日本三菱电机美国国家标准技术研究所美国美国戴维斯(Valara)保险商实验室有限公司美国美国费舍尔，约瑟夫美国菲茨杰拉德(BrianFitzgerald)美国商业/工业用户马萨诸塞州综合医院/合商业/工业用户美国保险商实验室有限公司美国欧司朗美国快速响应监视有限公司商业/工业用户美国Jarzombek,乔美国卑诗省安全局日本美国美国美国国际原子能机构奥地利美国美国国家安全局美国美国美国瑞士ABB有限公司*在撰写本文时，"测试与标准"利益类别未投票给SCC。4BANSI/CAN/UL2018年6月1本标准旨在用于合格评定。该标准的预期主要应用在其范围内说明。重要的是要注意，判断标准对于此特定应用的适用性仍然是标准使用者的责任。CETTENORME2018年6月1ANSI/CAN/UL4C2规范性引用2.3医疗设备标准-质量管理体系-法规目的要求，ISO13485:2003,应按照本标准的规定使用。4DANSI/CAN/UL3词汇表3.1基本安全-避免与产品预期用途没有直接关系的风险。3.2基本性能-与基本安全有关的性能，其损失或降级超出制造商规定的极限会导致不可接受的风险。3.3制造商-请参阅供应商3.4风险管理文件-风险管理产生的一组记录和其他文件[ENISO14971:2012]4产品资料4.1产品文档应符合可联网产品软件网络安全标准的要求：第1部5工艺文件6产品使用文件2018年6月1ANSI/CAN/UL56.1.2产品预期使用的环境应列举出产品在预期操作产品的使用说明声明应标识与打算在其内使用的环境有关的假设方面的安全功能和限制。6.2说明6.2.1有关为确保患者安全而在必要时超越安全措施的方法的说明和必须按照风险管理文件中所述，通过安全控制传达给预定的安全控制7.1产品应符合网络可连接设备软件网络安全标准的要求：第1部分：一般要求，UL2900-1,第7节，除8访问控制，用户身份验证和用户授权8.1产品应符合网络可连接设备软件网络安全标准的要求：第1部分：通用要求，UL2900-1,第8节，除9远程通讯9.1产品应符合可联网设备软件网络安全标准的远程通信要求：第1部分：一般要求，UL2900-1,第9节，除非以下条款另有规定。10密码学10.1产品应符合可联网设备软件网络安全标准的加密要求：第1部分：一般要求，UL2900-1,第10节，除非以下条款另有规定。2017年9月1日UL2900-2-711产品管理11.1产品应符合可联网设备软件网络安全标准第1部分中的产品管理要求：一般要求，UL2900-1,第11节，除非以下条款另有说明。产品评估12安全相关的安全风险管理12.1风险分析12.1.1产品应符合《医疗设备标准-医疗设备风险管理的应用》ISO14971或适用于网络连接产品的软件网络安全标准第1部分的适用要求：一般要求，UL2900-1,第12节，供应商产品风险注意：根据结合医疗设备的IT网络风险管理应用标准的信息技术网络风险-第1部分：角色，职责和活动，IEC80001-1,应被视为产品风险管理的一部分。12.1.2风险管理文件应根据医疗器械标准构建-风险管理在医疗设备中的应用，ISO14971,风险管理过程，并且应特别包括以下有关安全性的要素：a)安全风险分析；注意：安全风险分析应考虑深度防御，也称为保护层分析(LOPA)1。b)安全风险评估：c)安全风险控制；注意：安全风险控制措施应考虑深度防御策略，以最大程度地减少破坏的影响。d)生产和生产后的安全信息：e)验证和确认安全风险控制；和注意：验证演示了满足系统要求的实现。f)剩余安全风险的可接受性分析。1请参见IEC61511,《过程工业领域的功能安全性-安全仪表系统》。a)为产品开发分配足够的安全资源；注意：符合性可以通过证明符合本标准第13-20条来确定b)根据适用的国际，国家或地区法规建立产品安全风险可接受性的政策和标准：和c)正在按计划的时间间隔对安全风险管理流程的持续适用性进行重新评估，包括记录决策和采取12.2.1应根据可联网产品的软件网络安全标准第1部分中的12.3和12.4进行风险评估：一般要求，UL12.3.1网络可连接产品软件网络安全标准的第7-11节中确定的风险控制措施：通用要求，UL2900-1和包含医疗设备的IT网络的风险管理应用程序的安全功能-第2-2部分：对于风险管理，应考虑《医疗器械安全需求，风险和控制的披露和交流指南》IEC12.3.2风险分析中有禁忌的任何安全措施应在“风险管理文件”或替代措施的说明中指定为“不适用”12.3.3应当建立安全风险管理计划并形成文件，以反映以下过程，包括所使用的任何定性或定量措施的理a)识别资产，威胁和漏洞；b)评估威胁和漏洞对设备功能和最终用户/患者的影响；c)评估威胁和被利用漏洞的可能性；d)确定风险水平和适当的缓解策略；和e)评估剩余风险和风险接受标准。f)适用时与安全性相关的数据记录12.3.4供应商应提供风险管理工件，以反映与产品相关的有意和无意网络安全风险相关的危害分析，缓解a)产品设计中考虑的所有网络安全风险的详细列表；b)针对该产品建立的所有网络安全风险控制的特定列表和理由：2017年9月1日UL2900-2-9c)一种证明可追溯性的方法，该方法将产品网络安全风险控制与所考虑的网络安全风险相关d)摘要描述了计划，以在产品的整个生命周期中根据需要提供经过验证的软件更新和补丁，以继e)摘要，描述了为确保产品软件从源头到产品脱离供应商控制而维持其完整性(例如，保持无恶意软件)的网络安全风险控制措施；和f)与适用于预期使用环境的建议网络安全风险控制相关的产品使用说明和产品规格(例如，防病毒软件，防火墙的使用)。12.3.5组织应在风险管理文件或风险管理文件引用的单独文件中标识产品的所有与安全相关的安全和与安全无关的要求(另请参见,和))。12.3.6安全风险控制应基于风险评估得出的要求。12.3.7安全风险控制措施应源自相关的产品要求，包括客户未说明的要求，但对于产品在预期使用期间的安全性和安全性而言是必需的。12.4安全分析和测试的范围12.4.1输入保护如果适用，应规定保护产品输入的安全措施(例如，输入数据的加密)。应指定从产品输入中得出的风险控制的任何特定输入(例如，安全联锁的阈值)。必须为输入指定数据安全性(例如，经过身份验证的加密)。应为输入规定与中相当的元数据安全性(例如，患者识别信息)。必须规定安全措施，以保护任何公开的输入数据(例如，无线传输的数据，而不是在HMI本地安全输入的数据)的上下文含义的机密性。注意：这种措施的一个例子是对患者可识别数据的取消识别。应规定保护资产免受在产品状态更改期间通过输入操纵而利用的过渡漏洞的安全措施(例如，超出范围的值的异常处理，请参阅SANS排名前25)。注意：应该考虑状态机更改的触发器。应规定为患者安全所必需的安全措施，以超越输入的安全措施(例如，“破玻璃”)。在产品开发过程中应规定与产品输入有关的所有与安全性有关的假设和约束。12.4.2保护输出应规定保护产品输出的安全措必须为输出指定数据安全性(例如加密)。应为输出规定元数据安全性。必须规定安全措施，以保护任何公开的输出数据(例如，无线传输的数据)的上下文含义的机密性，完整性和可用性。注意：这种措施的一个例子是对患者可识别数据的取消识别。在产品状态改变期间，应规定保护资产免受通过输出操纵(例如伪造的安全证书)所利用的过渡漏洞的安全措施。应规定为患者安全所必需的安全措施，以超越输出安全措施(例如，“破玻璃”)。在产品开发过程中应规定与产品输出有关的所有与安全性有关的假设和约束。12.4.3与设计和开发过程相关的风险控制注意：合格性应通过检查风险管理文件来确定。安全控制措施应在设计和开发过程中按照风险评估的要求实施，其中以下各节构成了要考虑的最低限度的设计和开发过程安全控制措施，并且未使用风险管理中提出的任何考虑因素文件。在设计过程中，应根据安全风险评估对“随机”种子进行适当性评估，并记录在风险管理文件中。应仅授予软件过程及其授权用户执行其特定功能所需的特权。参见UL2900-1,第8.8条。除非产品风险评估有禁忌之意，否则所有输入均应在处理之前经过验证。2017年9月1日UL2900-2-11如果此类约束不会带来新的危害，则应确定性地限制程序(即使用受控制的编程结构)以避免漏a)缓冲区溢出；b)使用未定义或未初始化的编程结构(例如，空指针取消引用);c)使用非托管资源(例如免费使用);d)使用未初始化的内存：和e)资源管理功能使用不当(例如非法释放已释放的指针或不正确使用缓冲数据)。f)将异常处理技术与全部实现结合使用，允许在调用堆栈中出现异常而不影响设备的核心功能(如果可能的话),或者在受到异常影响的情况下使用已记录的回退功能。在风险评估中应考虑使用内存安全语言。在风险评估中应考虑使用语言子集。在风险评估期间，应考虑使用自动内存安全错误缓解措施和编译器强制执行的缓冲区溢出消除措在风险评估期间应考虑使用安全编码标准。0在风险评估期间应考虑使用自动线程安全分析。1在风险评估期间，应考虑使用经过验证的密码算法和实现。2在风险评估和测试计划期间，应考虑使用经过修改的条件决策范围进行功能测试。3应根据对操作用例的分析，删除未使用的功能/功能，如果认为有必要将其删除，则应在风险管理文件中证明存在这些未使用的功能。4应使用经过数字签名的软件和固件。5在重新初始化产品之前，应使用数字签名验证软件和固件更新。6白名单应用于身份验证和/或授权，除非这种使用会带来新的危害。注意：列入白名单的软件应遵守与适用于与其相关联的软件相同的安全要求。12UL2900-2-2018年6月18必须使用完整性监视器来监视存储(例如内存),以确保不会无意间修改了代码和数据部分。9直接保护与硬件连接的软件(包括敏感数据),应受到保护，以防止未经授权的修改或通过制造商风险管理流程规定的软件或硬件手段进行访问。0在风险评估期间，应考虑在加密协议中使用完全前向保密性。13已知漏洞测试13.1除非在卖方风险管理文件中另有说明，否则该产品不应包含任何已知漏洞，这些风险基于在卖方风险管理过程中使用的CVSS度量标准或CVSS度量标准或等效项的改编。13.2应根据可联网产品的软件网络安全标准，对产品进行已知漏洞测试：一般要求，UL2900-1,第13节。13.3应记录供应商处理来自外部第三方的与安全相关的漏洞报告的过程。14恶意软件测试14.1应根据可联网产品的软件网络安全标准，对产品进行恶意软件测试：一般要求，UL2900-1,第14节。15格式错误的输入测试15.1根据网络可连接产品的软件网络安全标准，该产品应接受格式错误的输入测试：一般要求，U15.2根据网络可连接产品的软件网络安全标准第15部分和第16部分进行畸形输入测试和结构化渗透测试后：根据UL2900-1的一般要求，产品应按其预期用途继续正常运行，或过渡到产品风险管理文件(RMF)中指定的已确定风险(RA)状态。2017年9月1日UL2900-2-1316结构化渗透测试16.1在可网络连接产品的软件网络安全标准的结构化渗透测试期间，第1部分：一般要求，UL2900-1,第16节，应在指定的测试条件下评估产品的特权提升(EoP)潜力。16.2应根据本标准至通过针对产品的输入和输出特性(即结构化渗透测试)来测试针对EoP的防护。16.3对于可能无法通过外部接口直接访问的软件过程，应评估针对EoP的防护。应使用网络可连接产品软件网络安全标准第16部分第16节中指定的结构化渗透测试方法，通过对16.4至16.12的评估来确定这一点：16.4必须测试保护产品内部安全关键软件流程(例如逻辑和状态转换)的安全措施(即用于软件到软件的接口)。16.5受产品内其他软件过程的输出影响的产品内任何与安全相关的软件过程均应进行测试。16.6应对数据安全性(例如加密)进行测试，以评估产品中可能与产品中其他不安全的软件过程交互的软件过程(例如多核处理)。16.7作为16.6的替代方法，可以将此类交互视为中对安全过程的输入。16.8应测试元数据安全性以评估产品中可能与产品中其他不安全的软件过程交互的软件过程(例如，多核处理)。16.9应测试用于保护任何公开输入数据(例如在安全和不安全核心之间共享)的上下文含义的机密性的安全措施，以评估产品中可能与产品中其他不安全软件过程交互的软件过程(例如多核处理)。注意：这种措施的一个例子是对患者可识别数据的取消识别。16.10在产品状态更改期间，应测试用于保护资产免受通过软件过程操纵而利用的过渡漏洞的安全措施。16.11为了患者安全，必须测试在产品内部超越软件过程安全措施的措施。16.12在对可联网产品的软件网络安全标准的第13部分进行结构化渗透测试后，第1部分：根据UL2900-1的一般要求，产品应按其预期用途继续正常运行，或过渡到产品风险管理文件(RMF)中规定的已定义风险已解决(RA)状态且无EoP。17软件弱点分析18静态源代码分析19静态二进制和字节码分析20生命周期安全流程20.1质量管理流程20.1.1产品应根据医疗器械标准-质量管理20.2一般采购流程20.2.2对于要集成到产品中的组件，供应商(即产品开发人员)应建立成文的采购程序，其中应包括对供20.2.3卖方(即产品开发人员)应计划供应商的选择，建立选择，评估和重新评估的标准，并根据供应商20.2.4供应