今天给大家带来的是“逐步建立SOC能力的实践和探索”。

SOC即是（Security Operation Center）安全运营中心。

首先统一下SOC的定义，从Gartner与MITRE搜集了关于SOC的定义如上图，都强调了“团队”，SOC区别于SIEM，强调了人、技术与流程的整体统一。

来自于Gartner2017年的报告中提到没有SOC就无法做到完整的信息安全，同时中型市场公司与大型企业具有相同的安全需求但没有大型团队和预算，SOC不仅仅是奢侈品，而是当今威胁形势的必需品。

如上图，我们认为有以上任意一种情况都可以考虑开始着手建立SOC能力。

“大而全”的SOC并不适合所有规模的企业，逐步建立SOC能力或者采用第三发SOCaaS也许是企业更好的选择。

来自于组织规模、IT投入、关注点与客户预算等等原因，逐步建立SOC能力是可以实现的，完全可以从不同的功能项开始建立，在初期如果能建立监控、分析与响应其中的一部分功能便可以实现部分SOC能力。之后随着SOC能力提高可以逐步增加威胁情报、扫描评估、自动化与安全意识等这些功能。

对于已有NOC（网络运营中心）能力的企业，扩展SOC能力时能够复用目前一部分资源和流程，可以使SOC建设工作更有效率。

我们帮助一些有NOC能力的企业设计过NOC/SOC聚和运营的流程与体系，经过研究发现NOC/SOC之间有部分可以复用的流程、工单与响应团队；无法完全复用又因为2者的关注点不同、知识域不同与对手的本质不同。

在建立SOC能力之前，我们需要对客户的规模和能力投入做一些预期来选择相应的SOC未来的规模。如上图列举了不同规模的SOC的组织架构，其中也包括中小型企业可能会使用的虚拟SOC方式及采用第三方的SOCaaS。

逐步建立SOC团队的第一步便是“人”，其中有两点需要强调：通常成员质量要求远远大于数量要求；思维意识远远大于背景和技能要求。

优秀的SOC团队需要有：对于安全分析的热情和好奇心、强烈的直觉和思考能力、考虑大局时注重细节、接受新事物的能力以及强烈的求知欲。

优秀的分析师往往可以做到：

• 从看似良性的审计日志或IDS警报集中找出潜在的入侵

• 构建新的工具和技术，从而将人力密集型任务压缩为可以在短时间内完成的工作

• 收集不同的数据（例如系统日志或硬盘映像）、构建事件时间表，并对潜在入侵的处置进行评估

• 使用网络协议分析工具了解各种线索，以识别跨开放源代码互连（OSI）网络协议栈的所有七个层的流量的含义及暗示

• 剖析恶意软件，并对其攻击媒介和可能的目的形成有效的了解

• 识别系统错误配置，并与系统所有者合作纠正错误配置

• 与SOC成员及合作伙伴建立发展关系，共享最佳实践，工具和技巧

• 站在对手的立场和角度上查看网络和支持的任务的结构，并评估在何处值得关注

以下1至2项有较深入了解可以作为SOC团队成员的候选人：

• Linux / UNIX系统管理、以及网络（路由器和交换机）、Web服务器、防火墙或DNS管理

• 使用NetFlow和协议收集和分析工具

• 整个TCP / IP或OSI网络协议栈的工作知识，包括主要协议

• 流行的加密算法和协议的工作知识

• 安全工程和体系结构工作-大型分布式系统的安全功能分析和工程

• 使用某些 NIDS / NIPS工具

• 使用各种日志聚合和SIEM工具

• 具有漏洞评估和渗透测试工具的经验，例如Metasploit，Kali Linux等

• 对于从事恶意软件逆向工程的人员

• 有编程和脚本语言以及文本操作工具的经验

• 对于从事取证工作的人员，具有Windows和其他操作系统内部知识以及基础的文件系统知识，并可以使用媒体取证和分析工具

通常来说SOC技术集包括以下三大类：对象本身、分析管理工具与知识。

• 对象本身里有FW/IPS/EDR/SAV/WAF/NAC/DLP、Windows/Linux/DNS/DHCP等。

• 分析管理工具里有数据标准化/解析/聚合/关联/规则、实时监控/可视化/趋势/告警/报告等。

• 知识里有安全产品知识/配置/最佳实践等…

以上包括了非常丰富广泛的技术要求，这也是很多公司在着手建立SOC能力时望而却步的原因之一，然而也完全可以在以上技术集进行选择和组合来逐步建立SOC。

云纷在AWS云上部署了IX（Insight-X）安全监控和分析平台，基于AWS上的计算引擎、块存储搭建了基础的SOC平台及服务。通过AWS网络服务，云纷实时收集安全数据，使用对象存储用于数据增量备份，满足数据的实时性、安全性和平台的容灾要求。

同时需要强调的是，收集对象种类广泛并不等于收集全部，收集数据种类越多不止对于人力与计算资源等要求过高，也可能会产生管理层预期和实现效果的差异。

成熟的分析管理工具不等于开箱即用，大量的SIEM类产品内置了多种功能模块，但针对企业的自身要求和安全现状都需要进行大量的运用、测试、分析和优化等工作，并需要团队长期运营改善。当然所有的知识集的了解都不是一劳永逸的，需要安全团队不断的学习跟进。

在进行完一定的技术集的选择之后通常场景化的安全分析会是个好的开始。场景化的分析可以帮助企业自上而下理解SOC的工作内容， 保持视角统一，场景通常可以：基于威胁（or攻击链）、基于资产、基于业务场景。

场景化安全分析中UseCase可以是1个告警、1个仪表盘、1条规则，能够反应一个有价值的用户目标即可认为是一个UseCase。

上图罗列了一些常见的UseCase的交付物，经过实践证实每个企业初步建立SOC时的关注点与需求千差万别，很难用统一的标准衡量与定义。

流程是衡量一个SOC团队的成熟度的重要标准之一。初步建立SOC能力时至少需要理解SOC的基础任务和节奏：

• SOC通常会指定一组人员专门对实时警报、来自用户的电话和其他日常任务进行分类。这个组别通常被称为Tier 1。如果Tier 1确定警报达到某个预定义阈值，则创建案例并将其升级到Tier 2。此阈值可根据各种类型的潜在“不良”程度（事件类型、 目标资产或信息、受影响的任务等）进行定义。

• 通常，Tier 1检查每个潜在事件的时间跨度确定在分钟级别。检查时间取决于SOC的升级政策、运营概念、分析师数量、组织规模和活动量等；如果事件花费的评估时间超过一定时间，它升级到Tier 2。

• Tier2接受Tier 1的案例并进行深入分析，以确定实际发生的情况——在给定可用时间和数据的情况下——以及是否有必要采取进一步行动。在做出此决定之前，可能需要数周时间来收集和检查所有必要的数据，以确定事件的范围和严重程度。

此外上图罗列了一些SOC流程相关的长期关注点。

上图汇总了SOC能力对于企业的价值。

了解企业自身风险：增强安全可视化、关注重要资产和业务、威胁、漏洞和风险。

提高安全管理能力：展现安全管理价值、最大化安全投资价值、逐步弥补企业安全短板。

提高响应能力：实时监控和检测、事件溯源和事件后处理、更完整的SLA（5X8–7X24）。

更好的对应合规和审计：应对各种审计要求、国内外合规要求、（如：等保2.0，GDPR，HW等）。