目录
概述:
本条款描述了确定道路使用者受威胁情景影响程度的方法。这些方法及其工作产品统称为威胁分析和风险评估(TARA),从受影响道路使用者的角度执行。本条款中定义的方法是通用模块,可以从项目或组件生命周期的任何点系统地调用。
目的:
- 识别资产、其网络安全属性及其损坏场景;
- 确定威胁情景;
- 确定损害情景的影响等级;
- 识别实现威胁场景的攻击路径;
- 确定攻击路径可被利用的难易程度;
- 确定威胁场景的风险值;
- 为威胁场景选择适当的风险处理方案。
1.资产识别(见15.3)
1.1要求和建议
- 应确定损坏程度
- 损坏情况可包括:项目功能与不良后果之间的关系;对道路使用者造成损害的描述;相关资产
- 应识别具有网络安全特性的资产,其危害会导致损坏情况。
- 资产的识别可基于:分析项目定义;进行影响评级;从威胁情景中获取资产;使用预定义的目录
示例1资产是存储在信息娱乐系统中的个人信息(客户个人偏好),其网络安全属性为机密性。损坏场景是由于失去保密性而未经客户同意披露个人信息。
示例2资产是制动功能的数据通信,其网络安全属性是完整性。损坏场景是车辆高速行驶时,由于意外完全制动而与后续车辆发生碰撞(追尾碰撞)。
2.威胁情景识别(见15.4)
- 应确定威胁场景
- 包括:目标资产;资产的网络安全财产受损;网络安全财产受损的原因。
- 注1:进一步信息可包括或与威胁场景相关,例如损坏场景、资产之间的技术依赖性、攻击者、方法、工具、和攻击面。
- 注2:威胁情景识别方法可以使用小组讨论或系统方法,例如:引发合理可预见的误用或滥用导致的恶意用例;基于框架的威胁建模方法,如E VITA 1^1、TVRA 12-11、PASTA E21、STRIDE[欺骗、篡改、否认、信息披露、拒绝服务、特权提升]
- 包括:目标资产;资产的网络安全财产受损;网络安全财产受损的原因。
3.影响评级(见15.5)
- 应根据安全、财务、运营和隐私(分别为S、F、0、P)影响类别中对道路使用者的潜在不利后果评估损害情景。
- 注1:本文件未提供关系[例如权重]不同影响类别之间。
- 注2:可考虑其他影响类别。
- 注3:如果考虑其他影响类别,则可根据第7条在供应链中共享这些类别的基本原理和解释
- 损害情景的影响等级应确定为以下影响类别之一:非常严重;严重;中等;可忽略不计。
- 注4:财务、运营和隐私相关影响可根据附录F中给出的表格进行评级。
- 安全相关冲击评级应源自ISO 26262-3:2018,6.4.3。
- 注5:附录F中的表F.1可用于将安全冲击标准映射到冲击评级。
- 注6:功能安全性评估可用于此目的。
如果一个损坏场景导致了一个影响等级,并且可以提出一个论点,认为另一个影响类别的每一次影响都是至关重要的,那么可以省略对该其他影响类别的进一步分析。例如,损坏场景的安全影响等级为“非常严重”,因此,没有进一步分析该损害情景的财务影响。
4.攻击路径分析(见15.6)
注:如果对项目进行攻击路径分析,则使用项目定义;如果对组件进行攻击路径分析,则使用网络安全规范。
进一步的支持信息可以考虑以下信息:网络安全事件的弱点[WP-08-04];产品开发过程中发现的缺陷[WP-10-05];建筑设计;先前确定的攻击路径[WP-15-05],如果可用;脆弱性分析[WP-08-05]
- 应对威胁场景进行分析,以确定攻击路径。
- 注1:攻击路径分析可基于:自上而下的方法,通过分析实现威胁场景的不同方式(如攻击树、攻击图和自下向上的方法,通过识别的漏洞构建攻击路径。
- 注2:如果部分攻击路径不会导致威胁场景的实现,则可以停止对该部分攻击路径的分析。
- 攻击路径应与攻击路径可实现的威胁场景相关联。
- 注3:在产品开发的早期阶段,攻击路径通常不完整或不精确,因为具体实施细节尚不清楚,无法识别特定漏洞。在产品开发过程中,攻击路径可以随着更多信息的可用而更新,例如,在漏洞分析后。
5.攻击可行性评级(见15.7)
威胁场景示例:
- 欺骗制动ECU的CAN消息会导致CAN消息的完整性丧失,从而导致制动功能的完整性丧失。
- 实现上述威胁场景的攻击路径:1.远程通信ECU通过蜂窝接口受损;2.网关ECU通过来自远程通信ECU的CAN通信受损;3.网关ECU转发恶意制动请求信号(不必要的快速减速)
- 对于每条攻击路径,攻击可行性等级应按照表1中所述确定。
攻击可行性 | 说明 |
高 | 攻击路径可以利用低工作量完成。 |
中 | 攻击路径可以利用中工作量完成。 |
低 | 攻击路径可以利用高工作量完成。 |
非常低 | 攻击路径可以通过非常高的努力来完成 |
- 攻击可行性评级方法应基于以下方法之一进行定义:a)基于攻击潜力的方法;b) 基于CVSS的方法;c)基于攻击向量的方法。
- 注1:方法的选择取决于生命周期中的阶段和可用信息
- 如果使用基于攻击潜力的方法,则应根据核心因素确定攻击可行性评级,包括:a)经过的时间;b) 专业知识;c) 项目或组件的知识;d) 机会之窗;e)设备。
- 注2:核心攻击潜在因素可从ISO/IEC 18045 1^1中得出
- 注3:G.2提供了基于攻击潜在性确定攻击可行性的指南。
- 如果使用基于CVSS的方法,则攻击可行性等级应根据基础度量组的可挖掘性度量来确定,包括:A)攻击向量;b) 攻击复杂性;c) 所需特权;
- 注释4:G.3提供了基于CVSS的方法确定攻击可行性的准则。
- 如果使用基于攻击向量的方法,则攻击攻击等级可基于评估主要攻击向量来确定。(参见攻击路径的CVSS l2^]2.1.1]。
- 注5:G.4提供了基于攻击向量方法确定攻击可行性的指南。
- 注6:在开发的早期阶段(例如概念阶段),当没有足够的信息来识别特定的攻击路径时,基于攻击向量的方法可以适用于评估攻击的可行性
6.风险值确定(见15.8)
- 对于每个威胁场景,应根据相关损害场景的影响和相关攻击路径的攻击可行性确定风险值。
- 注1:如果威胁场景对应于多个损害场景和/或相关损害场景对多个攻击路径产生影响影响类别,可为每个影响评级分别确定单独的风险值。
- 注2:如果威胁情景对应于多个攻击路径,则可适当聚合相关的攻击可行性评级,例如,威胁情景被指定为相应攻击路径的攻击可行性评级的最大值。
- 威胁情景的风险值应介于(包括)1和5之间,其中值1表示最小风险。
- 风险值确定的示例方法:风险矩阵;风险公式
7.风险处理决策(见15.9)-p55
- 对于每个威胁情景,考虑到其风险值,应确定以下一个或多个风险处理选项
- 避免风险;例1:通过消除风险源来避免风险,决定不开始或继续导致风险的活动
- 降低风险;
- 分担风险;例2:通过合同分担风险或通过购买保险转移风险。
- 保留风险。注意,保留风险和分担风险的理由记录为网络安全索赔,并根据第8条进行网络安全监控和漏洞管理