智能驾驶安全专题|信息安全概念阶段如何落地实施？

“乘风破浪”背后的安全隐患

        看过《速度与激情8》的人&＃xff0c;都应该对纽约第五大道汽车失控的那一幕记忆深刻。停车场里1000多辆汽车被黑客控制&＃xff0c;上演了一场“僵尸车大战”。黑客通过类似手机网络系统控制了指定区域汽车的OBD系统&＃xff0c;进而取得了汽车的控制权&＃xff0c;通过程序设定车辆的驾驶模式。电影情节在增强观众的视觉冲击力的同时&＃xff0c;也引起了汽车行业的广泛关注。

        虽然电影的表现手法比较夸张&＃xff0c;但单从技术角度来说&＃xff0c;目前远程控制和劫持汽车是可行的。因为今天的智能网联汽车已经变成名副其实的万物互联时代的智能终端设备。

        目前&＃xff0c;汽车的普通车型拥有25到200个不等的ECU&＃xff08;电子控制单元&＃xff09;&＃xff0c;高级轿车有144个ECU连接&＃xff0c;软件代码超过6500万行&＃xff0c;无人驾驶汽车的软件代码超过2亿行。汽车中ECU和连接越多&＃xff0c;黑客对汽车的攻击面就越多&＃xff0c;尤其是汽车通过通信网络接入互联网连接到云端之后&＃xff0c;每个计算、控制和传感单元&＃xff0c;每个连接路径都有可能因存在安全漏洞而被黑客利用&＃xff0c;实现对汽车的攻击和控制。此外&＃xff0c;与外部连接的接口&＃xff0c;如蓝牙、WiFi等的增多&＃xff0c;也相应增加了网络攻击的渠道。

        黑客的攻击不仅会对驾驶员人身安全造成威胁&＃xff0c;对社会公共安全也会造成一定的危害。因此&＃xff0c;智能网联汽车的信息安全已经成为汽车开发的关注点。

信息安全标准&＃xff08;ISO/SAE 21434&＃xff09;剖析

        针对智能网联汽车快速发展背景下的车辆信息安全开发&＃xff0c;信息安全开发流程标准应运而生。2020年2月12日&＃xff0c;ISO/SAE 21434 Road Vehicle-Cybersecurity Engineering 标准DIS版正式发布。该标准的出台意味着将汽车信息安全提升到与功能安全等同重要亦或更甚的位置。功能安全设计旨在避免因功能失效导致的安全事故&＃xff0c;信息安全旨在避免恶意攻击事件。

        与ISO 26262标准类似&＃xff0c;ISO/SAE 21434标准同样基于“V模型”的总体思路&＃xff0c;覆盖了汽车电子从研发到制造领域的核心开发活动。ISO/SAE 21434通过建立一个可重复且结构化的控制流程&＃xff0c;有效地识别出可能被利用的威胁与漏洞&＃xff0c;并能在系统设计过程中针对已识别的漏洞做出有效控制&＃xff0c;且可贯穿整个车辆生命周期&＃xff0c;从概念阶段&＃xff0c;到产品&＃xff0c;运营以及售后服务。不难看出&＃xff0c;汽车功能安全与汽车信息安全相互渗透&＃xff0c;都是在架构功能设计之初就将Safety/Cybersecurity纳入到系统中&＃xff0c;且都贯穿于产品的设计、研发、制造、维修、回收等环节。ISO/SAE 21434标准的发布&＃xff0c;为OEM/Tier1/Tier2解决信息安全问题提供了理论依据和实施指南。

ISO/SAE 21434对概念阶段的开发要求

        按照正向开发的流程&＃xff0c;概念阶段是信息安全开发活动的起点&＃xff0c;也是信息安全开发中很重要的环节。一个系统的开发如果没有清晰的架构和功能定义&＃xff0c;就无法准确识别系统中可能存在的漏洞风险&＃xff1b;若不能恰当的辨识威胁及攻击路径&＃xff0c;就无法准确的提出cybersecurity requirements。因此&＃xff0c;概念阶段的重要性不言而喻。

        我们先关注一下ISO/SAE 21434信息安全开发流程中对概念阶段的重点要求&＃xff1a;

    ♦ 相关项定义&＃xff0c;确定系统的架构与功能

    ♦ 威胁分析与风险评估&＃xff0c;导出信息安全目标

    ♦ 信息安全概念开发&＃xff0c;导出信息安全需求并分配到各模块上

    ♦ 验证

        接下来&＃xff0c;我们就展开剖析在ISO/SAE 21434中概念阶段开发具体如何实施&＃xff1a;核心的开发活动包括item definition、cybersecurity goals、cybersecurity concept三部分。

• Item Definition&＃xff08;相关项定义&＃xff09;

        在相关项定义阶段&＃xff0c;需要定义系统与车辆内部/外部的其他系统和组件的接口&＃xff08;item boundary&＃xff09;、功能(function)和初始架构&＃xff08;preliminary architecture&＃xff09;。

