0x00 前言 云转型使企业能够将新功能推向市场，更快地进入新市场，更轻松地进行创新，更高效地扩展。虽然引入这种新技术范式可能会降低整体技术风险，但企业对技术的日益依赖使更多的知识产权受到威胁。此外，大规模访问基础设施使开发人员能够创造新的体验来丰富我们的生活，而我们所以来的这些生活方式现在来看实际上比以往任何时候都更关注技术。为了在数字原生世界中保护我们的企业和人员，安全运营团队需要适应新的运营模式，以便在快速发展的以技术为中心的星球上充分预防、检测和应对对手。

我们对安全运营中心 (SOC) 进行现代化和改造以在不断发展的技术环境中保持速度的方法在很大程度上取决于人类创造性地解决大规模安全挑战的能力。这种以工程为中心的观点使我们能够专注于开发安全问题的解决方案，而不是通过威胁管理的日常操作来维持现状。

在本白皮书中，我们将讨论：

为什么 SOC 需要转型？ 什么是自动化安全运营？ 如何实现自动化安全运营？ 当您踏上转型之旅时，请记住，我们正在挑战一个存在数十年的问题。 与云转型类似——SOC 转型需要大量的思维文化、领导层的投资以及高度授权的员工队伍来克服这些障碍并共同开创威胁管理。

0x01 SOC 的使命 安全运营中心 (SOC) 的概念诞生于 1990 年代的大型全球企业。最初的 SOC 的 “DNA” 可能来自网络运营中心 (NOC)。

第一个安全运营中心的创建是为了集中专注于检测和响应的经验。随着时间的推移，他们的角色已经扩展到合规监控和一系列其他目标，有时非常广泛。

今天，SOC 主要是一个团队，然后是一组实践，最后是一组主要关注威胁检测和响应的工具。根据这个定义，我们可以暗示 SOC 可能会在 10 年甚至更长时间内存在。

在过去的四分之一个世纪中，SOC 的角色发生了变化。一些目标变得非常不同，一些更难，一些更容易，还有一些保持不变。当今 SOC 的核心功能包括检测威胁、促进对威胁的响应、提供上游反馈以防止未来威胁，以及其他因公司和行业而异的辅助功能。每个公司如何做到这一点各不相同，因为 SOC 使用的人员、流程和底层技术可能因组织而异。

无论如何，SOC 的使命是通过以减轻最大危害的最有效方式快速检测和响应攻击者来保护组织免受安全威胁。 SOC 的使命绝不是要确保组织永远不会被黑客入侵——这也许是不可能的。

最初的 SOC 涉及一大屋子的人观看显示屏，精心挑选的啤酒在显示屏上闪烁。今天，尤其是由于我们的数字原生和分布式劳动力的性质，有更多的虚拟和联合 SOC。

为什么要创建您的 SOC？您今天应该从您的 SOC 中获得什么价值？由于合规要求和其他原因（例如行业要求），肯定有组织创建了他们的第一个 SOC。如果您的 SOC 是为了满足审核员的要求而创建的，那么它可能会也可能不会实现上述 SOC 的更高使命。今天，如果您正在管理 SOC，无论您是完全在内部进行、涉及 MSSP 和合作伙伴，还是在混合模型中运营，您都应该期望看到明显的检测和响应价值。

此外，虽然对自动化的需求不断增加，但在可预见的未来，SOC 对人类的需求将持续存在。随着必要的自动化实施，攻击者将继续变得更加复杂，这将始终需要创造性的人为因素来防御。有鉴于此，我们相信未来 10 年 SOC 的变革将发生重大变化，但使命始终不变。 SOC 使命在我们的数字原生世界中变得更加重要。

0x02 为什么 SOC 需要转型？ (1) 业务转型 尽管 SOC 的核心任务基本保持不变——检测并响应威胁以保护您的组织——但它们的角色在范围和复杂性方面呈指数级增长。

撇开技术架构不谈，由于构建恶意软件和渗透组织并不是最容易接近的任务，因此对手过去较少且介于两者之间。如今，在 Google 上快速搜索 “如何构建恶意软件”，您可能会发现自己正在深入研究可以轻松构建无法检测到的恶意软件的多种方法。

此外，自 2000 年代初云计算概念兴起以来，全球互联网用户数量几乎翻了两番，从 12 亿活跃用户增加到超过 46 亿活跃用户。简而言之，当今世界上活跃的对手要多得多。与他们之前的任何一代人相比，他们更小、更快，并且可以在更有条理的互联网上获得更多洞察力。

现在，我们甚至还没有了解现代计算架构的范围、规模和复杂性。随着云计算的出现，现代计算架构变得更加复杂。通过规模经济，云提供商推动企业进行数字化转型的成本高于前云时代。

随着几乎所有企业都经历了将其产品、服务和运营转变为数字原生的旅程，利用组织呈现给对手的对手团结比以往更加引人注目。大规模破坏、财务收益、黑客行动主义、竞争情报和知识产权或地缘政治动机是在数字原生时代已经并将继续更加普遍的众多意图之一。

这也在经历云迁移的传统企业业务与快速启动的云原生组织之间形成了巨大的鸿沟。云迁移是改变企业工作方式的一种对立统一，但也让组织有机会重新想象他们如何保护他们的业务和保护他们的最终用户。

通过这种转变，如果组织没有为安全计划提供足够的资金并没有通过云呈现给他们的所有变化来培训他们的员工，那么安全方面可能会出现很大的差距。您如何跨云和非云基础架构设计、运营和管理安全性需要大量投资来重新培训您的团队以适应新的运营模式。

许多云转型的一个不确定的共同主题是，当组织有紧迫的时间和预算来推动他们的团队迁移到云时，SOC 要求就会被取消优先级。原因是，大多数 SOC 团队都忙于解决资源问题，没有空闲周期来专注于使他们的用例适应云工作负载和现代化他们自己的基础设施。缺少与业务现代化的这种对立统一只会使威胁管理问题变得更糟，因为感知价值的级联效应导致在大量其他问题中缺乏资金，从而最大限度地降低了 SOC 的效率。

