欢迎光临第五届中国汽车网络信息安全峰会2020!

TARA

发布日期:2020-07-19

GRCC IoVSecurity 昨天 

手机阅读

点击上方蓝色字体,关注我们

TARA-汽车安全概念


安全防护指导原则

(1) 不要带主观意识;

(2) 重视隐私:包括对代码进行硬件保护

(3) 不信任第三方系统:使用经过认证过的加密库,尽可能不要用自己实现的加密算法;

(4) 多因子认证;

(5) 最小权限;

(6) 多层防护;

(7) 简化系统设计:不需要或不安全的功能需要disable,如release后的产品调试功能,但简化系统设计并不意味着使用相同的密钥,功能等,如我们禁止在不同的功能上、不同的车辆上使用相同的密钥。此处的系统简化是在不违反安全设计的原则下精简系统组成;

(8) 最弱处加固:特别需要注意的就是随机数的随机性;

(9) 使用白名单:false positive永远比false negative好;

(10) 失败安全:当系统接收到破坏的、不合法或恶意数据和命令时,系统需要能够在安全状态下工作;

(11) 默认安全;

(12) 业务隔离:同一应用中尽可能将敏感数据放在一起,同一系统中,尽可能将安全组件放在一起,这样便于统一管理;

(13) 公开设计:永远要假设自己的代码是公开的,尽可能少的依赖代码的模糊性实现的安全,特别是禁止敏感数据的硬加密;

(14) 全生命周期的安全

(15) 安全机制实现需要按照正确顺序:如数据需要先规范化才能进行核验;

note:最弱处加固,就防护而言遵循的是木桶效应,防御机制如何精心设计,只要存在一个简单的绕过机制,就能完成攻击,我们要做的一是尽可能穷尽薄弱点,提高整体攻击难度,二是组合业务隔离和失败安全,不让薄弱处组合成攻击链;

note:使用白名单,白名单会导致错杀,但相对于黑名单的错放,false positive的后果肯定比false negative的结果小很多;

note:简化系统设计,漏洞没有固定的模式、固定的特征,某种程度来说,系统越复杂,就越容易出现漏洞,因此我们在设计方案时需要尽可能简单;

note:业务隔离,即不把鸡蛋放一个篮子里,单元模块的破坏不会导致整个系统的崩溃;

note:公开设计,即开放源码,我们不依赖于源码的实现,而是依赖于源码的逻辑,以加密为例,我们要相信只要我的密钥长度足够合理,即使攻击者获取了源码,一样不能够解密;感觉对汽车领域来说短时间无法实现;


安全概念

多层防护


最外面的第四层是与车联网相关的,目的是保护汽车整车的通信安全性和完整性以及驾驶员的隐私。推荐的安全解决方案是,与外部通信时经过防火墙,并满足通信和外部接口相关的安全标准。比如 IEEE 1609.2,ETSI TS 103 097等,定义了ITS相关的无线网络的安全通信规范。而且要使用软件组件和应用层网关(ALG:Application LayerGateway)将车内网络和外部通信分割。


第三层电子电气架构。目的是分离并保护整个车内网域,推荐使用能够管理通信数据以及访问权限的车载安全网关。例如,车载网关可以按照车内LAN网络的规范,以CAN的ID和报文内容,以及报文的传输频率为基础,对通信内容进行检查和过滤。使用列出安全通信对象的“白名单”方式,可以验证帧的ID,使用“状态包检查”和“深度包检查”等包过滤技术则可以检查报文的内容。此外,通过与正常传输的频率比较,可以检测出以更高频率或更低频率发送的报文。应该限制对安全网关的诊断和非标准数据的传输,如果必须接入访问的话,要请求解锁;


第二层主要目的是保护车内网络信号的完整性,实现车内传输结构安全、访问控制、权限管理、可信平台,是车辆网络安全重要一环。这个部分十分重要,后面详细说明。


最里面的第一层,是为了保护车辆搭载的各个ECU的软件和数据的完整性。推荐的解决方案是采用面向车载网络安全的安全硬件模块。


IDPS

· 应用防护:阻断非受信APP的安装、执行,防止受信APP被卸载和篡改


· 可信引导:基于硬件可信根,确保从上电开始每个环节所执行代码的可信,阻止offbox攻击


