# SDM2.0 与 OCSF 对比分析

> **文档定位：** 面向架构评审、产品负责人和研发团队的架构决策稿。
>
> **研究基线：** OCSF 1.8.0（2026-03-18 发布）与当前 SDM2.0 文档、Doris 数据契约及 S4 设计。
>
> **决策建议：** 采用“分层兼容”路线：OCSF 作为对外交换、行业分类与兼容性基线，SDM2.0 保留为平台内部事件调查、实体索引、存储查询与告警运营模型。
>
> **状态说明：** 本文区分“当前已实现”“当前草案”和“建议目标”；改造建议不表示代码、DDL 或接口已经完成修改。

---

## 一、执行摘要

OCSF（Open Cybersecurity Schema Framework）是厂商中立的开源安全数据 Schema Framework，以 Category、Event Class、Activity、Object、Profile 和 Extension 组织安全事件与 Finding。OCSF 明确不限定存储格式、采集方式或 ETL 实现，规范定义文件和规范化 Schema 以 JSON 表达。[1][2]

SDM2.0 当前定位为自研 SOC 的统一安全观测数据模型，以 Event 为事实单元，用 **source → carrier → target** 表达主行为链，用 **observer / related** 补充观察与关联语义。在此之上，SDM2.0 还研究或实现了事件宽表、语义分层、S4 实体倒排索引、调查视图和独立告警运营模型。[I1][I2][I3]

两者的核心交集是“多厂商安全数据标准化”，但不是同层次的替代关系：

~~~text
OCSF    = 逻辑 Schema + 行业分类 + 数据交换契约
SDM2.0  = 内部事件语义 + 物理服务模型 + 实体调查 + 告警运营
~~~

因此，不建议将 SDM2.0 直接替换为 OCSF JSON，也不建议忽略 OCSF 继续建设封闭的内部标准。推荐将 OCSF 引入为 SDM2.0 的外部标准基线，通过同一份语义映射同时产生 SDM 内部投影和 OCSF 交换投影。

---

## 二、架构决策

### 2.1 备选方案

| 方案 | 说明 | 优点 | 主要风险 | 评价 |
|---|---|---|---|---|
| 全面改用 OCSF | 以 OCSF Event/Finding 作为平台内部唯一模型 | 行业兼容度高，减少内部分类维护 | 无法直接替代 Doris 物理模型、实体 ID、调查索引和 SOC 工作流；丢失 carrier 的统一行为语义 | 不推荐 |
| 保持 SDM2.0 独立 | OCSF 只作参考，不进入核心契约 | 内部改造少，完全贴合现有产品 | 生态隔离，对外对接和规则迁移需长期自维护 | 不推荐 |
| 分层兼容 | OCSF 作为交换/分类基线，SDM2.0 作为内部服务模型 | 兼顾生态兼容、调查语义和查询性能，可渐进迁移 | 需要双向映射、版本治理和一致性测试 | **推荐** |

### 2.2 责任边界

| 责任 | OCSF 兼容层 | SDM2.0 内部层 |
|---|---|---|
| 外部数据交换 | 主责 | 通过映射导入/导出 |
| 行业事件分类 | Category/Class/Activity 基线 | 保留 SDM 稳定事件类型 |
| 事件角色和行为链 | 提供类专用对象 | 五角色模型主责 |
| 物理存储与查询 | 不规定 | S2/S3/S4 主责 |
| 实体归并和时间线 | 提供对象字段 | SDM 实体 ID 和 S4 索引主责 |
| Finding 交换 | Detection/Vulnerability/Incident Finding | Source Finding 对齐并保留来源语义 |
| 告警聚合与处置 | 提供 Finding/Incident 表达 | SDM Alert 运营模型主责 |

---

## 三、模型与能力对比

### 3.1 总体对比

| 维度 | OCSF 1.8.0 | SDM2.0 当前方向 |
|---|---|---|
| 目标 | 厂商中立的安全数据 Schema 与交换语言 | 自研 SOC 内统一事件、查询、关联与调查模型 |
| 治理 | Linux Foundation 项目，社区版本演进 | 项目内规范、OpenSpec 与代码契约共同演进 |
| 基本单元 | Event Class / Finding | Event |
| 分类 | category_uid + class_uid + activity_id + type_uid | event_category + event_type + operation + outcome |
| 对象语义 | 按 Class 使用 Actor、User、Process、Endpoint、Device 等 | 按统一五角色组织实体对象 |
| 字段约束 | Required/Recommended/Optional/Conditional/Profile | 概念文档有原则，物理表仍有大量可空列与占位值 |
| 告警/发现 | Findings Category，覆盖多类 Finding | Event 中 source_alert + 独立平台 sdm_alert |
| 实体调查 | 提供对象和 Observable，不规定归并算法 | 已设计稳定 entity_id、角色 posting 和 S4 索引 |
| 存储形态 | 实现中立，规范 JSON 为基准表达 | Doris 宽表、VARIANT、语义表、实体倒排/MV |
| 扩展 | Profile + Extension + unmapped | 扩展列 + extension VARIANT，尚需统一治理 |
| 生态 | AWS、Datadog、Splunk、CrowdStrike 等组织参与或支持 | 当前主要服务内部产品与数据链路 |

### 3.2 事件分类

OCSF 1.8.0 使用稳定数字身份组织事件语义：

~~~text
category_uid  = 事件领域
class_uid     = 事件类
activity_id   = 该事件类下的活动
type_uid      = class_uid * 100 + activity_id
~~~

例如认证登录可表达为 Authentication Class 3002、Logon Activity 1、Type UID 300201。OCSF 的优势是类型身份稳定、可机器校验，并将分类、对象和字段必要性绑定到 Event Class。[2]

SDM2.0 使用 AUTH_LOGIN、PROCESS_LAUNCH、NETWORK_CONNECTION 等可读类型，适合规则与产品展示，但事件清单、生成器映射、字段标准和生产契约之间存在演进差异。建议保留 SDM 可读事件类型，同时增加 OCSF 分类身份作为互操作投影，不将内部主查询契约绑定到某个 OCSF 版本。

### 3.3 角色和对象

OCSF 的对象细致且事件类特异。例如 Authentication 可包含 actor、user、src_endpoint、dst_endpoint、service 和 session；Process Activity 则关注 actor、process 及父进程关系。它在单个 Class 中精确，但通用实体遍历需要了解每个 Class 的字段布局。

SDM2.0 的五角色先回答“谁通过什么对谁做了什么”，再在角色中放置 User、Host、Process、File、IP、Domain 等对象，更适合统一时间线、实体跳转和行为链。这是 SDM2.0 不应被 OCSF 直接取代的核心原因。

五角色同样存在主观性：父进程是 source 还是 carrier，附件是 carrier、target 还是 related，必须由事件类型注册表给出机器可校验的唯一规则，不能只靠文档约定。

### 3.4 Finding 与告警运营

OCSF Findings Category 覆盖 Detection Finding 2004、Vulnerability Finding 2002、Compliance Finding 2003、Incident Finding 2005 等 Class。Detection Finding 可表达 Finding 基本信息、风险、置信度、Evidence Artifact、规则、攻击技术、受影响资源、状态和修复建议。[2]

SDM2.0 当前概念模型将来源产品告警摘要保存在 Event 的 source_alert 中，另外为平台统一 Alert 设计了六类对象：

~~~text
sdm_alert
├── sdm_alert_evidence
├── sdm_alert_entity
├── sdm_alert_attack_tag
├── sdm_analysis
└── sdm_workflow_action
~~~

