控制系统安全漏洞信息发布制度

2023年某石化厂DCS系统被曝出远程代码执行漏洞，控制厂商补丁还没写完，系统信息攻击指纹已经在暗网挂出两个报价档位。安全这事最荒诞的漏洞地方在于：一线运维人员比厂商工程师更早从安全社区获知细节，而他们手里根本没有修复权限。发布信息在错误的制度人手里流转，该知道的控制人反而被蒙在鼓里。

控制系统漏洞跟普通IT漏洞完全不是系统信息一回事。PLC、安全RTU、漏洞SCADA这些设备的发布设计寿命动辄十五年起步，跑的制度是Windows XP Embedded甚至DOS变体。你让一个化工厂把反应釜控制器停机打补丁？控制停产损失按分钟算。所以漏洞信息一旦公开，系统信息等于把手术刀递给所有人——包括那些根本不该进手术室的安全人。

现在通行的做法是“负责任披露”：发现者先报给CISA或厂商，等补丁出来再公开。听着挺合理。但实际执行中，厂商拖六个月不回复的案例一抓一把。某德国自动化巨头曾被曝出十七个漏洞，从首次报告到发布补丁用了四百多天。这期间发现者守口如瓶，攻击者却可能早已通过其他渠道拿到利用代码。守规矩的人吃亏，不守规矩的人通吃。

更麻烦的是漏洞信息的“分层需求”。设备厂商需要完整技术细节来开发补丁；终端用户需要知道“我到底有没有暴露”；监管机构需要评估关键基础设施风险；而安全研究员需要足够信息来验证漏洞真实性。这四类人需要的颗粒度完全不同，现在却往往被塞进同一份公告里。结果要么是厂商嫌披露太多，要么是用户看了等于没看。

我见过一份漏洞公告，技术描述精确到寄存器偏移量，却只字未提哪些型号受影响。运维人员拿着公告对了一圈设备铭牌，发现型号对不上——因为厂商用的是内部产品线编号。这种公告发了等于没发，还白白给了攻击者一份利用说明书。

分级发布机制不是没人提。美国ICS-CERT试过“先发摘要、后发细节”的两阶段模式，但执行时被厂商法务部门卡住，理由是“细节可能被竞争对手利用”。这理由站不住脚——竞争对手要逆向你的固件，不差这一份公告。真正被挡在门外的是那些需要自己写临时缓解措施的中小企业用户。

欧洲那边搞过“漏洞信息共享与分析中心”（ISAC），让同行业用户先于公众拿到预警。效果还行，但覆盖面有限。化工、电力、水务各自为政，跨行业攻击链根本预警不了。某次攻击者先拿下水务系统的漏洞当跳板，再横向移动到同一园区的电力控制网。水务ISAC发了预警，电力ISAC没发，因为漏洞不在他们清单上。

说到底，漏洞信息发布制度的核心矛盾是：安全需要透明，但控制系统的物理特性决定了透明有代价。一个能远程重启反应釜的漏洞，跟一个能远程重启打印机的漏洞，信息发布策略不该一样。现在的问题是，制度设计者往往用IT安全的模板套工控场景，结果就是要么过度保密导致用户裸奔，要么过度公开导致攻击门槛骤降。

我的判断很简单：漏洞信息应该按“利用后果”分级，而不是按“技术类型”分级。能导致物理破坏的漏洞，细节延迟公开，但受影响资产清单必须同步给所有可能受影响的运营方。能导致数据泄露但不影响物理过程的，按常规IT漏洞处理。这个分级标准需要写进制度，而不是留给厂商和发现者私下博弈。

否则下次再出个震网级别的漏洞，我们还是会看到同样的剧本：发现者纠结、厂商拖延、用户茫然、攻击者从容。信息在链条上流动，唯独绕过了最需要它的人。