打造安全平台工程团队

译自：Building A Security Platform Engineering Team^[1] 直译过来是打造安全平台工程团队。但是安全平台工程团队名字比较高大上，理解为企业安全开发团队也许更合适。文章阐述了作者的观点：企业什么时候需要安全开发团队，为什么需要安全开发，以及应该解决什么问题？文章中提及的安全铺好的路，在国内语境也可以理解为内生安全，安全免疫力。以下为文章内容：

我非常热衷于在现有流程中构建安全性，该术语由 Netflix 前 CISO Jason Chan 创造，称为“安全铺好的路”。这个理念认为，安全应该主要是隐形的。普通员工根本不必考虑后果严重的安全领域。他们将使用让他们的生活更轻松的工具，并且该工具默认内置安全性。是的，他们可以偏离那条已铺好的道路，但他们通常会有更糟糕的经历。这个想法是，95% 的人会坚持走已铺好的道路，而唯一偏离这条道路的人有特殊的理由这样做。

在过去五年左右的时间里，我们看到越来越多的安全工程师开发了这类工具，以及解决此问题的专门团队不断涌现。我在这篇博客中的目标是探索：

1. 什么是安全平台工程团队？
2. 他们做什么工作？
3. 怎么开发这个功能呢？
4. 你什么时候应该为团队配备人员？

为什么选择安全平台工程团队？

你的组织可能会面临两组安全问题。您的公司会遇到一些独特的问题，解决方案也会作为商品出售。

最好的例子是员工单点登录是有用的东西；但是很少有公司正在构建自己的SSO平台。为此，他们正在使用 Okta、Microsoft 和 Ping Identity 等供应商。对于每个人来说，重新造轮子并构建自己的 SSO 平台都是浪费资源，特别是对于对可用性和安全性都如此重要的东西。没有一家公司应该将资源投入到构建SSO平台上，而不是投入到创造收入的面向产品的功能上。要摆脱这种模式，需要一些非常独特的环境，我们将在下面详细讨论。

另一方面，您可能有一个自定义的内部问题，不能轻易使用商业产品。在许多软件公司中，一个很好的例子是帮助工程师与客户实例交互的客户支持工具。这些工具需要安全且可用，但这不是供应商可以轻松解决的问题，因为它确实是您的产品的独特之处。一般来说，你应该将精力集中在没有现成解决方案的问题上。当然，现在也有例外，例如：

• 可以比供应商提供的价格更便宜地构建它
• 当对供应商的安全状况有疑问并希望将其保留在内部时
• 该领域唯一的供应商是你不想花钱的竞争对手
• 避免供应商锁定，要么是因为你认为他们会提高价格，要么是他们不会构建你未来需要的功能
• 所提供的解决方案无法满足你的需求

他们解决什么问题？

安全平台工程团队专注于解决上述问题。他们的两项任务是：

• 开发新的工具和服务以提高安全性。
• 与其他工程团队协作，构建默认安全的系统。我领导了Shopify的其中一个平台工程团队，并与业内的一些其他团队进行了交流。我们发现各个行业和垂直领域都有一些共同的主题：
• 内部访问：IAM（身份和访问管理）、PAM（特权访问管理）、零信任以及内部访问等方面，供应商正在迅速改进。然而，在过去几年里，这些任务一直是这些团队所面临的共同挑战。
• 开发人员工具：确保开发人员能够构建安全的服务。这通常包括加密服务、密钥管理、身份验证、身份等各个方面。
• 客户支持：除了标准的helpdesk功能外，每个软件公司的客户支持工具都有其独特之处。考虑到客户支持每天都需要与未知的实体进行互动，因此这也是风险极高的领域之一。
• 扩展安全性：漏洞管理、安全审查、风险评估等。这个团队可以开发出能够帮助安全团队扩大规模，同时不需要增加人手的工具。

每个安全平台工程团队都应该意识到，有时候他们必须放弃自己的工作。我可以从我过去的一个经历来说明这一点。在Shopify，我们曾经开发了一个零信任解决方案，用于检查设备状态并阻止对应用程序的未授权访问，除非用户来自于一个经过安全加固且受管理的设备。这个方案在过去的几年里运行得很好，但是供应商们最终还是迎头赶上并超越了我们。事实上，我们只有少数几位工程师，而安全供应商则有数百名。因此，我们一直都知道，我们最终将不得不替换这个方案的某些部分。

安全平台工程团队背后的理念是解决独特的问题，但如果这些问题不再是独特的，那么就要毫不犹豫地切换到供应商。这不是浪费；在这段时间里，你保护了公司，现在你可以专注于新的和令人兴奋的事情。

这就是我喜欢这个领域的原因之一：你始终处于安全研究和开发的最前沿。

开发此功能

在评估安全开发功能时，你需要问自己两个问题：

1. 你的组织是否有独特的需求，无法通过现成的工具解决？
2. 你的团队是否足够大，可以投入大量时间进行不会立即产生价值的战略性投资？

