一、背景
如今，安全概念满天飞，什么安全运营中心（SOC）、威胁情报（TI）、态势感知等等不一而足，这些概念及其背后代表的安全思想都很好，不过很多产品为了迎合国内的工作汇报都做成了很多Dashboard，一来很酷炫，二来确实能看出趋势，方便决策。但是本身不适合工程师去处理问题，不适合一线工作人员处理具体的安全事件。所以简单的参考和设计了一个SOC模型，用来便于一线的安全人员去工作。
二、整体架构
架构图
名词解释
传感器
传感器在这里是各种常见的网络安全设备（例如IDS、WAF、FW、UTM、漏扫设备等等），或者各种应用系统或者蜜罐的日志输出模块，再或者镜像流量保存设备。总之就是和安全相关的各种告警、日志、流量数据都可以传到数据统一接收清洗平台，在这个地方箭头从传感器指向数据统一接收清洗平台，但不一定是传感器外发信息（例如syslog），也可以是开发者自己构造数据拉取引擎，通过原设备开放的API接口获取数据传输到数据统一接收清洗平台。
这里常见的传感器有：
- IDS（开源的Suricata，Snort，国内厂商启明优势产品）；
- FW（天融信的优势产品，国外平底锅的）；
- WAF（开源的ModSecurity，国内绿盟优势产品，国外的Rapid7的）；
- 漏扫设备（Nessus、Nexpose、国内绿盟的优势产品）；
- 应用系统输出模块就不在赘述；
- 镜像流量类设备（360企业安全天堤）；
- APT调查类设备（360企业安全天眼、态势感知，神州网云网镜等）
- 蜜罐（开源的Dionaea、Glastopf、ElasticPot，Cowrie）
- 终端安全软件（360安全卫士、天擎等）
数据统一接收清洗平台
数据统一接收清洗平台的作用就是接收数据，清洗数据，然后把清洗好的数据打入数据存储平台。为什么要清洗，是因为多来源数据的格式不同、字段名称不统一，只有清洗后才能统一存入数据存储平台，便于后面分析。所以整个流程中一般需要两个Logstash实例，一个消息队列。当然第一个Logstash实例也可以用带有数据清洗范式化功能的collector程序代替。所以这个地方一般的架构如下图。消息队列（Kafka、RabbitMQ）也可以用缓存数据库Redis。Logstash可以轻松的输入数据到消息Kafka和Redis，从二者中消费数据，监控新数据也很简单。
数据存储平台
这里实际上是一个大数据存储平台，为了方便检索和开源，选择Elasticsearch或是Splunk皆可。一般基于ELK整体解决方案，可以选择Elasticsearch。
智能分析平台
这是整个架构最核心的部分，一般是自研的分析引擎，从Elasticsearch中读取数据，按照自定义的规则分类、聚合、分析，然后再输出到一个消息队列中，然后再起一个Logstash实例去消费消息队列中的数据，反存入数据存储平台。这一步其实就是为了解决纷繁复杂的告警无法处理的问题，在这里可以过滤，检查、去重、筛选、聚合，输出最终可以处置运维的告警信息，彻底解放淹没在告警海洋中的安全工程师。
数据展示平台
这里我选择Kibana，因为也是基于ELK整体解决方案。Kibana方便展示，数据分析、适合工程师使用，也可以生成数据Dashboard，方便汇报和领导决策。