查看原文
其他

欧盟网络安全局发布《供应链攻击威胁全景图》报告(下)

ENISA 代码卫士 2022-05-23

 聚焦源代码安全,网罗国内外最新资讯!

编译:代码卫士



专栏·供应链安全

数字化时代,软件无处不在。软件如同社会中的“虚拟人”,已经成为支撑社会正常运转的最基本元素之一,软件的安全性问题也正在成为当今社会的根本性、基础性问题。


随着软件产业的快速发展,软件供应链也越发复杂多元,复杂的软件供应链会引入一系列的安全问题,导致信息系统的整体安全防护难度越来越大。近年来,针对软件供应链的安全攻击事件一直呈快速增长态势,造成的危害也越来越严重。


为此,我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯,分析供应链安全风险,提供缓解建议,为供应链安全保驾护航。


注:以往发布的部分供应链安全相关内容,请见文末“推荐阅读”部分。



今年7月,旨在提升欧洲整体网络安全水平的欧盟网络安全局 (ENISA) 发布了《供应链攻击威胁全景图》报告,分九个部分全面介绍了供应链相关情况,如下:

1、引言

2、什么是供应链攻击?

3、供应链攻击的生命周期

4、典型的供应链攻击

5、供应链事件分析

6、并非所有攻击都叫供应链攻击

7、建议

8、结论

附录A:供应链攻击总结

本文为第三部分的内容。



5. 供应链事件分析


本节分析了2020年早期至2021年7月报道的供应链攻击。分析关注的是公开已知供应链攻击,附录提供了详细的概述。如之后我们将要谈到的,某些攻击看似是供应链攻击但并非如此,因此分析中并未提到这些攻击。表12总结了本报告中分析的所有安全事件。

表12:总结所识别出的、分析的以及验证的供应链攻击(2020年1月至2021年7月初)


5.1 供应链攻击的时间线

分析表明,在24起已证实的供应链攻击中,8起(33%)在2020年报道,16起(66%)在2021年1月至2021年7月初报道。基于该数据,趋势预测认为2021年将发生的供应链攻击数量将是2020年的4倍。

图表8展示了本报告所分析攻击的时间线,突出了归咎于APT组织的安全时间以及它们产生的全球性影响或区域影响。每起攻击中的影响被归为全球性或区域性。如果客户遍布全球或者可能影响的终端用户数以百万计,则认为攻击具有全球影响。而如果攻击影响的客户位于某个特定区域或国别,或者仅影响少数用户,则认为攻击具有区域影响。

图表8:从2020年1月至2021年7月初报道的供应链攻击的时间线。图表中的“月份”指的是事件被报道的月份而非攻击发生的月份。被归咎于APT组织的事件以黑点标注,具有全球影响的事件以紫色点标注,具有区域影响的事件以绿色点标注。每个事件的详细总结可参见附录。


5.2 了解攻击流

图表7中的每起安全事件均根据本报告中提出的分类系统分析、总结和分类。该分类系统支持以结构化方式将供应链攻击作为整体进行研究。

图表8是桑基图,说明了最常见的攻击技术流以及在供应链攻击中观察到的资产。攻击技术 [ST] 用于攻击供应商资产 [SA],进而用于攻陷客户资产 [CA] 的攻击技术 [CT] 中。

从图表8中可知,用于攻陷供应商(第一栏 [ST])使用的最多攻击技术是:

  • 未知的(66%),其次是

  •  利用软件漏洞 (16%)

从所针对的供应商资产(第二栏[SA])来看,多数攻击的目的是攻陷:

  •  代码 (66%)

  • 数据 (20%)

  • 流程 (12%)

受陷的供应商资产用作攻陷客户的攻击向量。这些攻击多数通过如下方式完成(第三栏 [CT]):

  • 滥用客户对供应商的信任 (62%),或者

  • 使用恶意软件 (62%)

不同于所使用的攻击技术,多数供应链攻击旨在获得对如下内容的访问权限(第四栏 [CA]):

  • 客户数据 (58%);

  • 关键人员 (16%) 以及

  • 金融资源 (8%)

图表9:基于本报告提出的分析系统分析供应链事件。桑基图描述的是针对供应商资产[SA]的攻击技术[ST],之后被用于攻陷客户资产 [CA] 的攻击技术 [CT]。当这种关系出现在更多数量的供应链攻击中时,多种元素之间的连接宽度就会加宽。



5.3 目标导向的攻击者

