=Start=
缘由:
趁着周末整理回顾一下前几天(20200812)观看的「企业安全运营实践论坛」中的几个议题,方便后续学习参考。
正文:
参考解答:
SOAR不是银弹,只是在已有IDR的SOP成熟了之后自然而然的一个演进阶段,SOAR对企业当前的安全基础是有一定要求的,如果一些基础的能力都没建设好,就不要先急着做这个了,但可以借助类似的思考方法帮助自己厘清建设重点和建设节奏。
一、安全事件检测与响应(IDR)的运营困境
作者将没有SOAR之前的IDR运营之困总结成了6点,也分别做了介绍,感兴趣的同学可以自己去看回放,里面包含一些细节。
这里我就按照我自己的想法简单说一下:如果没有类似于SOAR这样的一种集中式安全运营管控平台,容易出现的问题就是——
- 误报(单一或者碎片化的数据无法支持准确告警,无法有效刻画真实场景)or漏报(如果单一的阈值就有不少告警了,那肯定还有很多异常没有被告警出来);
- 告警产出严重依赖于运营维护人员的经验和责任心(很难形成有效沉淀以及进一步的优化);
- 平台不统一、标准就很难统一,就很难进行科学有效的度量以及基于此的迭代优化,还有就是重复建设造成的资源浪费和内部部门墙心态(多方开会容易变成鸡同鸭讲的局面,谁都不懂谁或是谁都不服谁);
- 集中式的安全大脑最后肯定是要做的,早做不如晚做。
二、安全编排自动化与响应(SOAR)能做什么
在有SOAR之前(或者说不论有没有SOAR),就应该有标准化的事件响应流程SOP,SOAR只是将此流程中能够自动化的动作进行了自动化处理,提高了效率(虽然说看上去只是提高了效率,但有一件事情你也必须要认识到,先要解放双手,才能解放思想,量变引起质变)。
三、贴合甲方实际场景的SOAR建设思路
先要明确定位;还要结合企业部门当前的实际情况和建设目标,最好就是在做某件事情之前先对现状有足够的指标统计,然后再在做的时候有数据做支撑,也更容易说服老板争取到资源和信任。
在已有SOP的基础上小步快跑、迭代运营,用数据做支撑,用先进/合适的方法论做指导,不断拓展能力范围和边界。
参考链接:
企业安全运营实践论坛
https://bcs.qianxin.com/2020/live/index?meeting_id=20
=END=
《 “[安全大会]2020-BCS-企业安全运营实践-2-安全运营之自动编排的探索” 》 有 7 条评论
现代化SOAR的产品化落地(一)
https://mp.weixin.qq.com/s/E72-K43f-TkLv2WIHqKyKA
`
今年Gartner再次更新了SOAR(安全编排自动化响应)的定义,表达出了更高的期待:
定义6【2020】:SOAR平台是一类为人类安全运营人员在其团队中执行某些任务的过程中提供机器协助的解决方案。这里的团队不限于SIEM操作员或SOC分析师。这里的团队可以包括告警与分诊管理、事件响应人员、威胁情报、合规经理、威胁猎手。
定义7【2020年,安全运营炒作曲线】:SOAR是一类从各种来源获取输入,并应用工作流来拉通各种安全过程与规程,从而为安全运营人员提供机器协助的解决方案。这些过程和规程可以被编排(通过与其它技术的集成)并自动执行以达成预期结果,譬如分诊管理,事件响应,威胁情报,合规性管理和威胁猎捕。(参考1)
对于SOAR的定义不再只是单一的响应联动,而是寄望于它能够进一步促进SOC(安全运营中心)中人、技术、流程,三位一体的融合,加速PPDR模型中预测、防御、分析检测、响应过程。
反观SOAR在国内的市场都是不温不火的,归结下主要有几点原因:
·国内安全技术从业人员偏少,包括非技术类的整体从业人数也就十几万人(据调查),面对复杂如SOAR的平台也是无从下手;
·设备、接口碎片化过于严重,各设备谈不上接口标准化,生态不成熟,自家各盒子产品都不见得能用SOAR串起来;
·国内公有云厂商对于SOAR的安全建设多少乏力,公有云本是所有一流安全技术持续落地的优先场景;
前面两点就足以限制其市场地位,更不用说甲方用户、公有云、威胁情报提供商对它的认知了,所以目前多数安全厂商会选择兼顾市场需求的短平快联动功能进行产品开发,不会把功夫花在Gartner炒作和SOAR的绣花上。
任何一个新技术的尝试都需要一点点理想主义、加上现实的捶打,SOAR也不例外,面对着告警爆炸、人才/经验短缺、工具过量的痛点,SOAR作为由安全编排与自动化、威胁情报平台和事件响应平台融合而起的新兴安全解决方案,其所追求的人机协同自动化是解决这个痛点的方案之一,它是值得去探索的。
虽然SOAR平台能够消除现有安全运营流程中执行的单调、重复任务的需求,但是SOAR本身并不能代替人类。SOAR技术可以帮助安全运营人员更快地从决策点a移动到决策点B,但是所选择的路径以及如何在该路径上做出决定是需要人工交互的技能。
在SOAR产品中定义良好的剧本可以创建更高效的决策速度。但是具体响应执行过程还要由业务环境中事件的上下文、业务风险的容忍度以及安全运维之外的团队的能力来驱动。因此,我们只能将SOAR应用于已经预想可能会发生的并且知道如何响应的安全场景中。
所以,现代化SOAR除了需要完成【从响应到分析调查的升华,完成SOC效率、MTTR的提升】,还需要【做到知识的留存】等。在实际过程中对接SIEM, XDR, 资产,云端威胁情报等,以Playbook(剧本化)的形式,融合分析人员的知识来驱动下层的自动化编排引擎、作战室协作、案例化管理、威胁情报管理等方式实现一个安全运营体系的升级。
`
Gartner对SOAR的定义不断变化
https://mp.weixin.qq.com/s/X0BoaaFG1a-p5xymokC1YQ
`
分析Garnter在2020年的SOAR定义,可以发现,明显的变化在于强调了SOAR是一种为人提供机器协助的解决方案。具体可以分为两点:
1)强调了人在SOAR中的主体地位和作用,以及机器智能、机器自动化的辅助增强作用。从2017年说“人机结合”到2018~2019年不提及,再到2020年重提人的重要性,能够体会到Gartner对于SOAR的认知和定位的厘清过程。也许此时可以称SOAR为SOA for human吧。
2)SOAR从一种技术升格为一种解决方案。一般地,解决方案是多种技术的组合,用于满足特定的用户需求。
接下来呢?让我们一起等待Gartner最新一期的SOAR市场指南吧。
最后,也谈谈笔者对SOAR定义的理解。笔者认为,SOAR应该是这样一个系统:
1)它是一个智能化的协作安全运营系统;
2)它面向SecOps团队,以高效的实战化安全运营为目标,为团队赋能;
3)它能实现人与组织、流程、技术及工具的整合,整合的纽带是“剧本”和“应用”;
4)编排与自动化是SOAR的核心能力。
响应是SOAR的一个经典应用场景,但SOAR不限于响应,安全编排与自动化适用于识别、防护、检测、响应、恢复等等各个环节。
我们一直都在说一个完整的安全运营中心是人、流程和技术的集合体。以SIEM技术为核心的SOC平台或者安管平台一直致力于为SOC的人提供一个技术平台,但却从没有真正将人与技术整合到一起,更不要说流程。人和流程与SOC平台之间始终存在间隙。SOAR则恰好填补了这个空白,以整合人、流程和技术为使命,让我们朝真正的SOC又前进了一步。
`
【企业安全运营实践论坛】刘潇锋:安全运营之自动编排的探索
https://mp.weixin.qq.com/s/LkPD_C_eeNOGnidXpYajmA
`
一、安全事件检测与响应,也就是IDR流程的运营困境和挑战;
二、安全编排自动化与响应,也就是SOAR的概念,以及它能为安全事件检测与响应流程带来哪些改善;
三,我会结合滴滴的实践经验和探索,介绍贴合甲方实际场景的SOAR建设思路。
一、基于传统的SIEM/SOC的IDR运营中主要面临下面几项困难和挑战:
(一)海量异构的日志数据源;
(二)有效的告警会淹没在误报当中;
(三)告警研判推理的挑战;
(四)人员流失给团队带来的挑战;
(五)如何针对事件检测响应去建构知识体系;
(六)如何对事件检测响应工作建立科学的度量和评价体系。
二、安全编排自动化与响应,也就是SOAR的概念,以及它能为安全事件检测与响应流程带来哪些改善
(一)SOAR的概念介绍。
(二)SOAR如何加速事件检测和响应
(三)剧本编排的概念
三、结合滴滴的实践经验和探索,介绍贴合甲方实际场景的SOAR建设思路。
(一)在建设SOAR之前,我们需要明确SOAR在事件检测响应体系中的定位,也就是它与SIEM/SOC/安全事件响应平台SIRP之间的关系,还有它与TIP威胁情报平台之间的关系。
(二)SOAR在甲方如何落地,主要考虑三方面:
1、实现路径:
2、技术选型:主要是考虑可视化剧本的编排引擎,还有剧本的执行引擎。
3、系统设计:SOAR虽然是一个扩展的能力,但是从系统设计的角度来说,一旦我们引入SOAR,就会将它串联到我们整个的 IDR流程当中。所以SOAR自身的稳定性,还有一些其他的技术指标,比如像EPS每秒处理的事件数,SLA,包括一些其他的benchmark等等,这些也是我们关注的重点。刚才也提到SOAR会串联到IDR流程里,所以它有可能会引入或导致一个单点问题,所以我们也会考虑分布式的部署。还有降级,一旦SOAR不可用的时候,我们的SOC或者事件响应平台能否降级到没有SOAR的状态。
(三)如何评估SOAR的效果和收益?
1、对IDR核心运营指标MTTD和MTTR的提升,它能让我们技术运营投入更少的人力去做更多的事,提升人效。
2、他能否通过SOAR来识别攻击者完整的战术动作,也就是TTP。
3、通过将剧本的引入,将流程案件知识固化下来,牵引我们能力侧的建设。
`
你这补充的也太迅速了吧
Google对于未来SOC的建设思考(自动化安全运营白皮书)
https://zhuanlan.zhihu.com/p/528817905
https://go.chronicle.security/autonomic-security-operations
`
# 概要(Executive Summary)
面临的场景正在变化 Landscape is evolving:
攻击者正在变化 Attackers are evolving:
SOC必须要飞速发展才足以应对这些新挑战 The SOC must evolve dramatically to tackle these new challenges:
借助自动化安全运营对SOC进行转变 Autonomic Security Operations to Transform your SOC
# Introduction
# SOC的使命 The SOC mission
# 为什么SOC需要进行转变 Why the SOC needs to transform?
业务转型 Business Transformation
攻击面的扩大 Expanding Attack Surface
人才短缺 Talent Shortage
为什么未来的SOC会有所不同 Why should future SOC be different?
# 什么是自动化安全运营 What is Autonomic Security Operations?
10倍人效 10X People
10X analyst productivity and effectiveness
10X coverage of threats and assets
10X knowledge sharing
10倍流程效率 10X Process
10倍技术含量 10X Technology
可见性 10X Visibility
速度 10X Speed
信号 10X Signals
总拥有成本 10X TCO
10倍影响力 10X Influence
# 如何实现自动化安全运营 How to achieve Autonomic Security Operations
人员的转型 People Transformation
流程的转型 Process Transformation
技术的转型 Technology Transformation
影响力的转型 Influence Transformation
# Conclusion
自动化安全运营是一个长期的旅程(可能持续数年),这也不仅仅是CISO或是SOC负责人的责任,而应该是安全团队所有人共担的。这篇文章只是给你提供一个模型/思路去思考如何驱动组织内部的变化/转型,即便不是SOC也应该好好去规划下个月/季度/年,你们团队应该如何进化。然后Google云刚好又有这方面的经验和意愿,如果你想的话可以一起参与进来。
`
11 Strategies of a World-Class Cybersecurity Operations Center
https://www.mitre.org/news-insights/publication/11-strategies-world-class-cybersecurity-operations-center
https://www.mitre.org/sites/default/files/2022-04/11-strategies-of-a-world-class-cybersecurity-operations-center.pdf
https://www.mitre.org/sites/default/files/2022-04/11-strategies-world-class-csoc-highlights.pdf
`
SOC Fundamentals
STRATEGY 1: Know What You Are Protecting and Why
STRATEGY 2: Give the SOC the Authority to Do Its Job
STRATEGY 3: Build a SOC Structure to Match Your Organizational Needs
STRATEGY 4: Hire and Grow Quality Staff
STRATEGY 5: Prioritize Incident Response
STRATEGY 6: Illuminate Adversaries with Cyber Threat Intelligence
STRATEGY 7: Select and Collect the Right Data
STRATEGY 8: Leverage Tools to Support Analyst Workflow
STRATEGY 9: Communicate Clearly, Collaborate Often, Share Generously
STRATEGY 10: Measure Performance to Improve Performance
STRATEGY 11: Turn up the Volume by Expanding SOC Functionality
==
SOC基本面
策略1:知道你在保护什么以及为什么
策略2:赋予SOC完成其工作的权力
策略3:建立一个符合你组织需求的SOC架构
策略4:雇佣和培养高素质的员工
策略5:优先处理事件
策略6:用网络威胁情报做攻击者画像
策略7:选择和收集正确的数据
策略8:利用工具来支持分析师的工作流程
策略9:清晰沟通,经常合作,慷慨分享
策略10:通过衡量来提高效果
策略11:通过扩展SOC功能来提高效果
`
安全运营
https://www.yuque.com/kingjly/aqyy
安全运营中心策略1:知道你在保护什么以及为什么要保护
https://www.yuque.com/kingjly/aqyy/xuxd5h
安全运营中心策略2:赋予SOC完成其工作的权力
https://www.yuque.com/kingjly/aqyy/pdw7vm
安全运营中心策略3:建立一个符合你组织需求的SOC架构
https://www.yuque.com/kingjly/aqyy/sblp0h
e1knot:实践之后,我们来谈谈如何建设SOAR
https://mp.weixin.qq.com/s/HOduKBW15WdmaBhB9e3lFg
`
建设SOAR的核心其实还是基础已经搞的很好了(基本功已经练的很扎实了),现在有人有钱有闲有追求想进一步提高响应效率(有条件追求更高的层次),并希望平台化,将人员的能力不断积累沉淀到平台上,降低因人员流动等情况导致的输出质量效果不稳定的问题和风险。
0x01 为什么我们要去建设SOAR能力
在谈到建设SOAR能力的时候,在和周围人聊天的时候都对SOAR有着不同的看法,有的人觉得SOAR这个东西就是一个独立的产品,有些人认为SOAR这东西需要和SIEM进行深度绑定,有些人觉得SOAR这个玩意儿可以接入所有的东西。但是从实际落地SOAR而言,我们需要去谈论一下做SOAR的收益,在我看来做SOAR的意义在于以下几点。
(1)信息安全运营已经处于规模化阶段
当你在谈论SOAR的时候,其实绝大多数人实际上对于SOAR能力一直会有一个误区,就是觉得别人要有的东西我也要有,不能在产品线上落后别人一步(这种想法在部分安全领域其实是正确的,但是遇到一些需要堆人效的工作可能就会变得不那么适用),所以我们就需要去建立SOAR。但实际情况是,对于绝大多数企业而言,SOAR能力建设实际上完全是一个赔本的买卖,简单说主要有以下几个问题:
* 企业内部真的需要有那么多的安全事件能够发展到需要进行止损么,规则优化到位了么?
* 企业内部相关联的系统具备自动化/半自动化的响应能力么?(点个按钮拉群的那种不算)
* 建设SOAR的成本大概回本的周期是业务可以接受的吗?
* 如果没有SOAR的话,纯人工运营对于现在的信息安全和风险真的比SOAR更低吗?
其实以上问题如果能回答的很明白的话,绝大多数人对于需要建设SOAR相关的能力的公司会有一个大概的画像:
* 安全团队有一定规模,且基础的安全产品已经铺设的差不多了(资产安全相关产品、终端安全相关产品、流量安全相关产品、研发流水线安全相关产品等),并且数据质量和规则模型质量已经优化的基本到位了(漏报率和误报率达到了可人工运营的水平);
* 企业内部IT/运维相关平台和能力已经完成了绝大多数标准化的建设(不管是开源产品还是商业产品,数据结构和API的统一化和标准化建设基本完成);
* 安全需求多而繁杂,并且对应的安全运营相关指标已经出现了停摆或者说是达到了一定瓶颈(绝大多数是人效的问题或者说是TCO上不去);
* 信息安全相关的预算比较充足且一段时间没有预算明显降低的风险。
所以如果要是不满足上述的条件的话,可能拉群会比建设一整套SOAR能力来的更有性价比一些。
(2)信息安全运营工作的标准化和流程化建设
如果满足了上述条件,但是从指标来看,在各种响应层面的指标仍旧处于不健康或者是落后于同行的情况下,这个事后其实不用我说,大家也都知道一定是运营质量上出现了很多问题。笔者在建设SOAR能力的时候也在经常考虑一个问题,如何将SOAR相关的产出和部门内BU Goal甚至是BG Goal结合起来说明建设SOAR的价值,但是从一段时间的实践来看,似乎这不是一件容易的事情。
如果说前面的基本功做好了,差不多在1-2年之内就会遇到上述情况,比如说漏报率、误报率不稳定的问题、事件响应时间长的问题,人员变更导致运营能力不能稳定输出等。
如果你遇到了这种问题,绝大多数情况下肯定是运营质量出现了一些情况,最直观的感受就是很多core metrics会变得不稳定且不可预测,这个时候安全运营工作的标准化建设和流程化建设实际上是下一阶段安全运营工作建设的重点。
但是这个和SOAR有什么关系呢,从对SOAR这种类型的概念来看,本质上Playbook就是标准化和流程化结果的最好体现。简单来说SOAR的core metrics除了要关心产品的稳定性等性能指标之外,还需要去关心Playbook的覆盖程度、运营成功率、运营自动化率等问题,除了SOAR本身的能力不断要建设之外,IT/基础设施也是需要通过SOAR Playbook的覆盖程度去push对应能力的建设。除此之外,专家经验也是可以通过Playbook进行沉淀。这样建设一轮下来,误报率漏报率等核心安全运营指标在一段时间之后从原来的不稳定且不可预测会改观许多。
(3)信息安全工作人效比太低,TCO指标难看
这部分其实从2018年之后对于很多公司的信息安全团队都有一个比较明显的感受,企业内部对于信息安全的预算一降再降,这部分原因除了宏观背景之外,很大一部分原因是因为这个时候企业对于安全建设的ROI会发现不成正比。尽管任何企业被入侵这个事儿从概率的角度上讲几乎是一个必然事件,但是信息安全工作从来不在于完全抵御所有的网络攻击,而是尽可能提高攻击成本,甚至更进一步,在有限的资源内尽可能高的提升攻击成本。所以基础建设相关的团队都会把TCO指标当做自己核心指标的一部分。Google在2021年披露他们的Autonomic Security Operations相关的blog的时候,实际上已经这么干了。
而对于SOAR而言,提升TCO这一部分其实是顺手的事儿,SOAR建设的终极目标其实就是将企业内部的风险全都自动化处理掉(当然绝大多数的时候这是不可能的),所以对于TCO提升而言,SOAR的建设程度越高,TCO也就越高(其实TCO指标和SOAR成熟度可以互为反向指标)。
(4)信息安全建设工作需要进一步内生化和集成化
外挂式安全不可持续这件事儿其实一直是最近一段时间业内的共识(也有上限低的情况),原生安全能力的建设其实一直是未来信息安全建设的重点。SOAR能力其实本质上来讲也是一种外挂式能力,但是SOAR的外挂能力和扫描器等外挂式安全能力不同的地方在于SOAR更像是原生安全和外挂安全的耦合剂,也就是在处理风险的时候,SOAR可以更高效的调用原生的安全能力来解决实际的安全问题。
0x02 在企业内部如何去建立SOAR能力
SOAR的核心能力实际上对下是要把安全风险和安全能力进行耦合,对上要对各种安全领域出现的安全风险提供底层能力的Playbook级别的调用,达到自动化响应风险的目的。
(1)SOAR能力在整个SOC能力中的定位
首先对于SOC而言,SOAR的能力更像是是一个底座级别的能力,而非是和SIEM进行捆绑操作,本质上来讲SOAR在整个SOC架构里面应该是下面这种情况。

SOAR的核心能力实际上对下是要把安全风险和安全能力进行耦合,对上要对各种安全领域出现的安全风险提供底层能力的Playbook级别的调用,达到自动化响应风险的目的。
(2)建立SOAR的metrics和对应的measure plan
讲道理的话,但凡有点工作常识都知道应该从服务可用性和运营指标两个维度分别构建正反向指标用来描述SOAR能力在安全运营工作里面的价值。但是实际上SOAR的价值核心在于提效,然而效率指标这个事儿实际上是一件比较扯皮的事儿,因为很多时候风险运营的指标(比如说响应时间)很有可能仅仅是因为当天的值班人员在告警列表中多看了一眼,然后就发现这个运营指标嗖的一下就上去了,但是到开会的时候如果要是向上如实汇报的话,在管理层眼中这个原因是不可接受的,原因其实上面已经提到了——这个指标不具备稳定性和持续性。
简单来说在构建整个SOAR的评价体系的时候,需要在能力原有的指标稳定可控的前提下排除其他原因对于指标的干扰。简单来说其实可以浓缩成一张表(举个例子):

从构建体系来讲,一般是要遵循三个M,即指标化(Metrics)、体系化(Matrix)和可观测(Measure),尽量去贴近用户体感和实际运营指标。
(3)SOAR应用技术性问题的发现和解决
在建设SOAR的过程中,实际上来讲其实技术上的坑还是有很多的,从最近一段时间来看,其实SOAR的调用量比我们当初设计的时候要大很多,并且我们设计的指标体系有的时候并不一定符合用户的体感。
我举几个例子:
a. Playbook的高踩踏率优化
b. Playbook编排成功率和插件执行成功率的平衡
c. Playbook的配置成本
短期之内,Playbook配置的成本一定不会很低,但是长期来看,由于类似于ChatGPT之类的Copilot产品的引入,说不定会能降低一些。
d. Playbook的应用场景
0x03 总结
若你的基础设施标准化程度高,而且需要关注的信息安全比较多而且比较杂,并且安全相关的运营指标长期没有一个质变,这个时候可以考虑建设一些SOAR能力(标准化做得好的甚至可以使用商业产品),用来提升人效和运营效率,让运营相关指标有一个质变。
但是如果你的基础设施定制化程度很高,而且企业内部有充足的研发资源用来支持运营平台的研发,同时有足够基数的安全专家来提供专家经验,这一部分的话可以考虑自行建设SOAR能力来降低整个安全运营工作的TCO,也会收到不错的效果。
`