A security event analysis method and apparatus

Abstract

The application provides a security event analysis method and device, and relates to the technical field of network security. The method comprises the following steps: acquiring first security log data and first audit log data recorded by a vehicle-mounted unit in a target vehicle; acquiring second security log data and second audit log data collected by a roadside device; performing extension processing on the first security log data and the second security log data to obtain extended security log data of the target vehicle; performing extension processing on the first audit log data and the second audit log data to obtain extended audit log data of the target vehicle; performing detection processing on the extended security log data and the extended audit log data by using a detection rule of a security event, and determining whether the target vehicle has a security risk; and when the target vehicle has a security risk, generating a corresponding security event according to the security risk of the target vehicle.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a security incident analysis method and apparatus. Background Technology

[0002] The Internet of Vehicles (IoV) represents a new direction for the future development of the automotive industry. Integrating technologies such as the Internet of Things (IoT), the traditional internet, and the mobile internet, the IoV provides intelligent services for smart transportation while also generating broader security challenges. The IoV involves complex communication architectures, multi-interaction paths from cloud to end, and a long upstream and downstream industry chain, all of which bring new security risks and vulnerabilities. The IoV is increasingly becoming a target of ubiquitous attacks, as evidenced by the frequent occurrence of IoV security incidents. Therefore, the analysis of IoV security incidents has become a key area of ​​concern for businesses.

[0003] Currently, the data used in analyzing security incidents in the Internet of Vehicles is relatively limited, resulting in simplistic and unreliable analysis results that fail to help users avoid alarm fatigue and misleading information.

[0004] Therefore, how to conduct in-depth analysis of security incidents in the Internet of Vehicles (IoV) and improve its security is one of the technical issues worth considering. Summary of the Invention

[0005] In view of this, this application provides a security incident analysis method and apparatus for in-depth analysis of security incidents in the Internet of Vehicles (IoV) and to improve the security of the IoV.

[0006] Specifically, this application is implemented through the following technical solution:

[0007] According to a first aspect of this application, a security incident analysis method is provided, comprising:

[0008] Obtain the first security log data and the first audit log data recorded by the on-board unit in the target vehicle;

[0009] Acquire the second safety log data and the second audit log data collected by the roadside equipment;

[0010] The first security log data and the second security log data are extended to obtain the extended security log data of the target vehicle.

[0011] The first audit log data and the second audit log data are extended to obtain the extended audit log data of the target vehicle.

[0012] The extended security log data and extended audit log data are processed using security event detection rules to determine whether the target vehicle poses a security risk.

[0013] When such a situation exists, a corresponding security event is generated based on the security risks associated with the target vehicle.

[0014] According to a second aspect of this application, a security incident analysis apparatus is provided, comprising:

[0015] The first acquisition module is used to acquire the first security log data and the first audit log data recorded by the on-board unit in the target vehicle.

[0016] The second acquisition module is used to acquire the second safety log data and the second audit log data collected by the roadside equipment.

[0017] The first extension module is used to extend the first security log data and the second security log data to obtain extended security log data of the target vehicle.

[0018] The second extension module is used to extend the first audit log data and the second audit log data to obtain extended audit log data of the target vehicle.

[0019] The detection module is used to process the extended security log data and extended audit log data using the detection rules of security events to determine whether the target vehicle has any security risks.

[0020] The generation module is used to generate a corresponding security event based on the security risks existing in the target vehicle when they exist.

[0021] According to a third aspect of this application, an electronic device is provided, including a processor and a machine-readable storage medium storing a computer program executable by the processor, the processor being prompted by the computer program to perform the method provided in the first aspect of the embodiments of this application.

[0022] According to a fourth aspect of this application, a machine-readable storage medium is provided, which stores a computer program that, when invoked and executed by a processor, causes the processor to perform the method provided in the first aspect of the embodiments of this application.

[0023] The beneficial effects of the embodiments of this application are as follows:

