用 SOC 的方式管理洪水:面向泰国中资工厂与园区的「Flood SOC」检测与响应蓝图

近年来,越来越多中资制造企业在泰国东部经济走廊(EEC)及中部工业园区设厂。选址评估时,电价、物流、税收优惠都会被反复测算,但有一项风险常常只停留在一句"历史上曾受洪水影响":泰国每年的雨季。

2026 年 7 月,泰国政府推出了由水文信息研究所(HII)运营的国家水情平台 ThaiWater 新版本。新平台整合了 13 个部委下属 56 个机构的数据,把雨量雷达、水位、水库状况和风险区域集中到同一张交互地图上,并为全部 76 个府上线了府级水情网站。

困扰泰国几十年的"各部门水情数据分散、口径不一"问题,正在得到解决。但数据齐了之后,下一个问题随之浮现,而且做安全运营的人一眼就能认出来:

有数据,不等于能行动。 凌晨三点上游水位开始上涨,只有当某个系统注意到它、判断它对本厂是否要紧、开出工单、叫醒对的人、启动对的预案时,这些数据才有价值。同时,它不能在流域每下一场雨就把值班人员叫醒一次。

这正是安全运营中心(SOC)存在的意义。本文提出「Flood SOC」的思路:把我们为网络威胁构建的检测与响应模式,用在水上。

一、洪水与网络攻击,在运营上是同一种形状

抛开具体领域,SOC 做的就是五件事:从大量嘈杂的来源采集信号、关联成有意义的事件、评估严重程度、以工单形式跟踪处置、把第一步动作自动化。洪水应对五件事一件都不少。

SOC 概念	洪水场景中的对应
日志源(防火墙、终端、VPN)	水位传感器、雨量计、雷达、CCTV、居民上报
SIEM 采集与解码	把传感器数据和公共数据统一成一种事件格式
关联规则	"上游快速上涨 且 强降雨预报 且 下游闸门停运"
不可能旅行(impossible travel)检测	洪峰到达时间预测:上游涨水何时到达本厂
风险评分与严重级别	针对厂区的洪水风险评分
工单管理(DFIR-IRIS)	一次洪水事件 = 一张工单,有时间线、有负责人
SOAR 剧本	通知周边、启动工厂 BCP、调度现场团队
告警疲劳与调优	误报太多,大家不再理会预警
Agent 静默告警	暴雨中突然失联的传感器

最后两行比看上去更重要。多数洪水预警项目失败,不是败在传感器,而是败在这两点。

二、2011 年的教训:损失由谁承担

2011 年泰国大洪水造成的损害和损失合计 1.43 万亿泰铢(约 465 亿美元)。常被忽视的是:其中约 70% 由制造业承担,原因是大城府和巴吞他尼府的六个工业园区被淹;全部损害和损失中约 90% 落在私营部门身上。

中部平原的洪水推进缓慢,理论上许多工厂有好几天的预警时间。它们缺少的,是把府级信息转化为厂级决策的机制:现在转移库存、现在安全停线、现在通知客户。

国家平台无法替每一家工厂做这个决定,Flood SOC 可以,因为它的规则是为一道围墙、一批资产、一套预案专门编写的。

三、整体架构

flowchart TD
    S1["河道与水渠水位传感器"] --> N["数据标准化与富化"]
    S2["雨量计与雷达"] --> N
    S3["ThaiWater 与府级水情数据"] --> N
    S4["CCTV 读取水尺"] --> N
    S5["LINE 居民上报"] --> N
    H["传感器心跳监测"] --> R
    N --> R["关联与风险评分引擎"]
    R -->|低分| L["仅记录"]
    R -->|中分| C["创建洪水工单"]
    R -->|高分| P["创建工单并呼叫值班人员"]
    C --> I["DFIR-IRIS 工单管理"]
    P --> I
    I --> PB["SOAR 剧本执行"]
    PB --> A1["多语种 LINE 与短信通知"]
    PB --> A2["工厂 BCP 动作"]
    PB --> A3["现场团队 TAK 地图"]