这个方向正确：OCSF Finding 可作为“来源或检测引擎声称发现了什么”的事实与交换表达；SDM Alert 是聚合、去重、分派、研判、SLA、工单和 SOAR 处置的可变运营对象。OCSF Finding 不应直接替代 SDM Alert 六对象。

### 3.5 实体、Observable 与索引

OCSF 定义 Device、User、Process、File、Network Endpoint 等对象，并用 Observable 标记事件中的调查支点，但不保证不同厂商会为同一设备生成相同 UID，也不规定实体解析、存储和索引算法。该问题已有公开社区讨论。[9]

SDM2.0 S4 将 `sdm_event` 作为事件事实源，将物理派生表 `sdm_entity_event_index_mv` 作为实体 posting 索引，并定义实体 ID 版本、角色序号、主对端、水位、重建和查询回退。这属于存储服务契约，不属于 OCSF 职责，应继续保留。[I3]

### 3.6 存储与查询

OCSF 的实现中立性使它可以用于 JSON、Parquet、Iceberg、消息流或 API，但它不规定：

- 哪些字段物化为 Doris 顶层列；
- 事件与实体索引如何分区、分桶、刷新和重建；
- 实体时间线、一跳关系与详情回表如何路由；
- 查询性能、存储放大和派生延迟如何验收。

SDM2.0 已将这些问题纳入 S0/S1/S2/S3/S4 对比和业务查询 Benchmark。对 OCSF 的采用应停留在逻辑与交换层，不应将 Doris 主表直接替换为完整嵌套 OCSF JSON。[I4]

---

## 四、使用场景

| 场景 | OCSF | SDM2.0 | 建议 |
|---|---:|---:|---|
| 多厂商安全日志归一化 | 强 | 强 | 共享映射契约 |
| 对外数据交换/API | 强 | 弱 | 优先 OCSF |
| AWS Security Lake 等安全数据湖 | 强 | 需转换 | OCSF 投影 [5] |
| Datadog Cloud SIEM 内容兼容 | 强 | 需转换 | OCSF 投影 [6] |
| 内部事件列表与聚合 | 不规定实现 | 强 | 保留 S2/S4 |
| 实体时间线和一跳关系 | 提供对象基础 | 强 | 保留 SDM 实体 ID 和索引 |
| 行为链和调查视图 | 提供数据基础 | 强 | 保留 SDM 角色和 fieldset |
| 外部告警/Finding 归一 | 强 | 中 | 以 OCSF 完善 Source Finding |
| 告警分派、研判、工单和 SOAR | 中 | 强 | 保留 sdm_alert 系列 |

---

## 五、优缺点与社区反馈

### 5.1 OCSF 优势

1. **开放生态和厂商中立。** OCSF 已进入 Linux Foundation 治理，可降低封闭字段体系的长期对接成本。[1][4]
2. **安全类型和对象覆盖较广。** 1.8.0 包含 System Activity、Findings、IAM、Network、Discovery、Application、Remediation 等类别，以及 Cloud、Container、Host、Incident、Security Control 等 Profile。[2][3]
3. **字段契约完整。** Required、Recommended、Optional 和条件约束便于建立 Conformance 与数据质量报告。
4. **检测内容迁移基础更好。** 统一 Class、Activity 和 Object 后，规则和查询更容易跨来源复用。
5. **已有生产实践。** Amazon Security Lake 明确采用 OCSF；Datadog Cloud SIEM 已引入 OCSF Common Data Model，并映射 CloudTrail、Okta、GitHub 等数据源。[5][6]

### 5.2 OCSF 局限与社区反馈

> 以下来自公开 GitHub Issue 和贡献者讨论，反映实际实现问题与架构取舍，不等同于项目正式确认的缺陷清单。

| 问题 | 社区反馈 | 对 SDM2.0 的启示 |
|---|---|---|
| Schema 体积和数据放大 | 有实现者反馈转换后日志变大，提出 Slim 表达以降低存储与按量计费成本。[8] | 不在 Doris 主表完整物化 OCSF JSON |
| Finding 与触发 Activity 分离 | Cisco 等指出，改为 Finding 引用 Activity 后需生成 ID、管理多流并由消费者 JOIN；社区最终转向 Event Bundle 指引。[7] | 保留规范引用，同时提供查询友好的证据摘要或关联表 |
| 跨厂商实体归并 | Device uid 缺少统一生成约定，仍需组合 hostname、MAC、硬件 UUID、Agent ID 等判断同一设备。[9] | 保留 SDM 实体 ID 与归并服务 |
| 来源元数据边界 | 原始事件 source、type、format 与 product、logger、log_provider 边界存在讨论。[10] | 保留 log_type、原始 ID、转换链路和映射版本 |
| 前后状态表达不一致 | 文件、账号、实体和 Registry 中存在 x/x_result 与 prev_x/x 等模式。[11] | SDM 内统一 before/after，导出时按 Class 投影 |
| JSON 与列式时间类型 | timestamp_t 将时间语义与 epoch 毫秒编码绑定，进入 Parquet/Iceberg 后常需转为本地时间类型。[12] | Doris 使用 DATETIME(3)，仅在交换边界编码 |
| 多种合法表达 | Actor 与 process.parent、枚举 sibling、Extension/Profile 选择需要更强指引。[13][14] | 每个 SDM Event Type 只定义一种角色映射 |

### 5.3 SDM2.0 优势

1. 统一的五角色行为句式，适合跨类型时间线和行为链；
2. Event 与平台 Alert 边界清晰，证据引用不污染事件事实；
3. 已围绕 S2/S4 查询路径、实体 posting 和回表成本建模；
4. 适合中文 SOC、QAX 等存量兼容和产品调查视图；
5. 已定义实体时间线、关系扩展、原始回溯和行为链 Benchmark。

### 5.4 SDM2.0 局限

1. 对外生态弱，外部系统不会天然理解五角色和内部枚举；
2. 分类覆盖、字段必要性和 Profile 治理不及 OCSF；
3. carrier 有价值但映射主观，需要机器可读契约；
4. 当前 event_category=alert 混合了行为领域和记录性质两个维度；[I2][I5]
5. Benchmark 生成器按高严重度生成 RISKY outcome，混用了结果与风险语义；[I6]
6. extension 同时承载源私有字段、富化、ATT&CK、置信度和暂未物化语义，长期治理困难。[I5]

---

## 六、字段与模型改造建议

### 6.1 必须保留

- 保留 source、carrier、target、observer、related 五角色；
- 保留 S2 事实表与 S4 实体倒排的查询分工；
- 保留平台 sdm_alert、evidence、entity、attack tag、analysis 和 workflow；
- 保留 raw_log_ref、原始事件 ID 和映射前原值。

### 6.2 拆分事件领域与记录性质

| 字段 | 语义 | 示例 |
|---|---|---|
| record_kind | 活动、Finding、盘点/状态或修复 | ACTIVITY / FINDING / INVENTORY / STATE / REMEDIATION |
| event_domain | 安全行为领域 | SYSTEM / IDENTITY / NETWORK / APPLICATION / DISCOVERY / REMEDIATION |
| event_type | SDM 内部稳定类型 | AUTH_LOGIN / PROCESS_LAUNCH / NETWORK_CONNECTION |
| finding_type | Finding 类型 | DETECTION / VULNERABILITY / COMPLIANCE / INCIDENT |

兼容期双写旧 event_category 与新字段，但新规则、API 和索引不再使用 alert 覆盖行为领域。

### 6.3 将来源告警升级为 Source Finding

建议保留 source_alert 兼容读取，新增一等 Source Finding：

