多年来，安全从业者将安全运营中心 (SoC) 想象成一个大房间，里面摆满了昂贵的显示器和椅子。在这些人的心目中，一排排的分析师坐在那些椅子上，看着那些显示器闪烁的警报，让 SoC，好吧，一个 SoC。
安全运营中心的这一愿景源自网络运营中心 (NoC) 的最初愿景，网络运营中心 (NoC) 可能比 SoC 早了十年或两年。这本身可能源于1960 年代某些设施的巨大控制中心的图片。

什么

这是现代 SoC 的愿景吗？赞同上述 SoC 愿景的人认为 SoC 中的“中心”一词代表中央位置，即中央物理设施。
对他们来说，SoC 中的“中心”二字表示一个地方。他们谈论集中运营能力和分析师的中心位置。他们考虑集中安全运营人员，而不是联合或分配。
业内一些人对这一愿景提出了质疑，但他们反对说“SoC 已死”。对我来说，这听起来他们同意上述愿景，他们只是希望它消失。他们谈论需要杀死您的 SoC，或声称他们运行SoCless。

这里有冲突吗？

听到没有，你会感到惊讶吗？当我想到一个现代化的安全运营中心时，我不会想象一个房间。在全球大流行期间进行的两年安全行动应该已经使人们忘记了这一愿景。毕竟，如果你可以运行两年的分布式 SoC，为什么不能继续这样做呢？请注意，我刚刚提到了分布式 SoC——但这不是矛盾的术语：分布式和中心吗？
此外，大流行告诉我们，物理中心对于 SoC 来说并不是真正必不可少的。分布式 SoC 模型似乎可以在大流行后生存下来，并为寻找最优秀的人才和帮助建立最多样化的团队带来好处。然而，这些“分布式 SoC”仍然是控制的“中心”、协调的“中心”、专业知识的“中心”——一个检测和响应卓越的中心。
我认为我们生活在一个分布式安全运营中心的时代，这并不矛盾。神奇的是，中心这个词不代表一个位置，而是代表一个卓越中心。
事实上，由于合同义务、合规性、对其他高度自治的业务单位或机构的中央监督等原因，大多数组织都需要保留某种形式的集中检测和响应功能。即便如此，成功的安全组织将是那些去中心化和分配权力的组织，控制，尽可能的专业。如何？通过添加 SoC 的新定义：卓越安全运营中心。
想一想——当你想到一个卓越中心时，比如云迁移，你会想象一个闪烁着灯光的大房间吗？可能不是。当您认为某个组织在云安全方面拥有卓越中心时，它是否必须是一个有围墙和警卫的物理设施？
自然地，这种安全操作方法允许您在不受地理区域限制的情况下雇用现有的人才，从而极大地简化了招聘。这种优势可能是组织的决定性因素，受制于该领域的短缺。
自主安全运营愿景要求将您的 SoC 想象为卓越的安全运营中心。而且因为“SoCoE”是一个讨厌的首字母缩写词，我们为什么不直接称它为……SoC。

为什么

这种转变的动机是什么？除了目前在家工作增加的情况外，还有其他激励因素。例如，许多组织都在分发安全专业知识的情况下运作。当 IT 经历 DevOps 和SRE 转型时，许多类型的专业知识变得分散，分布在团队中。安全也是如此，对吗？然而，对于许多组织来说，安全操作——SoC——仍然是一个核心功能。但为什么？为什么不能分散安全运营，同时保留卓越安全运营中心（即 SoC）的卓越性？
除其他外，这种转换还允许将业务上下文和应用程序上下文更好地结合到安全运营活动中。毕竟，不同办公室和组织的本地团队拥有对有效安全运营至关重要的洞察力。例如，确认警报通常需要应用程序所有者等团队的协作。中央 SoC 的传统愿景涉及 SoC 分析师追逐这些团队成员，以确认警报的真正含义。但为什么要这样做？为什么不联合警报分类，至少对于某些警报？
随着数字化转型的发生，越来越多的开发团队需要这种安全技能。“SO CoE”有助于开发这些嵌入式人员，然后可能会为他们提供一个 API，他们可以将他们的 CI/CD 连接到以便在需要时集中报告某些内容（好吧，我们在这里做梦，但无论如何……这看起来像一个无论如何，更哲学的帖子）。但在很大程度上赢得这里意味着让这些人能够成功，而不是试图从一个中心位置为他们完成工作。