许多业务领导者还认为云本质上是安全的，因为人们普遍误解了责任共担模型以及预防性安全与检测和响应威胁的区别。当然，他们是完全正确的——云基础设施比他们的数据中心更安全。然而，他们自己对云的使用却并非如此。分析师经常提醒我们，绝大多数的云安全问题和数据泄露都是由于云用户的过错而不是云服务提供商的过错而发生的。

(2) 越来越大的攻击面 COVID-19 导致的快速数字化迫使人们寻求技术来寻找在家工作和生活的新方式。每个人，包括他们的孩子，都需要一台笔记本电脑、网络摄像头和必要的办公设备来工作和上学。再加上医疗科技、电动汽车、金融科技和去中心化金融、智能家居和联网设备等大规模行业的转型——如今对技术的使用和依赖呈指数级增长。

在企业中，新的云运营模式提出了微服务和编码的不可变基础设施的概念，可以根据命令构建、销毁和重新部署。这些相同的微服务为现代电动汽车、健康技术、物联网设备以及全球所有快速转型的行业提供动力。这种微服务模型避开了我们构建组织技术栈的方式。过去，我们常常想到城堡和护城河的类比，以及以网络防御为中心的分层防御模型来保护组织。但是今天，我们正在考虑设计最少的不可变基础架构，该基础架构专为特定目的而构建，并植根于强大的访问控制模型。

威胁建模仍然存在——而且它现在比以往任何时候都更加重要。然而，它已经从不常见的威胁建模的旧单片时代演变而来。相反，它必须是超敏捷的，融入您的迭代开发生命周期，并了解云操作模型附带的所有新数据源、网络路径和访问模式的上下文。使用您的 DevOps 对手进行强大的威胁建模将有助于减轻您的 SOC 工作量。

最重要的是，虽然 DevOps 团队构建、部署和管理这个新的基础设施栈，但 SOC 通常不具备云技术栈如何工作的内在知识，大多数时候是因为他们已经一直忙于应对事件，而不是有时间在云中增加和建立深度。此外，云加速了技术发展，行业根据开发人员的需求从服务到服务的发展非常迅速。就在 10 年前，虚拟机仍然是开发人员工作负载的核心，然后是像 Google App Engine 这样的 PaaS 模型，现在风靡一时的是基于容器的架构和无服务器模型，它们可以最大限度地减少开发人员的操作时间。这些新的架构范式对努力跟上创新速度的安全运营团队提出了独特的挑战。

这种不断增长的技术栈、世界的快速数字化以及企业资产范围的扩大导致了更多的数据——更多的数据导致更多的未知威胁、更多的误报和更多的噪音。对于准备不足、无法进行现代化改造和适应的劳动力来说，这是个坏消息。

另一方面，好消息是云模型本质上比本地模型更安全。云的责任共担模型使组织可以专注于仅保护其权限范围内的必要组件。例如，在过去，必须监控所有网络流日志以查找诸如 DDoS 之类的威胁用例是很常见的，而如今，借助 Google Cloud 快速可扩展且完全拥有的端到端基础架构，DDoS 攻击对于大多数现代工作负载而言，这在很大程度上已成为过去的威胁。共享责任矩阵还有无数的用例，因此了解责任在共享责任矩阵中的位置非常重要，因为这使您有机会将您的劳动力重新用于需要完成的其他工作。此外，云服务提供商通常在入职和将业务团队转变为设计更安全的 DevOps 方法方面做得很好，在这种方法中，团队可以利用构建安全架构模式、配置和纠正工具来防止配置驱动。这种新模型在本质上比传统的本地环境中存在的模型更安全……Google Cloud 通过 Shared Fate 方法对其进行了进一步发展。尽管如此，现在的不同之处在于，今天的互联网用户数量增加了 4 倍，数据量呈指数级增长，数据的价值正在增加，对技术的依赖已嵌入我们日常生活的 DNA 中。

(3) 人才短缺 让我们直面不断增长的人才竞争。 虽然我们继续听到数以百万计的安全职位空缺，但为填补这一空白所做的所有工作并没有产生任何有意义的影响。 这一挑战不会仅仅通过雇佣更多的人来解决，因为事实证明这是非常具有挑战性的，而且需要更多的人来解决安全劳动力的有效性问题。 有很多问题导致了这个因素，我们也有很多方法可以解决这个问题，以改善招聘、人才的成长和他们的效率，我们将在本文后面进行描述。

网络安全可能是一个具有挑战性的行业，即使该领域的职业道路多种多样，包括运营、工程、营销、法律、用户体验、产品、销售等。 仅在安全运营团队中，就有从分析师到数据科学家、事件响应者、安全工程师的各种运营角色，并且随着 SOC 的转变以满足未来的需求，这种角色还在不断发展。 进入这些领域的旅程没有得到很好的定义，甚至没有被理解，而且安全纯粹主义者和他们必要的邻接之间经常存在很多摩擦。

安全团队是成本中心，而不是创收团队，因此增加员工人数始终是一场艰苦的战斗。 最重要的是，几乎不可能量化网络安全中的真实风险，因此，组织有时不会在发生重大违规行为之前投资其安全团队。

我们还需要解决招聘更多来自不同背景的候选人并为他们提供领导职位的需求。虽然安全行业在该领域边缘化背景的代表性略高，但在领导职位的代表性方面却有所下降。正如 ISC2 通过包容性创新报告中指出的那样，研究表明，尤其是麦肯锡公司的一项综合研究，拥有种族和民族多元化领导团队的组织既有利于公司文化，也有利于底线收入，同时也增加了组织的整体信心。安全态势。我们面临的问题需要独特和创造性的方法来解决问题。更多代表现实世界的团队将帮助我们解决我们在现实世界中面临的挑战，更多来自现实世界不同背景的领导者将有助于激励所有安全人员从独特的角度应对挑战.

