IT/OT 边界上的智能体

11 分钟读完

S27
运维 · 安全、对齐与智能体安全

IT/OT 边界上的智能体:控制必须在触及范围之外。

Booz Allen 交给两个前沿模型的只有子网边界——没有代码、没有图纸、没有 OT 指引——它们却清掉了针对其隔离制造业试验台设定的全部八项攻击目标,从初始网络沦陷走到在控制环境内部采取动作,只用了十六分钟出头。被报道为扛住了的那两项保护措施,是一台拒绝了命令的控制器,和一台因本地模式开关在位、无法被远程启动的电机:两者都是网络改不了的状态。这就是任何靠近厂区设备的智能体的全部设计准则——如果智能体能触达一项控制的状态,那项控制是摩擦,不是预防——而要做的工作,是把它变成一份清册,而不是一句口号。

STEP 1

先把跨越路径枚举出来,再去争论控制。

常见的反驳——「我们的智能体离 OT 远得很」——通常是真的,却几乎从来不是相关的问题。智能体并不需要 OT 访问;它需要的是对某个已经拥有 OT 访问的东西的访问,而每座工厂都有一份很短的这类清单。先把你的那份写下来,因为本页其余部分的范围都由这份清单界定。

  • 工程师工作站。它存着项目文件、编程软件,并且往往还有一份保存下来的控制器凭据。跑在它上面的编程智能体或桌面助手,继承了全楼里 OT 权限最高的那个位置——也就是开发者工作站上的智能体所编目的那片暴露面,只是后面挂上了物理后果。
  • 历史库及其复制作业。这是从 OT 到 IT 那条获批的、有文档的、通常还是双向的管道。对它的读访问就是你的智能体会被建立在上面的那个合法用例;问题在于同一个账号能不能写。
  • 厂商远程支持隧道。常设、极少复核、通常深入工艺网络才终止,而且越来越多地是一条自动化而非人工的路径。把它当成它本来的第三方风险来处理——第三方模型与厂商风险。
  • MES/ERP 集成。工单、配方、排程与设定值从业务系统流进生产。对智能体来说这一条最要紧,因为一个拥有普通 ERP 权限的智能体,可以在完全不碰任何 OT 协议的情况下改变工厂在生产什么。
  • 云端 OT 平台。某家厂商的监控或优化服务,从工厂出站连一条链路,并在互联网上开一个 API。智能体调那个 API;而那个 API 握着这座工厂。

给这些排序时,按凭据能导致什么来排,而不是按它坐在哪个网段。企业网上一枚只读历史库令牌,和一个能放行生产订单的 ERP 账号,都算「IT 侧」,而两者毫无可比性。这套清册纪律与智能体清册与登记相同,只多一列:有无物理效应。

STEP 2

四档控制,以及唯一能把它们分开的那个问题。

问题不是这项控制有多强,而是一个已经攻陷网络的智能体能否改变这项控制的状态。这一道检验产出四档,而团队经常买了第三档,却在风险登记册里写上第一档。

  • 第 1 档——物理与额定保护功能。泄压阀、光幕、安全额定的速度与间距监控、急停回路。按功能安全要求评估,并被设计成在控制系统本身已经失效时仍然动作。通过以太网发出的任何东西都改不了它们。
  • 第 2 档——硬件模式状态。拨在本地或编程模式的钥匙开关、物理写使能跳线、维护选择开关。要改它,得有人在厂房里。这是便宜的那一档,也是被用得最不够的一档:它大体上只是一个决定——远程启动并不是你需要的功能。
  • 第 3 档——设备层拒绝。跑在控制器自身上、会拒绝超范围或乱序命令的逻辑。很强,而且强得恰好等于它的固件、工程协议上的认证,以及那段逻辑能否被远程改写。Booz Allen 另一项存活下来的保护措施就在这一档。
  • 第 4 档——命令路径上的一切。网关、策略引擎、消息代理、你智能体的工具定义、它的系统提示。这些才是你真正会去建的控制,也值得建——面向智能体的策略即代码正是把第 1 至 3 档表达给那些必须遵守它们的软件的方式——但它们从智能体所在的那张网络就能触达,所以它们是摩擦。