[0024] The security event analysis method and apparatus provided in this application embodiment acquires first security log data and first audit log data recorded by the on-board unit in the target vehicle; acquires second security log data and second audit log data collected by roadside equipment; performs extended processing on the first security log data and second security log data to obtain extended security log data of the target vehicle; performs extended processing on the first audit log data and second audit log data to obtain extended audit log data of the target vehicle; uses security event detection rules to detect and process the extended security log data and extended audit log data to determine whether the target vehicle has a security risk; when a risk exists, a corresponding security event is generated based on the security risk of the target vehicle. This application performs extended processing on the security log data and audit log data reported by the on-board unit and roadside equipment respectively, and then performs identification processing on the extended security log data and extended audit log data to determine whether the target vehicle has a security risk, and then generates a security event when a security risk is identified. This not only improves the accuracy of security risk identification results, but also avoids false alarms caused by directly treating security logs as security event alarms, and avoids user alarm fatigue. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a security event analysis method provided in an embodiment of this application;

[0026] Figure 2 This is a schematic diagram of the structure of a security event analysis device provided in an embodiment of this application;

[0027] Figure 3 This is a schematic diagram of the hardware structure of an electronic device implementing a security event analysis method, provided in an embodiment of this application. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0029] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the corresponding listed items.

[0030] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0031] The security incident analysis method provided in this application will be described in detail below.

[0032] See Figure 1 , Figure 1 This is a flowchart of a security incident analysis method provided in this application. This method is also applied to electronic devices, which may be, but are not limited to, applications on cloud platforms. For ease of description, when implementing the above method on a cloud platform, the method may include the following steps:

[0033] S101. Obtain the first security log data and the first audit log data recorded by the on-board unit in the target vehicle.

[0034] In this step, in order to ensure the safety of vehicles in the Internet of Vehicles, an Onboard Unit (OBU) will be installed in the vehicle. The OBU is the core data interaction device that makes up the intelligent connected system. The device is deployed on the vehicle and can obtain the vehicle's first security log data and first audit log data in real time through positioning.

[0035] Specifically, by deploying an IDPS system in the vehicle unit, the system detects whether the status of important vehicle components is abnormal, as well as abnormal network traffic connecting important components, to discover vehicle security alarms, thereby generating the aforementioned first security log data. In addition, the vehicle unit also has a series of security functions such as firewall, intrusion detection and prevention, deep packet inspection, and security logs, thereby ensuring the information security of the vehicle.

[0036] In addition to security logs detected based on IDPS, vehicle status audit logs can also be obtained based on the positioning system. These logs may include, but are not limited to, traffic logs and other types of logs, and are recorded as the aforementioned first audit log data. Specifically, during vehicle operation, the vehicle communicates with other road users via V2X communication protocols. V2X can be, but is not limited to, V2P, V2N, V2I, V2V, etc., where N represents an infinite number of possibilities. This allows the vehicle to know which vehicles are present in its vicinity and generate the first audit log data accordingly.

[0037] Based on this, after generating the first security log data and the first audit log data, the vehicle-mounted unit can send them to the cloud platform using a pre-defined communication method. In this way, the cloud platform can obtain the first security log data and the first audit log data.

[0038] It should be noted that the above-mentioned communication methods can be, but are not limited to, 5G and other communication methods, to be sent to the cloud platform.

[0039] S102. Obtain the second safety log data and the second audit log data collected by the roadside equipment.

[0040] In this step, roadside equipment is installed in the vehicle-to-everything (V2X) network. This equipment accurately acquires relevant vehicle data to generate second safety log data and second audit log data. Specifically, roadside equipment may include roadside sensing units, which can provide information such as pedestrians, traffic lights, road conditions, location, and time. Roadside equipment also includes roadside computing units, which can perform edge computing, identify driving risks, and provide local traffic warnings. These units can also report driving risk logs via roadside communication units. For example, roadside sensing units may include LiDAR, which acquires information such as vehicle position, speed, heading angle, pedestrians, and traffic lights. Based on this, the roadside computing unit performs local calculations on the data acquired by the LiDAR to determine the vehicle's driving risks and generate the second safety log data.

[0041] In addition, the roadside sensing unit will also record a large number of audit logs, referred to as the second audit log data mentioned above, including but not limited to vehicle position, speed, heading angle, surrounding pedestrians, and traffic light information.

[0042] Based on this, the roadside equipment can upload locally generated second security log data and second audit log data to the cloud platform through its internal roadside communication unit.

[0043] S103. The first security log data and the second security log data are extended to obtain the extended security log data of the target vehicle.

[0044] Specifically, security log data primarily describes a security alert, such as an attacker launching a denial-of-service attack on a vehicle. These logs represent preliminary security alerts, with the assessment already given. Without further analysis, they can be directly reported to the user as a security event. However, this could lead to alert fatigue, as many alert logs do not require user attention.