让我们面对现实吧——该领域的教育计划往往达不到要求。技术从业者和学者之间的鸿沟很难弥合。这在 SOC 中最为明显，那里最有才华的从业者通常是热情的分析师，而不是受过教育的分析师。 SOC 需要了解支持其使命的相邻角色，同时还需要寻找培养和培养新人才的方法，并建立一个连接的教育层，以提高对该行业的认识。

这与快速发展的技术和对手的性质相得益彰，当 DevOps 团队在快节奏、快速迭代的环境中运行时，通常需要跟上很多变化，而安全运营团队正试图在没有基础的情况下对最新威胁做出反应了解工作中的系统。

顺便说一句，需要明确的是，DevOps、DevSecOps 和 SecOps 之间的任务非常不同。一个专注于安全地构建、部署和管理代码，另一个专注于检测和响应威胁。前者，通常在安全最佳实践之前作为多米诺骨牌效应，在后者的高压力环境中级联成更多的威胁管理工作。

SOC 所处的高压力环境抑制了增长。大多数 SOC 团队都被过度使用，而倦怠是这些团队的共同主题，无论是入门级还是高级。当生活质量受到影响时，工作质量也会受到影响，这就是为什么像谷歌这样的公司在其安全运营计划中采取严格的工作与生活平衡和心理健康方法，以确保他们能够快速响应并做出响应有效。

更复杂的是，与以创新和资助其安全计划而闻名的公司相比，普通组织影响顶级安全人才的可能性要小得多。想想像 Netflix、Facebook 和 Snap 这样的组织，他们研究并发布了他们在行业中的工作。我们需要一种更好的方法来增强内部能力。

仅仅通过严格招聘更多人才来解决人才短缺是不够的，我们需要重新定位我们对安全劳动力的愿景，我们将在本文后面深入探讨如何实现这一目标。

(4) 为什么未来的 SOC 会有所不同？ 世界的自然进化只会继续推动我们人类对技术的依赖向上。想想所有正在进行数字化转型的行业——自动驾驶电动汽车、调节我们身体的互联医疗设备、埃隆·马斯克的 Neuralink 所描述的脑机接口、为我们提供日常必需品的公用事业提供商。所有这些行业都建立在数据之上。这些系统和这些数据的妥协不再是泄露社会安全号码和身份盗窃的问题。生活依赖于技术，网络安全将不可避免地开始被视为一项光荣的社会服务，因为网络安全人员的存在不仅仅是为了保护企业和知识产权，而是保护人们免受伤害。

与之相近的，随着所有这些新数据源的出现，不断发展的计算设施栈也随之而来，而随着新的计算设施栈的出现，攻击者可以利用新的模式和架构来实现他们的任务。随着数据数量的不断增加，预计到 2025 年，全球 50% 的数据（即 100 zettabytes）将存在于云中——我们当前的 SOC 模型无法主动检测和响应威胁很多数据，更不用说今天的数据了。

许多这些新的行业和技术栈都是在高度依赖第三方供应链的情况下构建的。由于创建微服务是为了分解单体应用程序中的功能，公司本身和开源项目的存在只是为了优先考虑对组织产生最大影响的最小服务的开发和创新。随着数据以光速在组织、环境、合作伙伴和人员之间移动，该供应链继续增长并变得更加复杂。这种复杂性为对手通过这些受信任的关系进入组织提供了许多机会，而 SOC 将需要能够保护他们的企业和消费者免受看似无法克服的问题的影响。

虽然使命保持不变，但 SOC 的未来与我们过去几十年的运营情况截然不同。如果我们想要领先于指数级的数据涌入、高度持续且不断增长的对手数量、永无止境的人才短缺以及网络攻击的严重性——我们需要一个新模型。我们需要一个模型，使 SOC 能够摆脱其僵化、集中的孤岛和 “运营中心”，并专注于结果。

让我们将 SOC 重新设想为卓越的安全运营中心，它的存在没有任何限制，而是通过以工程为中心的方法来解决安全挑战，以开发可扩展和可证明的结果——与 DevOps 同行类似。不再招聘地域人才，而是为企业面临挑战的安全用例创造性地解决问题，无论人才在哪里。现代威胁的管理需要成为组织的自动化功能，其中安全运营活动随着人员、流程和技术的快速增长和演变而自然流动。我们相信，实现自动化安全运营状态是未来 SOC 的答案。

0x03 什么是自动化安全运营？ 自动化安全运营是理念、实践和工具的组合，可通过适应性、敏捷和高度自动化的威胁管理方法提高组织抵御安全挑战的能力。 它建立在指数改进的四个支柱之上：

10X People（10 倍的人效）10X Technology（10 倍的技术先进程度）10X Processes（10 倍的流程效率）10X Influence（10 倍的影响力建设）您需要成倍地提高员工的能力和效率。 分发和自动化您的安全流程和工作流程。 利用可以在全球范围内以最小的运营开销运行的云原生技术，专注于解决安全挑战。 最后，在整个组织中进行深度整合和显着影响，以提高预防性防御的效力，从而最大限度地减少团队必须检测和响应的威胁数量。

实现安全运营的自动化状态并不能通过一个支柱的成功来衡量，相反，您在所有四个支柱上所做的改进将协同作用，以指数方式提高您大规模管理现代威胁的能力。

摆脱那种认为 SOC 是一个满屋子的人看着带有精美仪表板的屏幕的想法。 无论您将您的团队称为检测与响应团队、安全运营团队，还是 SOC，我们相信安全运营的未来要求我们与分散的员工一起解决挑战，他们与跨组织风险的跨职能团队整合，以实现自动化和操作融合的状态。 专注于创造性地开发和设计针对现代威胁的可扩展解决方案所需的技能对于保护组织免受当今及以后的风险类别至关重要。

