前言
毕业之后因为疫情找不到好的渗透岗，一度考虑去做安全运维，最后机缘巧合去了一家安全集成公司，什么都做，每天都感觉在打杂。这个过程很痛苦，但是也让我对安全运营有了一定的了解和思考。而后续在一些hw和重保中，我对于安全运维也开始有一些更进一步的看法了。
当我看到SOAR的概念时，很自然地，我将其与SOC平台进行了比较。它们之间有一条很细微的区分界限，这条线很难把握但又确实存在。我希望通过这篇文章对SOAR和SOC进行一个稍微深入一些的探究。
从源头探究起：什么是SOAR（Security Orchestration, Automation and Response）？
从各种资料中我们不难发现SOAR的定义最初在2017年由Gartner创造，它的词条定义是：
SOAR refers to technologies that enable organizations to collect inputs monitored by the security operations team. For example, alerts from the SIEM system and other security technologies — where incident analysis and triage can be performed by leveraging a combination of human and machine power — help define, prioritize and drive standardized incident response activities. SOAR tools allow an organization to define incident analysis and response procedures in a digital workflow format.
SOAR指的是一种可以让组织收集由安全运营团队所监控的输入的技术。例如，来自SIEM系统和其他安全技术的警报有助于定义、确定优先级并驱动标准化的事件响应活动，在这些安全技术中，可以利用人力和机器的力量来执行事件分析和分类。SOAR工具允许组织以数字工作流格式定义事件分析和响应程序。
（机翻）
可以看出这是一个很空洞而又宽泛的概念，后续Gartner又对其进行了不少的修补，最重要的是两篇报告：
Preparing Your Security Operations for Orchestration and Automation Tools
Market Guide for Security Orchestration, Automation and Response Solutions
第一篇文章对SOAR进行了很详细的定义与指导，但是我没有找到可以免费看这篇文档的地方，所以这里我只能放出它的目录来:
Analysis
- Defining SOAR
- SOAR Drivers and Enablers
- SOAR for Security Staff Productivity
- Additional SOAR Drivers
- SOAR Enablers
- SOAR Use Cases
- Detection and Triage Use Cases
- Incident Response Use Cases
- Threat Intelligence Use Cases
- Detailed Use Case Example: Phishing Email Handling
- SOAR Technologies in Depth
- Workflow and Collaboration Engine
- Case and Ticket Management
- Orchestration and Automation
- Threat Intelligence Management
- Other Components and Capabilities
- SOAR Architecture
- Differences Between Existing SOAR Tool Categories
- SOAR Future
- Strengths
- Weaknesses
Guidance
- Decide on the Need and Readiness for SOAR
- Build a Business Case for SOAR
- Select the Right SOAR Tool for You
- Test the SOAR Tools
- Align Skills Needed for SOAR Success
- Deploy the SOAR Technology
- Use SOAR Tools Effectively
- Expand and Evolve Your SOAR Deployment
The Details
Gartner Recommended Reading
从这里我们可以看出这篇报告已经涵盖了整个SOAR的定义、应用场景和使用案例，我们可以认为这篇报告确实配得上它自称的”our amazing SOAR paper”。所以我也对它非常好奇，如果有谁可以分享给我满足一下好奇心，那可真是非常感谢了。
再参考一些侧面描述SOAR的文章，如：
https://securityintelligence.com/posts/whats-new-2020-gartner-market-guide-soar-solutions/
https://www.dflabs.com/resources/blog/gartner-soar-magic-quadrant-the-best-of-incman-soar-is-yet-to-come/
https://blog.technologent.com/gartner-soar-model-future-it-security
现在我们可以用自己的话来对其进行一个描述了：SOAR平台是以workflow（工作流）和playbook（剧本）为核心的安全运营中心，它更强调了自动化判断报警级别的作用，并以playbook为核心设置了自动化流程。
从这个意义上我们可以发现SOAR的概念非常眼熟，不管是SIEM还是SOC都与之有一些相似性，但是又各有各强调的点。这也是安全方面概念的一些难点：几乎没有突破性的进展，更多是面对某些情况的修补和适配。（这里可以多说几句，最近几年安全方面强推零信任，安全设备换着名字翻新，而实际上几乎没有技术性的突破。这感觉真是太荒谬了，一方面是red team的技术和工具不断革新换代，利用点从框架漏洞转向侧信道再跳到代码审计上的0day漏洞，利用难度逐渐下降，攻击点越来越多。而blue team呢？不断纠结几个小的点的更新，从零信任到蜜罐到SOAR，不断缝缝补补最新的漏洞，俨然一副”安全的大厦已经建成，之后只需要小修小补”的姿态，最后甚至开始从制度上收紧，我不得不怀疑安全方向未来的发展。
让我们更进一步，SOAR和SIEM还有SOC之间有什么关联呢？
那么让我们先来看一下，什么是SIEM，什么是SOC：
SIEM (安全信息和事件管理)是软件和服务的组合，是SIM（安全信息管理）和SEM（安全事件管理）的融合体。两者的区别在 于SEM侧重于实时监控和事件处理方面，SIM侧重历史日志分析和取证方面。SIEM为来自企业和组织中所有IT资源（包括网络、系统和应用）产生的安全信息（包括日志、告警等）进行统一的实时监控、历史分析，对来自外部的攻击行为和内部的违规、误操作行为进行监控、审计分析、调查取证、出具各种报表报告，实现IT资源合规性管理的目标，同时提升企业和组织的安全运营、威胁管理和应急响应能力。
SOC平台，网络安全管理平台。
提供集中、统一、可视化的安全信息管理，通过实时采集各种安全信息，动态进行安全信息关联分析与风险评估，实现安全事件的快速跟踪、定位和应急响应。
从监控、审计、风险和运维四个维度建立起来的一套可度量的统一业务支撑平台。
从中可以看出，如果以中国的安全设备习惯来说，SIEM更多地接近日志审计平台，各大安全厂商都有这个产品，集中所有的日志对其进行分析（一般是分布式部署），同时可以解决掉等保的日志相关的合规要求。在使用中我用过启明星辰的泰合日志审计平台和360的日志审计中心，还有诸如graylog一类的开源日志平台。它们的主要功能很相似：从各个设备（不局限于安全设备）上发送日志和告警到自己这里，对其进行解析，归纳（有些可以分析），资产发现。一般不会具有响应动作。
而SOC平台，更多地是作为一个集中化的处理中心。它从日志审计中心中读取流量，然后进行分析，归纳，总结。以国内的产品来说，大部分厂商的态势感知平台都是为了这个目的而生的——————一个可以产生警报，调取日志，查询入侵路径的运营中心。这个中心需要部分安全人员值守，这也就是安全运维主要驻场的地方了。
而SOAR，更多地是作为一个SOC的+1版本，为了解决企业使用SOC平台方案后需要大量人力值守的情况，于是自动化就变成了一个新的需求点，SOAR也是为了解决这个需求而应运而生的。SOAR从SIEM中提取日志（是的SOC平台也需要从SIEM中提取日志），如果日志触发了SOAR的剧本的开始 条件，就会开始执行这个剧本。举例来说，某个xxx设备的xxx告警日志会触发我设定好的告警剧本，那么当SOAR平台收到这个告警日志，就会开始执行剧本的后续环节，例如发送警报到邮箱或是钉钉提醒。
短暂休息一下，让我们聊聊目前的安全现状。
在几年的安全工作中也大概地理解到了安全工作的尴尬。在过去我能想到的无非是：安全本身并不产生收益，但是却会消耗资源，所以各大公司都不愿意加大安全预算。
从现在的角度看起来这种想法并不能算错，但是委实太粗浅了一些。企业在安全方面的投资在我看来更像是一种”降低受灾概率”的存在。安全设备并不像备份设备一样能够为灾难或是数据丢失兜底，所有安全厂商都会告诉公司，你的系统有很多安全风险，只要购买了我们的xxxx，公司的网络系统就安全了。但是事实是，即使你购买了全套的安全设备，从防火墙到waf到日志审计到防病毒到态势感知到蜜罐…全部上上去，你的系统依然有可能被正面攻破/迂回潜入，你的数据依然有可能会被窃取。
那么企业在这样的环境下，又凭什么花费大力气在安全上呢？
安全建设从来都需要”由上而下”的力量作为第一推动力，否则企业不可能付出大的投入去做安全。而国内常见的安全现状是什么呢：甲方公司出于合规性的要求去做安全建设；甲方公司领导被乙方洗脑决定推动安全建设来解决自身的安全问题。后者当然比前者要来得更主动，更有决心，更有效果。但是在工作中我见过的后者公司，一只手都能数的过来。
目前的国内公司的安全情况可以从安全投入来讲粗浅地分为三类：
- 几乎没有安全投入的公司，这类公司一般是初创公司或者小的实业公司，没有太大的网络业务，官网就挂一个静态页面或者随便找外包用框架做一些展示页，维护当然更无从谈起。大部分脚本小子的练手方式就是baidu/google hack这些公司的官网。
- 稍微有一些安全投入的公司，有一些基础的安全设备如防火墙，waf。可能外包了安全业务给某些小的集成公司或是自己有几个专职安全的IT人员。这些大多是政府机关或是特殊行业公司，让他们对安全方面加大投入的大部分推动力是合规要求。最近几年的hw与等保让这些公司不得不加大在安全上的投入，从结果上来看确实有作用，但是从实际上来看也只能防一些小蟊贼，但是对于稍微深入的大哥还是效果有限。（今年9月1日施行的《关键信息基础设施安全保护条例》禁止了对信息基础设施的扫描，这可以有效地防范来自国内的攻击，然而对于国外的黑客依然无力）
- 安全措施很妥当的公司，每年有不错的安全预算，一整只安全团队，安全设备样样齐全，安全管理制度合理。这样的公司大多是实权单位或是大型企业，也是HW中能坚持到最后几轮的公司。
但是从结果上来看，这三种公司并没有本质性的差别，在hw中，这三类公司都可能在第一轮被打穿；而在实际中，我见过一则通报，一个地级市的医院单位（第二类）和一家大型企业（第三类）同样遭受了病毒攻击，当时领导开玩笑地问我：你说他们投入在安全方面的预算起作用了吗？
我哑口无言。
blue team先天上的弱点是，攻击永远比防御要简单，但我并不同意“防御就应该只是修修补补”这种说法。red team正在发掘更多的攻击面，更多的漏洞，更多的工具，形式依然是严峻的。是，最近几年在HW的压力下政府机关的安全投入在不断提高，防御方不断地在修补漏洞，攻击的成本越来越高，看起来成效喜人，可背后是更大的安全运维压力和安全管理压力。头疼医头，脚疼医脚，纵然在IT方面的准则是“没有银弹”，但这种叠补丁式的安全防御法迟早会决堤。
防御方需要一个能够一锤定音式的方法，一种能够解决掉大部分问题的集中化安全中心，但不是SOC，至少不是现在的SOC。SOAR和它的概念接近，但我更看好态势感知的预判功能的后续进展。目前的安全管理类的平台在我看来是纯粹需要人力去堆砌，希望态势感知的发展可以逐步缓解这种安全现状。
最后，让我们来谈谈SOAR的现状和展望
说回来，SOAR的出现本身就是为了解决安全运维的压力，但是它的特点——————workflow和playbook作为自动化流程，在我看来现阶段无非是实现流程控制，远远谈不上自动化。（在这里更要吐槽一下安全厂商的假概念，所谓大数据，人工智能，在安全方面的使用比例连画饼都算不上。）
放眼到全球，我们也可以从Gartnar在2020年发布的SOAR市场报告中可以看到这么一段：
SOAR tools are still primarily leveraged by organizations with a security operations center. Use cases to support security operations beyond threat monitoring and detection, threat intelligence, and incident response and threat hunting are still nascent.
SOAR 工具仍然主要由拥有安全运营中心的组织使用。除了威胁监控和检测、威胁情报、事件响应和威胁搜寻之外，用于支持安全操作的用例仍处于起步阶段。
很显然，SOAR目前在商业上是用作SOC的作用，其自动化特点在逐步完善，但是其安全操作的特点还没有被开发，这应该是它下一步的发展方向。安全运维的流程无非是：查看日志-发现问题-确认问题-处理问题，SOAR现阶段如果能实现帮忙在查看日志之前做一些筛选工作已经足矣，安全运维的压力大多也是在茫茫多的报警日志中去寻找真实的攻击事件，误报严重这件事从根上就不应该让SOAR来解决，而应该从底层，从安全设备的角度来处理。
前段时间看到了国内安全从业者的一段话，我感觉很受启发，作为结束语正合适:关于SOC安全运营中心的理解是多种多样的，有人把它定义为一套包罗万象的安全系统，在系统的基础上，增加一套安全人马来使用SOC系统；有人把它定义为一个安全体系理念，围绕理念，采购产品，添加人员；也有人把它定义为一个部门，例如，安全部=安全运营中心SOC=安全响应中心SRC=安全运营与响应中心SORC。围绕这个SOC部门，配备设备、技术、管理要求；我们不纠结于哪个定义，但要理解，在SOC中，人、技术、管理缺一不可，否则SOC将不能实现O（operation）运营的效果，从而导致失败；
后记
这篇文章断断续续写了一周，思路和逻辑都很散漫，我很不满意，但是应该也不会修改了。
希望几年后的我能够对这些概念有更多的思考。