CN117425153B - 车联网终端的风险检测方法及装置 - Google Patents

Abstract

本申请提出一种车联网终端的风险检测方法及装置。该方法包括：服务端接收车联网终端在检测到异常事件时发送的异常事件数据；基于异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；从车联网终端获取数据需求信息对应的事件关联数据；基于异常事件数据和事件关联数据，生成车联网终端的风险分析结果。本申请检测运算由服务端执行。终端只需采集数据并上报，适用于各种性能水平的车联网终端。且由服务端确定还需车联网终端采集的数据，数据采集及传输更有针对性、更高效，能节省终端带宽和系统资源。服务端基于模型检测是否存在风险，能适用于复杂多变的车端网络安全场景，且检测准确性很高。

Description

车联网终端的风险检测方法及装置

技术领域

本申请涉及网络安全技术领域，更为具体来说，本申请涉及一种车联网终端的风险检测方法及装置。

背景技术

随着车联网行业快速发展，自动驾驶、智能座舱、远程控制、云端服务智能化、网络化等需求迅速扩大，不同设备以及网络技术的应用，使得车联网终端的网络安全风险大大增加。

目前，传统的车联网终端的安全风险检测，通常在车联网终端中配置风险检测规则，由车联网终端基于风险检测规则来确定是否出现安全风险事件。

但通过配置风险检测规则难以适应车联网场景中复杂多变的网络攻击手段，容易出现漏检的情况，对车联网终端进行风险检测的准确性不高，导致车联网终端存在很高的网络安全风险。且由车联网终端进行风险检测，占用车联网终端的很多系统资源，可能会影响到车联网终端对应的车辆的正常使用。

发明内容

基于上述技术缺陷，本申请提出了一种车联网终端的风险检测方法及装置，服务端与车联网终端协同进行风险检测，车联网终端只需采集车端的数据并上报，节省车联网终端的带宽和系统资源。服务端检测车联网终端是否存在安全风险事件，能够适用于车联网中复杂多变的车端网络安全的应用场景，且风险检测的准确性很高。

本申请第一方面提供了一种车联网终端的风险检测方法，应用于服务端，所述方法包括：

接收车联网终端在检测到异常事件时发送的异常事件数据；

基于所述异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

从所述车联网终端获取所述数据需求信息对应的所述事件关联数据；

基于所述异常事件数据和所述事件关联数据，生成所述车联网终端的风险分析结果。

本申请第二方面提供了一种车联网终端的风险检测方法，应用于车联网终端，所述方法包括：

在检测到异常事件发生时，向服务端发送所述异常事件对应的异常事件数据；

接收所述服务端基于所述异常事件数据确定的数据需求信息，所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

向所述服务端发送所述事件关联数据，以使所述服务端基于所述异常事件数据和所述事件关联数据生成所述车联网终端的风险分析结果。

本申请第三方面提供了一种车联网终端的风险检测装置，应用于服务端，所述装置包括：

接收模块，用于接收车联网终端在检测到异常事件时发送的异常事件数据；

第一生成模块，用于基于所述异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

获取模块，用于从所述车联网终端获取所述数据需求信息对应的所述事件关联数据；

第二生成模块，用于基于所述异常事件数据和所述事件关联数据，生成所述车联网终端的风险分析结果。

本申请第四方面提供了一种车联网终端的风险检测装置，应用于车联网终端，所述装置包括：

发送模块，用于在检测到异常事件发生时，向服务端发送所述异常事件对应的异常事件数据；

接收模块，用于接收所述服务端基于所述异常事件数据确定的数据需求信息，所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

所述发送模块，用于向所述服务端发送所述事件关联数据，以使所述服务端基于所述异常事件数据和所述事件关联数据生成所述车联网终端的风险分析结果。

本申请第五方面提供了一种车联网终端的风险检测系统，包括服务端和车联网终端；

所述服务端，用于接收所述车联网终端在检测到异常事件时发送的异常事件数据；基于所述异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；从所述车联网终端获取所述数据需求信息对应的所述事件关联数据；基于所述异常事件数据和所述事件关联数据，生成所述车联网终端的风险分析结果；

所述车联网终端，在检测到异常事件发生时，向所述服务端发送所述异常事件对应的异常事件数据；接收所述服务端返回的所述数据需求信息；向所述服务端发送所述事件关联数据。

本申请第六方面提供了一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序以实现如第一方面或第二方面所述的方法。

本申请第七方面提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现第一方面或第二方面所述方法的步骤。

本申请的有益效果至少包括：

风险检测运算由服务端执行，车联网终端只需采集车端的数据并上报给服务端即可，车联网终端无需进行复杂运算，也无需存储大量数据，从而使得该方法能够适用于当前各种性能水平的车联网终端，提高了车联网终端的风险检测方法的普适性。且车联网终端基于异常事件的触发将异常事件数据上传给服务端，由服务端确定还需车联网终端采集哪些数据，数据的采集及传输更加有针对性、更加高效，减少了无用数据的采集和传输，能够节省车联网终端的带宽和系统资源。服务端基于预先训练的模型检测车联网终端是否存在安全风险事件，能够适用于车联网中复杂多变的车端网络安全的应用场景，且风险检测的准确性很高。

附图说明

构成说明书的一部分的附图描述了本申请的实施例，并且连同描述一起用于解释本申请的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本申请，其中：

图1示出了本申请一些实施例提供的车联网场景下车端面临的网络攻击面的示意图；

图2示出了本申请一些实施例提供的一种车联网终端的风险检测系统的示意图；

图3示出了本申请一些实施例提供的一种车联网终端的风险检测方法的流程示意图；

图4示出了本申请一些实施例提供的频繁模式树的结构示意图；

图5示出了本申请一些实施例提供的采用随机森林模型进行风险分析的流程图；

图6示出了本申请一些实施例提供的车联网终端与云端安全平台协同进行风险检测的示意图；

图7示出了本申请一些实施例提供的另一种车联网终端的风险检测方法的流程示意图；

图8示出了本申请一些实施例提供的一种车联网终端的风险检测方法的信令交互示意图；

图9示出了本申请一些实施例提供的一种车联网终端的风险检测装置的结构示意图；

图10示出了本申请一些实施例提供的另一种车联网终端的风险检测装置的结构示意图；

图11示出了本申请一示例性实施例所提供的一种电子设备的结构示意图；

图12示出了本申请一示例性实施例所提供的一种存储介质的示意图。

具体实施方式

以下，将参照附图来描述本申请的实施例。但是应该理解的是，这些描述只是示例性的，而并非要限制本申请的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本申请的概念。对于本领域技术人员来说显而易见的是，本申请可以无需一个或多个这些细节而得以实施。在其他的例子中，为了避免与本申请发生混淆，对于本领域公知的一些技术特征未进行描述。