（1）10X People 要使人员工作的效率提高 10 倍，您的 SOC 无法通过将人员增加 10 倍来实现这一目标。

截至今天，需要有效安全的威胁和技术资源的增长速度远远快于进入劳动力市场的人。 SOC 人员短缺通常不是因为缺乏人员，而是因为有正确的方法和合适的人才来创造性地解决组织可能面临的安全用例问题。 对于大多数组织来说，将 SOC 中的员工人数增加 10 倍是绝对不可能的。 即使公司发生重大违规行为，SOC 通常也会在业务恢复后淡出后台，新注资通常用于全面招聘安全人员。 因此，SOC 的 “倦怠” 是一个真正的问题。

这种人才短缺挑战与在 NOC 中运营的传统 IT 运营团队所面临的挑战并无不​​同。在 DevOps 之前，有一个由开发人员、QA 和 IT 运营团队组成的世界。 IT 运营部门在 NOC 中对可用性事件做出响应，而 SOC 今天面临的同样挑战也存在于这些团队中。当 DevOps 出现时，其理念旨在消除孤岛，倡导以自动化为中心的方法，并强调透明度、协作、持续改进和部署。通过这种方式，他们能够提高技能，同时利用技术来分配工作并降低利用率，以解决类似的倦怠挑战。

对于一个更加专业化的运营团队来说，站点可靠性工程 (SRE) 的想法是由 Google 的 Ben Treynor Sloss 提出的。该团队的核心重点是将 50% 的时间花在运营上，将 50% 的时间花在自动化上，充当力量倍增器并为根深蒂固的运营问题设计可扩展的成果。或许，是时候将我们在安全运营方面的思维转变为更像站点可靠性工程 (SRE) 的时候了。不要感到惊讶，这实际上就是 Google 和当今世界变革性安全运营团队的运作方式。检测工程师开发解决方案来大规模解决检测挑战，而不是打乱传统的分析师工作流程。他们还管理他们的解决方案创建的警报，并使用这些数据来进一步完善他们的检测逻辑。

鉴于此，我们认为 10x People 改进如下：

a. 10 倍的分析师生产力和效率

分析师生产力和效率的指数级提高将集中在人员的转变上，人们将被授权自动化，提高技能以解决高阶挑战，并通过可以提高他们的能力和吞吐量的技术来增强。

在 Google 和其他行业领先的安全运营团队中，分析师的角色不仅仅是管理案例和执行 1 级工作。 分析师是工程师、建筑师、项目经理，并有权成为其主题重点的领导者。 在这样的 SOC 中，1 级到 3 级分析师的概念已成为过去，相反，您应该根据技能与他们权限范围内的用例保持一致来组织团队。

让您的分析师承担更大的工作范围将需要您的 SOC 进行重大的文化转变，因此您激发和授权团队以不同方式思考的能力是这种转变的关键要素。强化学习、扩展机会、问题所有权和职业调整可以帮助您建立一支更有才华和目标导向的员工队伍。此外，人才可以而且应该来自于您在 SOC 内雇用的员工之外。在您的管道中招聘、增加和培养人才需要花费大量时间。合作伙伴、承包商和服务提供商可以提供咨询、咨询、工程和运营能力等关键功能，以帮助填补您目前可能没有能力的空白。你没有理由不利用所有你可以支配的人来完成你的使命。

这还需要与有意识的工作与生活平衡、轮换和满足团队需求的方法相结合，因为如果您的团队遭受倦怠和士气低落，就没有 10 倍的生产力。当人类没有遭受决策疲劳并在焦虑状态下工作时，他们会以最高的生产力工作。这听起来不像软件开发的演变吗？我们继续寻找方法来抽象出不必要的事情，例如构建和管理服务器，以便工程师可以简单地专注于代码并做他们被雇用做的事情。

如果不高度重视自动化，我们就无法实现生产力和效率的指数级提高。自动化以多种形式出现，作为简化日志摄取和管理过程的一种手段，能够在全球范围内管理检测或特定工作流。自动化增强了人类在 SOC 中的能力，人类可以实现他们独自无法实现的结果，从而提高生产力和效率。在不久的将来不会有机器人取代 SOC，这仅仅是因为随着防御变得更聪明，对手也变得更聪明。您将需要以自动化优先的心态解决所有问题，以便您可以最大限度地减少团队的操作时间，并让他们专注于更高阶的任务。毕竟，警报疲劳问题只会随着数据的增长而增长。

b. 10 倍的威胁和资产覆盖率

随着攻击面的增加，覆盖更多资产（从大型机到云的新旧资产）的需求要求 SOC 不仅要增加其资产覆盖范围，还要领先于不断发展的数据源，以免它们成为障碍到技术的快速增长。

使用自动化来实现（或至少接近）监控资产的完全覆盖就是一个例子。毕竟，云中没有 “流氓服务器”，每个资产都可以通过 API 找到。

随着 SOC 周围的 IT 采用 DevOps 和其他相关方法，SOC 需要插入新的记录系统、新的变更管理和其他现代基础设施元素。

最后，随着应用程序在默认情况下变得更加安全，SOC 将更有可能专注于真正需要人工参与的威胁和挑战。

c. 10 倍的资源共享能力

多年来，业内许多人都在感叹攻击者比防御者更有效地共享信息。无论是应用于情报共享还是共享工具，防御者在很多情况下都落后了。

实现 10 倍的改进需要大幅增加防守方共享。云提供商的目标是在威胁和保障共享方面发挥关键作用。随着 Sigma 和 YARA-L 等检测内容格式变得更加突出，开源和社区检测将增长，从而促进 SOC 数据共享并最终提高生产力。

检测逻辑的社区存储库（如 SOC Prime 和各种检测代码的 GitHub 存储库）也促进了行业和跨公司的共享，从而提高了对网络攻击者的整体抵御能力。

