使用 Elastic Stack 作为基于 SaaS 可安全操作的瑞士军刀

在 RS2，安全是我们所做一切的核心。我们的主要产品 BankWORKS 是一款功能齐全的端到端集成解决方案，可满足从设备交易获取到最终结算和分类账集成的所有支付处理需求。该软件被世界各地大大小小的银行、处理商和支付服务提供商使用，而无论他们的业务是简单还是复杂。我们还将该产品作为托管服务提供。

作为一个团队，我们有责任确保最大限度地降低数据在各业务渠道中被窃取或泄露的风险，还要确保我们满足多项合规性要求，同时避免日常运营中断。

在 2017 年 11 月，我们计划扩大我们安全团队的规模。不过，在获得额外聘用的批准之前，我们需要减轻一些处理事故和安全事件的人工工作。 我们的旅程从 Elastic Stack 开始。

从建议到生产的旅程

初始阶段

我之前在担任其他一些角色时，曾在个人项目中使用过 Elastic Stack，因此就想把该产品介绍给团队。由于其广泛的特性集和可扩展性，我觉得它可以满足我们所有的需求。

在 RS2 担任新角色的头几天，我在笔记本电脑上的虚拟机上启动了 Elasticsearch 和 Kibana 实例（本例中为版本 6 ），在虚拟机本身上安装了几个 Beats（ packetbeat、auditbeat、metricbeat 和 filebeat），并将所有数据直接发送到 Elasticsearch 。整个过程花了大约一个小时（其中 40 分钟包括操作系统 ISO 映像的下载和安装）在 Kibana 填充了有意义的数据。

我把这个展示给我的同事，他几乎立刻同意这是以后推进的方向，并赞成用真实的数据为执行团队创建一个演示，凸显该产品的有效性。我们决定包括少量网络设备和现有服务器（这样就不必使用不同的 Beats 和 Logstash 对生产网络进行任何更改），以及一些第三方集成。

云评估

在以前的职业角色中，我托管了跨多台服务器的大型 Elastic 部署。然而，我从未真正看过 Elastic Cloud 产品。RS2 碰巧处于“基础架构冻结”状态，因为它们即将迁移到云中。这一点，加上紧迫的截止日期和有限的资源，让我开始探索 Elastic Cloud。作为一名安全专家，我对此表示怀疑。我想确保服务的设计考虑到一定程度的安全性。

一旦我有了集群，我就进行了一些快速安全测试，看看是否能现任何明显的漏洞或弱点。以下是我的发现：

• Elastic 让您可以在作为后端云提供商的 AWS 和 GCP 之间进行选择，因此它们的所有安全功能及其合规性认证都是继承的。
• 每个群集都使用隔离网络，而不是每个提供商的默认子网。
• Elasticsearch 和 Kibana 网址都使用 TLS 设置和密码
• Elasticsearch 运输端口是随机的
• 每个实例的网址也是完全随机的，因此不可能枚举客户名称
• 没有群集标识，直接访问 IP 是不可能的
• 使用最新版本的 Elastic Stack，以及最新版本的 Java 8。

把它们放在一起

现在我有了云集群，我必须设计数据流。下图概述了 POC 的体系结构。

由于我们可以使用 X-Pack，观察者被大量用作警报框架的一部分。这是通过使用 Watcher webhook 操作与自定义 Slackbot 集成的。

演示准备 – 使用数据

第一步是尽可能多地解析和丰富我们的日志。在安全环境中，丰富性是快速解决事件的关键，因为它大大减少了分析师的调查时间。这也有助于过滤掉误报。使用几个 Logstash 过滤器插件，我可以轻松做到这一点。此外，为了适应我们现有的日志归档工具，我能够设置多个 Logstash 输出，以便同时向我们的 Elastic 集群和现有归档工具发送数据。

下面是添加到我们的解析日志中的一些丰富操作的列表：

• GeoIP 数据（位置和 ASN）
• 恶意软件知识产权查找
• 允许登录用户查找
• 用户代理解析
• 网址解码

这是为 POC 设置的部分内容列表。一旦我们移到生产，又增加了许多。

现在，我已经很好地解析了所有这些数据，我创建了自定义仪表板，与内置仪表板一起工作，突出前面提到的一些丰富特性。以下是我们为 POC 开发的一些定制 Kibana 仪仪表盘的几个示例（所有敏感数据都已删除） :

此外，我为演示添加了一些其他漂亮的集成，以展示将数据添加到 Elastic 中是多么简单。归根结底，这只是另一个索引。 这方面的一个例子是 Troy Hunt 与流行服务“Have I been Pwned”的整合。该服务提供了一个非常方便的 REST 应用编程接口，允许您查询在公开的数据泄露中是否检测到电子邮件地址。我们创建了一个监测系统，提醒我们注意我们域中的任何新条目。

警报提醒

POC 中警报框架背后的想法（稍后将在生产中使用）是让一切都可以通过 Slack 进行操作。下面是 Slackbot 中被操纵数据的一些例子。分析师开始调查所需的一切都包括在内。使用的数据通过 Logstash 由不同的 Beats 和解析后的网络设备收集。

一些数据集包括：

• 来自防火墙的 SMTP 中继日志、身份验证日志和数据包筛选器日志
• 数据包级别的 DNS 请求，使用数据包
• SSH/SFTP日志，结合使用 Wazuh 和 Filebeat
• 过程及其状态的列表，使用 Metricbeat
• 出站网络套接字监控，使用 *nix 系统上的 Auditbeat

以下是我们为 POC 开发的一些 Slackbot 警报的几个示例（所有敏感数据都已删除） :

• TeamViewer 连接警报
  
  
• 防火墙登录警报
  
  
• 恶意软件警报
  
  

结果

不用说，POC 非常成功，我们获得了移到生产的批准。重申一下，让我们顺利通过这一 POC 的要点：

• 使用 Elastic Cloud 及其所包含的一切的非凡易用性和速度（开箱即用的集成备份、Elastic 和高可用性、适合我们部署规模的捆绑 X-Pack ）
• 接收任何数据并迅速将其转化为有用且可操作的东西的能力（POC 从开始到结束需要大约3整天来实施，包括本文中提到的所有任务 - 解析、仪表板、丰富化、警报框架等等）
• 事实上，这可以与所有现有流程并行进行，不会中断

处理升级

经过几周的生产，Elastic 发布了一个更新。在之前用 X-Pack 升级了大型 Elastic 部署之后，我非常好奇他们的云平台是如何实现这一点的。事实证明，这就像在下拉菜单中选择新版本一样简单。其他一切都是自动完成的，没有任何中断。

结论

我们的 Elastic 之路显然没有到此结束。我们不断添加更多的数据源、更多的丰富内容（例如与人力资源系统关联以获取用户假期数据，以及物理访问系统以了解是否有人在建筑内，是否应该在建筑内），并根据新发现的威胁和恶意活动动态添加警报。我们还在努力与我们使用的其他内部工具集成。

我们对之后使用 Elastic 的安全分析感到兴奋。随着每次更新，Elastic 软件都会发布更多组件，让分析师的生活更轻松，工作也更令人满意。此外，我们同样对即将到来的 Elastic Cloud 升级感到兴奋。毫无疑问，RS2 将继续受益于广泛的功能集，不仅用于安全分析，而且遍及整个组织。