Elastic SIEM Detections
随着 Elastic 安全 7.6 的发布，我们宣布推出全新开创的现代风格检测引擎，该引擎能够通过 Elastic SIEM Detections 视图让 SOC 团队体验统一的 SIEM 规则。 这一检测引擎基于一套专门构建的 Elasticsearch 分析引擎开发而成，可在 Kibana 中新的分布式执行平台上运行。 在本篇博文中，我们将会简要概述一下 Elastic SIEM 中的检测工作流，还会讨论旨在帮助用户无缝完成这些检测工作的全新 UI 和后端功能。
在我们讲解检测过程之前，这里有一个快速提示：如果您已准备好试用 SIEM 应用，请访问我们面向小型企业和居家微型企业的 SIEM 博文系列。该系列涵盖很多内容，包括如何通过免费的 Elasticsearch Service 试用服务在云端完成设置，如何使用 Beats 从您的系统收集数据并将数据流式传输至 SIEM，等等。（这些操作比您想象的要简单得多！） 我们还针对混合部署提供了一套入门指南。
针对信号管理过程的 UI 工作流
Elastic SIEM Detections 视图的最基本内容是信号，也就是当满足信号检测规则的条件时所创建的 Elasticsearch 文档。如果考虑最简单的情况，对于符合规则中所定义查询的每个事件，均会创建一份信号文档。信号文档包括相匹配文档中的字段副本，并且会保存在一个单独的信号索引中。在创建信号时，并不会修改原始事件。
信号会出现在 SIEM 应用中。当从业人员首次看到某个新信号时，该信号处于“打开”状态。在分析并确定了后续步骤之后，从业人员会将状态变为“关闭”。所有这些变更均可在 SIEM 应用中的 Detections（检测）视图内进行管理。
信号计数直方图会显示处于打开状态的信号，并让相关人员跨多个属性进行快速比较：
- 分数、严重性、类型、名称或 MITRE ATT&CK™ 策略名称
- IP 地址的来源或目的地
- 事件操作或类别
- 主机或用户名称
下一步是在 Timeline 中调查信号：
如果您在创建规则时并未指定时间线模板，则会用信号文档来填充 Timeline。如果您指定了时间线模板，则会使用用户所保存的内容来填充 Timeline，以帮助加快特定规则类型的调查速度。
相关人员可以在专门的“外部告警”选项卡中查看来自外部告警系统（Elastic Endpoint Security、Suricata 或 Zeek）的告警。很多公司/组织还会实施规则以针对高价值的外部告警生成信号，以便受益于优化的信号调查工作流。
分析师调查信号或信号集并取得满意结果后，便可以逐个或批量关闭信号。如有必要，信号也可以重新打开。我们正在研究在未来的版本中可以通过什么方法来自动关闭信号。
针对规则创建过程的 UI 工作流
如想开始显示信号，检测过程的运行离不开规则！为 SIEM 检测过程创建规则十分简单和直接。归结下来，可以分为三个基本步骤：
1) 生成每次运行规则时所要用的查询。查询可以是 Lucene 语法、KQL、已保存的搜索，或者还可以从已保存的时间线导入查询（还有很多针对规则中所含查询的选项正在开发之中，在未来版本中会亮相）：
2) 为规则添加一些描述性信息（标题、描述，等等）：
3) 设定好规则运行的间隔时间，以及用于合理性检验的任何额外回查时间。通常我们建议设置一些回查 (look-back) 时间，以便应对特定用户采集管道中可能发生的延迟。建议设置一些回查时间的另一个原因是，我们不能确保规则会在所设置的准确间隔时间点运行，所以在运行过程之间可能会有延迟。任务管理器工作线程队列超载或者计算资源不足会导致发生此类延迟。
这三项内容是检测规则的三个基本构成元素。我们还提供了一些设置来根据 MITRE ATT&CK 策略和技巧对规则进行分类，也提供了一些指向更多参考信息的链接。
用户还可以单独或批量对既有规则进行操作，例如复制（以进行自定义）、停用、导出和删除规则。我们还有一份指南，其中为您提供了有关一般性规则管理的详细信息。
预构建的规则
开发规则是一件很困难的事儿，而且测试规则十分费时。有鉴于此，Detections 视图最初包括由 Elastic 安全部门的情报和分析团队开发的 92 个预构建规则，这些规则已经在 Elastic 的生产环境中得到了广泛使用。我们同时也在持续开发新规则以应对最新的关键威胁。要想加载并开始运行这些规则，操作十分简单，单击一个按钮就行！有关如何使用和调整预构建规则的更多信息，请参见此处。
Detections 实施详情
Elastic Stack 中的 Alerting 作为一级实体添加到 Kibana 中以提供告警支持后不久，Elastic SIEM 便利用告警来作为检测工作的基础了。在 UI 的幕后，Detections 视图会使用一个基于 Alerting API 架构的 API。SIEM Detections API 能够让您体验便捷性，为您提供工作流（例如打开和关闭信号），让您了解安全相关的域具体信息（例如 MITRE ATT&CK 识别），同时还支持 KQL。
规则在幕后是这样运行的：先创建一个 API 密钥，然后借助此 API 密钥来代表用户提交请求。这些规则会使用 search after 来找到匹配的事件，并使用 bulk create 来将事件相关信息复制到信号索引中的信号文档内。信号由下列两部分组成：规则详情，以及与规则相匹配的原始事件文档的详情。
如果在单次规则执行过程中发现了超过 100 份匹配的文档，则只会将最后 100 条匹配结果复制到索引文档中（按照 @timestamp 降序排列）。在您首次访问信号检测规则页面时，会为每个 Kibana 空间自动生成一个信号索引。索引名称的格式为 .siem-signals-
SIEM 信号索引的映射是将 Elastic Common Schema (ECS) 和我们针对信号定义的定制映射结合在一起。当通过规则中所含的查询检测到相符的文档时，系统会从源索引复制字段，并且如果源文档中的字段符合 ECS 规范，则生成的信号字段是可搜索的。即使索引文档中的字段并不符合 ECS 规范，它们仍会存储在信号的 _source 中，并且可以在 Timeline 及应用程序的其他部分查看，但是您不可对它们进行搜索。
可扩展性
Detections UI 是在新开发的 Kibana Alerting 框架和 Kibana 任务管理器的基础之上构建而成的。这两大基础提供了水平和垂直扩展功能，能够让您灵活调整以最大程度契合可用的硬件资源（无论规模大小）。您可以增加 Kibana 任务管理器工作线程的数量以实现垂直扩展，或者还可以在不同的 Kibana 实例之间进行复制以实现水平扩展。
如果有多个 Kibana 实例在同时运行，任务管理器会在它们之间进行协调，以便跨实例实现任务均衡。通过更新 kibana.yml 中 max_workers 的数量（默认值为 10），您可以垂直进行规模缩放，以便准确、更高效地为每个 Kibana 节点分配资源。
信号去重
规则运行时，它会基于所找到的、与规则中所含查询相匹配的事件生成信号。有时会因为下列情况而创建重复信号：不同规则中有重叠的查询，或者某一规则连续运行两次并由于额外回查时间较长而采集到同一信号。为避免信号表格中出现重复信号，我们会根据下列内容来识别信号：源事件所属的索引、源事件的文档 id、源事件的版本号，以及所运行规则的 id。通过对这些属性进行哈希运算，我们可以确保仅向信号索引中添加唯一的信号。
错误
有时会由于规则查询中的语法错误或者规则运行期间的某些其他问题而出现错误。我们会在规则详情页面的“故障历史”选项卡提供这些信息。我们计划未来会扩展下列两方面的可见性：规则执行信息，以及一般性的规则监测过程。
在这里，我们可以看到故障历史，会列出规则执行期间出现的最后五个错误：
SIEM Detections 的未来发展
在开发和发布这一 Elastic SIEM Detections 测试版的过程中，最激动人心的部分就是持续从 Elastic SIEM 论坛获得的早期社区反馈，以及我们的未完成功能跟踪列表。
为了向您提供更强大的检测功能，我们已经制定了宏大计划，例如，扩展规则中所含的查询以将聚合、Machine Learning 作业和 EQL 包括进来，还有很多。如果您有关于安全用例的好点子，或者希望向我们提问了解最新动态，欢迎加入我们！