应予以注意的是，这里所使用的术语仅是为了描述具体实施例，而非意图限制根据本申请的示例性实施例。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式。此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或附加一个或多个其他特征、整体、步骤、操作、元件、组件和/或它们的组合。

现在，将参照附图更详细地描述根据本申请的示例性实施例。然而，这些示例性实施例可以多种不同的形式来实施，并且不应当被解释为只限于这里所阐述的实施例。附图并非是按比例绘制的，其中为了清楚表达的目的，可能放大了某些细节，并且可能省略了某些细节。图中所示出的各种区域、层的形状以及它们之间的相对大小、位置关系仅是示例性的，实际中可能由于制造公差或技术限制而有所偏差，并且本领域技术人员根据实际所需可以另外设计具有不同形状、大小、相对位置的区域/层。

下面描述根据本申请的示例性实施方式。需要注意的是，下述实施方式仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。相反，本申请的实施方式可以应用于适用的任何场景。

随着车联网行业快速发展，自动驾驶、智能座舱、远程控制、云端服务智能化、网络化等需求迅速扩大，不同设备以及网络技术的应用，极大增加了车联网终端受网络攻击的攻击面，使车联网终端的安全风险增加。受限于车联网终端硬件资源限制，传统车端防护仅能采用简单的边界防护策略和权限控制等手段进行基础防护，但这种防护无法应对车辆复杂多变的攻击路径，一旦攻击者突破限制，网联汽车将受到侵害。

如图1示出了车联网场景中受网络攻击的攻击面，包括车身安全、近场通信安全、OTA（Over the Air Technology，空中下载技术）安全、云端安全、网络链路安全、应用安全、车路通信安全、车车通信安全。其中，除应用安全和云端安全外，其他攻击面均为车联网场景中车端的设备可能遭受的网络攻击面，本申请实施例将车端的设备称为车联网终端，如车载终端、车内网关、边界网关等。其中，车载终端可以包括IVI（In-VehicleInfotainment，车载信息娱乐系统）等。车内网关可以包括OBU（On board Unit，车载网关）、TBOX（Telematics Box，车载无线网关）等。

上述车身安全可以包括车内硬件、终端接口、车内网络等方面的安全。近场通信安全可以包括车辆定位、车控钥匙、车载WiFi、车载蓝牙等方面的通信安全。网络链路安全包括远控手机、蜂窝网络、管理服务等与车端的网络链路安全。车路通信安全包括道路上设置的交通标识、媒体设备、感知设备等与车辆之间的通信安全。车车通信安全包括车辆与其周围的车辆之间的通信安全。

相关技术中可以通过UEBA（User and Entity Behavior Analytics，用户与实体行为分析）技术来对终端进行风险检测及防护，UEBA主要是以用户和实体为对象，结合规则以及机器学习模型，对用户行为进行分析和异常检测，尽可能快速地感知内部用户的可疑非法行为。

但UEBA主要针对用户行为分析，主要站在人的视角，通过对用户、主机、应用程序、网络、数据库等信息进行画像描述，通过相关分析算法发现行为异常的活动所相关的潜在事件。而车端由于包含车辆驾驶状态、车身状态等特有信息，因此UEBA方案中分析算法无法适配车端安全检测的分析场景。

在另一种相关技术中，采用端点检测和响应来检测终端是否存在网络风险，通过记录终端与网络事件，例如用户，文件，进程，注册表，内存和网络事件等，并将这些信息本地存储在端点或集中数据库。结合已知的攻击指示器(Indicators of Compromise，IOCs)、行为分析的数据库来连续搜索数据和机器学习技术来监测任何可能的安全威胁。

但端点检测和响应软件需要部署在终端系统中，由于要对大量的信息进行收集、存储和分析，因此会消耗较大的计算和存储资源。由于车端系统普遍性能较低，无法承载太多的业务能力，因此无法在本地进行复杂的安全分析与处置。

以上相关技术均无法适应车联网场景下如图1所示的众多网络攻击面，使得车联网终端安全风险预警的准确性不高。且需要车联网终端进行大量的计算和存储操作，影响车联网终端的性能，进而影响车辆行驶或通信。

基于此，本申请的一些实施例提供一种车联网终端的风险检测方法，该方法由车联网终端与服务端协同进行风险检测与防护，具体检测运算由服务端执行，车联网终端只需采集车端的数据并上报给服务端即可，车联网终端无需进行复杂运算，也无需存储大量数据，从而使得该方法能够适用于当前各种性能水平的车联网终端，提高了车联网终端的风险检测方法的普适性。而且该方法利用服务端优秀的计算能力，基于深度学习算法检测车联网终端是否存在安全风险事件，检测范围能够覆盖车联网场景下车端所有可能遭受的网络攻击面，风险检测的准确性很高。检测出安全风险事件后还可以远程调用车联网终端执行防护策略，尝试阻断并清除安全风险事件，达到恢复健康的系统环境的效果。

本申请实施例提供的车联网终端的风险检测方法所基于的网络架构如图2所示，该网络架构中包括车联网终端和服务端，其中服务端可以为单个服务器、多个服务器构成的服务器集成、云服务器等，车联网终端可以为车载终端、车内网关、边界网关等。车联网终端和服务端通过网络通信连接。在本申请实施例中，车联网终端中安装有用于安全防护的SDK（Software Development Kit，软件开发工具包），负载对车辆网终端本地进行异常事件检测、采集车联网终端的数据以及与服务端进行数据交互。车联网终端与服务端协同进行车联网终端的风险检测与防护。

参见图3，本申请实施例提供的风险检测方法应用于服务端，具体包括以下步骤。

步骤101：服务端接收车联网终端在检测到异常事件时发送的异常事件数据。

车联网终端会对本地的事件进行检测，当检测到出现满足预设异常条件的异常事件时，采集该异常事件对应的异常事件数据，向服务端发送该异常事件数据。

上述预设异常条件可以包括事件占用的内存大小超过预设的内存上限值，预设时长内接收同一地址发送的流量超过预设的流量上限值，触发事件的用户不具有用户权限等。车联网终端对当前本地存在的各事件进行检测，若某事件满足预设异常条件，则将该事件确定为异常事件。

在车联网终端中异常事件可以包括操作事件和网络事件等不同类型的事件，操作事件是指对某个对象执行操作的事件，如访问内存的事件、创建进程的事件、注销进程的事件等。网络事件是指与其他设备通信相关的事件，如接收报文的事件、发送报文的事件等。

上述异常事件数据包括能够表征该异常事件的产生、经过和结果的所有数据。若异常事件为操作事件，则上述异常事件数据包括事件来源、用户信息、事件产生时间、事件行为信息、操作目标信息、操作结果、操作日志等信息。其中，事件来源包括执行该操作事件的进程标识，用户信息包括触发执行该操作事件的用户的标识，事件行为信息用于表征该操作事件执行的具体操作的过程。操作目标信息为该操作事件所针对的目标对象，如若该操作事件为访问内存的操作，则操作目标信息可以包括所访问的内存地址。操作结果用于表征该操作事件是否执行成功。

