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

2023年某石化厂DCS系统被曝出零日漏洞，控制攻击者能直接改写反应釜温度参数。系统信息信息厂方花了三天才从第三方安全公司拿到漏洞细节——因为没有任何制度规定漏洞信息该何时公开、安全向谁公开、漏洞公开到什么程度。发布这三天里，制度生产线一直开着。控制

漏洞信息发布制度，系统信息信息说白了就是安全给“漏洞情报”定规矩：谁发现、谁验证、漏洞谁发布、发布谁响应。制度但现实里，控制这条链条常常卡在“发布”这一环。系统信息信息厂商怕担责，安全捂着不报；研究机构怕惹官司，只发模糊描述；用户单位更是一头雾水，只能靠运气躲雷。

我见过最荒唐的例子，某工控安全公司发现某品牌PLC存在硬编码密码漏洞，按流程通知了厂商。结果厂商回复：“请先签保密协议，我们法务要审核你报告里的技术细节。”这一审就是四个月，期间至少有十几个使用该PLC的水处理厂暴露在风险中。漏洞信息不是商品，不该被商业流程拖死。

制度设计上，核心要解决两个问题：时限和分级。

时限很简单——发现漏洞后，验证时间不超过7天，通知相关CERT（计算机应急响应团队）不超过24小时，公开披露不超过90天。别拿“需要更多时间修复”当借口，90天修不完的补丁，再给90天也修不完。还不如先公开漏洞特征和临时缓解措施，让用户自己想办法。

分级则要区分场景。涉及关键基础设施（电网、水厂、核设施）的漏洞，必须第一时间上报国家主管部门，哪怕漏洞还没完全验证。普通工业设备漏洞，可以走常规披露流程。最忌讳一刀切——所有漏洞都按“最高机密”处理，结果就是谁都不知道，等于没发现。

发布渠道也得明确。不能只发在厂商官网某个角落，或者塞进安全公司的季度报告里。要有固定邮件列表、微信公众号、行业预警平台三线并行。用户单位得能主动订阅，而不是被动等通知。我认识一个电厂的信息主管，他每天上班第一件事就是刷五个安全网站——这不该是常态。

还有个细节容易被忽略：漏洞信息发布时的“技术细节脱敏”问题。公开POC（概念验证代码）会降低攻击门槛，但不公开，用户又没法自测是否受影响。折中方案是：公开漏洞类型、影响范围、检测方法，但不公开完整利用代码。可有些“安全研究员”为了出名，偏要发完整攻击链视频——这种就该在制度里立下规矩，违规者拉黑名单。

制度执行需要监督。建议由第三方机构（比如中国信息安全测评中心）负责抽查漏洞披露时效，每季度公布一次“拖延名单”。别怕得罪厂商，真要出了安全事故，责任比面子重要得多。

说到底，漏洞信息发布不是学术论文评审，不用等“同行评议”通过。它更像天气预报——哪怕预报不准，也比不预报强。早一天公开，用户就能早一天打补丁或采取防护措施。晚一天，可能就是一次爆炸、一次停产、一次数据泄露。

回到开头那个石化厂。后来查明了，那个漏洞其实早在半年前就被国外安全团队发现并通知了厂商，但厂商觉得“影响范围有限”就没公开。半年时间，足够攻击者把厂区网络翻个底朝天。要是当时有强制发布制度，哪怕只是提前一个月公开，厂方也能来得及加固边界防火墙。

制度不是万能的，但没有制度，漏洞信息就会烂在少数人手里，变成黑市上的商品。这道理，做安全的都懂，但真正敢拍板公开的人，太少了。