汽车信息安全TARA分析方法实例简介

2023 / 3 / 30 | 智能汽车网络安全咨询

概述（摘要）

随着智能网联汽车的不断普及与演进，汽车网络安全问题日益突显，其所存在的安全威胁与风险亟需通过科学、全面的分析，建立有效的安全应对措施。目前比较权威和有效的做法是ISO/SAE 21434标准中的威胁分析与风险评估方法TARA （Threat Analysis and Risk Assessment）。

北京豆荚科技安全咨询团队在实施TARA过程中经历了许多教训，也总结了一些成果。本文结合这些项目中的实战经验，分享一下整车或零部件TARA分析过程中的一些需要关注的要点和分析方法。

相关项识别（Item Identification）

如何判断整车功能中哪些部件需要信息安全保护呢？这个方面在ISO/SAE21434中给出明确的定义，如下图：

图1 网络安全相关性

通过上图可以分析出以下业务或功能是和网络安全相关的：
  1. 运动控制模块和具有汽车安全完整性等级（ASIL）的模块。
  2. 与驾驶员或乘客或潜在敏感信息（如位置数据）相关的示例数据。
  3. 内部连接—CAN、以太网、媒体导向系统传输（MOST）、传输控制协议/互联网协议（TCP/IP）。
  4. 外部连接示例——到后端服务器的功能接口;蜂窝通信网络，车载诊断（OBD-II）接口。
  5. 无线连接传感器或执行器示例–遥控门锁（RKE）、近场通信（NFC）、轮胎压力监测系统（TPMS）。

相关项定义（项目定义）

相关项定义的目的是了解分析对象，了解其业务、功能、流程、边界。在这个步骤中需要把相关项内容仔细的厘清出来，清楚的描述该相关项的输入、输出、关联的相关项有哪些等，下面就拿TPMS(胎压监测系统)进行举例说明。

胎压监测系统的传感器采集四个轮胎的胎压温度等信息并发送出去。胎压监测系统接收器接收传感器发送的数据，对数据进行分析处理，并将相关胎压信息上传到云端。如果有报警信息，通过GW发送给IVI集群显示，并提醒驾驶员胎压报警信息。

TPMS相关项边界定义示意图：

图2 边界图示例

那么在TPMS的相关项定义中，除了边界图之外，还需要包含如下内容的描述：
  • TPMS相关项组件：该相关项都包括哪些组件，每个组件在这个相关项中担当的角色、功能等，都需要罗列出来，并一一说明。
  • TPMS相关项位置：需要描述TPMS在车上的具体物理位置，这和之后我们分析攻击路径有关联。根据物理位置，可以分析对相关项进行物理接触是否方便等。
  • TPMS相关项功能：该相关项都包括哪些功能，需要把功能的详细信息描述清楚，包括每个功能的输入、输出、应用场景等。
  • TPMS相关项的操作环境：包括操作限制、环境限制等。举例：TPMS的操作限制是车速不能大于200Km/h;环境限制是温度-20°C~+50°C等。
  • TPMS关联的相关项：该相关项使用到的数据，其他相关项是否也使用到了。这点与危害场景有关联，举例：TPMS使用车速数据，那么我们就需要把使用到车速的相关项都一一列举出来，一旦车速数据遭到破坏，就能知道哪些相关项会收到影响。。
  • TPMS约束和法规：该车型受到的约束和需要遵守的法规。举例：如车型需在欧美销售的话，就需要满足UNECE R155、UNECE R156、UNECE R157等强制法规；如果在中国本土上道的话，就需要满足国内的相关法规。

数据流图（Data Flow Diagram）

重点是把该相关项中每个功能用到的数据标识出来，从哪个实体产生，经过哪个实体处理，经过哪个实体转发后，显示到大屏上或者通过其他警告声音告知驾驶员等。
以下是一个TPMS的数据流图示例：

图3 数据流图示例

数据流图中需要把每个实体的功能进行描述。如：GW的功能是负责转发CAN网络的报文；TPMS Receiver的功能是负责收集4个车轮传感器发出的胎压信息。

资产识别（Asset Identification）

识别数据流图中哪些是安全资产，并在数据图（图3）中进行标识。

图4 资产图示例

上图中数据资产包括：
  • D-001：左前轮sensor 发出的胎压信息
  • D-002：左后轮sensor 发出的胎压信息
  • D-003：右前轮sensor 发出的胎压信息
  • D-004：右后轮sensor 发出的胎压信息
  • D-005：TPMS Receiver把四个轮子收集的胎压进行分析处理后的结果信息
  • D-006：胎压的警告信息和正常显示的提醒信息。
  • D-007：网关到TBOX的胎压的信息。
  • D-008：车辆速度
  • D-009：从TBOX到云端的胎压的正常信息
  • D-010：从云到手机端的胎压的正常信息
  • D-011：手机控制指令
上图中实体资产包括：
  • P-001：手机端
  • P-002：左前轮传感器
  • P-003：左后轮传感器
  • P-004：右前轮传感器
  • P-005：右后轮传感器
  • P-006：云
  • P-007：TPMS Receiver
  • P-008：网关
  • P-009：中央大屏
  • P-010：TBOX
  • S-001:胎压数据保存

TARA分析：

