激发团队在安全领域的灵感
作者：Joe Basirico
发布于：2019年8月21日
阅读时间：5分钟
安全执行是传统的安全思维方式，安全团队被设置为软件发布前必须通过的关卡。因此，开发团队将安全要求视为需要克服的障碍，而不是有价值的见解。这并非不合理，大多数安全团队都以这种方式设置自己，作为安全的最后堡垒。我甚至听到安全同事说过“每个漏洞必须在发布前修复！”这样的话。有了这样的态度，开发团队不热衷于与安全合作也就不足为奇了。
别误会，执行很重要，但它应该被视为其他前期安全工作的背景。团队中的每个人都应该理解，构建安全软件是他们的责任。他们应该为自己的软件安全感到自豪，就像他们为软件功能丰富、可用、快速或美观感到自豪一样。
业界一直在共同努力将安全思维左移。思路是，如果我们更早地考虑安全，就可以最小化构建安全软件所需的工作量，并减少后期发现的架构问题数量。这是很好的思维，左移非常重要。我喜欢教人们简单地问“这个功能的安全/隐私/安全影响是什么？”请记住，虽然左移是好的，但它仍然是一种安全执行形式：
- 你的需求得到安全团队的批准了吗？
- 你进行过架构评审了吗？
- 你构建了威胁模型了吗？
如果我们从事的是减慢开发速度的业务，开发人员和其他人将花费时间规避安全请求。这些时间本可以更好地用于开发安全控制或修复安全问题。
解决方案是激励团队的每个成员将安全视为软件质量的一个方面，并赋予他们在整个过程中做出良好决策的能力。就像面粉、鸡蛋、牛奶和糖是烘焙蛋糕的重要成分一样，教育、工具和意识是构建主动安全程序的重要成分。仅凭成分无法制作蛋糕，你需要热量。在安全领域，热量是对安全的全面承诺。这种承诺超越了法令或单一倡议，它是一种感觉，即安全是团队想要构建的软件质量的基石，它是自豪的源泉和团队对目标的集体奉献。达到这一点可能很困难。
我很幸运地在比尔·盖茨宣布微软可信计算计划后的那个夏天在微软工作。这是大型组织首次，可能仍然是最好的例子之一，致力于改变整个组织的行为，以从根本上改善安全。它需要远见、奉献和严肃的承诺来改变微软内部软件的构建方式。变化是缓慢的，但目标是明确的，变化始终是积极的。十七年后，微软构建了一些令人难以置信的工具、流程、方法和研究，对安全社区大有裨益，更不用说大幅提高了他们构建的所有软件的安全性。
在任何行业成为先驱都比跟随领导者更困难。因此，将组织对安全的奉献转变不需要像2002年的微软那样 overwhelming，但它确实需要承诺和来自高层的强有力领导。
如果你想对安全做出全面承诺，就需要在整个组织中传达一致的信息和承诺。可以从CEO宣布公司对安全的承诺开始。对于合适的公司，我看到这种方法非常成功。每个团队或组织可能都有预算分配给安全推动，用于工具、培训或其他支持。然后，Scrum主管或开发负责人被要求在其开发时间表中分配时间，用于代码和安全评审、威胁建模等。组织的领导者可能在整个组织提供安全培训和意识。这种文化上的全面改变可以快速让组织走上安全轨道，但有时需要大规模不可行的承诺。如果这听起来难以实现，你是对的，它通常是的！
我真正喜欢的另一种方式是我称之为“大师”模型。想象一下，你去找一位大师健身，大师列出了你所有的缺陷和需要改变的一切。你需要：多睡觉、吃得更好、锻炼、冥想、服用维生素、多喝水、少喝咖啡和酒精。试图改变生活的几乎每个方面可能很困难，只有处于非常困境的人才会 motivated 跟进。在大师模型中，你不是改变一切，而是衡量你最大的挑战，改进那些事情，并重复。目标不是一次修复所有事情，甚至不是完美修复每件事，目标是让一件事变得更好，然后选择下一个最重要的事情并改进它。
找到并优先处理需要修复的事情可能很困难。有时，在任何地方取得进展都很重要，即使它不是最重要的事情。我看到安全团队，尤其是新团队，成功的一种方式是举行“安全罪忏悔会”。这些是无判断的倾听会议，让安全团队以外的人告诉安全联络人他们担心什么。也许他们使用糟糕的哈希算法存储密码（或者，天哪，根本没有哈希！），或者他们担心即将到来的架构评审。无论是什么，此时会议的目的不是做出判断，而是了解情况。当然，安全团队可以在被问到时提供帮助，但尽量抵制说他们做错了什么的冲动。
以这种方式工作，你可以建立信任，并展示安全团队的早期胜利，这将使以后的对话更容易。随着时间的推移，团队将开始谈论与安全团队合作是多么容易和有帮助，并可能开始以临时方式寻求他们的帮助。打破开发团队和安全团队之间的障碍是创建安全文化的重要第一步。在这种文化中，安全团队被视为赋能者而不是执行者。
请订阅我们的新闻通讯。每月我们会发送一份新闻通讯，包含新闻摘要和我们最近几篇文章的链接。不要错过！
分享与讨论
- 在HackerNews上讨论
- 在Twitter上分享
归档于
- 领导力
- 安全团队
Joe Basirico & Jason Taylor © 2023