如果两个答案都是肯定的，你可以直接申请人员编制，并从第一天开始尝试为这个功能配备人员，这正是Atlassian团队的做法。

假设第一个答案是肯定的，但第二个答案是否定的。在这种情况下，另一种选择是雇佣一名软件工程师，或者让安全工程师在这个领域作为他们职责的一部分。不过，从长远来看，我建议采用其他方法。这可能是一种很好的方式来观察这种方法是否适用于你的组织，但还有更有效的方法来运作。

如果你雇用安全工程师，你希望他们解决安全问题。你不希望他们在角色之间左右为难，既要成为一个优秀的开发者，又要成为一个优秀的安全工程师。这可能会在一段时间内奏效，但它会带来一些负面影响，包括：

• 工程师的倦怠。如果你是关键 Tier-0 服务的唯一负责人，祝你休假时候顺利。
• 由于没有人可以学习和交流思想，缺乏成长。
• 上下文切换导致这两个领域的进展缓慢。
• 如果那个人离开，就没有冗余，寻找另一个独角兽人才来填补空白也不是一个可扩展的方法。
• 移交给专门的工程团队可能很困难。工程团队通常不愿意接管由一个人创建的服务，在这些服务中，他们可能不得不偷工减料以使项目顺利完成。

由于资源有限，我过去曾经遇到过不得不使用这种模型的情况，我的经验是，它在出现问题之前运行良好。要小心处理大型的企业项目，因为工程师可能会累垮，离开，没有人愿意接手他们未完成的工作。由于这个原因，这些工作往往会被废弃，如果工程师处理的是具有更长寿命的项目，情况会更好。

组织还应该遵循公司的工程流程。安全工程师通常会知道Python或Go；如果你是一家基于Java或C#的公司，你应该希望安全平台工程团队使用相同的语言、框架和方法来构建软件。不要成为那个在Java公司用Rust构建一切的团队。

何时创建团队

大多数安全团队都很小，只有少数人，实际规模很大程度上取决于行业。与任何团队一样，在一些最大的公司中，安全人员可以是一个人，也可以是数千人。关于团队的组成，在你建立其他任何东西之前，你几乎可以肯定雇用应用安全、检测与响应、GRC 和 IT 安全功能。

那些规模超过这个范围的组织必须认真考虑如何扩大运营规模。安全团队的规模将继续扩大、一项一项手动处理任务，这样想是不可能的，也是不合理的。相反，我们需要某种方法来为大众建立安全保障。安全开发团队可以通过创建减少整个组织安全问题的平台来减轻安全团队的总体负担。这意味着，与其他安全团队不同，随着公司的发展，这个团队的投资回报率（ROI）也在增加。我的粗略指导是，如果你的安全团队接近 30 人，你有需要自定义代码来解决的独特问题，并且你至少有3个可用人员（一名工程经理，两名工程师），那么你应该考虑启动一个专门的团队。这将为你提供开始所需的最基本东西。

一个真正有效的安全开发职能部门包括一名工程经理、多名软件工程师（前端和后端），最好还包括产品经理。你可能还拥有专注于不同元素的专家（例如人工智能工程师）来解决整个技术栈中的人工智能问题。当然，这些专家也可以是专门的安全工程师，你会发现大多数这样的团队都有一些从安全工程师转型为建设者的人。这个团队应该能够运行Tier-0服务，具有随叫随到的能力，并且主要表现得像其他软件工程团队而不是安全团队。最重要的是，它应该把大部分时间花在建设上。这个团队的核心价值是专注，而不是在安全、开发和其他任务之间进行上下文切换。

总结

最近，我在 LinkedIn 上做了一个调查，结果并不让我感到惊讶。许多团队让他们的安全工程师也做解决这些问题的开发工作，有少数受访者有足够的资源来专门为这个目的组建整个团队，但他们选择不这样做。我鼓励安全工程师进行修补和建设，但我建议他们专注于成为非实践专家。他们可以构建有趣的工具来帮助解决问题，但他们应该远离任何可能成为企业规模或在产品路径中找到出路的东西。例如，DFIR分析师应专注于构建帮助自己团队的工具，而不是整个公司。

安全平台工程团队是一个很好的选择，可以帮助你在整个组织中扩展安全，但他们将继续只是大型企业使用的小众元素。尽管如此，我确实鼓励他们在较小的组织中使用；如果你的安全团队人数超过30人，并且有你我们讨论过的那些独特问题，那么你可以开始考虑在未来的人员配置中增加这个团队。

事实是，将安全防护栏杆构建到让人们的生活更轻松的工具有效得多。替代方案是进行手动安全审查，或者让人们遵循既定的流程。这些都有其用武之地；这取决于你想要解决的问题和修复它们所需的努力，但这种企业级问题几乎总是用一个用户喜欢的专用解决方案来解决更好。使用胡萝卜，而不是大棒。