TG咨询移动应用执行平台接入企业SIEM的安全事件字段规范，重点不是把所有日志原样搬入，而是让不同来源的事件能被统一检索、关联和响应。字段至少要回答：何时发生、哪个用户或应用实例参与、发生了什么、结果如何，以及记录来自哪里。
先划定事件范围，再统一字段
接入前列出平台实际能产生的安全事件，例如身份验证成功或失败、设备合规检查未通过、应用完整性校验告警、策略拒绝、会话结束和敏感操作触发。不要把普通诊断信息一概标成安全事件；也不要因平台没有提供某项数据，就用猜测值补齐。
字段可参考 OCSF 等公开事件模型进行映射，但不必照搬其全部结构。企业应维护自己的字段字典，明确字段含义、类型、是否必填、允许值及缺失时的处理方式。
一条事件记录应包含什么
| 字段组 | 建议字段 | 规范要点 |
|---|---|---|
| 事件识别 | event_id、event_type、event_category、event_action | event_id用于标识单条记录；类型与动作使用稳定枚举，避免同一含义出现多个拼法。 |
| 时间与来源 | event_time、observed_time、source、schema_version | 时间采用带时区的 RFC 3339 格式；区分事件发生时间与平台收到时间。source标明产生事件的组件。 |
| 主体与对象 | user_id、app_id、app_version、device_id、resource_id | 优先使用企业可关联的稳定标识；设备标识应说明作用范围，不能把临时会话号误当用户身份。 |
| 结果与风险 | outcome、reason、severity、policy_id | 结果可统一为成功、失败、阻止等受控值；severity说明分级规则，不能只填数字而不解释量表。 |
| 关联与传输 | session_id、correlation_id、sequence、delivery_status | 支持跨事件关联、重试排查和重复记录识别；传输状态不应替代安全事件结果。 |
移动场景中，应用版本、平台类型和策略版本常能帮助区分问题来源；但精确位置、通讯录内容、完整 URL 参数或认证凭据通常不应进入 SIEM。确需记录时，应先确认业务必要性、访问权限和保留期限，并优先采用脱敏或摘要标识。
落地时按顺序检查
- 建立字段字典。为每个字段写明数据类型、必填条件、枚举值、示例和敏感级别；时间统一到明确时区，推荐使用 UTC。
- 定义事件目录。把平台事件映射到企业分类，区分检测告警、策略决策和审计记录，并为每类事件规定触发条件。
- 制作映射与校验规则。把原始字段映射到标准字段；缺少值时使用空值或省略，并记录原因，不用“unknown”冒充真实数据。
- 验证传输与关联。模拟登录失败、策略阻止等可控场景，检查事件是否到达、时间是否合理、同一事件重试后能否识别重复，并确认关联标识能串起相关记录。
- 小范围上线并复核。先检查字段缺失率、重复率、解析失败和告警误报，再逐步扩大接入范围；字段字典或事件版本变化时同步更新解析和检测规则。
几个容易混淆的细节
发生时间不等于入库时间
网络中断或设备离线可能导致延迟上报。保留event_time与observed_time，SIEM检索和规则再分别选择事件时间或接收时间，避免迟到记录被误判为刚刚发生。
严重级别要能解释
平台的高、中、低不一定等同于 SIEM 的分级。应写清映射依据，例如是否已阻止、是否涉及高权限主体、是否有可验证的异常证据，并保留原始级别供追溯。
常见问题
字段名称必须和 SIEM 产品一致吗？
不必。先确定企业标准字段，再通过解析器映射到具体产品的数据模型，降低更换平台时的改造成本。
事件 ID 可以由 SIEM 生成吗？
可以，但平台若提供稳定事件 ID，应优先保留；否则接入端可按明确规则生成关联键，并避免把时间戳单独当作唯一标识。
是否所有字段都设为必填？
不建议。把事件类型、来源和事件时间等设为核心要求；设备或策略等字段按事件场景设条件必填，防止无意义的占位数据。
规范多久复核一次？
没有适用于所有环境的固定周期。平台升级、事件模型变更、解析失败增加或检测规则调整时，应及时复核字段字典和兼容性。
归根结底，移动应用执行平台接入企业SIEM的安全事件字段规范，应以可解释、可关联、可验证为准：每个字段有定义，每类事件有边界，变更有版本记录，敏感数据有明确限制。