OT/ICS安全训练数据稀缺？从5%溯源样本看懂数据组织与异常检测

刚接手一个工控安全项目时，你会很自然地想找一套现成的 OT/ICS 安全训练数据集来跑通异常检测流程。但真正找过一遍的人大多会碰壁：公开数据要么是模拟流量，要么标签不完整，要么缺少攻击步骤的上下文。最近看到的一个方向，是从已证明来源（provenanced）的 OT/ICS 安全训练数据集中抽取 5% 公开样本，用来让更多人先跑通流程、检验方法。这个“5%”听起来像是一个缩水版，但仔细想，它真正测试的不是模型，而是你对数据、标签和场景边界的理解。

1. 首先弄明白：OT/ICS安全训练数据为什么稀缺

1.1 生产数据不能碰，实验室数据不可信

在讨论数据稀缺之前，要先确认一个前提：OT/ICS 安全和传统 IT 安全虽然都叫“安全”，但数据形态完全不同。OT 环境里，Modbus、DNP3、S7Comm 这类工控协议通常保持周期性通信，生产流程对实时性和确定性要求极高，任何额外的扫描、抓包、流量干扰都可能影响控制回路。所以，现实的工控安全团队可以部署旁路监控，但很少敢在不停产的情况下做安全测试，更不可能为了采集攻击数据而主动中断生产。于是，带攻击标签的数据极少来自真实的在线系统。

即便某个现场发生过安全事件，日志也未必完整。PLC、HMI、历史数据库、工业防火墙、工程师站各自记录一份数据，时间基准可能不一致，字段口径可能不同。更麻烦的是，事件过程中的物理量变化（例如压力、温度、转速）大多只存在过程控制系统里，网络流量只是其中一个视图。要把这些数据整理成适合训练的数据集，工作量非常大，而且涉及商业机密和法律责任。

1.2 稀缺导致模型训练靠“借数据”与“造数据”

因为没有公开的完整真实攻击数据，很多团队会先用 IT 网络入侵检测数据集做试验。这个思路不是不行，但容易踩进一个坑：IT 流量的随机性远高于 OT。IT 网络里用户访问网页、收发邮件、下载文件，行为混杂，而 OT 网络里的 PLC 与 HMI 之间每几百毫秒可能就有一条固定周期的请求。用一个在 IT 数据集上表现很好的模型直接识别 OT 异常，往往会因为协议特征差异太大，产生大量误报。我甚至见过把一个在 CICIDS 系列数据集上性能不错的模型迁移到 Modbus 仿真环境后，F1 直接掉了一半的情况。原因不是模型退化，而是数据分布根本不匹配。

仿真数据是另一条路。现在有很多开源项目可以搭建小型 ICS 仿真环境，生成 Modbus 和 DNP3 流量，并注入一些攻击脚本。这类数据的好处是场景可控、标签明确，缺点是通常“太干净”。真实 OT 网络中会有短时抖动、设备重启、工程师临时改配置、偶发网络拥塞，这些噪声并不会严格按攻击阶段出现。如果只用“规范”的仿真数据训练，模型在真实环境中会因为分布外样本而失效。

1.3 一个“5%公开样本”出现的背景

所以，安全训练数据集的价值不在于有多少个 GB，而在于能不能回答三个问题：数据来自什么环境？标签是谁定义的？每条样本能不能追溯到具体场景？过去的公开数据集往往只给一个 CSV 或 PCAP，不给场景说明，不给设备清单，不给攻击阶段划分，导致后来者只能盲目调参。最近看到的这个方向，把一套带完整溯源信息的 OT/ICS 安全训练数据集开放出 5% 的公开样本，就是想先让使用者在全局数据之外，验证数据组织方式是否合理。这个思路挺值得关注：它把“数据发布”从一次下载变成了一个可以被评估、被讨论的工程过程。

2. 拆开标题：provenanced 数据到底在说什么

2.1 provenance（溯源）不只是文件的“出处”

