OneUptime 安全事件（SIEM）实战：OCSF 归一化、Sigma 检测规则与二级监测体系

OneUptime 安全事件SIEM实战OCSF 归一化、Sigma 检测规则与二级监测体系【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptimeOneUptime 将 SIEM 信号作为一等遥测类型管理安全事件与日志、链路、指标共同存储在同一个 ClickHouse 数据湖中并统一归一化为 OCSFOpen Cybersecurity Schema Framework格式——无论事件以何种方言OCSF、Google SecOps UDM、SecOps 告警载荷或任意通用 JSON到达。读完本文你将掌握如何通过 HTTPS 端点接入安全事件、理解归一化后的事件模型、编写基于 Sigma 的检测规则与评估参数以及如何用检测回写Detection Finding构建监测你的检测的第二层安全防线。安全事件的接入端点向 OneUptime 发送安全事件的方式是携带项目的遥测接入密钥telemetry ingestion key通过 HTTPS POST 提交 JSONcurl -X POST https://oneuptime.com/security-events/v1/ingest \ -H Content-Type: application/json \ -H x-oneuptime-token: your telemetry ingestion key \ -d { events: [ { class_uid: 3002, severity_id: 4, time: 1755770400000, message: Failed logon for alice, actor: { user: { name: alice } } } ] }请求体接受三种形态单个对象、裸数组、或{ events: [...] }包装。支持的方言如下format方言说明ocsf原生 OCSF 事件 JSONclass_uid、severity_id等字段udmGoogle SecOps / Chronicle UDMmetadata.event_type等字段google-secops-alertSecOps 检测/告警载荷SOAR webhook、detections 流generic其他一切——按常见字段名尽力映射省略format时系统按事件逐个嗅探方言per-event detection因此同一个 webhook 可以同时混入检测告警与原始事件。方言声明还支持?format...查询参数与x-oneuptime-security-event-format请求头。从源码看该端点定义在 SecurityEventsIngest.ts路由POST /security-events/v1/ingest依次挂接遥测禁用中间件、将请求标记为ProductType.SecurityEvents用于计量计费、复用统一的TelemetryIngest.forSurface(TelemetryIngestSurface.SecurityEvents)鉴权中间件最终交由SecurityEventsIngestService处理。这意味着安全事件与其他遥测共用同一套接入密钥鉴权体系。归一化事件模型一条事件长什么样每条事件都被归一化到一组类型化列外加一个展平的 attributes 映射。归一化的规范形状定义在 NormalizedSecurityEvent.ts 接口中核心维度包括分类ClassificationOCSF 的categoryName/className/activityName例如Identity Access Management/Authentication/Logon附带各自的数字 uid。严重级别SeverityOCSF 级别——Unknown、Informational、Low、Medium、High、Critical、Fatal。主体与目标Actors and targetsprincipalUser、principalHost、principalIp、principalProcess以及targetUser、targetHost、targetIp、targetPort、targetResource。可观察值Observables所有抽取出的实体值用户、主机、IP、域名集中在一个带索引的数组列中——查找提及 X 的所有事件只是一次廉价查询。源码注释指出该列由单个布隆索引bloom-indexed column支撑同时服务于实体邻域图entity-neighborhood graph见 NormalizedSecurityEvent.ts。检测来源Detection provenanceruleId/ruleName以及 MITRE ATTCK 的mitreTactics/mitreTechniques。属性Attributes完整源载荷被展平为点号分隔的键如principal.hostname——任何未映射成功的字段都不会丢失因此保持可查询。此外NormalizedSecurityEvent还携带eventUid源分配的 uid如 OCSFmetadata.uid、UDMmetadata.id缺失时接入侧会派生内容哈希使重复投递仍可去重、statusNameSuccess/Failure/Blocked/Allowed 等活动结果、vendorName/productName与消息摘要。关于 OCSF 分类的映射细节OcsfEventClass.ts 展示了兜底策略当 class uid 未命中精选类表时按floor(class_uid / 1000)推导 category1xxx 系统活动、2xxx Findings、3xxx IAM、4xxx 网络活动、5xxx 发现、6xxx 应用活动推导不出则归入Uncategorized——保证没有 OCSF 对应物的方言也不会被丢弃。类表本身是一个精选子集例如1007 Process Activity、2004 Detection Finding、3002 Authentication、4007 SSH Activity并额外收录了 Windows 扩展的 Registry Key Activity201001因为 Google SecOps UDM 注册表事件在真实环境中很常见。检测规则SigmaSecurity Events → Detection Rules每分钟对事件评估一次 Sigma 规则每条规则的评估间隔可配置。一条命中规则的后果打开一个 OneUptime告警alert——按规则与分组值去重走标准告警严重级别与 on-call 路由可选地打开一个事件incident——默认关闭因为 incident 会驱动 on-call 升级、SLA 与状态页严重级别优先级与 alert 相同规则显式指定的严重级别优先否则将 Sigma level 映射到 incident 严重级别向事件表回写一条Detection Finding事件使检测结果本身成为可搜索的信号。支持的 Sigma 子集是布尔核心部分命名 selection字段映射支持contains/startswith/endswith/re/cidr/gt/lt/all/cased/windash/exists等修饰符以及关键词列表完整条件语法and/or/not、括号、1 of x*、all of them等量词聚合条件| count() ...在保存时直接拒绝而不是被静默忽略字段名可以是 OneUptime 列名principalUser、常见别名CommandLine、src_ip或任意展平源键principal.hostname。这一子集的类型化表示见 SigmaRule.ts条件被解析为条件 ASTselection/and/or/not/of五种节点of节点携带any/all/ 数字量词与可选通配的名称模式每个 selection 至多呈现一种形态——字段映射列表映射间 OR、字段间 AND或裸关键词列表。SigmaLevel枚举为informational/low/medium/high/critical。示例规则title: Possible Brute Force level: high tags: - attack.credential_access - attack.t1110 detection: selection: className: Authentication statusName: Failure filter_internal: principalIp|startswith: 10. condition: selection and not filter_internal该规则对认证失败且来源 IP 不在 10. 内网段的任意单条事件即触发默认阈值 1。评估参数Evaluation settings规则Evaluation步骤控制它何时运行、匹配多少才触发字段作用Evaluation Interval (Minutes)规则运行频率。每次运行扫描自上次运行以来到达的事件。整分钟1–1440。Group By Field可选。将共享同一值如principalHost的匹配折叠为一个 finding——一台嘈杂主机只产生一条告警而不是几百条。计数按分组进行。Distinct Count Field可选。对该字段的不同值计数而不是原始匹配事件数。空值不计入。Match Count Threshold一个评估窗口内分组的计数达到该值才触发。默认1任意匹配即触发。整数1–1000000。凡是并非类型化事件列的名字都会到事件的 attributes 映射中查找——因此groupByField与distinctCountField接受与 Sigma 规则本身相同的字段词汇。基于计数的检测将阈值设为大于1即可在规则本身表达同一来源、同一窗口内出现 N 次——无需再叠加 monitor。上面的规则在单次登录失败时就触发若要改为同一来源 5 次失败Evaluation Interval (Minutes)10Group By FieldprincipalIpDistinct Count Field留空Match Count Threshold5加上Distinct Count Field则改变阈值计数的对象按principalIp分组、对principalUser做去重计数、阈值5表达的正是密码喷洒password spraying——同一个源对五个不同账户登录失败——而不是同一个账户被暴破五次。窗口是滑动落桶tumbling不是滚动rolling每次运行只统计自上次运行以来到达的事件然后推进游标窗口不重叠。间隔10、阈值5时09:58 的三次失败与 10:01 的两次失败落在不同窗口什么都不会触发。请据此设计阈值而不是设成恰好关心的最小值。此外worker 停机后或重新启用被禁用的规则时下一个窗口会覆盖整个空档期上限 24 小时——10 分钟内 5 次的规则可能短暂表现为自上次运行以来 5 次。Monitors滚动窗口与状态机Security Eventsmonitor 类型在滚动窗口内统计匹配事件按 severity、class、message、attributes、来源 service 过滤驱动标准条件机制——变更 monitor 状态、打开 alert 或 incident、路由到 on-call。Security Events → Monitors列出该类型的全部 monitor。检测规则与 monitor 的重叠多于表面所见但二者并非同一功能的两种口味规则匹配 Sigma 模式配合Match Count Threshold可以要求同一分组在一个 tumbling 窗口内出现 N 次才触发。它没有unmatch概念因此产物是 finding 与 alert——永远不产生状态status。monitor重读滚动窗口回答现在有多少。它没有 group-by能数任何地方的五次认证失败但无法表达来自同一来源 IP 的五次——而计数回落到阈值之下正是它能宣告风平浪静的机制。实践建议用规则阈值表达检测本身当你真正需要滚动窗口、monitor 状态、状态页曝光或按条件绑定的 on-call 策略时再上 monitor。监测你的检测Watching your detections每次规则命中都会回写事件表成为一条Detection Finding事件OCSF class 2004归属于名为OneUptime Detections的遥测 service。finding 携带规则名与 id、MITRE ATTCK 标签、observables中的匹配分组值以及这些属性属性值oneuptime.detection.rule_id触发规则的 idoneuptime.detection.rule_name规则名称oneuptime.detection.match_count该 finding 背后的事件数oneuptime.detection.distinct_count设置了 Distinct Count Field 的规则背后不同值数oneuptime.detection.group_value规则设置了 Group By 时的分组值oneuptime.detection.sigma_idSigma 规则自身的id:字段因为 finding 就是普通安全事件Security Events monitor可以监视它们——这便把两个特性组合成第二层检测检测风暴Detection storms。对Detection Finding类事件建 monitor统计全部 findings。一小时内二十条不同规则齐鸣是任何单条规则都看不到的信号——每条规则只知道自己命中的部分。monitor 看到聚合值、变更状态、并可打开 incident。按规则的速率变化。过滤oneuptime.detection.rule_id属性它是不可变的——过滤rule_name会在规则改名后静默失配。周频规则突然一小时触发五十次是需要不同响应的事件。检测管道静默Detection pipeline silence。平时总能看到几条 finding突然归零通常意味着转发器坏了而不是网络太平。用计数低于阈值条件表达它。通往第二层检测的最快路径是Security Events → Detection Rules上的Create Monitor行操作它打开 monitor 创建页并预填Detection Finding类与对该规则 id 的过滤永不按名字过滤——finding 携带规则的当前名字改名会静默孤立按名字过滤的 monitor。注意此类 monitor 统计的是findings而非背后的事件。带 Group By 的规则每次运行每个分组只写一条 finding因此它度量的是检测速率。若要先凑够 N 个事件才产生检测请在规则本身上用Match Count Threshold。威胁情报Security Events → Threat Intel订阅 STIX/TAXII 2.1 feed指标indicator在接入时以threat.*属性富化入站事件Sigma 规则与 monitor 可直接过滤无需新语法定时匹配器将近期事件与活跃指标做 join——命中时写 finding 并打开去重后的 alert行为与检测规则完全一致。详见 threat intelligence guide。保留与计费安全事件按接入的 GB 计量计费与其他遥测相同并遵循同一套保留配置项目默认值、按 service 覆盖以及专门的securityEvents保留支柱。行在保留期到期后由 ClickHouse TTL 删除。托管连接器Managed connectors除接入端点外Security Events → Connections可以直接轮询安全产品。一个 connection 保存产品的非机密设置与一个加密凭证后台 worker 按你设置的间隔轮询把新记录作为归一化安全事件导入并按源产品自身的记录标识去重。所有托管连接器都按源记录创建时间轮询而不是按底层活动时间。一条每小时运行的 SIEM 规则其检测结果远晚于所匹配的事件才产生——若按事件时间前移轮询器会跳过它们按创建时间前移则不会。首次轮询回看 24 小时使新 connection 立即可见近期记录Test connection从 API 直接执行、不经过 worker因此可以判断问题是否出在 OneUptime 自身的 worker 或调度器上。连接器导入内容Google SecOps (Chronicle)规则检测、策展检测与告警作为 Detection FindingsMicrosoft SentinelIncidents作为 Incident FindingsMicrosoft Defender XDRAlerts作为 Detection FindingsCrowdStrike FalconAlerts作为 Detection FindingsSplunk Enterprise SecurityNotable events或任意搜索作为 Detection FindingsElastic SecurityDetection alerts作为 Detection FindingsAWS Security HubFindings作为 Detection 与 Compliance FindingsOkta System Log认证、MFA、账户与策略事件作为身份事件各连接器的配置细节见 Google SecOps 集成指南等集成文档connection 的持久化模型见 SecurityEventConnection.ts 与 SecurityEventConnectionRun.ts检测规则模型见 DetectionRule.ts威胁情报 feed 模型见 ThreatIntelFeed.ts。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考