我们使用技术构建产品和服务的方式在不断发展，其速度令人难以理解。 遗憾的是，用于保护设计方法的主要方法是预防性的，这意味着我们在一个无状态的世界中设计有状态的安全性。 我们设计、实施和记录安全的方式并没有跟上现代产品工程技术，例如持续交付和复杂的分布式系统。 我们通常为生产发布的 Day Zero 设计安全控制，而未能从 Day 1 到 Day (N) 演化我们的控制状态。
这个问题也源于现代基于软件的架构和安全控制之间缺乏反馈回路。 迭代构建实践不断推送产品更新，创建不可变的环境，并将复杂的蓝绿部署和依赖应用于不断变化的第三方微服务。 因此，现代产品和服务每天都在变化，即使安全性漂移到未知领域。
安全性应该是客观且经过严格测试的，使用数据和测量来驱动我们关于企业安全性的决策。 复杂的分布式系统、持续交付和高级交付模型（如蓝/绿部署）的时代挑战了传统测试方法是否足够。 虽然测试可以作为系统检测的有用反馈机制，但仅靠测试是不够的； 我们还应该进行实验。
测试和实验有什么区别？ 测试旨在评估和验证先前已知的系统属性的存在。 相比之下，实验旨在通过利用科学方法来推导出关于系统的新信息。 测试和实验都是衡量我们假设系统如何运行与它实际如何运行之间的差距的绝佳方式。
安全工程领域中的安全实验从根本上是应用混沌工程的结果。 混沌工程是在分布式系统上进行实验的学科，目的是建立对系统在生产中承受动荡条件的能力的信心。
混沌工程中常见的说法是“希望不是一种策略”。 当我开始运用混沌安全之旅，使用 ChaoSlingr 时，我开始以不同的方式思考失败的角色，无论是在我们构建系统的方式还是在我们尝试保护系统的方式中。 我们通常如何识别企业内部安全控制的失败？ 通常，我们直到某个东西不再正常工作时才意识到它，这通常是安全事件的情况。 安全事件不是有效的检测措施，因为那时已经太晚了。 如果我们渴望主动检测安全故障，我们必须找到更好的检测和监控方法。
图片由 Aaron Rinehart 提供
虽然这可能会让你想起苏斯博士的经典儿童读物 "One Fish, Two Fish, Red Fish, Blue Fish"，但安全测试涉及的内容远不止是一盒装满紫色、蓝色和红色团队练习的蜡笔。 相反，它是一门广泛的学科，包含重要的技术，例如道德黑客攻击、威胁搜寻、漏洞扫描等。 在本文中，我们将讨论客观安全检测的一般重要性，红色和紫色团队练习等当前安全测试方法中的差距，以及安全实验的出现如何帮助弥合这些差距。
我们无意贬低红色和紫色练习或其他安全测试方法的价值，而是要扩展此测试的重要性并阐明一种新兴技术。
源于武装部队，红队多年来一直拥有许多不同的定义，但今天它可以被描述为一种对抗性方法，以尽可能逼真的方式模拟攻击者的行为和技术，以测试安全计划的有效性。 在企业安全测试中看到的两种常见的红队形式是道德黑客攻击和渗透测试，它们通常涉及内部和外部参与的混合。
历史问题：红队与蓝队测试
- 红队演习中的反馈回路通常包括扔过墙的报告，如果它们被共享的话
- 演习主要侧重于恶意攻击者、漏洞利用和复杂的主观事件
- 红队演习强调漏洞修复，而不是预防和检测
- 团队因其战胜对方的能力而受到激励
- 红队通常至少部分由外包团体组成
- 红队和蓝队的目标不一致
- 红队的成功通常会导致（大型可怕的报告 = 工作做得好），而蓝队的成功通常会导致（没有警报 = 所有预防性控制都有效！）
- 成功取决于团队可以绕过多少控制（蓝队失败点）
- 对于蓝队来说，许多警报可能会被误解为意味着检测能力正在有效运行
紫队演习 尝试通过提高透明度、教育和更好的反馈循环，在攻防安全技术之间创建更具凝聚力的测试体验。 通过将蓝队的防御策略和控制与红队发现的威胁和漏洞集成到单一叙述中，目标是最大限度地发挥每个人的努力。
现代产品工程中红队 (RT) 和紫队 (PT) 演习的问题
- 红队演习的许多问题也存在于 PT 演习中
- 通常仅在应用程序组合的最高百分比上执行
- 演习通常按年度或每月执行，或者最好每周执行一次，例如“Red Team Mondays”，即使对于成熟的企业来说，这也很耗费资源
- RT 和 PT 演习主要侧重于恶意或对抗性攻击，并且通常会取得一定的成功。 在我的职业生涯中，我很少看到这些演习以失败告终。
- RT 和 PT 演习主要侧重于恶意活动作为根本原因，尽管人为因素的趋势日益增长
- RT 和 PT 演习尽管提供了一种客观的安全测试方法，但鉴于系统更改、攻击、漏洞利用尝试、扫描等的数量，很难衡量。垃圾进 = 垃圾出 成为环境中发生许多更改的问题。 在红队活动期间，很难衡量这些活动的级联效应和相关的安全计划有效性
- RT 和 PT 演习无法跟上持续交付和分布式计算环境的步伐。 今天的产品软件工程团队可以在 24 小时内交付多个产品更新，这超过了进行有效的红队演习所需的时间段。 在演习中获得的结果的相关性可能会因系统可能已发生根本性变化而降低。
- RT 和 PT 技术缺乏足够的自动化能力来增强现代设计模式中的变化。 自动化流程为任何信息安全策略增加巨大的价值。 但是，自动化也可能让安全人员陷入虚假的安全感。 增加的自动化可能会导致自满和难以控制的复杂性，从而更难以看到“全局”。
- RT 和 PT 演习缺乏对过去发现的持续评估以识别损坏
万恶之源：回顾过去
在我们深入研究混沌工程及其向安全实验的演变之前，请考虑一个简单的问题：“数据泄露通常来自哪里？”
上面的图表来自 Ponemon Institute 的 2017 年数据泄露成本研究，显示恶意或犯罪攻击占 2017 年数据泄露的 47%。 这是网络安全行业中最常见的关注领域，包括高级持续性威胁、零日攻击、网络钓鱼活动、民族国家攻击、恶意软件变种等。
图表的其他两个部分包括人为错误 (28%) 和系统故障 (25%)，两者加起来占 2017 年数据泄露的 53%。 解决方案的格局和网络安全的常见定义主要只关注整个问题的 47%：恶意或对抗性攻击。 大多数人认为恶意和犯罪活动比人类和机器犯的错误更有趣。
人为错误和系统故障是数据泄露的主要原因。 这不是一种新趋势； 这种情况已经持续了大约八年。 除非我们开始以不同的方式思考，否则它不太可能改变。 为什么我们似乎无法减少每年的安全事件和漏洞数量，即使我们在安全解决方案上花费更多？ 你可以说，如果网络安全行业更加关注人为因素和系统故障，许多恶意活动就会失败。 例如，如果没有安全控制覆盖范围内的配置错误或失败的安全技术解决方案，许多恶意或犯罪攻击就不可能发生。 但是，由于缺乏关于恶意攻击与人为因素或系统故障作为根本原因之间关系的始终如一的可靠信息，因此很难证明这种论点。
失败：是摧毁的武器，还是构建的工具？
图片由 WikiMedia Commons 提供
理解我们在构建、运行和改进系统过程中失败所扮演的角色，是理解人为错误和系统故障的核心。事实上，失败也是人类生活的重要组成部分，因为它是我们学习和成长的途径。考虑到“人非圣贤，孰能无过”，认为我们构建系统的方式是完美的，也是不切实际的。
失败总是会发生
2018年1月13日上午8点07分，夏威夷州通过紧急警报系统和商业移动警报系统，在电视、广播和手机上发布了一条虚假的弹道导弹警报，警告称有弹道导弹威胁来袭，并建议居民寻找避难所。警报总结说：“这不是演习。”然而，该州并未授权或启动民防户外警告警报器。
混沌工程的根源在于失败始终存在，而我们如何应对失败是我们的选择。混沌工程由 Netflix 的 Chaos Monkey 推广，它是一门新兴学科，旨在主动以受控方式触发故障，以确保系统将以我们期望的方式响应故障。回想一下“希望不是策略”，仅仅希望你的系统完美运行并且不可能失败，不是一种有效或负责任的策略。
结合安全性和混沌工程
在将混沌工程应用于网络安全时，重点是识别人为因素和系统故障如何直接影响我们构建和保护的系统的安全性。如前所述，在信息安全领域，我们通常只有在安全事件被触发后才能了解安全或系统故障。事件响应阶段为时已晚；我们必须更主动地识别安全能力及其保护的系统中的失败。
混沌工程超越了传统的故障测试，因为它不仅涉及验证假设。它还可以帮助我们探索可能发生的许多不可预测的事情，并发现我们固有混沌系统的新属性。混沌工程使用一系列受控实验来测试系统应对真实世界事件的能力，例如服务器故障、防火墙规则错误配置、格式错误的消息、关键服务降级等。简而言之，混沌实验——或者就此而言，安全实验——必须遵循四个步骤
- 根据可测量的输出来识别和定义系统的正常行为
- 制定关于正常稳定状态的假设
- 根据您的假设设计实验，并将其暴露于真实世界的事件
- 通过比较稳定状态和实验结果来彻底测试假设
备份总是有效
备份总是有效；你必须担心的是恢复。灾难恢复和备份/恢复测试是经典示例，说明如果执行频率不够，影响可能是毁灭性的。您的其他安全控制也是如此。不要等到发现某些东西不起作用；相反，您必须主动将故障引入系统，以确保您的安全性像您认为的那样有效。
开始安全实验和混沌工程的常见方法是了解游戏日演练作为用于计划、构建、协作、执行和对实验进行事后分析的主要渠道所扮演的角色。游戏日演练通常运行两到四个小时，涉及一个工程师团队，他们开发、运营、监控和/或保护应用程序。理想情况下，它们涉及来自这些领域的成员的协作。
安全和混沌实验的例子
我们无法告诉您有多少次重大系统中断是由错误配置的防火墙规则更改引起的。我们愿意打赌这也是许多其他人常见的现象。
熟能生巧
目的是在受控的安全实验中引入失败，通常是在游戏日演练期间，以确定您的工具、技术和流程检测失败的效率，哪些工具提供了导致检测到的见解和数据，数据在识别问题中的用处，以及最终，系统是否按照您认为的方式运行。
那些走上混沌工程之路的人最常见的反应是“哇，我没想到会这样！”或“我不知道它是这样工作的。”
混沌工程和安全实验都需要对它们的原理和基础有扎实的理解，并专注于培养该学科的成熟度。举例来说，您永远不会开发一个实验并直接在生产环境中运行它，而首先不在较低的环境（例如暂存环境）中测试任何工具、实验等。首先培养在执行实验所需的方法和工具方面的能力和信心。
从小处着手，手动操作。如果您的假设是正确的，请自动化实验
James Hamilton & Bill Hoffman, 互联网规模服务的设计与部署
- 预期失败。组件可能随时崩溃或停止。依赖组件可能随时失败或停止。将会出现网络故障。磁盘空间将会耗尽。优雅地处理所有故障。
- 保持简单。复杂性滋生问题。简单的事情更容易做对。避免不必要的依赖。安装应该简单。一台服务器上的故障不应影响数据中心的其余部分。
- 自动化一切。人会犯错；人需要睡觉；人会忘记事情。自动化流程是可测试、可修复的，并且最终更可靠。尽可能自动化。
红队 (RT) 和紫队 (PT) 与安全实验
- 安全实验的目标和意图与红队或紫队演练不同。其主要目标是主动识别由人为因素、不良设计或缺乏弹性引起的安全故障。RT 或 PT 演练的目标是利用系统中的弱点。
- 安全实验基于简单、隔离和受控的测试，而不是涉及数百甚至数千次更改的复杂攻击链。这些小的、孤立的更改的目的不仅是为了专注于测试，还要直接识别问题。当您同时进行大量更改时，很难控制爆炸半径并将信号与噪声分开。
- 安全实验的意图是通过仪器化构建一种围绕您的企业安全系统如何工作的学习文化。虽然实验通常从小规模开始，并在暂存环境中手动执行，但目标是在给定实验中建立足够的信心，以自动化并在生产系统上运行它。
- RT 和 PT 演练主要关注恶意攻击者或对抗性方法，而安全实验则关注失败和人为因素在系统安全中的作用。
- RT/PT 和安全实验相互补充，通过提供关于组织如何改进其安全实践的真实、可操作和客观的数据。
- 安全实验试图解释现代系统复杂的分布式特性。这就是为什么更改必须简单、范围小、随着时间的推移自动化并在生产中运行的原因。
想了解更多吗？在 Twitter 上关注@aaronrinehart和@AWeidenhamer来加入讨论。
[请参阅我们的相关文章，开发者需要了解的关于安全性的知识。]
评论已关闭。