安全运营的“天坑”？

ANS 2019年的报告(上图)显示，超过70%的大型企业仍然依赖安全信息和事件管理(SIEM)系统来进行数据关联、安全分析和运营。此外，很多企业的安全运营中心(SOC)团队还围绕SIEM配备了用于威胁检测/响应、调查/查询、威胁情报分析以及流程自动化/编排的其他工具。这就产生了一个问题：如果SIEM是安全分析和运营的“重器”，为什么企业还要补充那么多其他工具?

研究表明，尽管SIEM擅长发现已知威胁并生成安全与合规性报告，但它并不适合检测未知威胁或其他安全运营场景。而且，有23%的安全专家表示SIEM平台需要大量的人员培训和经验，而21%的人则认为SIEM需要不断调优并消耗大量运营资源才能发挥作用。总之，SIEM不会很快失宠，但显然还远远不够

 

avid 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访问))，还能跨设备使用——只需编写一次，随

（编辑：信阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!