分段值得单独说一句,因为它是多数团队第一个说出口的控制。ISA/IEC 62443 意义上的区域与管道,以及它们通常画在上面的 Purdue/ISA-95 分层模型,确实有价值:实验室那次运行里的十六分钟之所以存在,正因为有边界要跨,而且它留下了痕迹。但一道由「从被防守那一侧就能触达的设备」上的配置来执行的边界,是一个怀着好意的第 4 档。把它当作替你买来时间与证据的东西去列预算,然后再问这些时间是用来干什么的——那是第 4 步。

STEP 3

给智能体一条读路径;让写路径成为另一个系统。

几乎每一个真正有用的厂区智能体——异常分诊、班次总结、维护预测、能耗优化、根因叙述——都是读负载。随之而来的诱惑是:给同一个智能体、用同一份凭据,赋予对它所发现之事采取行动的能力,因为演示效果好太多了。请用结构而不是用政策去抵住它:写路径应当是另一个系统、另一个身份,而智能体输出到它那里的东西应当是一份请求,不是一条命令。

# The shape that fails: one identity, one protocol, both directions.

agent ──▶ OPC UA client ──▶ controller
          read + write on the same session
          a prompt-injected summary becomes a setpoint

# The shape that holds: read is live, write is a work order.

agent ──▶ historian replica  (read-only account, no write grant anywhere)
      └─▶ CMMS work order    (queued, named human executes it in the plant)
                              ▲
                              └── rank-2 mode switch still required
                                  for anything that moves

有三个细节决定这套做法在实践中立不立得住。那个读账号必须是在服务端只读,而不是靠客户端配置里的惯例只读——一个能调写方法的智能体,迟早会被要求去调。工单队列必须携带智能体的运行 id 以及它据以提出请求的证据,这样执行它的那个人是在审阅一项主张,而不是在服从一条命令;这就是以技工为读者的决策收据模式。而这个队列必须是乏味的:如果「等人来领工单」的延迟让这个用例变得毫无意义,那正是一个信号——这个用例需要的是第 1 档或第 2 档控制加一个被授权的信封,而不是一次更快的审批,也就是物理动作安全里论证的那套结构。

在任何触达执行机构的路径上,重试逻辑都是那个安静的杀手。「超时就重试」是每个智能体框架里的默认,而它在这里是实打实的危险:命令可能已经执行、只是确认丢了,于是重试把轴移动了两次。每一个与写相邻的工具,在被允许靠近一条管道之前,都需要一个幂等键和一个服务端去重窗口——见幂等与重试。

STEP 4

把你的响应时钟对着轨迹定价,而不是对着班次定价。

十六分钟这个数字,才是该把 OT 路线图重新排序的那一个,而它对防御方宽厚了两重:那次运行被「人类逐一批准每次漏洞利用」卡着,而试验台由搭建它的那家公司做了充分埋点。把它与各机构在内部人一类事件上实际报出的检测与响应时间放在一起——约十五小时,大致七小时检测、八小时行动——结论就是算术。以小时作答的被动 OT 监控,值得为定范围、通知与监管而拥有。但它不在闭环里。

由此引出两条后果,而相对一次监控部署,两者都便宜。

  • 闸门必须是同步的。任何带物理效应的智能体动作,在执行之前都要在请求路径上拿到一个策略判定,并在求值器出错时失败即关闭。异步检查是一份报告。失效模式的取舍在失败关闭与失败打开里讲得很明白,而在工厂里默认是关闭。
  • 急停必须走带外。一个通过智能体正在驱动的那个平台去吊销智能体令牌的急停开关,不是急停。它需要一条不穿过已沦陷平面的路径,以及一个不用开会就能拉下它的负责人——急停开关,以及问责与角色里那个权限问题。

