3. 资产识别信息模型与属性设计

资产识别不是把设备名称抄进表格,而是为每一台工控资产建立一份可被机器和人共同理解的“身份档案”。这份档案的结构就是资产信息模型:它规定了要采集哪些属性、每个属性表达什么含义、用什么格式存储、由谁维护、在什么场景下使用。模型设计得好,后续的漏洞匹配、通信关系分析、风险评估和应急处置都能直接复用;模型设计得差,采集到的数据彼此孤立,评估时还要反复补录,资产库很快会变成一堆无法信任的文本。

一、核心属性分层

工控资产属性可以按“身份—技术—位置—业务—管理”五个层次组织。身份层解决“这是谁”,技术层解决“它是什么、怎么通信”,位置层解决“它在哪”,业务层解决“它有多重要”,管理层解决“谁对它负责”。五层属性共同构成一条完整记录,缺任何一层都会让资产在后续分析中失去上下文。

资产唯一标识是整条记录的主键,必须全局唯一且终身不变。推荐采用“站点代码-区域代码-设备类型-顺序号”的可读编码,例如 SH-A1-PLC-007,同时保留一个由系统生成的 UUID 作为内部主键。可读编码便于现场人员口头沟通和标签打印,UUID 保证即使设备迁移、改名也不会与历史记录冲突。唯一标识一旦分配,即使设备报废也应保留记录并标记状态,避免标识被复用导致历史数据错乱。

厂商、型号与固件版本是漏洞匹配的关键字段。厂商名称应使用规范全称而非简称,型号要精确到具体订货号,例如西门子 6ES7 315-2AG10-0AB0 而不是笼统的“S7-300”。固件版本要记录到可比较的版本号,如 V2.8.1,并注明采集方式(设备面板读取、组态软件读取或协议探测)。这三个字段组合起来,才能与工控漏洞库中的受影响产品范围做匹配。

通信协议属性不能只写一个协议名。一台 PLC 可能同时通过 S7 协议与上位机通信、通过 Modbus TCP 与第三方仪表通信、通过 OPC UA 对外提供数据。因此协议应作为可重复的子属性,记录协议类型、端口、角色(服务端/客户端)、是否加密、是否允许跨区访问。这些信息直接决定网络访问控制策略和异常流量检测规则。

网络位置要同时记录逻辑位置和物理位置。逻辑位置包括 IP 地址、MAC 地址、VLAN、所属安全区域(如控制区、监控区、管理区);物理位置包括厂区、车间、机柜编号、机架槽位。对于串口设备,还要记录串口服务器端口和映射关系。网络位置是判断“谁可以和谁通信”的基础,也是事故时快速定位物理设备的依据。

业务重要性不能简单写“高/中/低”,而应给出可解释的评分依据。常用做法是从可用性、完整性、机密性三个维度分别打分,再结合停机影响、安全影响、环境影响加权。例如一台反应釜温度控制器,可用性要求极高、停机可能引发安全事故,其业务重要性应显著高于办公区打印服务器。评分结果要能追溯到具体理由,而不是凭感觉填写。

责任人属性应区分业务责任人、技术责任人和运维责任人。业务责任人通常是工艺或生产主管,对资产承载的业务负责;技术责任人负责设备选型、配置和变更审批;运维责任人负责日常巡检、备份和故障处理。三类责任人都要记录姓名、部门、联系方式和备份人员,避免单点依赖。

二、属性模型的结构关系

下面用一张结构图表达各属性层之间的组织关系。图中以资产唯一标识为中心,五个属性层围绕它展开,每层列出本节讨论的核心字段,并标注哪些字段参与漏洞匹配、访问控制或风险评估。

