4. 医疗器械网络安全需求工程

网络安全需求工程不是把通用安全条款抄进文档，而是把“器械在真实临床环境中如何被使用、与谁交换数据、可能被谁以何种方式影响”转化为可设计、可实现、可测试、可追溯的工程约束。它的起点是临床使用场景与预期用途，终点是安全需求规格说明（SyRS/SRS 中的安全条目）以及一张能把需求、风险、设计、测试串起来的可追溯性矩阵。中间必须经过接口清单这一关键桥梁，因为绝大多数医疗器械网络安全事件都发生在接口与数据流上。

一、从预期用途与临床使用场景提取安全相关上下文

预期用途描述器械“治什么、给谁用、在什么环境用”，而临床使用场景则把它展开为具体的人、地点、时间、网络与操作序列。需求工程要做的第一件事，是把场景中与安全相关的要素显式化。建议围绕五个维度提问：

• 使用者与角色：临床医生、护士、患者、工程师、管理员、第三方维护人员，各自能做什么、通过什么界面进入。
• 运行环境：院内 VLAN、无线 Wi-Fi、家庭网络、隔离网段、云平台，是否存在共享网络与不可信链路。
• 数据对象：患者标识、波形、影像、剂量参数、报警阈值、治疗计划、日志、固件。
• 交互时机：术中实时控制、术后回顾、远程会诊、自动上报、夜间批量同步。
• 失效后果：数据泄露、参数被篡改、治疗中断、报警抑制、设备被远程操控。

例如，一台联网输液泵的预期用途是“由护士在病房内设置并执行输液方案，通过院内 Wi-Fi 将输注记录上传至护理系统”。由此可导出安全上下文：护士站与泵之间是无线链路，上传数据含患者标识与药物剂量，若剂量参数被篡改将直接造成过量输注。这类上下文不是需求，但它是需求的来源与验收依据。

二、接口清单：把“连接”变成可审计的资产

接口清单是需求工程中最容易被低估、却最影响后续测试覆盖的工件。它不应只写“支持以太网”，而应逐条记录接口的物理形态、协议、方向、数据内容、认证方式、开放端口、默认状态与生命周期。一个可用的接口清单至少包含以下字段：

接口清单一旦形成，就能反向检查场景：术中实时控制走 IF-02，若该链路被降级为开放网络，则控制指令的完整性与新鲜性必须成为安全需求；固件升级走 IF-03，则签名验证与回滚保护必须成为安全需求。接口清单因此是“场景→需求”的转换器。

三、安全需求规格说明的写法

安全需求应可验证、可分配、可追溯。推荐采用“主体—动作—对象—条件—约束”的句式，并绑定唯一编号。例如：

SEC-001：输液泵在接收 IF-02 控制指令前，必须验证指令来源设备的双向证书，
         且指令时间戳与本地时钟偏差不超过 5 秒，否则拒绝执行并记录审计日志。
SEC-002：IF-03 固件升级包必须使用厂商私钥签名，设备使用内置公钥验证；
         验证失败时不得写入 Flash，并保持当前固件可运行。
SEC-003：IF-04 调试串口在出厂配置中必须处于禁用状态，
         仅能通过物理维护开关在设备断电重启后 10 分钟内临时启用。

每条需求都应能回答：它来自哪个场景、对应哪个接口、缓解哪条风险、由哪个设计模块实现、由哪个测试用例验证。缺少这五问中的任何一问，需求就可能在评审中被退回。

四、可追溯性矩阵：让需求不悬空

可追溯性矩阵（RTM）把“场景—风险—需求—设计—测试”连成一条链。它的价值不在于表格好看，而在于任何一条需求都能向下找到实现与验证，任何一次变更都能向上找到影响范围。下面给出一个简化示例：

在实际项目中，RTM 通常以电子表格或需求管理工具维护，并设置“覆盖状态”列：未实现、已实现未测试、已测试通过、已测试失败。评审时优先看“未实现”和“已测试失败”两类，它们直接对应剩余风险。

五、从需求到验证的闭环

需求工程不是写完文档就结束。它要求在设计阶段把需求分配到具体模块，在测试阶段用可复现的用例验证，在变更阶段评估影响。一个常见的闭环做法是：每次接口变更或场景新增，先更新接口清单，再检查是否触发新风险，然后新增或修改安全需求，最后同步更新 RTM 与测试用例。这样，网络安全需求才真正成为工程活动的一部分，而不是一份束之高阁的合规文件。