新闻资讯
当前位置:

WP.29 ISO/SAE 21434 蓝图 -合规漏洞管理操作指南(二)

发布时间:2021-01-18  /  浏览次数:204 次

为了让整车厂奠定满足UNECE WP.29和第7.2章节中规定的基础,漏洞管理需要针对漏洞如何进行评估,缓解和持续监控制定完善的流程和政策。

在2020年6月25日,UNECE宣布批准了一项史无前例的车辆网络安全法规,该法规概述了新的网络安全管理流程和安全措施,要求制造商必须在其组织内和车辆中满足相关规定,从而获得车型许可认证。该法规适用于乘用车、面包车、卡车、公共汽车和拖车,并已在欧盟、日本和韩国制定了实施时间

漏洞评估

这是如何分析风险和漏洞,以确定它们对汽车组件的影响(生产前和生产后)的过程。这个过程通常包括以下步骤:

      软件组件展现

通过二进制分析和供应商软件清单报告共同形成一套针对电子控制元件、网关、关键单元等部件的安全物料清单(S-BoM)。

         威胁情报收集

大多数组织都会在NIST国家漏洞数据库上跟踪发布的已知公有漏洞(CVE)

这可以理想的通过自动化风险检测的解决方案,例如Cybellum来实现。Cybllum通过自动化的生成数字孪生工程来进行安全分析,其数字孪生工程包括详细的安全组件清单,底层架构映射,操作系统,配置信息,控制流,API调用信息等。

威胁情报的收集和分析本身就是一项具有挑战性的任务,而自动化可以令这项任务变得更加有效。理想情况下,我们应该跟踪多个不同的来源(例如:NIST NVD、GitHub问题跟踪器、JVN、CN-NVD等区域性数据库和暗网黑客论坛等)连同其他专有数据库(如:第三方或私有)。所有的舆情数据必须持续地聚合、规范和分析,以支持持续安全开发工作和生产后的安全监控

         漏洞评估

为每个软件组件形成一套可疑公开漏洞列表。这是通过将安全组件物料清单中的特征与相关漏洞或漏洞利用方式的威胁情报进行互相关联而生成的。整车厂/供应商通常将标准CVE数据库和通用漏洞利用数据库用于漏洞匹配。

         专有代码分析

为补充漏洞评估的覆盖范围,实践建议整车厂/供应商对专有软件(从第三方获得的软件与许可和内部开发的软件)进行漏洞分析。这种漏洞评估可能会暴露出专有软件中可能被利用的编码弱点,并使攻击者能够进行远程代码执行,或执行拒绝服务攻击,从而最终使黑客可以控制或导致对应产品崩溃。

由于有数百甚至数千个公开漏洞可能会影响到各种车辆组件,因此必须对威胁进行优先处理,并对最有可能反复出现的漏洞进行预先防范和整改。

漏洞修复&缓解

一旦潜在的风险被识别和评估,无论是在生产前还是汽车出场之后,都必须在合理的时间范围内解决网络风险和漏洞。对于每个影响您产品的漏洞(无论是组件还是整车漏洞),都必须设计、执行和记录对应的整改和补救的计划。应该为每个不同的漏洞清晰的记录对应的漏洞状态类型:

待处理

这是暴露漏洞的默认状态,后续将决定如何处理它们。

可修复的

通过修复代码来进行漏洞整改。通过开发团队或外部供应商使用软件包更新或补丁来实施对应漏洞的修复。

漏洞缓解

开发团队或外部供应商使用软件编译缓解工具或配置更改(如:禁用守护程序,修改的防火墙配置等)进行漏洞缓解

已知确认风险

漏洞没有被消除,但是被设定为可以不进行修复的合理已知风险

漏洞跟踪

漏洞跟踪能力是满足WP.29和ISO/SAE 21434漏洞管理要求的一个关键原则。它包括记录漏洞相关负责人,漏洞的状态,以及支持漏洞缓解方案的任何技术和商务依据。

这将作为未来的参考依据,用来支持后续的合规审计工作,并且能够在风险等级发生变化时进行持续监测活动。

漏洞监控

这是UNECE WP.29网络安全法规中漏洞管理准则中的关键环节,也是ISO / SAE 21434标准中重要的一部分。漏洞管理流程应该是一个持续的管理监控过程,哪怕是在车辆上市后,也应该对潜在和已有的安全风险进行持续监控。

事件响应

一旦车辆上路,网络安全事故通常由产品安全事故反应小组(PSIRT)处理。在这种情况下,通常会发生以下和漏洞管理相关的活动:

            根源分析

目的是找出该漏洞进入生产的原因,并评估该漏洞可能对组件/车辆造成的损害。

            闭环分析

在设计、开发和测试过程中识别所有可能的漏洞缓解措施过程,这些措施将阻止此类漏洞以及其它类似的漏洞在将来给车辆或车载软件带来的潜在风险。

虽然没有法规和标准强制要求,但当网络安全事件发生时,产品安全团队将希望进行漏洞影响分析模拟,以便在其他产品和开发项目中主动发现类似问题。

由于车辆网络威胁相关的风险和成本在车辆出厂后明显较高,整车厂和供应商应该创建一个实时的(或接近实时的)自动化,可伸缩的持续监测流程,且将其引入到他们的资产管理和OTA软件更新系统中,这样可以将识别受漏洞影响的产品过程和推出修复程序所需的时间最小化。

下面的政策常用于支持漏洞管理流程

         筛选政策

一旦掌握了有风险的组件或车辆的各种漏洞和缺陷的威胁情报,就必须对其进行分析处理。为了关注危害性更高安全风险问题,需要基于不同的漏洞属性设置一个阈值,以确定将对哪些漏洞进行进一步分析。

公有漏洞(CVEs)

以下是进一步分析公有漏洞所需的最小基础属性的例子(但每个组织可能可能会根据需要进·行

攻击向量(AV)= 临近的

攻击复杂度(AC) -很低(L)

特权要求(PR) -无

用户交互(UI) -无(N)

范围(S) -不变(U)

保密性(C) /完整性(I) /可用性(A) -其中之一

专有软件缺陷

这些缺陷是根据其潜在的影响进行的分类。作为参考的标准,应进一步审查所有由于用户或外部输入而可能导致应用程序出现问题的公有缺陷(CWE),但是整车厂(OEM)及其供应商应制定对应的政策,以匹配他们对潜在威胁形势的了解。

上报政策

漏洞上报流程定义了问题上报到内部开发小组和外部供应商的流程。

关于CYBELLUM

贯穿整个汽车生命周期,Cybellum赋予整车厂和供应商大规模安全评估和减轻安全风险的能力。我们的无代理安全解决方案可扫描嵌入式软件组件,而无需访问其源代码。它能够揭露网络安全漏洞和对应政策法规的违例,并为您在软件开发和SOP后的漏洞管理流程中提供补救的可操作性建议。

作为整车厂和供应商,您将受益于软件供应链的全面可视性、安全威胁的优先缓减以及持续的安全风险监控,从而使您能够符合最新的安全标准与法规,并制定完美的安全管理流程。Cybellum已经与全球领先的整车厂和一级供应商建立了合作伙伴关系,并期待与您的紧密合作。