甲方应如何检查和缓解供应链攻击风险?

作者:Sender Su  来源:原创内容  发布日期:2024-01-13  最后修改日期:2024-01-13

之前的供应链攻击事件中,被各路媒体反复翻炒的太阳风事件无疑是夜空中最耀眼的星。那么如果要防范供应链攻击,要怎样做?

article banner

笔者:国际认证信息系统审计师、软考系统分析师

很多网络安全分析、咨询服务机构都曾对供应链攻击发表了大量介绍和讨论的文章,但在笔者看来要么过于抽象,要么只着眼于软件供应链一种情况,干脆自己全面小结一下。

全文5千字,阅读本文需要有一定网络安全管理基础,了解等级保护要求。

正确理解供应链攻击风险

在解析供应链安全的风险评估和风险缓解措施前,要先熟悉什么是攻击向量

话说网络安全行业的名词新解确实是多,比如“向量”,本意是“具有大小和方向的量”,放到网络安全领域一般理解为“网络犯罪分子用于入侵或渗透受害者拥有的网络环境的方法组合”。

但在笔者认为,这个理解失去了向量的原意,应该理解为“基于安全漏洞而实现入侵或渗透受害者网络环境的方法和严重性”,其中的“方法”即向量的方向属性,“严重性”即向量的大小属性,具体一点就是如果攻击得手时会达到的破坏程度

为达成有效的攻击,攻击者需要通过社交工程、恶意软件、网络钓鱼、自动漏洞扫描等方法收集目标的信息,并基于收集到的信息识别出可能的攻击向量,然后利用现有攻击或专门创建新工具,利用攻击向量完成攻击过程。

常被讨论的网络安全漏洞:身份失陷、传输暴露、代码缺陷、以及包括供应链攻击等等,都是攻击向量中的方向属性。

由于网络安全业界长期偏向攻防技术的探讨,仅讨论攻击向量的方向属性而脱离了向量的大小属性,导致供应链攻击的危害性曾经长期被忽视。

为何脱离大小属性?

因为这是来自于甲方自身业务的属性。常规情况下的网络安全服务商作为乙方并不介入甲方业务,难以判断和衡量。

所以防范供应链攻击的工作更主要是落在甲方自己。

供应链攻击的严重性

供应链攻击最大的特点是它所构成的风险的复杂性。复杂性导致供应链攻击的危害性也比其他攻击向量严重得多。

就如我们在第一点中指出的,供应链攻击向量的大小属性是和甲方业务直接关联,这就会把供应链攻击从单纯是网络安全的语境扩大到业务领域,并引出了一个关键问题:

防御供应链攻击,需要和业务上的供应链管理、供应商管理协同吗?

笔者作为信息系统审计师(CISA),专业领域本来就包括了业务和信息化相结合的审计要求。所以这个问题的答案在我这是明确的:

必须协同。

但从现在网络安全管理要求和实务来看,大部分甲方内部要做到这两者的协同还需要很长一段时间。这是因为甲方业务人员对于供应链攻击这个词的理解,基本都只会停留在“这是IT的事,与业务无关”。

但供应链攻击绝不仅仅是信息技术的事。在甲方管理和业务运行过程中牵涉到的构成上下游延伸的相关方,都可能构成供应链攻击的因素。

必须注意的是,“相关方”表面上主要是上游,但不能忽视下游。供应链攻击所利用的上下游关系并不是水流那么简单:

信息流必然是双向流动的。

无论甲方内部网络安全和信息安全策略多么复杂,但如果未妥善管理供应商,盲目信任供应商,随意授权供应商访问敏感数据,由此形成的供应链攻击的后果的严重性,时至今日应该不用多解释。

如果供应商的服务是甲方业务的直接支撑,或者甲方自己就是产业链下游的重要服务/产品提供者,供应链攻击的严重性就更甚于一般情况。

有效评估供应链安全风险

“态势”也是一个被用烂了的词。网络安全行业用词就一如互联网企业那些“赋能”、“对齐”,颇有嘴里不蹦出这几个词就不是自己人的感觉。

言归正传。网络安全审计关键点是甲方视角,从甲方视角对供应链攻击进行风险评估,先要跳出攻防技术范畴,理清其风险特性,是复杂性化繁为简的必要过程。

基于信息技术的语境,供应链安全有广义和狭义之分。狭义仅指网络安全攻击向量中的供应链攻击;广义则是指对甲方业务运行构成影响的供应链安全态势。

这里会进一步引出供应链管理和供应商管理两种不同的概念。

供应链管理着眼于从供应商接收原材料或服务,到向客户交付产品或服务的端到端过程。供应商管理则侧重于在更广泛的供应链内的供应商关系的管理。

良好的供应商管理可以提升供应链管理的效率,且能同步提升防范供应链攻击的能力。

