浅谈TheHive平台在安全运营工作中的落地
背景
随着企业安全建设的不断完善,信息安全的工作也进入了Happy(苦逼)的运营阶段。谈起安全运营工作,自然避不开事件响应这个话题。对于安全事件响应而言,我们时常会需要进行跨部门的协作。并且在某些事件中,我们甚至需要进行持续的跟踪与排查。因此,在事件的响应过程中,对于每一个响应步骤的记录显得尤为重要。它可以帮助我们在事件解决后,将经验教训纳入其中,加强整体安全能力。另一方面从自动化的角度来说,我们也应该考虑如何将响应过程转换为可被复用的Playbook,用以快速应对攻击,从而缩短感染攻击到遏制攻击的时间。
下面来说说我这的痛点,或者也可以说是我们在运营过程中所需要解决的一些问题:
- 如何在事件响应过程中记录每一个响应步骤所花费的时间?这些任务的处理时间,将会直接影响到我们后期MTTD与MTTR的计算。
- 如何从安全事件中提炼Playbook?对于重复可被流程化的过程,自动化才是王道啊。
- 面对各种“骚”操作的攻击手法,如何提供更多可定制化的插件给安全分析人员使用,用以提升安全分析的效率?
- 如何快速的与现有的安全设备进行联动,并及时止损。
- 通常安全事件会涉及跨部门协作的情况,我们如何快速就此次事件展开分析并及时与协作部门之间同步事件进展。
安全事件响应平台 - TheHive
我最终选择了*TheHive* 安全事件响应平台来协助我进行日常的安全运营工作。TheHive不同于SIEM这类的产品,它主要对接的是需要被真实响应的事件。个人粗略汇总了一下它的特点:
- 融合协作:TheHive将安全事件视作Case,提倡多人、跨部门之间的协作。通过分享机制,可以快速与协作部门之间同步安全事件进展。
- 成本度量:TheHive支持记录每个Case、Task的时间成本开销。可以帮助我们更好的去度量现有的MTTD、MTTR指标,也为我们后期去优化指标提供了重要的依据。
- 快速响应:在事件响应的过程中,你会需要对已有的数据进行分析,并迅速提供补救措施来阻止攻击。TheHive的Cortex组件支持对数据进行快速的分析,并将已确认的IoC自动化推送到现有的安全设备完成与SIEM、WAF、FW、EDR的联动。
- 效率提升:对于可被流程化的响应过程,必然是需要自动化的,也就少不了日常Playbook的积累。那么,Playbook从何而来?我们可以采用TheHive去记录每一次的安全事件响应的过程,并通过Task的形式去拆分需要协作的事项以及响应的步骤,利用这种方式帮助我们去积累Playbook。
TheHive集群部署
由于篇幅的关系,这里主要介绍的是采用TheHive集群时需要调整的一些配置。至于如何安装TheHive,请参考:Step-by-Step guide。如果只是为了测试的话,可以直接用官网提供的Docker或者VM镜像。
根据官方文档介绍,TheHive集群涉及4个部分。以下将会分别说明当采用TheHive集群时,TheHive、Cortex、Cassandra、Minio需要做的调整。
Thehive
我们将节点1视为主节点,通过编辑/etc/thehive/application.conf
文件来配置akka组件,如下所示:
1 | ## Akka server |
Cassandra
集群配置
- 使用以下参数更新配置文件:
/etc/cassandra/cassandra.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16cluster_name: 'thp'
num_tokens: 256
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
data_file_directories:
- /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog
saved_caches_directory: /var/lib/cassandra/saved_caches
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "<ip node 1>, <ip node 2>, <ip node 3>"
listen_interface : ens160 # 监听的接口
rpc_interface: ens160 # 监听的接口
endpoint_snitch: SimpleSnitch- 删除文件
/etc/cassandra/cassandra-topology.properties
1
$ rm -rf /etc/cassandra/cassandra-topology.properties
- 使用以下参数更新配置文件:
启动服务
- 在每个节点上启动服务
1
$ service cassandra start
- 查询集群状态
1
2
3
4
5
6
7
8
9$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 192.168.199.35 449.33 KiB 256 100.0% 72e95db1-9c37-4a53-9312-76bd0b2e6ca7 rack1
UN 192.168.199.36 631.65 KiB 256 100.0% 4051f9d4-91de-43e5-9a4a-c3da46417830 rack1
UN 192.168.199.37 437.13 KiB 256 100.0% 8844626f-04c0-4dd3-855e-088935b8dc65 rack1初始化数据库
- 修改数据库默认密码(默认账户密码:
cassandra
/cassandra
)
1
2
3$ cqlsh th01 -u cassandra
cassandra@cqlsh> ALTER USER cassandra WITH PASSWORD 'HelloWorld';
cassandra@cqlsh> quit;- 确保所有节点上的用户账户都是一致的
1
2$ cqlsh <ip node X> -u cassandra
cassandra@cqlsh> ALTER KEYSPACE system_auth WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3 };- 创建名为
thehive
的KEYSPACE
1
cassandra@cqlsh> CREATE KEYSPACE thehive WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3' } AND durable_writes = 'true';
- 创建角色
thehive
,并授予thehive
权限(选择密码)
1
2cassandra@cqlsh> CREATE ROLE thehive WITH LOGIN = true AND PASSWORD = 'HelloWorld';
cassandra@cqlsh> GRANT ALL PERMISSIONS ON KEYSPACE thehive TO 'thehive';- 修改数据库默认密码(默认账户密码:
TheHive 相关配置
由于最新的TheHive集群需要配合ElasticSearch进行索引,因此需要同步更新如下配置:
- 更新
/etc/thehive/application.conf
配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28db.janusgraph {
storage {
## Cassandra configuration
backend: cql
hostname: ["<ip node 1>", "<ip node 2>", "<ip node 3>"]
username: "cassandra"
password: "HelloWorld"
cql {
cluster-name: thp
keyspace: thehive
}
}
## Index configuration
index.search {
backend: elasticsearch
hostname: ["<es node 1>", "es node 2", "es node 3"]
index-name: thehive
# auth
elasticsearch.http.auth.type=basic
elasticsearch.http.auth.basic.username=elastic
elasticsearch.http.auth.basic.password=HelloWorld
# ssl
elasticsearch.ssl.enabled=true
elasticsearch.ssl.truststore.location=/etc/thehive/truststore.jks
elasticsearch.ssl.truststore.password=HelloWorld
}
}- 更新
Minio
由于我的文件存储是采用了Minio,所以这里需要配置一下。其实更简单的方式,你可以考虑使用S3。
- 创建目录
1 | $ mkdir /opt/minio |
- 创建用户
1 | $ adduser minio |
创建数据卷
在每台服务器上至少创建2个数据卷
1 | $ mkdir -p /srv/minio/{1,2} |
- 修改主机名
1 | $ vim /etc/hosts |
- 安装
1 | $ cd /opt/minio |
配置
- 新建配置文件
/opt/minio/etc/minio.conf
1
2
3MINIO_OPTS="server --address :9100 http://minio{1...3}/srv/minio/{1...2}"
MINIO_ACCESS_KEY="admin"
MINIO_SECRET_KEY="HelloWorld"- 新建系统启动文件
/usr/lib/systemd/system/minio.service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20[Unit]
Description=minio
Documentation=https://docs.min.io
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/opt/minio/bin/minio
[Service]
WorkingDirectory=/opt/minio
User=minio
Group=minio
EnvironmentFile=/opt/minio/etc/minio.conf
ExecStart=/opt/minio/bin/minio $MINIO_OPTS
Restart=always
LimitNOFILE=65536
TimeoutStopSec=0
SendSIGKILL=no
[Install]
WantedBy=multi-user.target- 新建配置文件
启动
1 | $ systemctl daemon-reload |
注:这里记得确认一下权限的问题,权限不对的话会导致进程起不来。
创建bucket
- 登录Minio http://minio1:9100
- 创建bucket
修改TheHive配置文件
/etc/thehive/application.conf
1 | ## Attachment storage configuration |
Cortex
修改 Cortex 配置文件
/etc/cortex/application.conf
这里注意,官方默认的配置文件有个小问题。当采用Elastic认证的时候需要将
username
修改为user
,否则会报错。
1 | play.http.secret.key="QZUm2UgZYXF6axC" |
Analyzers and Responders
由于在Cortex 3中实现了对dockerized分析器的支持,安装过程已经被大大简化。因此,我们不必纠结于安装插件时的Python或其他库依赖项这种头疼的问题。
- 安装Docker
1 | # Ubuntu 18.04 |
- 给Cortex账户运行Docker的权限
1 | $ usermod -a -G docker cortex |
- 更新配置文件
/etc/cortex/application.conf
,启用analyzers.json
1 | ## ANALYZERS |
如何创建插件
前面有说到Cortex组件默认已经集成了丰富的Analyzers与Responses插件,便于运营人员快速的对安全事件进行分析与响应。在实际使用过程中根据需求场景的不同,我们仍需要进行一些插件的定制化。如何创建插件,官网有很详细的文档介绍,请参考:How to Write and Submit an Analyzer。以下附上了部分新增的插件代码:
好了,废话少说,放“码”过来!!!
Analyzers - 插件
微歩在线
由于我们已经购买了商业(微歩在线)威胁情报,所以我们也和TheHive进行了整合。
- threatbook.py
1 | #!/usr/bin/env python3 |
- threatbook_analyzer.py
1 | #!/usr/bin/env python3 |
- ThreatBook_Compromise.json
1 | { |
- ThreatBook_Reputation.json
1 | { |
ProxyCheck
- proxycheck.py
1 | #!/usr/bin/env python3 |
- proxycheck_analyzer.py
1 | #!/usr/bin/env python3 |
- ProxyCheck.json
1 | { |
Responders - 插件
Cortex默认有一个插件(Mailer)负责发送邮件。使用了一下发现比较“坑”,首先不支持对多个收件人的发送,且当选择从Observables中发送邮件时,收件人竟然是mail类型的IoC。。。 WTF!别问我怎么知道的,它源码里就是这么写的。。。所以,自己动手丰衣足食!
主要功能:
- 在原有的基础上新增了批量发送的功能;
- 新增了支持对task logs数据类型的发送;
- 发送邮件时会附带当前case或者task的URL,便于收件人快速浏览问题;
- mail.py
1 | #!/usr/bin/env python3 |
- Mail.json
1 | { |
Threat Intelligence
其实默认TheHive是推荐与MISP进行对接实现情报的feed。由于我们自建了威胁情报库,所以写了一个Responders插件,帮助在分析时提交IoC情报。这边代码就不上了。给出一个提交的用例:
1 | { |
如何启用插件
加载插件
- 插件路径
-
/etc/cortex/Cortex-Analyzers/analyzers
/etc/cortex/Cortex-Analyzers/responders
-
1 | $ ll /etc/cortex/Cortex-Analyzers/analyzers |
修改配置文件
/etc/cortex/application.conf
建议大家将新增的插件与官方的插件区别开,这样后期也便于维护。
1 | ## ANALYZERS |
启用插件
Analyzers
- ThreatBook - Analyzers Config
![Analyzers Config](/Analyzers Config.png)
- ThreatBook - Analyzers
Responders
- Mail - Responders Config
![Responders Config](/Responders Config.png)
- Mail - Responders
使用场景
下面来说一下我们都用TheHive做了哪些,刚开始使用场景其实并不多,还需要后期的摸索。
提前创建好模板,例如:按照Playbook的形式提前创建好。便于后期快速引用
分析周报模板
按照周为单位创建Case,以天为单位创建Task。
应急响应模板
可以参照应急响应阶段来创建
引用模板
事件运营:SIEM(Alarm) -> TheHive(Alert)
TheHive与SIEM做了对接,主要将两种类型的告警自动化的推送到了TheHive上。
第一种:需要研判的安全事件。例如:基于内->外的NetFlow告警事件(异常端口访问,周期性请求等等)、敏感信息泄漏告警事件(黑客论坛监控、GitHub监控)。通常这类事件需要进行二次确认的,所以会选择通过TheHive来记录整个事件的处理过程。
第二种:需要重点关注的安全事件。例如:EDR上的告警事件,命中C2指标的情报告警,通常这类事件需要第一时间去响应。
- 在事件响应的过程中我们可以借助Cortex Analyzers的能力协助我们进行数据分析。如:同时调用多家情报厂商接口进行查询,丰富化数据信息(查询PDNS信息、Whois信息、CMDB等),联动SIEM查询近一段时间内的安全事件等。
- 对于已“实锤”的指标,可通过Cortex Responders组件与安全设备进行联动,批量下发阻断策略,及时止损。
- 对于跨部门协作的问题,可利用TheHive去同步事件响应的进度,包括在同一个Case里讨论该问题。
- 通过对响应过程的记录,可更好的帮助我们去优化安全事件响应流程,并同时帮助我们积累Playbook,为日后的自动化做铺垫。
规则运营:SIEM(Alarm、Alert)-> TheHive(Case)
主要是将分析时发现的规则误报以及漏报的情况,通过手动提交Case的形式发送到TheHive上。例如,在SIEM上发现了某个告警存在误报的现象,通过SIEM提交该告警信息给指定负责人,系统会自动将邮件以及Case转到该人员名下。
- 通过SIEM推送至TheHive,并通知分析人员进行规则优化。
- 提交Case并邮件通知
- TheHive
日常事项:
安全分析周报
- 以周为单位创建Case
- 以天为单位创建Task
- 告警与Case相关联
- 批量分析IoC
- 分享给需要关注的小组
写在最后:
如果你有关注过开源解决方案的话,相信你一定有看到过一些TheHive与工作流(**Shuffle、n8n)组件整合的方案。不难看出,TheHive擅长的是事件响应与分析,这是一种半自动化的形式。通过与工作流组件的对接,你会发现这就是一个“散装*”版的SOAR。商业的SOAR相比开源的SOAR多了一个“作战室”的概念,这个功能与TheHive就会有那么一些相似。例如:你可以在作战室中分析某个IP的情报信息,或者联动现有安全设备对某个IoC进行响应的操作。这些功能其实就是对应到了TheHive中的Analyzers与Responders*的功能。
我个人觉得TheHive这种“半自动化”的形式,可以很好的与SOAR进行互补,相信与SOAR对接后会有更多的“价值”被体现出来。例如:在分析任务中可按照场景的不同有选择的调用SOAR的PalyBook,并将响应结果feedback至TheHive中。其实TheHive上还有挺多东西值得说的,一次也写不完。更多东西还需要我们根据实际场景再去挖掘,“思路”很重要!