（2）10X Process 让陈旧的安全流程以 10 倍的速度运行似乎是一项难以置信的努力。然而，鉴于威胁形势、不断演变（和增长）的攻击面以及来自各种安全工具的更多警报，我们需要开发一种自适应方法来优化新的和现有的流程。

自动化发挥着重要作用，例如对于许多常规 SOC 任务（如浓缩），将几分钟甚至几小时的人工时间转化为几秒钟的机器时间。

SOC 流程自动化，例如通过安全编排自动化和响应 (SOAR) 工具，提供 10 倍的速度、10 倍的一致性和 10 倍的可追溯性和可审计性。这意味着安全操作流程不仅运行速度更快，而且错误更少，实现相同结果的一致性更高，可审计性更高。可审计性可用于多种用途，而不仅仅是用于审计和合规性。例如，在事件发生后执行无可指责的事后分析并执行持续改进活动会容易得多。它还将简化交付给高级管理层的安全运营活动的报告和衡量标准。可审计性还可以作为自动化的制衡系统。大多数安全团队不信任自动化，因为许多问题并不是一刀切的方法，因此我们自然需要审查我们的机器执行的工作，以确保它们达到预期的结果。

这可能会使 SOC 显着降低 MTTD 和 MTTR 指标——检测时间和响应时间。请注意，恢复时间更难减少，但随着云计算增加自动化能力，包括修复活动，恢复时间自然会随之而来。将检测和分类自动化与定义明确的补救行动手册相结合，也可以加快您的 MTTR。未来的人工智能将学习人类活动，然后自动创建推荐的剧本。

当检测工具快速响应查询时（如 Chronicle 所做的那样），所有检测都转换为检测代码，实现自动化，并且更少的 “人工速度” 流程到位，非常清楚 MTTD 如何提高 10 倍. 因此，您的 SOC 涉及自动化安全操作。

显着加快响应时间 (MTTR) 的起源是相似的：自动化、以机器速度运行的一致且可预测的流程，以及用于识别事件优先级的有效知识共享，并由强大的威胁情报提供支持。

这并不意味着先进民族国家的入侵可以在几分钟内解决。顶级威胁参与者及其引发的事件可能仍需要人类专家以人类速度运行，花时间弄清楚到底发生了什么。也就是说，自动化确实为人类腾出时间，将精力集中在更老练的攻击者身上，而不是处理可能不太可能影响业务的大量警报。

现在，如何才能大幅加快规则和模型等检测内容的开发速度？自然地，这个过程需要有效的威胁情报收集实践以及将情报转化为检测的强大过程。

最后，10 倍的改进还需要在 SOC 内部以及 SOC 与组织的其他部分之间减少工作量并显着减少流程摩擦。

（3）10X Technology 许多 SOC 在其内部和附近的安全产品中都遇到了困难。由于 SOC 的工具箱中平均携带着数十种工具，因此工具蔓延是一个真正的挑战。再加上产品、供应商和用例之间缺乏深度互操作性，您在 SOC 中就会有一个非常有趣的杂耍行为。

即使具有高度差异化的能力和非常不同的意图，技术也需要推动更统一的方法。这意味着技术将需要开始对其邻接和集成有更多的语义意识，这样 SOC 中的工作流程才能真正得到优化，我们不会花太多时间重新训练我们的工具来思考它们应该的方式操作。过去是关于单一思维的，我们如何将每个特性和功能组合到一个产品中并尝试解决威胁。当世界从他们的技术栈中消除单体应用并迁移到专门构建的微服务栈以解决业务需求时，这显然无法扩展。

在 SOC 中，我们需要开始以类似微服务的方式考虑我们的工具，在这种方式中，我们使用一系列可定位以实现预期结果的技术来设计我们的用例，同时确保我们的技术栈具有对其邻接的深层语义意识。因此，鉴于此，当您的技术堆实现 10 倍改进时，需要考虑几个关键优先事项。

a. 10 倍可感知能力

许多组织意识到，他们的 SOC 必须对所有安全活动及其所有资产拥有完整、全面的可见性，无论是在本地还是跨云。毕竟，您需要一个威胁参与者来利用针对资产的漏洞才能存在风险。

这说起来容易做起来难，尤其是在组织 IT 层层增长的情况下，从大型机到虚拟机再到容器，再到现在的无服务器栈在几十年的过程中。但是，现代 SOC 必须能够提供完整的可见性，这意味着您不仅依赖于日志，还依赖于端点、网络、物联网、云遥测源、信号以及接下来发生的任何事情。

当数据富含深层元数据时，数据的可见性也会变得越来越有用，因为这为 SOC 提供了评估可达性、识别横向移动机会、评估爆炸半径并通过减少具有丰富上下文的调查时间来进一步降低 MTTR 的能力。调查人员处置。利用 Looker 等强大的可视化技术可以提高您的 SOC 将故事拼接在一起的能力，并对整个环境中发生的交互具有重要的洞察力。

这些要求不仅表明了收集、规范化和丰富收集到的数据的能力，还表明了随着可见性需求的增加而扩展的能力。从本质上讲，这种全面性不应该有代价，也不应该有速度障碍。

b. 10 倍的响应速度

许多在 1990 年代开始使用传统安全信息和事件管理 (SIEM) 产品的安全运营中心已经习惯了非常缓慢的查询速度。数据搜索和报告需要用户休息一下，在最坏的情况下，需要休假的情况并不少见。当今数字业务的发展速度使其成为不可行的安全时间表。

虽然现代 SIEM 产品通常会在几分钟内产生结果，但这对于 10X SOC 来说太慢了。有鉴于此，提供 10 倍技术栈能力的一个明显方法是将数据检索、搜索、报告器和仪表板的速度提高 10 倍。幸运的是，对于 Chronicle 等产品，这很容易实现，因为它建立在 Google 的骨干和高性能的技术基础设施。在 Chronicle 中，任何时间范围内的标准化数据搜索都会在四分之一秒内定期运行，并且它以 PB 级和多年的数据运行。

