H.D. Moore：OT 资产发现、漏洞洪流与 AI 安全恐慌

一台温控器背后，可能是一整条楼宇控制网络

Moore 说，RunZero 起步时面对的是一个常被忽略的假设：企业以为联网设备都已纳入管理，未纳管的设备仿佛不存在。但安全团队不知道其存在、也无法部署终端代理的设备，往往正是反复出问题的入口。工业控制网络中的 PLC、工业路由器和其他 OT 设备大多属于这一类；即使做被动发现，也只能看到镜像端口或抓包点覆盖到的流量，未必知道网络里还有什么。

这种盲区并不限于工厂。企业楼宇里的暖通空调、门禁和建筑管理系统，常常既不被视作普通 IT，也没有明确的内部团队负责。Moore 将风险归到这种职责断层：设备连在企业网络上，实际却由物业或楼宇团队维护。Gray 提到过往零售企业因暖通控制器受入侵的案例，感慨在便利与合理的隔离架构之间，组织仍常选择前者。

暖通系统说明了为什么只按 IP 地址扫描不够。Moore 以 BACnet 为例：温控器可作为通向总线的网关，接入第一个网关后，工具可以按设备编号枚举后方控制器，再继续沿路径转发。欧洲网络中常见的 KNX 机制不同，但同样需要经由其网关进入。工业侧的 Ethernet/IP 可以在串口与 IP 之间多次串接；Moore 说，这会让远端设备变成无法直接路由到的子网的探测入口。

RunZero 曾做过一次互联网扫描。Moore 报告称，直接暴露在互联网上的相关设备约有 5,000 台，但经由这些设备还能控制的后方设备约有 110,000 台。前一层看上去可能只是温控器，下一层却包括门锁、继电器和安全系统；他以这次扫描说明，协议网关会遮蔽攻击面。

他还把这种思路延伸到企业边界。部分摄像头会默认用 UPnP 在防火墙上开孔；某些 OT 设备则通过运营商的公网 APN 接入蜂窝路由器，企业未必知道它最终使用的公网地址。Moore 说，RunZero 试图先在内部为设备建立特征，再从全网扫描数据中寻找匹配项。这样即使企业不知道自己的公网地址段，也能发现某台内部设备是否同时暴露在外部。

CVE 列表赶不上被利用的漏洞

话题从发现资产转到漏洞管理时，Moore 的判断很直接：CVE 编号常在防守者能够采取最早行动之后才出现。攻击者利用的许多问题在利用当时没有 CVE，供应商也未必已接受报告或提供补丁。Gray 认为生成式 AI 降低了寻找和试验漏洞的成本，把眼前的局面称为漏洞洪流；他担心企业即使部署漏洞扫描，也会被数量淹没。

Moore 用 OpenBMC 的披露经历说明这种时间差。他说，团队发现了一个能绕过认证并进一步提权的问题，影响使用该管理栈的设备；在向厂商通报六十多天后仍未看到补丁，几天前才公开披露。RunZero 已在较早阶段提醒客户关闭或处置相关暴露面，但下游厂商在问题可以修补前并不积极响应。Moore 当时还说，团队正推动修复约 40 个问题，其中只有两项已经公开。

因此，他不把目标设为给每个 CVE 打补丁，而是要求先回答更基础的问题：企业有哪些设备，它们接到哪里，攻击者怎样触及它们，一个节点失守后影响范围多大，以及所用供应商和组件分别是什么。新漏洞出现时，这些信息决定团队能否迅速定位受影响系统；漏洞是否已有编号、是否可立即修补，都不会改变这层依赖关系。

在 Moore 看来，当时使用大语言模型的攻击工具让更多人能尝试利用漏洞，却未必擅长隐藏踪迹。他提到可以用蜜罐诱导这类工具暴露身份或行为，再据此更快发现攻击者。对他而言，防火墙、访问控制和蜜罐重新变得重要，正是因为防守者不能期待消灭所有攻击。

从 Metasploit 的争议到 AI 恐慌

两人把当下对 AI 攻击能力的担忧，放回了 2003 年 Metasploit 发布时的争论。Gray 当年在悉尼的 ZDNet 新闻台报道安全事件，也是在那时认识 Moore。Moore 回忆，Metasploit 最初数年曾被批评为给网络犯罪提供便利，甚至有人把他称作网络恐怖分子；但随后，公开工具不再领先于攻击者，反而常常落后于他们已经掌握的手法。防守方也需要公开的利用框架，才能跟上攻击技术。

