企业如何选择适合的SOC模型？

SOC平台简介

威胁情报管理

威胁和漏洞管理

从运维的角度SOC可以大致分为以下5种模型：

该模式没有专用的设施，也没有公共的“作战室”。相反，它由承担其他职责和职能的团队成员组成。由于没有专用的SOC基础架构设施，因此团队成员依赖分散的安全技术，并在发生安全事件时才会响应。

通常适用于仅发生偶发事件或与MSSP或其他第三方合作的小型企业。云御还认为，在过渡到更专用的SOC模型期间，该模型被用作临时方案。它通常是纯被动式的，但通过利用高级分析和自动监控功能（如相关性或基于规则的警报），可以在此模型中实现更主动的状态。在高风险环境中，利用异常检测和基于行为分析的警报（例如用户和实体行为分析[UEBA]）可启用这种主动状态。其特点可用概括为：

在某些最终用户组织中通常在资源共享层面把SOC和NOC进行融合，但只有当两者相对独立运作并彼此间的协作很少时，该模式才算是成功的。事实上，存在诸如组织政策，预算和流程成熟度不同等因素，很可能导致工作人员执行多项任务（SOC和NOC）。

NOC遵循事件和事件管理的信息技术基础结构库（ITIL）定义，但对于安全事件，ITIL并不适用。此外，如果没有适当地合并NOC和SOC，则会在两组之间造成严重的内部冲突及引起某些风险。

因其可在预算方面节省大量工具和设施成本投入，该模式还是有一定的市场。但安全和风险管理的领导者绝不能因这种融合模式的优点而掉以轻心，否则可能影响SOC的使命及其帮助安全交付和实现业务成果的能力。其特点可用概括为：

拥有专门的基础设施和专业团队，不仅可以履行安全职责，还可以在同一组织执行其他一些关键的7x24的IT运维操作，从而降低成本；

常规的使用者：中小型和低风险的大型企业，其中网络和安全功能已经由相同或重叠的一组人员和团队执行。

由一些专门的人员和基础设施组成，并由其他内部业务部门和/或外部服务供应商的其他团队成员进行了扩充。一个或多个专门的人员负责SOC运维，并根据需要让兼职团队成员和第三方参与。如果组织无法7x24全天候运行，可以借助供应商弥补由此产生的差距，从而形成混合SOC模型。这些供应商可能包括MSSP（托管安全服务），MDR（托管检测和响应）服务供应商，共同托管SIEM服务。他们是特殊的安全咨询供应商或系统集成商（SI）。

该模式可以降低7x24的运营成本，因此非常适合中小型企业，尤其是与第三方广泛合作的企业。此外，它允许组织在内部开发系统功能的同时保持稳定的安全操作。在这段时间内，任何资源缺口都将得到及时填补，现有的安全资源可以将重点转移到其他活动上，例如对事件进行更深入的调查。通常采用此模型的原因是缺乏技能和专业知识、总体预算约束及7x24全天候安全操作的巨大成本和差距。

需要注意的是，如果安全运营预算受到限制，则应优先考虑保持内部高业务价值和关键安全功能。例如IT安全基础架构设计，集成风险管理（IRM）和安全设备管理等，资源应优先投入到以上领域。其他领域如安全事件监控，检测和事件响应等可充分借助外部力量（MSS服务供应商）协作，他们还可以在业务高峰期和节假日，或设施故障和停机期间为突发事件或异常事件提供帮助。其特点可用概括为：

具有集中式专用基础设施、IT安全基础架构和团队。有相当高的独立性或完全独立于IT，拥有连续的日常安全操作所需的所有资源。团队通常由安全工程师，安全分析师和SOC经理组成。在轮班制操作的情况下，每个班次也可以有一个班次主管或值班经理。

完全集中化的SOC适用于具有多个业务部门、地理位置分散、高风险和高安全性要求的大型企业，以及提供MSS服务的供应商。其特点可用概括为：

超大型组织的区域办事处具有一定的运营独立性（如全球化集团在各个国家或地区的子公司在当地法律法规的限制下必须保持一定的独立性），提供MSS服务供应商和提供共享服务的组织（如政府机构），上述组织可能具有多个SOC。在这些情况下指挥型SOC应运而生，在要求自主运行的情况下，它们将充当集中式或分布式SOC。在某些情况下，SOC将协同工作，但必须进行分级管理，这时候应将一个SOC指定为指挥台SOC。指挥台除了提供其他专业知识和技能（例如法医调查和/或威胁分析）以外，还将协调安全情报收集，产生威胁情报并将其整合以供所有其他SOC使用。

有时，这就是计算机应急响应小组（CERT）在较小国家/地区的运作方式，这些国家/地区除了提供日常的安全操作外，还充当聚合和协调点。其特点可用概括为：