微软威胁矩阵不是雷神之锤

从人脸识别、垃圾邮件检测到自动驾驶、人工智能和机器学习技术已经广泛渗透到我们的日常生活，并进一步威胁到我们的隐私、财产甚至生命。这并非危言耸听，因为机器学习的普遍应用也引发了对抗性攻击，这是一种通过向算法“投喂”精心设计的“对抗样本数据”来操纵算法行为的攻击方式。

针对人工智能系统的对抗性攻击轻则可以谋财，重则能够害命，例如通过下图中的样本，研究人员能够诱使自动驾驶系统将停车标志识别为限速标志：

由于针对机器学习系统的对抗性攻击与日俱增，上周末微软发布了一个基于ATT&CK框架的机器学习威胁矩阵（https://github.com/mitre/advmlthreatmatrix），能够帮助安全专业人员检测和补救针对机器学习系统的攻击。

微软指出，过去四年来针对商用机器学习系统的攻击显著增加。通过更全面地了解机器学习威胁矩阵，安全团队可以开始实施缓解策略，以保护其服务器集群免受威胁。

对抗性机器学习威胁矩阵的灵感来自ATT&CK框架  

来源：微软

与ATT＆CK框架类似，机器学习威胁矩阵涵盖了针对机器学习的网络攻击中通常涉及的各个阶段，以及攻击者在每个阶段所采用的策略。组织可以使用矩阵来了解其攻击面，信息安全专业人员可以使用矩阵中的战术和技术来改善组织机器学习系统安全边界的监控策略。

微软研究人员在官方博客文章指出：“对抗性机器学习威胁矩阵的目标是将对[机器学习]系统的攻击定位在一个框架中，让安全分析人员可以锁定新的和即将到来的威胁。”

对于机器学习和人工智能系统的安全人员来说，微软的威胁矩阵无疑是武器库中的一件重器，但它会是完美无瑕的吗？我们如何正确看待企业发布的ATT&CK威胁矩阵？

也许我们需要回顾一下微软的第一次“ATT&CK模仿秀”。

早在今年4月，微软Azure安全中心发布过一个基于MITER ATT＆CK模型的Kubernetes威胁矩阵（https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/），汇总了Kubernetes中运行的环境所特有的策略和威胁，而Kubernetes是当今云原生应用程序构建者使用的最受欢迎的容器编排平台。

Azure Kubernete威胁矩阵将MITER ATT＆CK框架的攻击策略适配并转化为Kubernetes面对的挑战。例如，在MITER ATT＆CK矩阵中，“对计算机的初始访问”转换为Azure矩阵中的“对群集的初始访问”，反映了该访问涉及的不同技术。Azure的矩阵是捕获传统IT安全与云原生安全之间的差异以及横向扩展安全性的主要里程碑。

但是，平台工程师和安全运营团队不能完全依赖Azure的Kubernetes威胁矩阵。尽管Azure的Kubernets矩阵使企业安全团队可以沿用企业IT安全思路来理解Kubernetes安全，但是Kubernetes的很多特定结构在传统IT环境中是不存在的。而且，Kubernets威胁矩阵是全新的框架，并不一定能够覆盖安全研究人员不断发现的新的Kubernetes漏洞。

例如，在最近发现的威胁CVE-2020-8555中使用的技术未被捕获到Kubernetes的Azure MITER ATT＆CK威胁矩阵中。该漏洞使攻击者可以将Kubernetes控制面的访问权限升级到托管云环境，从而有可能从连接到托管环境的服务中访问敏感数据。

对于Kubernetes上的应用程序，威胁和风险向量可以分为两个主要区域：

这应该是熟悉的领域，但是与传统的整体应用程序有明显的区别。设计运行在Kubernetes环境中的应用程序是分布式的，并且由多个临时活动部件组成，这些临时活动部件具有不同的风险和威胁特征，通常由第一方和第三方组件和工具的组合制成。

这些风险和威胁与以下因素相关：

• 与软件供应链、开发和持续集成（CI）相关的风险以及用于部署到集群中的交付自动化和持续交付（CD）工具链。CI和CD都是软件供应链中的初始访问点，可将威胁引入集群；

  
  

• Kubernetes基础设施自动化工具，例如应用程序和基础设施监视以及微服务生命周期自治控制器；

• 有权在集群内执行操作的人工操作员（DevOps/站点可靠性工程人员）。

以下，我们一起来“遍历”Azure Kubernetes威胁矩阵中缺少的重要安全元素。在下面这个矩阵中，粗体项目是Azure Kubernets矩阵中没有的，值得注意的威胁：

资料来源：Gadi Naor

Azure威胁矩阵遗漏的一个值得注意的组件是“命令与控制”（C2）威胁类别，该类别在原始的MITER ATT＆CK矩阵中可以找到。事实证明，C2仍是Kubernetes用户关注的问题，它应该是Kubernetes威胁矩阵的一部分。

Kubernetes高度依赖DNS作为其服务发现的关键基础架构。建立隐蔽通道的常见做法是利用DNS协议消息交换中的固有弱点。因此，监视Kubernetes群集内的DNS活动非常重要，可以检测并有可能阻止C2建立隐蔽通道。

Azure Matrix在权限提升方面也存在差距。最新的CVE显示，攻击权限可以从节点提升到整个群集，也可以从群集提升到托管云环境。准入控制器和Kubernetes operator也可能遭到侵入，就前置安全性而言这是不可省略的。

Azure Matrix中缺失的另一点是Kubernetes威胁的持久性。攻击者可以直接在节点上启动容器，而Kubernetes不会管理容器，这对于DevOps来说是一个盲点。如果攻击者破坏了准入控制器，他们还可以将恶意代码注入任何一个容器中。最后，攻击者可以将脚本插入容器生命周期挂钩中来执行并持续进行攻击，这是一种Kubernetes机制，可以在预定的时间点运行脚本。