说到定向攻击,在66%的所分析事件中,攻击者关注的是供应商代码以进一步攻陷目标客户。关注攻击者目标数据的事件占比20%,关注供应商内部进程的事件占比12%。这对于了解网络安全防护措施的关注点至关重要。组织机构应当将精力放在验证第三方代码和软件上,确保二者未遭篡改或操控。

这些软件供应链攻击针对的的最终客户资产似乎主要是客户数据,如个人数据和知识财产。这种情况在所分析的供应链事件中占比58%,其次是其它资产如人员、软件和金融资源。

5.4 用于攻陷供应商的多数攻击向量仍未知

分析发现,在所分析的66%的供应链攻击中,供应商并不了解它们如何遭攻陷的过程,或者对此并不完全了解。与之相反,少于9%的受陷客户并不了解攻击是如何发生的。这说明供应商和面向终端用户的企业之间的网络安全事件报告成熟度之间存在差距。

考虑到83%的供应商位于技术行业,缺乏对攻击如何发生的知识或者说明对供应商基础设施的网络防御成熟度较低或者分享相关信息的意愿较低。造成缺乏了解的结果还有其它因素,包括攻击的复杂度和深度以及发现攻击的速度缓慢,因此阻碍了调查进展。

5.5 归咎于APT组织的复杂攻击

超过50%的供应链攻击归因于为人熟知的网络犯罪组织,包括APT29、APT41、Tallium APT、UNC2546、Lazarus APT、TA413和TA428。分析显示这些APT组织似乎稍微倾向于具有区域性影响的目标,大量攻击的目标是获得对客户数据的访问权限。

从分析的24起攻击事件来看,10起未归因于某特定组织。未归因的主要原因可能是其中7起攻击发生在过去7个月内。这类事件可能需要更长的时间进行调查,而且在某些情况下,仍然无法归因。然而,鉴于这些攻击的复杂性,供应商应该会遭到有组织的网络犯罪组织攻击并应做好相应准备。


6、 并非所有攻击都叫供应链攻击


从2020年1月至2021年7月初,很多安全事件最初看似是供应链攻击或被认为很可能是未来供应链攻击的一部分。找到的很多传统软件漏洞曾被认为是未来供应链攻击的“风险”。虽然某些案例涉及的漏洞被认为是故意放在软件或硬件种的,但后来发现是 bug 或无心之过。由于这些事件中并不涉及正被攻陷的供应商,因此不被视作供应链攻击。

在至少三种情况下,攻击者攻击的是软件库或依赖关系。在其中一种案例中,2020年12月报道,攻击者将恶意包上传至 RubyGems 仓库。2021年3月出现了一起类似报道,安全研究员设法使用被认为是组件或知名企业使用的基础设施的名称,上传了恶意 NPM 包。第三个案例在2021年4月报道,攻击者上传恶意NPM包,试图在被称为“品牌劫持“的攻击中故意假冒为人熟知的软件包。在所有这些案例中,攻击者未攻陷现有软件包或软件仓库本身,并未对供应商资产发动明确攻击,因此我们认为它们并非供应链攻击。

在很多情况下,虽然发现了软件漏洞但并未用于攻击中,或者证实是错误而非故意引入。第一个例子在2020年2月报告,安全研究员在Xiaongmai 开发的用于DVRs、NVRs 和IP摄像头的固件中发现了一个0day。其它例子包括2021年5月报道在Visual Studio Code 扩展中发现多个漏洞,2021年6月报道在基于Pling 的免费开源软件 (FOSS) 市场中发现多个漏洞。在所有这些案例中,虽然发现了漏洞,但在本文成稿时并未发生利用这些漏洞的活跃攻击。如在之前章节中提到的,供应链攻击至少涉及两起攻击,即针对供应商的攻击和针对客户的攻击。如果缺少针对供应商或客户的攻击,则攻击不被视作供应链攻击。

此外,其它一些网络安全攻击和漏洞也不能被视作供应链攻击。比如针对 Centreon 系统的攻击。Centreon 公司提供IT监控服务和开源软件IT监控工具。2021年1月,攻击者利用过时的公开 Centreon 实例攻陷客户的基础设施。攻击者被指为 Sandworm APT 组织,被发现时该攻击已持续三年的时间。该攻击旨在提取受影响客户的信息,并且针对的是法国的IT提供商。这起案例讲述的是某个特定的软件漏洞在客户安装的软件中遭利用。然而,供应商本身并未遭攻陷而且漏洞也并非故意引入。


7、 建议