[0045] In addition, since the first and second safety log data reported by the on-board unit and the roadside equipment can actually identify whether the target vehicle has a safety risk, in order to more accurately identify safety risks and generate safety events, and to avoid user alarm fatigue caused by all unnecessary alarms generating safety events, the first and second safety log data will be extended to obtain extended safety log data.

[0046] Specifically, when performing extended processing, the cloud-based knowledge base can be used to extend the first security log data and the second security log data.

[0047] The aforementioned vehicle security knowledge base may include, but is not limited to, vehicle information and historical security data. Vehicle information may include, but is not limited to, vehicle attribute information and user information. User information can be the vehicle owner, and vehicle attribute information can include license plate number, vehicle age, body color, etc. The aforementioned historical security data may include, but is not limited to, data related to past security incidents involving the vehicle, such as: vehicle vulnerabilities, number of traffic violations, area names corresponding to latitude and longitude coordinates, geographical location, association between attackers and IP addresses, attacker methods, etc. This data can be used to expand and enrich the acquired security log data.

[0048] In addition, cloud platforms can also store attacker threat intelligence, such as IP addresses, domain names, and attack types commonly used by hacker groups.

[0049] S104. The first audit log data and the second audit log data are extended to obtain the extended audit log data of the target vehicle.

[0050] Specifically, audit logs are objectively recorded logs, free from subjective judgment. Regarding the enrichment of audit logs in the cloud, cloud platforms can refer to the methods used to extend security log data for further processing; these will not be detailed here.

[0051] S105. Utilize the detection rules for security events to detect and process the extended security log data and extended audit log data to determine whether the target vehicle poses a security risk.

[0052] Specifically, the cloud platform also stores a built-in risk identification model. The cloud platform uses the risk identification model to identify and process extended security log data and extended audit log data, thereby identifying whether the security log data reported by the on-board unit (OBU) and roadside equipment should generate risks, and then pushes it to the vehicle through the cloud platform's data collection and push platform.

[0053] It should be noted that the risk identification model described above is determined based on the detection rules for security events.

[0054] S106. When such a situation exists, a corresponding security event is generated based on the security risks present in the target vehicle.

[0055] In this step, when a security risk is identified in the target vehicle based on the extended security log data and extended audit log data, a corresponding security event can be generated using the extended security log data and extended audit log data based on the identified security risk.

[0056] By implementing the security event analysis method provided in this application, first security log data and first audit log data recorded by the on-board unit in the target vehicle are obtained; second security log data and second audit log data collected by roadside equipment are obtained; the first security log data and the second security log data are extended to obtain extended security log data of the target vehicle; the first audit log data and the second audit log data are extended to obtain extended audit log data of the target vehicle; the extended security log data and extended audit log data are detected using security event detection rules to determine whether the target vehicle has a security risk; if so, a corresponding security event is generated based on the security risk of the target vehicle. This application extends the security log data and audit log data reported by the on-board unit and roadside equipment respectively, and then identifies the extended security log data and extended audit log data to determine whether the target vehicle has a security risk. When a security risk is identified, a security event is generated. This not only improves the accuracy of security risk identification results but also avoids false alarms caused by directly treating security logs as security event alarms, and prevents users from experiencing alarm fatigue.

[0057] Based on the above embodiments, the first security log data reported by the vehicle unit in this embodiment may include, but is not limited to, at least one of the following parameters: vehicle identifier, security event identifier, device code, event type, etc. For details, please refer to Table 1. It should be noted that Table 1 is only an example and does not constitute a limitation on the above first security log data.

[0058] Table 1

[0059] Parameter name meaning Remark id Security event message identifier UUID value model_device_code Device Code Equipment code (across vehicle models) eventcategory_id Event type id code Event type code category_name Event type name grade Event Type Level vin Vehicle Identification VIN code vehicle_id Vehicle ID vehicle_device_id Vehicle Equipment ID eventtime Time of the incident milliseconds ip_src Attack IP port_src Attack Port ip_dst attacked IP port_dst attacked port content Attack event log content business_code Business code Default: network convergence Convergence Count The default value is 1. direction Data flow direction 0 indicates no direction, 1 indicates input, 2 indicates output, and the default value is 0.

