上一篇讲完单一日志源的降噪和结构化，这一篇讲一个更麻烦的问题：单看一条日志、甚至单看一个数据源，很多攻击你根本发现不了。真正的攻击链，往往横跨Web日志、主机日志、云审计日志好几个系统，每个系统单独看都平平无奇，拼在一起才是一次完整的入侵。我经手过一起真实事件，复盘的时候最让人后背发凉的不是攻击手法有多高明，是每一步单独拎出来看，居然都不会触发任何告警。Web日志里有一条状态码200的请求，主机日志里有一次持续时间很短的进程创建，云审计日志里有一次身份验证成功的API调用——三条记录分别归属三个不同的监控系统，三个系统各自的规则引擎都没吭声，因为每一条单看都太正常了。直到应急响应的时候人工把时间线拼起来，才看出这是一条完整的攻击链：网页入口的SQL注入拿到了一个低权限账号，低权限账号被用来在服务器上落地了一个Webshell，Webshell又被用来调用云平台的临时凭证获取接口，最终拿到了能访问对象存储的权限。这类事件在复盘会上经常被总结成"我们各个系统的检测规则都是各自为战，缺少一个统一的关联视角"，这句话说得没错，但光说这句话解决不了问题——真正难的不是"要不要做关联"，是"关联的判断逻辑该怎么设计，才能既不漏掉真实攻击链，又不会把大量无关事件强行拼到一起制造误报"。这也是这一篇要讲清楚的核心内容。一、关联的本质是什么按第一性原理拆一下，"日志关联"这件事到底在解决什么问题。核心其实就两点：实体对齐和因果排序。实体对齐，是要搞清楚不同日志里出现的IP、账号、主机名、会话ID
上一篇讲完单一日志源的降噪和结构化，这一篇讲一个更麻烦的问题：单看一条日志、甚至单看一个数据源，很多攻击你根本发现不了。真正的攻击链，往往横跨Web日志、主机日志、云审计日志好几个系统，每个系统单独看都平平无奇，拼在一起才是一次完整的入侵。我经手过一起真实事件，复盘的时候最让人后背发凉的不是攻击手法有多高明，是每一步单独拎出来看，居然都不会触发任何告警。Web日志里有一条状态码200的请求，主机日志里有一次持续时间很短的进程创建，云审计日志里有一次身份验证成功的API调用——三条记录分别归属三个不同的监控系统，三个系统各自的规则引擎都没吭声，因为每一条单看都太正常了。直到应急响应的时候人工把时间线拼起来，才看出这是一条完整的攻击链：网页入口的SQL注入拿到了一个低权限账号，低权限账号被用来在服务器上落地了一个Webshell，Webshell又被用来调用云平台的临时凭证获取接口，最终拿到了能访问对象存储的权限。这类事件在复盘会上经常被总结成"我们各个系统的检测规则都是各自为战，缺少一个统一的关联视角"，这句话说得没错，但光说这句话解决不了问题——真正难的不是"要不要做关联"，是"关联的判断逻辑该怎么设计，才能既不漏掉真实攻击链，又不会把大量无关事件强行拼到一起制造误报"。这也是这一篇要讲清楚的核心内容。一、关联的本质是什么按第一性原理拆一下，"日志关联"这件事到底在解决什么问题。核心其实就两点：实体对齐和因果排序。实体对齐，是要搞清楚不同日志里出现的IP、账号、主机名、会话ID
)