~~~json
{
  "finding_id": "vendor-alert-id",
  "finding_type": "DETECTION",
  "activity": "CREATE",
  "title": "Reverse Shell",
  "severity": "CRITICAL",
  "risk_score": 92,
  "confidence_score": 85,
  "status": "NEW",
  "rule": {
    "id": "rule-101",
    "name": "Reverse Shell Detection",
    "version": "3"
  },
  "affected_entities": [],
  "evidence_refs": [],
  "attacks": [],
  "remediation": {}
}
~~~

每个源模板增加 mapping_mode：

| 模式 | 条件 | 输出 |
|---|---|---|
| ACTIVITY | 原始记录是可验证行为事实 | Activity Event |
| FINDING | 只有检测结论，无完整行为事实 | Source Finding |
| ACTIVITY_WITH_FINDING | 单条记录同时含完整事实和结论，且需保持单记录 | Activity 携带 Finding 摘要 |
| SPLIT | 需独立查询行为与 Finding | Activity + Finding，Finding 引用 Activity |

默认优先 SPLIT，但只在原始数据足以证明行为时生成 Activity；不得从告警描述中推断出伪事实。

### 6.4 拆分结果、严重度、风险与置信度

| 字段 | 语义 | 推荐值 |
|---|---|---|
| outcome | 动作是否成功 | SUCCESS / FAILURE / PARTIAL / UNKNOWN |
| status | 事件或 Finding 状态 | 按类型契约定义 |
| action | 安全控制采取的动作 | ALLOW / BLOCK / QUARANTINE / ALERT |
| severity / severity_id | 处理紧急程度 | UNKNOWN / INFORMATIONAL / LOW / MEDIUM / HIGH / CRITICAL |
| risk_score / risk_level | 综合风险 | 0-100 + 等级 |
| confidence_score / confidence | 检测准确性 | 0-100 + 等级 |
| log_level | 源日志输出等级 | syslog 或来源原值 |
| source_severity | 来源严重度原值 | 原样保留 |

RISKY 不再属于 outcome。例如高风险登录失败应表示为 outcome=FAILURE、risk_level=HIGH。

### 6.5 增加 OCSF 分类投影

~~~text
ocsf_version
ocsf_category_uid
ocsf_class_uid
ocsf_activity_id
ocsf_type_uid
ocsf_profiles
ocsf_mapping_version
ocsf_mapping_status
~~~

mapping_status 至少包含 FULL、PARTIAL、UNMAPPED、INVALID。OCSF 字段用于交换、规则迁移和质量治理，不替代 SDM event_type 与五角色查询。

### 6.6 建立机器可读事件注册表

~~~yaml
event_types:
  AUTH_LOGIN:
    record_kind: ACTIVITY
    event_domain: IDENTITY
    operation: LOGON
    ocsf:
      version: 1.8.0
      category_uid: 3
      class_uid: 3002
      activity_id: 1
      type_uid: 300201
    required:
      - metadata.event_id
      - metadata.occur_time
      - target.user
    conditional_any:
      - target.service
      - target.endpoint
    role_mapping:
      source: [actor, src_endpoint]
      carrier: [auth_protocol, session]
      target: [user, service, dst_endpoint]
      observer: [metadata.product, metadata.reporter]
~~~

由该注册表生成或验证 Catalog、Generator、Parser、DDL 约束、文档、UI 枚举、OCSF 导出和测试，避免在多处手工重复维护。

### 6.7 治理扩展数据

~~~json
{
  "extensions": {
    "sdm.security": {},
    "sdm.cloud": {},
    "sdm.container": {},
    "vendor.example": {}
  },
  "enrichments": [],
  "unmapped": {},
  "labels": [],
  "tags": {}
}
~~~

- extensions：有名称空间、Schema 和版本的扩展；
- enrichments：带来源和时间的资产、情报、地理、身份富化；
- unmapped：尚无标准语义的来源字段，不用于标准规则；
- labels/tags：检索和产品标签，不承载业务对象。

### 6.8 区分 Entity、Observable 与 Indicator

| 概念 | 定义 | SDM2.0 处理 |
|---|---|---|
| Entity | 可归并、有稳定身份和生命周期 | 生成 S4 posting |
| Observable | 事件中可查询和跳转的值 | 从规范路径派生，不必全部实体化 |
| Indicator | 带威胁判断、置信度和来源的情报指标 | 指向实体，不与实体本身混合 |

### 6.9 补齐时间与追溯

在 occur_time、ingest_time、parse_time 之上补齐：

~~~text
start_time / end_time / duration_ms / count
original_time / timezone_offset
schema_version / mapping_id / mapping_version
parser_version / transformation_history
original_event_id / correlation_uid
raw_data_hash / raw_data_size / is_truncated
~~~

物理存储继续使用 Doris 本地时间类型，在 OCSF 输入/输出边界做编码转换。

---

## 七、关键类型映射

> 最终 Activity ID 和必要字段必须由锁定的 OCSF 1.8.0 机器可读 Schema 生成，不在解析代码中手工重复维护。

| SDM 类型/场景 | OCSF Category / Class | 映射要点 |
|---|---|---|
| AUTH_LOGIN | IAM / Authentication 3002 | Logon；Actor/Source Endpoint → source，协议/会话 → carrier，User/Service/Destination → target |
| AUTH_LOGOUT | IAM / Authentication 3002 | Logoff；保留会话 ID |
| PROCESS_LAUNCH | System / Process Activity 1007 | Actor/Parent Process 必须由 SDM 契约规定唯一映射 |
| PROCESS_TERMINATE | System / Process Activity 1007 | 被终止进程 → target，发起者 → source/carrier |
| FILE_CREATE/MODIFY/DELETE | System / File System Activity 1001 | 进程 → carrier，文件 → target，明确 before/after |
| NETWORK_CONNECTION/FLOW | Network / Network Activity 4001 | 按建立、关闭、失败或流量区分 Activity |
| HTTP_REQUEST/RESPONSE | Network / HTTP Activity 4002 | 单事件或分事件由源契约决定 |
| DNS_QUERY | Network / DNS Activity 4003 | Query 域名 → target，响应 IP → related/observable |
| EMAIL_SEND/RECEIVE | Network / Email Activity 4009 | 发件人 → source，邮件/附件/会话 → carrier，收件人 → target |
| 用户增删改 | IAM / Account Change 3001 或 Entity Management 3004 | 按对象类型选择 Class |
| 恶意软件/入侵/IOC 检测 | Findings / Detection Finding 2004 | 默认作为 Finding；触发 Activity 单独引用 |
| 漏洞扫描执行 | Application / Scan Activity 6007 | 表达扫描行为 |
| 漏洞扫描结果 | Findings / Vulnerability Finding 2002 | 表达发现并引用受影响资源 |
| 合规问题 | Findings / Compliance Finding 2003 | 保留标准、控制项、结果和证据 |
| 平台告警/案件导出 | Detection Finding 2004 / Incident Finding 2005 | 仅作交换快照 |
| 文件隔离/删除 | Remediation / File Remediation Activity 7002 | 区分建议修复和已执行修复 |

---

## 八、目标架构

### 8.1 一次解析，双投影

~~~text
                          ┌── OCSF 交换投影
                          │      ├── 对外 API / Export
                          │      ├── AWS Security Lake
原始日志 → 解析与语义映射 ─┤      └── 第三方 SIEM / Datadog
                          │
                          └── SDM 内部投影
                                 ├── S2 事件事实
                                 ├── S4 实体索引
                                 ├── Detection / Correlation
                                 └── Alert / Investigation / Workflow