在具体的进行TARA的过程中，我们通常从下表中列出的几个方面逐一进行分析。

图5 TARA分析示例

①资产属性和危害场景分析

分析的要素：

  • 资产编号与名称：资产的名字：就是图4中的D-00X、P-00X和S-00X等
  • 网络安全属性：资产的网络安全属性，通常分为机密性(Confidentiality)、完整性(Integrity)、可用性(Availability)、真实性(Authenticity)、授权性(Authorization)、抗抵赖性(Non-repudiation)、新鲜性(Freshness)
  • 危害场景：资产的安全属性被破坏后造成哪些危害（影响），影响一定要落到：S（人身安全）F（财产）O（功能）P（隐私）四个方面
  • 危害判断说明：描述评估者的判断依据和理由
  • 影响类别：主要包括4个方面：人身安全、财产、功能、隐私的危害判断
  • 影响等级：根据公式自动计算，计算标准来自ISO21434

示例说明：

在图5中，我们针对TPMS的资产D-008（车辆速度）给出了其数据完整性属性相关的损坏场景分析。车速数据丧失完整性则意味着数据遭到了篡改。篡改后的数据发给GW等组件，将会对车辆行驶造成损害。
危害判断说明中，我们需要从SFOP四个方面进行分析，根据组织整体约定好的规则，判断影响程度。需要描述我们判断的理由，例如超速行驶可能会带来F（财产）的中等损失。

②威胁场景和攻击路径分析

分析的要素：

  • 威胁场景：这个通常采用STRIDE分析方法，下边是对STRIDE的概要解释。
  • S）Spoofing（伪装）：伪装成其他人或其他实体，如用别人的ID发言就是Identity Spoofing。
  • T）Tampering（篡改）：合法的内容被修改了。
  • R）Repudiation（拒绝承认）：实体对自己的行为不承认。
  • I）Information Disclosure（信息的泄漏）：对非授权方提供敏感信息。
  • D）Denial of Services（拒绝服务）：恶意过度消耗，使得系统无法获得提供服务所需的资源。
  • E）Elevation of Privileges（提升权限）：允许未授权实体执行授权行为，如普通用户尝试用管理员权限去做事情。
  • 攻击路径：需要用攻击树来确定可行性最容易的攻击路径。

示例说明：

对数据完整性的威胁，主要来自于STRIDE中的T，就是篡改。那么在威胁场景中，我们就描述数据遭到篡改就可以了。
对数据进行篡改有很多种攻击方法，这与数据的存储、传输、使用方式都有直接的关系。我们建议将攻击树分析得出的1~3条攻击路径都写出来。此处我们只举例了通过OBD端口劫持GW的一种方式，由于是示例写的比较简单。在实际的分析中，我们要从攻击者角度，把攻击路径清晰完整的描述出来。

③攻击可行性评估

分析的要素：

  • WP29攻击映射：WP29 附录5的表A1中对应的威胁场景（非必须项，由于WP29 R155明确要求“车辆制造商应考虑与附录5表A中提到的所有威胁相关的风险以及任何其他相关风险”，因此建议标注）。
  • 耗时：完成这个攻击路径需要的时间。
  • 专业知识：完成这个攻击路径，攻击者需要具备的专业知识程度。
  • 组件知识：攻击者获取该项知识的难易程度。
  • 机会窗口：发动攻击成功的可能性
  • 设备器材：发动攻击时，是否依赖特殊设备
  • 攻击可行性等级：根据以上计算的评分（计算方法来自ISO21434）
  • 综合攻击可行性等级：根据以上计算的评分（计算方法来自ISO21434）

示例说明：

该部分的评估需要安全团队基于组织的知识库来完成。

④风险评估和应对措施

分析的要素：

  • 风险数值：根据以上计算的评分（计算方法来自ISO21434）
  • 风险处置策略：风险应对措施
  • 网络安全目标：相关功能、组件、产品的网络安全目标
  • 网络安全需求：对相关功能、组件、产品的网络安全要求
  • 网络安全声明：产品安全声明（如果风险处置策略不是缓解减轻风险，而是选择接受或规避、转移的时候，需要进行声明）

示例说明：

该部分需要安全团队和相关安全负责部门参与完成。其中安全声明部分，牵涉到供应商约束、法律法规内容，需要相关负责人参与决策。

 

总结：

通过TARA分析，我们需要得到该相关项或零部件的是安全目标、产品要求、产品安全声明。根据笔者的项目经验，在进行TARA分析前，一定要对相关项的功能进行细致的分析，这样才能充分识别出资产（包括内部实体、外部实体、存储数据、数据流等），以及每个实体、数据被破坏后带来的危害场景是什么。这些必须要在相关项定义（Item definition）中做明确标识。

另外，攻击路径写的越全，识别出的安全要求就越完整，当然工作量也会变的更多，成本也会增多。攻击路径需要基于安全积累，安全知识库来撰写，并且一定要有安全专家和安全团队的支持，来评估攻击路径的步骤是否清晰、攻击路径是否可行，针对攻击路径中的描述缓解措施是否正确等，这是TARA分析的关键要点。

由于篇幅所限，这里只是从实战角度简单的描述了TARA项目中笔者认为的一些要点。实际上我们在做TARA分析时，每一步都要基于业务和/或安全经验的支持，需要非常细致的分析工作。