概述


整车厂(OEM)通过供应链获得软件组件,这些组件在网络安全方面几乎是盲目的。因为没参与组件的开发过程,且无法访问所有源代码,因此无法知道软件组件的内容、组成,以及其中的安全风险。

在不断变化的安全世界中,现有的解决方案(譬如对每个设备进行人工评估)是不够的。设备在集成之前看起来是安全的,但在集成之后可能会发现新的漏洞或新的攻击技术,让设备面临着 安全风险,甚至,在部署之后情况会变得更糟。如果不实时监控汽车中所有已部署的组件,那么已上路车辆会对可能出现的新风险浑然不觉。

在汽车领域中,一次汽车安全违规的风险是丧失生命,因此,在攻击和漏洞发生并造成任何伤害之前阻止它们至关重要。对汽车网络安全方案进行风险评估是确保车辆持续安全的唯一途径。 对错误不留余地,对过失不给时间。必须采取主动,在攻击发生之前查找并监控漏洞。

将开发外包的结果是: 应用程序重要部分的行为实际上在目前大多数流行的代码分析工具中无法被发现。第三方软件通常仅以二进制形式提供,因此无法用市面上的静态源代码分析工具进行检查。无法访问源代码,这些工具没法对应用程序中执行第三方代码的安全后果完全负责。


软件是组装的

软件和实体产品非常相似,都是从零部件开始组装。 在软件生态系统中,构建者(或开发人员)创建软件产品,购买者(或消费者)使用它们。无论产品是移动App、医疗设备、汽车ECU还是飞机固件,构建者都是通过组装部件来创建软件。

第一方代码由构建者组织内产品团队直接开发。通常,这些代码将第三方组件粘合在一起,并提供产品其他特定的功能。

第三方组件是在产品团队之外创建的,它们可能是开源组件、商业化组件,甚至是在构建者组织内不同部门中开发的。

成品是将所有内容都放一起的第三方组件和第一方代码的组合。具体比例因项目和行业而不同,但每个行业几乎所有软件都是以这种方式组装的。

第三方组件的集成构成了软件供应链,它具有传统制造业供应链的所有挑战,再加上了许多网络安全风险。

人工管理供应链安全风险不可行,自动化风险检测方案使您能够最大程度地减少供应链中的安全风险。


组件存在安全风险

乍看起来,组件似乎好得难以置信,可以获得所需功能,节省自己写代码的时间和金钱。但是,组件带来了通常会被忽略的严重风险。

主要的风险来自于漏洞,使得攻击者有机会窃取信息的组件错误,导致产品行为不正确或产品完全遭破坏。幸运的是,通常已知漏洞在NVD中被公布到全世界。如果你知道正在使用的哪个组件,并且知道它是公开组件,那么就可以找出有哪些已知漏洞。但是,如果是专有组件的话,就不能这样做。

如果你的产品用含漏洞软件组件,那么你和你的客户将面临严重安全风险和健壮性风险。如果销售车辆,攻击者可能会利用软件组件中的已知漏洞来破坏汽车系统并导致其故障。如果销售医疗设备,漏洞可能会意外地导致患者死亡。除致死和遭窃之外,安全违规和破坏还带来严重后果。制造商和采购方的声誉都会受到无法挽回的损害,造成无法估量的财务损失。

开发机构有时会认为不是我的代码意味着不是我的问题。引入第三方软件的部分心态是认为其他人已测试过软件的质量和安全性。这有可能正确,也有可能不正确,但无论内部发生什么故障,产品包装上是你的名字。如果车辆因发动机密封件故障而瘫痪,从密封件厂商到发动机厂商乃至汽车厂商本身,供应链中的每一个环节都会面临严重麻烦。软件有着产品制造者和购买者所承载的同样的依赖关系和安全风险。

当机构发布含第三方代码的产品时,它将对其中每一行代码负责 --- 包括所有的第三方代码。

由于以下任何原因,产品中的组件无法得到更新:

● 开发人员没意识到所含组件的安全性影响,他们关注重点只是功能。

● 影响他们的组件和漏洞不容易跟踪,许多团队仅通过电子表格或简单列表来管理缺陷及漏洞,这样很难保持准确性和及时性。

● 没人意识到组件存在,举例来说:为可移植性已修改的代码,仅被静态链接,很容易被遗漏。

● 保持组件的最新版本有挑战性。

● 以及主要原因 --- 大多数情况下,它们是完全未知的。