许多收集遥测数据的组织仍然在数据收集方面遇到困难，特别是在数据源载入方面。例如，虽然将某些受支持的数据源连接到 SIEM 在技术上很简单，但可能需要安全团队跨越组织边界并面临摩擦。此外，数据源最终可能会集成到安全工具中，但在技术栈中的任何其他工具中都缺乏语义意识。

鉴于此，10 倍的改进需要显着提高数据源载入速度，并且需要对其底层数据模型采用标准化方法，该方法可通过其集成使用，而无需重新设计上下文。幸运的是，对于现代云数据源（例如 GCP 上的云数据源）而言，使用统一数据模型的即时启用在很大程度上已成为现实。

c. 10 倍的信号情报量

许多安全供应商承诺非常清晰的信号情报和改进的检测质量。 但是，对于在真实环境中起作用的真实威胁，这很难实现。 例如，如果没有安全团队的大量工作，任何依赖搜索原始日志数据的产品都无法预测地提供良好的检测信号。

这意味着高质量的检测和调查信号情报要求产品在收集时处理数据，将数据融合到连贯的时间线和故事中，并为使用信号情报的最终用户提供清晰的路径，以获得可操作的见解。

这也将确保信号在本质上更干净，并且我们可以减少由于信号情报仅建立在静态环境和缺乏上下文意识而导致的警报疲劳问题。 如果我们想应对警报疲劳挑战，检测信号情报的质量肯定会在推动这一挑战方面发挥重要作用。

d. TCO 降低 10 倍

每个 CxO 都需要确保他们投资的工具与他们期望的投资结果保持一致。在安全方面，量化风险管理几乎是不可能的，因此优化成本始终是每个 CxO 的首要考虑因素。第一个担忧是，“我们将所有这些钱都花在了这些产品上，但是，我们仍然不确定我们是否安全”。所以虽然这篇论文

不专注于对量化风险管理的可能性进行哲学思考，以便您可以为董事会提供明确数量的收入损失，您可以通过安全工具减轻这些损失，我们需要指出，现代化的 SOC 在优化方面做得更好整个安全技术栈的 TCO。

随着云的出现，组织可以通过从传统的资本支出转移到运营支出来成倍增加其技术栈提供的价值，从而提供将管理责任转移给供应商或 CSP 的额外好处。毫无疑问，转向运营支出是所有行业的方向。安全人员应该专注于安全，而不是基础设施管理。是的，当您不拥有整个基础架构时，灵活性肯定会降低，但是如果您专注于您试图通过用例实现的结果，您可以利用额外的工时和人员来专注于更高阶的挑战。这种运营开销的减少并不是消除员工人数，而是重新确定您的人员的优先级，以专注于创造性地设计更好的结果，更多地关注安全性，而您的云服务提供商可以处理可扩展性和其他责任。

安全操作也是一项非常昂贵的维护能力。它的核心是一个巨大的数据湖，数据呈指数级增长，数据的操作和操作也呈指数级增长。随着越来越多的企业迁移到云端，随着越来越多的行业通过技术进行转型，这个庞大的数据湖将继续以难以想象的速度增长。不幸的是，安全运营也受到预算的限制并且没有无限的资金池，因此组织需要非常小心，不要为了控制而牺牲安全性。相反，通过迁移到提供更好定价经济性的云原生工具和托管服务来牺牲控制需求，从而优化您的预算。这样，您就可以将额外的资金用于增强覆盖范围、人才和其他用例。

(4) 10X Influence 如果 SOC 对安全生命周期的上游元素也有强大的影响力，它才能真正实现 10 倍的变革和变革。如果您的团队与您的 DevOps 实践紧密集成，您可以对进入 SOC 的警报数量产生重大影响。深入了解如何在整个组织中安全地构建、部署和管理基础设施和应用程序，再加上您影响此设计的能力，只会提高您在攻击者最早出现时捕获攻击者的能力，甚至更好地阻止他们完全进入.

像零信任这样的方法，如果实施得当，确实可以减少 SOC 分析师和工程师必须处理的噪音。尤其是现代计算技术栈以访问模型为中心，再加上全球和远程劳动力，现在比以往任何时候都更需要转向零信任访问模型。

您的漏洞管理计划是实现组织强大防御状态的最重要元素之一。漏洞需要被捕获，优先考虑严重性，并即时修补。迈向自动化补丁管理状态对于建立强大的安全态势至关重要，同时还可以捕获由错误（即错误配置）引起的漏洞并自动纠正它们。毕竟，错误配置是导致数据泄露的最大原因。当开发人员拥有特权访问权限并向全世界开放您的防火墙时，您的 SOC 如何真正保护您的组织？以指数方式提高效率的 SOC 对漏洞管理流程及其如何集成到开发生命周期以及为防止开发人员错误而实施的控制有深入的了解。

开发人员错误会发生并将继续发生，即使工具会自动捕获并纠正配置偏差。有时配置可能从一开始就没有很好地定义，因此针对较差的基线进行监控可能没有多大价值。在一个责备没有得到任何结果的世界里，在邻接之间推动影响力所需的一项关键技能是开发人员的同理心。遵循基于同理心的方法将帮助您了解根深蒂固的安全问题以及如何定制解决方案以大规模适应开发人员的需求。

现代 SOC 绝对必须对它们的邻接产生影响，以改善防御，最大限度地减少 SOC 需要采取行动的警报数量，并推动更好和持续的反馈循环以对 SOC 中已识别的威胁向量采取行动。

0x04 如何实现自动化安全运营 将您的 SOC 从纯人工运营转变为自动化安全运营并非易事。与云转型类似，这种规模的计划是一个多年的旅程，需要您的领导层、组织范围内的宣传以及可以支持您完成这一旅程的合作伙伴的大力投资。