供应链攻击利用的是全球市场的互联性。当多个客户依赖的是同一个供应商时,针对该供应商的网络攻击后果就被放大,从而可能造成大规模的国家影响甚至是跨境影响。对于某些产品而言,如软件和可执行代码,供应的存在并不透明甚至对终端用户是完全隐藏的。终端用户软件直接或间接依赖于由供应商提供的软件。这类依赖关系包括软件包、库和模块——所有这些此前都用于降低开发成本并加快交付时间。

组织机构防御网络攻击做得越好,攻击者对供应商的关注就越多。很简单,供应商正在成为供应链的最薄弱链条。同时客户要求产品的网络安全性更高同时成本维持在低水平,但这两种需求并不一定总能同时满足。

从我们观察到的多起供应链攻击事件中可知,组织机构越来越意识到需要评估供应商的网络安全成熟度以及这种客户-供应商关系带来的风险暴露程度。客户需要评估并考虑供应商产品的整体质量及其网络安全实践,如供应商是否应用了安全开发流程。此外,客户应当在筛选并审查供应商过程中以及因管理这些关系而导致的风险过程中进行更多的尽职调查。

管理供应链网络安全风险,客户应当:

  • 识别并记录供应商和服务提供商的类型;

  • 为不同的供应商和服务类型定义风险标准(如重要的供应商和客户依赖关系、关键软件依赖关系、单点失败);

  • 根据业务可持续性影响评估和要求评估供应链风险;

  • 根据良好实践定义风险管理措施;

  • 根据内部和外部信息来源以及供应商的性能监控和审计研究结果,监控供应链风险和威胁;

  • 使客户人员意识到风险的存在。

管理和供应商的关系,客户应当:

  • 在产品或服务的整个生命周期内管理供应商,包括处理已达生命周期的产品或组件的程序;

  • 把与供应商共享或者供应商可访问的资产和信息进行分类,并定义访问和处理的相关程序;

  • 定义供应商在保护组织机构资产,共享信息,审计权利,业务持续性,人员筛选,以及处理事件中的责任、通知义务和程序中的义务;

  • 定义所购买产品和服务的安全要求;

  • 在合同中包括所有这些义务和要求;就分包规则和潜在的级联要求达成一致;

  • 监控服务性能和开展定期安全审计,验证协议中的网络安全要求一致性;包括对事件、漏洞、补丁、安全要求等的处理;

  • 获得供应商和服务提供商关于未包括已知的隐藏特性或后门的保证;

  • 确保考虑到发规和法律要求;

  • 定义管理供应商协议变更的流程,如工具、技术等的变更。

从另一方面来看,供应商应当确保产品和服务的安全开发和普遍认同的安全实践一致。供应商应当:

  • 确保用于设计、开发、制造和交付产品、组件和服务的基础设施遵循网络安全实践;

  • 执行和普遍认可的开发进程一致的产品开发、维护和支持流程;

  • 执行和普遍认可的安全实践一致的安全工程流程;

  • 基于产品类别和风险考虑技术要求的应用性;

  • 向客户提供关于多项已知标准的一致性声明,如 ISO/IEC 27001、IEC 62443-4-1、IEC 62443-4-2(或特定标准如关于云服务的CSA云控制矩阵 (CCM)),以及确保并以最大程度证明产品的完整性及产品中使用的开源软件的来源;

  • 定义质量目标如缺陷的数量或外部发现的漏洞或外部报告的安全问题,并以此作为改进整体质量的工具;

  • 维护关于软件代或组件的准确及时数据,以及关于应用于软件开发流程中内部和第三方软件组件、工具和服务控制的准确及时数据;

  • 定期审计,确保实施如上措施。

此外,和任何构建于或基于易受漏洞影响的组件和软件的产品或服务一样,供应商应当执行良好的漏洞管理实践,如:

  • 监控由内部和外部资源报告的、包括第三方组件中的安全漏洞;

  • 使用漏洞评分系统(如CVSS)对漏洞进行风险评估;

  • 根据风险设立处理已识别漏洞的维护策略;

  • 通知客户的流程;

  • 验证和测试补丁,确保满足运营、安全、法律和网络安全要求,以及补丁和非内置第三方组件兼容;

  • 安全补丁交付的流程和向客户推送补丁的文档,或

  • 参与漏洞披露计划,包括报告和披露流程。

供应商应当以补丁的形式管理漏洞。同样,客户应当监控市场上是否出现潜在漏洞,或从供应商接收各自的漏洞通知。良好的补丁管理实践包括:

  • 维护资产清单,包括补丁相关的信息在内;

  • 使用信息资源识别相关的技术漏洞;

  • 评估已识别漏洞的风险,提供可记录和执行的维护策略;

  • 仅从合法来源接收补丁并在安装前进行测试;

  • 如补丁不可用或不适用,则采取其它措施;

  • 应用回滚程序和有效的备份及恢复流程。

