利用自动生成的出口策略打击供应链违规行为

Last updated 15 2 月, 2023 by Aleck Brailsford

从最近的安全事件中，我们再次看到，通过分段限制出口流量是防止攻击的有效方法。针对Solarwinds漏洞事件，FireEye建议企业“对安装了SolarWinds软件的服务器或端点封锁互联网出口”。¹

网络安全行业目前尚无有效的解决方案来防止这种攻击。我们可以假设，未来的攻击也有类似的复杂性，因为事实证明它对攻击者是有效的。

限制出口很容易实施，但却很少有企业这样做，这是为什么呢？

根据客户的反馈，常见的答案是“成本太高”。

当防火墙保护着一个大型子网时，限制出站流量显然非常困难，因为防火墙内部有许多服务器想要连接到另一侧的许多其他端点。安全经理要评估所有通过防火墙的连接，并判断哪些是必要的，哪些应该被阻止，这是一项无比艰巨的任务。

firewall policy

由于CDN的动态特性，企业不可能管理一系列被允许的目标IP地址，即使按FQDN（DNS名称）来做也很困难 – 安全经理将不得不定义他们自己的应用程序所需要的端点的整个允许列表。

几家安全厂商提出了下面两种替代方案，但它们并不能防止上述复杂问题：

1. 定义IP地址或DNS名的拒绝列表：这一要求是对那些为了绕过拒绝列表而更改IP地址和DNS名称的黑客的无休止的追逐。即使厂商从中央管理平面 (如 MISP), 更新列表，他们也无法防止零日漏洞，直到为时已晚。
2. 使用下一代恶意软件检测：这在一定程度上是有效的，但黑客在不断改进他们的技术，将他们的非法连接伪装成合法连接，因此无法保证防火墙能够检测到不良连接并阻止它们。

更糟糕的是，即使有人能够定义出口端点的允许列表，它也会很快失效，因为应用程序总是随着新功能和端点依赖关系的变化而发展。

因此，问题实际上归结为策略管理而不是执行：我们如何定义合法出口DNS名称的允许列表？

我们认为，有效控制出口流量是可能的。要做到这一点，我们需要一种不同的安全策略管理方法。

首先，我们需要缩小范围。虽然不可能为整个VLAN定义一个出口策略，但对于单个服务器（更理想情况下单个工作负载），应该比较容易。像Kubernetes和Serverless这样的微服务架构是理想选择。

server security policy

其次，手工编写安全策略是不可行的。它太难维护，也无法随着应用程序的频繁变更而扩展。

因此，我们应该通过监控应用程序的行为来自动学习策略，而不是手动编写策略。

但这里有一个矛盾：如果您正在监控以自动生成策略的流量的工作负载已经受到了损害，那么您就会学习到一个坏的连接。

为解决这个问题，我们建议在开发过程的早期自动学习安全策略，例如，在运行集成测试时。这些策略应该由相对少量的被允许出口端点组成。开发人员和安全团队可以很容易地对它们进行审查，确保将渗透测试或类似活动从学习模式中排除，以避免学习不良模式。

ci/cd workflow

第三方软件也应该附带这样的策略，策略可以由软件商以同样的方式生成。

我们称之为“不可变策略”。它们在生产环境中永远不会被修改，只有在每次修改应用程序时才会自动生成，然后完整地铺展到生产中。这些策略是软件不可分割的一部分，对于每个应用程序都应该是强制性的。

不可变”的字典定义：

不可变：不会随着时间的推移而改变

我们对“不可变策略”的定义

不可变策略：自动生成的最低权限安全策略，只有在部署应用程序时才会更新

在极端情况下，比如Solarwinds漏洞，代码本身被攻击者修改，所以即使是自动生成的策略也会包含恶意的出口连接。这也能预防吗？

我们认为是可以的。当受保护资产的范围较小时，可以很容易地审查工作负载中的每个出口连接并批准它，就像我们做代码审查一样（把策略想象成代码）。

对于感染病毒的二进制文件，您会看到不同的出口策略。一个新的连接会弹出，审查员应该很容易检测到它是一个可疑的连接。

制定出口策略，只允许访问必要的和经过验证的目标。

这些策略应该像Kubernetes工作负载一样，处于更细的级别。由于每个工作负载都有相对较小的外部连接范围，因此定义出口限制要容易得多，也可持续
使用自动化来学习策略。

学习应用连接，为每个Kubernetes服务生成有效的入口和出口连接策略。
在开发周期中尽可能早地学习策略。

应该在应用测试期间学习应用策略，以便生成可以提交到代码仓库的策略定义。然后，这些代码可以作为CI/CD管道的一部分部署到生产中。