• Cybersecurity goals&＃xff08;定义信息安全目标&＃xff09;

        车辆功能安全在概念阶段需要进行危害分析与风险评估&＃xff08;HARA&＃xff09;&＃xff0c;确定ASIL等级&＃xff0c;提出safety goals&＃xff1b;同样&＃xff0c;信息安全也需要进行威胁分析与风险评估&＃xff08;TARA&＃xff09;&＃xff0c;提出cybersecurity goals。

        对于更容易进行识别的功能危害分析来说&＃xff0c;传统车辆的评估流程已非常完善&＃xff0c;能对车辆潜在的安全风险逐个进行功能测试&＃xff0c;如碰撞试验等&＃xff0c;即可逐个排除。但信息安全的威胁分析则更为复杂&＃xff0c;对整车以及各个子网部件&＃xff0c;存在太多未知的攻击漏洞及攻击方式&＃xff0c;且需要站在攻击者的立场上&＃xff0c;使用非传统式的漏洞分析&＃xff0c;渗透及统计学技术进行分析&＃xff0c;难度相对较大。

ISO/SAE 21434中专家给出的建议是通过辨识系统中的资产&＃xff08;Asset identification&＃xff09;并赋予相应的安全属性&＃xff0c;然后通过CIAA、HEAVENNS、STRIDE等安全属性-威胁映射方法进行威胁识别&＃xff08;Threat scenario identification&＃xff09;。

        基于STRIDE&＃xff08;CIAA/HEAVENNS&＃xff09;方法识别特定资产和威胁之后&＃xff0c;需要对风险进行评估&＃xff08;Impact rating&＃xff09;。也就是说要导出每个威胁的安全等级&＃xff08;Security Level&＃xff09;。安全等级用于衡量安全相关资产满足特定安全级别所需的安全机制强度。安全等级&＃xff08;Security Level&＃xff09;的确定由威胁的“可能性”&＃xff08;Likelihood Level&＃xff09;和“严重度”&＃xff08;Severity Level&＃xff09;这两个参数共同决定。

        系统模型的搭建应该本着深层防御的思想&＃xff0c;尽量减少因某些元素遭到攻击而导致其他元素受到损失。进行FTA分析&＃xff0c;可以识别出会违反安全目标的单点或多点故障。而对于ATA分析&＃xff0c;我们的目标是识别出attackers攻击的潜在路径&＃xff08;Attack path analysis&＃xff09;及其攻击可行性等级&＃xff08;Attack feasibility rating&＃xff09;进而通过制定相应的信息安全措施消除漏洞或使其更难被利用。&＃xff08;Risk determination&＃xff09;。

        根据利益相关者的可接受风险分等级和潜在攻击路径&＃xff0c;确定Risk Treatment&＃xff0c;提出Security Measures&＃xff0c;并确定Cybersecurity Goals。&＃xff08;Risk determination&＃xff09;。

Cybersecurity Concept&＃xff08;信息安全概念&＃xff09;

        在信息安全概念开发阶段&＃xff0c;需要基于Cybersecurity Goals&＃xff0c;导出对应的Cybersecurity Requirements&＃xff08;Specify cybersecurity requirement&＃xff09;&＃xff0c;并将其分配到系统设计架构/运行环境中&＃xff08;Allocate  cybersecurity requirement to component&＃xff09;。

        验证Cybersecurity Requirements与Cybersecurity Goals的一致性、完整性以及与预期功能的一致性&＃xff08;Verification&＃xff09;。

信息安全开发解决方案-Medini Cybersecurity

        针对智能网联汽车信息安全开发需求&＃xff0c;Medini Cybersecurity第一时间推出了支持ISO/SAE 21434开发流程、以模型为中心的信息安全开发解决方案&＃xff0c;可以覆盖信息安全概念阶段的开发环节&＃xff0c;助力信息安全开发活动开展。

        通过SySML模型在Medini中搭建系统架构&＃xff0c;识别资产并定义其安全属性。

        基于安全属性-威胁映射方法STRIDE辨识威胁&＃xff0c;并对威胁进行风险评估。

        基于系统架构快速构建攻击树&＃xff0c;分析攻击路径&＃xff0c;制定处理措施并提出安全目标及对应的安全需求&＃xff0c;并把安全需求分配给对应的系统和组件。

        安全需求、系统设计、安全分析三者可以统一在Medini中进行链接、交互和管理&＃xff0c;保证信息安全开发活动的一致性和追溯性&＃xff0c;节省开发时间成本。

        经纬恒润从2008年开始研究及实施功能安全&＃xff0c;并于同年组建了功能安全团队&＃xff0c;从消化ISO-26262标准到参与2017年GB/T 34590功能安全标准的制定&＃xff1b;结合自身汽车电子产品研发实践&＃xff0c;经纬恒润的功能安全团队在智驾域、底盘域、动力域、车身域实施国内外100&＃43;成功案例&＃xff0c;积累了丰富的经验。迎合市场所需&＃xff0c;结合量产产品功能安全落地实施的技术难点&＃xff0c;经纬恒润功能安全团队将以智能驾驶功能安全为主题&＃xff0c;陆续发布解决方案系列文章&＃xff0c;欢迎大家共同探讨&＃xff01;