不要忘记，实现自动化安全运营状态是理念、实践和工具的结合，它们将提高您的组织抵御安全攻击的能力。没有单一的指标可以描述您何时处于这种存在状态，相反，当您能够在人员、流程、技术和影响力这四个支柱上实现指数级改进时，您的关键安全运营指标将随之而来。

无论您是需要利用 MSSP 产品的以 DevOps 为中心的小型组织，还是想要 DIY 的大型企业，我们都将讨论几个主题来帮助您转变 SOC，围绕四大支柱。

（1）人员转型

高级安全检测和响应团队（例如 Google 的团队）的基本原则之一是，研究威胁、开发检测逻辑和响应警报和其他信号的人是同一个人。

从哲学上讲，您可以将其视为一种用于安全操作的 DevOps，其中开发代码的人（在本例中为检测逻辑）与操作代码的人相同（在本例中为响应信号和警报）。检测工程师的工程特性不一定是软件工程师的技能，而是需要编写查询、规则、自动化脚本、构建剧本、操作数据源等。这些技能可以通过聘请安全工程经理来大规模开发他们也是鼓舞人心的领导者，可以采取实际行动来提升整个团队的技能。

当你开始投资你的团队时，想想我们之前讨论过的所有关于内在人类动机、目标设定、人才获取和在你的团队中播种成长的概念。 DevOps 哲学不仅仅是一种建议声明，它成为拥护这一信念体系的工程师的一种生活方式。

你也应该绝对利用行业认证。 从业者会提出反对认证的担忧，但现实情况是，认证提供了很多好处，而且没有任何缺点。

认证提供了理论知识，以低成本提升您的劳动力技能。 认证为多元化和代表性不足的群体提供了进入该领域的机会，这是在与日益增长的对手的战斗中至关重要且很大程度上尚未开发的劳动力。 认证可帮助安全专业人员成为更有效的沟通者，并通过建立超出其核心专业知识主题的基础知识，在他们的邻接之间建立影响力。 认证可帮助招聘人员通过寻找技能与 SOC 角色更接近的人才来筛选首选候选人。 SANS Institute 提供了许多专门针对安全运营专业人员的实践技术培训计划和认证。 ISC2 和 ISACA 提供与技术无关的认证，帮助您的安全运营人员了解攻击的全局和生命周期，超出 SOC 中发生的情况。云认证让您的 SOC 团队能够在他们运营的云中获得深度和主题专业知识。Google Cloud Professional Cloud Architect 认证是世界上薪酬最高的认证是有原因的。这些云认证非常全面，出于上述原因，您应该激励您的员工寻求扩展学习机会，同时培养他们的动手技术技能并同时投资于他们的职业发展。一个好的经验法则是考虑将团队 20% 的时间用于知识共享和学习。

除了认证之外，像 SANS 研究所这样的组织还提供多种有偿和无偿学习机会，并且有许多区域信息共享和分析中心 (ISAC)，允许从业者共享知识并相互学习。这些也为您的员工提供了成为思想领袖并参与相关活动以提高技能和提升他们能力的机会。通常，在组织之外拥有同行和导师可以为解决问题提供新的见解。

思考如何与您的组织领导（包括人才管理和人力资本团队）合作，为与对手的战斗带来令人兴奋的新亮点。

可以通过以下的几个方法来进行操作：

拆除 SOC 中将分析师和工程师隔开的墙 确定您的 SOC 所需的技能，开始雇用技能，而不是等级 通过自动化日常任务提高生产力（通过 SOAR 和托管服务）利用合作伙伴和第三方 创造一种延伸学习、赋权和创新的文化（2）流程转型

改进安全运营流程听起来像是一项无聊的任务，但卓越的流程确实将 10X SOC 与可能无法管理组织遇到的威胁的最低性能 SOC 区分开来。在 SOC 中有几个方面可以改进它。

但是，要牢记的关键原则之一是，优秀的安全运营团队既要有一致且可预测的流程集，还要利用人类创造力来对抗顶级攻击者。对抗自动攻击通常更容易防御，因为签名和模式已被识别，并且云的规模可以处理分布式攻击等事情。与高度顽固的对手作战，他们在您的环境中度过他们的甜蜜时光，甚至数周甚至数月，是一项需要人类思想家来解决的挑战。

因此，对流程的改进需要提高一致性，同时又不会破坏和破坏人类分析师的创造力。平衡这一点很困难，有些流程肯定会关注一致性，例如一致的警报分类。另一方面，一些流程，例如威胁追踪和红队（与 SOC 相邻的流程），肯定会严重倾向于更多的创造力。

改进的关键过程之一当然是检测工程过程。为了应对您的组织面临的威胁，您的 SOC 将需要创建检测逻辑，无论是以规则还是算法和机器学习模型的形式。

另请注意，对于某些组织而言，流程改进要等到转型阶段才会进行。 例如，不进行任何威胁搜寻或情报创建实践的组织将需要从头开始创建这些流程，然后对其进行改进。

一些开始 SOC 之旅的组织从供应商提供的检测逻辑开始，然后发展到调整和完善，然后发展到自己的检测逻辑。 在转型阶段，您自己的威胁研究和自定义威胁情报以及狩猎操作和事件响应将创建和完善您的检测内容。

可以采取以下几个方法：

巩固基础，在你能很好地探测到之前不要做狩猎 专注于威胁情报以推动其他 SOC 工作 推动 “SRE” 方法 - 将 50% 的时间发展为自动化工作 之后添加狩猎、测试和分析 更高的透明度将允许更多创造性的问题解决（3）技术转型

