供安全工程师实用的SOC模型

1、背景

---

---

现在，安全概念满天飞，什么安全运营中心（SOC）、威胁情报（TI）、态势感知等等不一而足，这些概念及其背后表明的安全思想都很好，不过不少产品为了迎合国内的工做汇报都作成了不少Dashboard，一来很酷炫，二来确实能看出趋势，方便决策。可是自己不适合工程师去处理问题，不适合一线工做人员处理具体的安全事件。因此简单的参考和设计了一个SOC模型，用来便于一线的安全人员去工做。

2、总体架构

---

---

架构图

---

名词解释

---

传感器

---

传感器在这里是各类常见的网络安全设备（例如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，方便汇报和领导决策。