基于 Elastic stack 构建 SOC 能力—Elastic Stack 实战手册

2021-10-29 07:38:04

创作人：冯钰妍
审稿人：李捷

本文将介绍如何使用 Elastic Stack 在网络安全分析领域中的实际应用

Elasticsearch 做为一款功能强大的分布式搜索引擎，支持近实时的存储、搜索数据，具有扩展性好，检索速度快等优势，依托于 Elasticsearch 的这些优势，其不仅广泛地应用于各种搜索场景，如日志检索，聚合分析等，在安全分析等领域也开始逐渐展现其强大的能力。

在传统安全领域，企业通常会借助防火墙，杀毒软件等，为企业构造起一套固若金汤的安全防御体系，然而即使在如此严密的防护之下，仍然无法完全保证内部数据的安全，尤其是当面临内部威胁时。

这时，根据已有安全数据进行安全分析，及时发现并处理威胁，就需要使用到可以大量实现实时日志存储及数据可视化于一体的平台——Elastic Stack。

然而，现代企业的安全数据，已随着日益蓬勃发展的信息网络技术而迅速膨胀，对海量安全数据的采集，处理，存储，查询等正日益困扰着企业安全分析团队。而 Elasticsearch 正是为应对海量数据的采集和检索而生的，将 Elasticsearch 应用于安全分析领域，可以非常便捷高效地解决安全分析领域，海量数据的存储和检索问题。

第一部分是先配置好不同安全产品或服务器的监控日志的 syslog 转发；
第二部分则是将监控数据从监控系统中收集到 Logstash 或 Beat，它还负责对监控数据进行拆分、转换的职责；
第三部分是用于存储监控数据的到Elasticsearch集群，我们借助 Elasticsearch 冷热模型，延长了监控数据的保存时间；
第四部分是将处理过的数据进行可视化展示，通过分析和关联多种安全产品数据，将庞大的安全事件降噪为真实的威胁事件，并且实现定时或实时告警，方便企业的安全运维人员可以在第一时间发现威胁并采取相应处理措施。

数据收集

安全分析的第一步当然是建立各类数据收集，而数据来源的多种多样，决定了我们收集时使用的方式。

轻量级的数据采集工具 Beat

Elastic Stack 中的 Beat 工具包含了丰富的数据采集工具，可以十分轻量且便捷的应用于各种数据的采集场景，下表是目前安全分析中需要采集的各类数据对应该采用的 Beats 方式：

数据类型	来源	采集方式
网络数据	网络监控，抓包等	Packetbeat, Filebeat
应用数据	日志	Filebeat
云端数据	接口，日志	Functionbeat, Filebeat
系统数据	系统调用，日志	Metricbeat,Auditbeat, Winlogbeat, Filebeat Osquery module
设备运行状态数据	日志	Heartbeat

Elastic 的开源性质决定了它没有太大的局限性，所以 Elastic 不仅仅提供了官方 Beats，还有大量的社区贡献的 Beats，用户还可以根据自己的需要开发自定义Beats，完全可以满足安全分析对各种数据源的采集需求。

ELK 中不可或缺的L（Logstash）

在网络安全中数据的多种多样，往往会分散或集中地存在于不同的系统中，或常见或不常见的。Logstash 作为一个日志聚合器，可以收集和处理来自几乎任何数据源的数据，它可以过滤、处理、关联，并且增强它收集的任何日志数据。

以下是一段360天擎的日志。

<6>{"version":"\u5929\u64ce6.6.0.4000","log_name":"\u6f0f\u6d1e\u7ba1\u7406","log_id":"82a40dbab698e5b6049d22071db2c517","create_time":"2020-02-28 10:40:11","ip":"42.101.64.215","report_ip":"192.168.1.107","mac":"3cf0117b5d27","gid":16777228,"work_group":"abfchina.local","content":{"name":null,"type":null,"action":"\u7528\u6237\u5378\u8f7d\u6f0f\u6d1e\u8865\u4e01","kbid":"4504282"}}

{
    "version": "天擎6.6.0.4000", 
    "log_name": "漏洞管理", 
    "log_id": "82a40dbab698e5b6049d22071db2c517", 
    "create_time": "2020-02-28 10:40:11", 
    "ip": "42.101.64.215", 
    "report_ip": "192.168.1.107", 
    "mac": "3cf0117b5d27", 
    "gid": 16777228, 
    "work_group": "bayu.local", 
    "content": {
        "name": null, 
        "type": null, 
        "action": "用户卸载漏洞补丁", 
        "kbid": "4504282"
    }
}

针对这种未解码的 JSON 嵌套的日志，首先我们可在数据进去时，设置好解码格式，再使用到JSON 模块进行对字段的拆分，再选择存放到 Elasticsearch 中，解析如下：

nput {
  syslog {
    timezone => "UTC"
    port => "514"
        tags => "syslog"
    codec => plain{
                charset=>"GBK"
        }
  }
}
filter {
        grok { 
               match => ["message", "<\d?>%{GREEDYDATA:log_json}"] 
  }

          json {
               source => "log_json"
  }
        mutate {
            add_field => {"[source][ip]" => "%{report_ip}"}
            add_field => {"[destination][ip]" => "%{report_ip}"}
}
}
output{
        elasticsearch {
                index => "360tq-%{+yyyy.MM}"
                hosts => ["localhost:9200"]
                user => "xxxx"
                password => "xxxx"
        }
}

数据标准化