对于许多组织而言，转换安全技术是困难的。这可能是由于根深蒂固的利益、昂贵的产品和冗长的支持合同。当前使用的许多技术（例如 SIEM）实际上在转换后的 SOC 中有用。这些技术有效性的许多改进都是关于利用您的优秀团队来改进技术的使用方式并优化他们与之交互的流程。它们并不是真正要批量替换技术。

但是，随着组织的发展和迁移到云，需要新的可见性区域。例如，对于许多组织而言，当它们从 SIEM 中的简单日志分析发展到更自动化的工具（如端点检测和响应 (EDR) 等）时，就会发生战略改进。覆盖本地和云环境的许多传感器的高度自动化融合，转向将一些责任抽象给您的服务提供商的托管服务，以及通过 SOAR 和产品差异化实现的自动化将使您的安全运营技术栈更上一层楼。

好的 SOC 在数据收集中利用自动化来最大限度地减少摄取错误和规范化问题。他们还通过机器学习 (ML)、EDR 和其他技术使用自动化来改进检测。他们自动进行分类以消除误报和欺骗，更准确地对警报进行分类，对警报队列进行优先级排序等等。他们使用自动化和脚本来自动化数据的丰富过程，然后在警报可以自动关闭或使用新上下文重新确定优先级的情况下，将内容重新泵入带有附加上下文的分类队列。他们还可以推动补救行动。

对于许多组织而言，自动化能力的建设尤其具有挑战性。大多数 SOC 构建的自动化通常以部署、实施和利用 SOAR 工具为中心。但现实情况是，您可以通过使用具有差异化功能的技术以及接收技术的方式（即通过托管服务模型）来提高自动化程度。您所有自动化工作的总和可以

加起来解决了很多盲点，这样您就可以优化您的操作时间来专注于更高阶的安全挑战。在后期阶段，使用机器学习和其他系统不仅有助于自动化 SOC 中的日常任务，还有助于实现认知任务。

到今天为止，不要以为机器学习会带来神奇的效果。对于拥有 ML 团队的高素质组织，需要对用例和数据集进行深入界定，以确定利用 ML 大规模解决特定挑战的机会。由于经济成本高昂且此处的 ML 用例缺乏成熟度，因此 ML 需要一些时间才能实现它承诺提供的有效性。正如行业观察家所指出的，在不久的将来，机器学习和类似技术可能会带来其他渐进式改进，而不是改变游戏规则。

可以采取一下的方法：

不要放弃 SIEM，除非你已经为他们的用例设计了解决方案 扩大可见性：NDR、EDR / XDR、云等 请注意，云原生安全工具最终会胜出 使用 SOAR 来自动化日常任务 使用 ML，但不要指望它有魔法……（4）影响力转型

建立一个极具影响力的安全运营专家团队将成为变革性 SOC 中最有价值的元素之一。 SOC 是离攻击者最近的团队，因此自然而然，如果他们能够影响上游和下游，他们可能对解决整个组织的安全挑战产生最大的影响。

最好的 SOC 团队对世界构建方面的工作方式有很多上下文理解。没有这种理解，SOC 团队真的很难有很大的影响力，而且往往会导致影子 IT。此外，如果您计划进行任何类型的响应自动化，如果您的自动化出错并导致生产环境瘫痪，您可能会造成很大的损失。与您的同行建立深厚的关系，建立强大的联锁机制，并教育您的 SOC 从一开始就了解威胁模型，这样您就可以真正设计出预期的结果。

请记住，您需要资产、要利用的漏洞以及要利用它的威胁才能被攻击。因此，虽然实践中的漏洞通常被称为代码漏洞，但现实情况是，“人工修复” 同样重要。因此，为了产生很大的影响，您不仅需要确保您的漏洞管理团队正在修补软件并可以访问您的威胁情报以捕获关键漏洞，而且您还需要确保您在整个开发过程中都有安全拥护者团队在其开发生命周期中捕获最终用户漏洞和正确的威胁模型。确保您的漏洞管理团队在您的组织内推动采取行动以降低新漏洞的创建速度也很重要。不要忘记，您还应该将漏洞管理工具中的数据与 SOC 中的威胁相关联，以丰富您的发现并获得更有效的结果。

您的 SOC 可能专注于检测和响应，但不要忘记它们可以为组织的其他成员提供的价值。他们对邻接的影响可以在他们在 SOC 内管理的项目中产生指数影响。此外，如果他们能够外包他们的知识并成为整个组织的思想领袖，那只会增加提供给您的 SOC 团队的预算及其感知价值。

可以采取以下几种方法：

对 SOC 进行有关变更的上游影响的教育 (DevOps) 不要错过与业务关系现代化的机会 与 SOC 邻接建立深厚的关系并定期联锁 为所有创建的检测记录攻击的生命周期 确保关键团队可以访问 SOC 上下文以修复正确的漏洞

0x05 总结 当您开始意识到您正在解决世界上更多独特的挑战并且更多人希望为您工作时，您提出的将您的 SOC 推向更好的存在状态的意图将在未来获得回报。这当然是一个多年的旅程，但本指南将为您提供一个心智模型，说明您应该如何思考推动组织变革。这当然不仅仅是你的 CISO 或 SOC 领导的工作——你应该利用这些知识并在你的团队中传播它。考虑组建一个 “TigerTeam”，专注于规划您的章程在未来 30 天、6 个月和几年内将如何发展。

在 Google Cloud，我们一直在努力构建解决方案，以便与大大小小的组织合作，共同实现自动化安全运营的转型努力。我们可以帮助您保护您的组织免受现代威胁，无论您的数字资产部署在我们的云、本地还是其他云中。

通过在实现自动化安全运营的道路上与我们合作，您将拥有一个触手可及的真正现代化之旅，这将改变您的组织检测和响应数字威胁的能力，以及共同开创威胁管理的机会。

无论您是独自踏上这一转型之旅，还是想与 Google 合作，我们都会在此过程中提供宝贵的见解和帮助。

原文：https://go.chronicle.security/autonomic-security-operations