~~~

同一份源映射契约产生两个投影，保证枚举转换、来源身份、原始引用和映射版本一致。避免维护两套独立解析逻辑，也避免将 OCSF 作为有损中间格式再转换成 SDM。

### 8.2 Finding 与平台 Alert

~~~text
外部产品告警 / SDM 检测引擎
                ↓
      OCSF-compatible Source Finding
                ↓ evidence references
           SDM Event / Raw Log
                ↓ aggregate / deduplicate / correlate
           SDM Platform Alert
                ↓
   Analysis / Workflow / Case / SOAR
~~~

Source Finding 可直接投影为 OCSF Detection Finding；平台 Alert 或 Case 可按交换场景投影为 Detection Finding 或 Incident Finding 快照，但内部 workflow 历史仍保留在 SDM Alert 模型。

---

## 九、迁移路线

### P0：修正核心语义

1. 定义 record_kind、event_domain、finding_type，保留旧 event_category 双写；
2. 停止新映射使用 event_category=alert 覆盖行为领域；
3. 修正 outcome 与 severity/risk 的混用；
4. 为现有 Template Catalog 标注 mapping_mode、目标类型和事实字段充分性；
5. 对现有规则、API 和查询建立兼容视图，不立即删除旧字段。

### P1：建立 OCSF 兼容契约

1. 固定 OCSF 1.8.0 为首个支持版本，不使用 dev Schema；
2. 建立 Event Type Registry，定义 Class/Activity、角色映射、必要性和 Golden Sample；
3. 增加 OCSF 身份、映射版本和映射状态；
4. 增加 Source Finding 与 Event-to-Finding Evidence Relation；
5. 建立 OCSF Import/Export Validator；
6. 为 S2/S4 增加必要高频列，并按分区重建受影响 posting。

### P2：扩展生态和调查能力

1. 按实际数据源逐步引入 Cloud、Container、Host、Incident、Security Control Profile；
2. 增加 Observable 投影，保持与 Entity posting 的边界；
3. 实现 AWS Security Lake、Datadog 等下游端到端验证；
4. 建立 OCSF 版本升级评估、映射 Diff、双读/双写和重建机制。

### 9.1 兼容原则

- 新老字段双写，规则、API、UI 和 Benchmark 切换前不删除旧字段；
- 分类、角色、实体 ID 或 peer 规则变化时按分区重建；
- 双写期同时运行新旧查询，比较事件集、告警集和结果差异；
- OCSF 映射失败标记 PARTIAL/UNMAPPED，保留原始证据，不丢弃数据；
- OCSF 投影故障不应成为 S2 入库与 S4 内部查询的单点故障。

---

## 十、验收指标

| 类别 | 指标 | 建议口径 |
|---|---|---|
| 映射覆盖 | 有版本映射的源模板比例 | 纳入 Pilot 的模板 100% |
| 映射成功 | FULL + PARTIAL 占比 | 分数据源报告，不用全局平均掩盖弱源 |
| 必填覆盖 | Required/Conditional 满足率 | FULL 事件 100%，否则降级 |
| Schema 一致性 | OCSF Validator 通过率 | FULL 导出事件 100% |
| 语义正确性 | Golden Sample 和人工评审 | 覆盖成功、失败、Other/Unknown、缺字段 |
| 查询正确性 | 新旧查询事件 ID 集差异 | 非预期差异为 0 |
| Finding 证据 | Finding 到 Event/Raw Log 可回溯率 | 有证据声明的 Finding 100% |
| 存储成本 | OCSF 投影与 S2/S4 字节放大 | 按源、每百万事件报告 |
| 查询性能 | B01-B12 p50/p95/max、错误率 | 回退查询不计作新索引命中 |
| 派生一致性 | S2 事件与 S4 posting 差异 | posting multiset 等价，水位可观测 |

---

## 十一、风险与缓解

| 风险 | 表现 | 缓解 |
|---|---|---|
| 双模型漂移 | SDM 与 OCSF 由不同代码维护 | 同一机器可读源映射产生双投影 |
| OCSF 版本演进 | Class/Object/Profile 变化影响历史 | 固定 1.8.0，升级走显式 Change |
| 数据放大 | 嵌套对象、枚举 sibling 和双投影增加成本 | 交换投影与 Doris 服务列分离 |
| Finding/Activity 关联丢失 | 无法回答触发告警的行为 | 稳定 ID、Evidence Relation 与 Bundle 同时设计 |
| 告警伪造成行为 | 从检测结论推断 source/target | mapping_mode 控制，证据不足只产 Finding |
| 旧规则和 UI 破坏 | 依赖 event_category=alert | 双写、兼容视图和分阶段切换 |
| 推断关系污染实体图 | 可疑攻击者被当成已观察 source | posting 标注 OBSERVED/REPORTED/INFERRED，默认优先 OBSERVED |

---

## 十二、告警字段字典与三方对比

### 12.1 口径与当前状态

| 对象 | 本节基线 | 权威来源 | 字段规模 | 状态说明 |
|---|---|---|---:|---|
| OCSF Detection Finding | OCSF 1.8.0、Category 2、Class 2004 | OCSF Schema Browser | 50 个顶层字段，其中 Required 8、Recommended 10、Optional 32 | 正式外部 Schema [15] |
| 大禹/QAX 告警标准 | `QAX-告警数据标准v.1.6.3.xlsx`，2025-01-07 | `告警数据标准` 工作表 | 496 个字段，其中标记必填 45 | 存量产品兼容标准 [I7] |
| SDM2.0 告警 | 当前工作树 DDL 和字段标准草案 | `010_sdm_alert.sql`、`011_sdm_alert_evidence.sql` | `sdm_alert` 49 字段，`sdm_alert_evidence` 21 字段 | 两张 MVP 表已有 DDL；entity/attack_tag/analysis/workflow 仍是后续草案 [I8][I9] |

> 大禹工作表还包含 ClickHouse、PostgreSQL、ES 类型、责任方、示例、使用情况和编码表。本节提取完整分组、全部必填字段和对比所需的关键可选字段；496 字段的逐行类型、描述、示例和码值仍以原工作簿为唯一权威源，避免文档副本与 Excel 演进分叉。

### 12.2 OCSF Detection Finding 顶层字段

OCSF 的 `Required` 是 Schema 有效性底线，`Recommended` 是常规互操作应提供的字段，`Optional` 不代表无价值。字符串 sibling（如 `severity`）通常是数字枚举（如 `severity_id`）的文本表达，不应被当成两个独立业务字段。[15]

#### 12.2.1 分类、身份与主内容

| OCSF 字段 | 必要性 | 类型 | 定义/关键枚举 |
|---|---|---|---|
| `activity_id` / `activity_name` | Required / Optional | Integer / String | Finding 活动：0 Unknown、1 Create、2 Update、3 Close、99 Other |
| `category_uid` / `category_name` | Required / Optional | Integer / String | 类别固定为 2 / Findings |
| `class_uid` / `class_name` | Required / Optional | Integer / String | 事件类固定为 2004 / Detection Finding |
| `type_uid` / `type_name` | Required / Optional | Long / String | `class_uid * 100 + activity_id`：200400/200401/200402/200403/200499 |
| `severity_id` / `severity` | Required / Optional | Integer / String | 处理与解决所需成本：0 Unknown、1 Informational、2 Low、3 Medium、4 High、5 Critical、6 Fatal、99 Other |
| `finding_info` | Required | Finding Information | Finding 唯一 ID、标题、分析技术、首末次发现时间、ATT&CK、来源产品等支撑信息 [16] |
| `metadata` | Required | Metadata | OCSF 版本、产品、租户、来源、Profile、原始 ID、处理链路等交换元数据 |
| `message` | Recommended | String | 来源定义的事件/Finding 描述 |
| `comment` | Optional | String | 用户评论 |
| `is_alert` | Recommended | Boolean | 当前活动是否是需要告警的信号；Finding 不必然等于当前可告警状态 |