攻击手段在不断演进

安全研究人员以及黑帽子们每天都会在软件组件中发现新的漏洞,即便你一直勤于你的供应链,并且今天你的产品组件不含已知漏洞, 但是,安全状况快速变化。 举例来说,2015年,国家漏洞数据库(NVD)全年共有6,447个, 到了2017年,这一数字增加到14,712。

2018年,熔毁漏洞和幽灵漏洞对该问题发出了刺耳且无情的信号。这些是我们设备CPU(中央处理单元)中的安全漏洞,使得恶意代码访问设备中不应被访问的信息。漏洞被披露后,制造商和采购者都难以做出快速有效的反应。大多数行业缺乏供应链管理,一些基本问题很难回答:

● 制造商在问哪个产品使用了有漏洞的版本

● 购买者问在已有的或将要购买的系统中运行的哪个产品含有漏洞的版本

用合适的供应链安全流程以及正确的技术,答案就在您眼前。如果您在正确地管理供应链风险,您就可以快速地做出响应,冷静地应对新爆出来的漏洞。也能够快速识别哪些资产正在使用受影响的组件,并立即行动修复问题。


供应链的安全管理

固件供应链安全管理是您业务的关键部分,你需要密切注意在使用的组件,确保它们适合您的产品并且质量良好。

需要做的第一步就是定义管控策略。在任何情况下哪些组件不易受到攻击?应对第三方组件漏洞的策略是什么?保证向客户发布关键补丁的门限是什么?

一旦定义好了策略,它就是引入或升级第三方组件时必须要通过的门槛。

对于厂家而言,那些门限通常在两个位置:

1. 在发布工程期间,对产品中的组件进行全面的安全风险检查。

2. 在部署期间,监控供应链中已知漏洞和新发现的漏洞,做出知情的风险决策。使用该信息来判断何时更新或替换这些组件,并且发布软件的新版本。为客户提供适当的信息帮助他们做出是否更新的风险知情的决策。


了解您的许可

另一个风险是软件许可。几乎每个软件组件都有一个相关联的许可,其中列出了允许您使用该组件的条款。

我们所有人都习惯于在安装软件包时点击“license”,--- 有人真的读过该文本吗?软件组件也有控制你使用该组件的许可,而且某些许可具有深远的影响。

如果你的产品不符合其组件的许可要求,那么很有可能陷入其他法律纠纷。知识产权诉讼所涉及的时间和金钱会很繁重,持续的法律纠纷将延迟或将你的产品开发完全停止,无论法律结果如何都会造成负面公众影响。

另一个风险是意外地包含了许可相互冲突的组件。在这种情况下,在任何情况下都不能把两个组件一起使用;他们的许可条款是相抵触的。

您应该了解有毒的许可,对其进行管理,并在这些许可之上实施您机构的策略。

从机构来说,重要的是有策略,确定哪些开源许可与你的业务和产品兼容,哪些不兼容。一旦有了策略,你就可以使用合适的工具来跟踪第三方组件的使用情况,并确保你的产品符合该策略。


工欲善其事,必先利其器

人工管理供应链的安全风险几乎是不可能的,但许多机构仍然在这样做,使用电子表格或其他原始工具。Cybellum的V-Ray平台将这些关键任务自动化,使得软件供应链管理成为可操作的实时的流程。

第一步是确定产品中的内容,全面了解构建产品的所有组件,类似于产品的成分列表。

一旦看得的到产品的组件构成,V-Ray就会执行额外分析。从安全的角度看,V-Ray根据产品中的所有组件找到其中公开的和未知的漏洞。这是了解风险的快速准确的方法。重要的是,V-Monitor 跟踪漏洞源,能够在新漏洞或新攻击技巧对你的产品组件施加风险时来告警。

解决方案还可识别与第三方组件相关的许可,并判断所用组件是否符合你的策略。在部署之前实施这类分析,它启用一个流程确保产品中仅包含合适的第三方组件。

组件清单

了解软件的供应链,获取软件的组成清单,然后使用这个清单来分析漏洞对于管理安全风险至关重要。

V-Ray自动分析固件所有开源的、商业化的以及专有的子组件,并生成最完整最准确的组件清单。


发布更安全的产品

经过半个世纪令人难以置信的创新和增长,软件行业日趋成熟并发展成为真正的工程学科。尽管构建软件以往是对功能的疯狂冲刺,现代软件工程涉及DevOps流程,流程的每个步骤都确保安全性、稳定性和耐用性。