[0060] Similarly, the first audit log data reported by the above-mentioned vehicle unit may include, but is not limited to, at least one of the following parameters: traffic data message identifier, vehicle identifier, cumulative inbound traffic value, cumulative outbound traffic value, etc. For details, please refer to Table 2. It should be noted that Table 2 is only an example and does not constitute a limitation on the above-mentioned first audit log data.

[0061] Table 2

[0062]

[0063]

[0064] Based on the above embodiments, the second safety log data reported by the roadside device in this embodiment may include, but is not limited to, at least one of the following parameters: safety event message identifier, license plate number, event type level, event log content, etc. For details, please refer to Table 3. It should be noted that Table 3 is only an example and does not constitute a limitation on the above-mentioned second safety log data.

[0065] Table 3

[0066] Parameter name meaning Remark id Security event message identifier UUID value eventcategory_id Event type id code Event type code category_name Event type name grade Event Type Level Vin_code license plate number Vin_color Body color eventtime Time of the incident milliseconds content Event log content business_code Business code Default: network

[0067] Similarly, the second audit log data uploaded by the aforementioned roadside equipment may include, but is not limited to, at least one of the following parameters: audit log message identifier, license plate number, vehicle body color, etc. For details, please refer to Table 4.

[0068] Table 4

[0069] Parameter name meaning Remark id Audit log message identifier UUID value Vin_code license plate number Vin_color Body color createtime Recording time milliseconds content Event log content business_code Business code Default: network

[0070] Optionally, based on any of the above embodiments, in this embodiment, the cloud platform can perform step S103 according to the following process: extract the target security log data corresponding to the vehicle identifier from the second security log data according to the vehicle identifier in the first security log data; use the vehicle identifier in the first security log data to match the vehicle security knowledge base to match the historical security log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; generate extended security log data according to the first security log data, the target security log data, the historical security log data and the vehicle attribute information.

[0071] Specifically, the second safety log data collected by roadside equipment is often the safety log data of all vehicles within the collection range of the roadside equipment. The first safety log data reported by the on-board unit in the target vehicle is often the safety log data of the target vehicle itself. This application aims to analyze whether the target vehicle poses a safety risk; therefore, it is necessary to screen out the target vehicle's safety log data from the second safety log data. In view of this, this embodiment proposes that a vehicle identifier representing the vehicle's identity can be extracted from the first safety log data, and then the target safety log data corresponding to that vehicle identifier can be extracted from the second safety log data. This extracted data is the safety log data of the target vehicle collected by the roadside equipment. Simultaneously, to enrich the target vehicle's safety log data, the vehicle safety knowledge base is matched based on the aforementioned vehicle identifier to extract the target vehicle's historical safety log data and vehicle attribute information. Then, based on the first safety log data, the target safety log data, the vehicle attribute information, and the historical safety log data, extended safety log data is generated, thereby achieving extended processing of the safety log data.

[0072] It is worth noting that when extracting historical safety log data from the vehicle safety knowledge base, safety log data that is close to the time when the current safety analysis of the target vehicle is performed can be extracted to ensure the accuracy of the safety risk identification results.

[0073] Optionally, based on any of the above embodiments, step S104 in this embodiment can be performed according to the following method: extracting the target audit log data corresponding to the vehicle identifier from the second audit log data according to the vehicle identifier in the first audit log data; matching the vehicle audit knowledge base with the vehicle identifier in the first audit log data to match the historical audit log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; generating extended audit log data according to the first audit log data, the target audit log data, the historical audit log data and the vehicle attribute information.

[0074] Specifically, the second audit log data collected by roadside equipment is often the audit log data of all vehicles within the collection range of the roadside equipment. The first audit log data reported by the on-board unit in the target vehicle is often the audit log data of the target vehicle itself. This application aims to analyze whether the target vehicle has audit risks; therefore, it is necessary to screen out the target vehicle's audit log data from the second audit log data. In view of this, this embodiment proposes that a vehicle identifier representing the vehicle's identity can be extracted from the first audit log data first, and then the target audit log data corresponding to that vehicle identifier can be extracted from the second audit log data. This extracted data is the audit log data of the target vehicle collected by the roadside equipment. Simultaneously, to enrich the target vehicle's audit log data, the vehicle audit knowledge base is matched based on the aforementioned vehicle identifier to extract the target vehicle's historical audit log data and vehicle attribute information. Then, based on the first audit log data, target audit log data, vehicle attribute information, and historical audit log data, extended audit log data is generated, thereby achieving extended processing of the audit log data.