#### 12.2.2 评分、状态与时间

| OCSF 字段 | 必要性 | 类型 | 定义/关键枚举 |
|---|---|---|---|
| `confidence_id` / `confidence` | Recommended / Optional | Integer / String | 规则准确性：0 Unknown、1 Low、2 Medium、3 High、99 Other |
| `confidence_score` | Optional | Integer | 来源报告的置信分；Schema 没有在字段说明中强制 0-100 |
| `impact_id` / `impact` | Optional | Integer / String | 预期危害幅度：0 Unknown、1 Low、2 Medium、3 High、4 Critical、99 Other |
| `impact_score` | Optional | Integer | 影响分，有效范围 0-100 |
| `risk_level_id` / `risk_level` | Optional | Integer / String | 风险等级：0 Info、1 Low、2 Medium、3 High、4 Critical、99 Other |
| `risk_score` / `risk_details` | Optional | Integer / String | 来源风险分与风险说明 |
| `status_id` / `status` | Recommended / Optional | Integer / String | 由消费方设置：0 Unknown、1 New、2 In Progress、3 Suppressed、4 Resolved、5 Archived、6 Deleted、99 Other |
| `status_code` | Recommended | String | 来源报告的原始状态码 |
| `status_detail` | Recommended | String | 状态或结果的详细说明 |
| `vendor_attributes` | Optional | Vendor Attributes | 消费方修改了 severity 等可变字段时，保留厂商原值；原始生产者不填 |
| `time` | Required | Timestamp | 归一化事件发生时间或 Finding 创建时间 |
| `timezone_offset` | Recommended | Integer | 相对 UTC 的分钟偏移，-1080 至 +1080 |
| `start_time` / `end_time` | Optional | Timestamp | Finding 所包含事件的最早/最近时间 |
| `duration` | Optional | Long | `start_time` 至 `end_time` 的毫秒数 |
| `count` | Optional | Integer | 该时间范围内同一逻辑组的事件数 |

#### 12.2.3 证据、对象与追溯

| OCSF 字段 | 必要性 | 类型 | 定义 |
|---|---|---|---|
| `evidences` | Recommended | Evidence Artifacts Array | 触发检测的结构化证据，可含 actor/API/网络连接/端点/文件/进程/DNS/HTTP/注册表等 [17] |
| `observables` | Recommended | Observable Array | 事件中可调查、查询和跳转的属性指针/值 |
| `resources` | Recommended | Resource Details Array | 受影响资源，其 `role_id` 可表达 Target/Actor/Affected/Related |
| `device` | Optional | Device | 受影响设备/主机，可与 `resources` 同时使用 |
| `anomaly_analyses` | Optional | Anomaly Analysis Array | 正常基线、偏离与异常分析 |
| `malware` / `malware_scan_info` | Optional | Malware Array / Malware Scan Info | 恶意软件与扫描作业信息 |
| `vulnerabilities` | Optional | Vulnerability Details Array | 与 Detection Finding 相关的漏洞 |
| `remediation` | Optional | Remediation | 修复描述、CIS Control、KB/补丁和参考链接 |
| `enrichments` | Optional | Enrichment Array | 外部数据源对事件/Finding 的富化 |
| `raw_data` | Optional | String | 收到的原始事件/Finding 载荷 |
| `raw_data_hash` / `raw_data_size` | Optional | Fingerprint / Long | 原始数据指纹与字节数 |
| `unmapped` | Optional | Object | 暂无 OCSF 标准语义的来源字段 |

### 12.3 OCSF 关键嵌套对象

#### 12.3.1 `finding_info`

| 字段 | 必要性 | 类型 | 定义与 SDM 对应 |
|---|---|---|---|
| `uid` | Required | String | 来源 Finding 唯一 ID；对外导出对应 `alert_id` 或 `source_alert_id` |
| `title` | Recommended | String | Finding 标题；对应 `alert_name` |
| `analytic` | Recommended | Analytic | 检测分析技术；`uid/name/version/type_id` 对应 SDM `rule_id/rule_name/rule_version/rule_type` [18] |
| `desc` | Optional | String | Finding 描述；对应 `description` |
| `created_time` / `modified_time` | Optional | Timestamp | Finding 创建/修改时间；对应 `created_time/updated_time` |
| `first_seen_time` / `last_seen_time` | Optional | Timestamp | 首次/最近发现；对应 `first_seen/last_seen` |
| `data_sources` | Optional | String Array | 产生 Finding 使用的数据源；不完全等于生产产品 |
| `product` | Optional | Product | 报告 Finding 的产品；与 `metadata.product` 的转换产品语义分开 |
| `attacks` | Optional | Attack Array | MITRE ATT&CK/ATLAS 战术、技术、子技术、缓解和版本 |
| `kill_chain` | Optional | Kill Chain Phase Array | Cyber Kill Chain 阶段 |
| `related_events` / `related_events_count` | Optional | Array / Integer | 关联事件/Finding 及数量；这些事件不一定是 OCSF |
| `related_analytics` | Optional | Analytic Array | 其他相关检测/分析 |
| `attack_graph` | Optional | Graph | 资源、Finding 与可能攻击路径的图 |
| `src_url` | Optional | URL String | OCSF 可返回来源 Finding URL；SDM 不将其纳入标准字段，来源链接如确有需要放入 `extensions` |
| `tags` / `traits` / `types` | Optional | Array | 标签、特征和来源 Finding 类型 |
| `uid_alt` | Optional | String | 备选 Finding ID |
| `product_uid` | Deprecated | String | 1.4.0 起废弃，改用 `product.uid` |

#### 12.3.2 `evidences`

`evidences[]` 的结构化证据字段包括 `actor`、`api`、`connection_info`、`container`、`database`、`databucket`、`device`、`src_endpoint`、`dst_endpoint`、`email`、`file`、`process`、`query`、`http_request`、`http_response`、`reg_key`、`reg_value`、`resources`、`script`、`tls`、`url`、`user`、`win_service`、`job`、`ja4_fingerprint_list` 和兼容容器 `data`。每个证据还可带 `uid`、`name`、`verdict_id/verdict`。条件约束要求 actor/API/连接/数据/数据库/数据桶/设备/端点/邮件/文件/作业/进程/DNS/注册表/脚本/URL/用户/Windows Service 中至少一项存在。[17]

OCSF Evidence Artifact 是内联证据快照，SDM `sdm_alert_evidence` 是可分区、可排序、可回表的证据关系。映射时建议：

| OCSF | SDM2.0 | 映射判断 |
|---|---|---|
| `evidences[].uid` | `evidence_id` | 直接映射，若来源无 ID 则按映射版本稳定生成 |
| Evidence 对象 | `event_id` / `log_id` / `external_ref` | OCSF 内联快照不能替代 SDM 的原始证据引用 |
| `verdict_id/verdict` | `sdm_alert_evidence.confidence` 不可直接映射 | verdict 是证据研判结论，confidence 是置信度；SDM 当前证据表缺少 evidence verdict |
| 数组顺序 | `chain_id/sequence_no/parent_evidence_id` | SDM 可表达调查链和父子证据，属于 OCSF 顶层数组没有的内部运营能力 |