若异常事件为网络事件，则异常事件数据包括该网络事件中报文的五元组，收发该报文的进行表示、该报文的原始数据、相关地址的其他流量信息等。其中，相关地址的其他流量信息可以包括报文的五元组中源地址发送给该车联网终端的其他报文，或该车联网终端发送该上述报文的五元组中的目的地址的其他报文等。

在本申请的一些实施例中，异常事件数据除包括上述事件的数据外，还可以包括车联网终端的相关信息以及车联网终端对应的车辆的相关信息，如车联网终端的终端类型、系统类型、车辆行驶状态、车身状态等。其中，终端类型可以包括车载单元、车内网关、边界网关等类型，系统类型可以包括Linux、X86等类型，车辆行驶状态可以包括加速行驶、减速行驶、匀速行驶等，车身状态可以包括启动状态或静止状态等。

车联网终端检测到异常事件时，主动向服务端发送异常事件数据，从而触发服务端对该车联网终端进行网络安全的风险检测，实现基于异常事件触发风险检测。且风险检测由服务端进行检测，车联网终端只需采集异常事件数据并上报给服务端，即可触发风险检测流程，车联网终端无需进行复杂的运算处理，也无需存储与风险检测相关的大量数据，节省了车联网终端的系统资源，从而不会因风险检测影响到车联网终端的系统性能。

步骤102：服务端基于异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；该数据需求信息用于指示车联网终端采集与异常事件相关的事件关联数据。

上述频繁模式模型可以采用FP-growth（Frequent Pattern growth）算法。频繁模式模型是对第一预设维度的事件特征与数据需求信息所属事件关联数据对应的第二预设维度的事件特征之间的关联关系进行学习得到的。上述事件关联数据指除异常事件数据以外与异常事件相关的所有数据。上述数据需求信息可以包括事件关联数据中各数据的参数标识，车联网终端可以基于该数据需求信息中的参数标识来采集参数标识对应的具体数据。

服务端接收到车联网终端上传的异常事件数据后，基于该异常事件数据，确定异常事件数据对应的异常事件类型。从异常事件类型和异常事件数据中提取第一预设维度下的事件特征。其中，异常事件类型就是一个第一预设维度的事件特征。将提取的事件特征输入预先训练的频繁模式模型，输出数据需求信息。其中，频繁模式模型是对第一预设维度的事件特征与数据需求信息对应的第二预设维度的事件特征之间的关联关系进行学习得到的。其中，数据需求信息对应的第二预设维度的事件特征，即为上述事件关联数据的事件特征。

上述异常事件类型包括网络攻击类型、网络事件类型、操作事件类型等。其中，网络攻击类型为外部对车联网终端实施的外到内的网络攻击，如后门攻击、密码攻击、植入木马等。网络事件类型可以包括车联网终端内部产生的异常流量。操作事件类型可以包括系统执行的异常形成，如车联网终端遭受病毒攻击导致系统执行注销正在执行的进程或修改系统配置等行为。

服务端基于该异常事件数据中包括的具体数据来确定异常事件类型。例如，服务端基于异常事件数据中包括报文的五元组、接收该报文的进程的表示，该报文的原始数据等信息，确定该异常事件数据属于网络攻击类型。

服务端确定异常事件类型后，从异常事件类型和异常事件数据中提取第一预设维度下的事件特征。其中，第一预设维度可以是基于异常事件类型及异常事件数据包括的内容设置的，第一预设维度可以包括异常事件类型、车联网终端的系统类型、终端类型、车辆行驶状态、车身状态等。

服务端将提取出的第一预设维度的事件特征输入到训练好的频繁模式模型中，输出数据需求信息，该数据需求信息能够指示判断该车联网终端是否存在安全风险还需要采集哪些数据，也就是说该数据需求信息能够指示上述事件关联数据。

上述频繁模式模型的训练过程包括，获取样本集，该样本集涵盖了每种异常事件类型的异常事件样本，且每种异常事件类型的样本数目相等或样本数目之间的差值小于阈值。如此各类异常事件类型的样本数目分布比较均匀，能够使得后续训练出的频繁模式模型在出现各类异常事件类型的异常事件的情况下，都能够准确地分析出数据需求信息。

而且，上述样本集还可以涵盖各种车联网终端中产生的各类异常事件类型的异常事件样本，例如分别从各种车联网终端中获取相同数目的异常事件样本，且从每种车联网终端中获取的异常事件样本包括各类异常事件类型的样本，每类异常事件类型的样本数目相同或相近。上述各种车联网终端包括车载终端、车内网关、边界网关等。

例如，分别对车辆智能终端TBOX、IVI、OBU、智能网关等设备上分别抽取1000条异常事件样本，要求样本中的事件类型按照网络攻击类型、网络事件类型、操作事件类型等进行均匀分布。其中网络攻击类型可以包括后门植入、DDoS（Distributed Denial ofService，分布式拒绝服务）攻击、中间人攻击、密码攻击、提权攻击等。

对于每种异常事件类型，获取属于该异常事件类型的多个异常事件样本，构成上述样本集。其中，异常事件样本包括异常事件数据和对应的事件关联数据，事件关联数据中包含数据需求信息，该数据需求信息中包括其所属的事件关联数据中的参数标识。对于每个异常事件样本，基于该异常事件样本，提取第三预设维度下的事件特征。其中，第三预设维度包括第一预设维度和第二预设维度，其中第一预设维度为异常事件数据中包括的具体数据的维度，第二预设维度为异常数据对应的事件关联数据中包括的具体数据的维度。

第一预设维度可以包括异常事件类型、车联网终端的系统类型、终端类型、车辆行驶状态、车身状态等。第二预设维度可以包括网络流量大小、网络流量并发数、网络流量频率、进程信息、系统日志、总线通信日志、总线通信频率等。第三预设维度可以包括异常事件类型、车联网终端的系统类型、终端类型、车辆行驶状态、车身状态、网络流量大小、网络流量并发数、网络流量频率、进程信息、系统日志、总线通信日志、总线通信频率等。

每个异常事件样本，都提取出上述第三预设维度的事件特征，并对每个异常事件样本对应的事件特征中的部分数据进行编码和解释等。例如，将车辆行驶状态编码为0/1，0表示运行，1表示静止。将车身状态编码为[001-XXX]，不同的编号表示车身状态的不同告警信息，如001-000表示胎压故障告警，001-111表示发动机故障告警等。对于网络流量大小的维度，统计最大报文长度以及每秒总流量数。对于网络流量并发的维度，统计每秒平均并发数量以及最大并发数量。对于网络流量频的维度，提取单个进程周期内流量平均间隔时间以及最小间隔时间。对于进程信息的维度，统计终端进程列表以及相关资源占用情况。对于总线通信频率的维度，统计终端与总线交互周期流量平均间隔时间以及最小间隔时间。

