freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

汽车信息安全风险评估方法探讨
2020-04-07 13:49:02

随着信息技术、互联网与汽车产业的不断融合,汽车信息互联和智能化已成为汽车产业发展的必然趋势。

汽车联网其本质是汽车电子系统的联网。然而,以信息篡改、病毒入侵、恶意代码植入等手段对联网汽车进行信息攻击而引发的汽车信息安全问题也愈发严峻,在国际范围内引发极大关注。

提到汽车联网面临的信息安全风险问题,其中涉及到信息安全领域的核心技术方法—信息安全风险评估,世界各国及地区的安全监管机构已经草拟了一系列准则,预计将在未来几年内发布并生效,用以监管这些潜在的信息安全风险。

其中主机厂最适合对车辆进行安全管理,执行风险评估,因为他们了解车辆整个生命周期开发过程,并且能够以最快的速度做出响应。适用于整车全生命周期的信息安全评估方法内容主要包括:资产识别、脆弱性和威胁分析、风险确定和风险处理。

1.   信息安全风险评估是什么,什么时候和为什么需要它?

通常,我们信息安全风险评估是在车辆生命周期的概念阶段。依照即将出台的ISO 21434标准“道路车辆-信息安全工程”中相关要求进行车辆开发时,汽车制造商有义务进行初步的信息安全风险评估,即信息安全风险审计。根据审计结果,用以确认信息安全风险评估目标,同时完善信息安全需求,进一步做好信息安全设计。

然而,这一过程尚未在汽车行业形成共识并推动全面实施,通常OEM也仅在汽车安全运行中心出现新警报时启动风险评估工作,然后作为事件响应程序的一部分。例如,假设发生了以下事件:

●你的一辆车上发现了黑客攻击

●互联网在线发布了新的CVE,而这可能会影响OEM的某个车型。

最后,OEM利用风险评估的结果,制定信息安全事件响应计划,对车辆出现安全事件时进行必要的维护工作,并有望恢复到安全状态。

2.   风险评估过程有什么要求?它应该提供什么?

一个好的风险评估过程提供了好的洞察力以使之大达到一个切实有效的结果,显然,并非每个漏洞发布都应迫使OEM进行召回或通过OTA软件更新来部署补丁。但在事前做出了正确和成熟的风险评估之后,至少能够尽可能的避免事件的发生。

然而,深入到某个具体环境中分析可能是一个耗时的过程,如果执行不正确,风险评估的时间可能会更长。OEM希望流程简洁,以便能够尽快发现关键问题,并在需要时提供及时响应。此外,这样一个过程应该是自动的,以便能够处理汽车SRC(安全运营中心)的一连串事件。

3.   风险评估方法

      让我们假设一个新的安全预警刚刚出现在我们建设完备的汽车SRC中,该警报通常是由于我们已经部署的一种车载纵深防御解决方案引起的,或者是一个漏洞已通过公开渠道发布。那我们如何创建最佳的风险评估实践流程呢?新的ISO 21434标准提出了一个路线图。以下是我们如何将其分解并直接地呈现出来的:

      3.1 资产鉴定:是否受到影响?如果是那具体在哪里?

     第一步是暴露面评估。我们需要确定是否有相关资产可能受到上述漏洞或攻击的影响。这些资产可以从二进制文件、MCU(微控制器)和信息到PII(个人识别信息)不等。在资产识别之后,我们需要对其进行映射并考虑:

●除此之外它们还可能影响哪些资产?例如,一个二进制文件可能被部署在多个MCU上,从而使暴露程度超出预期。


●那些(现有的)风险资产存在于哪些具体车型上?

002.png

       目前,进行准确资产识别所需的数据可能分散在OEM及其各个供应商之间,因此可能需要检查完整的硬件和软件BOM(物料清单)。这意味着,当发生任何类型的事故时,OEM都需要联系其供应商以向他们查询受到影响的资产存在。

       这样的递归过程必然代价非常高,除了SLA和OEM与零部件供应商之间的自然往返延迟外,还需要多方参与。为了符合上述流程要求,OEM设备制造商需要从一开始就拥有这些数据,从而能够清楚地了解自己的资产。

     003.png

      3.2 漏洞分析和威胁场景:攻击者可以做什么?

      接下来,假设我们受到了影响。我们的下一个任务是了解攻击者可以利用这种漏洞或攻击媒介做什么。我们需要调查攻击者在尝试利用该漏洞时将面临的机会或可能性。

      例如,攻击者可能利用已发布的远程执行代码漏洞,利用其与目标车辆的可连接性,从不受保护或未受监视的信息链路渗透到车辆中,从而在随后的步骤中更轻松地横向移动漫游并直接通往相关失陷ECU。

      更简单的情况是,我们可以假定攻击者已经获得了车辆内部组件之一的访问权限,因此,所述攻击媒介将使他们能够向失陷ECU发送恶意命令。

     综上所述,我们需要在我们自己的信息中“扮演”攻击者的角色,考虑到其完整的拓扑结构、端点特征以及我们部署的各种安全措施

3.3 风险确定-实现成熟决策

    一旦建立了完整的威胁模型,我们需要总结出事件的风险水平。

004.png

我们重点要考虑两个共同构成风险结果的参数:

1.攻击可行性:此事件将[再次]发生的[实际]触发条件是什么?

2.影响等级:如果确实发生此类事件,将影响到什么? 这是安全问题吗?或者,这是否可能只是“财务”问题,是否可能在风险触发前锁定车辆,从而阻止其发生(例如勒索软件)?

让我们看两个例子:

1.   一个相对简单的案例:蓝牙漏洞。

