MUNIK解读ISO21434专题分享(8):基于具体开发目标的安全工程示例
—原创文章,文章内所有内容文字资料,版权均属本公众号所有,任何媒体、网站、公众号或个人未经Munik公司授权不得转载、转贴、引用或以其他方式复制发布 、发表。已经被Munik公司授权的媒体、网站、公众号、个人,在下载使用时必须注明来源,违者Munik公司将依法追究相关责任.
回到本文的源头文章“ISO21434标准解读”,请点击链接:ISO 21434 Automobile Cyber Security汽车网络安全服务
回到知识分享,请点击链接:MUNIK中国-技术分享
ISO/SAE 21434 标准为道路车辆的网络安全提供了一个系统化的框架,涵盖了从概念阶段到退役的整个生命周期。为了更好地理解如何在具体开发目标中应用该标准,本次推文以BMS系统为例作为一个基于具体开发目标的安全工程示例。
【相关项定义具体步骤】
1.相关项架构图绘制
根据车内E/E架构、车内外网络、系统架构图、早期开发文档等输入物,确定相关项边界。通过梳理功能及信号交互,绘制相关项架构图,包括相关项资产、资产间的连接、运行环境、相关项边界。
如图1所示为BMS系统架构图。根据该系统架构图中各个组件的功能、交互信号、交互信号的类型,将系统架构图中具有网络安全属性的资产与交互信号作为《相关项定义》的输入信息。
图1 MS系统架构图
除此之外,可在相关项架构图后加上对敏感数据的备注。敏感数据包括个人隐私数据、密钥)等。
2.相关项资产描述
资产为组件发送的信号和功能模块。信号类型包括通信信号(CAN/CANFD、LIN、以太网等)、串口信号(SPI、IIC等)、PWM、调试信号(JTAG、USB等),功能类型包括MCU固件、CAN收发器、继电器、SPI通信模块、PWM通信模块、ADC采样模块等。
对相关项内资产进行描述,包括资产名称、资产发送的信号名称、发送信号对应的接口类型。
说明:接口类型包括但不限于JTAG、UART、USB等调试接口,CAN、以太网等标定接口,OBD等诊断接口,4G/5G、WIFI、蓝牙、USB、OBD、GNSS、TPMS等无线接口,CAN、LIN、以太网等通讯接口以及硬线接口等。
例如,在BMS的快充充电管理功能中,XX模块采集XX电压信号作为一个相关项资产,可对其进行如下描述:
表1 相关项资产表
资产ID |
资产 |
发送端 |
接收端 |
接口类型 |
资产类型 |
功能描述 |
|
A1 |
XX |
XX |
XX |
Hardware interface |
Hardware Data |
采集XX电压信号 |
3.功能实现逻辑描述
对功能实现的每一步过程,包括该过程中资产间信号的收发进行描述。
以快充充电管理功能中XX向XX发送快充相关信号为例,该部分的功能实现逻辑可以描述为:XX向BMS的CAN收发器发送上高压请求、快充插枪信号以及充电允许信号,CAN收发器将相应CAN信号通过硬线发给MCU。
4.功能逻辑时序图与数据流图绘制
根据功能实现逻辑描述,将基于资产间信号的交互绘制功能逻辑时序图,基于资产间的数据交互关系绘制数据流图。功能逻辑时序图需体现各资产间的信号传递先后顺序和处理逻辑;数据流图需体现该功能所涉及到的所有资产及信号交互关系。以BMS快充充电管理功能为例,其功能逻辑时序图如图3所示,数据流图如图4所示。
图2 BMS快充充电管理功能逻辑时序图
图3 BMS快充充电管理数据流图
注意:功能逻辑时序图与数据流图中的各资产交互细节(如资产名称、信号名称、信号交互方向、功能逻辑顺序等),应与相关项架构图保持一致。
【TARA分析具体步骤】
1.资产识别
资产为《相关项定义》中组件发生的信号和功能模块,资产的类别分为Data和Function。资产的网络安全属性包括机密性Confidentiality、完整性Integrity、可用性Availability。
例1:伪造遥控钥匙解锁请求信号,使得车辆在停靠期间被意外解锁,导致车内财物、行车记录仪丢失。这破坏了遥控钥匙解锁请求信号的真实性。
不同接口类型的资产所拥有的网络安全属性不同,具体可参考表2。
表2 资产网络安全属性表
资产接口类型 |
资产示例说明 |
网络安全属性 |
备注 |
JTAG |
具备快充管理功能、热管功能、碰撞断电功能等MCU固件
|
机密性 完整性 可用性 |
快充管理功能等MCU固件中包含敏感信息,因此有机密性;通过JTAG接口可以对快充管理功能等MCU固件进行篡改、拒绝、伪造攻击,因此有完整性、可用性、真实性;通过JTAG接口没有权限要求,因此无授权;通过JTAG接口没有否认攻击,因此没有不可抵赖性。 |
2.损害场景识别
损害场景是指资产的网络安全属性被破坏以后,涉及车辆或车辆功能并影响道路使用者的不良后果,如车辆无法运动、撞到行人、撞到其它车辆、撞到建筑物、车辆使用体验差、车辆起火、发送触电等。
例1:资产为存储在信息娱乐系统中的用户敏感信息,其网络安全属性是机密性。损害场景是指在未征得客户同意的情况下泄露了客户的个人信息,导致信息损失机密性。
具体损害场景库可见下图:
Damage ID |
Damage scenario |
Impact category |
Impact Rating |
|||||||
S-JUST. |
S |
F-JUST. |
F |
O-JUST. |
O |
P-JUST. |
P |
|||
D1 |
车辆无法运动 |
未造成人身伤害 |
S0 |
影响正常运营 |
F1 |
车辆无法运行 |
O3 |
无隐私泄露风险 |
P0 |
Severe |
图4 损害场景库举例
3.损害场景影响等级确定
确定损害场景时需要从道路使用者的人身Safety、财产Financial、操作Operational、隐私Privacy这四个方面综合考虑,考虑在不同损害场景下对这四个影响类别造成的严重程度,严重程度等级分为轻微0,中等1、严重2、非常严重3。
例如车辆无法运动的损害场景,未造成人身安全,因此人身安全为S0即Negligible;影响了车辆的运营,因此财产为F1即Moderate;车辆无法运行,因此操作为O3即Severe;无隐私泄露风险,因此隐私为P0即Negligible,取影响等级最严重的等级,所以车辆无法运动的损害场景的影响等级为Severe。
Damage scenario |
Impact category |
Impact rating |
|||||||
S-JUST. |
S |
F-JUST. |
F |
O-JUST. |
O |
P-JUST. |
P |
||
车辆无法运动 |
未造成人身伤害 |
S0 |
影响正常运营 |
F1 |
车辆无法运行 |
O3 |
无隐私泄露风险 |
P0 |
Severe |
图5 损害场景举例
4.威胁场景识别
识别威胁场景时,需要依据资产识别和损害场景的分析结果,针对攻击行为会破坏某个资产的某个网络安全属性进行具体分析,进而分析造成损害场景的潜在威胁。资产的网络安全属性与威胁(参考微软STRIDE威胁模型)的对应关系如下表所示。
表3 资产网络安全属性与威胁模型对应表
资产安全属性 Asset Cybersecurity Properties |
威胁模型 (STRIDE) |
真实性 Authenticity |
伪造 Spoofing |
完整性 Integrity |
篡改 Tampering |
授权 Authority |
提升权限 Elevation of Privilege |
不可抵赖性 Non-repudiation |
否认 Repudiation |
机密性 Confidentiality |
信息泄漏 Information Disclosure |
可用性 Availability |
拒绝服务 Denial of Service |
在描述威胁场景时,应具体描述资产类型、攻击方法(此处的攻击方法指STRDIE模型中的伪造、篡改、提升权限、否认、信息泄漏、拒绝服务)、攻击路径,列出所有相关项已识别资产涉及到的威胁场景。
不同类型的资产所拥有的网络安全属性不同,对应的攻击方法不同,描述威胁场景时可参考表3。
分析攻击路径时,需结合攻击者的动机与控制器的功能,分析对控制器可能的攻击。可结合控制器功能的数据流图对攻击场景进行分析,识别攻击路径和连接方式。连接方式分为物理(需要破线或拆除车辆零部件后连接)、本地(连接车辆对外暴露接口,如OBD口、充电口)、近程(如蓝牙、WIFI)、远程(如5G)。
例如:从整车角度考虑,BMS对外通信接口均为非对外暴露接口(CAN、SPI、PWM、硬线),因此针对BMS的连接方式均为物理连接。
描述攻击路径时需要按步描述从收集信息到实现威胁的攻击路径,例如:
1)攻击者逆向通信矩阵,校验算法;
2)攻击者伪造有校验(无密钥参与)的通信信息;
3)连接CAN通信接口,发送仍能通过校验的通信信息。
5.攻击可行性等级分析
需针对每一条攻击路径进行攻击可行性分析,可以采用基于攻击潜力的分析方法。
采用基于攻击潜力的分析方法对攻击可行性进行分析时,需要从经历时间Elapsed time、专业知识Expertise、相关项或组件知识Knowledge of the item or component、机会窗口Window of opportunity、设备Equipment这五个参数进行分析,最终取值由以上5个参数累加而成,并根据下表中的映射关系得出攻击可行性,攻击可行性分为Very low、Low、Medium、High4个层级。
表4 攻击可行性映射表
Attack feasibility rating |
Explanation |
Value |
High |
The attack path can be accomplished utilizing low effort. |
0-9 |
10-13 |
||
Medium |
The attack path can be accomplished utilizing medium effort. |
14-19 |
Low |
The attack path can be accomplished utilizing high effort. |
20-24 |
Very low |
The attack path can be accomplished utilizing very high effort. |
≥25 |
6.风险等级确定
确定风险等级时,需要根据损害场景的影响等级和威胁场景的攻击可行性来综合判断,具体参考下表。
表5 风险等级表
风险值 Risk Value |
攻击可行性 Attack Feasibility |
||||
Very low |
Low |
Medium |
High |
||
影响等级 Impact Rating |
Severe |
2 |
3 |
4 |
5 |
Major |
1 |
2 |
3 |
4 |
|
Moderate |
1 |
2 |
2 |
3 |
|
Negligible |
1 |
1 |
1 |
1 |
7.确定风险处置决策
在确定风险处置决策后需要定义网络安全目标或声明。如果风险处置决策为Reducing,需要定义网络安全目标。
【网络安全概念具体步骤】
1.网络安全目标描述 Description of Cybersecurity Goals
在TARA分析中确定风险处置决策后,与相关方进行决策并确定导出网络安全目标。
以资产为固件功能的TARA分析举例:当由于攻击者从JTAG调试接口侵入而导致该固件功能的网络安全属性被破坏时,根据TARA分析得出风险处置决策为降低风险,导出的网络安全目标为:确保ECU的JTAG被保护。
表6 网络安全目标表举例
网络安全目标ID |
目标描述 |
CAL |
CSG_01 |
确保ECU的JTAG被保护。 |
2 |
2.网络安全机制设计
针对由TARA分析得出的网络安全目标,为网络安全目标设计合适的网络安全机制。应对网络安全机制进行详细描述,包括触发检测机制、响应机制,最终处理结果说明,和涉及的安全资产说明。
以网络安全目标为"确保ECU的JTAG被保护"为例,设计的网络安全机制为:移除JTAG连接器,并为其增加接入密码。该机制涉及到的网络安全资产为:在侵入JTAG调试接口后网络属性被破坏的资产。
表7 网络安全机制表举例
网络安全机制ID |
网络安全机制 |
ID_01 |
移除JTAG连接器,并为其增加访问密码。 |
3.网络安全需求分配
针对提出的网络安全机制,进行分模块/部件安全需求设计,明确各组件职责,并关联相关安全目标。首先确保所有的网络安全机制都有对应的需求,同时每个需求都细化到具体的模块/组件,此时不需要区分软硬件需求。对网络安全机制进行拆分时,保证拆分出的各个需求没有重叠或遗漏。每个网络安全需求应与其对应机制的对应网络安全目标相一致,确保需求与目标之间的关联。
以上述网络安全目标和机制为例,根据其设计得到的网络安全需求如下:
表8 网络安全需求表举例
网络安全需求 ID |
网络安全需求描述 |
CSM ID |
CAL |
模块 |
CSG ID |
CSR_01 |
MCU应在量产时移除JTAG连接器。 |
CSM_01 |
2 |
MCU |
CSG_01 |
【总结】
通过以上示例,可以看到如何在具体开发目标中应用ISO/SAE 21434标准。该标准提供了一个系统化的方法,帮助开发团队在整个生命周期内管理网络安全风险,确保系统的安全性和可靠性。
另外,这里列出一些芯片厂商分享的车辆通信场景的网络安全需求,也包括车载网络和车到云端的通信安全需求供参考。
关于 MUNIK
我们目前具有经验丰富的网络安全专家团队,且获得多家著名认证机构的预审核评估资质,客户主要是OEM主机厂和T1/T2 零部件供应商,以及供应商和相关上下游行业。最后,如果你还为汽车网络安全相关资质、审核、测试评估和认证不知道怎么下手而发愁,请不要犹豫,关注上海秒尼科技术服务有限公司官网www.munik.com,获取更多服务内容~