基于在第二大点中指出的,应把供应商管理和防御供应链攻击协同进行的观点,从审计角度出发,甲方在使用基于业务影响分析(BIA)的方法执行对供应商管理的业务风险评估时,应同时纳入供应链攻击风险因素,进行综合评估。

设计和实施风险缓解

实话说供应链攻击的风险是非常难以缓解的----仅甲方自身的网络安全风险缓解就已经足够难,难到让基于理性的网络安全责任人都会以“必然被攻破”作为工作底线,倒推如何才能履职尽责。

所以供应链攻击的风险缓解也不可能脱离这种底线思维。既然可以通过风险评估确定供应链攻击的严重性,那么也就应该从相同的角度设计和执行缓解方法。

按此倒推,甲方应在参考成熟的供应链风险管理框架实践和网络安全管理要求的同时,从供应商管理的角度,制定供应商管理政策和供应商风险管理计划,设计有针对性的供应链风险评估项目和相应的风险缓解措施。

鉴于这个角度已经超出了网络安全范畴,需要上升到甲方治理层推动部门横向联动才可能把把风险缓解措施落地实施。

clip

典型检查点和缓解措施

在笔者经验而言,主要聚焦于网络安全的供应链风险管理,可以从至少以下8个方面设计检查点,实施评估和执行相应的风险缓解措施,有条件时可扩展到非网络安全范畴。

这里给出的只是作为读者的思考提示,篇幅所限不可能尽列。在实际评估时,还要充分发散扩展,力求全面覆盖自身的供应链情况。

1、供应商网络安全合规
合规并不一定等同于安全性有效,但它是构建整体安全的基础。该项可包括以下检查点:

1)供应商是否已经按法律法规等合规要求实施了必要的网络安全管理相关措施?
2)供应商是否达到了符合自己要求的,甚至超越了自己能实施的网络安全管理级别?
3)供应商在其他方面的安全管理是否实现了合规?

缓解措施可包括:

1)制订可施加于供应商的安全策略和制度,设定服务水平协议(SLA)条款,通过合同要求供应商实现网络安全合规以及其他方面的安全管理合规。
2)规范合同签订前的流程,按安全策略和制度对合同内容实施相应的控制条款。
3)安排专职人员执行供应链风险总览管控,重点在合同执行期间的控制,包括持续监控、在出现问题时提前终止执行等。
4)定期进行供应链风险评估,同步提升自身在供应链安全管理上的评估能力和速度。

2、供应链整体影响程度
观察得越远对风险的认识就越深。该项可包括以下检查点:

1)是否具备对上游供应商构成供应链的观察能力?
2)上游供应商提供的产品或服务是否对业务构成重要影响且不可替代?3)下游客户是否对供应商提出网络安全要求或其它安全要求,此类要求能否传递到自己的上游供应商?
4)上游供应商的供给会否受到地缘政治影响而停供?

缓解措施可包括:

1)增强业务产业链情报收集能力。
2)积极寻求替代服务和产品。
3)积极响应和实施安全要求。

3、供应商提供的信息技术产品或服务的安全性
安全性需要通过检验检测和认证实现确认。该项可包括以下检查点:

1)供应商是否提供了经过安全认证的产品或服务?
2)安全认证的有效期是否被良好维持?
3)产品或服务是否有不良记录,尤其是高于平均水平的记录?

缓解措施可包括:

1)确保把产品选型或服务供应商筛选时要核查相关认证的要求纳入到网络安全管理和采购管理。
2)采购前核查相关认证的有效性。
3)必要时设计验证方案(通过第三方机构)进行验证。

4、产品漏洞管理
软件漏洞是供应链攻击的重点利用。该项可包括以下检查点:

1)产品供应商提供的信息技术产品软件部分的溯源是否清晰?
2)供应商的信息技术产品是否应用了SBOM等标准的物料清单规范?
3)供应商的漏洞修补服务时效是否符合自己的要求?

缓解措施我觉得基本上不需要写了,这应该是读者最熟悉的。

但基于太阳风事件,我认为要增加一种措施:正向和逆向的双向代码匹配性审计。正向是指直接对源代码的漏洞审计,而逆向就是从二进制代码逆向为(准)源码的审计,且两者要能匹配。由于源代码经过构建后不一定能100%还原源代码,还有可能其他保护机制,因此需要从静态动态两方面实现运行逻辑的匹配。

由于这个措施涉及到产品提供商的知识产权,甲方直接实施并不适合,且绝大部分甲方都不可能有此类审计能力。所以由专业第三方代码审计机构进行会较好。

5、服务供应商的管理
任何安全管理都必然把要求落到人。该项可包括以下检查点:

1)服务供应商提供的信息技术服务其管理是否遵循了良好的管理框架,比如ITIL等?
2)如果发生错误配置导致授权供应商能特权访问、非故意的供应商人为错误甚至供应商故意窃取数据,能否及时发现?

缓解措施可包括:

