同一个日志平台，已知攻击和异常行为谁管

结论先行：同一个日志平台上通常跑着两套性质不同的引擎：一套按已知规则匹配攻击特征，一套按行为建模找异常。前者回答「有没有发生我认识的事」，后者回答「有没有发生我从没见过的事」。它们该不该由同一班人管，取决于三件事：告警量级、处置动作的可判定性、以及值班人的技能结构。多数企业的现实选择是——规则侧交给安全运营，行为侧先在安全团队内部试运行，等误报率稳定了再交给同一班人。

本文只谈这两类能力在同一个平台上的职责划分与告警归属，不谈已有检测规则怎么建，也不谈日志该收哪些数据源。

先把两件事说清楚：它们在回答不同的问题

行业内常见的表述是「SIEM 处置已知攻击，UEBA 识别异常行为」。这句话对，但不够用。真正需要分清的是两者的判断依据。

第四行和第五行是关键。规则侧的误报可以通过调参数收敛，行为侧的误报很多时候调参数没用——因为问题出在建模前提上，比如新人没有历史、小部门样本不足、月末结账的批量动作被当成异常外发。这两类问题的处理路径完全不同，混在一起讨论就会陷入「到底是模型不准还是数据不够」的循环。

三个判断，决定该不该分两班人

判断一：告警量级。规则侧一天几十条、行为侧一天几百条，这两类告警的处理方式不可能一样。前者可以逐条看，后者必须靠聚合、靠白名单、靠优先级排序。如果两类告警进了同一个队列，结果一定是行为侧的告警把规则侧的告警淹掉——而规则侧的告警往往是更紧急的那一类。

判断二：处置动作的可判定性。规则侧命中之后，动作通常是明确的：封一个地址、锁一个账号、隔离一台主机。行为侧命中之后，动作是「去找这个人核实」。前者可以写进剧本自动执行，后者必须有人去问。动作性质不同，值班人的工作内容就不同。

判断三：技能结构。规则侧需要的是对攻击手法的熟悉度，行为侧需要的是对业务的理解——哪个岗位该在什么时间做什么操作。这两种能力在同一个团队里不一定都有。

三个判断里，前两个是客观的，第三个是现实约束。多数企业在项目初期只有一个安全值班人，这时候分两班人是不现实的；可行的过渡做法是同一个队列里做硬隔离：行为侧告警单独一个视图，不进主队列，只在每天的固定时段集中看一次。

告警重复怎么处置

同一个行为往往同时触发两侧。一次账号被盗用，规则侧可能命中「异常时段登录」，行为侧可能命中「该账号访问了不属于其岗位的数据」。两条告警说的是同一件事，但如果分属两套引擎、两个队列，就会派给两个人，各自查一遍。

可行的做法不是合并引擎，而是在上报之前做一次关联：以账号、主机、时间窗为锚点，把同一个实体在短时间内的多侧告警聚合成一条事件。事件的标题描述事实，正文分别列出两侧各自的依据。

聚合之后要保留一个信息：这条事件里哪一侧先触发。这个顺序对研判很有用——规则侧先触发，通常说明事件本身比较典型；行为侧先触发，往往意味着有新东西，值得单独复盘。

行为侧上线的前六个月，别急着给结论

行为建模有一个无法回避的问题：基线需要时间。上线头一周产生的告警基本没有参考价值，因为系统还不知道什么是正常。

比较稳妥的节奏是分三段。前一到两周只观察不告警，把模型认为是异常的行为列出来，由熟悉业务的人逐条标注，这批标注会成为后面调参的依据。第二到第六周小范围告警，只覆盖少量关键岗位，把告警发给指定的人。第六周之后再逐步扩大覆盖。

这个节奏的代价是慢，收益是团队对这套东西建立起基本信任。反过来，如果上线即全量告警，头一天几百条误报，团队对它的信任会在头一周内耗光，之后即使模型调准了，也没人愿意再看。

还有一件常被漏掉的事：行为侧的告警需要一个明确的「谁来看」的约定。规则侧告警天然属于安全值班，行为侧告警在很多企业里处于灰色地带——安全团队觉得那是业务的事，业务部门觉得那是 IT 的事。这个归属如果不在上线前定下来，告警就会一直堆着。

只有一个人值班时，先开哪一侧

资源有限时的顺序，建议是先规则侧、后行为侧。理由有三个。

规则侧的投入产出比更确定。写的规则针对的是已知手法，命中之后动作明确，误报可以通过调参收敛。它对团队的要求低，对体系的依赖也低。

行为侧需要的数据基础更厚。基线要成立，日志的完整性和字段一致性必须到位，而这些通常是规则侧先跑起来之后才逐步补齐的。

更重要的是，规则侧跑起来之后，团队的处置流程才成型——谁能封、谁能锁、封了之后谁通知、多久之后复查。这套流程是行为侧将来复用的东西。流程没成型就上行为分析，最后往往变成「发现了很多，但没人处理」。

别把两套能力当成两套产品

采购时容易出现的另一个问题，是把这两件事当成两个独立产品分别采购，结果拿到两套控制台、两套账号体系、两套告警队列，用起来比不用还累。

更合理的判断标准是：这两套能力是否共享同一份数据底座、同一次检索、同一张实体关系图。行业里较完整的平台会把日志检索、规则引擎、行为模型、可视化运营、自动化响应放在同一个体系内，从同一批原始数据出发，而不是各拿一份副本。

这一点在做选型验证时可以直接问：两侧的告警能不能用同一个账号、在同一次检索里互相下钻。能，说明是同一套底座；不能，说明是拼起来的。

深圳市奇摩计算机有限公司在日志与安全运营类项目里，通常把这两侧的上线顺序和归属写进实施计划：规则侧先跑通处置流程，行为侧按岗位逐步放开覆盖范围，两侧的告警在同一个视图里做关联。这样安排的原因很实际——制度先于算法，流程不通的时候，再准的模型也落不了地。

落地清单

• 把两侧的判断依据、告警含义、误报形态列成一张表，让团队对号入座。
• 按告警量级、处置可判定性、技能结构三项判断是否分班，不要一刀切。
• 只有一个值班人时，行为侧告警单独视图、不进主队列，固定时段集中看。
• 两侧告警以账号、主机、时间窗为锚点聚合成事件，并记录哪一侧先触发。
• 行为侧分三段上线：只观察、小范围告警、扩大覆盖。
• 上线前定下行为侧告警的归属人，不要留在部门之间的灰色地带。
• 选型时验证两侧是否共享同一份数据和同一次检索，避免拼装式平台。

若您正在规划日志与安全运营平台的能力分工，欢迎 预约咨询。