供应链安全管理是构建产品的关键部分,有效的供应链安全管理降低了安全风险,从而为每个人创造更美好的世界。软件购买方在采购流程中通过检查它们构建者的供应链管理了解软件的组件构成,软件开发商管理他们自己的产品确保最少的漏洞。 最终客户因开发者和购买方有效地管理他们供应链安全性而受益,整个生态系统变得更加安全,更加可靠和更有保障。


汽车行业

V-Ray是功能强大的二进制分析平台,可帮助汽车制造商保护其供应链。V-Ray以快速且可扩展的方式检查二进制文件,深入了解软件组件的质量、安全性和合法性。

一辆现代汽车有超过1亿行的软件代码。随着车载软件的增长,攻击面也随之增大,这使得其更容易受到网络攻击。每个不良构建的软件都代表一个攻击者可以利用的潜在漏洞,每个漏洞就是一个潜在的召回。

保护汽车软件供应链非常困难,原因是:

● 供应链的复杂性 --- 汽车软件是由多层供应商构建的,没有既定标准。

● 源代码访问 --- 供应链中的供应商不提供软件的源代码,也不会提供他们使用的第三方库的列表。

● 人工检查的成本高昂 --- 为每种车型人工检查迭代生成的1亿行代码将花费数千工程师数年的工作。

Cybellum解决方案对汽车行业而言功能强大,因为:

● 这是一个可定制的平台,提供精确的可执行的洞察力。

● 检查二进制文件是否存在已知的和未知的安全漏洞,并促进符合标准。

● 提供在用软件许可的详细列表,并识别与所需策略的冲突和偏差。

● 通过添加和定制“执行程序”,可持续地增强功能。

● 帮助公司在整个软件供应链中达到OEM定义的保证标准,无论是供应商还是在开发流程阶段。


弥补缺口

与定期接收更新和补丁的传统IT软件不同,在汽车行业,组件在通过验收测试和初始集成时就经常达到其使用寿命(EOL)。

随着组件开始联网,汽车厂商不再保持未打补丁状态,协商每个新的修复和更新。Cybellum专有的二进制分析技术提供针对从配置问题到缓冲区溢出一系列漏洞的自动创建的热补丁。这项独特的功能可以施加热补丁,直到发布正式补丁,或者用在不存在源代码的旧组件之上。

热补丁使您可在任何情况下都可以给任何组件修补任何漏洞,使您高枕无忧。


产品

Cybellum V-Ray™

基于自动化漏洞检测,提供完整的组件可见性和风险评估。

自动化逆向工程并扫描固件的漏洞与安全威胁,模仿攻击者行为方式,对所扫描组件提供全面的可视化。在集成阶段操作,不用在组件加入任何代码,评估风险,采取补救措施,然后安全地发布车辆。


Cybellum V-Monitor™

根据公共的、私有的以及暗网信息来源,监控所有已部署组件是否存在新漏洞和安全威胁。该平台通过与厂商资产管理系统相结合,自动监视新漏洞并将其与上路车辆中已 部署组件相关联,并且当出现需要注意的安全问题时发出警报。

结果 --- 所有组件的威胁情报都在一个仪表盘上显示。



两种产品都可以部署在云中和客户的服务器上

可以作为OEM SOC(安全运营中心)的一部分进行部署,以完结车辆中所有组件的漏洞和风险态势


资产管理整合

Cybellum V-Monitor集成到您的标准资产管理系统中,以检索资产记录的信息{ECU,软件版本,VIN,型号,相关部位}。使用此信息(或部分信息),Cybellum V-Monitor将新漏洞的数据和威胁情报与道路上的相关车辆相对应。

在启动过程中,设置一个到您资产管理(或ERP)系统的连接器,以持续检索相关信息。


安全威胁情报

网络安全是一个瞬息万变的世界,因为安全风险是动态的,并且会随着时间而变化。单个漏洞在外被利用的风险和尚未证明其可被利用的风险完全不同。

在没全部附加信息和安全社区知识的情况下来了解你漏洞,只会让你仅仅看到并了解实际风险的一部分。

Cybellum通过实时威胁情报来将风险详细信息完善,实时威胁情报基于来自开源情报(OSINT)、社交媒体情报(SOCMINT)、技术情报以及来自于深网、暗网情报的情报收集。

漏洞的严重程度根据实时数据进行相应调整,包括:

