我们有多少人曾经说过以下这句话：“我希望这能行得通！”？
毫无疑问，我们大多数人都说过，可能不止一次。 这句话并不能激发信心，因为它揭示了我们对自身能力或我们正在测试的任何东西的功能的怀疑。 不幸的是，这句话非常贴切地定义了我们传统的安全模型。 我们的运作基于假设和希望，即我们部署的控制措施——从 Web 应用程序的漏洞扫描到端点上的防病毒软件——可以阻止恶意行为者和软件进入我们的系统并损坏或窃取我们的信息。
渗透测试采取了一步来对抗依赖假设，它通过积极尝试闯入网络、将恶意代码注入 Web 应用程序或通过发送网络钓鱼电子邮件来传播“恶意软件”。 渗透测试由查找和戳破我们不同安全层中的漏洞组成，但它无法解释主动打开漏洞的情况。 在安全实验中，我们有意创建混乱，以受控的模拟事件行为的形式，客观地衡量我们检测和阻止此类活动的能力。
“安全实验为分布式系统安全性的实验提供了一种方法，以建立对承受恶意条件能力的信心。”
当涉及到安全性和复杂的分布式系统时，混沌工程社区中一句常见的格言重申“希望不是一种有效的策略”。 我们多久会主动衡量我们设计或构建的东西，以确定控制措施是否正在失效？ 大多数组织直到安全事件因该失败而发生时才发现其安全控制措施正在失效。 我们认为“安全事件不是侦查措施”和“希望不是一种有效的策略”应该是 IT 专业人员有效安全实践的座右铭。
行业传统上强调预防性安全措施和纵深防御，而我们的使命是通过侦查性实验来推动对安全工具链的新知识和见解。 由于如此关注预防机制，我们很少尝试超出一次性或年度渗透测试要求来验证这些控制措施是否按设计执行。
由于现代分布式系统中所有这些不断变化的无状态变量，人类几乎不可能充分理解其系统的行为方式，因为这可能会随时变化。 解决此问题的一种方法是通过强大的系统工具化和监控。 对于安全工具化，您可以将域分解为两个主要类别：测试和我们称之为实验的东西。 测试是对先前已知结果的验证或评估。 简而言之，我们知道我们要寻找什么，然后再去寻找它。 另一方面，实验旨在获得以前未知的新的见解和信息。 虽然测试对于成熟的安全团队来说是一项重要的实践，但以下示例应有助于进一步阐明两者之间的差异，并更具体地描述实验的附加价值。
示例场景：精酿啤酒配送
考虑一个简单的 Web 服务或 Web 应用程序，它接受精酿啤酒配送的订单。
对于这家精酿啤酒配送公司来说，这是一项关键服务，其订单来自客户的移动设备、Web 以及来自供应其精酿啤酒的餐厅的 API。 这项关键服务在该公司的 AWS EC2 环境中运行，并被公司认为是安全的。 该公司去年以优异的成绩通过了 PCI 合规性认证，并每年执行第三方渗透测试，因此它认为其系统是安全的。
这家公司还以其 DevOps 和持续交付实践而自豪，有时甚至在同一天部署两次。
在了解了混沌工程和安全实验后，公司的开发团队希望持续不断地确定其安全系统对现实世界事件的弹性和有效性，并进一步确保他们不会向系统中引入安全控制无法检测到的新问题。
团队希望从小处着手，评估端口安全性和防火墙配置，以了解它们检测、阻止和警报 EC2 安全组上端口配置错误更改的能力。
- 团队首先总结他们对正常状态的假设。
- 为他们的 EC2 实例中的端口安全性开发一个假设
- 选择并配置 YAML 文件以进行未经授权的端口更改实验。
- 此配置将指定要随机选择的目标对象，以及应更改的端口范围和端口数。
- 团队还配置了何时运行实验并缩小其爆炸半径的范围，以确保最小的业务影响。
- 对于第一次测试，团队选择在其阶段环境中运行实验，并运行一次测试。
- 以真正的游戏日风格，团队选举了一位灾难大师在预定义的两小时窗口内运行实验。 在此时间窗口内，灾难大师将在其中一个 EC2 实例安全组上执行实验。
- 游戏日结束后，团队开始进行彻底、无责的验尸分析，重点是实验结果与稳态和原始假设的对比。 问题类似于以下内容
验尸分析问题
- 防火墙是否检测到未经授权的端口更改？
- 如果检测到更改，是否被阻止？
- 防火墙是否向日志聚合工具报告了有用的日志信息？
- SIEM 是否针对未经授权的更改发出警报？
- 如果防火墙未检测到更改，配置管理工具是否发现了更改？
- 配置管理工具是否向日志聚合工具报告了良好的信息？
- SIEM 最终是否关联了警报？
- 如果 SIEM 发出警报，安全运营中心是否收到了警报？
- 收到警报的 SOC 分析师是否能够对警报采取行动，还是缺少必要的信息？
- 如果 SOC 警报确定警报是可信的，安全事件响应是否能够轻松地从数据中进行分类活动？
对系统中失败的承认和预见已经开始揭示我们对系统工作方式的假设。 我们的使命是将我们所学到的知识更广泛地应用，开始真正主动地解决安全漏洞，超越当前主导传统安全模型的被动流程。
当我们继续探索这个新领域时，我们将确保发布我们的发现。 对于那些有兴趣了解更多关于研究或参与其中的人，请随时联系 Aaron Rinehart 或 Grayson Brewer。
特别感谢 Samuel Roden 在本文中提供的见解和想法。
[请参阅我们的相关报道，DevSecOps 这个术语有必要吗？]
评论已关闭。