### 12.4 大禹/QAX 告警字段定义

#### 12.4.1 全量字段分组

| 字段组 | 字段数 | 必填数 | 设计特征 |
|---|---:|---:|---|
| 基础信息 | 38 | 15 | ID、归并、名称、分类、严重度、来源、规则、处置建议 |
| 时间信息 | 10 | 8 | 首末告警/入库/日志时间、持续时间、处置时间 |
| 攻击者及地理/资产 | 38 | 0 | attacker 大宽表字段 |
| 受害者及地理/资产 | 46 | 0 | victim 大宽表字段 |
| 源 IP 及地理/资产 | 33 | 1 | `sip*`、源用户、NAT、安全域 |
| 目的 IP 及地理/资产 | 32 | 0 | `dip*`、目的用户、NAT、安全域 |
| 多租户/云/集群 | 18 | 0 | 日志来源租户、VXLAN、云资产、集群列表 |
| 状态信息 | 24 | 11 | 阅读、处置、上传、工单、研判、告警、失陷、转事件/通报 |
| 处置信息 | 17 | 1 | 处置序列、研判人、附件、操作历史、AI 研判 |
| 关联信息 | 14 | 3 | 规则、工单、资产、日志类型、事件列表 |
| IOC / 漏洞 | 16 | 0 | IOC 值/类型/状态，CVE/CNVD/CNNVD 和漏洞修复 |
| 协议/攻击信息 | 24 | 5 | 应用/传输/工控协议、风险、结果、Kill Chain、ATT&CK |
| 结构化证据 | 146 | 1 | 载荷、PCAP、HTTP、DNS、文件、进程、注册表、邮件、数据库等平铺字段 |
| 扩展/保留 | 40 | 0 | 21 个 `extend_fields*` 与 19 个 `reserve_fields*` |
| **合计** | **496** | **45** | 产品存储、展示、调查和运营语义合并在一张大宽表 |

#### 12.4.2 45 个标记必填的字段

| 大禹字段 | 中文名 | CK / PG 类型 | 定义摘要 | SDM2.0 去向 |
|---|---|---|---|---|
| `alert_seq` | 告警序列 | string / varchar | 用户可见唯一序列，支持跨模块跳转 | `alert_display_id` |
| `alert_id` | 告警编号 | string / varchar | 告警唯一标识 | `alert_id`；外部告警则 `source_alert_id` |
| `merge_id` | 归并编号 | string / varchar | 按关联规则与策略生成的逻辑归并 ID | `merge_id` |
| `alert_name` | 告警名称 | string / varchar | 默认规则名，可富化或自定义 | `alert_name` |
| `alert_cat_level1_cd/name` | 一级分类代码/名称 | string / varchar | 大禹一级告警分类 | `category_code/name` |
| `alert_cat_level2_cd/name` | 二级分类代码/名称 | string / varchar | 大禹二级告警分类 | 不复制到平台告警；通过 `evidences[].event_id` 回查来源事件 |
| `confidence` | 置信度 | string / varchar | 告警可信度 | 枚举转换后写 `confidence` 0-100，保留原值 |
| `severity` | 危害等级 | string / varchar | 告警严重程度 | 枚举转换后写 `severity` |
| `alert_src` | 告警来源 | string / varchar | 1.6 已废弃，被 `alert_src_list` 替代 | 只作兼容输入 |
| `alert_src_list` | 告警来源列表 | Array(string) / jsonb | 可存多个告警来源 | `source_systems` |
| `alert_detect_method_cd` | 发现手段代码 | string / varchar | 检测手段编码 | `rule_type/detection_engine` 的映射输入 |
| `disposal_advice` | 处置建议 | string / varchar | 基于规则和研判依据配置 | 当前无专用列，建议结构化 remediation |
| `is_emphasis_attention` | 是否重点关注 | String / varchar | 记录是否重点关注 | 告警标签/优先级扩展，不等于 severity |
| `first_alert_time` / `latest_alert_time` | 首次/最新告警时间 | DateTime64(3) / timestamp | 归并告警观测时间范围 | `first_seen/last_seen` |
| `first_insert_time` / `latest_insert_time` | 首次/最新入库时间 | DateTime64(3) / timestamp | 告警创建与最后入库时间 | `created_time/updated_time` |
| `log_start_time` / `log_end_time` | 日志起始/结束时间 | DateTime64(3) / timestamp | 触发告警的日志最小/最大时间 | `first_seen/last_seen`；原值不一致时保留在 `extensions.source_time_range` |
| `update_time` | 更新时间 | DateTime64(3) / timestamp | 任一告警字段变更的时间 | `updated_time`，需定义与 latest_insert 的优先级 |
| `ip_direction` | IP 方向 | string / varchar | 源 IP 到目的 IP 的关系映射 | 拆入 Alert Entity/SDM Event，不进主表 |
| `read_status_cd` | 阅读状态 | String / varchar | 1 已读，2 未读 | 用户级 UI 状态，不进全局 Alert 主契约 |
| `dispose_status_cd` | 处置状态 | String / varchar | 待处置/处置中/不处置/误报/已处置 | `disposition_status`，误报需同时映射 `verdict` |
| `upload_status_cd` | 级联同步状态 | string / varchar | 0 未上传，1 已上传 | 集成传输状态，不进 Alert 业务状态 |
| `ticket_status_cd` | 工单状态 | String / varchar | 未关联/待下发/处置中/已撤销/已处置 | `ticket_status` |
| `alert_status_cd` | 告警状态 | String / varchar | 未研判/未处理/已处理/无需处理 | 非单值直映射，需拆到 `workflow_status` + `verdict` |
| `is_from_external` | 是否外部威胁 | String / varchar | 攻击者是否在客户网段外 | Alert Entity/富化属性 |
| `compromise_status_cd` | 失陷状态 | String / varchar | 受害者是否已失陷 | `extensions.qax_compromise_status_cd`；后续可进入受害实体或资产状态模型 |
| `sub_unit_id` | 下级区域编号 | string / varchar | 级联管理区域 | 租户/组织兼容层 |
| `event_status_cd` | 转事件状态 | String / varchar | 1 已转事件，2 未转事件 | 建议转换为 `incident_ids` 关联事实 |
| `notify_status_cd` | 转通报状态 | String / varchar | 1 已转通报，2 未转通报 | 通报子系统状态，不进通用告警核心 |
| `is_ignore` | 是否忽略 | String / varchar | 0 否，1 是 | 映射 `workflow_status=SUPPRESSED` 前需确认业务原因 |
| `dispose_seq` | 处置序列 | string / varchar | 辅助告警归并的标识 | `merge_id/dedup_key` 映射输入，保留原值 |
| `relevant_rule_id/name` | 关联规则 ID/名称 | string / varchar | 触发告警的规则 | `rule_id/rule_name` |
| `killchain` | 攻击链阶段 | string / varchar | 告警所处攻击链阶段 | `sdm_alert_attack_tag` 草案；OCSF `finding_info.kill_chain` |
| `alert_count` | 告警次数 | Int32 / int2 | 原始告警归并数量 | `event_count` |
| `attack_count` | 攻击次数 | Int32 / int8 | 告警内攻击行为全量累加数 | 当前无专用列，不应无条件等同 `event_count` |
| `attack_method` | 攻击方法 | string / varchar | 告警使用的攻击方法 | 分类/attack tag 映射输入 |
| `attack_result_cd` | 攻击结果 | String / varchar | 不涉及/成功/企图/失陷/拦截/未知 | 不能只写 `verdict`；拆成 Activity outcome/action 与 Alert compromise/verdict |
| `batch_no` | 批次号 | string / varchar | 监控接入批次数据丢失 | 采集/映射元数据，不进 Alert 业务核心 |
| `relevant_incident_id_list` | 关联事件 ID 列表 | Array(string) / jsonb | 告警关联的事件/案件列表 | `incident_ids` |

