引言
眼下很多单位的安全业务都深受”威胁检测”问题的困扰。Mandiant安全公司在2018年的M-Trends报告中就指出，从攻击开始到发现攻击活动的平均时长是99天。在这个“猫捉老鼠”的游戏中，很明显，现在这只猫还只是一只在喝奶的小猫咪。为了让它迅速强大，众多安全厂商开始鼓吹为这只嫩猫配备一个叫做“SIEM”的神器。可没想到，投了钱，烦恼却越来越多……
我曾在SANS开过一门“SIEM with Tactical Analytics”的课程，很多人认为我是SIEM的绝对拥护者。当然，我的确是，因为我认为SIEM是现有的、最强大的检测解决方案之一。但是，“最强大”并不一定意味着“最好”。虽然我也希望SIEM能够解决我们所有的问题，但事实并非如此。
甲方单位采购SIEM一般都会带着下面这些美好的愿望：
- 快速的搜索和响应时间
- 能够与任何团队或个人尽可能精细化地共享数据
- 内置威胁情报，突出攻击者活动
- 零误报
- 大数据及分析技术
- 机器学习或行为分析的自动化
- 数据关联自动化
但实际部署后，除了最开始的采购投入，还会产生大量日常维护的费用支出和人力成本。
从目前的SIEM技术及部署情况来看，上面提到的“美好愿望”都是不合理的。首先我们要明确的一点是，SIEM只是整个安全保障项目中的其中一部分，它是否能够发挥作用仍然依赖于其它安全组件。
一、SIEM的五大常见问题
1. 收集的数据质量越高，SIEM性能越好
明确收集哪些类型的日志比单纯地收集日志更重要。
只简单地部署一个SIEM起不到任何安全保障的作用——将数据加载到SIEM中才赋予了它真正的价值。那么问题来了：很多数据源并不理想，且大多数数据不易以二进制“好/坏”的方式分类。比如，Windows日志的收集非常普遍，对安全操作人员来说，这是一个最好也是最糟糕的数据源。
对于刚接触的安全人员来说，Windows系统甚至都不会记录重要的事件日志，因为进程和命令行日志、PowerShell日志和Windows驱动程序框架日志在默认情况下都是不启用的。但如果在未调试的情况下记录所有日志，SIEM就会因为大量的无用数据而不堪重负。默认启用的Windows日志尽管作用很大，但也会产生大量的垃圾信息。日志的收集、解析和过滤是一门需要时间和耐心的艺术。另外，还要对日志的有效性进行反复评估。
更何况，我们还没有考虑数据如何输入SIEM的问题。如果该日志由syslog(一种常见的日志传输协议)发出，那么管理员必须执行解析。这就意味着该日志在SIEM中的状态可能已经丢失了原始事件中的某些数据和环境信息。还是以Windows为例，单个Win10系统在本地二进制XML日志结构中有超过800个字段。然而，大多数SIEM对日志源进行解析、削减和转换后就只有200个字段了。
这个结果就像你本来是可以开跑车的，却去骑了马。你能走多远，取决于你收集了什么数据、通过什么样的方式收集。
2. SIEM要与实际案例相结合
SIEM无法将信息安全领域的专业知识和日志应用与你的具体需求实现自动化结合。一旦数据进入SIEM，就需要你来告诉SIEM应如何处理这些数据。简单来说，就像我们买了一个玩具，玩具本身是不带电池的，需要我们准备好电池并完成准确的安装。SIEM就是一个很酷的玩具，但是木有电池……
你是否也有过这样的经历，询问某个厂商关于他们SIEM产品的告警规则或检测攻击者所使用的技术，却只得到“每个单位都不一样”这样的回答?虽然一定程度上的确如此，但还是有一些基于常见攻击方法的技术具有普适性。下面我举两个例子：
- MITRE ATT&CK：这个开源框架是攻击方法与行为的模型。防御者可以用它来识别攻击者可能使用的技术方法，查看他们的流程和控制措施，从而找出检测和预防覆盖面中的不足。
- Sigma：这是一种SIEM的中性规则语言，可用于编写支持任何环境及任何SIEM的规则。为了使这个概念发挥作用，转换过程采用SIEM非自动编写的规则，适用于特定的SIEM。
总而言之，SIEM+应用案例=幸福的婚姻。不与实际应用相结合的SIEM早晚都会“离婚”，SIEM的“誓言”、“信任”以及强大的检测功能都将形同虚设。
3. 数据越多并不等于检测功能越强大
大数据时代已经来临。安全运营团队正在争先恐后地收集他们可以得到的所有数据。除了抢房，还要抢数据。
最常见的错误就是SIEM中充斥着大量无用的数据，我把这种现象称之为“茶歇SIEM”——即使是简单的搜索，也需要数秒或更长时间才能完成。如果一位分析师一直都在等待搜索结果，那么他们可能就会自然而然地选择值得搜索的内容，即返回结果最快的。
SIEM需要的是增强分析，而不是阻碍分析过程。简单来说，less is more(过犹不及)。数据越多，SIEM性能反而越差，分析师掉的坑也就越多。
4. 缺乏环境
一个好的SIEM应由分析师构建，为分析师服务。也就是说，当分析师查看警报或日志时，SIEM能够提供有利的环境信息。如今市场中大多数SIEM在日志丰富化(log enrichment)或为日志添加环境信息方面的功能都很完善。但是，在实际部署中，相对于log enrichment，很多人都更加注重数据的收集。
例如，如果一个分析师正在查看“covertc2.com”这个正在被访问的可疑域名。一个DNS日志包含域名、源IP和目的IP报头信息、产生的IP地址以及DNS记录类型。这些信息是否足以让分析师确定该域名为恶意、可疑还是良性?很明显，仅根据这些有限的数据作出的决定肯定存在偏差。
现在请你想象一下，如果SIEM添加了以下这些环境信息，你能够推测出什么?
- 该域名不在访问的前100万个网站中。
- 该域名注册于2016年11月1日。
- 该IP与伊利诺伊州的一家企业有关。
- 该IP属于Total Server Solutions L.L.C.。
- 该域名未出现在威胁情报数据库中。
- 该域名看起来并非随机生成。
这些环境信息并不能让分析师百分之百地确定善恶，但无疑为分析师提供了很多背景信息，能够帮助他们作出更加明智的决定。
5. 重心偏离：过多关注SIEM的维护
说来也怪，很多单位都能接受SIEM的一大弱点——人力成本(有时甚至是一笔巨额开销)。他们会聘请专家或要求现有团队为数据收集和SIEM的维护提供支持。因此，最后造成的局面就是该单位没有发挥SIEM的服务价值，反过来消耗大量资源来“伺候”它。这方面的人力投入如果放在其它地方，完全可以实现更大的价值。
如果你花80%的时间在SIEM的维护上(代理部署、日志解析、系统升级)，那么你就很可能永远无法实现SIEM价值的最大化。自动化对于一个成功的SIEM实施方案来说太重要了。你的环境是不断变化的，“自动化”也应紧跟步伐，只有这样才能将你的时间花在战术实施方面。
二、应用案例：6周 vs. 14个月
关于第5个问题，我们来看一个实际案例。我曾供职的一家公司推出了一个SIEM解决方案。该项目中有15个全职员工，项目总时长14个月。一年以后，他们暂停了项目，反思SIEM实现了什么功能、为公司创造了什么价值。回顾结果并不理想。14个月以后，他们仍然处于数据收集的状态，检测功能依然无法发挥作用。
后来我有幸介入了这个项目。在不到一个月的时间内，推出了一个全新的方案：利用自动化技术部署日志代理、数据收集、数据源部署，修改或禁用默认或预警警报，并根据已丰富的日志数据实施新的警报机制。
直到第6周快结束时，不到5个正式员工所输出的解决方案超过了15个人花了14个月的工作成果。显然，改革后SIEM的投资回报远超预期。
三、采购SIEM的6大关键前提
一个成功的SIEM方案必须具备以下条件：
- 员工具有专业的信息安全知识背景
- 员工具备对SIEM产品的充分了解
- 数据丰富功能
- 支持自动化
- 对重要数据的收集与利用
- 检测功能与实际应用相结合
机器学习和行为分析也是非常重要的技术组成部分。但是在你还没有做好上述准备之前，暂且不要将精力全部放在机器学习或行为分析上。一个已达到上述6个前提条件但尚未实现自动检测功能的SIEM应用单位将比没有做好准备却专注于自动捕捉异常行为工具的单位更具潜力。
关键要点
根据一般的经验法则来看，SIEM更适合成熟的、有经验的安全团队来操作。当然，这也不是硬性规定，我同样也看到过很多初级团队成功部署SIEM并取得正向结果。他们能够将SIEM很好地与部署环境相结合，并实施像防火墙规则这样的安全控制措施。但大多数情况下，很多团队都是莽撞地加入SIEM大军，迎面即遇上了我上述列举的五大问题。
关键要点如下：SIEM绝不能成为展开安全保障的切入点，尤其是在刚成立安全部门的情况下。一口吃不成胖子，首先要从最基础的做起。终端安全解决方案、网络分段、防火墙等等在安全防御方面路漫漫其修远兮，但是对于检测功能的实现却尤为必要的。完成基础内容后，下一步当然也不是立马去买个SIEM回来。只有当你符合上述要求时，才可以推进SIEM的购买和维护。
我希望以上的观点能够帮助你的团队规避SIEM的常见问题，成为威胁检测战役中的常胜将军。
