「网络安全是臭名昭著的“守门员”，他们在虚拟CAT机器中肆意妄为，为软件交付设置路障，用千斤顶砸出坑坑洼洼的路面。这引起了几乎所有其他软件交付利益相关者的不满，但由于网络安全反映了一系列独特而复杂的挑战这一“事实”，这种做法往往是合理的。」

实际上，这不是事实。它更像是宣传。网络安全并没有那么特殊。如果我们想最大限度地减少网络攻击对软件系统的破坏，网络安全就不应该那么特殊。

在本文中，我将痛斥自视特别的安全组织，然后为如何使我们的计划更具建设性、而非限制性提供机会。

网络安全是否特殊？

为了开诚布公地交流，我们来想一下网络思想领袖们经常提到的网络安全与众不同的一些原因，并加以驳斥：

1.很难证明我们的价值，因为它是建立在反事实的基础上。

网站可靠性工程 (SRE, Site reliability engineering) 团队也面临着同样的挑战，但却少有怨言。

2.这么多团队、有这么多软件变更，我们怎么可能改进这些活动？

这本来就是平台开发团队的使命，许多团队甚至可以为其改进的价值提供证据。

3.攻击者是特别聪明的人类，他们活着的目的就是要伤害我们。

攻击者可能很聪明，但并非总是如此，而且我们从“特别聪明”的开发者/团队身上看到的可靠性故障所造成的危害，远远超出了攻击者的想象。早在勒索软件团伙出现之前，实习生就已经在破坏数据了。

4.我们被视为成本中心！

同样，请与您的 SRE 或平台工程师交谈，或者，如果您想听听被持续解雇的真实感受，请与您的 D&I 同事交谈。

5.软件系统如此复杂，我们怎么可能期望对它们有足够的了解，从而确保安全？

你可以问问开发部门的任何人，软件的复杂性是否会增加他们的工作难度，尤其是那些在架构审查时喃喃自语谈论Lamport逻辑时钟的人。你觉得以民族国家为对手就很惨吗？他们在与基本物理定律作斗争啊。

恕我直言

总之，网络安全问题并不像我们认为的那样深奥难懂。然而，我经常遇到一些网络工程师，他们不相信他们的平台/信息安全/开发人员/SRE同事的工作真的那么难。有时，我觉得网络安全领导者和工程师们认为，所有这些团队都自动获得了业务部门的尊重——自主权、预算、权力。

在这方面，我听说CISO被描述为“美国企业中最难的工作”，如果你忙于掩盖重罪，也许确实如此，但我听到安全领导者抱怨的几乎所有问题都反映在信息、平台和SRE方面。

这种尊重必须赢得。其他团队则通过巧妙地解决可靠性和开发人员工作效率方面的难题来赢得尊重。他们做的是thinky thinky和buildy buildy的艰苦工作，而不是把繁琐的策略和工具强加给软件工程师，我称之为SSB模式（“sink or swim, bitch”，不成功便成仁）。他们不会在Confluence中刻画100条安全戒律；他们会构建模式、框架和工具，对正确的需求进行编码，让软件工程师更轻松、更快速地采用更好的方法。

如果网络安全想要赢得类似的尊重，就不能继续在软件上设置障碍和把关。它不能假装安全故障在重要性和影响上是如此与众不同，以至于需要完全独立的工作流程、堆栈、审查、工具、设计和其他一切。攻击者在未经我们同意的情况下访问我们的系统是故障的一种，但不是唯一的一种。可靠性故障可以说是更频繁、更具破坏性的故障；开发人员的生产力故障可能意味着成功的市场差异化与失去市场份额之间的差异。

弹性，而非拦路虎

这正是我强调软件弹性的原因，因为它包含了我们对可靠性和网络安全的关注。这与我们的目标结果有关：我们希望系统能够在瞬息万变的世界中适应故障和机遇。这些故障可能是网络攻击者造成的，也可能是性能缺陷或开发人员体验（DX）缺陷造成的，两者之间的差别并不像我们想象的那么大。

共同的“敌人”是意外行为。事实上，它是我们古老的克星，是形式化方法无法战胜的永恒敌人。为意外行为的每一个诱因建立独立的管道、可观察性堆栈或审查流程，将是一场操作灾难，而网络安全恰恰坚持这样做。

网络安全拥有自己独特的流程并不合理。无论是在操作上、哲学上还是社会上，都没有道理。这不符合系统的弹性需求，甚至在软件安全方面也无意义。

如果我们想保持大规模的弹性恢复能力，那么我们就应该集思广益，制定战略来提高系统在各种故障中的弹性恢复能力。从实际意义上讲，无论服务宕机是由于性能漏洞还是攻击者利用了安全漏洞，这都无关紧要；无论哪种情况，对业务造成的结果都是收入损失。

例如，队列或消息代理可以帮助我们在任何情况下恢复服务健康。我们应该忽视这个基于设计的解决方案，而选择安全团队需要审查和批准每个软件发布，因为它可能存在可利用的漏洞，现在积压至少六个月，这导致软件工程师的批处理大小增加，从而导致更高的故障率。天啊，为什么有人认为这是可以接受的状况？帝国建设可能感觉很好，但对每个人都不利。

