ES (Elasticsearch)是当前主流的大数据搜索引擎,具有扩展性好,检索速度快,近实时等优势,依托于ES的这些优势,其不仅广泛地应用于各种搜索场景,如日志检索,应用搜索等,在安全分析等领域也开始逐渐展现其强大的能力。 在传统安全领域,企业通常会借助防火墙,杀毒软件等为企业构造起一套固若金汤的安全防御体系,然而即使在如此严密的防护之下,仍然无法完全保证内部数据的安全,尤其是当面临内部威胁时。这时,根据已有安全数据进行安全分析,及时发现并处理威胁就显得尤为重要。然而,现代企业的安全数据已随着日益蓬勃发展的信息网络技术而迅速膨胀,对海量安全数据的采集,处理,存储,查询等正日益困扰着企业安全分析团队。 而ES正是为应对海量数据的采集和检索而生的,将ES应用于安全分析领域可以非常便捷高效地解决安全分析领域海量数据的存储和检索问题。使用ES进行安全分析的工作流如下图:
数据采集是安全分析的第一步,也是至关重要的一步。安全分析所需的数据来源多种多样,有网络数据,也有文件数据,有本机数据还有云端数据。Elastic Stack提供的Beat工具包含了丰富的数据采集工具,可以方便地应用于各种数据采集场景。下表是安全分析中需要采集的各种数据以及ES下对应的采集方式
数据类型 | 来源 | 采集方式 |
---|---|---|
网络数据 | 网络监控,抓包等 | Packetbeat, Filebeat |
应用数据 | 日志 | Filebeat |
云端数据 | 接口,日志 | Functionbeat, Filebeat |
系统数据 | 系统调用,日志 | Auditbeat, Winlogbeat, Filebeat Osquery module |
Elastic不仅提供了官方Beat,还有大量的社区贡献的Beat,用户还可以根据自己的需要开发自定义Beat, 完全可以满足安全分析对各种数据源的采集需求。
安全分析的数据来源多种多样,不同来源的数据中表示相同含义的字段在名称,类型上各不相同,这就导致了在进行数据检索分析时,为了检索不同数据源中的同类数据,可能要兼容性地写多个查询条件,这给数据分析带来了不小的麻烦。如下是一条Apache日志
10.42.42.42 - - [07/Dec/2018:11:05:07 +0100] "GET /blog HTTP/1.1" 200 2571 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"
在实际的安全分析中为了兼容来自不同数据源的数据可能要写出如下查询:
src:10.42.42.42 OR client_ip:10.42.42.42 OR apache2.access.remote_ip:10.42.42.42 OR context.user.ip:10.42.42.42 OR src_ip:10.42.42.42
为了解决这个问题,Elastic建立ECS(Elastic Common Schema)项目,采用专业的分类方法,对字段进行统一命名,且Elastic生态相关组件均遵循这一命名规格,使得对不同数据源的检索得以简化。 使用ECS标准后该日志的调整如下
字段名称 | 值 | 备注 |
---|---|---|
@timestamp | 2018-12-07T11:05:07.000Z | |
ecs.version | 1.0.0 | |
event.dataset | apache.access | |
event.original | 10.42.42.42 - - [07/Dec ... | 未修改的完整日志,供审计用 |
http.request.method | get | |
http.response.body.bytes | 2571 | |
http.response.status_code | 200 | |
http.version | 1.1 | |
host.hostname | webserver-blog-prod | |
message | "GET /blog HTTP/1.1" 200 2571 | 事件中重要信息的文本表达,用于在日志查看器上简要显示 |
service.name | Company blog | 您为此服务定制的名称 |
service.type | apache | |
source.geo.* | 地理位置字段 | |
source.ip | 10.42.42.42 | |
url.original | /blog | |
user.name | - | |
user_agent.* | 描述用户代理的字段 |
其他不同类型的数据源也通过ECS进行规范,此时查询语句便可简化如下:
source.ip:10.42.42.42
ECS不仅对字段的名称进行了规范,对字段的类型也进行了定义。如下是ECS对Destination的部分字段的定义
字段 | 定义 | 类型 |
---|---|---|
destination.ip | IP address of destination. Can be one or multiple IPv4 or IPv6 addresses. | ip |
destination.hostname | Hostname of the destionation. | keyword |
destination.port | Port of the destination. | long |
destination.mac | Mac address of the destination | keyword |
destination.domain | Destination domain | keyword |
destination.subdomain | Destination subdomain | keyword |
可以看到ECS会根据字段的特点为字段设置最符合其使用场景的字段类型,以优化其存储和查询。
除了对数据进行标准化以外, Elastic Stack中的Beat、Logstash、Elasticsearch等组件都可以对数据进行增强,根据现有环境或数据,通过数据处理衍生出一些相关数据,为安全分析提供更为直接详细的信息。如下是各组件提供的数据增强方式
组件 | 数据增强方式 | 说明 |
---|---|---|
Beats | processor | 可以对数据进行添加,移除,解析等操作,参考 |
Logstash | filter | 可以根据现有数据进行各种数据处理操作,参考 |
Elasticsearch | ingest pipeline | 可以根据现有数据进行个数数据操作,甚至通过脚本自定义处理方式,参考 |
海量安全数据的存储和检索在传统安全分析领域是一个非常棘手的问题,它们往往为了减少存储的数据量提高查询速度,不得不丢弃部分非核心数据,这很有可能在后期问题定位时产生数据盲点。而ES具有如下特点:
面对海量的安全数据,通过人为巡检的方式来发现数据异常已经成为一件很难实现的事情,而Elastic Stack作为一个完善的数据处理检索技术栈,在数据异常自动发现方面也有充分考虑。
实现异常自动发现最直接的方式便是基于阈值规则的监控和告警。Elasticsearch提供了Watcher功能: Watcher由Triger, Input, Condition, Transform, Actions等部分组成,其中
虽然基于阈值规则的监控和告警可以在很多场景下帮助安全分析人员发现一些不符合预期的情况,然而阈值的选择对告警的效果影响较大,阈值过高无法发现问题,阈值过低又有可能导致误报。为此Elasticsearch提供了Machine Learning功能 Elasticsearch的Machine Learning功能采用非监督学习方式,通过对历史数据的学习,并对未来数据进行预测,对于与预测数据不符的情况触发告警。
发现异常仅仅是安全分析工作的开始,为了进一步确认异常,定位异常产生的原因和详细链路,需要对数据进行各种各样的检索。ES作为数据搜索引擎,在数据检索方面提供了强大的支持
在进行安全分析发现一个威胁时,需要采取相应的行动,如将非法用户添加到防火墙中,发出告警邮件等。 Elasticsearch的Watcher内置了包括邮件,Slack在内的多种通知方式,另外还支持webhook, 用户可以将任意想要触发的动作以web服务的形式提供出来,当watcher对应的条件触发时,便会调用对应的WEB服务,执行用户定义的动作。
随着安全数据的不断暴增,传统的安全分析方法对于企业安全问题的定位和解决越来越显得力不从心。ES作为当前主流的大数据存储和检索引擎,其优势使得其对解决当前安全分析领域面临的问题有得天独厚的优势。而Elastic团队也在这方面不断发现提供了一套完整的解决方案,使得安全分析团队在使用ES进行安全分析变得得心应手,有的放矢。 ES的安全分析相关介绍及demo参考:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。