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