基于每个异常事件样本的事件特征，训练频繁模式模型。具体地，基于每个异常事件样本的事件特征，构建频繁模式树。在本申请实施例中可以采用FP-growth模型来构建频繁模式树。在构建频繁模式树过程中，首先统计每个异常事件样本的事件特征中各事件特征重复出现的次数，删除出现次数小于预设频繁阈值的事件特征，该预设频繁阈值可以为1或2等。基于统计的事件特征及对应的出现次数，来构建频繁模式树。具体可以按照一定的特征排列顺序来构建从根到叶子的各节点。例如，按照终端类型、系统类型、网络流量、总线数据、进程、异常事件类型等特征排列属性来构建频繁模式树，每个节点记录事件特征及该事件特征出现的次数。

如图4所示的频繁模式树的示意图，该频繁模式树中根节点是空的，第一层叶子节点记录的是不同的终端类型及终端类型对应的出现次数，如在所有异常事件样本中，TBOX出现的次数为100次，IVI为300次，OBU为50次。第二层叶子节点记录的是不同终端类型下的各系统类型对应的出现次数，如在出现次数为100次的TBOX中，操作系统为Linux的TBOX的数目为40，操作系统为android的TBOX的数目为60。在出现次数为300次的IVI中，操作系统为Linux的IVI的数目为100，操作系统为android的IVI的数目为200。第三层叶子节点记录的是网络流量，在操作系统为Linux的TBOX中出现网络流量的次数为30。第四层叶子节点记录的是总线数据、进程及DoS攻击，其中在上一层出现次数为30的网络流量中出现总线数据的为5次，出现进程的次数为10次，出现DoS攻击的次数为2次。最后一层叶子节点记录的是一些异常事件类型，如图4中所示的远程控制出现5次，非法外联出现8次，病毒植入出现3次。

通过上述方式构建出频繁模式树之后，基于频繁模式树和上述第一预设维度，构建各类事件异常类型对应的条件模式基。其中，条件模式基包括从根节点到事件异常类型所在的叶子节点的路径上各节点记录的事件特征以及该事件异常类型的出现次数，该出现次数也表征了该条件模式基中各事件特征构成的组合在所有异常事件样本中出现的次数。

例如，构建的条件模式基可以如表1所示，以远程控制为例，条件模式基{总线，网络流量，linux，TBOX：5}表示，在总线-网络流量-linux-TBOX组合的情况下出现远程控制的次数为5次。条件模式基{总线，应用，android，IVI：3}表示，在总线-应用-android-IVI组合的情况下出现远程控制的次数为3次。

表1

通过上述方式构建出各类事件异常类型对应的条件模式基之后，从每个异常事件样本在第三预设维度下的事件特征中，分别查询各条件模式基对应的第三预设维度的事件特征。其中，条件模式基对应的第三预设维度的事件特征中包括该条件模式基所对应的第一预设维度的事件特征，该第一预设维度的事件特征也就是该条件模式基所对应的事件异常类型的异常事件样本包括的异常事件数据对应的事件特征。该条件模式基对应的第三预设维度的事件特征还包括第二预设维度的事件特征，该第二预设维度的事件特征即为该条件模式基所对应的事件异常类型的异常事件样本包括的事件关联数据对应的事件特征。

查询出各条件模式基对应的第三预设维度的事件特征之后，根据各条件模式基对应的第三预设维度的事件特征，构建频繁模式森林，将频繁模式森林作为频繁模式模型。具体地，对于每个条件模式基，根据该条件模式基对应的第三预设维度的事件特征，构建一颗频繁模式子树。其中，频繁模式子树的各节点中可以分别记录有一个维度的事件特征的参数标识。获得各条件模式基对应的频繁模式子树之后，将所有的频繁模式子树组成频繁模式森林，该频繁模式森林即为训练得到的频繁模式模型。

由于上述频繁模式模型中的每个频繁模式子树中既包括第一预设维度的事件特征，又包括第二预设维度的事件特征。因此在已知异常事件对应的异常事件数据的情况下，可以从异常事件数据中提取出第一预设维度的事件特征，将提前出的第一预设维度的事件特征输入到该频繁模式模型中，即可查询出对应的第二预设维度的事件特征，将第二预设维度的事件特征对应的参数标识组成数据需求信息。

在构建条件模式基时基于数目更少的第一预设维度进行构建，能够缩减算法规模，减少计算量，快速从数据量较大的频繁模式树中抽取出各异常事件类型对应的条件模式基，提高计算效率。

在本申请的另一些实施例中，在训练获得频繁模式模型的过程，还可以基于从异常事件类型对应的异常事件样本提取出的第三预设维度的事件特征，以及基于该异常事件类型对应的条件模式基查找出的第三预设维度的事件特征，计算查找出的数据与从样本中的提取出的数据之间的误差。基于各类异常事件类型对应的误差计算模型训练的损失值。基于该损失值调整模型参数，基于调整后的模型参数继续按照上述过程循环迭代，直至迭代次数达到预设次数，或直至损失值小于阈值时停止训练，得到训练好的频繁模式模型。

在服务端接收到车联网终端上传的异常事件数据，并确定对应的异常事件类型后，也从该异常事件类型和异常事件数据中提取出第一预设维度下的事件特征。并将该事件特征输入到训练好的频繁模式模型中，从该频繁模式模型中查询出对应的第三预设维度的事件特征。从查询出的第三预设维度的事件特征中剔除第一预设维度的事件特征，得到第二预设维度的事件特征。将第二预设维度的事件特征的参数标识组成参数列表，将该参数列表作为数据需求信息。该数据需求信息即为当前进行风险检测还需要进一步获取的参数列表。

通过频繁模式模型来确定风险检测进一步需要获取的数据，以便后续再从车联网终端获取这些数据，这样在车联网终端检测到异常事件时只需上传异常事件数据，由服务端确定后续检测需要什么数据，如此能够减少车联网终端与服务端之间传输无用数据的情况发生，节省车联网终端的带宽，且车联网终端只需进行数据采集和发送，无需进行计算，对车联网终端的系统资源占用较少。

而且服务端利用频繁模式模型来确定数据需求信息，本申请实施例简化了频繁模式模型中生成条件模式基所采用的特征维度的数目，简化了算法规模，大大减小了计算量，提高了计算效率。

步骤103：服务端从车联网终端获取数据需求信息对应的事件关联数据。

服务端通过上述步骤102的操作确定出数据需求信息之后，向车联网终端发送该数据需求信息。车联网终端接收该数据需求信息，基于该数据需求信息中携带的各参数标识，采集各参数标识对应的数据，本申请实施例将基于数据需求信息采集的数据统称为事件关联数据。车联网终端向服务端发送该事件关联数据，服务端接收该事件关联数据。

其中，事件关联数据可以包括除异常事件数据外与当前的异常事件相关的所有数据。例如，事件关联数据可以包括与当前的异常事件相关的系统、车辆、总线、进程、接口等各方面的信息。

