安全运营的“天坑”？ SIEM 的残酷真相
【金融特辑】光大银行科技部DBA女神带你从0到1揭秘MGR
2020年网络安全的焦点是“人的因素”，重心是“安全运营”，但是安全运营的发动机——SIEM，却始终是CISO头上的一个大包。
SANS 2019年的报告(上图)显示，超过70%的大型企业仍然依赖安全信息和事件管理(SIEM)系统来进行数据关联、安全分析和运营。此外，很多企业的安全运营中心(SOC)团队还围绕SIEM配备了用于威胁检测/响应、调查/查询、威胁情报分析以及流程自动化/编排的其他工具。这就产生了一个问题：如果SIEM是安全分析和运营的“重器”，为什么企业还要补充那么多其他工具?
研究表明，尽管SIEM擅长发现已知威胁并生成安全与合规性报告，但它并不适合检测未知威胁或其他安全运营场景。而且，有23%的安全专家表示SIEM平台需要大量的人员培训和经验，而21%的人则认为SIEM需要不断调优并消耗大量运营资源才能发挥作用。总之，SIEM不会很快失宠，但显然还远远不够。
安全关联的进化怪圈
“痛苦金字塔”(Pyramid of Pain)
David Bianco于2013年提出的“痛苦金字塔”(Pyramid of Pain)众所周知。位于塔尖的关注重点(TTP)就是检测活动中你需要理解的那些指标。但SIEM检测发展历程及其当前状态中存在一些令人费解的谜团。本文正是要破迷解密，带您正确认知安全关联的过去与现在，揭示关于SIEM的残酷真相。
首先，让我们的思绪穿越到1999年。那时主机入侵检测系统(HIDS)是高大上的代名词，“SIEM”这词儿在Gartner分析师眼里也就是个华丽丽的新鲜玩意儿。但是，有些供应商居然已经开始开发和售卖“SIM”和“SEM”设备了。要知道，这可是1999年!设备可火了!
这就是第一批很快便会被称为SIEM的工具，拥有非常基本的“关联”规则(真的，不过是聚合和计数单条属性，比如用户名或源IP之类的)，例如“多个目的地址同一端口的多个连接”、“包含SYNflood的思科PIX日志消息重复50次”、“SSH登录失败”等等。很多此类规则都非常脆弱，攻击行为的些微改变就可以规避规则触发。而且，这些规则还是设备依赖的(例如，你得针对每个防火墙设备编写此类规则)。所以，SIM/SEM供应商不得不加载成百上千条此类规则。而客户则在启用/禁用和调整大量规则的深渊中痛苦不堪。
1999年时，Dragon Squire之类主机入侵检测系统真的是90年代安全技术的一大突破，可以梳理日志，查找“FTP:NESSUS-PROBE”和“FTP:USER-NULL-REFUSED”之类的东西。
略过千禧不谈，我们快进到2003-2004时期——革命爆发了!SIEM产品横空出世，放出两个大招：规范化事件和事件分类。分析师花点时间将设备事件ID划入SIEM分类事件类型中(如：Windows事件ID 1102该往哪儿去?)，然后对此编写检测规则。SIEM检测内容编写就此变得有趣!
SIEM的这个巨大进步为我们带来了著名的关联规则，例如“同一目的地址远程访问类事件后的多个漏洞利用类事件”。这种规则开始支持跨设备通用检测逻辑，分析师的生活从此变得阳光明媚!通用规则的适用性强得多(就好像“任意漏洞利用”和“任意远程访问”与特定的攻击(例如VNC访问))，还能跨设备使用——只需编写一次，随后就算换了另一种防火墙，此关联规则依然能检测恶意事件。
哇哦，简直神奇!有了这个，你就(大概)能凭借几十条好规则走遍天下，无需再在几十个系统和多个操作系统版本类型的无数正则表达式、子串和设备事件ID间苦不堪言。在当时，SIEM可谓是安全产品的重大进步，这就好比汽车淘汰了马车。
此外，一些人对通用事件表达(CEE)计划寄予厚望，开始努力生成现实可用的全球日志分类和模式(大约在2005年)。
一觉醒来还在解放前
但你绝对想不到此后发生了什么!
现在，我们快进到今天，已经跨入到2020年。实际上，当前的大多数检测内容还是用的90年代风格——匹配原始日志的狭窄而精确的风格。看看Sigma内容就知道，1998年的Network Intelligence enVision SIM用户都能看懂其中大部分检测!不可否认，我们今天也有ATT&CK框架，但这解决的是另一种问题。
还有一个特别奇怪的视角：随着机器学习和分析的兴起，如果我们想要掌握更多安全用例，而不仅仅是检测，对干净的结构化数据的需求肯定会不断上升。然而，我们恰恰是只增加了数据总量，能馈送给机器学习算法的数据并没有多少。我们需要更多干净的、丰富过的数据，不是更多数据!现在不是人多力量大的时代，数据的质量更甚于数量!
这个进化过程就好像我们从马车时代走到汽车时代，然后是电动汽车，然后是喷气式汽车，结果又回到马车时代……
那么，这些年到底发生了什么?
从挥舞关联“魔法棒”15年的ArcSight老手，到用现代工具运营检测团队的安全主管，对安全同行的调查给出了答案。
但在揭晓最终答案之前，我们不妨回顾一下调查数据收集过程中同行们都是怎么想的：
原始搜索赢了
缺乏事件规范化或规范化做得很差(或懒惰到依赖客户去做规范化工作)的产品，因不相干的原因赢得了市场(比如所收集数据的总量等)，而新一代安全运营中心(SOC)分析师从没见过别的工具。于是，分析师用手头的工具勉强应付。好吧，我们暂且将此推理逻辑称之为“原始搜索赢了”。
猎手赢了
威胁猎手春风得意，把传统检测人员逼到墙角，一脚踢出窗外。现在，威胁猎手试图用自己狩猎未知威胁的方式来检测搜索已知攻击的蛛丝马迹。这可称之为“猎手赢了”。
误报赢了
另一种想法是：对“误报”(FP)的容忍度下降了(由于不断恶化的人才短缺状况)，所以编写更窄的检测规则降低误报率开始流行起来(“漏报”是万万不可的——我们只能编写更多规则来阻断漏报)。规则狭窄了也更容易测试些。不妨将这种思路称之为“误报赢了”。
数据多样性赢了
还有一种假说与现代威胁和所收集数据更多样有关。由于我们需要检测更多种类的更多东西，规范化事件和分类事件就被挤到了后面。这种思路可称之为“数据/威胁多样性赢了”。
以上结论您认同哪个?您在检测工作中遇到过类似情况吗?
显然，上述解释都是盲人摸象，直觉告诉我们，SIEM的魔法并不存在，当所有碎片拼接在一起，我们逐渐看清了SIEM的残酷真相：
SIEM中的规范化和分类化方法从未切实起效!在其诞生之初的2003年就没用，此后的每一年里都毫无效果。现在的环境中依然如此。除非某些事情来个大逆转，否则SIEM中规范化和分类化方法无效的事实不会有任何改变。
认识到这一点真是令人伤心，尤其是对构建、宣传、改进和试图全球标准化该方法(通过CEE)的人而言。
事情的真相真的有这么糟吗?很不幸，还真是!SIEM事件分类其实……
- 总落后于时代，现在比之前落后得更多;
- 跨多个事件和日志源时不一致——当今每家供应商均如是;
- 各供应商之间差异很大——无法达成只学习一次的效果;
- 随时间流逝积累的错误和遗漏越来越多;
- 无法有效测试当今面对的真实威胁。
所以，我们甚至不能说“SIEM事件分类已死”，因为它就没真正活过。举个例子，某SIEM供应商的“身份验证失败”事件类别可能漏掉新版软件(比如Windows更新引入的新型事件)，漏掉不常见日志源的事件(SAP登录失败)，或者漏掉错误映射到别的东西上的事件(例如“其他身份验证”类别)。
人们总会自欺欺人，编写愚蠢的字符串匹配和基于正则表达式的内容，而一旦涉及性命攸关的入侵检测，没有人会把希望寄托在事件分类上。
下一代SIEM，取决于下一代SOC
根据安全牛SOC报告(上图)，下一代SOC最主要的特征之一就是摆脱被SIEM支配的困境。
下一代SOC的“大脑”，将是SIEM、风险管理和威胁情报的融合领域，威胁情报正在成为企业打造全新高效安全运营平台，提升安全运营能力的核心。
作为企业内部安全日志的汇聚器，SIEM的基本功能永远不会过时，而且本地安全日志也将是“内生安全”中的高价值威胁情报来源(甚至比蜜罐和商业威胁情报的价值更高)。
下一代SIEM产品log Rhythm的仪表盘界面
而下一代SIEM产品，无论在云端SaaS还是本地，也将顺应SOC智能化、自动化、平台化的大趋势。(支持)开源、上云、自动化和智能化是SIEM产品的四个变革方向，我们在IBM Cloud Pak、Splunk Cloud、Exabeam、翰思和LogRhythm的产品路线中都看到了下一代SIEM的影子。
无论下一代SOC还是SIEM，甚至SOAR和TIP，其最终目标都是为新威胁形式下的风险管理和CISO的新业绩指标服务，而这些关键指标背后的安全运营变革，安全牛将在《下一代SOC报告》中详尽阐述。
【本文是51CTO专栏作者“安全牛”的原创文章，转载请通过安全牛（微信公众号id:gooann-sectv）获取授权】