不同来源的数据中表示相同含义的字段，在名称、类型上各不相同，这就导致了在进行数据检索分析时，为了检索不同数据源中的同类数据，可能要兼容性地写多个查询条件，这给数据分析带来了不小的麻烦。

为了解决这个问题，Elastic 建立 ECS(Elastic Common Schema) 项目，采用专业的分类方法，对字段进行统一命名，且 Elastic 生态相关组件，均遵循这一命名规格，使得对不同数据源的检索得以简化。

同样是以上 360 天擎的日志，其日志字段被 Logstash 的 JSON 解析器拆分之后的字段与 ECS 后的字段对比如下

原生字段	ECS后
create_time	event.created
log_id	event.id
log_name	event.category
ip	source.nat.ip
client_name	host.name
login_user	user.name

经过对字段的处理，字段的统一命名，便大大的提高了各类日志源之间的关联性。

ECS 不仅对字段的名称进行了规范，对字段的类型也进行了定义。在安全分析中，对IP的关联查询频次较高，以下是 ECS 对 source 的部分字段的定义

字段	定义	类型
source.ip	IP address of the source (IPv4 or IPv6).	ip
source.port	Port of the source.	long
source.domain	Source domain.	keyword
source.mac	MAC address of the source.	keyword

威胁事件与告警

实现异常自动发现，最直接的方式便是基于阈值规则的监控和告警。

Kibana Detection 模块：

Elastic 官方在 Kibana v7.3 之后推出了 SIEM APP后，更名为 Security app ，为安全分析团队提供了一个专用的集成化交互工作空间，数据可通过 Beats 模块和 Endpoint agent 发送到 Elasticsearch。使用 Detection 功能创建和管理规则，并查看这些规则触发的告警。

除了可以使用 Elastic 预先构建的规则之外，还可以自定义规则，创建规则警报时，可以使用 Kibana 的 Alerts 和 Actions 发送通知，通知可以通过 Email、PagerDuty、Slack 和 Webhook 发送。

IXtra邮件告警：

最早期为了实现定期查询 Elasticsearch 数据、判断是否满足特定条件、发送HTML邮件，衍生了 IXtra Web 应用。

IXtra 应用是由一组邮件告警 Python 脚本发展而来，经过不断地升级迭代，现阶段 IXtra 的主要功能是事件监控，通过连接多个不同的 Elasticsearch 集群，可以集中地对这些集群进行监控和告警。

当集群内某个索引满足告警阈值内条件时，即产生告警。但一旦这些告警产生大量噪音时，IXtra的聚合阈值型查询（聚合后重复出现次数大于阈值），则可以发挥到降噪作用。

除此之外 IXtra 也可以在一个 Elasticsearch 集群内建立两个查询（同时满足），进行组合型查询。并且所有查询后的结果，都会自动根据预设的规则分组、影响程度、紧急程度和标签等通知到安全运维人员，另外 Ixtra 还可将告警的内容写入至指定索引、自动将告警内容，提交到威胁情报库进行调查，并且可以自动将告警事件通过 API 方式在工单（Trello、Jira等）系统创建 ticket 等功能。

具体的工作流程图如下：

大大简化了安全运维人员的手动操作部分、提升安全运维人员的工作效率。

扮演的角色

经过以上的阐述，希望您大致可以了解到，其实 Elastic Stack 本身并不是一个传统意义上的SIEM（Security information and event management）平台，而是我们这些具有专业素养的安全服务行业的人员，利用 Elasticsearch 本身的性质，DIY 搭建一个具有 SIEM 基础功能的平台。完整的 SIEM 解决方案，包含从各种数据源收集信息，长时间保留信息，在不同事件之间关联，创建关联规则或警报，分析数据并使用可视化和仪表板监控数据的能力。

随着安全数据的不断暴增，传统的安全分析方法，对于企业安全问题的定位和解决越来越显得力不从心。Elastic 作为当前主流的大数据存储和检索引擎，由于开源具有最佳的价格，其优势使得其对解决当前安全分析领域面临的问题，有得天独厚的优势。

它简化了安全操作工作流程，并通过从业人员驱动的关联性，帮助从业人员最大化数据见解。

安全团队受益于涵盖广泛安全用例的多种检测和调查方法。将基于 EQL（弹性安全检测引擎中高级关联背后的技术）的关联与基于机器学习的检测，指标匹配类型检测规则，以及云规模的第三方上下文相结合，可以实现更全面的安全策略。

而 Elastic 团队也在这方面不断发现、提供了一套完整的解决方案，使得安全分析团队在使用Elastic 进行安全分析变得更得心应手。

结语

无论一款工具多么强大，都可能存在这样或那样的不足，从来都不存在可以“一劳永逸”的工具。想要真正最大化实现工具的性能，还需要根据自身需求和具备的实际条件来进行选择，而Elastic Stack 则更适合那些拥有员工，技能和耐心的企业，自行创建解决方案。

当然，寻找一个实力相当的 SIEM 供应商，提供的全面 SOCaaS（SOC-as-a-Service）的快速部署和响应事件，也是个不错的选择。

近来，越来越的企业为避免过多一次性投资的基础上，实现全方位全时段的安全保障，更愿意寻求第三方安全托管机构的 724 SOCaaS 服务。同时，由于夜间被打扰的概率更小，其实 724SOCassS 服务更适合做一些专注需求高的特殊工作，例如漏洞的深度分析、网络情报分析等。

另外，中型市场公司与大型企业，具有相同的安全需求，而没有大型团队和预算，SOC 可以很好的解决这一难题。

码农公寓