步骤104：服务端基于异常事件数据和事件关联数据，生成车联网终端的风险分析结果。

服务端从车联网终端获得事件关联数据后，基于当前异常事件对应的异常事件数据和事件关联数据，通过预先训练的风险分析模型生成车联网终端的风险分析结果。

服务端可以先对异常事件数据和事件关联数据进行预处理，比如将异常事件数据和事件关联数据中包括的所有信息按照时间先后顺序进行排序，将所有信息按照程序进行分类等。其中，按照程序分类可以划分成属于总线收发程序的信息、属于网络通信的信息、属于日志的信息等。

服务端将预处理后的数据输入预先训练的风险分析模型进行处理，输出风险分析结果。该风险分析模型可以是随机森林模型、支持向量机等。风险分析结果包括用于指示是否存在安全风险事件的指示信息，若存在安全风险事件，则风险分析结果中还包括该安全风险事件的风险类型、风险等级以及影响范围信息等。其中，影响范围信息用于指示存在的安全风险事件只影响当前车联网终端对应的单个车辆，还是影响车联网终端对应的车辆以及该车辆周围与该车辆通信的其他车辆，或者影响某个网络范围内的所有车辆等。

上述风险分析模型的训练过程可以包括，获取样本集，对样本集中每个样本提取第三预设维度下的事件特征，提取事件特征过程中进行编码操作等。这些操作均与上文训练频繁模式模型过程中的相应操作的过程相同，在此不再赘述。

利用处理后的数据训练风险分析模型。以风险分析模型为随机森林模型为例，利用处理后的数据构建随机森林，通过调整随机森林中树的数量、深度、特征数量等信息，观察基尼系数、执行效率等数据，使得构建的随机森林达到最优，得到训练好的随机森林模型。在应用该随机森林模型的过程中，将当前的异常事件数据和事件关联数据也按照上述方式进行特征提前及处理，将处理后的数据输入到训练后的随机森林模型中，通过随机森林模型中不同的树分类器对信息进行风险评估，最终将所有树分类器的结果汇总到随机森林模型的主程序中，通过投票机制获得最终的风险评估结果。利用随机森林模型来生成风险分析结果并进行预警和响应的过程如图5所示。

通过上述方式获得车联网终端的风险分析结果，若风险分析结果指示车联网终端当前不存在安全风险事件，则服务端向车联网终端发送无风险的提示信息。车联网终端接收到该提示信息，确定当前不存在安全风险。或者，服务端不向终端反馈，终端超过一定时长未接收到服务端反馈信息，则确定当前不存在安全风险。

若风险分析结果指示车联网终端当前存在安全风险事件，则服务端可以向车联网终端发送预警信息。车联网终端接收该预警信息后，可以通过人机交互装置向用户提示当前存在安全风险。

在存在安全风险事件的情况下，服务端还可以基于风险分析结果，通过预设的解决方案模型获得建议策略列表，该建议策略列表中包括建议策略信息与权重值的映射关系向车联网终端发送建议策略列表中权重值最大的建议策略信息。

上述解决方案模型可以包括专家模型和机器学习模型中的至少一种。其中，专家模型中可以存储有风险类型、建议策略信息及权重值的映射关系。机器学习模型为利用过去出现过的风险类型、影响范围信息、所采用的有效的建议策略信息等数据训练得到的模型。

在风险分析结果指示存在安全风险事件时，从风险分析结果中获取风险类型及影响范围信息，基于风险类型、影响范围信息及前述的异常事件类型、异常事件数据、事件关联数据，通过上述专家模型和/或机器学习模型生成建议信息列表，该建议信息列表中包括建议策略信息与权重值的映射关系，包括至少一个建议策略信息，权重值用来表征建议策略信息解决安全风险事件的效果的大小。

获得建议策略列表后，服务端向车联网终端发送该建议策略列表中权重值最大的建议策略信息。该建议策略信息中包括防护策略和评估规则，防护策略中包括防护指令，车联网终端执行该防护策略中的防护指令对应的防护操作。

上述评估规则中包括评估上述防护策略的防护效果所需要采集的参数标识。车联网终端执行完上述防护操作后，基于该评估规则包括的参数标识采集评估数据，向服务端发送评估数据。其中，评估数据可以包括车联网终端当前在系统、网络、进程、车辆状态等多个方面的数据。

服务端接收车联网终端返回的评估数据。基于评估数据，确定车联网终端是否仍存在安全风险事件。具体地，可以将评估数据输入风险分析模型中，基于输出的风险分析结果确定车联网终端中是否仍存在安全风险事件。若确定不再存在安全风险事件，则表明发送给车联网终端的建议策略信息能够解决该安全风险事件，存储本次风险检测及防护过程中的所有数据，以便后续追溯分析或取证。

若基于评估数据确定仍存在安全风险事件，则向车联网终端发送建议策略列表中权重值次大的建议策略信息。车联网终端按照上述过程再次执行对应的防护操作并返回评估数据，如此循环执行，直至确定车联网终端中不存在安全风险事件或建议策略列表中的所有建议策略信息均已发送给车联网终端为止。

当多次发送建议策略信息后确定车联网终端中不再存在安全风险事件，则将最后一次发送给车联网终端的建议策略信息对应的权重值增大。

在确定存在安全风险事件时，下发建议策略信息给车联网终端，以尝试阻断安全风险事件，并对防护策略的实施结果进行评估，能够减少车联网终端受到安全风险事件持续迫害的情况，提升对车端的安全防护能力。

在本申请的另一些实施例中，还在服务端中预先配置预设车辆状态对应的定期巡检周期以及启动风险检测所需满足的定期巡检策略。其中，预设车辆状态包括行驶状态和静止状态等。

不同的车辆状态设置不同的定期巡检周期。由于车辆处于行驶状态下，车联网终端的系统资源需要更专注于行驶控制，若在行驶状态下频繁地进行风险检测，可能会影响车联网终端对车辆行驶的控制，导致影响行驶状态下的通信稳定性或车辆行驶的安全性。因此本申请实施例中，对于行驶状态下设置的定期巡检周期要长于静止状态设置的定期巡检周期。例如，对行驶状态设置的定期巡检周期可以为每周或每月检测一次等。而对静止状态设置的定期巡检周期可以为每一天或两天检测一次等。预设车辆状态对应的定期巡检策略用于判断当前车联网终端是否处于该预设车辆状态，该定期巡检策略可以包括车辆的速度、车辆行驶状态、车身状态等所需要满足的条件。

若服务端检测到当前时间到达预设车辆状态对应的定期巡检周期，则从车联网终端获取终端状态信息，该终端状态信息包括车辆的速度、车辆行驶状态、车身状态等。确定终端状态信息是否符合预设车辆状态对应的定期巡检策略，若符合定期巡检策略，则向车联网终端发送数据采集请求。接收车联网终端基于数据采集请求返回的终端环境数据。终端环境数据包括车联网终端当前在系统、网络、进程、车辆等多方面的数据。基于终端环境数据，通过预先训练的风险分析模型生成车联网终端的风险分析结果。

