碳泽解读——说说SIEM/SOC系统中Event和Incident的那些事儿

大多数人认为在检测用例被触发的那一刻，event变成了incident。但这是绝对的吗？还是我们不必要地使流程、程序和职责复杂化了？

SIEM/SOC系统中的Event 和 Incident

在网络安全行业，我们使用event、alert、notification和incident等词。在继续回答问题之前，先对这些词作个解析。

• 一个event包含有关已发生的事情的信息。例如，用户通过SSH登录了主机。

• 当用例触发时生成一个notification。例如，用户通过SSH从恶意IP地址登录到了主机。用例是检测进出恶意IP地址的任何流量以及何时使用了SSH协议。

• 一个alert表示一个正确的notification。SOC将分析和评估所有生成的notification，并将它们分类为“正确判断（true positive）”或“误判（false positive）”。

• 当告警关联的event包含潜在的恶意意图时，就会引发一个incident。例如，从刚刚通过SSH成功登录到主机的恶意IP启动了不寻常的下载动作。

Pagerduty的ITIL Event管理

彻底理解这些定义至关重要。因为这样我们可以认识到“在检测用例触发的那一刻，event变成incident”中的逻辑缺陷。

除此之外，理解“不可否认（Non-repudiation）”一词也同样重要。我们能毫无疑问地证明生成的event确实发生了并且事件本身没有被篡改吗？这不仅在以事件为证据上法庭时至关重要，而且安全运营中心会将摄取的event视为正确无误。安全运营中心在寻找event时不会去寻找始发主机，他们会寻找已经传输到一个集中位置的event。如果event数据没有从发起设备安全地传输到集中环境，证明不可否认性就很难甚至几乎不可能。而且，安全运营中心将对集中收集的event数据形成判断。

当event数据被引入SIEM解决方案时，它会根据配置的检测规则进行检查。例如，检测进出恶意IP地址的SSH流量。就其本身而言，此检测规则可能听起来简单明了。但复杂的是如何定义恶意IP地址。大多数安全运营中心使用第三方威胁情报数据供应商来确定IP地址是否恶意。并且大多数安全运营中心盲目地依赖这些信息。然而，问题是“你能吗？”。这些信息的可信度如何？你需要对第三方威胁情报数据进行尽职调查。并与安全运营中心分享结果，因为他们在调查notification时需要了解第三方数据的可靠性。

SIEM/SOC系统中的Notification和Alert

触发用例时，会生成notification。这个notification将出现在一级分析师的屏幕上。他们将进行分析，并在可能的情况下形成判断或将其传递给二级分析师。这是因为一级分析师没有充足的时间，或者因为这个notification没有记录在他们的响应剧本中。

根据响应剧本，如果是正确判断，这个notification将变成一个alert。根据响应剧本，要么直接交给解决小组，要么直接交给incident经理来生成incident。

一级分析师是7x24小时盯着屏幕，而二级和三级分析师大部分时间基于notification随叫随到。

设计缺陷阻碍摄像头展现其真正价值

虽然这听起来像是设计和实施安全运营中心响应服务的持久而真实的解决方案，但在此设计中隐藏了多个关键缺陷：

1. 一切最初都由一级分析师进行分析

2. 基于时间的分析

3. 广义响应剧本

这个设计在我看来是有缺陷的。原因如下：

• 基于时间的分析思维是基于数量优先于质量的原则。 质量调查确实需要时间才能完成。如果时间是一个关键因素，那么需要确保一级分析师在分析notification时会立即获得所有相关信息。而大多数情况下，情况并非如此。

• 所有初步调查均由一级分析师进行。 但问题是“一级分析师是否有足够的经验和知识来担负这样的责任？”。大多数安全运营中心雇用初级或中级员工担任一级分析师，因为他们的成本低。但是第一，并不是所有来自实施检测规则的输出，都可以被一级分析师分析，因为他们缺乏经验和知识。第二，如果成本对安全运营中心经理来说是一个关键的事情，那么自动化一级分析师执行的步骤在大多数情况下要便宜得多。附带的好处是你有更一致的输出。

• 一个响应剧本就可以解决所有问题。 勒索软件攻击是否需要与分布式拒绝服务攻击相同的步骤？也许在更高的层次上，步骤是相同的，但不是在刚刚生成notification时。那么所有的步骤都很重要。这对于那些不使用像千乘SOAR这样专门的系统，而是使用更传统的（基于工单的）系统（如ServiceNow）的安全运营中心尤其有效。通用响应剧本的问题是关键步骤可能会被迅速遗忘和/或以错误的顺序执行。这是公认的“当日分析”分析师。

但矛盾的是，当你优化了安全运营中心并消除了设计缺陷时，从alert阶段转化到incident阶段仍然是人为决定的。事实上，数据科学确实可以帮助我们提出一个谨慎的理由。但是数据科学无法接管这个决策点，至少现在还没有。

如果拥有足够的数据（SOC 响应过程的输出），你也许能够创建一个数据模型来自动执行此步骤。但是如果你想走这条路，那就不要像大爆炸般的迁移，而是一个一个慢慢来。用例类别按用例类别，夯实每一步。

执行此步骤后，我们几乎可以消除event和incident之间的界限，因为所有中间步骤都是自动化的。但是，你仍然可以识别四个阶段（event、notification、alert、incident）。

成熟的管理平台

不难理解，事件管理是将事务状态的变化信息与人员响应进行联动的一系列过程。

虽然企业准备了非常详尽的业务连续性保障计划和应急预案，但随着商业模式和IT支撑环境复杂性的增加，团队需要管理的事件规模也呈指数级增长，但管理事件的人员数量却没有得到增加。因此收集更加全面的信息，运用智能化的手段，帮助团队实时风险量化，提高安全防御能力，提升反应速度和准确性，就变得至关重要。

由三种技术解决方案(安全编排和自动化、威胁情报平台和事件响应平台)融合而成的SOAR解决方案不仅维护从自动化和精心安排的活动中收集的所有信息和丰富的数据，它还维护响应期间所采取的所有行动的详细审计日志。功能全面的SOAR同样能允许进行详细的任务管理，允许事件管理人员创建、分配和监视分配给参与响应的所有分析人员的任务。此外，也允许用户跟踪事件中涉及的资产，并对所有物理和逻辑证据保持详细的保管链。

碳泽千乘SOAR（安全编排与自动化响应平台）作为行业领先的碳泽NGDR核心中枢，能够轻易地将各类已部署的安全工具与既有安全人力及安全流程连结起来，将信息系统中各项“对信息安全而言有价值的资产”和即有安全策略及安全管理流程链接链接再一起，在使各类资产得到妥善连结的同时，进行自动化安全运营，帮助企业组建信息安全快速反应部队，通过安全工作流编排加速自动化防御和响应，提升安全运营能力。

总之，借助安全过程自动化，真正提升了安全运营人员的协同工作效率，缓解了重复性劳动的压力，降低了人为错误的概率，减少了安全事件的平均响应时间。

End

碳泽信息
专注于下一代安全防御与响应体系。

销售咨询：[e-mail]

技术支持：[e-mail]

官方网站：http://www.tanze.net.cn