现在，一些安全领导人可能因为我让他们放弃自己宝贵的特殊流程而大发雷霆。这通常是在面对面的对话中，他们会反驳说：“那么，你是说我们根本不应该关心网络安全吗？”我绝不是这个意思。我们应该关注网络安全，但我们不应将其孤立起来，或将其视为单独的问题，因为这实际上会恶化我们所谓的长期关注的结果。

那么，我们应该怎么做才能不成为阻碍呢？网络安全和平台工程团队可以利用大量的机会来实现我们所追求的最终目标，而且比繁琐的网络设计/代码审查要有效得多。下面就让我们一起来看看。

如何不成为前进障碍

1. 自我认证指南。让产品工程团队根据我们事先编写的（相对）完整的指南进行自我认证。一些网络安全团队声称他们已经在做这个，但软件工程师通常发现这些指南太模糊，因此会绕过它们。通常，这是因为网络安全团队以“我看到时就知道安全是什么样子”的心态运作。而且由于网络安全团队缺乏软件工程专业知识，它经常与软件交付实际运作脱节。

2.遵循Platform/SRE。将安全设计审查纳入一般设计/架构审查流程（代码审查也是如此）。就此与站点可靠性工程 (SRE) 或平台工程团队合作；了解他们如何确保在设计审查过程中考虑可靠性要求，然后......基本上就是这么做的。归根结底，两个利益相关者（可靠性和网络安全）都希望得到相似的结果，因此我们越能找到消除或减少系统危险的设计机会：通过设计实现弹性和安全性，我们的代码就会越安全、越可靠（即质量更高）。

3.构建标准化模式。为适用于所有服务和软件的“横向问题”构建标准解决方案（也称为“铺平道路”或 "模式"）。这些解决方案通常由平台工程团队构建，用于解决与性能和可靠性相关的横向问题。如果平台工程团队针对网络安全问题构建了标准解决方案，那是因为他们对网络安全团队的惰性和低效感到失望，因此自己构建了标准解决方案。

有一些网络安全团队已经在实践中建立了这些标准解决方案（比如Netflix、Block和其他一些团队，我希望他们能公布自己的努力，提示提示）。但我仍然听到一些CISO声称这样做是 “不可能的”（客观上并非如此）。

例如，我们可以创建架构或编码模式，使编写更安全的代码变得更容易（或者相反，使引入某些类型的错误变得更困难）。我们可以为充满危险的中间件（如身份验证）提供标准化库。这样，产品工程团队就不必亲自实施authN，从而节省了时间，而且我们也可以确信，不会潜伏着大量潜在的、临时的authN灾难。

4.放弃边界模式。摒弃要求所有软件永远“安全”以维护我们想要的安全属性的外围、护城河和城堡模式。因为你猜怎么着，这种假设将不可避免地失败。许多组织已经拥有开发、测试或暂存环境，让我们能够评估我们对软件工作方式的假设。这些环境也是创建隔离环境的一种模式，可以控制故障影响。

如果您的组织还没有测试或暂存环境，这对您的网络安全团队来说是一个很好的起步项目；同时，您还可以倡导集成测试。

5.提供建议，不要发号施令。提供咨询服务，让软件工程师可以就安全相关问题向我们寻求帮助或指导。设计人员和工程师最好能在安全与他们所面临的其他问题（如可靠性、可维护性和上市时间）之间取得平衡，而不是由安全团队来决定设计要求。这是网络安全计划与业务保持一致的关键方法。

6.要求平台团队集成安全性。主动与基础架构和平台团队合作，将安全用例集成到他们的设计中，这样更广泛的产品工程社区就可以将安全问题授权给他们正在使用的库和模板。

7.提供隔离模式。为软件工程团队提供隔离COTS软件的机制。我们的目标是，至少使其符合要求，并通过设计减少事故影响。这样，我们的工程团队就不必乞求供应商来实现我们组织的自视特别的安全要求（世界上其他地方会认为这是“怪异”的），或者自己分叉开源软件（OSS）来实现这些要求。

8.进行用户研究。让更安全/更可靠的方式也成为更令人愉悦的方式：更快、更轻松、更简单。通过开展用户研究，花时间了解用户在特定活动中的目标、限制因素、工作流程和情感历程，我们可以定制我们构建和实施的解决方案，帮助他们以安全的方式实现他们的愿望。

一个比较常见的例子是，推出SSO可以为工程团队带来愉悦的体验，因为他们的所有应用程序现在都在一个地方；用户只需 SSO 进入他们的应用程序即可访问，而无需维护N个单独的账户（减少了操作步骤）。这意味着我们在提高了速度和易用性的同时，也改善了安全性。我们的企业一定会非常高兴。

向更好的网络化前行

我曾听人真诚地说过，CISO是美国企业中最难做的工作之一。他们应该会很高兴地发现，我所认识的CISO中，至少有一部分人遵循了上述原则，他们似乎比那些还在试图用马车鞭子指挥开发人员的人更享受自己的工作。

在上述模式中，以及在我在书中描述的平台弹性工程学科中，我们以一种感同身受的方式为真实的人类构建事物、解决真实的问题。我们可以看到实实在在的改进，而不是“风险覆盖率提高X%”这样模糊的成功。