Provenance 这个词，在数据集语境下翻译成“溯源”或“来源信息”都对，但不能把它简单理解成“这是哪个实验室发布的”。这里更重要的是一套贯穿数据准备阶段的标准。举个例子，一条攻击流量记录至少应该包含：网络拓扑中的位置、涉及的设备型号、通信协议、告警或攻击阶段、数据采集时间范围、标签规则版本。这些信息组合起来，才能让使用者判断这条样本在什么条件下有意义。

如果一份数据集只给“源IP、目标IP、协议类型、标签”，它就像一张没有尺例的地图，你很难知道坐标代表什么。带溯源的数据集相当于在地图上标了比例尺、图例和拍摄时间。对于算法工程师来说，这批额外元数据可能要占据大量存储，但它能避免一个很常见的问题——你把模型调得很好，却讲不清它为什么对某一条攻击报警。

2.2 为什么攻击事件必须带有上下文

OT 攻击很少是单包攻击。即使是一次简单的指令篡改，也往往经历了探测、建立通信、发送恶意指令、观察物理响应等阶段。如果数据集只把流量标成“正常”和“异常”，模型只能学到异常的模式，学不到阶段之间的关系。而带溯源的数据集会为每条样本关联攻击阶段编号，甚至包括该阶段前后的状态量变化。这样训练出来的模型才有机会对“链式攻击”提前预警，而不是等恶意指令下发之后才报警。

这一点在生产环境里特别关键。很多 OT 安全产品想要的不只是一个“有没有攻击”的分数，而是“攻击正在沿哪个路径推进”。没有上下文的数据，很难支撑这种分析。所以，我当时看到“provenanced OT/ICS security training datasets”这个描述时，最先注意的不是“训练数据集”，而是“provenanced”。它意味着数据不是简单采集后转储，而是按可解释、可复现的方式组织过。

2.3 5%样本的真实价值：不是数据量，而是数据组织方式

一个 5% 的公开样本，在数量上大概率不足以训练一个可靠的深度学习模型。它更重要的作用是让使用者在投入大量资源之前，先回答以下几个问题：这个样本集里有多少种协议？标签是二分类还是多阶段？时间戳是否完整？每条样本能映射回哪个场景？如果 5% 样本在这些维度上都清楚，说明发布方对数据工程是有意识的，后面使用全量数据时重复成本会低很多。如果 5% 样本非常混乱，那全量数据很可能只是“更多混乱”，此时你在上面做的模型评估也会失真。

抽样方式在这里很关键。如果 5% 是简单随机抽样，攻击事件少的小类可能几乎被漏掉；如果是分层抽样，则保留了类别比例，但时序连续性可能被切断。使用时要先阅读文档确认抽样策略，不能默认它和全量数据同分布。

3. 把这5%用得起来：从拿到样本到训练出第一个模型

3.1 环境准备与依赖确认

拿到样本之后，第一步不是写神经网络，而是确认你手里的东西到底是什么。先看元数据文档和文件列表，再看格式。常见格式包括 CSV、Parquet、PCAP、JSON。不同的格式决定了你后续的解析成本。我建议先做一个独立虚拟环境，避免把数据分析环境弄得越来越乱。

python3 -m venv .venv source .venv/bin/activate pip install pandas numpy scikit-learn matplotlib # 如果是 Parquet 格式，再安装 pyarrow pip install pyarrow

如果原始数据是 PCAP，你还需要装流量解析库，例如 scapy 或 tshark，但要注意这些库的版本和协议解析能力。更重要的，是确认数据集文档里声明的 Python 版本和依赖版本，不要想当然地用最新版本，因为旧数据文件可能和某些新库存在兼容问题。这里没必要一次装全，按需安装，跑一步看一步。

3.2 先做数据概要，不要直接训练

很多人拿到数据后第一件事就是训练神经网络，这是最容易被带偏的。正确做法是先做数据概要，把数据当普通数据集去探索。下面这个示例可以帮你快速了解表格型数据的基本面貌：