检测仍然有它的位置,只是目标更窄。通用的行为基线在智能体身上失效,因为智能体天生异常;但 OT 给了你那些罕见的、确实有区分力的信号:向一个没有任何业务流程会写的标签写入、在维护窗口之外的一次模式变更、一个来自非工程师工作站地址的工程协议会话。这些是确定性的、低流量的、几乎免费的——也就是把检测智能体沦陷里那条「有区分力的信号」论证,用在一个恰好只有极短合法写入者名单的领域上。

STEP 5

记录那些让事件可重建的东西,并把工厂当成不可信输入。

一次物理事件之后,问题永远是同一个,而且几乎从来答不出来:是哪条指令导致了这件事、是谁或什么发出的、凭谁的权限。在工厂里,证据散落在三个不共用同一只钟的系统里,所以这件事需要在第一次事件之前决定,而不是在事件当中。

  • 每一次标签写入与每一次模式变更,带上发起身份、智能体运行 id(若有)、变更前的值,以及来自单一来源的单调时间戳。当操作员账号正是那个集成所使用的账号时,「操作员改了设定值」不构成证据。
  • 与之并排的智能体轨迹,保留时长至少覆盖你的事件调查窗口——取舍见轨迹采样与保留。被采样丢掉的轨迹,是你事后唯一无法重建的东西。
  • 授权记录:这次运行是在哪个信封之下运作的,以及哪位具名的人类签了它。没有它,责任就落到部署这个智能体的那个人头上——智能体动作的保险与责任里的那道缺口。

没人会去规划的那个方向是入站。传感器读数、告警文本、设备描述、标签注释与厂商文档,全都流进智能体的上下文,而它们全都是某人可写的——一个承包商、一次厂商固件更新、一个先摸到历史库的攻击者。一条告警描述就是一串智能体会当作指令来读的字符串,这让工厂成为一个提示注入面,也让遥测作为不可信输入从理论变成承重结构。隐蔽性帮不上忙:实验室里的模型在完全没有文档的情况下推算出了一台机械臂的安全区与运动限位,所以任何「指望攻击者看不懂你的工艺」的计划,都是在一个侦察成本已按 token 计价的市场里,按人的耐心来定价。

STEP 6

那套演练,以及那个告诉你自己处境的数字。

三项练习,按顺序来,没有一项需要新的采购。

  • 分档普查。把厂里每一个「经由网络抵达的指令能使其产生物理效应」的操作列出来。对每一个,点出会阻止它的那项控制及其档位。诚实做完,多数工厂会发现绝大多数落在第 4 档,并且发现把其中两三个挪到第 2 档,代价是一个钥匙开关和一场关于便利性的争论。那场争论才是真正的工作。
  • 有人值守的试运行。让智能体只读地跑在活数据上一个月,并由一位工程师给它的结论打分,在任何东西接到工单之前。正是这一档会抓到:智能体自信地读错了一个自 2017 年以来名字含义已经变了的标签。
  • 在管道处做故障注入。把历史库拔掉、让消息代理停住、返回过期值,然后看智能体会做什么——也就是面向智能体的故障注入里那套纪律。一个把过期读数当成当前值的智能体,会为一个一小时前就已结束的状态推荐一个动作。

要往上汇报的那个数字,是带物理效应的操作中,其预防落在第 1 档或第 2 档的比例。第一次算出来会很不舒服,而它是本页上唯一一个在模型换代、厂商推送更新、或有人匆忙加了个工具时都不会退化的指标。

本周就从这里开始:写出第 1 步的跨越路径清单与第 6 步的分档普查——一位 OT 工程师和智能体负责人之间一天的工作量。然后只做两件改动:在服务端把你智能体所用那个只读账号的写能力吊销掉,以及把一个高后果操作放到一个第 2 档模式开关之后。本页其余一切都是排序;而当你的检测延迟最终是七小时、你智能体的轨迹最终是两分钟时,仍然扛得住的是这两件。