ELK实际上是三个工具的集合，Elasticsearch + Logstash + Kibana，这三个工具组合形成了一套实用、易用的监控架构，很多公司利用它来搭建可视化的海量日志分析平台。
Kibana是一个优秀的前端日志展示框架，它可以非常详细的将日志转化为各种图表，为用户提供强大的数据可视化支持。
4. ELK Stack
对于日志来说，最常见的需求就是收集、存储、查询、展示，开源社区正好有相对应的开源项目：logstash（收集）、elasticsearch（存储+搜索）、kibana（展示），我们将这三个组合起来的技术称之为ELKStack，所以说ELKStack指的是Elasticsearch、Logstash、Kibana技术栈的结合。
如上所述，SIEM系统涉及汇总来自多个数据源的数据。这些数据源将根据你的环境而有所不同，但是你很可能会从应用程序，基础结构级别（例如服务器，数据库），安全控制（例如防火墙，***），网络基础结构（例如路由器，DNS）和外部安全数据库（例如线程供稿）。
这需要ELK Stack非常适合处理的聚合功能。结合使用Beats和Logstash，你可以构建由多个数据管道组成的日志记录体系结构。 Beats是轻量级日志转发器，可以用作边缘主机上的代理以跟踪和转发不同类型的数据，最常见的beat是用于转发日志文件的Filebeat。然后可以使用Logstash汇总节拍中的数据，对其进行处理（请参阅下文），然后将其转发到管道中的下一个组件。
由于涉及的数据量很大，并且要利用不同的数据源，因此很可能需要多个Logstash实例来确保更灵活的数据管道。不仅如此，还需要部署一种排队机制以确保处理数据突发，并且管道中各个组件之间的断开连接不会导致数据丢失。 Kafka通常是在此上下文中使用的工具，安装在Logstash之前（也使用其他工具，例如Redis和RabbitMQ）。
因此，仅ELK堆栈就无法满足你的业务需求，并且生成的数据会不断增长。打算将ELK用于SIEM的组织必须了解，将需要部署其他组件来增加堆栈。
收集数据并转发数据当然只是Logstash在记录管道中完成的工作的一部分。在SIEM中，另一项至关重要的任务（也是一项极为重要的任务）是处理和解析数据。
上面概述的所有那些数据源类型均以不同的格式生成数据。为了在下一步（搜索数据和分析数据）中取得成功，需要对数据进行规范化。这意味着将不同的日志消息分解为有意义的字段名称，在Elasticsearch中正确映射字段类型，并在必要时丰富特定字段。
不能过分夸大这一步骤的重要性。如果没有正确的解析，则当你尝试在Kibana中分析数据时，数据将毫无意义。 Logstash是支持此关键任务的强大工具。 Logstash支持大量不同的过滤器插件，可以分解你的日志，用地理信息丰富特定字段，例如，放置字段，添加字段等。
同样，诸如SIEM系统所需的日志记录架构可能会变得复杂。具体来说，将Logstash配置为处理各种日志类型将需要多个Logstash配置文件和Logstash实例。复杂的过滤器配置导致繁重的处理过程会影响Logstash性能。监视Logstash管道很重要，并且监视API（例如用于标识具有高CPU的Java线程的热线程API）可用于此目的。
从不同数据源收集的日志数据需要存储在数据存储中。就ELK而言，Elasticsearch扮演着数据索引和存储的角色。
实际上，Elasticsearch是当今最受欢迎的数据库之一，它是仅次于Linux内核的第二大下载开源软件。受欢迎的原因有多种-开源，相对容易设置，快速，可扩展，并且拥有庞大的社区来支持它。
当然，部署Elasticsearch集群只是第一步。由于我们正在谈论要建立索引的大量数据，这些数据很可能会随着时间的推移而增加，因此用于SIEM的任何Elasticsearch部署都必须具有极好的可扩展性和容错性。
这需要许多特定的子任务。我们已经提到使用排队机制来确保在断开连接或数据突发的情况下不会丢失数据，但是你还需要关注关键的Elasticsearch性能指标，例如索引率以及节点JVM堆和CPU。同样，有监视API可用于此目的。容量规划也很重要，如果你部署在云上，则最有必要使用自动扩展策略来确保你有足够的资源来建立索引。
另一个考虑因素是保留。
为了进行事后高效的取证和调查，你将需要长期的存储策略。例如，如果你发现来自特定IP的流量激增，你将需要比较这些历史数据以验证其是否为异常行为。有些攻 击可能会在几个月后缓慢发展，作为分析人员，拥有历史数据对于成功检测模式和趋势至关重要。
不用说，ELK堆栈不支持开箱即用的归档功能，因此你将需要弄清楚自己保留数据的体系结构。理想情况下，不会对你的组织造成财务上的损失。
在Elasticsearch中收集，解析和索引数据后，下一步就是查询数据。 你可以使用Elasticsearch REST API进行此操作，但是很可能你将为此使用Kibana。
在Kibana中，使用Lucene语法查询数据。 例如，常见的搜索类型是字段级搜索。 例如，假设我正在寻找组织中某个人执行的操作所生成的所有日志消息。 因为我在所有数据源中标准化了一个名为``用户名''的字段，所以可以使用以下简单查询：
用户名：“ Daniel Berman”
我可以将此搜索类型与逻辑语句结合使用，例如AND，OR，NOT。
用户名：“ Daniel Berman”并且输入：登录ANS状态：失败
同样，如果你想使用ELK Stack for SIEM，则需要利用Logstash的解析能力来处理数据-而且你执行此操作的效果如何会影响你所点击的多个数据源的查询容易程度 成会。
Kibana以其可视化功能而闻名，它支持各种不同的可视化类型，并允许用户以自己喜欢的任何方式对数据进行切片和切块。 你可以创建饼图，图形，地理地图，单个度量标准，数据表等，并且结果非常有效。
这是在Kibana中为AWS环境构建的SIEM仪表板的示例：
在Kibana中创建仪表板不是一件容易的事，它需要你对数据以及构造日志消息的不同字段有深入的了解。 更重要的是，Kibana中缺少某些特定功能，例如可视化中的动态链接。 有解决方法，但是内置功能将是巨大的好处。
Kibana还不支持对象的安全共享。 如果你发现安全漏洞并希望与同事共享仪表板或单个可视化文件，则不会标记Kibana中的共享链接。 你可以在Kibana（X-Pack）之上或可以使用的开源解决方案之上实施一些商业附加组件。
SIEM中的另一个关键要素是事件关联。 正如我们在上一篇文章中已经定义的那样，事件关联是将来自不同数据源的信号连接成一种模式，该模式可能表示安全漏洞。 相关规则定义形成此模式的事件的特定顺序。
例如，可以创建一条规则来识别在特定的时间内从特定IP范围和端口发送多于x个请求的时间。 相关规则的另一个示例将查找异常数量的失败登录以及特权帐户的创建。
这些关联规则由各种SIEM工具提供或针对不同的攻 击场景进行了预定义。 ELK Stack当然没有内置的关联规则，因此分析人员可以根据使用Logstash进行的解析和处理，使用Kibana查询在事件之间进行关联。.
没有警报，关联规则毫无意义。 SIEM系统中的关键要素是，在识别到可能的攻 击模式时被提醒。
继续上面的示例，如果你的系统记录了来自特定IP范围的大量请求，或者异常数量的失败登录，则需要将警报发送给组织中的正确人员或团队。 速度至关重要-发出通知的速度越快，成功缓解的机会就越大。
ELK Stack以其开放源代码形式，没有附带用于警报的内置机制。 要添加此功能，需要使用警报插件或附件来增强ELK Stack。 同样，X-Pack是一种选择。 另一个选择是添加ElastAlert-一个可以在Elasticsearch之上添加的开源框架。
发现问题，分析师提醒。 现在怎么办？ 你的组织对事件的响应程度将决定结果。 SIEM系统旨在帮助安全分析人员采取进一步的措施-包含事件，在必要时将其升级，缓解并扫描漏洞。
ELK Stack在帮助分析人员识别事件但管理事件方面无能为力时非常有用。 即使在堆栈的顶部实现了用于警报的附加组件，也需要一种用于管理已触发警报的方法，以进行有效的事件管理。 否则，可能会淹没警报并在重要事件中丢失。 自动化升级过程和创建票证对于有效的事件处理也很重要。
那么，ELK堆栈可以用于SIEM吗？
这个问题的答案很简单。 由Logstash，Elasticsearch，Kibana和Beats组成的原始形式-ELK Stack并不是SIEM解决方案。
让我们总结以上要点：
尽管ELK Stack是用于集中式日志记录的功能非常强大的工具，但它不能按原样用于SIEM。 缺少内置的警报功能，关联规则和缓解功能-ELK Stack无法完成安全分析师所需的完整工具箱。
当然，ELK Stack可以增加其他平台和服务。 这正是市场上几种开源SIEM解决方案所做的。 但这需要组织进行巨大的工程壮举。 将ELK Stack与其他附加组件和平台融合在一起所需的大量资源和技术知识，更不用说财务成本了，因此选择了商用SIEM。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