近期在一个行业通用的嵌入式蓝牙协议栈中发现了一个0Day(零日)漏洞。漏洞评分显示严重性非常高,可以通过远程执行代码,且无需遵循提权升级及在物理上接近才能利用该漏洞。我们考虑到,我们向市场发布的那些车型(以及计划的未来版本)实际上都包含此失陷的蓝牙模块-可能安装在某些周边相关组件(例如IVI或TCU)上。为了便于讨论,让我们假设受影响的设备,即我们的资产,是TCU。其次,研究了可能的攻击媒介和攻击者的操作方式。现在,让我们仔细看看三种可能的情况


A.该资产受嵌入式安全解决方案的保护,该解决方案可防止利用该漏洞。

005.png

B.该资产受到外围安全解决方案的保护,该解决方案可防止被攻击设备进一步移动漫游至车辆内部系统中。

006.png
            C.该资产不受安全解决方案的保护,可以直接进入车辆的安全信息。

007.png

      清单上的其他情况……每一种情况可能都具有相似的发生可能性,但它们的影响是完全不同的,从没有影响到全方位的安全影响。

2.一个更“复杂”的案例-AUTOSAR漏洞

假设一个刚刚发布的0Day漏洞影响了基于AUTOSAR架构开发的某种组件。漏洞的严重性得分很高,甚至可以通过远程执行代码,而无需遵循提权升级,并且利用同一个开放信息访问即可利用该漏洞。

我们迅速确定受影响的ECU是什么,并相应地确定相关车型。为了便于讨论,让我们假设资产是一个经过安全加固的ECU。


再次,让我们仔细看一下三种可能的情况:

A. 该资产受嵌入式安全解决方案的保护,该解决方案可防止利用该漏洞。

008.png

B.从外围到资产的每个路由ECU都有一个信息IDPS,用于管理和监视入站数据包。

009.png

C.该资产不受任何安全解决方案的保护,并且在外围信息到资产之间存在未受保护的信息路径。

010.png

如果漏洞被利用,这些场景中的每一个都可能产生类似的安全影响,但是利用漏洞的可行性差异很大,范围包括:

1.最小的可行性-假设攻击者已经绕过了一些安全措施,并有可能在通往我们资产的途中损坏其他设备。

2.高度可行性-假设外围还有另一种公共易受攻击的设备,并且是从它到我们的资产之间有一条直接路径。

通常风险是受两个主要因素的影响,即攻击可行性和影响评级。每种路径在不同情况下也可能产生完全不同的效果。

一旦确定并考虑到风险水平后,我们最终可以得出我们面临的威胁因素是什么,可以进一步关于如何应对做出更“成熟”的决定。

4.   风险处理

在遵循我们的完整开发流程并找到广受欢迎的“智能”风险确定因素之后,决定处理过程可能显得微不足道。然而,这样的决策还考虑了供应链约束、各种汽车程序和子模型中的变体。我们还需要确保我们的处理不会干扰其他所需的信息安全策略或已受安全影响的车辆所采取的扩展处理。就像在汽车行业中进行的其他处理一样,任何处理都应在所有受影响的模型上有良好的仿真测试确认,进行严格监控和验证。

5.   时间至关重要

信息安全风险评估是一个日常性的工作。不幸的是,这使得我们将要面对来自各个来源的多种事件。随着时间的推移,我们看到汽车攻击事件不断增加,OEM期望可以处理越来越多的事件,但这需要业界的关注和资源。因此,面对风险必须迅速做出反应,当我们正在进行评估风险的同时,事件很容易失控。

此类事件无法在经典的汽车时间框架内处理。为了达到目的,风险评估过程应该尽可能精简,最好是将时间从现在的几周缩短到几天甚至几小时。准备工作也是成功的关键——为了实现这样一个过程,评估员必须提前收集所有需要的数据,以便根据需要支持不同的评估过程。

在处理潜在的安全事件时,评估者不能允许第三方或自己浪费时间,故应与涉及该过程的各个实体签订SLA。

6.   风险评估由谁来做?

运用我们分析过的各种场景和可能性,我们只触及了表面。应该清楚的是,有时为了正确地进行风险评估,我们需要车辆的全部范围。至少需要受影响车辆的拓扑结构,并希望伴随有相关的硬件和软件BOM。归根结底:OEM是复杂汽车供应链中唯一对此负责的落脚点。

由于供应商不具备车辆生产过程的全部资料,这不仅不能由任何供应商来完成,而且拥有品牌风险和客户关系的OEM也应该努力以最小的干预和延迟来进行该过程,避免其他供应商之间扯皮虚耗时间。

7.   未来展望

正如ISO 21434标准中所提到,OEM必须意识到他们需要了解如何识别新的和不断发展的信息威胁和漏洞,以及将如何做出响应。

通过上文我们现在可以了解,风险评估是一个过程,它不是一定导致0或1的二元结果,而是一个更复杂的决定,甚至在各家OEM的汽车程序中也可能各有不同。现在,OEM提出了一个新的要求,即快速评估自己的车辆,直到ECU的硬件和软件BOM,从而不受供应商干预或延误。OEM成功应对这些新要求的关键在于需要提前准备,并采取更具信息化战略的方法来管理汽车信息安全生命周期,实现更好的流程管理和响应,从而更好地应对下一次安全事件的发生。


 编者简介:

 情报分析:李强(ID:Keellee),国家智能网联汽车创新中心,专注汽车安全情报及运营管理

 内容编辑:杨文昌(ID:文昌007),国家智能网联汽车创新中心,专注汽车信息安全流程开发及咨询

# 汽车安全 # 风险评估 # 技术方法
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者