这段经历构成 Moore 对当前政策讨论的立场。他主张开放模型有助于行业保持防御能力，呼吁放慢发展或以监管来减速，无法阻止全球范围内的攻击研究。Gray 也反对把风险描述成末日，不过他承认过渡期会很混乱。两人由此把注意力放在攻击能力扩散后的工程问题：当攻击更容易发动时，隔离、监测、检测和复盘会成为日常工作。

Moore 还认为，恐慌本身会带来商业激励，因此安全行业应把更多注意力放在资产可见性、入口控制和可验证的检测能力上。两人讨论的是攻击与防御工具的演进，而非 AI 的整体社会影响。

把 AI 接进产品之前，先重做接口和边界

Gray 认为 RunZero 较早改变了 OT 主动扫描的看法：只要充分理解协议，主动探测不必然会让工业环境停摆。Moore 随后介绍 4.9 版本加入的能力，包括 BACnet、Modbus、S7 等 OT 协议及背板协议的发现，也包括把二层、三层和串行连接放在同一张地图中查看。他还提到漏洞修复跟踪、暴露管理、仪表板和报告功能，让不同岗位看到自己需要处理的信息。

团队对在产品中加入 AI 的态度曾相当保守。Moore 说，一些客户起初明确不希望出现 AI 功能；同时，团队仍在研究如何安全地使用相关工具。等到客户需求和团队把握同时变化后，RunZero 才开始交付功能。团队先搭建能够执行集成任务的底层引擎，再让 AI 参与生成集成。

Moore 把这种做法称为集成生成器。产品先提供多种通信、凭据和加密设置，再让模型生成相应的集成。根据他的说明，这个引擎可使用 SSH、WMI、SMB、MSRPC、HTTP 等方式，因此既能把数据取入产品，也能把结果送出。用户不必为每一个定制需求从零编写 API 调用，生成的内容则运行在产品设定的权限与凭据边界内。

AI 后端采用 BYOK，也就是由客户提供自己的密钥和服务地址。客户可选择自己的模型服务、网关或日志与过滤层，让报告生成、问答和集成创建请求经由指定端点。Moore 以 OpenRouter 为例，说明客户若需要可观测性，可以从所选后端取得相应的 OpenTelemetry 日志；模型选择、请求路径和观察能力都留在客户已有的控制面中。

MCP 的难处在于上下文、权限和反证

RunZero 的 MCP 服务直接随产品实例运行，无论实例是自托管还是云端，都通过远程 HTTP 流式连接提供工具。Moore 说，首个版本上线后几乎没人使用：API 又慢又会把上下文窗口塞满，说明文本和 CSV 导出都可能占据大量 token，返回的数据也多到难以决策。

团队后来重做了工具集，把摘要放到 API 层处理，并调整访问控制、API 密钥和用量管理。自然语言搜索可以先转换成可继续调用的查询；默认还限制了检索记录数与代理回合数，Moore 提到默认约为八回合。目标是在给模型足够上下文以调用工具的同时，避免输入和输出两端都耗尽窗口。改版约一个月后，他观察到使用量开始上升，但没有提供具体用户或请求规模。

权限是这次返工的另一半。早期只有只读、读写和管理员等较粗的选项；现在可以按资产清单、用户管理等数据类别细分读写权限，再映射为角色，并通过 SSO 组把角色分配给特定组织。MCP 凭据也能限制到特定组织或特定数据类型。Moore 说，AI 在这类大规模重构和回归测试中有帮助，但权限模型本身仍需要产品团队逐项定义。

当 Gray 问到未来会不会主要由代理调用 API、仪表板逐渐退居次位时，Moore 没有把两者视为替代关系。用户可以用提示词生成任意报告，却容易只得到自己指定的答案，忽略与目标相反的信息。因而他仍主张保留有明确判断的仪表板、查询和图表，让系统指出使用者本来没有要求展示的问题；与此同时，定制化接口让团队能按自身工作流取数和执行任务。对安全产品来说，代理的灵活性和能呈现反证的可视化，需要同时存在。