图中每个组件,在生产环境的 SOC 里都已经存在。变化的只是输入的数据和输出的剧本。

信号层。 在河道、桥梁和厂区周边排水沟安装低成本雷达式或超声波水位传感器,通过 LoRaWAN 或 NB-IoT 回传;在数据提供方许可的范围内接入 ThaiWater 和府级水情中心的公开数据;利用现有 CCTV 读取水尺;员工和周边居民通过 LINE 官方账号上报带定位的照片。

关联层。 标准化模块把所有来源统一成一种结构(站点、河段、数值、变化率、时间)。关联引擎必须保存状态——这是无状态规则引擎单独做不到的,和网络安全场景中由 SOC 集成器而不是 Wazuh 负责多事件关联与去重是同一个道理。

响应层。 DFIR-IRIS 保存工单,Shuffle 执行剧本。需要现场协同时,工单推送到 TAK 共享态势图。Flood SOC 决定的是什么时候该启动 TAK。

四、检测规则:从阈值到关联

第一级:阈值。 "X 站水位超过 Y 就告警。"大多数地方预警系统停留在这一级。有总比没有好,但噪声很大。

第二级:风险评分。 把多个弱信号合成一个可解释的分数。以河边工厂为例:

信号	分值
上游站点每小时上涨超过 20 厘米	+35
最近站点距堤顶不足 50 厘米	+30
流域预报 24 小时降雨超过 90 毫米	+20
下游闸门或泵站停运	+15
30 分钟内 1 公里范围收到 2 条以上居民上报	+15

70 分及以上为严重(建单并呼叫值班);40–69 分建单不呼叫;40 分以下仅记录。

以上数值仅为示例。 实际权重和阈值来自厂区的历史淹水记录、水文专家意见,以及最关键的——在真实降雨中的调优。

第三级:有状态的关联。

• "到达预测"取代"不可能旅行"。 SOC 会标记两次物理上不可能完成的异地登录;Flood SOC 则根据上游站点的涨水和该河段的历史行进时间,推算洪峰到达下游的时间窗口。通知内容是"预计 9–14 小时后到达厂区边界",而不是"某处水位偏高"。
• 去重。 同一河段已有未关闭工单时,新读数追加到该工单,而不是新建。否则一场暴雨能生成五十张工单,没人会看。
• 按趋势升级。 一直停留在"中"级、但上涨速度在加快的工单,会被自动重新评分。

引擎输出的决策,和 SOC 的决策几乎一样:

{
  "decision": "create_case_and_page",
  "severity": "critical",
  "risk_score": 80,
  "reach": "upstream-bridge-to-estate-north-gate",
  "reason": "Upstream rise 28 cm/h, bank crest margin 40 cm, very heavy rain forecast",
  "predicted_arrival_hours": [9, 14],
  "playbook": "estate-bcp-level-2"
}

五、静默本身就是信号

在 SOC 里,停止发送日志的 agent 本身就要告警。simpliSOC 已为日志源提供这一能力:在设定时间窗口内没有收到事件,就会触发告警。

在洪水监测中,这条规则更加关键。传感器恰恰会在最需要它的时候失效:停电、太阳能板被漂浮物遮挡、基站中断,甚至水位直接没过传感器。暴雨中还显示"2 小时前:水位正常"的系统,比没有系统更危险。Flood SOC 把静默计入风险评分:当周边站点都在上涨时突然失联的站点,必须升级处理。

六、调优:频繁误报的预警,比没有预警更糟

去年收到三次错误撤离通知的员工,今年就不会动。上线后的头几周,和部署 SOC 一样是调优期:记录每一次误报,调整权重与阈值,抑制已知的无害模式(例如每晚随潮位上涨的河段、维护期间的异常读数),然后再扩大通知范围。

