下图概述了 SOC 在攻击复杂性和攻击量方面的运营营模各种典型功能 。尽管这很难说明和预测，中心但此图可以用作粗略指南 ，设式帮助您推断应达到的建立计运能力水平 。

可能对攻击量没有任何真正的安全了解，但在这个阶段 ，运营营模它并不那么重要，中心主要结果需要定义与组织相称的设式能力级别 ，考虑到威胁概况中攻击的云计算建立计运潜在复杂性 
。

请记住，安全这是运营营模累积性的，因此如果认为组织将成为高度复杂的中心对手的目标，将需要确保 SOC 具有上述所有功能。设式在此示例中，为了支持威胁搜寻，需要确保拥有成熟的用例开发能力等等。

本指南的检测部分详细介绍了这些功能实际包含的内容。服务器租用

SOC 支柱

设计 SOC 操作模型时的一个有用方法是将其分为以下关键支柱。

通知 SOC – 可以在此处放置威胁情报等功能，其中输出应用作 SOC 功能的指导 。在较小的 SOC 中
 ，这可能只是第三方情报源。

开发能力——在这里 ，可以获取通知功能、SOC 需求或分析师想法的输出 ，并将它们转化为技术检测能力 
。还可以将工程团队纳入此处 ，香港云服务器以确保 SOC 能力得到维护和改进。

检测和响应——这是大多数 SOC 的基础，当检测到异常 、恶意或可疑的情况时
，SOC 需要对其做出响应 。这是由事件响应或事件管理等团队管理事件的地方。

支持 SOC – 根据组织规模或 SOC 范围，可能需要支持功能。这是客户关系管理或系统入门的所在地 ，免费模板通常会根据需要调用其他技术功能。

图片

如图所示，通过建立这些链接，每个支柱都会相互影响，避免信息和知识孤岛 ，从而使 SOC 成熟并应对不断变化的威胁形势。

SOC功能

帮助了解运营模型设计中可能需要包含哪些功能；下面列出了最常见的核心 SOC 功能。请注意，这些流通中的函数可能有不同的名称，并且某些函数可能会合并。

威胁情报 (TI) – 该功能应向 SOC 提供有关组织和 IT 资产当前网络威胁的信息。建站模板这通常包括妥协指标 (IOC) 和有关威胁行为者的定性信息。

威胁追踪——该功能旨在对规避现有安全控制的网络威胁进行主动
、迭代和以人为中心的识别。

内容开发或分析– 该团队将可操作的威胁情报转化为 SOC 工具中的程序化检测规则
。然后，这些信息又被用来识别系统和服务中的可疑行为。

工程– 该团队通常负责 SOC 工具的维护 、日志的技术安装（有时称为管道）并确保所有系统都在运行 。源码下载

事件响应或处理——该团队通过调查事件的根本原因来响应安全事件
。他们的主要目标是确定事件是否应升级为安全事件。

事件管理 (IM)  – 当事件被确认为安全事件时，SOC 会将事件传递给其 IM 团队（可以是静态团队 ，也可以是响应的动态团队）。该团队将承担从通信到技术反应的多种职责，所有这些都是为了减少影响并控制安全事件造成的损失

除了这些核心功能之外，一些组织可能会向 SOC 添加其他功能：

漏洞管理- 识别和管理资产内漏洞所需的 SOC 将需要截然不同的资源（例如，用于测试
、修补和评估系统构建的专业知识和工具） 。这将要求 SOC 与系统进行更多的交互 ，这也意味着更大的责任 。重要的是，在设计中捕获此功能所需的额外资源 。

内部威胁- 与仅针对外部威胁的 SOC 相比 ，需要检测和响应内部威胁的 SOC 也将具有不同的设置 。它们并不相互排斥，但由于监控员工是一个敏感主题 ，因此执行此类任务的任何功能（特别是工具集）都应该隔离 。这是因为 SOC 及其员工以及其他业务系统和员工可能会受到安全监控和调查，以应对安全事件。

地点

大多数 SOC 都会外包一些操作，即使这只是您的工具将用于检测的签名。

发展内部职能有很多好处，包括更好的业务背景意识，这将有助于任何需要进行的调查 
。

然而，从业务角度来看 ，如果很少使用某个功能，或者 SOC 根本没有资源在内部实现该功能 ，那么将其外包也可能是有效的 。

在考虑外包 SOC 的哪些组件时，确定这样做的利弊非常重要  。下表旨在帮助您思考这些决定。

例子

