新闻资讯
当前位置:

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

发布时间:2020-12-28  /  浏览次数:128 次

车辆整车厂和他们的供应商越来越依靠软件为自己的产品赋能和推动创新。事实上,现代车辆中大部分包含50-150个电子控制元件,由数千万行的代码驱动组成。这些系统的范围从功能丰富,软件繁重的组件,如,车载信息娱乐系统(IVIs)或者高级驾驶辅助系统(ADAS),到基于汽车开放系统架构(AUTOSAR)的微控制器,用来控制管理刹车系统和其它的对于安全而言至关重要的系统。

随着乘用车和商业车辆逐渐采用自动驾驶技术,并且实现高度网络互联,对软件依赖的趋势在未来几年必然显著增长。

但是随着汽车软件的普及,涌现出越来越多的由于开发人员缺乏安全的编码意识,偶然地编写错误和不充分的程序测试导致的网络安全漏洞。除此之外,整车厂开发人员还可能引入第三方商业和开源框架代码。与此同时,车辆与基于开源框架代码的第三方供应商系统和应用也在时刻进行着交互。根据以上所有的情况来看,使用不安全的软件包将导致日益剧增的潜在安全风险。

风险是真实存在的-研究表明超过70%的汽车软件是基于开源框架开发的(其余的是第三方商业代码或内部开发的软件),仅到2020年9月在NVD就报告了超过12,000个公开漏洞(与去年同期增长了10%),足以表明潜在的软件漏洞已无处不在。暴露和管理软件漏洞是一个非常重大的挑战,尤其是对于汽车产业及其复杂的软件供应链——对于二进制文件(无法获取源代码)汽车开发团队和安全团队无法完好的解决潜在漏洞和安全威胁的影响。

监管机构和制定政策者也同样关注着这些风险,并且推动各种举措管理风险,使网络安全成为汽车供应链不可或缺的一部分,最明显的是UNECE颁布的 WP.29法规和ISO/SAE 21434标准

为了更好的保护客户的安全,满足合规标准并保持竞争力,汽车制造商及其供应商必须将网络安全责任和意识延伸到整个供应链。否则将持续的暴露在长期的违规违例,安全责任索赔,和品牌资产侵蚀等风险中。

什么是汽车漏洞管理?

漏洞管理涉及到很多方面,不过让我们从“不是”这个关键词来展开下面的内容:

1.漏洞管理不是仅在暗网上搜索黑客之间的谈话

2.漏洞管理不是只注意公开漏洞

3.漏洞管理不是在供应商要求时对代码进行补丁修复

4.漏洞管理不是只对源代码进行安全扫描(因为源代码并不是时刻拥有的)

5.漏洞管理不是只进行一次性的模糊/渗透测试,它们可能在短期内会有价值(短期价值有限),但不能处理高度动态的安全威胁

即使拥有源代码,执行二进制代码分析来验证生产级代码的总体安全性是非常重要的,因为在编译和构建时随时可能会出现错误。

上述所有单独的一项做法都是有用的,但都没有达到漏洞管理的预期目的,即实现安全产品的一致开发和有效维护。但在执行所有的正确操作之后,会带来以下好处:

1.生产可以保障车辆运行和人们的生活的安全产品

2.符合相关法规,标准和企业内部政策

3.减少事故响应时间

4.提高您的风险态势

5.减少人工服务的预算以及降低对安全专家的需求

漏洞管理是指在整个车辆生命周期中,对于软件漏洞的暴露、优先级、评估、修复(或减轻影响) 和持续跟踪软件漏洞发展的实践过程。

它涉及到车企的专项资源,明确流程,达成共识的政策和持续运行的安全工具来抵御潜在的网络威胁。 这对于网络安全的最佳实践是至关重要的,随着2022年UNECE WP.29法规的采纳,这一实践将对汽车行业产生更加深远的影响。

本电子指南将帮助您创建有效的漏洞管理操作流程。 它基于Cybellum与全球领先的整车厂及其供应商的广泛合作,旨在帮助车企满足合规性要求的同时,通过有效的拓展漏洞管理来应对不断发展的安全威胁格局。

车企中有两个主要的工作职能负责处理大部分的漏洞管理操作 -

1.产品安全专家

担任开发组织内产品安全方面的核心专家,兼顾增强零部件和车辆安全性的广泛职责范围。

2.项目安全专家

负责特定组件和车辆开发项目的安全管理

在这两个核心职能之上,还有两个职能以不同的形式参与漏洞管理操作流程。产品安全事件响应团队(PSIRT)在汽车生产后期采取行动来缓解潜在安全事件。同时在一些组织中,还有一个内部渗透红队来模拟黑客攻击场景,从而主动的发现组件和车辆的弱点缺陷。

让我们来阐述一下这四种不同的职能的主要职责和他们是如何相互影响的(我们不会深入讨论具体的职位头衔或团队结构,因为这些都取决于企业可用的资源和文化)。

产品安全专家

1.负责组织内所有的产品安全,包括产品的安全培训、文化和治理:

2.明确并监控产品安全政策的遵守情况,以支持“安全产品设计”的理念

3.设定符合相关法规和标准的合规要求

4.评估产品漏洞,并将问题上报至开发团队和外部供应商

5.持续跟踪整个产品生命周期的安全状态,包括跨产品之间的安全影响分析

6.这是一个与开发和运维安全专家共同协作的职位。

一些组织也同时让项目安全专家执行产品漏洞评估,尽管这不是常见的做法。

项目安全专家

1.负责特定开发项目内的产品安全需求

2.明确该项目的网络安全风险目标,并满足公司内部准则和客户要求

3.与开发部门和外部供应商合作进行关于产品设计和架构的安全设计

4.负责针对客户的问题进行“公有漏洞追查”的任务(通常与产品安全专家共同进行)

5.向工程组织内的特定领导团队报告。

产品安全事件响应团队(PSIRT)

1.负责产品SOP后的安全事件响应:

2.分析风险事件数据和问题以评估潜在影响

3.对相关的漏洞进行根源分析以避免再次出现。

与开发团队和外部供应商共同合作制定漏洞缓解计划

管理安全事件响应流程并与公司内部(包括法律部门等)和外部的(黑客或组织机构)的相关责任人进行沟通

在整车厂中,PSIRT很可能包含于已有的车辆安全运营中心(VSOC)之中。

与产品和项目涉及的安全团队联系沟通,以允许在所有项目中采取安全预防措施。

内部渗透红队

1.专注于对私有软件(内部开发或第三方)进行主动的白帽渗透攻击和漏洞分析。

2.使用各种渗透测试技术分析车辆组件,以识别代码编码缺陷

3.向开发团队、外部供应商、项目和产品安全团队上报检测到的潜在安全问题

4.在需要的时候为PSIRT安全事件响应提供支持

5.渗透红队服务通常会外包给整车厂外部供应商,通常(尽管不总是)由产品安全团队进行管理

一旦这些功能到位,整车厂和供应商就有了牢固的组织结构,可以支持开发/SOP阶段前的漏洞管理操作,以及道路上车辆的安全运营和维护。