精华观点 软件供应链安全
从国内外政策标准框架来看,软件供应链安全主要关注供需两方,在具体环节上,供方包括软件全生命周期的计划、开发、构建、测试、发布环节;需方涉及软件全生命周期的部署、运维和监测环节。
--------------------------------------------------------------------------------------
以下为正文
关键信息基础设施是经济社会运行的神经中枢,保障关键信息基础设施的安全对于维护国家安全和社会公共利益具有重大意义。2024 年 7 月 19 日,美国网络安全公司“众击”(CrowdStrike)的软件更新错误引发大规模的微软 Windows 系统蓝屏,直接导致全球范围的航空、金融、医疗等重要行业领域关键信息基础设施中断运行。本文立足供应链安全视角,对“微软蓝屏”事件的成因及影响开展分析,剖析事件相关方在软件供应链上下游的不足。该事件反映出政策标准执行不到位将导致严重的软件供应链安全风险,且相关风险会在各类关键信息基础设施应用中持续累积和放大。就短期而言,对软件供应链安全的管理从意识到实践尚存在巨大的鸿沟。应从多层面加强软件供应链安全实践,以期系统性提升关键信息基础设施韧性,有力保障重要行业领域关键信息基础设施稳定运行。
一、链式反应,剖析“微软蓝屏”事件放大效应
近年来,SolarWinds 和 Log4j2 等软件供应链安全事件层出不穷,使得软件供应链的安全问题成为全球热点。2024 年 7 月 19 日,“众击”公司的终端安全软件 Falcon 在自动更新时引入了疏于测试的配置文件,导致全球范围的 Windows 系统蓝屏,是一起灾难性的由上游软件故障触发下游业务崩溃的软件供应链安全事件。与以往事件不同,“微软蓝屏”事件根源不在于恶意攻击,而在于供应链上游微小的软件缺陷,且事件的影响范围更广,破坏力更大,直接导致全球性的关键信息基础设施(以下简称“关基”)系统故障和大规模业务崩溃。这一事件标志着软件供应链安全问题成为全球重大命题,其中暴露出的安全风险和隐患,亟需引起重视和思考。
(一)事件对软件供应链下游的影响
事件对软件供应链下游的主要影响情况如表1所示,其直接引发了全球 850 万台 Windows 设备系统崩溃蓝屏,数十个国家的航空、金融、医疗等行业的业务系统受到影响甚至陷入瘫痪。从系统、业务及经济社会等方面来看,事件影响主要呈现出三个特征:一是关基业务系统大范围暂停服务,造成航班停飞、金融交易停止及医疗活动中断等灾难性后果;二是部分关基系统长时间停止运行,事件发生 5 天后,仍有 3% 的蓝屏设备未恢复运行,直到第 10 天左右才基本恢复;三是产生持续的经济损失及社会负面影响,事件导致“众击”公司面临来自多方的追责和诉讼,并在航空、金融和医疗等行业造成潜在经济损失接近 1000 亿美元。
表1 “微软蓝屏”事件对供应链下游的影响
(二)事件的供应链上游成因
导致本次灾难性事件的根源在于“众击”公司的一款安全软件 Falcon,Falcon 部署于终端操作系统的本地检测引擎,能够按照预定义的模板加载解析云端提供的威胁情报,以辅助提升其本地检测能力。Falcon 对预定义模板的更新导致了大规模蓝屏事件,其详细过程如图1所示。
图1 “微软蓝屏”事件过程分析
模板更新。2024 年 2 月 28 日,为实现对“进程间通信(IPC)新型攻击”技术的检测能力,“众击”公司开发了一种具有 21 个参数字段的云端威胁情报模版(以下简称“IPC 模板”)。以 IPC 模板定义的威胁情报实例(以下简称“IPC 威胁情报实例”)会通过编号为 291 的“通道文件”传送至 Falcon 本地检测引擎进行加载。但值得注意的是,同期更新的 Falcon 本地检测引擎(7.11版本)所集成的代码只能够解析 IPC 威胁情报的前 20 个参数字段。
测试上线。“众击”公司开展了对 Falcon 本地检测引擎的发布测试以及对 IPC 模板类型的压力测试等多层构建验证,并在 2024 年 3 月 5 日通过了相关测试。但在实际测试过程中,测试用例使用了通配符对第 21 个参数进行匹配,事实上忽略了对第 21 个参数的测试,使得 IPC 模板参数数量不匹配这一问题未暴露出来。
上线运行。自 2024 年 3 月 5 日 IPC 模板功能更新上线至 2024 年 7 月 19 日事件发生前,“众击”公司至少下发了 3 条 IPC 威胁情报实例。同样,由于这些实例均采用了通配符对第 21 个参数进行匹配,因此期间并未引起系统崩溃。
事件发生。2024 年 7 月 19 日,“众击”公司额外增加了两个 IPC 威胁情报实例,其中一个实例的第 21 个参数为非通配符匹配,并通过“通道文件 291”下发更新。此时,只能解析 20 个参数的 Falcon 本地检测引擎尝试访问第 21 个参数时,出现了超出数据数组末尾的越界内存读取问题,导致系统蓝屏崩溃。
事后应对。事件发生后,“众击”公司从多个方面进行应对,一是联合微软开展事件处置和系统修复,对遭遇系统蓝屏的用户提供技术支持;二是修复问题代码,在本地检测引擎代码中添加了边界检查、验证模板类型输入等功能;三是完善测试流程,使用非通配符条件匹配对每个字段进行测试,并聘请两家独立的第三方软件安全供应商对 Falcon 代码和端到端质量控制及发布流程进行进一步审查。
由此可见,IPC 模板参数数量不匹配导致的内存越界访问问题是本次事件的罪魁祸首,而此类微小错误可以通过校验 IPC 模板类型中的字段数量或对输入字段进行运行时数组边界检查等常见测试流程加以避免。
(三)供应链对上游问题具有放大效应
一般而言,导致 Windows 系统蓝屏的应用软件代码逻辑错误时有发生,但很少造成大范围影响,而此次“微软蓝屏”事件却导致如此灾难性影响,这是多方面因素共同作用的结果:一是在于“众击”公司自身,其对 IPC 模板问题疏于检测,顺利通过测试并在实际生产系统堂而皇之地运行了超过 4 个月时间,最终在增量更新 IPC 威胁情报实例时导致问题爆发;二是在于 Windows 系统加持,Windows 系统在桌面操作系统的市场占有率超过 70%,同时 Windows 的桌面版与服务器版均是基于 Windows NT 通用核心开发,为 Falcon 的驱动程序提供内核层面的访问权限,使其代码错误会导致桌面和服务器 Windows 系统同时蓝屏崩溃;三是在于“众击”公司产品在海外行业的深度应用,其产品覆盖金融、交通和医疗等数十个行业领域的重要企业,而这些企业对于“众击”公司安全软件的更新过程和内容不具备选择控制权,同时也没有自身的分阶段部署及回滚机制。
以上原因中第二点和第三点可视为供应链上游问题的放大器,即来自供应链上游的微小单点错误,在高市场份额及行业深度应用的加持下,放大为导致供应链下游用户大规模系统崩溃和业务失效的灾难性事件(如图2所示)。
图2 “微软蓝屏”事件供应链放大效应
二、全链审视,洞察关基软件供应链安全的挑战与启示
为应对当前全球软件供应链的不确定性和潜在风险,多国都发布了一系列政策标准要求。美国作为供应链安全战略的先行者,将供应链安全列入多份国家级战略文件,从早期重视 ICT 供应链、网络空间供应链演进到重点关注软件供应链。围绕软件供应链安全相继推出 3 道行政令、7 组法律框架、8 套标准和 10 余项指南文件,包括EO14028《关于改善国家网络安全的行政命令》《软件供应链安全指南》及软件安全开发框架(SSDFV1.1)等加以层层落实。总体上,美国软件供应链安全要求呈现出从战略到标准,从概念到实践的快速深化过程,持续引领全球范围的软件供应链安全领域的认知、方法和应用。欧盟相继出台了《欧盟理事会关于 ICT 供应链安全的结论》、NIS2 指令以及《网络安全弹性法案》等顶层政策,从供应商管理、供应链风险管理实践、经济运营者主体安全义务责任等多方面对欧盟供应链安全进行规范。
整体而言,我国的软件供应链安全体系尚处于起步阶段。《关键信息基础设施安全保护要求》《网络安全审查办法》从顶层政策方面对关基行业软件供应链安全提出要求;国家标准《信息安全技术 ICT 供应链安全风险管理指南》《软件供应链安全要求》提出软件供应链安全风险管理、组织管理和供应活动管理的具体要求,防范软件供应链中的供应关系风险。从国内外政策标准框架来看,软件供应链安全主要关注供需两方,在具体环节上,供方包括软件全生命周期的计划、开发、构建、测试、发布环节;需方涉及软件全生命周期的部署、运维和监测环节。
此次事件中,问题主要定位于供方的测试环节以及需方的部署环节(如图3所示)。“众击”公司作为供方,暴露了其在软件测试环节存在不充分和不规范问题,而各行业领域的关基运营者多作为需方角色存在,暴露了其在部署环节对安全产品更新过程缺乏控制问题。关基是我国网络安全的重中之重,其软件供应链安全问题不容忽视,应从“微软蓝屏”事件汲取经验启示,为做好关基软件供应链安全工作提供借鉴。
图3 “微软蓝屏”事件在软件供应链安全框架中的问题定位
关基运营者对其重要软件缺乏自有风险控制机制,软件供应链安全韧性不足。一是过度依赖单一供应商。国外部分关基行业对 Windows 及“众击”公司等产品高度依赖,这些产品发生问题会对关基业务系统造成严重影响,但由于缺乏替代备用产品和多系统并行运行策略,使得业务系统难以快速恢复。二是对具有内核权限的软件更新缺乏控制权。为使安全产品能在系统启动早期介入,以检测和防御高级威胁,微软允许第三方安全软件进行内核级访问。然而关基运营者对于安全软件的自动更新过程不具备控制权,引入的缺陷或逻辑错误极易破坏系统内核运行的稳定性。三是缺乏分阶段的风险防范措施。关基运营者对于关键软件缺乏分阶段的更新策略,未能遵循从测试环境、小范围生产系统到大范围生产系统逐阶段更新,不具备在发现问题时快速停止更新或回滚的能力,以致事件对生产系统造成了灾难性影响。这种缺乏替代、控制不力、恢复缓慢的现状,反映出关基软件供应链整体韧性不足的问题。
关基运营者缺少清晰的软件供应链安全实施路线指引,对软件供应链安全的管理从意识到实践尚存在巨大的鸿沟。如前文所述,国内外已有一些推荐性的安全标准,例如美国国家标准与技术研究院(NIST)发布的《确保软件供应链安全:面向用户》,明确了用户需在产品更新升级前执行产品的安全测试;我国发布的国家标准《网络安全技术—软件供应链安全要求》(GB/T 43698-2024)中同样也对软件供应链供需双方提出了具体要求,如要求需方应确保软件来源的多样性,并对所获取软件进行全面安全检测和风险评估。由于相关标准缺乏强制性,关基运营者对于如何做好软件供应链安全实施缺乏指引,思路不清。短期来看,关基运营者从建立软件供应链安全的管理意识到形成最佳实践尚存在巨大鸿沟。
单一供方的供应链安全改善只是杯水车薪,缺乏关基领域软件供应链安全的整体规划。此次事件发生后,“众击”公司在事后处置阶段,开展了应急处置、代码修复以及测试完善等措施以改善自身的供应链安全管理。然而,“众击”公司仅为关基运营者众多供应商之一,单家供应商做好自身供应链安全管理难以直接提高关基运营者的供应链安全水平,也不代表关基运营者软件供应链各类安全隐患会随之消除。考虑到关基运营者软件构成数量庞大、种类复杂,其对软件供应链安全风险控制能力不足的局面将会长期存在,这些风险也会在各类关基应用中持续累积。因此,为系统性提升关基软件供应链安全性,亟需国家、行业和关基运营者通力配合,既做好顶层规划,也做好落地实践,从整体上主动提升关基行业领域软件供应链安全。
三、前车可鉴,构建关基软件供应链安全防护体系
在中央网信办统筹协调下,公安、安全、保密、密码等有关单位各司其职、分工协作,通过政策统筹、信息统筹、标准统筹、督查统筹、人才统筹等“五个统筹”工作,形成了关基保护的良好局面。如前所述,关基软件供应链安全已成为影响国家安全和全球竞争力的关键因素,建议在国家层面统筹推进关基软件供应链安全战略,以政策标准为支撑,以技术系统为手段,系统提升关基韧性。
(一)国家战略引领,行业试点先行,形成关基供应链安全整体规划
立足关基安全保护要求,建议加快推进国家层面的软件供应链安全战略、政策框架制定。在统筹规划中,建议以保障关基安全稳定运行为核心目标,构建形成多方协同配合的关基软件供应链安全管理关系(如图4所示)。国家监管部门统筹协调保护工作部门、标准制定机构、相关测评机构,形成从软件和服务供应商、关基运营者、关基保护工作部门至国家监管部门逐级上报垂直管理的模式,标准制定机构和相关测评机构协同支撑关基运营者和关基保护工作部门对软件和服务供应商进行规范和评估。在具体实施过程中,充分考虑不同行业特点和差异,鼓励行业内优势单位作为先行者,探索形成可复制、可推广的软件供应链安全管理最佳实践,实现软件供应链安全管理的规模化推广,以期形成多方协同保障关基软件供应链安全的局面,系统性提升关基行业领域供应链安全水平,构建更加稳固的关基安全保护防线,从整体上降低关基供应链安全风险。
图4 关基软件供应链安全管理各角色分工建议
(二)做好政策标准协调,指引关基软件供应链安全保护实践
政策制定者宜用好各类推荐性软件供应链安全标准,在政策制定时明确引用标准及条款,形成具备较强操作性的政策。标准制定者宜强化各类标准的应用导向,以实际需求牵引国家标准的制修订工作,同时充分考虑不同行业的特殊性,鼓励行业主管部门和研究机构结合实际情况制定行业标准和实践指南,为关基软件供应链安全保护实践提供方法指引。此外,建议鼓励安全产业提升软件供应链安全的供给能力,使得要求、能力与供给相匹配,促进软件供应链安全产业生态协调健康发展。
(三)技管结合,补足软件供应链短板,增强关基系统韧性
面对软件供应链的复杂性,关基运营者作为关基保护的责任主体,宜主动落实各方要求,牵引供方共同加强软件供应链安全建设,并通过管理与技术手段相结合的策略来增强关基软件供应链的安全性和适应力。一是构建全生命周期的软件供应链管理体系。做好供需双方的制度管理、人员管理、知识产权管理等,在软件供应链的各阶段实施有效的风险管理和质量保证措施。二是建设关基软件供应链风险分析平台。以成分分析为抓手,摸清软件供应链家底,构建软件供应链安全知识图谱,并识别软件潜在安全漏洞,支撑风险评估和决策。三是提升关键软件供应多元性。加强关键软件供应商的多样性和可替代性,确保关键软件和组件的持续供应;四是强化关键软件管理。实现对关键软件全生命周期的管理和监控,重点加强对具备内核权限软件的过程管理,从而保障关基核心系统的稳定性;五是精细化风险控制。对于各类软件进行分类分级和分阶段风险控制策略,及时发现并解决潜在问题,并确保系统在故障时具备快速恢复能力。综上,通过管理技术相结合的体系化运营,使得关基运营者持续识别和修复自身不足,不断增强关基软件供应链安全保障能力,强化关基业务及系统韧性。
(本文刊登于《中国信息安全》杂志2024年第7期)