安全错配

安全必须是业务的推动者，而不是阻碍者。

Phil Vachon

“叮！”你的电脑发出提示音：你有新邮件。就像巴甫洛夫训练有素的狗一样，你打开了你的电子邮件客户端。一些可怕的东西潜伏在你的收件箱顶部：安全审查工单的更新。当你审查结果时，你感到绝望。你的团队在向付费客户交付功能方面已经迟到了，你没有时间和资源来修复所有问题。当安全团队介入时，目标似乎在移动。有时感觉好像每个审查员都发现了一些他们刚刚读到的论文中的理论问题，并以此为借口来推迟你的发布日期。你与你的产品管理团队安排了一次临时会议，以审查计划。
也许他们会灵活一些……

任何在中大型公司经历过产品交付生命周期的人都体验过类似的情景——安全团队在最后一刻给出了一系列问题，而已经延期的产品团队正在权衡忽略产品安全指导的风险。相反，安全审查员在游戏后期才被引入，给产品团队一份需要在发布前完成的任务清单，但没有优先排序，并且不清楚这些问题的严重程度。

通常，工作过度的产品安全审查员不得不将初步调查结果草率地抛给产品团队，让他们自行解决。这种没有建设性的反馈循环仍在继续。

更糟糕的是，安全团队警惕地注视着产品交付团队，仿佛他们犯了滔天大罪，他们对安全最佳实践的明显无知让他们无可救药。另一方面，产品交付团队将安全团队视为一群高薪牛仔，他们编造不切实际和不现实的风险场景。产品团队渴望明确需要解决哪些高优先级风险——毕竟，安全是很令人兴奋的！然而，看到安全团队未能利用这种兴奋感，将这些互动变成产品团队所畏惧的事情，这并不罕见。难道没有办法弥合这种差距吗？

产品安全审查员长舒一口气。又完成了一个工单，暂时的，直到它再次弹回待审查队列。团队承受着越来越大的压力，需要处理越来越多的工单。安全团队也没有很好的指导——业务（推动产品的部门）愿意接受哪些风险？哪些产品是最重要的，需要检查问题？

“叮！”安全审查员的电脑发出提示音。她叹了口气，打开了她的电子邮件客户端。一些东西潜伏在她的收件箱顶部：来自CISO（首席信息安全官）的全员更新，感谢团队的所有辛勤工作。

“感谢”掩盖了重点：紧随其后的是提醒公司正在冻结招聘。但是公司一直在发布新产品，她的团队如何跟上工作量？她无奈地看了看安全审查工单队列的顶部：接下来要处理的是她之前审查过的工单。也许她会发现一些新的东西……

软件本质上是复杂的。开发软件系统的经济压力加剧了这一事实。框架、面向服务的架构、普遍的代码重用以及软件工程中的其他复杂性管理策略的蓬勃发展有助于降低“从头开始”的成本。

有些人可能会争辩说，这些策略可能会使复杂的设计变成一个更加复杂的问题，但海勒姆定律的一个推论是，软件系统通常没有充分的规范。正是在这些规范的模糊性中，软件开发人员有机会发展他们自己对什么是公共接口或大型系统功能，什么不是的理解。安全团队就生活在这个层面，并在这些模糊性中蓬勃发展。产品团队只想发布一些对行为良好的用户有效的东西。

麻省理工学院航空航天学教授 Nancy Leveson 经常提醒我们，可靠性、弹性和安全性是定义良好的系统的涌现属性。产品是系统面向客户端的部分，它建立在数千行基础设施代码之上，一直到底层硬件的金属和硅。这些层中的每一层都有自己的管理、可靠性和安全挑战，并且堆栈上层的所有权开发团队从较低层的细节中抽象出来。通常，安全功能是在事后才附加的，或者更糟糕的是，在最初的开发人员离开公司多年后才添加。

你可以看到错配发生在哪里：安全团队存在于一个非常不同的空间中。他们深入研究抽象，深入了解特定组件如何交互。然而，他们经常忽略将各层联系在一起的细节，或者产品团队甚至不了解这些层的结构这一事实。或者他们可能会对他们要求的“简单”更改的复杂性做出乐观的假设——你“简单的界面”更改可能会爆炸式地扩展到无数个地方。

你和你的团队挤在会议室里。你的产品经理在大陆另一端的公司总部，正在 Zoom 上。安全审查员没有明确指出哪些问题最严重，所以你必须尽力猜测优先级。

当你滔滔不绝地列出调查结果和拟议的解决方案时，产品经理看起来心不在焉。她打断并问道：“听着，安全团队是否阻止我们发货？”你思考了一下这个问题，心中充满了对接下来会发生什么的恐惧。