内部

外包

优点

缺点

优点

缺点

威胁英特尔 (TI)

更好的商业环境 。 可以寻找与特定相关威胁相关的情报。

资源密集型。成本。

通常 ，大量的 TI 在许多组织之间共享 ，形成一个广泛的网络。

可能非常通用。缺乏商业背景。

数字取证和事件 (DFIR)

更好的业务环境 和更快的设备访问 。

并不总是需要
 。

需要时可以调用。

可能缺乏业务背景。事件响应延迟 。

该表并非详尽无遗 。目的是展示决定哪些组件可以外包的过程
。

资源

在尝试实施运营模式时，找到合适的人选可能是最大的限制之一 。

在这个领域 ，运营模式实际上是一个目标。因为可能需要时间来找到合适的人员或培训现有员工来提供所需的服务。

通过定义威胁概况并了解 SOC 的范围 ，应该能够评估交付威胁概况所需的资源数量 。就像设计过程一样，这可能需要多次迭代才能正确 。

不可能准确规定需要哪些人员或技能
，但是，有一些关键考虑因素：

技能

SOC 分析师所需的具体技能将受到所采用的攻击检测方法的影响
。

但是，应该确保整个团队拥有交付决定的检测方法所需的广泛技术技能和经验。

如果团队能够理解攻击者的心态，这将非常有用 。了解攻击者如何瞄准并尝试利用系统是检测和响应的基础 。

SOC 分析师

优秀的分析师是有效 SOC 的核心，他们有能力适应不断变化的环境，边学习边研究攻击者下一步可能会做什么。对 SOC 工作人员的投资将会带来回报 。

分析师应根据业务需求和当前情况进行指导
。然而，您应该警惕对分析师进行分类和隔离任务。这通常会导致分诊疲劳、工作满意度差以及安全性差等问题 。

下图类似于分析师如何参与检测用例的开发。从了解威胁情报中的威胁 、在内容开发团队中开发用例以及对事件处理中的任何事件进行分类。接触所有这些领域是非常有价值的 。

图片

让分析师参与并了解 SOC 生命周期通常会带来更好的安全性。这是因为他们将更多地接触系统 、威胁情报 、检测、警报的背景，并鼓励更大的协作和协同作用。这种经验的拓宽不应凌驾于任何学科专业之上，应充分利用这些专业知识，但在可能的情况下
，应优先考虑技能多样化 。

治理

应考虑 SOC 在组织结构中最适合的位置 。确保报告关系和监督适合正在执行的工作非常重要。作为此过程的一部分，SOC 将需要确定正在报告哪些指标 。指标可以随着时间的推移而发展，以满足组织不断变化的需求。

管理 SOC 的运营需要强有力的治理，以确保 SOC 合法运营 、遵守法规
、组织政策并确保 SOC 权力不被误用或滥用。SOC 无疑会面临诸如“你能告诉我员工 x 一整天都在做什么吗”之类的问题 ，而回答该问题可能不属于安全运营中心的职权范围。

定义该线的位置将取决于需求 ，但请注意，将资源从检测安全事件转移出去可能会对 SOC 的整体功能产生不利影响。

SOC通常可以制定运营原则来确保其工作合法，例如：

进一步的考虑

此时，SOC 设计的各个部分应该结合在一起，但当然还有进一步的考虑 。

持续改进

持续改进对于 SOC 的成功至关重要 ，因为它们所处的环境和面临的对手都在不断变化 。

这些挑战分为三大类：

营业时间

虽然网络攻击可能发生在一天中的任何时间，但在决定需要运行的时间时，需要考虑一些重要的因素。例如，维护 24/7 的 SOC 将比 9-5 且非工作时间待命的操作需要更多的员工。虽然 24/7 提供全天候监控
，并且可能适合高威胁场景，但 9-5 操作仍然比根本没有 SOC 提供多 100% 的监控。

SOC安全

保证SOC内的数据和服务的安全至关重要 ，因为SOC收集的信息可能被认为非常敏感 ，因此对于威胁行为者而言将成为有吸引力的目标
。这些信息可能包括有关组织的敏感信息 
、个人身份信息 (PII)、财务数据，甚至是在 IT 资产中实施的安全控制的详细信息 。

此外
，如果恶意行为者能够访问这些信息
，他们就可以通过访问或修改这些信息来隐藏他们的踪迹，增强他们的攻击，甚至逃避任何事件后的清理操作
。

SOC 安全性的一些关键考虑因素包括 ：