第二部分：从安全门到责任共担
图片来源：未知
作者：Joe Basirico
发布日期：2021年9月7日
阅读时间：8分钟
这是多部分博客系列的第二部分，如果您尚未阅读，请先查看第一篇：
第一部分：我在Series E初创公司ProdSec的头100天
在我的第一篇博客中，我讨论了如何找到Highspot以及这家公司吸引我的地方。我谈到了在快速适应新角色文化和需求时所面临的直接挑战。如果您还没读过，建议从那里开始再回来。
在这篇文章中，我将探讨安全思维的转变：从将安全团队视为软件交付瓶颈的安全门模式，转向通过培训、文化和支持使安全成为每个人的责任。这种转变将安全团队与工程团队的关系从“执行者”变为“赋能者”，这对每个人都更好！
微软SDL：每个阶段都附有安全“门”
当我开始从事安全工作时，我很幸运地在近20年前加入了微软，当时他们推出了可信计算计划。那时，最先进的安全指导是通过门（不是比尔·盖茨）来控制风险流——一组结构和检查点，旨在确保漏洞不会溜走。
- 想建议新功能或更改现有功能？从安全团队获取威胁模型。
- 想签入代码？从安全团队获取代码审查。
- 想发布软件？从安全团队获取安全评估和签核。
我是安全负责人之一，我的工作是在软件发布给客户之前签核我们的产品。知道大多数开发人员和测试人员没有深入的安全知识，而我的工作是查找和修复该产品中的所有安全漏洞，压力很大！在发布日前的几周里，我睡不好觉。
即使这些安全门有效，它们也不高效。它们使安全团队成为任何安全相关事务的瓶颈。这将所有责任从构建软件的工程师转移到安全团队，导致“猜测和检查”风格的安全程序注定失败。此外，这是基于微软古老的18个月瀑布流程设计的，在今天的敏捷开发环境中永远行不通。
尽管如此，我们仍在尝试将这些想法硬塞进现代开发流程，但未能成功。即使有像“左移”这样的高级概念，我们通常也没有给工程师提供工具、指导和培训，使他们有能力为自己的功能做出伟大的安全决策。
为了赋予工程师安全自主权，必须通过培训和反馈使他们能够做出决策，并且必须对这些决策负责。安全团队的存在是为了支持和指导这些决策，而不是做出决策。这是我知道的唯一能随组织扩展的模式。除非您计划为每个开发人员雇佣一名安全工程师，但这既不合理也不会成功。
培训
应用安全意识始于一套基线安全培训。这是开发人员学习构建安全代码、攻击场景以及首选修复和防御的角色和责任的地方。没有人比您的开发人员更了解您的代码库，用知识和热情武装他们以构建安全软件。
Highspot拥有我见过的最好的新员工入职流程之一。您的第一周用于了解行业和产品，然后在本月剩余时间深入探讨您工作的具体细节。如果您是工程师，这意味着理解我们使用的工具、流程和最佳实践。我们利用这个机会确保每位工程师都参加了我们的安全101培训，其中我们为每位工程师提供理解风险、常见漏洞以及寻求支持的知识。
在安全101之后，工程师有机会通过参加每两周一次的安全办公时间来增加知识。在办公时间中，我们回答工程师的紧迫问题，当问题用完时，我们提供实时培训。这种办公时间培训可以是正式培训，最终推广到工程团队的其余部分，也可以基于新的Highspot倡议甚至其他公司的新闻文章或漏洞进行更具体或范围更窄的培训。从错误中学习总是重要的，但从别人的错误中学习更好！
支持
安全团队必须为工程团队的其余部分提供支持以取得成功。这意味着对请求做出响应，并在需要时提供清晰指导。支持可以采取多种形式，从上述培训到审查、库或框架选择，或推荐修复。
我在疫情期间加入Highspot，这意味着我没有机会面对面见到许多同事。没有这一点，我发现很难建立基于信任的关系，而没有这些关系，我的互动更加事务性。事务性关系在某些情况下可能没问题，例如，如果我需要向IT团队请求某个系统上的新账户，我不需要在那里利用我的关系。但要构建安全文化环境，工程师必须感到舒适地提问和指出缺陷。
安全可能令人害怕，通常我会发现系统中的缺陷，这会给他人带来工作。如果该请求不是基于相互信任、尊重和目标，人们很快就会停止向我的团队寻求帮助。能够支持工程团队的一个重要部分是让他们感到舒适地向安全团队提出疑问或请求。通过频繁互动早期建立这些信任关系将在以后带来回报。
我通过许多一对一的Zoom会议、打开摄像头、在会议中发言和提问来实现这一点。
长期工具
为了安全地跨洋航行，我们需要工具和自动化使安全变得容易。这意味着实施和集成安全默认值、库、框架、工具和自动化。这些在安全系统的实施和检测漏洞时都扮演不同的角色。
默认值
为新系统创建安全默认值大大减少了错误的数量。拥有一套安全默认值还为您提供了一个在错误溜走时更新的地方。看到很多未加密的S3存储桶？在创建新S3存储桶时将加密设置为默认设置。在环境中发现很多操作系统相关漏洞？创建一个具有安全合理默认设置的安全黄金镜像。每当问题出现时，问问自己是否可以通过更好的默认设置来缓解。进行更改以缓解立即问题，并更新默认值，这样您就再也不会看到该问题。
库和框架
您上次看到CSRF或会话固定问题是什么时候？如果您的答案是一两年以上，您可以感谢库和框架最近的重大改进。选择最新的库和框架并正确使用它们可以大大帮助提高整体安全性，同时减少安全对开发流程速度的总体影响。
不过，适当使用库和框架非常重要。许多这些库附带安全默认值，这很好，但它们可能不是不安全现有库的即插即用替代品。这意味着有时工程师可能只是禁用安全控件以使某些东西工作，而不是花时间理解新系统。这是安全团队可以介入帮助建立最佳实践并提供支持和培训的地方。此外，我们设有监控以检测许多错误，并进行定期评估以最小化这些问题存在的时间。
工具
根据工具在软件开发流程中的部署和集成位置，它们在缓解风险、提供反馈或可能引入开发人员挫折感方面可能更有效或更无效。Highspot使用许多工具用于不同目的。安全团队频繁运行SAST和DAST工具以查找新引入的漏洞。您可以选择让安全团队定期运行工具，或将它们构建到构建或集成管道中。Highspot选择让安全团队运行工具，以便我们可以对每个问题进行分类并提供定向和具体的修复指导。这有助于减少开发人员的噪音，并保持CI/CD管道快速平稳运行。我们确实将带有安全规则的linter集成到我们的CI/CD管道中，以确保工程师遵守最佳实践。
工具不仅可以帮助捕获漏洞，还可以将安全保持在每位工程师的 forefront。来自linter或SAST/DAST工具的提醒可以提醒工程师安全很重要，并且需要一定水平的代码质量才能接受。
自动化
我喜欢“第二次自动化”这句话。如果有频繁执行的任务，应该自动化。这将帮助安全和工程团队扩展并应对新的独特挑战。我们已经集成和自动化了大多数工具以协同工作，我们的依赖检查器和其他工具被定向到我们的错误跟踪器进行分类。工具与Slack和电子邮件集成以提高可见性。当漏洞被修复时，它被转化为单元测试以确保回归不会在以后悄悄出现。我们还将尽可能自动化漏洞的发现。手动检查TLS配置、Cookie标志和标头等内容是浪费时间。自动化它，并将其集成到您使用的工具中！
总结
在我从事安全的20年里，很多事情发生了变化。我们不再需要说服每个团队安全很重要，我们与每个团队合作的方式也发生了变化。现在安全与工程其余部分之间有更多的协作，其中很多来自对支持、赋能和工具的关注，使安全团队成为交付伟大软件的合作伙伴，而不是障碍。
在最后一篇文章中，我们将探讨更多我在头100天中的错误和假设，以及我如何转变思维以满足新团队和新公司的需求。
请订阅我们的新闻通讯。每月我们发送一份新闻通讯，包含新闻摘要和我们最近几篇文章的链接。不要错过！