> 工作表将已废弃的 `alert_src` 和替代它的 `alert_src_list` 都标为 Y，所以不能将“45 个 Y”等同为新建数据的 45 个同时必填列。导入契约必须结合版本、废弃标记和条件约束生成，不能只读 Y/N 列。

#### 12.4.3 重要可选字段与对象去向

| 大禹字段簇 | 代表字段 | SDM2.0 去向 | OCSF 去向 |
|---|---|---|---|
| 研判与流转 | `verify_status_cd`、`verify_*`、`ai_verify_*`、`op_list` | `sdm_analysis/workflow` 草案 | `status_id`、`comment`、Incident Profile；不宜全部塞入 Detection Finding |
| 规则/检测 | `rule_id/name/version/status`、`relevant_rule_*` | 主表 `rule_*` | `finding_info.analytic.*`，不是一般 `rule` 对象 |
| ATT&CK | `mitre_tactics_cd`、`mitre_tech_cd`、`att_ck_id` | `sdm_alert_attack_tag` 草案 | `finding_info.attacks[]` |
| IOC | `ioc_value/type/status_cd/release_time` | Alert Entity/Indicator 子对象 | `observables[]` 或威胁情报对象，不应只用字符串 |
| 漏洞 | `vuln_name`、`cve_id`、`vuln_solution` | 证据/关联漏洞 | `vulnerabilities[]`；以漏洞为主体时应转 Vulnerability Finding 2002 |
| 网络证据 | `sip/dip`、`http_req_url`、`dns_*`、`pcap_packet` | SDM Event + `sdm_alert_evidence` 引用 | `evidences[].src_endpoint/dst_endpoint/http_request/query/data` |
| 主机证据 | `file_*`、`process_*`、`reg_*` | SDM Event + Evidence + Entity | `evidences[].file/process/reg_key/reg_value` |
| 影响资源 | `victim_*`、资产、云、集群字段 | 主表 `victim_*` 查询投影 + `sdm_alert_entity` 草案；`primary_entity_id/type` 当前为 `NULL` | `resources[]`、`device` |
| 攻击方 | `attacker_*` | Alert Entity role=attacker 草案 | `resources[].role_id=Actor` 或 Evidence actor/src_endpoint，按语义选择 |
| 日志引用 | `log_id_list`、`relevant_log_type` | 逐条写 `sdm_alert_evidence.event_id/log_id` | `finding_info.related_events[]` 或 Bundle 关联，不只保留类型列表 |
| 扩展/保留 | `extend_fields*`、`reserve_fields*`、`proof_info` | 拆分 `extensions/enrichments/unmapped` | 有 Schema 的进 Extension/Profile，富化进 `enrichments`，其余进 `unmapped` |

### 12.5 OCSF、大禹与 SDM2.0 核心映射

| 语义 | OCSF 1.8.0 | 大禹/QAX 1.6.3 | SDM2.0 当前 | 覆盖判断 |
|---|---|---|---|---|
| 平台告警 ID | `finding_info.uid` | `alert_id` | `alert_id` | 直接；外部 ID 不得覆盖 SDM ID |
| 展示序列 | `finding_info.uid_alt` 可候选 | `alert_seq` | `alert_display_id` | 大禹→SDM 直接；OCSF 无完全等价专用字段 |
| 归并 ID | `metadata.correlation_uid` 或扩展 | `merge_id` | `merge_id` | 部分；correlation 不必然等于归并 |
| 标题/描述 | `finding_info.title/desc`、`message` | `alert_name/alert_desc` | `alert_name/description/summary` | 直接，但需定义 desc/message/summary 优先级 |
| 行业分类 | `category_uid/class_uid/activity_id/type_uid` | 无 | 无物理列 | **SDM 缺口**；建议作 OCSF 映射投影 |
| 大禹告警分类 | 可放 `finding_info.types/tags` 或扩展 | `alert_cat_level1/2_*` | `category_code/name` + 证据事件回查 | 平台分类只使用 UDM；QAX 一二级原值不复制到告警 `extensions` |
| 生成类型 | `finding_info.analytic.type_id` | `alert_detect_method_cd` | `alert_type/rule_type` | 部分；三方枚举粒度不同 |
| 严重度 | `severity_id/severity` | `severity` | `severity` | 直接但必须走版本化枚举表 |
| 置信度 | `confidence_id/score` | `confidence` | `confidence` | 部分；大禹枚举需转 0-100 并保留原值 |
| 风险 | `risk_level_id/risk_score/details` | `attack_risk` | `risk_score` | 部分；大禹字段仅定义于特定工控场景 |
| 影响 | `impact_id/impact_score` | 无统一字段 | 无 | **SDM/大禹缺口**；不应用 severity 替代 |
| 生命周期 | `activity_id`、`status_id` | `alert_status_cd` | `workflow_status` | 部分；OCSF 活动与当前状态是两个维度 |
| 处置/研判/工单 | Incident Profile/外部工作流 | 多组状态字段 | `disposition_status/ticket_status/verdict` | **SDM 内部运营更强**，不强行压成 OCSF `status_id`；大禹失陷状态保留在扩展或实体层 |
| 创建/更新 | `finding_info.created_time/modified_time` | insert/update 时间 | `created_time/updated_time` | 直接，需统一多个大禹更新时间的优先级 |
| 首次/最近观测 | `finding_info.first_seen_time/last_seen_time`、`start/end_time` | first/latest alert、log start/end | `first_seen/last_seen` | 统一为告警命中证据时间范围；原始不一致值进扩展字段 |
| 持续时间 | `duration` 毫秒 | `duration` 秒 | `last_seen - first_seen` | 直接，查询层派生，不落告警主表 |
| 计数 | `count` | `alert_count/attack_count` | `event_count` | 部分；必须定义计数对象 |
| 规则/分析 | `finding_info.analytic.*` | `rule_*`、`relevant_rule_*` | `rule_id/name/version/type/detection_engine` | 基本覆盖；SDM 还需补 analytic algorithm/category 的扩展映射 |
| 来源产品 | `metadata.product`、`finding_info.product`、`metadata.reporter/source` | `alert_src_list`、设备/节点 | `source_systems/detection_engine` | 部分；当前 SDM 缺少产品、报告者、转换者的分层元数据 |
| 受影响资源 | `resources[]/device` | `victim_*`、资产/云/集群 | 主表 `victim_*`；`primary_entity_id/type=NULL`；`sdm_alert_entity` 草案 | **MVP 部分覆盖**；子表未落地前不能宣称全量兼容 |
| 攻击者/行为者 | Evidence actor/src_endpoint 或 Resource Actor | `attacker_*`、`sip*` | `sdm_alert_entity` 草案；事件五角色 | 部分；不得把“来源报告的攻击者”冒充已观测 Activity source |
| 证据 | `evidences[]`、`related_events[]` | 146 个平铺证据字段、`log_id_list` | 主表 `evidences[].event_id` + `sdm_alert_evidence` 21 字段 | 单表阶段顶层保留事件 ID，后续展开为关系表；导出 OCSF 时组装内联快照和关联 ID |
| Evidence verdict | `evidences[].verdict_id` | `verify_status_cd` 等间接字段 | 无 | **SDM 缺口**；需增加证据结论，不能复用 evidence confidence |
| Observable | `observables[]` | IOC 和大量 IP/文件/进程字段 | 事件实体索引，Alert 无专用对象 | **SDM Alert 缺口**；Observable 不应全部实体化 |
| ATT&CK/Kill Chain | `finding_info.attacks/kill_chain` | `mitre_*`、`att_ck_id`、`killchain` | `sdm_alert_attack_tag` 草案 | 草案可覆盖，当前 DDL 未落地 |
| 修复建议 | `remediation` | `disposal_advice/solution/vuln_solution` | 无专用字段 | **SDM 缺口**；建议对象化而非只加文本列 |
| 原始数据 | `raw_data/hash/size`、`metadata.original_event_uid` | 多个原字段/批次 | Evidence refs | 部分；SDM 通过证据引用回查原始事件，不在告警主表复制原始载荷 |
| 租户 | `metadata.tenant_uid` | `log_src_tenant_id` 等 | `tenant_id` | 直接，但组织/空间/租户映射需明确 |
| 扩展与未映射 | Extension/Profile、`enrichments`、`unmapped` | `extend_fields*`、`reserve_fields*` | 受约束的 `extensions` | 当前禁止复制证据事实和来源分类；后续仍需 Schema/版本治理 |

