有许多众所周知的、所谓的技术定律。摩尔定律尤其具有代表性。让我们来看看其中的一些定律，看看它们对安全产生了哪些影响，以及由此可能带来的进一步发展。

1.Moore’s Law 摩尔定律

摩尔定律是指集成电路（IC）中的晶体管数量大约每两年翻一番。摩尔定律是对历史趋势的观察和预测。与其说它是一条物理定律，不如说它是一种与生产经验收益相关的经验关系。

我们都非常熟悉摩尔定律，以及它在过去几十年中给计算机和社会带来的巨大好处。随着处理能力成本的降低，几乎所有东西都实现了大规模数字化，这当然令人惊叹。然而，这也不可避免地助长了攻击面呈指数级增长的网络攻击。

另一方面，处理能力的大幅提升也带来了安全方面的好处，但这一点却鲜为人知。我们在使用安全功能的上升周期时不再那么节俭。此外，芯片上的专用指令也有助于优化加密运算的性能，如果没有这些指令，我们在许多平台上享受的普遍加密技术就不会像现在这样具有成本效益。

虽然硅片领域一直面临着成本、功耗、性能和其他因素的压力，但摩尔定律所描述的扩展也促成了其他安全创新。从管理程序、虚拟机管理器到操作系统，这些创新为更高层次的安全隔离目标提供了支持。我们还有其他硬件创新，如机密计算，它使人工智能系统的保护取得了进步。

然而，从坏处来看，摩尔定律所描述的效应已经逐渐减弱。因此，我们看到处理器需要进行性能优化，这就产生了推测执行(speculative execution)等技术，无意中催生了一系列漏洞，如 Spectre、Meltdown 等。

2.Murphy’s Law 墨菲定律

墨菲定律是一句格言或谚语，通常是这样说的："任何可能出错的事情都会出错"。在某些表述中，它被引申为 "任何可能出错的事情都会出错，而且是在最糟糕的时候"。

当然，这并不是严格的技术法则。各行各业都会遇到这种情况。这说明在安全和可靠性领域，弹性和混沌工程是一门扩展学科。在拥有数百万台机器的情况下，即使是四到五个9的可靠性也会变成持续的单点故障，此时，面对持续故障构建技术就变得更加重要。因此，针对此类故障的工程设计至关重要。关于这一概念的最佳书籍来自谷歌的经验：作为计算机的数据中心：《设计仓库规模的机器》（The Datacenter as a Computer : Designing Warehouse Scale Machines）。

墨菲定律在安全方面的一个更具体的角度是需要持续的控制监测。大多数控制措施都会随着时间的推移而退化或失效，除非刻意持续进行。

墨菲定律还意味着，失效的控制措施将是你最需要用来挫败攻击的措施--如果只是因为顾名思义，你会在漏洞事后检查中发现失效。大多数事后分析通常是关于「为什么你认为应该阻止攻击的控制没有阻止攻击」（"是的，我们在这次变更中禁用了它，但有人没有重新打开它"），而不是真正的新攻击，没有人考虑过针对这种攻击的控制。

我最喜欢墨菲定律的推论："如果你能想到四种出错的方式，那么它就会在第五种方式中出错"。

3.Conway’s Law 康威定律

康威定律描述了组织的沟通结构与它们设计的系统之间的联系。这个定律以计算机程序员梅尔文·康威的名字命名，他在1967年提出了这个想法。他最初的措辞是：“设计系统（在这里使用的广义上）的组织受限于产生与这些组织的沟通结构相似的设计。”

在任何组织的产品开发过程中，都会由此产生许多分支。这不仅适用于大型科技公司，尽管这张传奇性的图表确实是许多人对此看法的缩影。

根据我的经验，康威定律影响着大多数组织，即使是那些小组织也不例外。此外，值得从整体风险管理和安全调整的角度来考虑这个问题，而不是从产品的构思和生产方式的角度来考虑。

许多安全团队努力与产品团队紧密结合，或者完全嵌入安全工程师或在其他团队中创建联合安全团队。起初，这样做的安全团队大多认为要做的是培训、装备和支持这些被嵌入式团队，以完成本地的安全工作。

但在大多数情况下，真正的工作是努力协调这些团队跨越组织边界线的工作。老实说，这在很大程度上意味着要处理组织功能失调的问题，使所有工作都能在组织结构图中正常运行。我并不是说这听起来太消极，有时组织结构从某个设计目标来看非常合理，但对其他目标（包括安全目标）来说却行不通。我确信，如果我们在设计组织结构时纯粹为了优化端到端的安全目标，我们可能会打破更广泛的目标或影响其他风险（如恢复能力）。优化此类问题是一个难题。

