很多人不清楚SOAR（安全编排、自动化及响应）是用来干什么，所以今天就通过介绍其核心部分 -- 剧本，来让大家认识下他~
一、前言
在讨论如何编写一个SOAR剧本前我们先回顾下什么是SOAR？
Gartner将SOAR定义为安全编排、自动化及响应（Security Orchestration，Automation andResponse），其包括四个阶段分别是：检测（Detect）、分类（Triage）、响应（Respond）和评估（Prioritize）。
咋看之下似乎还是搞不懂SOAR这个东西是用来干什么的？适用于哪些场景？没关系，我们通过对相关产品的分析以及部门自身结合用户实际数据进行落地的过程中，总结出了五字方针来专门描述SOAR的适用范围。
缺：缺少安全分析、运营人员进行处理或者相关安全告警、事件处理经验。
乱：内部处理安全问题流程过长，往往需要多部门合作。
杂：拥有各种品牌、不同型号的安全设备，难以通过简单、快捷的方式将设备利用起来。
多：每天甚至每小时产生的安全事件、告警量巨大，需要耗费较多人力、时间进行排查。
急：出现某类型安全事件时需要马上进行处理，但缺少相对应的24小时应急人员或处理方式。
通过上面所说的五字方针，想必各位已经对SOAR的适用范围有了初步的了解，接下来我们就来看SOAR最为核心的部分 --剧本。
二、什么是剧本？
什么是剧本？剧本就是处理一类安全问题的方法描述，里面包含了需要用到哪些东西进行处理以及应该如何进行处理。在我们看来，一个剧本应该由动作和处理逻辑来构成：
在剧本中，动作要做的事情可以分为以下四类：
查询类：开始阶段，我该获取哪种类型的数据？
解析类：获取到数据之后，我应该提取里面的哪些字段？
响应类：在这种情况下，我应该做什么？
输出类：完成事情后，我应该怎样通知使用者？
而剧本中的处理逻辑我们则总结为：常规套路+因地制宜。
举个例子：客户机器上突然出现了病毒软件，常规套路就是上杀毒软件！删除病毒！！并且全盘扫描走起！！
什么是因地制宜？哦，原来客户端上部署的Agent只有检测，没有文件删除功能，但是有部署阻断设备。那就换个法子：先阻断相关流量并通知人员处理，处理完成后自动恢复正常。
看到这里可以感觉到动作和处理逻辑之间的关系就如同四肢和大脑的关系一般，事实上也的确如此。我们将其归结为下图：
在看完剧本的两个核心组成之后接下来讨论的问题就是如何编写一个剧本了。
三、如何编写一个剧本？
在讨论如何编写一个剧本前，我想先讨论一个问题：剧本真的是越大越好吗？（这里的大是指剧本里面包含的较多的动作和判断逻辑）
在安全界里面有一个很搞笑的工具叫做：一键卫星。
（工具只是拿来搞笑的，大家不要当真，也不要做这种危害国家安全的事情）
这里拿出来说只是想表达“可以通过简单的方式来完成大量复杂、艰巨的事情”的意思。对于使用者而言，肯定想通过几个剧本就能够把所有的安全场景和安全问题给解决，这样就不用投入太多的人力物力以及精力来解决安全方面的问题。而从理论上讲，一个内容足够丰富的剧本的确可以处理一类问题的绝大部分情况，但在实际过程中我们却没有这样做。
过于庞大的剧本主要会导致下面两方面问题：
1).难于阅读和进行修改
在我们调研SOAR的初始阶段，我们曾经在Demisto产品（国外一家安全厂商，他们就有SOAR产品）中看到一个巨大无比的剧本：单独算动作而言，该剧本里面就有100+的动作，如果算上判断逻辑，则数量更多。
可能大家对于100+的数量并没有很直观的感觉，我们可以换一种描述方法。剧本是可以通过在页面进行展示的，因此通过拖动页面的方式来进行浏览。浏览该剧本用鼠标飞轮进行滚动的话可能需要数十秒才能够完成从头到尾的翻页过程，同时剧本当中还有相当部分的逻辑分支。由此可见一个大的剧本对于浏览以及修改的用户而言是及其不友善的。
2).剧本越大，移植性越差
剧本越大，解决问题的范围越广；解决问题范围越广，要用到的设备越多。而在实际环境中往往每个客户所拥有的设备是不一样的，所以对应使用的动作（调用设备）也不一样。因此剧本中调用的动作（指调用的设备）越多，则该剧本在不同环境很可能会不能正常运行或获取正常的结果。
同时这里也给我们一个警示：一个优秀的剧本不应该在其内部限定使用某种具体的设备来完成这个动作，而应该提供大量可以调用该类型设备的动作。只有这样，在不同客户环境下才能确保同一个剧本也能正常运行，并不会出现因为没有某种设备而导致弃用该剧本的情形。
接下来回归到我们的主题：如何编写剧本。首先我们先从动作方面进行讲解。
前面我们讲到将动作分为四类：查询类、解析类、响应类、输出类。接下来我们将逐类进行讲解。
1.查询类
在设计查询类动作时，曾考虑过是否需要设计一种能够定时执行的动作。但后来在和组内的小伙伴进行沟通后决定将定时执行的功能交给平台执行，保持“一类动作只完成某一种功能”的设计思想。而在查询类中我们主要实现了三大类查询功能，下面来一一介绍。
首先，查询类动作必须要满足的功能就是能够读取到安全事件或者告警。而在实际落地中，我们实现了多种的读取安全事件或者告警的方式，总体而言可以分为两类：单个读取和批量读取。而这两类下面又有对应的细分项，具体可看下图：
单个读取
在单个读取类下有读取最近产生以及最近产生的某种安全事件/告警这两种动作。设计“读取最近产生的事件/告警”动作的目的则是为了和平台的定时执行功能进行搭配，这样在一定配置下就能做到所谓的“分钟级”检测。至于为什么会有读取指定某种类型的事件/告警动作的出现则在介绍完批量读取后再做解释。
批量读取
或许有些人会有疑问：运行多个“单个读取”类动作的效果不是和“批量读取”的效果一致吗？这个问题我们从实际中的两个角度出发来进行解答：
1).实际使用中，客户往往需要对昨天或近期的安全状况进行评估然后编写相关分析说明或指定相关计划。如果只提供“单个读取”类动作，那剧本中可能存在大量此类动作，难免显得有点臃肿甚至于无法正常运行，此时未免有点捉襟见肘的味道了。
2).黑客攻击过程中所产生的告警往往是有关联性的，因此需要对某一段时间内的安全事件/告警进行分析。举个例子：如果出现了“植入一句话木马”的安全告警，单单从该请求而言无法判断是真的系统存在漏洞被人植入成功亦或只是扫描器的自动化攻击行为。但如果这时候发现在该请求的前一段时间范围内存在大量的”SQL注入行为“，那就意味着很有可能是真的存在漏洞：SQL注入成功并且能够成功写入一句话。这个时候就体现了批量读取安全事件/告警的重要性了。
回到之前在”单个读取“中所提出的问题：为什么需要读取指定某种类型的事件/告警动作？这种情况也是我们在设计时没想到，后来在运行实际数据时才发现的问题：客户中往往存在多种安全设备，而设备与设备之间检测功能有重合的地方以及对于同一种类型的漏洞各有各的分类名称。因此要想获取到一种特定类型的安全事件/告警往往需要指定关键词方可。
在”读取安全事件/告警“类动作外我们还需要一种能够查询各种常用信息的方法，因此我们实现了一种名为”常规查询“的方式，其中包含四类动作：ES查询、MySQL查询、资源查询以及调用查询，如下图所示：
“ES查询”中的“限定字段值”以及“限定范围”这两类动作很好理解：在大数据平台中往往使用ES（ElasticSearch）进行数据存储，因此我们需要提供一个能从中获取数据的功能。但有一个拦路虎就是：如果要使用较为复杂的ES查询语句，应该如何支持？难道只能通过让用户输入较为复杂的ES查询语句？或者是只能支持较为简单的查询语句？这个问题想了很久，最后发现一个很妙的方法就是可以交给上文提到过的“解析类”动作进行处理。因此这里不做详细描述，请看下文分解~
与“ES查询”类似的“MySQL查询”，作用也很直白：从MySQL数据库中查询数据。但由于数据库结构的原因，在使用该动作时可能需要对数据库中的库、表、字段名有一定了解。同时目前并不支持过于复杂的SQL查询，只能支持较为基础的查询功能。
“资源查询”，看名字就能够了解到是做什么的了：用于获取第三方信息的。而在这我们则将其划分为两类：“开源情报查询”以及“外部查询”。做这样的划分而不是合并为单独的一个查询是因为开源情报真的非常牛逼，足以单独拎出来研究。另外，“外部查询”则是专门用于从内部或外部系统中获取数据使用的。如相关资料放置在某文件中，此时需要获取其中的资料以用于进行判断，这时就可以采用该类动作了。
最后的“调用查询”则是和实际强相关的了。
“调用设备查询“：在客户环境中有如端上的Agent或部分设备具有检测性质的功能，因此我们提供该类动作来获取相关检测的结果。
”协同查询”：协同？协同的对象是谁？当然是人了，因此该类动作的目的是在于和别的软件、系统进行交互，或获取相关人员下发的相关指令或设定等。
讲到这里，“查询类”动作的算是介绍完毕，这里做个稍微总结：“查询类”动作下有两大类，共六大子类，如下图所示。
2.解析类
接下里要介绍的“解析类”，从整体上而言共有四大类：结构解析、描述解析、条件解析以及混合解析，如下图所示：
首先我们先来解读“结构解析”类动作。
“单一结构类”动作其实较好理解：很多时候读取到的日志或安全事件/告警是字典格式的，可以直接通过键名来读取某一字段值。因此在解析数据时这是最为基本的动作。
“结构互嵌类”动作，可能第一眼看上去有点难以理解，但换种直白的方式进行解释可能就懂了：数据之间是处于一种“套娃”的形式，要获取的数据C存放在数据B中，而数据B又是数据A的一个字段值。的确可以使用多个最为基本的“单一结构类”动作来解析这种情况下的数据，但这样较为麻烦，因此我们直接提供一类动作能够解析这种“套娃“般的数据。
“列表嵌套类“动作则是用于对列表中的每一个元素进行解析用的。上文说过，”查询类“动作可以从数据库或其他地方获取到相关的数据，而这些数据的格式以列表形式为主。因此需要提供一类动作来对列表中的数据进行解析。
而第二个“描述解析类”动作则是用于获取字段值中的实际需要部分的，提供了两类动作：正则解析类和特征描述类。
“正则解析类”很好理解，实际中往往存在一些非结构化的数据或需要从某字段中提取相关特征的场景，这个时候使用正则表达式就能够很好的解决这个问题，因此我们认为有必要提供这样的一类动作。
说到正则，使用过的同学都知道，正则是一种很不稳定的工具，常常会因为数据出现变化或者表达式写的不够完善而出现获取不到信息甚至是获取到错误的信息的状况。因此我们通过创建“特征描述类”动作来作为“正则解析类”动作的一种补充。“特征描述类”动作则是通过分隔符以及描述符来进行解析，如：先将字段用空格进行切割，然后再对第三个分割值用逗号进行分割，最后取被逗号分割后的第三个值。
在介绍完“描述解析类”动作后，我们来看一下带有逻辑感的“条件解析”动作。
为什么需要带有逻辑的“条件解析”动作呢？因为在实际中发现需要对某些用语言描述起来很简单但却需要花费相关功夫才能实现的逻辑，比如说判断一个ip是否在一个ip段范围内。在我们SOAR的平台中（运行剧本的引擎），包含了最为基础的判断功能，如字符串的包含、数值之间的大于、小于等，但类似于上述所说的需要带有一定判断逻辑的功能则无能为力。因此我们通过设计这样一种类型的动作来弥补这样的一个缺陷。
“多字段值条件类”动作针对的是多个字段要同时满足一定条件的才获取的数据，而“复杂判断条件类”动作则是适合于需要对字段值做转换、计算才能进行比较的场景。
最后的“混合解析类”则是将已有的解释类动作进行组合，以便解决更为复杂的应用场景。在这里要声明的一点是，剧本之间是可以相互进行嵌套的，一个剧本的输出结果可以作为另外一个剧本的输入源。而剧本是由动作所构成的，因此动作之间理应也是可以嵌套的（动作在页面上的表现形式为一个个可以拖动的组件，但在后台里本质还是一连串的代码）。在有了上面多样的解析类动作后，就可以很轻易解决上文所说的“ES查询类“动作中如何解决获取复杂ES查询语句结果的问题了：通过简单查询获取结果后再进行解析。
在我们看来，同样是获取复杂结果，通过页面可拖动组件完成字段解析的方式效率要比写一手漂亮的ES语句高（当然也有可能是我们ES写的比较菜）。
3.响应类
接下来所说的“响应类“动作则是根据实际设备情况进行设计的。
在思考“响应类“动作应该如何进行划分时产生了多种想法：应该按照国内外设备进行划分呢？还是按照设备的功能进行划分呢？还是按照其他划分依据呢？思前想后，最后得出了以下结论：按照设备功能和调用设计分开两个方面进行划分，因此下面针对”响应类“动作会有两种划分方式。
方式一：调用设计
在响应类动作中，难免要和各种各样的设备进行打交道，因此我们需要知道如何和设备进行沟通。在这里我们从开源软件（软waf等）和闭源设备进行分析。
实际环境中有部署开源安全软件或二次开发的开源安全软件进行使用的情况，一般这类安全软件都有详细的说明、使用规范和成熟的可供外部提供的API接口，因此编写调用这类安全软件的响应类动作是较为简单的。较为坑的点可能就是“难以调用类“动作的编写了，该类动作更需要通过阅读源码获取相关使用参数后才能写出对应使用方法，因此编写成本较大。
而“闭源“这一类多数指的是各类厂商的设备。在这方面，有的厂商则为产品提供了良好的使用手册以及成熟的API口，因此可以通过查阅手册的方式来为其编写调用方法（与开源的类似）。而有些厂商则是需要客户提出需求后才会开启相关接口，而开启相关接口后的实现方式就与刚才所说的类似。
因此，对于上面所说类型的动作可以通过提供简单的HTTP请求接口来完成。
另外一种情况则是设备提供命令行窗口来进行交互，这种情况下如果发送的消息是被加密的则较难进行处理；如果不是，则可以通过抓包的方式来获取数据请求格式，然后再改变对应参数来发起HTTP请求达成对应目的。
最后“独立类“动作则是面向于那种不提供接口，也没有命令行，仅支持页面登陆进行操作的设备。至于这种情况下怎么操作暂时保密！
方式二：设备功能
关于响应类动作的另一种分类方式就是通过被调用设备的功能进行划分，上图就是较为简单的一种分类方式，因为就功能而言各有特点在此不做过多介绍，有兴趣的同学可以自行去查阅资料。
接下来就介绍的就是我们动作中最后的一项，也是跟用户最为接近的一类动作：输出类。
4.输出类
同样先直接献上其类别分类图，总体而言可分为四个部分，分别为：状态反馈类，常规通知类、产品结合类以及协同处理类。
对于SOAR而言，需要处理大量的安全事件/告警，因此在处理完需要将其状态进行变更或修改相关字段值以示“这个已被处理”。基于此目的，我们设计了“状态反馈类”的动作来完成该类动作。
而设计“常规通知类”的目的则是为了能够及时通知系统管理员相关紧急事件或需要参与决策的场景，同时也支持向非本系统（SOAR）的使用者发送。
我们SOAR是作为部门研发的SOC产品的一部分，因此我们需要将相关一部分结果输送回SOC的其他功能当中。但SOAR作为一个编排和自动化响应的平台不应该仅仅只能与SOC结合，更应该能够与其他的平台简易的结合，因此我们命名了名为“产品结合类”的动作（当然目前更多的是与我们SOC产品进行结合=、=）。
最后的“协同处理类”则更多的强调记录负责人处理相关安全问题的流程，因为实际场景中往往是将机器划分到人进行管理的。
动作小结
至此，SOAR剧本中与动作有关的知识介绍完毕，其类别可分为四大类，如下图所示。
动作的归纳与总结是我们通过分析别人家的产品以及在实际落地过程中总结得来的因此具有较高参考价值。
处理逻辑
前文说了剧本由两部分组成：动作和处理逻辑，上文介绍完了动作那接下来我们就该介绍处理逻辑了。处理逻辑我们上文说过是常规套路+因地制宜的组合，这样的说法较为笼统因此我们需要将其进行一定的细化，而我们将其整理如下：
采用何种数据
剧本是用于解决某一类问题的，因此我们需要明确在解决这类问题的时候需要用到哪些数据。只有在确认要使用何种数据时，才可以选择具体的动作来获取以及解析数据。同时，获取何种数据是会影响解决成果的质量。前面说过，在实际场景中同一种类型的漏洞可能会有多种不同的设备产生事件/告警，而不同设备提供的详细信息程度是不一样的。因此如果在选取数据阶段选取了正确的数据类型往往能达到事半功倍的效果。
判断依据是什么
在处理安全事件/告警时往往需要对攻击进行判断，因此我们需要判断这是哪种类型的漏洞、攻击payload是什么、攻击payload能否成功等相关因素。而这些正是需要固化到剧本中的东西，因为随着攻防技术的升级很多攻击特征已经不再是肉眼或简单的规则能够分辨出来了。在确定了判断依据后还需要考虑如果通过动作来将其实现（固化过程）。
是否需要结合其他数据
在攻防世界中，往往很多漏洞或攻击手法并不是简单的依靠单个事件/告警就能够完成确认，因此很多时候需要结合其他数据进行确认。而在结合其他数据的时候可以通过从时间维度以及告警类型角度进行考虑。
简单举例，如果服务器先出现了SQL注入告警，然后出现了一句话木马的告警那么就很有可能是攻击成功。或者服务器遭受登陆爆破后突然出现了异常登录的告警，那么就很有可能就是被爆破出正确密码然后进行登录了。
如何进行处理
如何处理事件/告警则需要考虑现场的实际条件进行操作以及事件/告警的类型。而且还需要注意的一点是：并不是所有的处理都一定要依赖于安全设备（当然有安全设备固然是比较方便的）。有些操作（如调整相关网络策略来达到阻断效果或删除服务器上的恶意文件）是可以自定义的动作来完成。在有安全设备的前提下则需要考虑使用哪种设备在达到目的的同时又能保证业务的正常运行。
是否需要人为介入
在做检测时候经常能够听到两个词：漏报和误报，这两类问题在SOAR中也会出现，因此在编写剧本的时候必须考虑进去。我们的目标是把SOAR做成一个“使用者喝着咖啡，点几下鼠标就能解决问题的平台”，但在短期而言还是挺困难的，所以当下这个阶段还需借助人的力量来做决策，而SOAR则解决大部分的事情。而当需要人做决策时，剧本中应该通过动作来获取大量相关信息以辅助使用者。
是否需要验证处理结果
不管是在调用设备进行操作或需要其他同事进行协助操作后都需要稍微考虑该步骤能否达到预想结果，如果不能，则需要添加额外的动作以及处理逻辑进行确认或重试。如查杀木马为例，如果该病毒无法被删除或具有死灰复燃的能力，那在这情况下我们需要确认木马文件是否真正被删除，如果无法被删除那我们应该怎么进行处理。
如果一个安全事件/告警的处理是处于一种假真的状态（显示处理成功，但实则处理失败），那接下来后续中将会一直出现同类型的事件/告警，最终导致消耗过多的资源在同一个错误步骤上。
以上就是我们对于“怎样才算是应该固化的处理逻辑”的思考，可能由于个人经验原因有所不足，请大家多多见谅。
四、剧本场景
看到这里，可能各位更加关心SOAR都能运用在哪些场景里面呢？别担心，我们同样简单总结了现有场景给大家：
看完上图迷惑于为什么要将网络攻击和网站攻击两者进行分开？在现实中，网站攻击（Web攻击）往往占到一大部分，而类似于DDoS之类的网络攻击和网站攻击在攻击形式和防御方法上又有较大的区别。为了个场景之间能够更加明确各自解决的问题，所有就把这两者划分为两个不同的场景。
而其他类场景的出现则是为了解决实际过程中较为特殊或难以归到某一确定类型的场景。
五、实际效果
到了将实际运行效果这里，感觉不应该放太多的文字描述，感觉还是简单的图片+注释这样有更好的效果！
上述就是“可疑行为”类的一个实际应用场景，可以看出SOAR在里面解决了绝大部分安全告警，只挑选出少数部分需要人工进行解决的告警。
下面的则是我们部门其他团队用于解决他们日常安全运营过程中的问题：
上图是后台剧本各动作节点的运行图，其他绿色代表的是该次运行过程中所走的路线（那个时候还没有开发Web页面，所以长得比较丑=、=）。
六、扩展
1.与其他类的工作结合
在把SOAR的基础框架开发出来后，我们曾经想过这样一个问题：除了处理安全事件/告警以外，SOAR还能做什么？刚好有一天团队的一个小伙伴问我：能不能把SOAR和运维相关的东西结合在一起？
想了想感觉还是可以的，因此简单的草拟了下面剧本原型图：
2.如何融入检测指导模型
在安全界内有几个比较热门的入侵检测理论指导模型，如Kill Chain、MITRE ATT&CK等。当初在编写SOAR剧本的时候就曾经尝试过将Kill Chain融入到处理流程中，而实际中反馈出来的结果也确实挺有参考价值。比方说如果攻击者是使用多个不同的IP发起的攻击，那在剧本中应该如何的去构造这个链呢？还有就是如何将安全事件/告警和链上的各部分对应起来呢？因为一旦要把各部分串联起来就需要将大量的数据关联起来，而在理论而言应该是链越后面的步骤所占比例越少（表明攻击的越深入），但实际中却发现越到后面的安全事件/告警比例却逐步上升。
因此带来一个问题就是：我们应该用处理前的事件/告警来构造链还是处理后的呢？关于这两个模型的实际应用，欢迎各位小伙伴来商量探讨下！
七、总结
因为作者目前主要研究私有云方向为主，因此本篇主要围绕着私有云下SOAR剧本开发进行讲解。曾经想一度把公有云下的情况也进行概括，但毕竟因为对公有云场景了解不是很深，所以并没有在上文中进行分析。而在私有云场景下则对SOAR的适用范围，剧本的构成以及剧本的灵魂 -- 动作和处理逻辑分别进行了详细的描述，最后则简单思考了SOAR进一步还能做什么。