建立安全运营中心（SOC）设计运营模式

了解组织试图防御的建立计运威胁以及需要监控的资产后
，现在可以开始考虑运营模型应包括哪些内容。安全

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

SOC能力矩阵

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

请记住 
，安全这是运营营模累积性的  ，因此如果认为组织将成为高度复杂的中心对手的目标 ，将需要确保 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将在法律
、相关法规、组织政策等范围内运作。敏感数据只会被收集/搜索/索引 ，以检测可能损害组织声誉 、繁荣和安全的恶意
、可疑或滥用行为
。数据只会保留到不再需要为止或最多 x 个月。

进一步的考虑

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

持续改进

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

这些挑战分为三大类：

不断变化的环境——组织很可能会不断发展 ，业务可能会发生变化，对攻击者更具吸引力
。试图保护的资产可能会发生变化
，从而导致监控能力出现缺口
。如果将审核周期纳入 SOC 流程中 ，应该能够掌握这一点。不断变化的威胁形势——攻击者不断更新他们的方法，动机可能会改变。这就是威胁情报发挥作用的地方
。保持检测有效性- 所有检测方法都需要 SOC 来构建和维护其检测方法 ，以保持有效。这包括构建新的安全警报逻辑并投资于分析师的持续发展。

营业时间

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

其他 IT 职能部门的工作时间是多少？ 大多数重大事件都需要其他 IT 职能部门参与响应。考虑这些团队的工作时间。如果其他 IT 功能仅朝九晚五地覆盖且没有值班安排，则 24/7 SOC 的效率将大大降低。组织是否已经拥有可以接收高优先级安全警报的 24/7 IT 职能 ？有些组织已经由另一个 IT 团队（例如数据中心运营团队）执行 24/7 全天候覆盖 。考虑将高优先级的非工作时间安全警报发送给该团队进行初步分类，然后再升级给 SOC 分析师。考虑向非工作时间待命的SOC分析师发送高优先级警报。 或者 ，如果确定需要立即响应潜在事件的能力 ，请考虑使用警报自动通知待命的 SOC 分析师。

SOC安全

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

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

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

敏感数据- 这是一个难以控制的方面，尤其是在需要保护大量客户和系统的SOC中。重要的是，SOC必须在其法律和监管要求范围内运作 ，并确保采取适当的控制措施来执行这一要求
。这可以是数据摄取的验证或检测敏感数据的警报
。隔离- 应该隔离SOC服务
，这样 ，如果您的 IT 资产的某个组件受到损害，攻击者将无法直接访问SOC数据 。职责分离- 拥有高权限管理员账户的用户可能会在组织内执行恶意活动。因此 ，SOC服务应驻留在单独的安全域中。这意味着将检测到利用管理员账户的任何潜在攻击，并且威胁行为者将无法影响审计跟踪。审计- SOC服务的用户（SOC工作人员）必须承担责任，这一点很重要。这可以通过创建可以报告SOC操作并发出警报的特权账户和功能来完成。根据良好的安全实践 ，这应该遵循最小特权原则，并且对此的访问应该受到极大的限制
。