import pandas as pd # 示例结构，实际文件路径以数据集文档为准 df = pd.read_csv("sample.csv") print(df.shape) print(df.dtypes) print(df["label"].value_counts()) print(df["timestamp"].min(), df["timestamp"].max()) # 如果需要时间序列分析，先解析时间列并排序 df["timestamp"] = pd.to_datetime(df["timestamp"]) df = df.sort_values("timestamp")

这一步会暴露很多问题。比如，label 列可能不叫 “label”，而是像“attack_type”“phase”“severity”这样的名字；时间戳可能不是标准格式，有的精确到秒，有的精确到微秒；缺失率高的列可能根本无法用于训练。我见过有人直接把标签列当成 float 输入模型，训练完成后才发现标签是连续值，这属于完全没有做数据探索。建议在此阶段画出标签分布和时间覆盖图，确认数据是不是连续记录，有没有明显断层。

3.3 从单样本到批量：定义一个最小可复现训练流程

确认数据可读之后，建议用一个很小的模型跑通全流程。这个阶段的目的不是精度，而是让数据能够顺利进入模型。流程为：读入数据 -> 特征选择/构造 -> 划分训练验证集 -> 训练 -> 评估 -> 记录结果。所有步骤都要固定随机种子和数据集划分方式，否则后面很难对比不同模型的效果。

这里有几个实操经验。第一，不要把攻击时间段切得太碎。如果你的样本是带时间戳的连续流，直接随机划分训练集和测试集，很可能让同一条攻击事件同时出现在两边，导致指标虚高。更好的做法是按时间划分，比如前 80% 时间做训练，后 20% 时间做验证，或者按场景编号划分。第二，要先验证模型能过拟合一个批次的数据。如果在几十条样本上都无法良好拟合，说明特征或模型设置有问题，没必要继续调参。第三，日志要记录清楚。跑完一次实验后，至少把数据版本、特征列表、参数、指标都存下来，方便将来复现。

注意：不要一上来就训练大模型，先用小模型和最小数据子集把数据链路打通。链路通了，再慢慢增加特征和模型复杂度。

3.4 一套数据集质量评估清单

在决定是否要申请或下载全量数据之前，可以拿这份清单去验一验：

• 数据来源与许可证：能否用于研究和商业用途？是否允许二次分发？
• 协议覆盖：是否包含你关心的 OT 协议，如 Modbus、DNP3、S7Comm、EtherNet/IP？
• 时间信息：字段是否统一，时区是否明确，是否存在时间跳变？
• 标签体系：是二分类还是多标签？是否包含攻击阶段？是否存在冲突？
• 数据粒度：是逐包、流级还是会话级？是否包含网络层/应用层字段？
• 类别平衡：正常流量和攻击流量的比例是否合理？
• 场景划分：训练集和测试集是否按场景隔离，以避免数据泄露？
• 溯源信息：每条样本能否映射到设备、拓扑、攻击脚本或采集点？
• 缺失值与重复值：是否需要大规模清洗？
• 扩展性：是否预留了与全量数据兼容的接口和字段？

如果这份清单有一半以上不明确，建议先和发布方确认，再投入时间。数据准备阶段省掉的检查，往往会在模型评估阶段加倍还回来。

4. 从样本到生产：边界、风险和最关键的排查顺序

4.1 适合谁、不适合谁

5% 公开样本适合三类人：一是安全研究员，想快速验证一个新想法在 OT 数据上是否可行；二是算法工程师，需要一份带标签、带溯源的数据来测试训练管线；三是学生和转行者，没接触过工控安全，想通过真实数据形态建立基础认知。

不适合的场景同样重要。如果你希望直接把模型部署到某条产线上，不能只依赖这个 5% 样本。它只是一个中间产物，真正部署前需要结合现场流量、设备清单、应急预案做小范围试点。如果你的目标是比较多个工业安全产品的性能，也不能只看这个样本的公开指标，因为你不知道发布方预处理和后处理逻辑，对比结果可能偏离实际。还要提醒一点，如果你完全不懂 OT 协议和工业网络架构，直接拿这份数据调模型，很容易把 IT 思维带进来，只能离业务越来越远。