定期巡检方式能够有效避免因终端识别能力滞后，无法识别新型攻击事件，导致基于事件触发的安全风险分析逻辑无法执行的问题。

为了帮助进一步理解本申请实施例提供的风险检测方法，下面结合图6，以服务端为云端安全平台，与车联网终端协同进行风险检测和安全防护为例进行说明。如图6所示，车联网终端中安装有安全装置SDK，该安全SDK的核心功能包括：1、安全防御，内置防御模块，具备基本异常事件识别能力以及针对网络、进程阻断处置能力。2、信息收集，通过hook、日志、命令等方式采集相关环境数据信息。3、联合防御，通过针对性策略以及升级方式，抵御攻击实施。云端安全平台具备的功能包括：1、数据关联，通过分析异常事件、关联事件可能世界到的车端数据，并通知车端进一步采集。2、安全AI模型学习和匹配、威胁前置研判，AI算法判断恶意行为，对可疑车辆行为进行提示信息下发，提示威胁。如图6所示，车联网终端负责采集数据并上传给云端安全平台，云端安全平台基于车联网终端采集的数据下发处置指令给车联网终端。

在本申请实施例中，风险检测运算由服务端执行，车联网终端只需采集车端的数据并上报给服务端即可，车联网终端无需进行复杂运算，也无需存储大量数据，从而使得该方法能够适用于当前各种性能水平的车联网终端，提高了车联网终端的风险检测方法的普适性。且车联网终端基于异常事件的触发将异常事件数据上传给服务端，由服务端确定还需车联网终端采集哪些数据，数据的采集及传输更加有针对性、更加高效，减少了无用数据的采集和传输，能够节省车联网终端的带宽和系统资源。服务端基于预先训练的模型检测车联网终端是否存在安全风险事件，能够适用于车联网中复杂多变的车端网络安全的应用场景，且风险检测的准确性很高。

本申请的另一些实施例还提供了一种车联网终端的风险检测方法，该方法应用于车联网终端，参见图7，该方法具体包括以下步骤。

步骤201：车联网终端在检测到异常事件发生时，向服务端发送异常事件对应的异常事件数据。

步骤202：车联网终端接收服务端基于异常事件数据确定的数据需求信息，该数据需求信息用于指示车联网终端采集与异常事件相关的事件关联数据。

步骤203：车联网终端向服务端发送事件关联数据，以使服务端基于异常事件数据和事件关联数据生成车联网终端的风险分析结果。

本申请实施例实现了基于异常事件触发风险检测方案，车联网终端检测到异常事件时只需向服务端发送异常事件数据，无需发送其他与异常事件无关的数据，能够节省车联网终端的带宽。由服务端确定进行风险检测需要进一步采集的数据，车联网终端基于服务端反馈的数据需求信息进一步采集并反馈事件关联数据，提高了车联网终端与服务端之间数据交互的精准性。由服务端进行风险检测的具体计算过程，不占用车联网终端的系统资源。

在本申请的另一些实施例中，还提供对车联网终端进行定期巡检的方案，车联网终端接收服务端在达到预设车辆状态对应的定期巡检周期时发送的终端状态获取请求，向服务端发送车联网终端当前的终端状态信息，接收服务端在终端状态信息符合预设车辆状态对应的定期巡检策略时发送的数据采集请求，基于数据采集请求，向服务端发送终端环境数据，以使服务端基于终端环境数据生成车联网终端的风险分析结果。

定期巡检方式能够有效避免因终端识别能力滞后，无法识别新型攻击事件，导致基于事件触发的安全风险分析逻辑无法执行的问题。

在本申请的另一些实施例中，车联网终端还接收服务端发送的建议策略信息，其中，建议策略信息为服务端确认风险分析结果指示车联网终端存在安全风险事件的情况下发送的。执行建议策略信息包括的防护策略对应的防护操作。执行完防护操作后，基于建议策略信息包括的评估规则采集评估数据，向服务端发送评估数据，以使服务端基于评估数据确定车联网终端中是否仍存在安全风险事件。

本申请实施例中服务端以及车联网终端执行的具体操作以及执行的操作所能达到的技术效果，均可以参考上述应用于服务端的各实施例中的相应描述，在此不再追溯。

在本申请实施例中，车联网终端只需采集车端的数据并上报给服务端即可，车联网终端无需进行复杂运算，也无需存储大量数据，从而使得该方法能够适用于当前各种性能水平的车联网终端，提高了车联网终端的风险检测方法的普适性。且车联网终端基于异常事件的触发将异常事件数据上传给服务端，由服务端确定还需车联网终端采集哪些数据，数据的采集及传输更加有针对性、更加高效，减少了无用数据的采集和传输，能够节省车联网终端的带宽和系统资源。

为了便于理解本申请实施例的车联网终端的风险检测方法，下面结合图8来进一步说明服务端与车联网终端之间的交互过程。如图8所示，对于基于事件触发的流程，车联网终端检测到异常事件，向服务端发送异常事件数据。服务端获取异常事件数据后，识别异常事件类型。基于异常事件数据和异常事件类型，通过预先训练的频繁模式模型确定数据需求信息，下发数据需求信息给车联网终端。车联网终端根据数据需求信息采集事件关联数据，该事件关联数据包括车辆状态、系统状态、网络流量、用户日志等信息。车联网终端向服务端发送该事件关联数据。

服务端接收事件关联数据，对异常事件数据和事件关联数据进行预处理，然后通过预先训练的风险分析模型判断是否存在安全风险事件，如果否则流程结束。如果是，则基于风险分析模型输出的风险分析结果以及上述异常事件数据和事件关联数据，下发建议策略信息给车联网终端。车联网终端接收建议策略信息，执行其中的防护策略，然后基于建议策略信息中的评估规则收集评估数据，向服务端发送评估数据。服务端基于评估数据判断是否仍存在风险，如果否则结束流程。如果是，返回下发建议策略信息给车联网终端的步骤循环执行。

对于定期巡检流程，确定到达定期巡检周期，下发数据采集任务给车联网终端，后续车联网终端与服务端的操作与上述事件触发流程的操作相同，在此不再赘述。

服务端与车联网终端协同进行风险检测和安全防护，能够适用与车联网中复杂多变的车端网络安全现状，无需占用车联网终端太多的系统资源，不会对车端的正常通信和车辆使用造成影响。

本申请的另一些实施例还提供一种车联网终端的风险检测系统，如图2所示，该系统包括服务端和车联网终端；

服务端，用于接收车联网终端在检测到异常事件时发送的异常事件数据；基于异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；数据需求信息用于指示车联网终端采集与异常事件相关的事件关联数据；从车联网终端获取数据需求信息对应的事件关联数据；基于异常事件数据和事件关联数据，生成车联网终端的风险分析结果；

