网络安全（Cyber Security）是近几年汽车电子圈与以太网、自动驾驶、车联网等并驾齐驱的热门话题，为何（Why）？目前的标准和现状是什么（What）？网络安全防的是谁（Who）？是从哪里发起攻击（Where）？面对这些攻击，何时（When）要做网络安全工作？如何做（How）？
作为当代“汽车人”，让我们从这5W1H来聊聊汽车网络安全这个话题。
· 自动驾驶的下沉和技术升级➔网络安全的缺陷如潜伏的灰犀牛，影响和危害更大
· 车联网广泛的需求➔更多攻击源，更大的个人信息外泄风险（如在车端交易付款的账户信息）
· 以太网通信技术的普及➔已存的基于以太网的攻击技术将无缝迁移
· 下一代基于高性能计算平台的电子电器架构➔使Linux、QNX等操作系统在域（Domain）控制器/区（Zone）控制器中得以广泛应用，同步引入了成熟的攻击“套路”（如下图1）
上述的 “叠加效应”以及过去几年发生的安全事件和攻防演练案例（以15年大切诺基的网络安全“网红事件”开始），让大家对网络安全更为敏感和重视。但网络安全该如何行之有效地落地，这也是当前行业同仁们的焦虑点之一。
“Cyber Security”，其中之一的英文说明：“A attribute of a cyber-physical system that relates to avoiding unreasonable risk due to an attack”，很挣扎地把它翻译为：网络物理系统中“避免由于攻击而引起不合理风险”的一种属性。后续章节通过对比的方式将给大家展示更形象的释义。
网络安全常涉及的四个名词：Vulnerability vs. Threat vs. Attack vs. Risk，借用下图予以解释。
前者更宏观，包括通信链路安全以及“链路”所运载的数据安全；后者更具体，强调的是数据的安全，例如对通过蓝牙共享在车机中电话薄信息的保
以铁路运输为例，网络安全包括铁路干线运行安全和运行之上的列车及货物安全，信息安全侧重于列车中货物安全（防火防盗），是网络安全的子集。
网络安全vs功能安全（Security vs Safety）
Security的目标是如何免受攻击（Attack），保护财产、隐私信息、生命安全，所需应对的威胁和攻击具有不可预测及动态的特性。
Safety的目标是在受到外部攻击或内部故障的情况下，保护车内人员、路人的生命安全，其危害（Hazard）分析具有相对的可预测及静态的特点。
Safety Communication：防止非恶意故障（如ECU自身软件的运行错误）对通信链路的影响，如消息损坏、消息丢失。采用的机制包括CRC/E2E等，保证信息的完整性。
Security Communication：防止恶意攻击（如ECU软件被非法替换）对通信链路的影响，如消息的插入、删除、修改、延迟等。采用机制包括SecOC等，保证信息的真实性及完整性。
SAE J3061从两个维度阐述了两者之间的关系：
· 从实体或载体的角度，功能安全关键系统是网络安全关键系统的子集
举例来说，ADAS控制器是毋容置疑的“关键的”功能安全系统。同样的安全漏洞在此类载体中所产生的危害更大，所以对它不仅要求满足对应功能安全等级的技术条件，同时也必须应用网络安全相关技术，这也是为何很多网络安全技术在此类功能安全关键系统中应用更广的推动力。反之，T-Box是公认的网络安全的关键系统，但却不是功能安全的关键系统。
功能安全和网络安全的设计开发流程相互影响，部分要素互为输入。在ISO26262 2018版中专门阐述了两者之间在概念、开发、生产各阶段的潜在的交互关系。
为了更好地理解及应用，可简单地将近些年汽车网络安全相关主要标准及组织按照如下二维坐标进行定位。
· AUTOSAR所定义的网络安全技术，对车内ECU是快速落地的最佳选择
· ISO21434将于2020年正式发布，可能会取代SAE J3061
· 在传统IT及工业领域的ISO 15408、ISO 27001、IEC 62443可充分借鉴参考
· 某些情况下“车内”和“车外”的界线并不明显，具体问题具体分析
· 国家非常重视交通运输领域网络安全标准的制定和推广，相关的标准、行业白皮书需大家关注
网络安全和功能安全都是相对的，不存在绝对的“安全”。许多已有网络安全技术本身既炫酷也有效，但为何却并未如预期普及呢（如车内报文加密、基于机器学习的IDS、IPS等）？汽车行业的开发是分厘计较的，多一点代码/多一点存储空间占用/多一点CPU开销都需精打细算其对成本和性能带来的影响，所以平衡最重要也最难。
图6 应用IDS和IPS后转发性能的对比（图片来源：Bosch）
网络安全需要认清一个现实：“道高一尺，魔高一丈”，如果有足够资源（时间、金钱、设备等），一切安全措施都可能被突破。而尝试攻击的人，可大致分两类：
· 技术段位极高的，想扬名立万的黑客级玩家，主观上无损害他人人身和财产安全的意愿
显然，要防范的重点是后者。从社会经济学的角度，既然逐利，后者同样会分析投入与收益的关系。所以对于网络安全的设计者而言，需建立相应的安全措施去重点保护可让攻击者获益的漏洞，从而让攻击者觉得投入回报不具吸引力。
弄清和了解“谁是我们的敌人”，做到知己知彼，方可有的放矢！他自狠来他自恶，我自一口真气足。
补充一点，尝试攻击的除上述以外，当然还存在有组织、有纪律的团体，其目标非单一维度的“获名”或“获利”来描述，不在本文讨论的范畴。
根据车内和车外进行划分，可以把潜在攻击点汇总如下图，针对ADAS传感器端的攻击不属于本文的讨论范畴。
通宵达旦处于防备状态为理想，但对车辆而言功耗和馈电的紧箍咒，决不允许ECU如此“任性”。所以可行的方式是网络安全相关的功能/任务，要“早起晚睡”：从ECU唤醒和启动的时刻开始布防，如下文将提到的Secure Boot，同时站好最后一班岗。
若是解决短期的网络安全设计困惑，可借鉴如下图8所示的相对简单有效的方式实现网络安全。
若长远考虑建立网络安全开发机制，可以参照和解读SAE J3061，定义与功能安全十分相似的开发过程：
推荐通过TARA（Threat Analysis and Risk Assessment）的方法（此处画重点，和功能安全中的HARA分析方法异曲同工），评估和定义网络安全特性及需求。
定义产品在系统层面、硬件层面、软件层面网络安全开发流程。
· Production, Operation and Service
定义车辆生产、使用和售后维护过程的网络安全需求，比如售后诊断刷写工具等。
可与ISO26262所定义的支持过程共用的，比如配置管理，文档管理，变更管理等，同时需根据网络安全开发的特点进行一定的定制，如网络安全需求管理、分布式开发的处理。
图9 网络安全的Concept阶段和产品开发阶段的工作流（来自SAE J3061）
总的来说，SAE J3061定义了涵盖产品完整的生命周期网络安全开发流程，后续在ISO 21434中进行继承和补充，但是与ISO26262相同的：定义的都是What，不是How！
基于车辆电子电器系统和局部的特点，网络安全的技术框架普遍采用层层设防的分层理念。同时，按照保护、监测、响应不同的目标阶段，对所涉及的技术可简要汇总如下图。
针对多核多操作系统域控制器，为了保证网络安全就需要控制器从逻辑或物理上实现隔离分区，这样可保证一旦某个操作系统下的漏洞被攻破，不会影响其它操作系统的通信和功能。
以太网本身自带一些安全机制（VLAN/ACL等），同时TSN定义了802.1Qci，实现入口过滤和监控，以满足作为主干网通信的网络安全需求。另外，诊断通信也将定义新的诊断指令以更好地支持网络安全。
采用以功能域为导向或以网络安全关键性为导向的架构设计方案。
包括数据加密和身份认证等技术，以实现防探测和防篡改，网络安全技术的芯片化是趋势；同时，3GPP主导的C-V2X中网络安全相关标准在起草中，值得关注。
图11 以功能域和安全关键性为导向的架构设计示意图
从技术应用的落地角度，对车内可区别对待，先从功能安全（ADAS/VCU等）和网络安全关键系统(GW/TBOX/HMI等)着手，先从可行的技术着手；而车外可借助IT行业成熟经验和技术，保证TSP及TSP与TBox之间通信，手机端APP及手机端与TSP之间通信的网络安全。
测试依然负责坚守最后的防线，但与以前有些不同。对于网络安全而言，测试的地位明显提高，因为网络安全测试的过程也是模拟攻击，发现漏洞的过程。
包括ISO 21434和SAE J3061等在内的标准和文档，介绍了如下几种常用的测试方法：
基于网络安全设计需求的正向和逆向测试和性能测试，可黑盒实现。
通过功能测试，验证从输入和输出是否满足设计需求，可归类至功能性测试，可黑盒实现。
通过产生随机数，或“规律的”随机数，验证系统的行为，可黑盒或灰盒实现。
在白盒或灰盒的状态下进行扫描测试，例如基于CERT的Guideline进行代码扫描，或基于已知的安全漏洞Checklist进行审查，漏洞扫描的结果可作为渗透测试的输入。
利用系统漏洞，发起“攻击”，尝试获得系统控制、访问等各种权限。基于测试结果识别网络安全需求，强化系统的安全设计。可在黑盒、灰盒或白盒状态下开展，对测试人员的要求极高。
ISO 21434中定义了1级-4级的CAL（Cybersecurity Assurance Level）。与ASIL相似，不同CAL等级的部件需采用不同Level的测试方法和手段。
技术落地要从实际出发，要结合汽车行业自身的特点。以大家耳熟能详的SecOC中的MAC（Message Authentication Code）应用为例：
· CAN报文中增加了MAC数据，对数据场分配带来了影响，进而可能对网络负载产生影响
· 是否需要采用CAN FD以容纳新增的数据场？如果是，就需要进行CAN FD通信需求设计；如果否，需要对原有的网络设计进行重定义和优化
· 如使用CAN FD通信了，需考虑是否基于CAN FD实现诊断刷写，是否增加网关的路由类型等问题，这些将会影响系统架构的设计
· MAC对于接收端和发送端都将产生额外的资源消耗，需通过专用的硬件HSM模块来处理，才能降低CPU/MCU开销，并减少收发延迟
· HSM硬件模块采用何种方案，对开发和成本影响有多大，都需要予以考虑
由此可见，哪怕只是增加一个MAC的特性，就已涉及了内部和外部的上下游，涵盖从顶层设计至具体实现的方方面面，每走一步的包袱和惯性自然会大一些，更何况是网络安全这样的大话题。所以，更需要策略性的应对，坚持“合适的才是最好”的原则。