1)加强人员培训,尤其是与供应商人员对接的人员应具备足够的敏感性,负责对供应商人员的监督。
2)对服务人员的必要限制措施。
3)服务人员行为记录管理并定期审计。

6、数据安全管理
网络安全问题最终都会趋同为数据安全问题,如何保护自有的知识产权不被盗窃或未经授权的访问。该项可包括以下检查点:

1)是否实现了数据分级分类,鉴别了敏感数据并对应实施了保护措施?
2)是否外包了数据处理服务,服务的执行过程是在场还是离场?
3)在场数据处理如何防止服务商私自传出数据?
4)离场数据处理是否已经对数据采取了必要的脱敏措施?

缓解措施可包括:

1)必须实施数据分级分类,对敏感数据进行重点保护。
2)与数据处理服务商之间必须签订保密协议,且包含有惩罚性条款。
3)实施全覆盖的终端管控,以及出口流量监控。
4)任何数据离场都必须先进行脱敏并经数据所有者核查确认后才允许离场。

7、物理环境安全
业务领域的物理环境安全通常会被归入安全生产领域,需要注意网络安全的性质和安全生产完全不同,这我在之前的文章中也反复强调过。

对物理环境的安全风险评估必须尽可能地扩大评估范围。阴沟翻船是物理环境安全的常有情况。两者的共通点在于物理领域的检查点概念是相同的。比如:

1)物理环境的安全管理服务是否由第三方提供?
2)是否进行了定期的环境风险评估,能清楚辨识各种物理威胁,比如资产被盗、丢失、损毁的风险?
3)对风险评估发现的问题是否及时处置,缓解风险?

缓解措施也是大家都很熟悉的,比如资产造册,跟踪管理,定期盘点等等。

8、物流及信息流安全
物流和信息流共同形成的混合流是供应链管理的复杂性特征。本项实际和第2项即供应链整体影响程度有关联。

如果供应链中的多个实体存储、传输和使用同一种数据,形成多分段、多端点的信息流时,每一个端点都应该同等对待,防范短板作用,尤其是集团化企业内存在供应链关系时。笔者所经历过的集团化企业该问题尤其突出。一些检查点可包括:

1)安全生产管理是否具备制度和实务规范物流运输安全?
2)网络安全管理是否合规并执行了措施确保信息流的传输安全?
3)是否从业务运行管理角度或内部审计角度,具备措施核查物流和信息流之间的匹配性,且措施得以持续执行?
4)集团化企业内是否存在供应链关系,其中有无存在安全短板?

缓解措施诸如物流实时GPS跟踪,信息流强制加密和校验等,这些基本大家都应该是清晰的。笔者认为关键在于持续合规执行和持续审计。

其它支撑

防范供应链攻击的措施在具体落地实践时,会有很多困难。比如缺乏能同时掌握供应商管理和供应链安全管理(尤其是网络安全管理)的人员,缺乏能持续监控供应链风险态势的能力和工具,缺乏衡量风险缓解措施有效性的具体指标等等。

要支撑该项工作,需要积极对接业务、采购、审计、法务、网络安全及信息化等相关职能部门,多方介入,共同评估选择高风险因素优先设计和实施风险缓解措施,逐步完成管理覆盖。

另外,需要配置配置适用于支撑供应链安全管理的工具软件,重点在于配置专门面向供应商安全评估管理的工具软件。使用这种工具的关键目的在于形成对供应链的整体认识,找出短板并针对性地设计风险缓解措施。

有钱的甲方可以定制开发或采购,确实没钱的话,用个EXCEL表自己定义、记录和评定也比啥都没有要好。

其他该有的网络安全软硬件就不详细表述了,但笔者认为,需要有足够的安全情报才能及时应对可能波及整个供应链的风险传递,所以态势感知这一类集成的威胁情报和分析工具是应该投资配置的。

最后

供应链风险态势是持续变化的,因此应参考持续审计的方式进行持续的评估。关于持续审计,我之前有一篇相关的介绍,可以在此概念上扩充为不限于网络安全范畴的供应链安全审计:

甲方需要实施持续的网络安全审计

本栏目相关
  •  2024-11-13 挖深网络安全的兔子洞:CPU 微码补丁管理
  •  2024-11-10 安全加固基准搅合国产操作系统上下游关系
  •  2022-05-11 CIS-CAT 配置评估工具介绍及操作实践
  •  2022-03-16 Windows 系统安全基线及软件工具介绍
  •  2022-08-28 网络攻防中的色彩象征
  •  2022-03-11 安装RHEL/CentOS时如何选择配置安全策略?
  •  2023-02-27 注意:TightVNC 2.8.75 释出,修补 zlib 漏洞 CVE-2022-37434
  •  2022-03-25 从甲方角度介绍“CIS互联网安全中心”
  •  2022-03-17 详细了解微软安全合规工具包(SCT)
  • 本站微信订阅号:

    微信订阅号二维码

    本页网址二维码: