操作方法

Elastic 上的 Elastic：深入了解我们的 SIEM 架构

By
Aaron Jewitt

Elastic 上的 Elastic 

Elastic 信息安全检测和分析团队负责构建、调优和维护用于保护所有 Elastic 系统的安全检测。在 Elastic 内部，我们自称为零号客户，并努力始终使用我们产品的最新版本。

在这一系列博客文章中，我们将概述我们的架构、发送到集群的数据、我们如何以及为何在安全和机器学习 (ML) 应用中使用跨集群搜索 (CCS)，以及我们如何调优和管理告警并通知分析师。

Elastic 信息安全环境概述

许多网络安全产品和安全控制措施都是为传统“企业内网”架构设计的：工作站和服务器部署在本地网络中，并依靠防火墙提供保护。一旦告警触发且您需要对主机进行取证时，您得亲自前往设备现场，导出内存并制作硬盘镜像。而在 Elastic，我们从设计之初就不是一家“传统”公司，因此信息安全团队必须灵活创新，在保障安全的同时，不会以安全为由，强行把企业的运行模式套入固定框架。幸运的是，Elastic Stack 是解决这一问题的完美解决方案。

Elastic 是一家业务遍及全球的公司，从设计之初就采用分布式架构，客户和员工遍布全球 80 多个国家/地区。我们的大多数员工为 100% 远程办公，通过全球各地不受信任的网络，使用连接互联网的 Elastic 自有笔记本电脑开展日常工作。作为一家开源公司，我们的源代码托管在 GitHub 上，我们的持续集成和软件构建系统部署在云端，且对贡献者公开可见。要在这个现代化的分布式企业网络中成功开展监控和取证工作，就必须收集正确的信息，并确保分析师能够在一个统一的位置访问所有这些信息。

此外，除了我们的工作站和企业系统，我们还监测并保护 Elastic Cloud。Elastic Cloud 提供 Elastic SaaS 服务，这些服务目前运行在 AWS、GCP、Azure 和 IBM 托管的 40 多个云区域中的 37,000 多个 Elastic 集群上。Elastic Cloud 是由云团队管理的独立高权限环境，但 Elastic 信息安全团队也负责在该环境中创建告警、监测告警并作出响应。 

深入了解 Elastic 信息安全基础架构 

信息安全下属的安全工程 (SecEng) 团队使用 Elastic Cloud on Kubernetes 和 Helm 构建并维护我们的集群集合，以部署基础架构并保持最新状态。SecEng 管理七个不同的集群；六个承担不同职能的数据集群；第七个“检索头”集群则作为我们的安全信息和事件管理 (SIEM)，该检索头集群使用 CCS 查询所有其他集群中的数据并生成告警。我们使用最新的堆栈版本和候选发布版本，并结合真实世界数据，因此堆栈开发人员会定期使用我们的集群来查找和修复问题，并改进 Elastic 堆栈，从而更好地服务于我们的客户。

成功监测并保护任何组织的关键在于收集正确的数据，并支持在一个统一的位置搜索这些数据。对于信息安全而言，没有任何单一数据源能够提供所需的一切信息。许多组织都面临着同一个难题，即它们记录并存储了正确类型的数据，但不同类型的数据却分散存放在相互独立的位置。数据分开存储有时是出于敏感度、隐私等级差异的要求，也经常是因为数据源由不同的团队拥有和维护，还有一部分情况是把数据归集到一处会产生高昂的传输成本。借助 CCS 的强大功能，我们能够将数据存储在不同的集群中，同时仍可通过单个 Kibana 接口搜索这些数据并针对其生成告警，从而让分析师全面了解情况。

所有信息都集中呈现在同一位置后，分析师便可以在 Elastic Stack 中构建检测、威胁情报和事件响应环境。调查告警时，我们可以使用 Security 应用中的时间线功能，通过查询每个索引中的某个值来调查告警。除了使用 Security 应用中的时间线功能，我们还会使用多个自定义“调查”仪表板，以便快速显示我们需要从各种指标中获取的信息。

严重警报场景

设想这样一种情形：我们收到一条紧急告警，提示某位员工的 Okta 账户可能已遭到入侵。同时我们还可以看到，上个月该用户的工作站曾触发一些低风险行为告警，这些告警最初被视为误报而搁置，但现在需要重新核查。我们可以使用“用户调查”仪表板，通过该用户的电子邮件地址进行搜索，并快速查看其所有 Okta 身份验证活动、通过 Okta 单点登录访问的所有应用、其访问或更改过的所有 Google Drive 文件、这段时间内的 GitHub 活动，以及其账户可能遭到入侵期间访问过的所有 o365 文件。仪表板面板会显示 JAMF 系统清单中有关发放给该用户的工作笔记本电脑的信息，以及该用户的联系信息。

利用系统信息，我们可以转到“主机调查”仪表板，查看该系统上的所有活动，以及该系统是否也已遭到入侵，还是只有 Okta 账户遭到入侵。告警触发时没有用户登录，即表明该系统可能已遭到入侵，需要隔离。Okta 事件中包含用于登录的 IP 地址；我们还可以搜索该 IP，查看当时它是否出现在其他数据集中，例如云服务数据集。 

如果您无法在一个统一的位置查看所有事件，此类调查可能会非常耗时。如果不集中收集您的事件，您就需要登录每个托管服务的管理控制台，以查看其环境中的日志。

跨集群搜索，制胜之选

blog-elastic-siem-1.png

我们最初决定使用 CCS，是因为我们已经有了包含数据的集群，但我们希望能够从单个集群搜索所有数据，以简化 Watcher、仪表板、机器学习任务和检测引擎规则的管理。我们没有选择把全部数据迁移到单一集群，而是采用了 CCS。在使用 CCS 之前，我们需要在多个集群中维护所有这些对象和配置，而且经常要在各个集群中重复工作。

调查警报时，以前我们必须打开多个浏览器标签页才能查看关于该事件的各种数据源。现在，在调查警报时，我们可以在 Security 应用中创建一个案件和时间线，其中包含与该案件相关的每个事件。例如，如果我们在 Auditbeat 数据中发现某台服务器上存在异常活动的警报，并且该事件包含一个 IP 地址，我们就可以在所有索引的 时间线 内查询该 IP，并快速查看该 IP 是否曾出现在我们的任何其他服务中，例如 Nginx 代理数据、Okta、GitHub、云服务提供商日志、Endgame 工作站事件等。得益于 ECS，所有索引模式中的字段都具有标准格式，因此针对 source.ip 的查询将从任何有匹配项的索引返回文档。

除了最初的这些原因外，我们还发现了这种设置的许多其他优势。以下列出的是我们发现的使用跨集群搜索来保障安全的众多优势。

  • 将不同类型的数据存储在不同的集群中，意味着我们所有数据不会有单点故障。升级集群时，其他所有集群仍可供使用。
  • 我们可以授予开发人员访问某个特定数据集群的权限，让他们进行测试和故障排查，而无需授予他们访问 Infosec 所用全部数据的权限。
  • 来自 Observability 和 APM 集群的数据在调查期间通常对安全分析师非常有用。与其复制所有数据，我们可以将远程集群添加到我们的 CCS 配置中。
  • 分析人员可被授予更高权限，使其能够在 SIEM 集群上构建和管理告警及索引，同时对远程集群上的原始数据仅拥有只读访问权限。这样一来，分析人员便可在 Kibana 中使用全部功能，同时保护原始数据的完整性，以满足审计和监管要求。
  • 将主要的“搜索头”Elastic 集群升级到新版本后，您将能够访问所有新的 Kibana 功能，即使其他集群尚未升级。这大大减轻了生产环境 SIEM 频繁提前升级的压力，因为这样您可以测试最新功能，同时无需让承载真实数据的集群面临服务中断的风险。
  • 自 7.13 起，Fleet 用户必须在集群上拥有超级用户权限。我们可以在 Fleet 集群上将 Fleet 管理员的数量保持在极少数，同时向所有其他用户授予对 Fleet 集群所收集事件的只读权限。

零号客户（续）

在这篇文章中，我们概述了 Elastic 信息安全团队如何利用 Elastic Stack 的诸多功能，从各种不同的数据源收集数据，从而让分析师能够全面了解与安全相关的事件。

请记得回来查看本系列的第二部分，其中将深入探讨 Elastic SIEM 中可搜索的数据类型，以及您如何帮助团队简化并优化相关工作。