除了客户和供应商自身可采取的措施外,也可从行业层面采取一些措施。2021年6月,谷歌引入端对端框架 SLSA,在整个软件供应链中确保软件工件的完整性。SLSA的目标是提升行业尤其是开源状态,防御最急迫的完整性威胁。尽管SLSA 关注软件供应链攻击而非所有的其它攻击类型,但这可能是使组织机构受益的良好开端。

2021年6月,MITRE 发布了更加通用但更全面的应对网络安全威胁的建议:MITRE D3FEND 项目。该项目是一个框架或结构化知识库,可使组织机构找到特定缓解措施以阻止 MITRE ATT&CK 框架中出现的特定攻击。该项目并不特定由于供应链或APT攻击,但可应用其中的建议提升组织机构的基础安全水平。

不过,并非所有的供应链风险均可通过客户、供应商或组织机构执行的良好实践进行缓解。具体而言,硬件组件中隐藏的功能和未记录的访问能力(后门)无法通过最常见的认证或标准的渗透测试全部发现。另外,0day 漏洞如仅由某个特定组织知道和使用的漏洞仍然是一个挑战。于是,国家甚至是欧洲作为一个整体都应该采取措施。国家主管机关可评估供应链风险的国家安全风险,将已知组织考虑在内,在国家层面出台关于供应商的措施。此外,供应链攻击可能由具有高阶能力的国家黑客资助,而在这种情况下,可能需要相关机构协助缓解受国家支持的攻击的风险。


8、结论

随着攻击保护良好的组织机构的成本增加,攻击者偏向于攻击其供应链,而这成为造成大规模和跨境影响的额外动机。这一前已导致报告的供应链攻击案例数量多于以往,预计2021年发生的供应链攻击数量将是2020年的四倍。当前供应链的内在全球性本质增强了这些攻击的潜在影响,拓宽了恶意人员的攻击面。本报告涵盖了大量已知攻击,但在现实中未被检测到的、未经调查或未归因的供应链攻击数量可能更多。

尤其在软件中,供应链攻击破坏了软件生态系统中的信任。本报告中提到的安全事件说明恶意人员可能会从最早期阶段(开发阶段)攻陷软件供应链。需要开发新方法从设计上确保供应链的安全。从这个方向来看,新举措如谷歌 SLSA 和 MITRE D3FEND 看似一片光明。

本报告分析表明,在所调查的事件中仍然存在大量未知元素。用于供应商的66%的攻击向量仍然未知。缺乏透明度或调查能力为供应链的信任带来了严重风险。改进透明度流程和问责是改进供应链中所有元素安全性和保护最终客户的第一步。

供应链攻击可能是复杂的,要求进行仔细策划并通常需要数月或数年的时间执行。虽然超过50%的攻击归因于APT组织或为人熟知的攻击者,但供应链攻击的效果可能使供应商成为其它更常见的攻击者的未来目标。因此,组织机构不仅应关注自身而且还应关注供应商安全,这一点至关重要。对于云服务提供商和管理服务提供商而言尤为如此,近期发生的攻击活动说明了这些行业需要实施网络安全控制。

随着互相依赖和复杂性的增加,针对供应商的攻击可能会产生深远影响。不仅是因为受影响方数量庞大,而且,尤其是在机密信息被泄露的情况下,会引发国家安全风险或地理政治后果。

在这个复杂的供应链环境中,从欧盟层面建立良好实践和协调措施以帮助所有成员国发展类似能力以实现同一水平的安全性都很重要。


附录 供应链攻击总结

(略,详见原文链接)

——报告END——








推荐阅读
欧盟网络安全局发布《供应链攻击威胁全景图》报告(上)
欧盟网络安全局发布《供应链攻击威胁全景图》报告(中)
在线阅读版:《2021中国软件供应链安全分析报告》全文开源软件 Nagios 曝11个漏洞,可使IT 基础设施遭接管引发供应链攻击Apache OpenOffice 漏洞使数千万用户易受代码执行攻击谷歌资助OSTIF审计8个重要开源项目,提升软件供应链安全
【BCS2021】软件供应链完整演讲回看
美国政府召开网络安全峰会,与私营行业巨头合力提振软件供应链和开源等安全





原文链接

https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks


题图:Pixabay License



本文由奇安信编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。




奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

    觉得不错,就点个 “在看” 或 "赞” 吧~



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存