[0075] It is worth noting that when extracting historical audit log data from the vehicle audit knowledge base, audit log data that is close to the time when the current audit analysis of the target vehicle is conducted can be extracted to ensure the accuracy of the audit risk identification results.

[0076] Based on any of the above embodiments, in one possible embodiment, step S105 can be performed according to the following method: if any security event is confirmed to exist in the extended security log data according to the security event detection rules, then determine whether the extended audit log data contains the security event; if the extended audit log data contains the security event, then confirm that the target vehicle has a security risk.

[0077] Specifically, the risk identification model described above can be constructed based on the rule model of security events. Then, the risk identification model is used to identify risks in extended security log data and extended audit log data. For example, if a security event A is detected in a target vehicle, theoretically, the OBU can detect security log A from the traffic packets of the vehicle's CAN bus. At the same time, audit log A, audit log B, etc., of the target vehicle will also appear simultaneously. Therefore, a risk identification model is constructed based on this detection rule. Based on this, when step S105 needs to be executed, the risk identification model can be invoked, and then used to identify the extended security log data and extended audit log data. If it is confirmed that security event A exists in the extended security log data, it can be further confirmed whether security event A exists in the extended audit log data. If security event A also exists in the extended audit log data, it can be confirmed that the target vehicle has a security risk. Therefore, based on the extended security log data and extended audit log data of the target vehicle, security event A is generated.

[0078] If security event A is not detected in the extended audit log data, it can be confirmed that the target vehicle does not pose a security risk.

[0079] In another possible embodiment, step S105 can also be performed as follows: if any security event is confirmed to exist in the audit extended log data according to the security event detection rules, then determine whether the extended security log data contains the security event; if the extended security log data contains the security event, then confirm that the target vehicle has a security risk.

[0080] It should be noted that the implementation of this step can refer to the description of the foregoing embodiments, and will not be described in detail here.

[0081] In another possible embodiment, step S105 can be performed as follows: using the learned normal behavior baseline, the extended audit log data is identified and processed to determine the degree of deviation of the extended audit log data from the normal behavior baseline, wherein the normal behavior baseline is learned and established from normal audit log data; if the degree of deviation exceeds a set range, the degree of matching between the extended security log data and the learned abnormal behavior baseline is determined, wherein the abnormal behavior baseline is learned and established based on abnormal security log data; if the degree of matching is within a set range, the target vehicle is determined to have a safety risk.

[0082] Based on this, the extended audit log data is processed using a normal behavioral baseline to determine the degree to which the audit log data deviates from the baseline, denoted as the deviation degree. Then, it is determined whether this deviation degree exceeds a set threshold. If it does, it indicates that the extended audit log data may pose a security risk. To further ensure the accuracy of the security risk identification results, this embodiment proposes further processing of the extended security log data, namely, determining the degree of matching between the extended security log data and the abnormal behavioral baseline. If the degree of matching is within a set range, it indicates that the extended security log data also poses a security risk, thus confirming that the target vehicle has a security risk, and thereby generating a security event.

[0083] Furthermore, the aforementioned normal behavior baseline is calculated using machine learning algorithms such as clustering or density calculation based on historical normal audit log data for all vehicles. For example, the audit log data used may include, but is not limited to, data from multiple dimensions such as traffic volume, number of abnormal packets, and access sources. Similarly, the aforementioned abnormal behavior baseline is calculated using machine learning algorithms such as clustering or density calculation based on historical abnormal security log data for all vehicles.

[0084] Furthermore, when a security event is confirmed to exist in the extended security log data based on security event detection rules, but not in the extended audit log data, this embodiment also provides the following solution: The extended audit log data is processed using a learned normal behavior baseline to determine the degree of deviation of the extended audit log data from the normal behavior baseline, which is obtained by learning from normal audit log data; if the deviation exceeds a set range, the degree of matching between the extended security log data and the learned abnormal behavior baseline is determined, which is obtained by learning from abnormal security log data; if the degree of matching is within a set range, the target vehicle is determined to have a security risk.

[0085] Based on any of the above embodiments, in this embodiment, the security data generated based on step S106 may include, but is not limited to, at least one of the following: the type of security event, the threat level of the security event, the credibility of the security event, the source of the security event, the affected device of the security event, the possible losses, etc. Furthermore, processing suggestions for the security event can also be provided to the user.