· 越权检测:对系统异常行为进行检测,抵御越权攻击


· 隐私保护:用户数据访问特权保护,防止窃取隐私


· 控车安全:智能的CAN指令过滤,识别风险控车指令


Car Firewall

· 区域隔离:车载网络和因特网的安全隔离


· 访问控制:防火墙支持ip、port访问控制,支持基于app网络访问控制


· 协议过滤:基于协议识别的应用层安全过滤


· 实时阻断:基于实时网络异常流量的检测、告警、阻断


· 安全审计:基于内核驱动技术实现日志落盘、安全审计功能


· 策略管理:支持离线策略配置、易于运营


· 密钥管理:软件级或硬件级密钥安全存储


      当然还有很多其他的安全概念,在此不一一列举,有需要的可以自己查阅,google上有很多,在此推荐的有PREESERVE、NHTSA这两个组织,上面有很多内容可以给前期的TARA分析和后面的防护措施提供参考,当然所有的资料都是全英文的,作为汽车人,英语不好,真的是寸步难行。


PS:要相关的资料可以给我留言,但麻烦你看完后给我一份自己理解的中文版。(资料很多,我也想偷懒,大家一起学习,一起提高)


TARA-Asset穷举


资产可以分为大的资产和细化的资产,大的资产为use case中设计到的ECU,细化的资产设计到通信链路、密钥、个人信息,参考evita,可以有:

下面以Door lock为例:


TARA-威胁建模方案


威胁模型可以包含多个层级。如果模型中的某个过程过于复杂,应当考虑通过在模型框图中增加层级,将该过程进一步分解。但是,在建模初始阶段,你往往只能分解到Level 2 级。下面将从Level 0 级开始介绍各个不同的层级。

Level 0 级:鸟瞰视图

        进行本级建模时,需要参考在分析攻击面时建立的检查表。分析数据通过何种方式进入车辆。将车辆绘制在中心,并标注出内部空间和外部空间。Level 0 框图的范例如图所示

    在图1-1 中,矩形框表示输入,中心的圆形代表整辆汽车,在输入到达车的过程中穿过的两条点虚线则分别表示外部和内部威胁的边界。车辆周围的圆形并不表示某个输入,而表示一个复杂过程——也就是一系列可进一步分解的任务。所有过程都有编号,如图1-1 所示,图1-1 中的过程被编号为1.0。如果在威胁模型中有多个复杂过程,则将编号顺延。例如,第二个过程编号为2.0,第三个则是3.0,以此类推。随着对汽车功能了解的逐步深入,对模型框图作相应的更新。

2Level1 级:接收端

         要继续进行 Level 1 级框图建模,需要选择一个过程进行分析。由于图1-1 中只有一个“车辆”过程,因此本节将深入该过程内部,聚焦于各个输入与哪些对象交互。图1-2 中的Level 1 级映射图与Level 0 级中的几乎相同,唯一的区别是在Level 1 级映射图中标识出了一些接收Level 0 级输入的车辆数据连接。在本级中暂时不对接收端作深入分析,而只关注与输入交互的各个基本设备或区域。

       请注意,在图1-2 中对每一个接收端进行了编号。第一位数字代表Level 0 级框图(见图1-1)中的过程编号,第二位数字则代表该接收端的编号。由于信息娱乐单元既是一个复杂的过程,也是数据输入源,因此这里用一个圆形过程符号表示它。另外还有其他3个过程:防盗系统、ECU(Electronic Control Unit,电子控制单元)和TPMS(Tire PressureMonitoring System,胎压监测系统)接收器。Level 1 级框图中的点虚线表示信任域的边界。框图顶部的输入是最不被信任的,而框图底部的信任级别**。通信信道穿过的信任边界数量越多,意味着它的风险程度越高。