七、中资企业需要额外考虑的问题

数据不出境。 传感器数据、员工和周边居民的联系方式,都属于需要谨慎处理的数据。Flood SOC 与 simpliSOC 一样采用本地部署或私有云部署,原始数据留在泰国当地的基础设施内;向国内总部汇报时,可以只同步工单摘要和处置时间线,而不必传输原始个人数据。同时,居民联系方式在泰国受 PDPA 约束,需要合法依据并控制保存期限。

让 BCP 的"触发条件"可量化。 很多海外工厂的应急预案写清楚了"怎么做",却把"什么时候做"留给现场判断。Flood SOC 把风险评分和剧本绑定,让启动条件成为事先约定、可审计的规则。这也是"智改数转"在海外工厂落地的一个具体场景:从经验判断走向数据驱动。

传感器网络同样是攻击面。 被注入的虚假水位数据,可能导致不必要的停产,或者掩盖真实险情。把水情监测和网络安全监测放在同一个运营中心,优势也在于此。

八、已有能力、按项目定制、明确不做

目前已提供:

• simpliSOC:基于 Wazuh 的检测、DFIR-IRIS 工单管理、Shuffle 自动化,以及负责关联、去重和严重级别映射的集成器;通过 Docker Compose 本地部署。
• 日志源静默告警。
• TAK 集成服务,可将工单和告警接入共享态势图。

按项目定制(并非打包功能):

• 传感器接入、解码器和洪水事件标准化结构。
• 针对厂区调优的关联规则、风险评分和到达预测逻辑。
• ThaiWater 及府级水情数据连接器(遵循数据提供方的使用条款)。
• LINE 官方账号通知流程与多语种模板(中文、泰语、英语、缅甸语等)。
• 工厂 BCP 剧本与 ERP 联动(例如标记受淹风险库存)。
• 现场设备心跳监测规则。

明确不做:

• 官方预警和撤离命令。这属于泰国灾害预防与减灾厅(DDPM)、气象厅和地方政府的职权。Flood SOC 辅助决策,不替代官方预警。
• 作为权威机构发布水文预报。我们接入预报和历史行进时间,但不是预报机构。
• 生产传感器硬件。我们集成硬件合作伙伴的设备。

常见问题

Flood SOC 是现成的产品吗?
不是。它是一套参考架构,由现有组件(simpliSOC、集成器、TAK 集成)加上每个厂区的定制工作(传感器、规则、剧本、调优)组成。

能替代 ThaiWater 或官方预警吗?
不能。ThaiWater 是最重要的输入之一。Flood SOC 补上的是针对贵厂围墙的运营层:规则、工单、负责人和预案。

Wazuh 真的能处理水位数据吗?
Wazuh 可以解码结构化 JSON 事件,因此传感器读数可以流经它。但上涨速度、行进时间、各河段状态等水文关联,和网络安全中的有状态关联一样,放在集成器层处理。具体分工按项目确定。

第一个项目有多大?
从一个厂区、几台传感器、一路公共数据、一个通知渠道开始,在真实降雨中调优之后,再扩展到更多厂区和通知对象。

联系我们

如果贵司的厂区在 2011 年被淹过,或者去年雨季险些被淹,请把厂区平面图、构成威胁的河道,以及凌晨三点需要被叫醒的人告诉我们。我们会给出一份小规模起步方案:采集哪些信号、先上哪些规则、哪个剧本最先运行。支持中文沟通。

邮箱:hello@simplico.net
了解更多:simpliSOC 与 TAK 集成服务。

---

来源:

• All-in-One Page: Government Revamps ThaiWater App — Thairath English,2026 年 7 月 17 日
• 2011 Thailand Floods — Rapid Assessment for Resilient Recovery and Reconstruction Planning — PreventionWeb / 世界银行
• 如何在现代 SOC 中构建 Automated Decision Logic — Simplico