4.2 数据漂移、标签不平衡和溯源链条断裂

从样本走向生产，最常见的三个坑：

数据漂移。5% 样本和全量数据即使同源，抽样方式也可能引入偏移。比如简单随机抽样会导致小类攻击事件占比过低，影响少数类检测；按时间抽样则可能遗漏某些长期运行的攻击场景。如果样本抽取不是按拓扑或攻击类型分层，你在样本上得到的指标就不能简单外推到全量。

标签不平衡。OT 安全数据里，正常流量往往占 95% 以上，攻击流量可能只占很小比例。直接训练会出现“全部判正常”也能得到很高准确率的现象。所以要关注 Precision、Recall、F1，而不是整天盯着 Accuracy。

溯源链条断裂。如果样本数据里没有把流量映射到攻击阶段和设备上下文，模型报警时你很难知道这是哪个环节出了问题。很多安全产品在实验室效果很好，一到现场就被关闭，就是因为只在“流量特征”层面做了报警，却无法告诉操作员“这条报警对应的设备、协议、攻击阶段”是什么。数据溯源，正是为了补上这个断点。

如果训练集和测试集来自同一条时间线，很容易出现数据泄露，模型指标虚高。先按时间或场景划分，再谈模型性能。

4.3 排查一个“训练结果异常”的顺序

当你在样本上训练出来的结果“高得不正常”或者“低得离谱”时，可以按下面顺序排查：

1. 先看数据泄露。训练集和测试集是否混入了同一时段的记录？尤其检查按时间顺序划分时，是否有人先做了全量归一化再利用未来信息。
2. 再看标签质量。标签是不是由自动化规则生成的？规则本身是否用了你准备作为特征的数据？比如用一个基于阈值的规则把高位寄存器值标成攻击，那模型学到的只是这个阈值，不是真正的异常。
3. 再看类别平衡。正常样本占比多大？是否有重采样、加权或异常检测场景下的无监督方法？
4. 再看特征构造。时间戳是否被当作连续特征直接交给模型？有没有包含滞后变量导致未来信息泄漏？归一化是否在划分训练集前执行？
5. 最后看模型选择。OT 流量是序列数据，用普通分类器能否学到阶段特征？如果小模型已经够用，就没有必要上复杂模型。

这个顺序不是万能，但它覆盖了从数据到建模的大部分低水平错误。大多数“结果异常”都不是模型技巧不够，而是数据划分和预处理阶段出了问题。

4.4 未来：自己构建带溯源的数据集

如果公开的 5% 样本始终无法满足你的业务需求，另一个方向是自己构建一套带溯源的数据集。这里说的并不是要复刻实验室，而是建议把数据准备工作工程化。搭建一个小型 ICS 仿真环境时，至少记录以下元数据：网络拓扑和设备型号、每个流量采集点的位置、正常运行脚本、攻击场景脚本、标签生成规则和版本、时间同步方式。每次修改环境或脚本后，重新生成数据，并把版本号与文件名关联起来。这样，你最终得到的就不只是一堆流量，而是一个可以复现、可以追溯数据的实验记录。

把数据准备当作工程问题，而不是临时任务。

自己构建数据集确实很耗时，但它会让你对数据中的每个字段都心知肚明，以后训练模型、评估产品、汇报成果都有据可依。而且，这其实才是“provenanced”真正想推动的做法：不是只消费别人发布的数据，而是形成一套自己的数据管理习惯。回到最开始那个 5% 公开样本的启示——真正值得长期关注的，不是它提供了多少流量，而是它是否逼你更早地面对数据来源、标签、边界和可复现性。如果你能从一份样本开始，把小流程跑通，把数据质量检查清单沉淀下来，再逐步叠加自己对 OT 场景的理解，那么在这条技术路径上就已经领先很多人了。