[0086] Thus, by adopting the security event analysis method provided in any of the above embodiments, not only is the accuracy of security event identification improved, but false alarms caused by analyzing only security log data are also avoided.

[0087] To better understand this embodiment, the following example illustrates the situation: Suppose a roadside device is infected with a worm virus. Since the worm virus automatically scans and discovers surrounding devices, it can spread rapidly, potentially attacking target vehicles. In this case, the roadside device will generate audit log data, as shown in Table 5. It should be noted that, for privacy protection purposes, the roadside device may only know the anonymized ID of the target vehicle and not the specific vehicle information.

[0088] Table 5

[0089]

[0090] Similarly, the safety log data collected by roadside equipment can be found in Table 6:

[0091] Table 6

[0092]

[0093] The audit log data obtained by the on-board unit in the target vehicle can be seen in Table 7. It should be noted that, due to privacy protection, the target vehicle may only know the anonymized number of the roadside equipment.

[0094] Table 7

[0095]

[0096]

[0097] Similarly, the safety log data recorded by the vehicle-mounted unit can be found in Table 8.

[0098] Table 8

[0099]

[0100] Building upon this foundation, the cloud platform can perform extended processing on the safety log data and audit log data reported by roadside equipment and vehicle-mounted units, respectively. Then, based on the obtained extended safety log data and extended audit log data, it can use any of the aforementioned methods for risk identification. When a safety risk is identified in a target vehicle, a corresponding safety event is generated. This not only improves the accuracy of safety event identification results but also avoids false alarms caused by simply analyzing safety log data.

[0101] Based on the same inventive concept, this application also provides a security incident analysis device corresponding to the above-described security incident analysis method. Specific implementation details of this security incident analysis device can be found in the above description of the security incident analysis method, and will not be elaborated upon here.

[0102] See Figure 2 , Figure 2 This application provides an exemplary embodiment of a security event analysis apparatus, comprising:

[0103] The first acquisition module 201 is used to acquire the first security log data and the first audit log data recorded by the on-board unit in the target vehicle.

[0104] The second acquisition module 202 is used to acquire the second safety log data and the second audit log data collected by the roadside equipment;

[0105] The first extension module 203 is used to extend the first security log data and the second security log data to obtain extended security log data of the target vehicle.

[0106] The second extension module 204 is used to extend the first audit log data and the second audit log data to obtain extended audit log data of the target vehicle.

[0107] The detection module 205 is used to perform detection processing on the extended security log data and extended audit log data using the detection rules of security events to determine whether the target vehicle has a security risk.

[0108] The generation module 206 is used to generate a corresponding security event based on the security risks existing in the target vehicle when they exist.

[0109] Optionally, based on the above embodiments, in this embodiment, the first extension module 203 is specifically used to extract the target security log data corresponding to the vehicle identifier from the second security log data according to the vehicle identifier in the first security log data; use the vehicle identifier in the first security log data to match the vehicle security knowledge base to match the historical security log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; and generate extended security log data according to the first security log data, the target security log data, the historical security log data, and the vehicle attribute information.

[0110] Optionally, based on any of the above embodiments, in this embodiment, the second extension module 204 is specifically used to extract the target audit log data corresponding to the vehicle identifier from the second audit log data according to the vehicle identifier in the first audit log data; use the vehicle identifier in the first audit log data to match the vehicle audit knowledge base to match the historical audit log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; and generate extended audit log data according to the first audit log data, the target audit log data, the historical audit log data and the vehicle attribute information.

[0111] Optionally, based on any of the above embodiments, in this embodiment, the detection module 205 is specifically used for:

[0112] If any security event is confirmed to exist in the extended security log data according to the security event detection rules, then it is determined whether the extended audit log data contains the security event.

[0113] If the extended audit log data contains this security event, then the target vehicle is confirmed to have a security risk.

[0114] or,

[0115] If any security event is confirmed to exist in the audit extended log data according to the security event detection rules, then it is determined whether the extended security log data contains the security event.

[0116] If the security event is present in the extended security log data, then the target vehicle is confirmed to pose a security risk.

[0117] Furthermore, the aforementioned detection module 205 is also used to, if the extended audit log data does not contain the security event, use the learned normal behavior baseline to identify and process the extended audit log data, and determine the degree of deviation of the extended audit log from the normal behavior baseline, wherein the normal behavior baseline is learned and established from normal audit log data; if the degree of deviation exceeds a set range, determine the degree of matching between the extended security log data and the learned abnormal behavior baseline, wherein the abnormal behavior baseline is learned and established based on abnormal security log data; if the degree of matching is within a set range, determine that the target vehicle has a security risk.

