不要只测试现有系统，强大的安全性需要更主动的策略。我们中有多少人曾经说过这样的话：“我希望这能奏效！”？毫无疑问，我们大多数人可能不止一次说过这句话。这句话并不是为了激发信心，而是揭示了对我们自己的能力和我们目前正在测试的功能的怀疑。不幸的是，这句话很好地描述了我们传统的安全模型。我们假设我们实施的控制措施（从Web应用程序扫描到设备上的防病毒软件）可以防止恶意病毒和软件进入我们的系统并破坏或窃取我们的信息。渗透测试通过主动尝试闯入网络、将恶意代码注入Web应用程序或通过发送网络钓鱼电子邮件传播病毒来避免我们对假设的依赖。由于我们发现和利用不同安全级别的漏洞，因此手动测试无法解决主动打开漏洞的情况。在安全实验中，我们故意在受控情况下制造混乱，模拟事故场景，客观地测试我们发现和预防此类问题的能力。“安全实验为分布式系统的安全实验提供了一种手段，以建立对其抵御恶意攻击能力的信心。”当涉及到分布式系统的安全性和复杂性时，混沌工程社区的一句名言需要反复重申，“希望不是有效的策略”。我们多久主动测试我们设计或构建的系统以确定我们是否失去了对它的控制？大多数组织直到发生安全事件时才发现他们的安全控制失效。我们认为，“安全事件不是侦查措施”和“希望什么都不发生不是有效的策略”应该成为IT专业人员实施有效安全实践的口号。该行业传统上强调预防性安全措施和纵深防御，但我们的使命是通过检测实验将新知识和新见解引入安全工具链。由于专注于预防机制，我们很少尝试多次或每年手动测试所需的安全措施，以验证控制是否按设计执行。随着现代分布式系统中的无状态变量不断变化，人们可能很难完全理解系统随时间变化的行为。解决这个问题的一种方法是通过强大而系统的仪器。对于安全测试，您可以将这个问题分为两个主要方面：测试，以及我们所说的实验部分。测试是对我们已经知道的东西的验证和评价。简单来说，我们需要在开始寻找之前弄清楚我们要寻找的是什么。另一方面，实验是关于发现我们以前不知道的见解和知识。虽然测试是成熟安全团队的重要实践，但以下示例将有助于进一步说明差异并更恰当地描述实验的附加值。示例场景：精酿啤酒考虑一个用于接收精酿啤酒订单的Web服务或Web应用程序。对于这家精酿啤酒运输公司来说，这是一项重要的服务，订单来自客户的移动设备、网页，以及通过为该公司精酿啤酒提供服务的餐厅的API。这项重要的服务在公司认为安全的AWSEC2环境中运行。公司去年顺利通过了PCI规则，每年都会邀请第三方渗透测试，所以公司相信系统是安全的。该公司对其DevOps和持续交付工作感到自豪，有时一天部署两次。在了解了混沌工程和安全实验之后，该公司的开发团队希望持续确定他们的安全系统对现实世界事件的有效性和弹性。同时，确保它们不会将安全控制无法检测到的新问题引入系统。该团队希望，在小范围内，评估端口安全和防火墙设置将使他们能够检测、阻止并警告他们对EC2安全组上端口设置的错误配置更改。该团队首先总结了他们对正常情况的假设。假设EC2实例中的端口安全性。为未经身份验证的端口更改实验选择和配置YAML文件。此配置从所选目标中随机化对象，并且更改端口的范围和数量。该团队还设置了运行实验的时间并缩小了暴力攻击的范围，以确保对业务的影响最小。对于第一个测试，该团队选择在他们的测试环境中运行实验并运行单个测试。在真正的比赛日风格中，该团队选择了灾难大师在预先计划的两个小时窗口内运行实验。在该窗口期间，DisasterMaster将在EC2实例安全组中的一个实例上运行实验。比赛日结束后，团队将开始进行彻底的、无责备的事后分析。它的重点是稳态和原始假设的实验结果。问题类似于以下内容：事后分析问题防火墙是否检测到未经授权的端口更改？如果检测到更改，是否会阻止更改？防火墙是否将有用的日志信息记录到日志聚合工具中？SIEM是否警告未经授权的更改？如果防火墙没有检测到未经授权的更改，配置的管理工具是否看到了更改？配置管理工具是否向日志聚合工具报告合理的信息？SIEM是否最终关联了警报？如果SIEM发出警报，安全运营中心是否会收到警报？收到警报的SOC分析师是否能够根据警报采取行动，或者是否缺少必要的信息？如果SOC确定警报是真实的，安全事件响应是否可以简单地根据数据进行分类活动？对我们系统中故障的承认和预期已经开始揭示我们对系统如何工作的假设。我们的使命是将我们学到的知识应用到更广泛的领域。这样才能真正做到主动解决安全问题，超越当前传统主流的被动处理问题的安全模式。随着我们继续探索这个新领域，我们一定会公布我们的研究结果。如果您有兴趣了解有关该研究的更多信息或想参与其中，请随时联系AaronRinehart或GraysonBrewer。特别感谢SamuelRoden对本文的见解和想法。