在风险治理方面也存在类似的效应，当存在跨企业风险时，需要各部门协调解决问题。我多次见到的经典例子是软件漏洞，表现为共享库中的漏洞，更新会改变一些其他功能所依赖的功能，而这些功能因为某种原因无法优先考虑测试和升级。因此，所有组织都因为一个组织而“受限”，而对于每个功能都产生或分叉库版本是不可取的。这个问题的组织设计方面归结为不同程度的“协调成本”和激励措施，以减轻这些类型的风险。

4.Hyrum’s Law海勒姆定律

海勒姆定律认为，如果API的用户数量足够多，那么在合同中承诺什么并不重要：系统的所有可观察行为都会被某些人所依赖。

XKCD 的另一幅经典漫画也许最能说明这一点。

我曾多次目睹过这种情况造成的安全后果，通常与康威定律的后果同时出现。我最喜欢（如果这也算喜欢的话）的一个例子是，多年前，我试图升级一个知名目录服务器上密码集的密钥长度。它无意中暴露了一个不在其主要标准API中的属性（我在这里略过了很多细节），而该属性已成为某个供应商的 NFS 文件系统所依赖的属性，无法支持这种更改。目录服务器供应商并不想知道这个问题，因为它不在他们的官方 API 中，而 NFS 供应商也在拖延时间（"你们是唯一要求这样做的客户"--尽管我们不是）。更糟糕的是，在 NFS 供应商最终进行升级时，上游的自研数据库系统进一步依赖于 NFS 系统中一些未注明的性能优化功能（聪明的工程师），而这些功能将被破坏。因此，尽管我们付出了巨大的努力和组织承诺，我们还是花了很长时间才升级了加密系统。在外人看来，我们似乎并不关心安全问题，因为他们没有看到我们所处的隐藏的依赖性地狱景象。类似的例子也许你可以写一本书。

5.Metcalfe’s Law 梅特卡夫定律

梅特卡夫定律指出，电信网络的经济价值或影响力与系统连接用户数量的平方成正比。该定律以罗伯特-梅特卡夫的名字命名，于 1980 年首次提出，但不是以用户为单位，而是以 "兼容的通信设备"（如传真机、电话）为单位。

如今，从社交网络、B2C、B2B、复杂的 IT 环境到供应链，这一法则几乎渗透到我们的一切工作中。网络效应、具有优先附着性的无规模网络和其他特性会产生一系列风险。这些风险通常表现为特定组件、服务、产品、供应商或物理基础设施的集中风险。在许多情况下，它们是供应链网络中第四方和第五方层面的隐藏部分，与自己的第三方无关。

不过，从好的方面看，这确实给我们提供了一些机会，让我们在推动安全升级时找到 80/20 的方法。它还揭示了基于 "网络 "的机会，可以在更广泛的企业范围内实施顺流控制。例如，我记得在 2000 年首次实施企业单点登录（SSO）系统时--当时我们都是第一次做这种事情--要在大型企业中集成 5000 多个应用程序并非易事。我们的主要直觉是，先不要在最关键的系统上实施 SSO，而是在使用最广泛的系统上实施 SSO。坦率地说，这些系统中的大多数并不是安全关键系统。我们这样做的原因是，我们希望最终用户能体验到密码输入摩擦减少的好处，这样他们就会反过来要求 IT 团队在 SSO 系统上安装他们的应用程序。这样一来，我们安全团队就不需要强制实施 SSO。相反，我们提供了工具和API，让开发团队按照用户要求的速度自助上架。如果我们先从占风险关键性 80% 的 20% 系统着手，就不会产生网络效应，完成这项工作所需的时间也会是现在的 5 倍。相反，通过对涉及到 80% 员工的 20% 系统进行不同的处理，我们催化了业务驱动力，从而在½ X的时间内完成了这项工作。

6.Wirth’s Law 维斯定律

维斯定律是一个关于计算机性能的格言，它指出软件变慢的速度比硬件变快的速度更快。计算机科学家尼克劳斯-沃思（Niklaus Wirth）在 1995 年发表的文章《精益软件的诉求A Plea for Lean Software》中对此进行了论述。

尽管存在摩尔定律，但我们还是设法开发出了能够充分吸收硬件扩展的软件。我还记得在 IBM 大型机上开发软件的情景，那时候的大型机确实很酷。我印象最深的是在大型机上运行一个 1000 多个并发用户的事务管理系统，而大型机的处理能力还不如一台奔腾电脑，内存只有 8Mb，磁盘空间也不大。但是，由于有了协同处理（前端通信处理器、磁盘通道等）和高效的操作系统，即使是虚拟化（VM/CP 上的 MVS），以及明智地使用高效编程和事务监控器，我们也能从每个指令周期中挤出很多时间。