[0118] Optionally, based on any of the above embodiments, in this embodiment, the detection module 205 is specifically used to identify and process the extended audit log data using the learned normal behavior baseline, determine the degree of deviation of the extended audit log from the normal behavior baseline, wherein the normal behavior baseline is learned and established from normal extended audit log data; if the degree of deviation exceeds a set range, then determine the degree of matching between the extended security log data and the learned abnormal behavior baseline; if the degree of matching is within the set range, then determine that the target vehicle has a safety risk.

[0119] The safety event analysis device provided in this application expands the safety log data and audit log data reported by the vehicle-mounted unit and roadside equipment, respectively, and then identifies the expanded safety log data and expanded audit log data to determine whether the target vehicle has a safety risk. When a safety risk is identified, a safety event is generated. This not only improves the accuracy of the safety risk identification results, but also avoids false alarms caused by directly treating safety logs as safety event alarms, and also avoids users from becoming fatigued by alarms.

[0120] Based on the same inventive concept, embodiments of this application provide an electronic device, which may be, but is not limited to, the aforementioned cloud platform. For example... Figure 3 As shown, the electronic device includes a processor 301 and a machine-readable storage medium 302. The machine-readable storage medium 302 stores a computer program executable by the processor 301. The processor 301 is prompted by the computer program to execute the security event analysis method provided in any embodiment of this application. Furthermore, the electronic device also includes a communication interface 303 and a communication bus 304, wherein the processor 301, the communication interface 303, and the machine-readable storage medium 302 communicate with each other via the communication bus 304.

[0121] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0122] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0123] The machine-readable storage medium 302 described above can be a memory, which may include random access memory (RAM), DDR SRAM (Double Data Rate Synchronous Dynamic Random Access Memory), or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0124] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0125] For embodiments of electronic devices and machine-readable storage media, since the methods involved are basically similar to those described in the foregoing method embodiments, the description is relatively simple, and relevant details can be found in the descriptions of the method embodiments.

[0126] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0127] The specific implementation process of the functions and roles of each unit / module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0128] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units / modules described as separate components may or may not be physically separate. The components shown as units / modules may or may not be physical units / modules, that is, they may be located in one place or distributed across multiple network units / modules. Some or all of the units / modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0129] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A security event analysis method characterized by, The method comprises: obtaining first safety log data and first audit log data recorded by a vehicle-mounted unit in a target vehicle; obtaining second safety log data and second audit log data collected by a roadside device; performing extension processing on the first safety log data and the second safety log data to obtain extended safety log data of the target vehicle; performing extension processing on the first audit log data and the second audit log data to obtain extended audit log data of the target vehicle; performing detection processing on the extended safety log data and the extended audit log data by using a detection rule of a safety event to determine whether the target vehicle has a safety risk; when the target vehicle has a safety risk, generating a corresponding safety event according to the safety risk of the target vehicle; the extension processing on the first safety log data and the second safety log data to obtain the extended safety log data of the target vehicle comprises: extracting target safety log data corresponding to a vehicle identifier from the second safety log data according to the vehicle identifier in the first safety log data; matching vehicle safety knowledge base by using the vehicle identifier in the first safety log data to match historical safety log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; generating extended safety log data according to the first safety log data, the target safety log data, the historical safety log data, and the vehicle attribute information.

2. The method of claim 1, wherein, the extension processing on the first audit log data and the second audit log data to obtain the extended audit log data of the target vehicle comprises: extracting target audit log data corresponding to a vehicle identifier from the second audit log data according to the vehicle identifier in the first audit log data; matching vehicle audit knowledge base by using the vehicle identifier in the first audit log data to match historical audit log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; generating extended audit log data according to the first audit log data, the target audit log data, the historical audit log data, and the vehicle attribute information.

3. The method of claim 1, wherein, the detection processing on the extended safety log data and the extended audit log data by using the detection rule of the safety event to determine whether the target vehicle has a safety risk comprises: if it is confirmed according to the detection rule of the safety event that there is any safety event in the extended safety log data, determining whether the extended audit log data has the safety event; if the extended audit log data has the safety event, confirming that the target vehicle has a safety risk; or, if it is confirmed according to the detection rule of the safety event that there is any safety event in the extended audit log data, determining whether the extended safety log data has the safety event; if the extended safety log data has the safety event, confirming that the target vehicle has a safety risk.