工控资产信息模型:五层属性围绕唯一标识组织 资产唯一标识 SH-A1-PLC-007 / UUID 身份层 • 资产名称 / 别名 • 设备类型(PLC/RTU/HMI) • 资产标签条码 技术层 • 厂商 / 型号 / 订货号 • 固件版本 / 硬件版本 • 通信协议 / 端口 / 角色 位置层 • IP / MAC / VLAN • 安全区域(控制/监控) • 厂区 / 机柜 / 槽位 业务层 • 业务重要性评分 • 可用性/完整性/机密性 • 停机影响 / 安全影响 管理层 业务/技术/运维责任人 · 联系方式 厂商+型号+固件 → 漏洞匹配 协议+网络位置 → 访问控制与流量检测 业务重要性 + 责任人 → 风险评估与应急响应

三、属性采集与维护的实际做法

模型确定后,采集要分“存量”和“增量”两条线。存量资产通常缺少完整记录,建议按区域分批推进:先通过被动流量镜像识别在线设备及其协议,再用主动扫描补充 IP、MAC、开放端口,最后到现场核对铭牌、固件版本和物理位置。被动识别不会给生产网络带来额外负载,适合作为第一步;主动扫描要避开生产高峰,并提前确认不会导致老旧设备通信异常。

增量资产则应在采购、安装、调试、变更四个节点强制录入。采购时录入厂商、型号、订货号;安装时录入唯一标识、网络位置、责任人;调试时录入固件版本、通信协议和端口;变更时更新版本、协议或位置并保留变更记录。每个节点由不同角色负责,避免所有字段都压给一个人。

属性维护中最容易出问题的是固件版本和网络位置。固件升级后如果不同步更新,漏洞匹配会持续误报或漏报;设备迁移后如果 IP 和区域不更新,访问控制策略就会失效。建议把这两个字段设为“变更触发更新”字段,任何升级或迁移工单都必须附带资产记录更新项,并在月度巡检中抽查一致性。

示例:一台 PLC 的完整属性记录
  • 唯一标识:SH-A1-PLC-007(UUID:a3f1-…-9c2e)
  • 身份:1号反应釜主控 PLC,设备类型 PLC
  • 技术:西门子,6ES7 315-2AG10-0AB0,固件 V2.8.1,协议 S7comm(端口102,服务端)、Modbus TCP(端口502,服务端)
  • 位置:IP 10.20.1.17,MAC 00-1B-1B-…,VLAN 120,控制区,A车间1号机柜3号槽位
  • 业务:可用性5、完整性4、机密性2,停机影响高,安全影响中,综合重要性 高
  • 管理:业务责任人 张工(生产部),技术责任人 李工(自动化部),运维责任人 王工(运维组)

四、模型落地时的常见偏差

第一类偏差是把唯一标识做成“可改的名称”。一旦设备改名就换标识,历史漏洞、告警和工单全部断链。正确做法是标识不变,名称作为可修改的显示字段。第二类偏差是协议字段只填一个值,导致多协议设备在访问控制分析中被漏掉。第三类偏差是业务重要性只填等级不填依据,评估时无法复核,也无法向管理层解释为什么某台设备被列为重点保护对象。第四类偏差是责任人只写一个人,人员离职后资产无人认领。第五类偏差是只采集不校验,IP 重复、固件版本格式混乱、区域名称不统一,最终使资产库无法用于自动化分析。

要避免这些偏差,可以在录入环节加入基本校验规则:唯一标识符合编码规范且不重复;IP 地址在所属网段内且不冲突;固件版本符合“V主版本.次版本.修订号”格式;业务重要性必须同时填写三个维度分值;每类责任人至少填写主备两人。校验规则不需要复杂系统,一张带数据验证的表格就能挡住大部分低级错误。

资产信息模型的价值不在于字段多,而在于每个字段都有明确用途、明确来源和明确维护责任。当唯一标识稳定、技术属性可匹配漏洞、位置属性可支撑访问控制、业务属性可支撑风险排序、管理属性可支撑应急联络时,资产库才真正成为工控安全工作的基础数据,而不是一份静态清单。