她叹了口气。“好吧，发货吧。我们会处理善后事宜。董事会更关心收入，而不是安全人员说什么。”她挂断了 Zoom 电话。显然她有更重要的事情要担心……

由于世界观的这些差异，安全团队往往发现自己与产品团队处于对立状态。即使有最好的意图，他们也发现他们的指导被忽视了。

安全团队开始退而求其次，使用恐吓战术来证明他们的工作对企业的重要性。这会产生更多的摩擦，并且在这种环境中，“我们与他们”的心态找到了肥沃的土壤。“对一切都说不”的安全团队是现代企业环境中常见的比喻，但这种回应并非出于恶意。有时这只是因为不堪重负，并且没有很好的方法来回答“是的，但是……”

安全团队需要委婉地提醒他们的合作伙伴，对企业基础设施的攻击对坏人来说是有利可图的，尤其是在勒索软件和数据勒索的时代。这些类型攻击的复杂性也在不断提高——但犯罪分子并没有使用任何新颖的技术来获得最初的立足点。令人惊讶的是，对重要服务的弱身份验证、暴露于公共互联网的未修补或敏感系统以及社会工程仍然是许多备受瞩目的攻击的根源。（有人可能会聪明地问，“为什么你不把‘心怀不满的内部人员’或‘0-day漏洞’包括在列表中？” 前者是需要解决的独特的业务挑战，但它是一种风险。后者是不太可能的，除非你真的在错误的地方并且被正确的人盯上了。我们将在未来的专栏中更多地讨论这一点。）

可以肯定的是：说“不”的信息安全团队需要改变。（请注意，我从不使用网络安全来描述我们所做的事情；如果可以的话，我会绞尽脑汁避免使用网络这个词。这仅仅是一种偏好。）躲在护城河后面可以轻松抵御攻击，但桥梁可以让你补充物资并与客户的城堡建立关系。请记住，安全团队的角色是授权他们的业务充满信心地前进，而不是阻碍进步。

对于您希望我在未来专栏中探讨的广泛主题，您有任何问题或想法吗？请通过电子邮件 [email protected] 与我分享。

Phil Vachon（Twitter 上的 @pvachonnyc）领导彭博 CTO 办公室的信息安全项目。他的团队为彭博的安全设定愿景和方向，并制定战略以确保公司今天的安全。Phil 在构建安全的嵌入式生物识别系统以及硬件安全模块方面拥有丰富的背景。此前，他共同创立并担任一家初创公司的 CTO，该公司构建了一个高速数据包捕获和分析平台，并从事星载合成孔径雷达数据处理和应用。Phil 的技术兴趣集中在以用户为中心的安全系统，尤其是在身份和身份验证方面。他还对嵌入式系统的实用威胁模型感兴趣。当不面对电脑时，Phil 可能会在他的自行车上，可能在某个地方爬山。

最初发表于 Queue 第 21 卷，第 3 期—
在数字图书馆中评论本文

更多相关文章

Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用保密联邦学习的可信赖 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 AI 法规的基石。经典的 FL 在设计时非常强调安全性和隐私性，但以牺牲透明度和问责制为代价。CFL 通过将 FL 与 TEE 和承诺相结合，弥合了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性和推理期间模型的保护。机密计算的最新进展（例如机密容器和机密 GPU）意味着现有的 FL 框架可以无缝扩展以支持 CFL，且开销较低。

Raluca Ada Popa - 机密计算还是密码计算？
通过 MPC/同态加密与硬件飞地进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您心中想到的工作负载非常重要。对于简单的工作负载（例如简单的求和、低阶多项式或简单的机器学习任务），这两种方法都可以在实践中使用，但对于丰富的计算（例如复杂的 SQL 分析或训练大型机器学习模型），在目前，只有硬件飞地方法对于许多实际部署场景来说足够实用。

Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处展示的实验表明，Parma（在 Azure 容器实例上驱动机密容器的架构）增加的额外性能开销不到底层 TEE 增加的开销的百分之一。重要的是，Parma 确保了容器组的所有可达状态的安全不变性，并以证明报告为根基。这允许外部第三方与容器安全地通信，从而实现广泛的容器化工作流程，这些工作流程需要对安全数据的机密访问。公司获得了在云中运行最机密工作流程的优势，而无需在其安全要求上妥协。

Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
机密计算具有通过将监管系统移出 TCB 来提高通用计算平台安全性的巨大潜力，从而减小 TCB 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在由第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。