从消极方面看，沃斯定律的一个重要后果是软件的臃肿，在许多情况下造成了不必要的大攻击面和相应的安全漏洞。

7.Cunningham’s Law 坎宁安定律

坎宁安定律："在互联网上获得正确答案的最佳途径不是提问，而是发布错误答案"。这是指人们纠正错误答案比回答问题更快。根据史蒂文-麦克吉迪（Steven McGeady）的说法，坎宁安在 20 世纪 80 年代初突发奇想，向他提出了这一建议，麦克吉迪将其称为 "坎宁安定律"。

我们中的许多人都遇到过这样的相关问题：安全社区的某些人非常善于批评为提高安全性而做出的值得称赞的努力，但他们自己却没有提供多少替代方案。是的，我们都应该脸皮更厚一些，但坎宁安定律总是在无意中发挥作用。

8.Hyponnen’s Law 海波能定律

Hyponnen定律的表述是 "如果它很聪明，它就很脆弱"。

Mikko Hypponen的定律显然是正确的，是的，是故意显而易见的。我之所以喜欢这个定律，特别是因为它提醒我们要考虑合理安排事物的智能程度。现在，这听起来可能有点奇怪，难道我们不希望所有东西都尽可能聪明吗？当然不是。我不一定希望我的烤面包机那么聪明。

除此以外，还可以选择确保设备的基本功能可以在没有连接的情况下或在用户选择的智能程度下持续运行，这不仅可以确保某种程度的长期可靠性，还可以消除一大批潜在的攻击集结点和未来的僵尸网络。

9.Kryder’s Law克雷德定律

克雷德定律描述的是磁盘平均存储密度的增长速度超过摩尔定律。这一速度远远快于摩尔定律假设的半导体芯片密度两年翻一番的速度。

说到攻击面，这是一个相关的概念，即我们保存了多少数据--仅仅因为我们可以--主要是因为克雷德定律。因此，有了这些数据，我们就必须加大力度保护这些数据。许多企业都在努力减少各种服务中捕获或保留的数据。从好的方面来看，我们可以保留更多的日志和其他对安全有用的遥测数据。

10.Venables’ Law 维纳布尔斯定律

维纳布尔斯定律可以表述为 "攻击者也有老板和预算"。

抱歉，我把自己的 "法则 "放在这里，显得有些傲慢。虽然我可能是第一个用这种表达方式阐述这一概念的人，但我肯定不是唯一一个在几十年前就考虑到攻击者有制约因素，并且在这些制约因素面前大多是理性的人。而且，只要存在制约因素，防御者就有机会与攻击者周旋，以施加代价或威慑行动。

制约因素可能是经济因素，他们有预算和时间在不得不转向其他事情之前进行某些攻击。其他制约因素可能是他们所处的权力结构（他们的上司），这种权力结构驱使他们想要表现自己，不想被抓，不想让团队或政权难堪。或者，制约因素可能是个人的，比如你很享受每年在欧洲的假期，但讨厌的起诉/制裁或其他对你的曝光会在很多方面影响你的生活。

所有这些制约因素都可以被防御者放大，使防御更加有效，通过 "前卫 "挑拨攻击者群体、网络或管理结构，增加他们被抓的可能性。这就是为什么网络威慑是一个细致入微的话题，而不仅仅是以惩罚的形式向攻击者倾泻火力；你还可以利用徒劳性（提高攻击成本）、依赖性（攻击也会影响攻击者网络或供应链中的某个环节）或反生产性（攻击者行为的长期后果会否定其自身的战略目标）。

因此，从这一规律出发，作为防御者，我们的目标是破坏攻击的经济性，破坏攻击者的人力/组织网络的权力结构。攻击者只需一次正确，而防御者却必须永远正确，这句谚语可以也应该颠倒过来。攻击者必须始终正确（不被发现），而防御者只需发现他们一次。当然，要真正做到这一点并真正付出代价，就必须在预防、检测、响应、恢复和透明化方面采取相当成熟的方法。透明度部分（也许是以某种严密的方式）将推动数字免疫系统摧毁攻击者的优势，并为他们的目标和权力结构带来阳光消毒剂。

最重要的是：当然，这些不是严格意义上的定律，但这些格言仍然对编码我们的知识体系非常有用。就像大趋势一样，这些格言值得关注，这样你就可以利用它们来获得优势，但更重要的是确保你不会与它们代表的不可阻挡的力量对立。

原文链接：

https://www.philvenables.com/post/security-and-ten-laws-of-technology

声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。