4. The method of claim 3, wherein If the security event does not exist in the extended audit log data, the normal behavior baseline learned is used to identify the extended audit log data, and the deviation degree of the extended audit log data from the normal behavior baseline is determined, the normal behavior baseline being established by learning normal audit log data; If the deviation degree exceeds the set degree range, the matching degree between the extended security log data and the learned abnormal behavior baseline is determined, the abnormal behavior baseline being established by learning abnormal security log data; If the matching degree is within the set degree range, it is determined that the target vehicle has a security risk.

5. The method of claim 1, wherein, The extended security log data and the extended audit log data are detected by using the detection rule of the security event, and it is determined whether the target vehicle has a security risk, including: The normal behavior baseline learned is used to identify the extended audit log data, and the deviation degree of the extended audit log data from the normal behavior baseline is determined, the normal behavior baseline being established by learning normal extended audit log data; If the deviation degree exceeds the set degree range, the matching degree between the extended security log data and the learned abnormal behavior baseline is determined; If the matching degree is within the set degree range, it is determined that the target vehicle has a security risk.

6. A security event analysis apparatus characterized by comprising: Including: The first acquisition module is configured to acquire first security log data and first audit log data recorded by a vehicle-mounted unit in a target vehicle; The second acquisition module is configured to acquire second security log data and second audit log data collected by a roadside device; The first extension module is configured to perform extension processing on the first security log data and the second security log data to obtain extended security log data of the target vehicle; The second extension module is configured to perform extension processing on the first audit log data and the second audit log data to obtain extended audit log data of the target vehicle; The detection module is configured to perform detection processing on the extended security log data and the extended audit log data by using a detection rule of a security event, and determine whether the target vehicle has a security risk; The generation module is configured to generate a corresponding security event according to the security risk of the target vehicle when the security risk exists. The first extension module is specifically configured to extract target security log data corresponding to a vehicle identifier from the second security log data according to the vehicle identifier in the first security log data; The vehicle identifier in the first security log data is matched with a vehicle security knowledge base to match the historical security log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; and the extended security log data is generated according to the first security log data, the target security log data, the historical security log data, and the vehicle attribute information.

7. The apparatus of claim 6, wherein The second expansion module is specifically configured to extract target audit log data corresponding to the vehicle identifier from the second audit log data according to the vehicle identifier in the first audit log data; match the vehicle identifier in the first audit log data with a vehicle audit knowledge base to match historical audit log data and vehicle attribute information of the target vehicle corresponding to the vehicle identifier; and generate expanded audit log data according to the first audit log data, the target audit log data, the historical audit log data and the vehicle attribute information.

8. The apparatus of claim 6, wherein, The detection module is specifically configured to: if it is confirmed according to the detection rule of the security event that any security event exists in the expanded security log data, determine whether the expanded audit log data has the security event; if the expanded audit log data has the security event, confirm that the target vehicle has a security risk; or, if it is confirmed according to the detection rule of the security event that any security event exists in the expanded audit log data, determine whether the expanded security log data has the security event; if the expanded security log data has the security event, confirm that the target vehicle has a security risk.

9. The apparatus of claim 8, wherein: the detection module is further configured to, if the expanded audit log data does not have the security event, perform identification processing on the expanded audit log data by using a learned normal behavior baseline, determine a deviation degree of the expanded audit log data from the normal behavior baseline, the normal behavior baseline being established by learning normal audit log data; and if the deviation degree exceeds a set degree range, determine a matching degree between the expanded security log data and a learned abnormal behavior baseline, the abnormal behavior baseline being established by learning abnormal security log data; and if the matching degree is within the set degree range, determine that the target vehicle has a security risk.

10. The apparatus of claim 6, wherein: the detection module is specifically configured to perform identification processing on the expanded audit log data by using a learned normal behavior baseline, determine a deviation degree of the expanded audit log data from the normal behavior baseline, the normal behavior baseline being established by learning normal expanded audit log data; if the deviation degree exceeds a set degree range, determine a matching degree between the expanded security log data and a learned abnormal behavior baseline; if the matching degree is within the set degree range, determine that the target vehicle has a security risk. ​

Images