● 监控您的专有资产

○ Emails

○ Users

○ IPs

○ URLs

● 新漏洞利用代码的发布

● 漏洞和利用代码的交易

● 使用跨不同行业已知漏洞的攻击


安全运营中心

路上行驶车辆受到的安全威胁每天增长,管理和分析这些安全威胁是了解实际风险状况和威胁态势的关键。

鉴于每天都有新漏洞爆出,应对如下简单问题:

● 哪些组件有漏洞?

● 上路车辆哪台有漏洞?

● 如何解决?

如果没合适工具,可能花费数周时间才能完成,耗时又耗费。

将Cybellum方案作为安全运营中心(SOC)的组成部分,你可以在几分钟之内主动地解决这些问题和其他许多问题。


技术

Cybellum V-Ray是用于漏洞检测的瑞士军刀,它由几个前沿技术的检测引擎构成,其唯一目标就是发现并验证实际的安全威胁。检测未知漏洞的主要算法基于机器学习技术,以如下方式工作:


学习阶段

在学习阶段,我们下载了数以千计的公开漏洞,以及我们实验室中生成与合成的数百万漏洞,提取这些漏洞的全部可能参数(从堆栈调用、method名称、参数类型、到缓冲区大小等等),将这些信息“喂”给机器学习引擎,学习出来哪个参数最有可能关联哪类漏洞。

长时间的学习完成之后,我们有了一种方法:给一段二进制就可以在该二进制中产生我们称之为“漏洞线索”的该二进制中极有可能出现的漏洞。


工作阶段

技术由两部分组成 --- 静态和动态:

● 静态 --- 静态地扫描闭源二进制文件,对其反汇编以查找已知漏洞、缺少安全缓解技术、链接问题等等,以及通过二进制文件执行学习算法来检测漏洞模式,并生成一组漏洞线索。

● 动态 --- 扫描静态引擎检索到的所有漏洞线索,并以各种方法自动地尝试触发并利用这些漏洞线索。如果能触发漏洞,就报告其严重程度和缓解措施的完整细节。

触发漏洞以确保它是真正的安全威胁并消除误报。

每个Cybellum方案发现的新漏洞或新公开的漏洞都会被添加到学习流程中用以改进算法。


高层架构




检测的漏洞类型


公开漏洞

● 多个公开的和私有的数据库获取的漏洞

● 国家漏洞数据库(NVD)

● GitHub问题跟踪器

● 开源项目bug跟踪器


内存损坏

● 缓冲区溢出 ---堆/ 栈

● 缓冲区过读 --- 堆/ 栈

● 无效页错误

● 死锁

● 整数溢出

● 空指针解引用

● 未初始化数据

● 内存释放后使用

● 同一块内存释放两次

● 非法与不匹配释放

● 除零

● 类型混淆


安全错误配置

● 地址空间布局随机化(ASLR)

● 栈溢出保护功能(SSP)

● 可执行空间保护(NX)

● 重定位表保护(RELRO)

● 栈警惕标志

● SafeSEH

● 数据执行保护(DEP)

● CFG

● 符号和剥离

● 强化源


危险的安全措施

● 最佳实践编码错误

● 错误处理问题

● 信息泄漏

○ 硬编码凭证

○ 纯文本密码

○ 哈希密码

○ 电子邮件,IP,URL,文件路径

● 加密

○ 可访问的加密密钥

○ 未加密的通信

○ 私钥

● 违反安全最佳实践

● 危险/ 不推荐使用的函数


支持的平台

支持的操作系统

● 标准Linux发行版

○ 汽车级Linux(AGL)

● Android

● QNX

● Windows

○ Windows Mobile

● NetBSD

● FreeBSD

● 专有实时操作系统

● 物联网操作系统RIOT

● Fuchsia 操作系统

● OSEK 操作系统

● VxWorks

规范框架

● AUTOSAR

● MISRA C

● CERT C

支持的硬件架构

● Renesas

○ V850

○ SuperH

● Power

● PowerPC

● Infineon

○ TriCore

● ARM Cortex-M

● ARM Cortex-A

● ARM Cortex-R

● x86

● X64

● NVIDIA AGX

○ Xavier

● MIPS

● NXP

支持的语言

● 汇编语言

● BASIC

● C

● C++

● Delphi

● Go

● Haskell

● Java

● Lisp

● OCaml

● Objective-C

● Qt

● Rust

● Swift