企业安全建设与态势感知

2019 年 8 月 12 日 FreeBuf

前言

安全在今天越来越受重视，各类企事业单位也不断加大安全投入，很多度过了安全建设初级阶段(被动防御)的安全团队开始做态势感知。然而，市场很多声称具备安全态势感知的产品大多是厂商站在乙方视角推出的SOC产品，在甲方发挥的主要作用是安全可视化，往往成为一个观赏性的玩具。

下面谈一下笔者在安全建设中对态势感知系统的思考和理解，望能抛砖引玉。

安全建设目标

首先我们回顾一下为什么要有态势感知系统?

安全建设的三大驱动力之一是安全事件驱动，而不断的“事后灭火”过于被动。显然我们都希望在事中甚至事前就能对攻击有了解。所以安全建设初期在IT基础设施中部署各类威胁检测/防护系统是构建纵深防御体系是首要目标。

数据来源:The Black Report 2017

在其建设过程中，我们还需要量化指标，如TTD注1来度量系统的成熟度。如图，如果我们能在2小时内检测对业务造成实质影响的攻击(TTD)并响应威胁(TTR)注2，就能大概率抵御80%以上的攻击。要做到这一点，不仅仅需要广泛部署先进的入侵检测系统还需要专业的安全工程师持续运营。

检测能力的构建对于预算充足的团队，可以通过采购注3来完成。如果安全设备的部署不影响业务或不需要和业务耦合，那么“堆盒子”这个工作虽然会有困难，但总是可以完成。

完成了以上工作，安全挑战从开始的没有威胁感知能力变为真正的安全威胁被海量安全日志和告警淹没。这时候安全团队不仅疲惫不堪，而且也无法让管理层感知到巨大的安全投入带来的收益。此时安全主管一般将目光转向SIEM(Security information and event management)。并期望SIEM具备强大的交互式分析能力，支撑安全团队通过关联分析，(安全告警)冒泡模型等方式来消减告警和进行事件调查，帮助团队提升安全分析效率，缩短TTR。

然而较短的TTR并不等同于业务(IT资产)是安全的，所以还倾向于SIEM具备安全可视化能力，让管理层从资产的视角看到安全态势，呈现安全价值。同时考虑到威胁情报，事件调查，UEBA(User and Entity Behavior Analytics)等场景的需要，安全团队这时就希望有个全功能的统一作战分析平台来搞定一切，这时安全态势感知系统(NG-SIEM注4)登场了，但如前所述，其落地不好，很容易沦为“玩具”。

态势感知系统建设失败原因和建议

那么为什么会出现这样的结果，笔者认为一般有如下原因:

1. 构建基础错误

鉴于NG-SIEM并不是一个新事物和小项目，一个相对简单快捷的方式是直接购买成熟的商业产品，并在这个基础上定制开发。这也是绝大多数安全团队的优先选择。然而购买的产品是传统的偏向于告警聚合和展示的SOC注5还是安全分析的SIEM，效果截然不同。

前者一般是乙方安全公司提供的产品，往往是该公司自己的全线产品管理和告警聚合平台发展而来，侧重于各类安全系统的运维管理和告警聚合，再加上一些对友商告警的解析支持和安全可视化模块，如果用户有办公网安全需求，甚至还会加上所谓的APT检测模块(基于流量或终端安全的传统检测设备加强版)。

而后者(SIEM)通常侧重安全分析，但并不支持对安全设备的策略管理。典型代表可以参考Gartner的SIEMMagic Quadrant报告。该报告中第一阵营中的商业产品都比较成熟。用户可以在这类产品上持续创建运营告警的冒泡模型和自定义报表，有足够人力还可以做深入的数据挖掘，如根据User-agent识别爬虫和扫描工具，并联动WAF阻断，统计分析DNS日志，识别DNSTunnel。根据报文大小，识别异常流量。限于篇幅这里不一一展开。

数据来源:Cisco 在BroCon 2014 上的OpenSOC主题演讲

商业产品的一个显著缺点就是资金成本高，定制功能交付周期长，所以另一个选择是参考OpenSOC自行开发NG-SIEM系统。需要注意，这个选择仍然要较高的人力成本，好处是自由度高，团队可以随着产品的完善而不断成长，小公司也能用其满足关键需求。

2.输入数据质量低劣

