作为当代“汽车人”，让我们从这5W1H来聊聊汽车网络安全这个话题。
1Why-背景
从行业应用的角度
从技术通路的角度
上述的“叠加效应”以及过去几年发生的安全事件和攻防演练案例（以15年大切诺基的网络安全“网红事件”开始），让大家对网络安全更为敏感和重视。但网络安全该如何行之有效地落地，这也是当前行业同仁们的焦虑点之一。
2What-概念及现状
名词解释
“CyberSecurity”，其中之一的英文说明：“Aattributeofacyber-physicalsystemthatrelatestoavoidingunreasonableriskduetoanattack”，很挣扎地把它翻译为：网络物理系统中“避免由于攻击而引起不合理风险”的一种属性。后续章节通过对比的方式将给大家展示更形象的释义。
网络安全常涉及的四个名词：Vulnerabilityvs.Threatvs.Attackvs.Risk，借用下图予以解释。
网络安全vs信息安全
网络安全vs功能安全（SecurityvsSafety）
先说区别：
Security的目标是如何免受攻击（Attack），保护财产、隐私信息、生命安全，所需应对的威胁和攻击具有不可预测及动态的特性。
Safety的目标是在受到外部攻击或内部故障的情况下，保护车内人员、路人的生命安全，其危害（Hazard）分析具有相对的可预测及静态的特点。
以通信作为对比示例：SafetyCommunication：防止非恶意故障（如ECU自身软件的运行错误）对通信链路的影响，如消息损坏、消息丢失。采用的机制包括CRC/E2E等，保证信息的完整性。
SecurityCommunication：防止恶意攻击（如ECU软件被非法替换）对通信链路的影响，如消息的插入、删除、修改、延迟等。采用机制包括SecOC等，保证信息的真实性及完整性。
再说联系：
SAEJ3061从两个维度阐述了两者之间的关系：
功能安全和网络安全的设计开发流程相互影响，部分要素互为输入。在ISO262622018版中专门阐述了两者之间在概念、开发、生产各阶段的潜在的交互关系。
标准及现状
关于上述标准文档的解读不在此展开，只说明几点：
小结
网络安全和功能安全都是相对的，不存在绝对的“安全”。许多已有网络安全技术本身既炫酷也有效，但为何却并未如预期普及呢（如车内报文加密、基于机器学习的IDS、IPS等）？汽车行业的开发是分厘计较的，多一点代码/多一点存储空间占用/多一点CPU开销都需精打细算其对成本和性能带来的影响，所以平衡最重要也最难。
3Who-防的是谁
显然，要防范的重点是后者。从社会经济学的角度，既然逐利，后者同样会分析投入与收益的关系。所以对于网络安全的设计者而言，需建立相应的安全措施去重点保护可让攻击者获益的漏洞，从而让攻击者觉得投入回报不具吸引力。
弄清和了解“谁是我们的敌人”，做到知己知彼，方可有的放矢！他自狠来他自恶，我自一口真气足。
补充一点，尝试攻击的除上述以外，当然还存在有组织、有纪律的团体，其目标非单一维度的“获名”或“获利”来描述，不在本文讨论的范畴。
4Where-从哪里发起攻击
根据车内和车外进行划分，可以把潜在攻击点汇总如下图，针对ADAS传感器端的攻击不属于本文的讨论范畴。
5When-何时
关于When可分为两个层面：
建议：技术储备只争朝夕，方案落地结合实际。
6How-如何实现网络安全
简单有效的开发方法
若是解决短期的网络安全设计困惑，可借鉴如下图8所示的相对简单有效的方式实现网络安全。
体系化的流程
若长远考虑建立网络安全开发机制，可以参照和解读SAEJ3061，定义与功能安全十分相似的开发过程：
推荐通过TARA（ThreatAnalysisandRiskAssessment）的方法（此处画重点，和功能安全中的HARA分析方法异曲同工），评估和定义网络安全特性及需求。
定义产品在系统层面、硬件层面、软件层面网络安全开发流程。
定义车辆生产、使用和售后维护过程的网络安全需求，比如售后诊断刷写工具等。
可与ISO26262所定义的支持过程共用的，比如配置管理，文档管理，变更管理等，同时需根据网络安全开发的特点进行一定的定制，如网络安全需求管理、分布式开发的处理。
总的来说，SAEJ3061定义了涵盖产品完整的生命周期网络安全开发流程，后续在ISO21434中进行继承和补充，但是与ISO26262相同的：定义的都是What，不是How！
网络安全实现的技术方案
基于车辆电子电器系统和局部的特点，网络安全的技术框架普遍采用层层设防的分层理念。同时，按照保护、监测、响应不同的目标阶段，对所涉及的技术可简要汇总如下图。
对各层新技术趋势，举例来说：
以太网本身自带一些安全机制（VLAN/ACL等），同时TSN定义了802.1Qci，实现入口过滤和监控，以满足作为主干网通信的网络安全需求。另外，诊断通信也将定义新的诊断指令以更好地支持网络安全。
采用以功能域为导向或以网络安全关键性为导向的架构设计方案。
从技术应用的落地角度，对车内可区别对待，先从功能安全（ADAS/VCU等）和网络安全关键系统(GW/TBOX/HMI等)着手，先从可行的技术着手；而车外可借助IT行业成熟经验和技术，保证TSP及TSP与TBox之间通信，手机端APP及手机端与TSP之间通信的网络安全。
网络安全测试
测试依然负责坚守最后的防线，但与以前有些不同。对于网络安全而言，测试的地位明显提高，因为网络安全测试的过程也是模拟攻击，发现漏洞的过程。
包括ISO21434和SAEJ3061等在内的标准和文档，介绍了如下几种常用的测试方法：
基于网络安全设计需求的正向和逆向测试和性能测试，可黑盒实现。
通过功能测试，验证从输入和输出是否满足设计需求，可归类至功能性测试，可黑盒实现。
通过产生随机数，或“规律的”随机数，验证系统的行为，可黑盒或灰盒实现。
在白盒或灰盒的状态下进行扫描测试，例如基于CERT的Guideline进行代码扫描，或基于已知的安全漏洞Checklist进行审查，漏洞扫描的结果可作为渗透测试的输入。
利用系统漏洞，发起“攻击”，尝试获得系统控制、访问等各种权限。基于测试结果识别网络安全需求，强化系统的安全设计。可在黑盒、灰盒或白盒状态下开展，对测试人员的要求极高。
ISO21434中定义了1级-4级的CAL（CybersecurityAssuranceLevel）。与ASIL相似，不同CAL等级的部件需采用不同Level的测试方法和手段。
7总结
技术落地要从实际出发，要结合汽车行业自身的特点。以大家耳熟能详的SecOC中的MAC（MessageAuthenticationCode）应用为例：
从系统设计角度
以部件实现而言
由此可见，哪怕只是增加一个MAC的特性，就已涉及了内部和外部的上下游，涵盖从顶层设计至具体实现的方方面面，每走一步的包袱和惯性自然会大一些，更何况是网络安全这样的大话题。所以，更需要策略性的应对，坚持“合适的才是最好”的原则。