谈谈我对应急响应的一些拙见

应急响应有两个指标mttr和mttd，这两个指标衡量企业的应急响应能力，其实在乙方工作还有一个隐藏指标叫做客户预期，通常接到应急事件，前期和客户沟通后会确定几个事情，一是能不能做，二是怎么做，响应人员理清楚几个排查思路，一一去验证，当然随着排查分析的结果也可能会有新的思路。三是排查结果和客户的预期有无差距。如果有，就需要在前期介入的时候基于自己的经验去说服客户为什么这件事情做不到。举个例子，有一次应急响应事件，客户是接到集团通知，说是有系统有数据泄露情况，给了数据样本，客户拿着样本排查，发现有这个数据的系统很多，现场也没有部署端和流量侧设备。只有一个日志平台记录了所有主机上和web侧的所有日志，当时我们介入的时候对这个事件理了几个思路，业务逻辑漏洞、脱裤、开发主机失陷和内鬼，也和客户沟通了排查方向。随着排查的进行发现每个思路往深了做投入时间都是很多的，且不一定有产出，于是在做了第一天工作后，把目前的工作和初步结果整理了下同步给客户，同时调整了排查方向，最后找到了一个疑似的泄露点，交付的时候客户也算认可我们的工作。

参与了多次应急响应后，也发现目前工作上有一些问题，一是没有沉淀，一个事件处理结束后除了报告啥都没有，有时候A客户取证后，在B客户那里还是老操作再走一遍，没有形成针对性取证思路和参考文档。二是有时候会从失陷主机拿回来样本、日志，简单分析后也没有后续了，往后日志在硬盘里日复一日。三是通常情况下每台主机有个必要的工作就是基础排查项，一般来说都要看下，但现实是看启动项，日志后我们找到了入侵点，事件结果等，剩余的排查项目随着找到一个入侵点后就忽略了。关于忽略排查其他项有益有弊吧，弊端就是可能会遗漏信息，曾经笔者的一个同事在处理应急的时候意外发现了该主机很早之前也被入侵过，留有后门但不影响主机正常工作。

为了解决工作上的问题，近期阅读了不少国内外关于如何建设威胁分析平台文章，然后也尝试搭建了下。期间踩了不少坑，这里记录下。关于搭建分析平台的时候有几个诉求。

1.  复用开源，非从0开始

2.  扩展性强，可以对多个不同的类型进行检测

3. 应急响应中牵涉分析的主要有两块日志和流量，日志侧主要分析各种操作系统，中间件和应用的日志。流量侧分析主要依托suricata zeek或者snort规则，并且有很重要的一点http流量足够可视化，一般分析pcap都是wireshark，wireshark很强大，但是分析http流量的时候每次都要追踪流才能友好的看到http请求与响应，这点有点难麻烦。还有一个行为日志，应急的时候很少能拿到，主要是agent采集到的日志，包含了进程执行后调用的文件，网络行为，注册表等等，这种暂时不考虑。

4. 易上手，这也是最重要的一点。

基于上面的诉求，利用开源工具搭建了几个平台。

（1）securityonion是一个免费的开源平台，用于网络、主机和企业安全监控和日志管理，内置有TheHive、Playbook、Fleet、osquery、CyberChef、Elasticsearch、Logstash、Kibana、Suricata、Zeek、Wazuh和许多其他工具。本质上基于elk扩展的。下载后是个iso镜像，虚拟机直接搭建运行，搭建起来后支持导入evtx日志和pcap。这个平台pcap分析做的不是很好，另外有些大。

（2）splunk很强大，公司内部分析工具也用的这个，但是充钱才能使用完整功能。

（3）HELK，这个是基于elk搭建的分析平台。基于elk来做的，传日志的话是基于logstash和beat。默认不支持流量分析。

几个平台用下来总感觉很不顺手，结合自己平时的应急情况，决定基于elk搭建一套，用到的工具有elasticsearch、logstash、kibana、suricata、zeek，把这四个联动起来，需要自己写一些脚本。大概流程分为三步，解析、检测、输出。第一步，解析数据，把解析后的日志数据格式化解析存储es中；第二步就是规则检测，使用开源的sigma、kql语句、suricata语句对输入数据进行检测；第三步就是汇总规则检出结果。

windows解析日志这块网上大部分内容都是基于python库做的，这种解析思路是对evtx的xml内容进行解析个人觉得可读性不是很好。通常分析windows日志都是利用事件管理器，然后看日志id和常规里的信息，使用python库无法获取常规里的内容，然而splunk解析出的内容可以和事件管理器一致，果然充钱才能变强。于是又查了些资料，用powershell解析可以实现这个月需求，将powershell解析结果输出csv，将结果中的事件id和微软官方的事件id对应的信息映射，生成新的数据集合存储为json打入es。默认情况下powershell是可以将是evtx转成json的，但是会有一个坑点，Timecreated字段不太容易格式化。

linux日志比较好解析，不管是脚本还是logstash都好解决，这里不再赘述。

规则检测这一块需要筛出开源的sigma和kql中针对日志检测的规则，这一块需要花费不少时间。还有一点有些规则是针对英文版windows的，中文版可能需要二次开发下。

流量检测需要先把流量用suricata检测，输出结果后打入es中。

搭建这个平台零零散散用了不少时间，也明白了一个道理，事情从0到1难，从1到2更难。

附录：

securityonion: securityonionsolutions.com

HELK: thehelk.com

sigma:  github.com/SigmaHQ/sigma

elastic: github.com/elastic/detection-rules

原文始发于微信公众号（huasec）：谈谈我对应急响应的一些拙见