有了NG-SIEM这个“基座”，很多安全团队往往迫不及待的不区分场景积极收集各类机器数据，试图收集的大而全后再开始进行数据挖掘，构建分析模型。然而在输入至SIEM时，很多数据就存在大量的无效告警注6和误报，典型如NIPS和WAF的告警以及海量的Access。log日志，这给资源有限的安全分析工作带来极大的挑战。而当其试图进行数据降噪(标记无效告警和失败攻击)时，由于SIEM对安全探针策略支持的不完善和详情展示不足(很多安全设备通过syslog吐出来的数据和原生portal上展示的数据详情有较大差异)会大概率再一次遭到挫折。最终变的garbage in，garbage out(垃圾数据进，垃圾数据出)。

因此笔者建议按照下面的思路来采集和处理安全数据更容易事半功倍。

2.1 在安全设备上优化安全策略和检测规则(Signature)，消减误报。

2.2 在SIEM上对接CMDB(Configuration Management Database)以方便标记无效告警;并将同一威胁类别，同一时间窗口的不同安全探针的告警基于专家经验关联分析，标记失败攻击。

2.3 在NG-SIEM平台上使用机器学习进一步对安全告警进行降噪，典型如使用HMM算法对WAF告警进行降噪。

3.资产画像未能反映IT资产的真实安全状况

如前所述，很多国内的SOC产品都具备资产画像安全可视化能力，基本原理是用公式来计算资产的安全风险程度并将资产安全评分以图表方式呈现。如[不同威胁等级漏洞(A1)]权重+[不同威胁等级告警(A2)]权重+[不安全的配置(A3)]权重+[资产敏感程度(A4)]权重。而在日常的安全分析活动中，安全团队也会把原始安全告警中的无效告警和误报剔除，再对剩下的有效告警区分为成功的攻击和失败的攻击。只有成功的攻击才会对资产有实质的影响。

遗憾的是，很多SOC产品大多是半成品，其安全评分一般以原始告警作为公式中的A2指标的来源，而非将有效告警作为数据来源。或者实时性很低，24小时一次。显然，基于各类安全数据准实时(分钟级)的描绘资产画像，不断减少[灰色]资产状态的数量使其黑白分明注7，资产画像才真正有价值。

避免了以上问题，NG-SIEM基本不会失败了，那么NG-SIEM可以在安全建设中做的更好吗?

安全建设/态势感知系统如何做的更好?

数据来源: SANS Institute 发布的白皮书《The Sliding Scale of Cyber Security》

在The Sliding Scale of Cyber Security（网络安全滑动标尺模型）中定义了安全建设的5个阶段(成熟度模型)注8，一般态势感知系统是在被动防御的阶段较为成熟的时候启动的，那么如何前进到主动防御乃至情报驱动的阶段?NG-SIEM又应该怎样做，才能发挥更大的作用呢?不同安全建设阶段，有很多区别，但最核心的区别是做为防守方，掌握的主动权大小不同。

那么如何在攻防对抗中掌握更大的主动权，尽可能打胜仗呢?

“知己知彼，百战不殆”——《孙子·谋攻》

这句名言在网络安全中同样适用。

1.完善IT治理，构建应用指纹库

NG-SIEM对接CMDB对告警降噪有一定帮助，但很多组织的IT成熟度较低，在事件调查中，安全团队会发现需要的很多信息和数据，CMDB都无法自动化提供，只能让安全团队在业务主机上手工提取(一般要进行权限申请)或委托运维团队提供。

更合适的做法是，DFIR（Digital Forensics & Incident Response）团队需要的任何数据NG-SIEM均可从对接的运维IT系统自助提取。

但这样仍然是不够的，漏洞预警是DFIR团队一个重要场景，为尽快确定Nday漏洞受影响范围和修复效果，最佳实践是构建一个应用指纹库（主机，端口，应用，代码指纹）来提高效率，而这个系统一般需要安全团队自行开发并集成到NG-SIEM中。此外，考虑软件供应链安全，业务版本发布规范的组织还可以考虑将第三方开源组件的使用记录下来也一并集成。

2. 构建威胁阻断和安全编排能力，支撑分析识别对手技术水平

安全告警在NG-SIEM中消减为有效告警后，无论成功的攻击还是持续进行的失败攻击，一般我们需要进行ThreatHunting(威胁追踪)注9，判断对手的技术水平，分析其攻击意图和可造成威胁的机会(业务的脆弱性)。那么如何判断对手的技术水平呢？