如何

自然，许多组织会喜欢将 SoC 作为安全运营卓越中心的概念。但是，他们将无法开始朝这个方向前进。将您的安全运营中心发展为卓越中心而不是物理位置的一些关键要素是什么？
自然，我的第一个建议将集中在研究自主安全运营方法以及从SRE 学习中获得其他经验教训，因为它们改变了 IT。
从战术上讲，在全球大流行期间尝试分散和分布式安全操作的组织应专注于汇总、总结和实施这些经验教训，使它们成为其工作的永久特征。
值得注意的是， ASO 愿景的许多元素在分布式环境中工作得更好，并且实际上并不需要一个物理房间。作为旁注，这不是针对物理 SoC 的运动——如果一些分析师在低隔间的墙壁上向他们的同事大喊大叫时更好地协作，那是完全可以的。

下一步是什么

这一切都很好，也很有趣，但是对您今天的安全运营团队有什么实际影响？
第一点建议是警告认为SoC 已死至少是错误的。如果我们正确地将 SoC 定义为专注于检测和响应的团队，那么它并没有消亡，但现在比以往任何时候都更需要它。
但是，面对面的物理 SoC 很可能已经死了。此外，对于许多环境和情况，也许它应该是死的，因为这个模型甚至可能不起作用。为什么不？因为如果您要随着威胁和资产增长线性扩展团队，您根本无法将足够的人放在房间里。虚拟化和分布式是唯一的出路，将其扩展到“SoC as SO CoE”将在相同的道路上产生更好的结果。
SoC 作为 CoE（或作为一种能力，如此处所述）意味着卓越的检测和响应不仅仅是雇佣最好的 SoC 分析师。它是关于设计更好的检测，同时也使环境支持 D&R 工作得更好。SoC 作为 SO CoE 是关于运行“影响操作”以使检测和响应更加成功。正如我之前所说，我认为“你不能‘操作’你的方式来取得 SoC 的成功，但你可以‘开发’你的方式”（来源‘）
感谢 Dave Herrald 的想法和一些文字贡献。

21.07.22-新论文：《自主安全运营——安全运营中心10倍转型》

21.05.28-一个 SoC 试图检测云中的威胁……你不会相信接下来会发生什么

21.05.14-SoC 趋势 ISACA 网络研讨会问答

21.03.02-停止试图将人类带出 SoC……除了……等等……等等……等等……

21.02.11-SoC 威胁覆盖率分析 - 为什么/如何？

20.12.23-新论文：“SoC 的未来：SoC 人员——技能而非等级”

20.08.20-新论文：“SoC 的未来：塑造现代安全运营的力量”

19.12.13-当心：小丑级 SoC 仍然比比皆是

现在，SoC 最终是一个团队（这对那些说“是的，我们今天可以卖给你 SoC”的妄想者来说是一个有用的提醒）。人们在快乐时工作得很好。我见过一些令人讨厌的“SoC 衰退”案例，重复性和手工工作只会扼杀人才。由此产生的残羹剩饭被证明与攻击者能够向他们投掷的最好的东西相提并论。不努力留住优秀人才会 扼杀 SoC。因此，回到这个网站。我看到 SoC 试图自动化任务和流程，以使人们免于被所有例行公事所烧毁。伟大的？好吧，他们没有写下任何流程，甚至没有在任何人的脑海中清楚地表示出来。当然，有一些工具（例如SOAR）可以通过自动化、提高一致性和减少错误来实现价值，但要实现自动化，您通常需要首先掌握它。你有它，它有点咆哮，但希望它能让你避免你的 SoC 中的一些错误。

现代安全运营十问

安全运营中心（SoC）是一种自动化的高效平台，已被众多企业所采纳作为其安全运营的得力助手。但是，在SoC平台的运营过程中，却难免会遇见一些难题。前几日，ISACA网络研讨会成功举行，会议的重点即安全运营中心的治理。本文将会议整理为问答形式，帮助企业获得SoC运营的提示以及了解SoC平台的趋势。

Q：既然SoC首先是一个团队，那么传统SoC与现代SoC的区别在于哪些功能？

区别的功能包括：威胁狩猎、威胁情报、数据分析以及一些别的功能。这些在传统的SoC中都不太常见。具体的可以看这篇论文章《SoC的未来：SoC的运营者——重要的是技能，而不是等级》。