### 12.6 字段对比结论与优先级

1. **OCSF 不能直接作为 SDM 告警物理表。** OCSF 顶层是 Finding 交换快照，而 SDM 还要承担去重、归并、证据回表、分派、研判、工单和案件关联。
2. **大禹不应被整表照搬。** 496 字段中大量是平铺的 Entity/Evidence/富化/兼容列，还有 40 个无结构扩展与保留字段。SDM 应保留输入映射，内部按 Alert、Entity、Evidence、Analysis、Workflow 拆分。
3. **P0 补语义缺口。** 固化 severity/confidence/risk 映射表，将大禹复合状态拆到 workflow/disposition/verdict/ticket/compromise，明确秒与毫秒换算，增加 evidence verdict 和 remediation 目标对象。
4. **P1 补 OCSF 交换契约。** 增加 6.5 的 OCSF UID/版本/质量字段，完成 `finding_info`、`metadata`、`resources`、`evidences`、`observables` 导入导出映射。
5. **P1 不得超前宣称。** `sdm_alert_entity`、`sdm_alert_attack_tag`、`sdm_analysis`、`sdm_workflow_action` 在当前字段标准中是后续阶段草案；只有主表和 Evidence DDL 不等于已覆盖大禹全量告警运营字段。
6. **P2 治理兼容字段。** 将大禹的 `extend_fields*`、`reserve_fields*`、`proof_info` 按有 Schema 扩展、外部富化、未映射原值分流，并用映射版本与质量状态验收。

---

## 十三、最终结论

OCSF 和 SDM2.0 在安全事件归一化层高度重叠，但整体场景不一致。OCSF 的主要价值是对外互操作、成熟的分类/对象语言与跨厂商检测内容基础；SDM2.0 的主要价值是统一行为角色、查询友好的物理投影、实体时间线和完整的 SOC 告警运营边界。

最优路线是：

> **OCSF 作为行业分类、数据交换和外部 Finding 基线；SDM2.0 作为内部事件调查、实体索引、高性能查询和告警运营模型。**

实施上应首先修正 event_category=alert 覆盖行为领域、来源 Finding 与行为事实混用、outcome/severity/risk/confidence 混用三个语义问题，然后再引入 OCSF UID、Profile、Validator 和下游对接。只增加若干 ocsf 字段会形成表面兼容，无法获得规则复用和数据治理收益。

---

## 十四、参考资料

### 14.1 OCSF 官方

1. [OCSF 官方网站](https://ocsf.io/)：项目定位、实现中立原则和 Linux Foundation 项目公告。
2. [OCSF Schema Browser 1.8.0](https://schema.ocsf.io/1.8.0/)：Category、Class、Object、Profile 和字段约束。
3. [OCSF Schema 1.8.0 Release](https://github.com/ocsf/ocsf-schema/releases/tag/1.8.0)：本文基线版本。
4. [OCSF 贡献组织列表](https://github.com/ocsf/.github/blob/main/profile/Contributors.md)：社区参与组织参考。
15. [OCSF 1.8.0 Detection Finding 2004](https://schema.ocsf.io/1.8.0/classes/detection_finding)：顶层字段、必要性、类型和枚举。
16. [OCSF 1.8.0 Finding Information](https://schema.ocsf.io/1.8.0/objects/finding_info)：Finding ID、标题、Analytic、ATT&CK、时间和关联字段。
17. [OCSF 1.8.0 Evidence Artifacts](https://schema.ocsf.io/1.8.0/objects/evidences)：证据对象字段与条件约束。
18. [OCSF 1.8.0 Analytic](https://schema.ocsf.io/1.8.0/objects/analytic)：检测分析类型、ID、名称和版本。

### 14.2 产品实践

5. [Amazon Security Lake FAQ](https://aws.amazon.com/security-lake/faqs/)：Security Lake 对 OCSF 的采用和第三方数据接入。
6. [Datadog：OCSF Common Data Model in Cloud SIEM](https://www.datadoghq.com/blog/ocsf-common-data-model/)：CloudTrail、Okta、GitHub 映射和检测实践。

### 14.3 社区反馈

7. [Issue #995：Embed full related events in Findings](https://github.com/ocsf/ocsf-schema/issues/995)。
8. [Issue #1223：Create a slim version of the ocsf-schema](https://github.com/ocsf/ocsf-schema/issues/1223)。
9. [Issue #1409：Cross-vendor device identity](https://github.com/ocsf/ocsf-schema/issues/1409)。
10. [Issue #1487：Original event source/type metadata](https://github.com/ocsf/ocsf-schema/issues/1487)。
11. [Issue #1601：Pre/Post-Event Target Object State](https://github.com/ocsf/ocsf-schema/issues/1601)。
12. [Issue #1694：timestamp_t semantic type](https://github.com/ocsf/ocsf-schema/issues/1694)。
13. [Issue #1187：Parent Process in Actor vs Process.Parent](https://github.com/ocsf/ocsf-schema/issues/1187)。
14. [Issue #1397：To enum or not to enum](https://github.com/ocsf/ocsf-schema/issues/1397)。

### 14.4 SDM2.0 内部依据

- [I1] [SDM2.0 日志模型概念研究](4.SDM2.0-日志模型概念研究.md)。
- [I2] [SDM2.0 告警模型初稿](archive/alert-model/8.SDM2.0-告警模型初稿.md)。
- [I3] [S4 实体索引模型设计](../openspec/changes/add-sdm2-s4-entity-index-model/design.md)。
- [I4] [SDM2.0 基准测试方案](7.SDM2.0-基准测试方案.md)。
- [I5] SDM2.0 日志字段标准（87 列旧版已移除）。
- [I6] [SDM2.0 Benchmark 记录生成器](../benchmark/generator/sdm2_write_task.py)。
- [I7] [QAX 告警数据标准 v1.6.3](QAX-告警数据标准v.1.6.3.xlsx)，采用“告警数据标准”工作表；版本说明标注 2025-01-07。
- [I8] [SDM2.0 告警模型 v0.2](../alert-model/docs/00-overview.md)；v0.1 55 列草案已移除。
- [I9] [SDM2.0 告警 DDL v0.2](../alert-model/schema/010_sdm_alert.sql)；v0.1 主表/证据 DDL 见同归档目录。