从被动响应到主动感知:云原生自动化应急响应实战
2020-08-28 18:09:02 Author: www.4hou.com(查看原文) 阅读量:238 收藏

作者简介.jpg

最近参加了Xcon2020安全技术峰会,趁热打铁跟大家聊聊云平台上的原生自动化应急响应。

随着云计算的大规模普及,公有云的应急响应趋势已逐渐从"被动响应"发展为"主动感知"。一方面云计算的灵活性、可扩展性和性价比吸引了更多的企业上云;另一方面云计算的网络开放,资源共享特性也给网络攻击提供了更为广阔的土壤。

传统单点对抗的应急响应已无法满足云时代的复杂攻击形态和规模。如何在攻击前做好预防措施,攻击后快速有效的自动化溯源取证和风险收敛已经成为云时代应急响应技术的核心竞争力。

应急响应的发展

我认为近代应急响应的发展可分为两个时代:IDC时代和云时代。

1.jpg

IDC时代企业环境部署应用多以linux和windows为主,这一阶段事件响应检测方法论多以单点对抗为主。

随着云计算的普及的普及,越来越多的企业上云,企业环境和资产形态已由传统的实体化向虚拟化和多样化转换,云计算的灵活性、可扩展性和性价比吸引了更多的企业上云,同时也带来了新一轮的安全风险。

2.jpg

IDC时代的资产形态以windows和Linux实体机为主,数量在百台以下。其特点是:成本高、不易扩展、维护和恢复比较复杂,这一阶段的应急响应方法论一般为被动式单机检测。

云时代的资产形态则更加多样化和多元化。数量更是有千台甚至以上。其特点是:低成本、易扩展、资产数量多、安全责任共担。云计算的提供便利的同时,其规模也带来很大安全运营成本。对于安全事件应急响应的自动化溯源取证已经成为必然趋势。

云上应急响应简述

3.jpg

安全行业的小伙伴应该都明白一个道理,那就是没有绝对安全的系统。而当系统被入侵和破坏时,不可避免的会导致业务中断。应急响应的核心价值就是在安全事件突发时,快速有序的处理,最大限度的快速恢复业务和减少损失。因此响应和恢复速度将是云上应急响应的核心竞争力。

4.jpg

以上是我总结的云上应急响应的现状,从图中可以看到云租户的诉求和运营商的交付方案存在很大的不对等,这也是云上应急的主要矛盾。大量的差评工单和投诉都是因为这个产生的。这也是客户和运营商面临的一个重大难题。

5.jpg

既然是难题,难在哪里?从图中我们可以看到有六大困难,并get到三个关键点:海量事件的困扰,分析投入大、人员要求高;证据完整性的挑战,证据提取和保全难度大;责任共担模型便捷模糊导致权责不清晰。

6.jpg

如何解决以上提到的困难?通过上图我们可以看到云平台的主要解决方案是通过云平台基础设施和自动化运维体系构成。通过SOC中集成的云产品日志和全网蜜罐数据进行智能化分析解决云主机自身无日志或日志丢失问题、通过镜像、快照和自动化工具突破网络复杂、应用场景复杂、责任边界模糊、取证苦难和数据量大的困难。

云时代的原生自动化应急响应

7.jpg

业内通常使用的PDCERF方法学(最早由 1987 年美国宾夕法尼亚匹兹堡软件工程研究所在关于应急响应的邀请工作会议上提出),将应急响应分成准备(Preparation)、检测(Detection)、抑制(Containment)、根除(Eradication)、恢复(Recovery)、跟踪(Follow-up)6个阶段的工作。从上图可以看到一次完整的应急响应需要做的事情很多。而业内的提到应急响应一般仅进行到第二个阶段,比较好的运营商会进行到第四个阶段。无论第二还是第四阶段都是建立在解决问题的角度,无法进行持续性运营和方案进化。常规的应急响应对人力和能力的要求很高。且无法解决上边提到的六个难点问题。为了更好的在云上做好应急响应。腾讯安全云鼎实验室结合多年的云上运营和实践经验设计出云原生自动化应急方案。

8.jpg

此方案遵守三大原则:

• 整个系统运行环境和资源均在用户vpc内
• 操作由用户账号发起/用户授权
• 所有证据数据和分析结果均保留于用户vpc空间

整个方案分为两大部分:被动响应和主动发现。本方案采用CS架构,结合云平台多年运营经验、SOC、全网蜜罐和威胁情报的数据进行自动化智能分析。从而帮助应急响应人员在最短时间内定位入侵途径、完成电子取证和输出应急策略。

被动溯源分为三个阶段:

第一阶段:当客户发生入侵事件后,通过自助授权后会启动溯源主机中的谛听系统。谛听系统会申请镜像授权,当授权通过后,会创建临时API KEY并根据要求进行快照或镜像。当镜像打包完毕会进行镜像挂载或者加载快照进行常规溯源。常规溯源会覆盖九大检测场景。如果溯源结束会输出报告和证据;

第二阶段:如果溯源失败。会自动拉取SOC的行为检测数据、全网蜜罐的入侵还原数据以及威胁情报的IOCS数据进行智能化数据分析。分析后会输出报告和证据;

第三阶段:如果溯源结束,将会输出相关IOCS到log中,输出未知检测告警,通过人工进行最终溯源。

主动溯源由SOC、蜜罐、威胁情报构成:SOC的行为检测数据会实时输出异常告警,并提供告警溯源;全网蜜罐进行入侵数据采集,还原数据入侵路径,并输出IOCS进行特征匹配,输出溯源结果和报告;根据威胁情报的IOCS数据进行特征匹配,输出溯源结果和报告。

接下来我们通过被动关系和主动关系构建来看看整个数据是如何关联和分析的。

9.jpg

上图展示了整个溯源方案的被动关系构建图谱:通过入侵时间将恶意命令、服务、登录日志、服务日志、进程网络等数据关联起来,并通过算法、逻辑和入侵特征判定入侵途径。

10.jpg

主动关系的构建通过SOC和蜜罐数据来完成:SOC流量日志和进程日志通过域名或者IP等进行关联;服务指纹和文件/木马特征通过基线和木马行为进行特征关联;SOC和蜜罐数据通过聚类校验和回归验证判断入侵行为。

11.jpg

对于被动检测和主动检测无法覆盖的未知入侵方式、文件和行为将会以日志的方式打印出来。通过查看日志可以得知云安全产品和溯源工具的检测能力等。从而针对性的进行改进,持续进化自身,驱动和完善云安全产品。

运营案例分享

接下来我们通过案例来看看整套方案的一个应用效果,这里展示的是数据加密勒索的应急分析案例。

12.jpg

首先,溯源主机上的谛听客户端经过特征分析成功匹配到入侵方式、入侵时间和相关文件证据链;

13.jpg接着,谛听服务端经过数据聚合分析进行时间排序,从而成功输出入侵链路和感染路径;

14.jpg

最终生成整个证据链和分析结论。从上图可以看到完整的分析流程。

云上运营效果展示

15.jpg

上图充分展示了方案实施后的一个运营效果。

以上就是本次要分享的云原生自动化应急响应方案,此方案通过与云平台基础设施相结合,利用大数据智能化分析和自动化手段有效的解决了应急响应中的三大难题。希望本次分享可以帮助大家做好云上的应急响应。

如若转载,请注明原文地址


文章来源: https://www.4hou.com/posts/8Oro
如有侵权请联系:admin#unsafe.sh