3Level2级:接收端分解

         在 Level 2 级,对车辆内部的通信进行分析。示例框图(见图1-3)关注了某个基于Linux的信息娱乐控制台,即图1-2 中的接收端1.1。它是接收端中较为复杂的之一,且往往直接连接到车辆内部网络。在图1-3 中,使用代表信任边界的虚线框对通信信道进行分组。现在,信息控制台内部新增了一条称为内核空间的信任边界。能直接与内核交互的外部系统的风险级别高于与系统应用程序交互的外部系统,因为前者可能绕过信息娱乐单元上的访问控制机制。例如,蜂窝移动(手机)通信信道的风险级别比WiFi高,因为蜂窝移动(手机)信道穿过了一条信任边界直达内核空间。另一方面,WiFi则与用户空间中的WPA 客户端进程通信。

     该系统是一个基于Linux 的IVI(In-Vehicle-Infotainment,车载信息娱乐)系统,它使用与Linux 环境通用的部件。在内核空间中,可以看到对udev、HSI 和Kvaser 这3 个接收本威胁模型输入的内核模块的引用。其中,udev 加载USB 设备,HSI 是处理蜂窝通信的串口驱动程序,而Kvaser 则用于驱动车辆的内部网络。Level 2 级威胁模型的编号形式为x.x.x,继续沿用如前所述的标识系统。在Level 0级框图中,将整辆汽车的信息处理过程标识为1.0,在对该过程进行更深入分析的Level 1级框图中,将其中的过程分别标识为1.1、1.2 等,依次顺延。由于在Level 2 级框图中选择了信息娱乐控制台过程1.1 并对其进行了进一步分解,因此在Level 2 级框图中将复杂过程标识为1.1.1、1.1.2 等,依次顺延(在深入分析过程时,可以继续使用该编号方案。该编号方案旨在满足文档编制需求,通过它可以准确引用合适层次的某个过程)。

注意:理想情况下,本阶段应能标注出哪个过程处理哪个输入的对应关系,但目前还只能依赖猜测。在现实条件下,往往需要对信息娱乐系统进行逆向工程以获取这一信息。在建造或设计汽车系统的过程中,应当对尽可能多的复杂过程进行持续“下钻”式分析。邀请开发团队参与工作,讨论每个应用程序所用的库和方法,以将这些库和方法纳入该应用程序自身的威胁框图。在进行应用程序级的建模分析时,往往会发现信任边界通常处于应用程序和内核之间、应用程序和库之间、应用程序相互之间,甚至是应用程序内部的函数与函数之间。在分析这些连接时,标出那些具有更高权限或处理更敏感信息的方法。

大概思路就是根据STRIDE威胁,结合资产和资产之间的信息流,确定可能的威胁。在进行STRIDE分析之前,可以根据系统功能定义划分,针对单个系统功能进行STRIDE分析,进而完成整个系统的安全分析。


(详细可以参考微软的stride介绍,https://docs.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool)




该威胁建模基于日本的 JASO-TP15002,大致可以分为两个步骤:


(1)确定需要保护的资产以及确定资产间的信息流;


(2)根据资产和信息流的CIA,结合不同的情景,穷尽threat;穷尽的方法从Where、Who、When、Why、What展开;





主要的问题:


(1)Phase1中,由于整车厂以及不同的设备供应商之间对于TOE的定义会有差异,如何统一管理这些差异,以及将这些资源整合、交互是一个必须的过程;


(2)Phase2中,对于what的描述是个抽象概念,不好定量,进而导致威胁确定的时候需要以一个特殊的方式进行;其次在风险评级的过程中如何将Where、When、What关联进去;


(3)基于CVSS v2的CRSS和基于CVSS v3的RSMA之间,如何比较已确定适用于汽车的评级方法;



威胁建模的方法:


(1)确定可能实现的攻击目的;目标是可以进一步细化的;


(2)确定所有可能的攻击方法;方法中可能包含一个多个需要满足的条件


(3)根据攻击方法确立具体的攻击手段;包括需要什么设备,影响什么资产,系统需要处于什么样的状态、什么样的配置;如下图




       车辆在与其他车辆进行通信时,可以接收来自其他车辆的危险告警信息,而攻击者可能对此发起“篡改告警消息”的攻击。以此为例进行攻击树分析,如下图所示。



其他类似的攻击树有(详细自已搜索梆梆安全对应的文档):




————————————————

版权声明:本文为CSDN博主「qq_24925595」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/qq_24925595/article/details/104824712



相关文章

汽车网络安全之——CAN网关测试
汽车网络安全风险评估方法
汽车网络安全之——CAN安全分析方法总结(国外文献)
汽车安全测试Checklist




SELECTED EVENTS




 

长按二维码识别关注



我就知道你“在看”


  • 电话咨询
  • 15021948198
  • 021-22306692
None