车联网终端，用于在检测到异常事件时，向服务端发送异常事件对应的异常事件数据；接收服务端返回的数据需求信息；向服务端发送事件关联数据。

本申请实施例提供的车联网终端的风险检测系统与本申请实施例提供的车联网终端的风险检测方法出于相同的申请构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施例还提供一种车联网终端的风险检测装置，用于执行上述任一实施例中的车联网终端的风险检测方法中服务端所执行的操作，如图9所示，该装置包括：

接收模块301，用于接收车联网终端在检测到异常事件时发送的异常事件数据；

第一生成模块302，用于基于异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；数据需求信息用于指示车联网终端采集与异常事件相关的事件关联数据；

获取模块303,用于从车联网终端获取数据需求信息对应的事件关联数据；

第二生成模块304，用于基于异常事件数据和事件关联数据，生成车联网终端的风险分析结果。

第一生成模块302，用于基于异常事件数据，确定异常事件数据对应的异常事件类型；从异常事件类型和异常事件数据中提取第一预设维度下的事件特征；将事件特征输入预先训练的频繁模式模型，输出数据需求信息；所述频繁模式模型是对所述第一预设维度的事件特征与所述数据需求信息所属事件关联数据对应的第二预设维度的事件特征之间的关联关系进行学习得到的。

该装置还包括：模型训练模块（图中未示出），用于对于每种异常事件类型，获取属于该异常事件类型的多个异常事件样本，异常事件样本包括异常事件数据和对应的事件关联数据；所述事件关联数据包含数据需求信息；对于每个异常事件样本，从异常事件样本中提取第三预设维度下的事件特征；第三预设维度包括第一预设维度和第二预设维度；基于每个异常事件样本的事件特征，训练频繁模式模型。

上述模型训练模块，具体用于基于每个异常事件样本的事件特征，构建频繁模式树；基于频繁模式树和第一预设维度，构建各类事件异常类型对应的条件模式基；从每个异常事件样本的事件特征中，分别查询各条件模式基对应的所述第三预设维度的事件特征；根据各条件模式基对应的所述第三预设维度的事件特征，构建频繁模式森林，将所述频繁模式森林作为所述频繁模式模型。

该装置还包括：巡检模块（图中未示出），用于若当前时间到达预设车辆状态对应的定期巡检周期，从车联网终端获取终端状态信息；确定终端状态信息是否符合预设车辆状态对应的定期巡检策略；若符合定期巡检策略，则向车联网终端发送数据采集请求；接收车联网终端基于数据采集请求返回的终端环境数据；基于终端环境数据，执行生成车联网终端的风险分析结果的操作。

该装置还包括：策略下发模块（图中未示出），用于若风险分析结果指示车联网终端存在安全风险事件，则基于风险分析结果，通过预设的解决方案模型获得建议策略列表，建议策略列表中包括建议策略信息与权重值的映射关系；向车联网终端发送建议策略列表中权重值最大的建议策略信息。

建议策略信息包括防护策略和评估规则；上述策略下发模块，还用于接收车联网终端在执行防护策略后、基于评估规则采集的评估数据；根据评估数据，确定车联网终端是否存在安全风险事件；若存在安全风险事件，则向车联网终端发送建议策略列表中权重值次大的建议策略信息，并继续执行所述接收所述车联网终端在执行所述防护策略后、基于所述评估规则采集的评估数据的步骤，直至确定车联网终端中不存在安全风险事件或建议策略列表中的所有建议策略信息均已发送给车联网终端为止；当多次发送建议策略信息之后，若确定车联网终端中不再存在安全风险事件，则将最后一次发送给车联网终端的建议策略信息对应的权重值增大。

本申请实施例提供的车联网终端的风险检测装置与本申请实施例提供的车联网终端的风险检测方法出于相同的申请构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施例还提供一种车联网终端的风险检测装置，用于执行上述任一实施例中的车联网终端的风险检测方法中车联网终端所执行的操作，如图10所示，该装置包括：

发送模块401，用于在检测到异常事件发生时，向服务端发送异常事件对应的异常事件数据；

接收模块402，用于接收服务端基于异常事件数据确定的数据需求信息，数据需求信息用于指示车联网终端采集与异常事件相关的事件关联数据；

发送模块401，还用于向服务端发送事件关联数据，以使服务端基于异常事件数据和事件关联数据生成车联网终端的风险分析结果。

接收模块402，还用于接收服务端在达到预设车辆状态对应的定期巡检周期时发送的终端状态获取请求，向服务端发送车联网终端当前的终端状态信息；接收服务端在终端状态信息符合预设车辆状态对应的定期巡检策略时发送的数据采集请求；

发送模块401，还用于基于数据采集请求，向服务端发送终端环境数据，以使服务端基于终端环境数据生成车联网终端的风险分析结果。

接收模块402，还用于接收服务端发送的建议策略信息，其中，所述建议策略信息为所述服务端确认所述风险分析结果指示所述车联网终端存在安全风险事件的情况下发送的；

该装置还包括策略执行模块（图中未示出），用于执行建议策略信息包括的防护策略对应的防护操作；执行完防护操作后，基于建议策略信息包括的评估规则采集评估数据；

发送模块401，还用于向服务端发送评估数据，以使服务端基于评估数据确定车联网终端中是否仍存在安全风险事件。

本申请实施例提供的车联网终端的风险检测装置与本申请实施例提供的车联网终端的风险检测方法出于相同的申请构思，具有与其采用、运行或实现的方法相同的有益效果。

下面请参考图11，其示出了本申请的一些实施方式所提供的一种电子设备的示意图。如图11所示，所述电子设备7包括：处理器700，存储器701，总线707和通信接口703，所述处理器700、通信接口703和存储器701通过总线707连接；所述存储器701中存储有可在所述处理器700上运行的计算机程序，所述处理器700运行所述计算机程序时执行本申请前述任一实施方式所提供的车联网终端的风险检测方法。

其中，存储器701可能包含高速随机存取存储器（RAM：Random Access Memory），也可能还包括非不稳定的存储器（non-volatile memory），例如至少一个磁盘存储器。通过至少一个通信接口703（可以是有线或者无线）实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。

总线707可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。其中，存储器701用于存储程序，所述处理器700在接收到执行指令后，执行所述程序，前述本申请实施例任一实施方式揭示的车联网终端的风险检测方法可以应用于处理器700中，或者由处理器700实现。

处理器700可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器700中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器700可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器701，处理器700读取存储器701中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的电子设备与本申请实施例提供的车联网终端的风险检测方法出于相同的申请构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施方式还提供一种与前述实施方式所提供的车联网终端的风险检测方法对应的计算机可读存储介质，请参考图12，图12示出的计算机可读存储介质为光盘30，其上存储有计算机程序（即程序产品），所述计算机程序在被处理器运行时，会执行前述任意实施方式所提供的车联网终端的风险检测方法。

