遗留系统，现实冲击：OT 安全的真实面貌

我今天想写一写运营技术（OT）与安全领域中一个我经常遇到的特别棘手的问题。鉴于我个人作为无可救药的漏洞观察者的兴趣，以及我在 runZero 担任安全研究副总裁的职业角色，我处理 OT 安全问题的频率比一般人要高。我注意到，在更广泛的漏洞管理领域中，确实存在一种"IT 是这样，但 OT 是那样"的氛围。在 OT 领域，发现、记录和披露漏洞的过程都有其独特之处，那么我们就来深入探讨一下！
在这里，一切都是遗留的
在 DEF CON 上，ICS Village 是最受欢迎的去处之一。它对信息安全领域的新手和行业老手都同样有吸引力，原因相同：一旦你带着现代的 IT 漏洞狩猎工具和直觉靠近 OT 技术，往往感觉就像回到了 1999 年，重新体验当年的黑客风格。直到最近，OT 作为一个类别，还不太关心提示输入密码或验证用户输入；其假设是本地网络是可信的。软件本身通常以编译对象的形式运行，硬件资源有限，因此没有太多空间容纳像 ASLR 和 DEP（地址空间布局随机化和数据执行保护）这样花哨的 21 世纪防御措施。因此，它是练习的理想平台，并且对于我们这些，怎么说呢，生活经验更丰富的人来说，还有点怀旧。
拒绝服务是灾难性的
然而，许多经典的 OT 攻击实际上甚至不涉及远程代码执行（RCE）或本地权限提升（LPE），而这些都是 IT 攻击者通常追求的"大奖"漏洞。相反，拒绝服务（DoS）效果的价值在 OT 中至关重要。一个合法的"单包杀手"就能让一台极其昂贵的设备变砖（公平地说，这在 IT 世界也会引起关注），一个仅仅是"临时"的状况（比如持续不断的垃圾流量导致设备无法执行其 OT 功能），或者一个安全控制触发序列（故意导致故障安全状态），最终都会导致同样的结果：执行器停止，机器人冻结，整个 OT 建设的全部目的被中断、偏离计划，有时甚至危及人的生命安全。
这对 OT 运营者来说是一件大事，远比在 IT 环境中严重得多——在 IT 环境中，优雅的故障是正常的、可控的，并且通常可以通过投入廉价的带宽和 CPU 来快速解决。几乎没有人会有一个备用的备份工厂。
看到问题，就要说出来
那么，如果你在 OT 设备中发现了一个（对你而言）新的漏洞，你会怎么做？在 IT 领域，通常的路径是通知软件生产商，获取一个 CVE 编号，也许能推动修复（也许不能），然后发布研究成果。少数情况下，某些 IT 漏洞在披露前需要更多的谨慎和审查，但几乎总是存在某种缓解措施或配置，即使在没有补丁的情况下也能削弱漏洞的影响。偶尔，核心库（或整个软件供应链）中的漏洞需要额外的协调层级。这很糟糕，但尚可管理。
OT 漏洞则不同；与 IT 不同，在 OT 领域，描述一个理论攻击的后果时，常常以"这就是你如何毒害整个社区"或"一旦电力输送中断，医院就会瘫痪"或类似末日般的场景收尾。即便是讨论漏洞的存在本身也充满风险，媒体和政府会感到恐慌。更别提发布一个完整的概念验证代码了。
更糟糕的是，即使你知道漏洞的存在，实际修补许多 OT 设备也是困难重重，甚至不可能。存在漏洞的代码可能位于数百英里外的油田的一块电路板上，或者受到非常严格的非计划更新法规约束。它可能根本无法重新编程，而是需要代价高昂的"叉车式升级"来缓解，而且新硬件是否与你突然变成遗留系统的控制平面兼容，谁也说不准。通常，你能做的最好的事情就是将易受攻击的设备隔离到网络中的一个"不听话的角落"，严格控制对该网络的访问，并接受这样一个事实：任何接触它的人，无论是物理上还是虚拟上，都有能力摧毁它。
当两个世界碰撞时
事实是，OT 的大部分防御姿态恰恰就是网络隔离，而且仅仅是网络隔离。但是，这种情况正在改变，无论你喜欢与否，OT/IT 融合的时代已经到来，这意味着 OT 正日益成为 IT 的问题。我们不可能永远把这些漏洞封存起来。那么，你该如何处理你新发现的 OT 零日漏洞呢？我认为你不能只是坐视不管。在前沿 AI 对抗软目标的世界里，你轻易发现的漏洞被别人用作关键基础设施武器，只是时间问题。我敦促你访问 https://cisa.gov/report，点击"报告软件或 ICS 漏洞"按钮。这是一个常常令人困惑和恐惧的过程的第一步，但近年来，主要的 OT 供应商已经认真对待这些报告，并与美国的 CISA 以及其运营地区的区域 CERT/CC 建立了良好的关系。
虽然"看到问题，就要说出来"在过去可能并不受欢迎，但 OT/IT 融合的现实要求我们发展我们的思维和工具，以应对 OT 面临的基本网络安全挑战，以免 AI 辅助的攻击者关掉电灯，或造成更严重的后果。