一个常见的做法是，对某类攻击施加干扰，然后根据对手调整攻击手法的变化频率，干扰措施绕过水平和攻击资源投入的强度、时间来判断。这就需要安全设备具备阻断能力，如WAF根据不同响应码（200和404）分布比例拦截web扫描，或拦截特定User-agent的请求报文，甚至特定payload的请求报文。

同时，有了阻断能力，构建安全编排能力，让不同安全探针/设备之间的检测和响应联动将能进一步提升TTR，典型场景如WAF和扫描器联动，HIPS和AV集群，Sandbox联动。

总而言之，威胁阻断能力对威胁追踪非常关键，也许对纵深检测体系的团队来说，这可能要花很大精力调整，但是非常值得的。

3.输出威胁情报，强化威胁追踪

拥有应用指纹库和安全编排后，安全团队在知己方面就建设的比较完善了，而为提高对攻击者的了解，一般还会适时引入威胁情报，最常见的威胁情报是C2情报（Command and Control服务器的域名或IP），这类Detection Indicators(检测指标)往往是第三方安全服务商提供的。但更好的做法是安全团队不仅使用情报还能输出情报，即对每个告警背后的含义进行分析:这次攻击到了KillChain的哪个环节?

每个环节上，攻击工具有哪些特征?能否被安全工具捕获到?其攻击源是否是在持续攻击?能否将提取出来的Indicators(威胁指标)按照用途注10分类并标记相关告警。

这样一方面完成了威胁情报的输出，方便绘制攻击者画像，强化威胁追踪的能力，另一方面带有标记的数据也方便在威胁检测中使用用于机器学习技术。

4.制定运维操作规范，使用UEBA技术提升威胁检测能力

NG-SIEM经过前面的努力，CMDB在安全场景中提供的数据应该比较全面了，但往往仅到服务器这个粒度，很少会细粒度到服务器内部的业务进程实例的程度。这就难以自动化识别出是攻击导致还是正常业务行为导致敏感文件(认证文件，系统配置等)的变化。

合适的做法是，在运维流程和制度上对运维活动的执行用户，操作路径，运维脚本名称都加以规范，同时使用OSQuery这类运维工具获取活动进程信息(pid，name，path，cmdline，state，cwd，root，uid，euid，ppid)和其对应的openfile(活动进程打开的文件)，活动端口等信息，建立对运维角色和业务进程的正常模型，来消减无效告警和提高异常发现率，这也是UEBA理念的一个很好的实践。

5. 使用Deception（欺骗防御）技术进行攻击预警

传统的蜜罐一般是部署在互联网上搜集木马样本和监测僵尸网络，但如果将蜜罐架设在业务环境内部，并将蜜罐告警同步给NG-SIEM，就可以关联攻击源IP的数据进行攻击预警。进一步可以在业务数据库中插入业务不使用的脏数据并做数据库审计，来监测内网的攻击。

6. 构建红蓝对抗机制，回归到人和人的对抗

做了以上几点，NG-SIEM(态势感知)系统已经较为完善了，但究竟“行不行”还需要建立红蓝对抗机制实际检验。这就要求BlueTeam（防守方）定期对各类威胁攻击针对性的进行技术验证，确认各安全设备均可实际有效检出相应攻击，并持续优化。

还要给RedTeam(攻击方)充分的授权和支持，允许其在公司办公网络外部自由进行渗透测试，以模拟黑客拿到高价值数据或获取控制权为目标。BlueTeam在NG-SIEM上根据实际演练结果，同RedTeam共同复盘和改进。

总结

安全建设的后期，NG-SIEM系统的建设是重中之重，作为整个安全系统的统一作战平台，它的成熟度甚至可以衡量整个安全团队的建设水平，行文至此，我们做一下总结

1.工具:NG-SIEM不是检测系统，降低安全设备/探针本身的误报率和无效告警能大幅提高NG-SIEM的效率，并降低传输及存储成本。

2.数据:NG-SIEM不是一个独立的IT系统，更有可能是多个安全分析系统的集合，且严重依赖运维系统的支撑。IT成熟度的高低和提供数据的全面性对NG-SIEM的效果有重大影响。

3.流程:NG-SIEM特别是其中的UEBA模块，不仅仅是一个技术问题，完善的运维流程和操作规范会让其事半功倍。

4.人:安全的的本质是人和人的攻防对抗，在建设安全系统的过程中不要忘记对安全人才的培养和重视。高素质的安全工程师才是安全建设的根本。