另外，所述计算机可读存储介质的例子还可以包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器(RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

本申请的上述实施例提供的计算机可读存储介质与本申请实施例提供的车联网终端的风险检测方法出于相同的申请构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。

需要说明的是：在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备有固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

类似地，应当理解，为了精简本申请并帮助理解各个申请方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，申请方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器( DSP )来实现根据本申请实施例的虚拟机的创建装置中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序。实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种车联网终端的风险检测方法，其特征在于，应用于服务端，所述方法包括：

接收车联网终端在检测到异常事件时发送的异常事件数据；所述异常事件数据包括能够表征所述异常事件的产生、经过和结果的数据；

基于所述异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

从所述车联网终端获取所述数据需求信息对应的所述事件关联数据；

基于所述异常事件数据和所述事件关联数据，生成所述车联网终端的风险分析结果。

2.根据权利要求1所述的方法，其特征在于，所述基于所述异常事件数据，通过预先训练的频繁模式模型生成数据需求信息，包括：

基于所述异常事件数据，确定所述异常事件数据对应的异常事件类型；

从所述异常事件类型和所述异常事件数据中提取第一预设维度下的事件特征；

将所述事件特征输入预先训练的频繁模式模型，输出所述数据需求信息；所述频繁模式模型是对所述第一预设维度的事件特征与所述数据需求信息所属事件关联数据对应的第二预设维度的事件特征之间的关联关系进行学习得到的。

3.根据权利要求2所述的方法，其特征在于，所述频繁模式模型的训练过程包括：

对于每种异常事件类型，获取属于该异常事件类型的多个异常事件样本，所述异常事件样本包括异常事件数据和对应的事件关联数据；所述事件关联数据包含数据需求信息；

对于每个异常事件样本，从所述异常事件样本中提取第三预设维度下的事件特征；所述第三预设维度包括所述第一预设维度和所述第二预设维度；

基于每个异常事件样本的事件特征，训练频繁模式模型。

4.根据权利要求3所述的方法，其特征在于，所述基于每个异常事件样本的事件特征，训练频繁模式模型，包括：

基于每个异常事件样本的事件特征，构建频繁模式树；

基于所述频繁模式树和所述第一预设维度，构建各类事件异常类型对应的条件模式基；

从所述每个异常事件样本的事件特征中，分别查询各条件模式基对应的所述第三预设维度的事件特征；

根据各条件模式基对应的所述第三预设维度的事件特征，构建频繁模式森林，将所述频繁模式森林作为所述频繁模式模型。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

若当前时间到达预设车辆状态对应的定期巡检周期，从所述车联网终端获取终端状态信息；

确定所述终端状态信息是否符合所述预设车辆状态对应的定期巡检策略；

若符合所述定期巡检策略，则向所述车联网终端发送数据采集请求；

接收所述车联网终端基于所述数据采集请求返回的终端环境数据；

基于所述终端环境数据，执行所述生成所述车联网终端的风险分析结果的操作。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

若所述风险分析结果指示所述车联网终端存在安全风险事件，则基于所述风险分析结果，通过预设的解决方案模型获得建议策略列表，所述建议策略列表中包括建议策略信息与权重值的映射关系；

向所述车联网终端发送所述建议策略列表中权重值最大的建议策略信息。

7.根据权利要求6所述的方法，其特征在于，所述建议策略信息包括防护策略和评估规则；所述方法还包括：

接收所述车联网终端在执行所述防护策略后、基于所述评估规则采集的评估数据；

根据所述评估数据，确定所述车联网终端是否存在所述安全风险事件；

若存在所述安全风险事件，则向所述车联网终端发送所述建议策略列表中权重值次大的建议策略信息，并继续执行所述接收所述车联网终端在执行所述防护策略后、基于所述评估规则采集的评估数据的步骤，直至确定所述车联网终端中不存在所述安全风险事件或所述建议策略列表中的所有建议策略信息均已发送给所述车联网终端为止；

当多次发送建议策略信息之后，若确定所述车联网终端中不再存在所述安全风险事件，则将最后一次发送给所述车联网终端的建议策略信息对应的权重值增大。

8.一种车联网终端的风险检测方法，其特征在于，应用于车联网终端，所述方法包括：

在检测到异常事件发生时，向服务端发送所述异常事件对应的异常事件数据；所述异常事件数据包括能够表征所述异常事件的产生、经过和结果的数据；

接收所述服务端基于所述异常事件数据确定的数据需求信息，所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

向所述服务端发送所述事件关联数据，以使所述服务端基于所述异常事件数据和所述事件关联数据生成所述车联网终端的风险分析结果。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

接收所述服务端在达到预设车辆状态对应的定期巡检周期时发送的终端状态获取请求，向所述服务端发送所述车联网终端当前的终端状态信息；

接收所述服务端在所述终端状态信息符合所述预设车辆状态对应的定期巡检策略时发送的数据采集请求；

基于所述数据采集请求，向所述服务端发送终端环境数据，以使所述服务端基于所述终端环境数据生成所述车联网终端的风险分析结果。

10.根据权利要求8或9所述的方法，其特征在于，所述方法还包括：

接收所述服务端发送的建议策略信息，其中，所述建议策略信息为所述服务端确认所述风险分析结果指示所述车联网终端存在安全风险事件的情况下发送的；

执行所述建议策略信息包括的防护策略对应的防护操作；

执行完所述防护操作后，基于所述建议策略信息包括的评估规则采集评估数据；

向所述服务端发送所述评估数据，以使所述服务端基于所述评估数据确定所述车联网终端中是否存在所述安全风险事件。

11.一种车联网终端的风险检测装置，其特征在于，应用于服务端，所述装置包括：

接收模块，用于接收车联网终端在检测到异常事件时发送的异常事件数据；所述异常事件数据包括能够表征所述异常事件的产生、经过和结果的数据；

第一生成模块，用于基于所述异常事件数据，通过预先训练的频繁模式模型生成数据需求信息；所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

获取模块，用于从所述车联网终端获取所述数据需求信息对应的所述事件关联数据；

第二生成模块，用于基于所述异常事件数据和所述事件关联数据，生成所述车联网终端的风险分析结果。

12.一种车联网终端的风险检测装置，其特征在于，应用于车联网终端，所述装置包括：

发送模块，用于在检测到异常事件发生时，向服务端发送所述异常事件对应的异常事件数据；所述异常事件数据包括能够表征所述异常事件的产生、经过和结果的数据；

接收模块，用于接收所述服务端基于所述异常事件数据确定的数据需求信息，所述数据需求信息用于指示所述车联网终端采集与所述异常事件相关的事件关联数据；

所述发送模块，用于向所述服务端发送所述事件关联数据，以使所述服务端基于所述异常事件数据和所述事件关联数据生成所述车联网终端的风险分析结果。