一、前言
本文不会涉及具体的平台搭建步骤以及具体的方案架构讨论，在这里只是想和大家分享一下我们在运营当中遇到的一些问题以及解决的思路，可能文中提及的技术架构也并非适合每一位读者。闲暇时写下本文，仅仅希望能够帮助在甲方企业和机构从事安全运营工作的同仁们获得一些启示和灵感，为大家提供更多的解决方向。本文前面的章节会简要给大家介绍下SIEM产品目前在市场上的几种分类和应用情况，接着会给大家介绍下我们为了解决一些运营中的难题，如何利用ELK搭建的一套简化版的SIEM平台，在文末我们会介绍下我在安全运营工作当中如何利用这套平台解决一些问题，帮助大家了解如何实现安全风险检测、安全监控告警、与威胁情报关联等。希望本文可以抛转引玉，帮助大家的打开思路。
1X01 SIEM的简介
首先给大家简单介绍下什么是SIEM，SIEM在我们企业的信息安全的日常运营中能带来什么帮助。SIEM英文全称是：security information and event management，从字面理解就是安全相关信息和事件的管理平台或系统。我们安全运营人员在日常的工作中每天会面对海量的安全告警日志，完全依靠人工的分析进行处理所耗费的人力成本是巨大的。而且实际上面对企业的业务更加的互联网化，黑产团伙因为有利益的驱使，攻击也是层出不穷，我们的运营人员完全依靠人工去分析每一条告警日志，并且从海量日志中找出真正对我们有价值的信息也是低效的，实际上根本无法真正实现。那么这时候我们就需要有这样一个平台，把我们纷杂的告警日志（WAF、IPS、firewall、抗D设备、业务日志等）汇聚到一起，通过一系列的风险分析方法把我们最想关注的告警信息提炼出来以告警的形式发送给我们的安全运营人员，从而能够快速及时的进行下一步响应。另外也可以通过规则区分出一些高危的风险事件，通过与防火墙、WAF设备等一些防护系统的联动实现对风险事件的自动化响应。SIEM系统将大大提高安全风险事件的响应速度度，实现繁杂告警信息的关联分析和自动化响应，事件的工作流管理可以帮助运营人员将最关注的事件展现出来并持续跟踪事件处理的全生命周期，通过特征模型、数据分析甚至机器学习等新的技术不断优化我们的安全事件的风险发现、检测告警以及自动响应机制。
目前市面上常见的SIEM一般大概分为几类：国内外厂商的商业软硬件、（半）开源的SIEM软件、利用开源技术或自研自己建立SIEM系统。
国内的商业产品一般主要集中在几个比较大的安全厂商，但整体来说产品成熟度以及适配性不好，因为甲方客户的业务环境和所选用的设备型号复杂多样，大部分都需要跟着整体的安全集成项目进行驻场开发，项目周期一般都较长，且一般项目结束后也需要长期驻场运维以适配客户环境的不断变化。国内的大型国企、*部门、大型运行商因为自身技术能力不足很多会选择采购这样的一套SIEM产品。
国外的产品在国内企业用的比较多的有Splunk、HP ArcSight等产品，这两家都是美国的软件厂商，Splunk并不是为解决信息安全日志收集和分析的专用产品，它原本最主要的用途是通过收集业务的应用数据，给市场分析人员乃至公司决策层提供有力的数据支撑，开放的社区可以提供丰富的插件，能够满足绝大多数的日志收集和分析的场景，方便的报表生成和漂亮的报表展示也是它比较亮眼的地方，而且在数据检索的性能上也是可圈可点，唯一的不足就是——贵，是真的很贵。HP的ArcSight相比就更偏重安全分析和告警的单一场景并且同样价格不菲。除此之外，对于安全要求比较严格的单位，比如涉密单位、金融行业等，由于保密性要求也无法采购这几款产品。
splunk
近几年国外陆续开源或者半开源了一些SIEM软件，比较常见的有OSSIM、OPENNMS等，这两款产品算是比较成熟，功能也比较齐全的，以OSSIM为例，OSSEC、suricata等开源的安全软件统统可以接入进行管理，还有资产的识别发现，安全资产管理等。如果是“一个人的安全部”，那么这些开源SIEM是个很不错的方案。
OSSIM界面
1X02 ELK-日志收集和数据分析的利器
ELK实际上也是个英文缩写，分别代表了三个不同的开源软件：“E”：Elasticsearch、“L”：Logstash、“K”：Kibana。
Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
Kibana 也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。
另外还有一个轻量级的日志收集工具filebeat，可以通过在服务器上安装agent，由agent将日志收集后再传送给logstach，filebeat占用资源非常小。
使用ELK这套集中式的日志系统作为自建SIEM的底层技术实现方案，它的优势在于能够采集多种来源的日志数据、组件全部开源具有很强的横向扩展能力，支持UI分析和监控告警的配置，配合起来使用能够满足安全运营人员的大多数需求和业务场景。
ELK工作示意图
思科之前在BroCON大会上发布了一个开源的opensoc安全大数据分析架构，该架构就采用了大量的开源技术，其中在存储层也包括了ELK“三大件”中的elasticsearch。
opensoc架构图
二、需求场景梳理
前文给大家介绍了SIEM和ELK的一些基本概念，实际上我们最初也并没有想完全自研搭建一套SIEM系统。SIEM的概念在安全行业的历史不算短，从最初的SOC到SIEM以及最近两年各大安全厂商都在热炒的SOAR，虽然涵盖的安全功能和理念几经演变，但基本的目标和方向都是解决安全运营中的一些问题，提升安全运营效率，降低安全运营成本。任何脱离了实际需求和场景的技术实现都是耍流氓，因此我们在搭建平台之前，最重要的就是理清实际安全运营和应急响应中的需求，真正解决运营中的一些痛点。
在下面，我列出我们在工作中迫切的一些需求点，并按照优先级分成了一期和二期：
2X01 基础需求--第一阶段
1. 不同日志源、不同日志格式的安全设备告警日志可以统一收集、展示、检索。
2. 全流量业务日志的收集、展示、检索。
3. 根据日志内容可以进行分析规则的制定，配置告警规则。
4.不同日志源的关联分析
5.安全运营数据的报表展示
以上这些都是日常运营中对日志分析和风险数据挖掘的最基础功能，无论后续我们采用什么样的技术方案，这些基础的功能是必须得到满足。我们也基本明确了第一阶段的平台建设以数据收集、展示和基本的分析、告警等功能为主。
2X02 扩展出的需求和场景（二期）
除了一期的这些基本的需求和场景，在一期完成，初步实现安全运营数据收集的基础上，我们召集人员进行头脑风暴，收集二期的建设需求，以实现平台和产品的不断迭代。下面是我们二期收集的需求：
1.通过日志的告警信息与防火墙、waf等设备进行联动，实现自动化的拉黑。
3. 对Http业务日志可以通过检测规则进行准实时的监控，不同事件类型可以分别实现邮件、短信告警、自动与防护设备联动等。
4. 对新上线资产通过全流量日志进行被动的发现，甚至请求响应报文中的一些特征可以作为识别新的资产类型的一种辅助手段。
5.可以通过基于全流量日志的监控规则，作为WAF或其他防御手段是否有效的一种验证手段。
6.基于全流量日志可以做基于接口的频率监控，作为cc攻击、暴破、批量猜解等攻击的一种发现手段
7.全流量日志结合威胁情报进行预警，内部产生的各种设备日志也可以作为内部的情报为风控系统等提供数据参考。
理清楚上面的这些需求点，我们接下来最重要的就是选择什么样的技术方案可以实现这些功能。
三、平台搭建
下面这张图是我们二期整体需求基本完成后的架构示意图。一期主要完成了数据采集层、数据处理层、数据存储和展示交互的部分功能。二期完善了watcher监控告警功能、规则引擎部分。
数据采集层：我们对于诸多安全设备的告警日志、ldap、邮件服务等服务日志的采集，采用syslog发送至rsyslog服务器进行统一收集。业务流量日志的还原是通过在汇聚层交换机进行流量镜像，镜像流量发送至packetbeat服务对http流量的网络数据包进行还原，然后发送至kafaka服务进行下一步处理。
数据处理层：syslog日志由rsyslog收集后，会发送给摆渡程序，由摆渡程序进行数据格式化、数据脱敏、解码、纠错等一系列处理。同样http流量还原日志也会先经packetbeat处理后发送给kafaka集群，再由kafaka集群转发给摆渡程序进行数据处理。
数据存储：数据经由摆渡程序处理后，最终会写入es集群。
数据展示交互：es的数据检索除了提供的API接口，还有很多开源的可视化工具。为了实现安全的登录认证、审计、告警邮件、webhook、图形化数据展示，我们首先要安装xpack，然后在用户交互这块我们选用的是kibana。通过kibana，我们用户可以进行数据检索、visual插件可以自定义很多满足用户需要的图表，图表类型还是很丰富的，像常见的饼图、柱状图、折线图、时序图都可以满足。另外还可以通过dashboard定制自己的仪表板进行攻击态势的展示。告警的配置，我们可以通过kibana的watcher组件来完成，通过在watcher里编写DSL查询语句，搜索匹配出我们想要的结果，然后调用webhook进行邮件告警、短信告警以及自动化安全防护联动脚本。
规则引擎：规则引擎是我们在一期实现后，进行的一个优化，主要是对全流量的http日志进行的入侵检测分析，添加了一些检测规则，实现准实时的入侵检测和监控，同时利用机器学习对cc攻击、撞库等频率特征明显的攻击进行检测。另外多数据源的日志通过威胁情报平台形成内部的情报结合评分体系实现关联分析和自动化的响应联动以及攻击链的展示等。
架构示意图
除此之外，实际在es集群和kibana搭建中也有不少的坑点，但本文主要目的是带给大家一个解决安全运营问题中的思路，故就不在这里详细展开讨论了。
四、平台在运营中的使用
正所谓“工欲善其事，必先利其器”，在平台的搭建完成后，安全运营中所需的数据都已经被收集起来，那么如何用好这样一个安全数据分析的利器，如何真正的能帮助到我们日常的安全运营工作就是至关重要的了。下面我们将结合安全运营中的一些具体场景，介绍具体的平台使用。
4X01 攻击溯源（日志查询检索）
首先这个平台给我们最直接的帮助就是无论是安全防护设备的攻击日志，还是全流量的http业务日志，我们都可以通过这个平台来进行查询，大大节约了我们依次登录不同的设备来查询获取日志的时间。另外我们二期建设的时候，结合威胁情报项目，将内外部情报的攻击标签（内部情报就是曾攻击过我们的攻击源，部分攻击类型可以作为内部的威胁情报进行标记）、源IP地理位置、是否是IDC或基站的IP、是否是我们自己的职场和IDC机房的出口IP，这些信息的补充可以大大节约我们溯源的查询时间。后续有时间可以给大家再介绍下我们威胁情报的建设，在这就不给大家展开了。
使用kibana查询全流量的业务日志
4X02 攻击态势展示（仪表板）
kibana上Visualize插件支持用户自定义制作展示的图表，支持折线、饼图、柱状、数字仪表盘等等丰富的模板。
新建图表支持的格式
我们可以通过仪表板插件，将不同的图表集中到一个页面中展示，也可以通过Embedded iframe将不同的图表集中到一个html页面中展示，还可以通过css调整我们想要的样式，十分灵活。下图中是我们自定义的一个展示大屏。
展示大屏
4X03 监控规则配置（watcher）
如上文所说我们所说我们二期建设中通过spark开发了规则引擎，其实我们在一期基于kibana的watcher就做了很多监控的规则，包括基于全流量http日志的攻击特征监控、接口超频监控、源自动拉黑、敏感信息监控等。
watcher的使用需要了解es的DSL语句，通过DSL我们对es中的数据进行检索和聚合操作，最后通过调用webhook，将我们触发告警的内容以邮件、短信发送给我们，也可以调用防火墙接口将源IP自动拉黑。DSL语法大家可以参考es的官方手册：https://www.elastic.co/guide/cn/elasticsearch/guide/current/_finding_exact_values.html
st2 rce\spring等检测规则举例
应用层攻击监控：应用层的攻击监控，我们主要是基于全流量http日志，packetbeat还原http包时会将请求和响应包组合到一起，我们的监控规则可以根据请求内容和响应内容两个维度来做。对请求内容：请求行、参数、请求头等进行特征匹配，实际上是对我们防护机制的一种验证机制，能帮助发现需要防护的资产是否在WAF或防火墙配置生效（还有新资产发现）、防护规则是否有效。对响应内容的监控更多的是对入侵成功的一种高危预警，另外还可以对敏感信息的泄露、违禁内容进行监控，提高对安全入侵事件的发现和响应速度。二期建设中，我们将大部分特征类型的规则都迁移到基于spark的规则引擎上，大大提高了监控的实时性。
规则引擎的日志
告警邮件
接口超频监控：对于cc攻击、爬虫、撞库这类没有明显攻击特征的风险，是我们一直比较头疼的，一直苦于没有比较好的发现手段。攻击者如果将攻击频率控制在我们的防护阈值之内（抗D设备基本无法发现防御流量并不大的cc攻击），就绕过了我们的防御规则。在一期平台搭建完成后，我们拥有了全流量的http业务日志，于是我们通过收集以及和业务方确认，将登录、注册、找回口令、修改口令、短信等重要业务域名的所有敏感接口进行了分类别的请求阈值监控。其他接口根据kibana查询的每日请求的平均频次，将阈值上调20%左右设置成统一的阈值。二期规则引擎我们建设的过程中，对于cc类攻击的监控采用监控阈值和机器学习相结合的方式，优化了告警的精确度。
重要防护设备日志的告警：之前因为设备厂商、型号不统一，告警形式也是多种多样。如今通过syslog收集安全设备和系统的告警日志，在kibana的watcher上可以根据告警的类别、级别、持续频率等维度进行邮件、短信告警，甚至可以通过webhook调用防火墙接口进行IP拉黑，实现自动化的安全事件的响应。下图为自动拉黑在es索引中的记录日志。
日志平台联动防火墙自动拦截的日志
新资产发现和防护有效性检测：我们通过脚本程序调用es的api接口，每天定时将24H内http全流量日志中request.host字段和资产库中的域名（公网Ip）进行比对，当发现新增的域名或公网Ip时立刻与扫描平台联动，启动新增资产的安全扫描任务，同时脚本发送测试payload验证waf防护是否有效，如无效则发送告警邮件，然后将防护资产关联日志中的数据：ng ip、域名或公网ip、响应中是否有应用指纹（tomcat、Apache、PHP等）、waf是否有效等写入资产库中。另外每月还会进行全量的waf有效性验证。
五、总结
一个好的安全工具和平台，从平台设计、开发搭建到投入使用，离不开安全运营人员的实际需求和对数据挖掘分析积累的场景和经验。说到底产品好不好，运营是关键，只有真正的运营起来，我们才能更多的发现优化的点，才能提出更有价值的需求点。希望上面这些内容可以对大家的工作带来帮助，也欢迎大家拍砖。