Q：能否实现基于AI/AL的完全自动化，实现“观察—调整—决策—行动”的OODA循环？使SoC可以实现完全自动化的上机日志源、威胁检测规则的创建、PlayBook的创建、响应、自动集成和执行。

以目前的现状来看，短时间内，大多数SoC无法实现完全自动化。最麻烦的部分是在自动响应和其他行为的行为链末端。此外，还有一些有高度不确定性的状况仍然需要人工手动处理。最后，一些棘手的遥测源的上线，有时也需要人工迭代和调整配置。
如今，自动化在检测自动化在检测（创建警报）和分流（充实和确认警报）等领域已经变得十分普遍，但在补救和数据上机方面却不尽如人意。我不指望这方面在短时间内会有什么大规模的变化，但随着企业采用更多的公共云，这些领域的自动化自然也会随之增长。

Q：SIEM和SoC之间的区别是什么？

SIEM是一种特殊的安全工具，而SoC则是一个团队以及他们使用的相关流程和工具（目前大部分SoC中包含了SIEM）。这就是为什么当我听到 SoC-as-a-service（安全运营即服务）时，总是感到有点奇怪。我个人更喜欢MDR这个词。

Q：如果我们不能把顶级攻击者赶出我们的网络，那公司该如何应对这种风险？

在这里，我很难给出规范性的建议，因为这是一个艰巨的挑战，并且属于“随机应变”的领域。遇到这种情况，大多数组织会寻求帮助，来邀请第三方事件响应团队来协助他们调查，最终将攻击者赶出去。
虽然听上去有些悲观，但是我们完全有可能会遇到比自己的团队更强的攻击者（即便你的团队已经很优秀）。在这种情况下，企业不得不寻求帮助。尽管这会产生成本，但却是无法避免的。

Q：你认为需要采取基于风险的方法来设计和管理现代SoC吗？

在你的问题里，”基于风险 “的意思较为模糊。目前，大多数正在运行的SoC并不是完全基于合规条例中的固定检查表而建立的。在这种情况下，我遇到的大多数SoC至少在某种程度上是基于风险的。

Q：怎样才能成为一个优秀的SoC？

这很难用几句话来概括。不过，我认为一个糟糕的SoC是因为过度关注技术以及过度苛求流程，而一个优秀的SoC则是把运营的人放在首位，然后才是流程以及技术。

Q：你对SoC中使用的AI工具有什么看法？

从我还是一个分析师的时候我就开始思考这个问题，到现在已经持续了很多年。随着时间的推移，我也有了自己的立场：唯一的办法是在短期内对AI用于安全领域持怀疑态度，但站在长远角度则持乐观态度。
虽然有很多供应商疯狂地夸大其词，称他们的ML/AI工具如何帮助安全分析师顺利解决问题。然而，正如人工智能在其他领域逐步发展去帮助人类一样，网络安全领域中的AI也需要发展。
今天，你在SoC中最有可能遇到的基于机器学习的工具是某种形式的异常检测，如UEBA工具或NDR。虽然这些工具是有效的，它们产生的警报往往是有用的（就像常规的基于规则的警报）。然而，我非常清楚，今天的SoC中还没有 “cyber AI “的魔力。

Q：你对威胁狩猎人员的技能要求是什么？

这个问题很难回答，我在做分析师的时候也曾试图回答这个问题。鉴于伟大的狩猎最终是一门艺术，但上述艺术家也需要成为顶级的技术专家，因此想要定义这个技能组合是非常困难的。不过可以肯定的是，威胁知识、深厚的IT技术知识和创造性思维都必不可少。

Q：一个小公司/创业公司如何权衡人才与工具和成本？

这是我在做分析师的时候处理的另一问题。众所周知，小公司将使用更多的第三方服务，即外包服务。有些企业根本就没有SoC，而是靠MSSP或MDR供应商。也有一些用的是混合模式。
当然，这既有好处也有隐患。一个关键的隐患就是：不能认为你给别人钱，他们就能把你的安全做好。

Q：SoC即服务和内部SoC的情况如何？您的建议是否适用于这两种情况？

如果你所说的SoC即服务是指利用MSSP或MDR供应商，那么网络研讨会上的一些建议是适用的。MSSP供应商可能遵循更传统的SoC方法，也可能使用这里讨论的现代SoC要素。不过，我遇到的许多MDR提供商都采用现代SoC方法。

👮‍♀️网络安全👮‍♀️

Medium（Anton·Chuvakin）