以下内容整理自谈思AutoSec8周年年会。
目前，阿维塔的数字安全团队有20多个人，在日常工作中，几乎每个人每天都在写代码、做红蓝对抗，大家最大的兴趣爱好就是给公司挖一些车云安全或者车辆安全的漏洞。
阿维塔安全团队的工作原则是凭手艺说话、凭事实定级、凭自省提高，也就是说，无论是做TARA，还是做漏洞分析，都必须自己证明：我至少能找到这个漏洞。而不是凭空跟业务讲：某个地方很危险，某个漏洞不修的话会怎样……很重要的一点在于，漏洞找到之后能不能利用，而不是拿扫描器扫出来一堆CVB，然后去找业务反馈。
01阿维塔安全攻击实例
首先，来介绍阿维塔的一些攻击实例。图1显示的是一个非常简单的案例，尤其是做乙方的朋友可能会特别熟悉，当接到甲方的渗透测试时，无论是智能座舱，还是智能驾驶，首先要做的就是nmap一轮扫，看是否有开放端口，再比对业务的端口设计文件，一旦发现有在这个设计文件里面没有的端口，就会去跟业务确认。
当然，也会先做一些尝试指令的连接，比如说“adbconnect”，这些连接都尝试一遍后，往往就会发现这样开放到车机里的端口不止一个，这是因为我们拿到的往往是一个测试版本，而在测试阶段，研发是有合理的需求去保留这么一个端口去打印日志，或者是输出一些CAN信号。
这时，我们就要先跟研发进行一轮确认，并且也要捋一下日志里面的内容，CAN信号也会打印一份出来看，如果这是CDC跟TBOX之间的CAN信号，但捋出来发现里面有跟MDC、或者有一些敏感信息，那就是超微传输CAN信号了，就要进行一些限制，并且要留底，以提醒研发在实际的商用版本中，关闭这些暴露端口。有必要的话，还要再做一些强密码的保存，以便后面的调试。
图2是我们阿维塔安全团队的工程师挖到的另一个比较有意思的漏洞。在研究了一款很多主机厂都采用的一套通用代码的座舱后，在里面发现了一串地址，这串地址光用肉眼去看的话，是不太能知道讲的是什么，有些地方可能有一些英文符号如news，或weather，从而猜测它可能是连接到座舱里的天气，或者是某个消息中心。
一般来说，座舱的展示屏幕前端会不停地调取后端接口发的数据，所以我们就一直去探测类似于news这样的自研地址，并发送一些文字，比如说一开始就发“hello”，后面再尝试发一些可能不雅的言论，测试用户是否真的会受到影响。
严格来讲，这个漏洞不是那种扫描出来后很难修复的漏洞，而是大量的代码导致的逻辑漏洞，这也是在车机里面大家最怕的一种，如果有黑客思维的话，能在很多通用代码里找到大量类似问题，所以这里也提醒大家以后要注意。
最后一个漏洞案例比较偏合规和体系，叫座舱安全刷写无校验，如图3所示。车联网安全行业的同仁可能都知道所谓的安全刷写和安全启动，二者都是AUTOSAR里面写得很标准的东西，测试手法大家也都知道，通俗一点讲就是篡改，那篡改的到底是什么？
这里我将其概括为“包身包头包尾巴”。我看过很多家主机厂的渗透测试报告，也包括在跟乙方进行交流时，他们给到的测试条例上面就只会写“我会篡改你这个包，然后重新刷到一个控制器上，看看能否成功做这个刷写”。
但研究后发现，篡改不同的位置证明的是不同的东西，并且，篡改的内容也是有区分的，比如RXSWIN（RegulationXSoftwareIdentificationNumber），它是R156里面的一个概念，这个概念跟R155有一定的重叠，然后我就发现，改的东西不同测的也不一样。
对应这个法律法规，我们一般去篡改这个包的版本号，对应的是R156里面的这个版本号的唯一性，就是说一个OTA版本只能有一个版本号，所以车企要去做欧标认证的话，这一条就不能只是简单的一个篡改就能证明的，而是一定要证明篡改的是它的版本号。因为阿维塔正好在做欧洲出海的项目，所以这块就捋得比较细。
还有R155，通俗来讲，改的就是签名值，这也是基于之前做测试时的经验。我们团队把这个包整个拆开来改，改了一个“.s19”的文件后发现刷不成功，当时改的不是签名，也不是版本号。我们就发现，不是随便打开这个包，改一个配置文件，就能证明这个实验是成功的。
这里提醒一下，改“.s19”文件的时候，是会影响它本身的完整性校验的。所以我们只知道篡改，但并不知道改了什么东西。所以现在就做了严格的要求，并且把它对应得比较细化。
02实战漏洞分布
讲完阿维塔的漏洞攻击实例，接下来讲一下实战漏洞分布。这个数据是基于阿维塔的日常工作所调研出来的，跟中汽中心或一些国检中心的不一样，他们是车云漏洞的占比更高，但因为我们团队更偏零部件、车端的渗透，所以碰到的端上漏洞更多。此外，由于我们这个车依赖的云平台是华为车云，所以确实没什么漏洞，不得不说，华为在这方面做得挺好的。
至于为什么要说安全减负，因为攻击做多了之后就会发现，安全需求并没有那么难做，它不需要下得那么全面。下图是按照阿维塔的车型项目节点去计算的安全团队解决问题的速率。首先，平均每个车上解决的漏洞是25个，这25个指的是把所有的组件漏洞合并之后，那些需要组件升级的往往会被我归并成一个。
目前，阿维塔已经把信息安全纳入了质量标准，即整车上市之前，在信息安全层面也要符合公司的质量标准。其解决率为98%，即量产之前，车辆的高危及中规漏洞要消除为零，可能会有一、两个属于可以去澄清或没有办法解决的中危漏洞，但是它不可被利用，那这种情况是可以放过的。
图4是卡点攻击面的一些分析，首先是TARA分析，TARA在做的过程中很容易边界模糊，把所有的功能录进去之后，有些时候会发现不知道自己在分析什么了。所以我们会采用几个方法论，一个是定性，一个是定量，然后再用一个风险倒推。有的风险其实是能想象得到的，所以就能用这种倒推的形式完成整个TARA分析，这样也能保证这个分析不是超出认知和常识的。
举个例子，我们经常讲SecOC，也都知道SecOC是一段Mac值加一段新鲜值，它上在任何一个信号上都会影响这个信号本身传输的速率，在让电子电器架构设计的时候，他都会说“Mac值加FA值得占多少个BT、影响私CAN的负载率……”所以我们往往就只能在那些所谓定级最高的信号上推这个防护措施，但是往往定级最高的信号，它的传输实时率要求又很高，所以在这方面，安全概念就成了一个悖论。
再比如，一些动力域发到电驱的信号很重要、不能被篡改。但事实是，很多电驱是挂在动力域下面，中间走的是私CAN，这个时候SecOC对这两个控制器其实一点帮助都没有，因为它只能解决跨域传输的问题，对私CAN是完全不进行校验的。所以我们就在原有的一套理论和方法论上面减了很多负，取消了私CAN上面的SecOC。
其次，安全的需求特性。还是刚才那个例子，保护不同的信号一定要定到非常细的方案上，一一对应。再就是安全方案设计，我们团队中的任何一个工程师，都能指导SecOC代码的编写，以及调库。经常会遇到一些供应商，他可能是第一次写，我们会告诉他AES的算法哪个库会比较好用，会剪裁得比较好，还会告诉他整个算法怎么去排这个逻辑。
最后就是我们能自己去闭环进行符合性测试。符合性测试跟渗透测试的区别大家也知道，符合性就是下了需求后，有没有给做；渗透就是在做了这个安全需求的基础上，还能不能通过其他的黑客手段再进入到这个体系内造成一些威胁。这就是我们整个卡点的一个思路。
这里我理了一个简易的分类，由于每家车企的电子电架构不一样，这个只是给大家做一个参考，如图5。
首先，是智能座舱、网关、智驾、T-box分为一类，这是所有信息安全方案基本都要上的一类；第二类是BLE等，上的安全方案也比较多，相对前一类少一个TLS，因为它不直接跟云端进行交互，而且有可能不跟其他三个件做间接的TLS，因为它不传输敏感数据；第三类是转向、电驱和无接触充电。
最后一类比较极端，什么安全方案都不用上，比如说香氛。其实我们的业务很规范，做了体系之后，他们在每个项目上都会来确认“xx控制器有没有信息安全的需求”，我会直接告诉他“没有，你不要担心。那上面既没有代码，也不OTA，做什么信息安全呢？”所以真正要实施信息安全方案的控制器并没有那么多，而且有的控制器的方案还是重合的。
03IDPS编写实例
相信大家都并不陌生IDPS，以前从事过互联网的同仁会更熟悉，其实就是把主机安全的东西移到车上，把车当做一台电脑。基于这样的思路，我们做了一些拆解。在跟华为合作的主机厂里面，阿维塔是第一个推动华为共建IDPS能力的，双方一起写了这版策略。
这里重点讲下我们怎么在IDPS的策略上面减负的。有的主机厂可能会让咨询公司出一套IDPS策略，但这种策略一般会比较粗糙，只会大概说有哪几个部署点，有哪些探针……但是对于这些探针的策略实际上要细化到通过采什么、计算什么，以及要去读整个系统里的哪个配置文件。
或许大家可能没有关心到那么底层，但我们团队对这个直接梳理到了底层，其中就有这么几个案例。第一个是我们在优化减负的时候，跟“网络配置篡改检测”这个问题battle了很久，一开始下的策略是对这个文件要进行全面的监测，无论是读的权限还是写的权限，这个配置文件全都要较高频率地监听。
但在跟研发探讨了几轮后发现，这个文件本身权限就控得很死，是一个只读，在只读的前提下，又只有两个进程可以进它的root，而且这两个进程的权限也几乎就是最高的权限了。所以我们就把这些只读文件的监听范围做了一轮缩小，毕竟安全团队自己都完全没有办法攻击进去，业内黑客做了评估后发现，也没办法进去，那就没必要去监听这些文件了，哪怕这些文件里面确实写的是非常高敏的东西，但这个时候要得放且放，毕竟，在甲方的工作里面，去防这些未知的攻击手段其实是不现实的。
第二个案例是异常账号检测。其实和上面那个案例类似，我们会去盘点这个账号本身有没有保护机制，有的话还需不需要做那么全面的监听。最后一个案例是敏感文件监控，大家都知道IDPS是要上传日志到VSOC进行分析的，我们一开始是要求全量的日志都要上传，但后来反思了一个问题：安全运营排查的时候，真的要看日志的其他字段吗？那些没有用的字段为什么要上传上来？有的字段在告警的阶段已经被用于记算了，还要它原本字段的这些内容干嘛？所以我们就删除了那些安全排查无用的字段，最后帮助性能整体提升了20%。
最后，我们也弄了一个闭环验证实验，这个是跟我们部门负责IDPS的同事一起写的文档。研发在帮我们正向开发的时候，我们就会直接把那个测试ID写出来给他。当时研发质疑一个只读文件配置的时候，就说“你自己能不能写出测试条例来？我都不知道这个怎么黑进去，那相应的安全日志也不会记录下来”。
当时，我们也battle了好几轮，最后被说服了，后来在出策略的同时，针对这个策略必须写一条测试用例出来，这样才能闭环地给研发证明，这个东西是有用的，也是有实际研发价值的。还有就是端口扫描。端口扫描在策略上其实可以玩得很花，可以是强策略，也可以是弱策略。
阿维塔的安全团队一直秉持就是多搞技术，少说空话、持续学习、开放态度，这也是我们的延续之本。