Integrated device failure and network attack detection system

Abstract

An integrated device failure and network attack detection deployment. An integrated Vehicle Health Management (IVHM) system is used to address anomalies related to device failures detected by a Network Intrusion Detection System (IDS). The advantage of this system is that it generates fewer alerts requiring manual analysis. The combination of network monitoring with integrated Vehicle Health Management (IVHM) can be a high-value differentiator. As the solution matures through a learning loop, it can be customized cost-effectively for different customers, whereas developing such solutions in-house can be expensive for most original equipment manufacturers (OEMs). The IVHM symptom pattern recognition matrix links patterns of reported symptoms to known device failures. This matrix can be initialized from vehicle design data, but its entries can be updated through a learning loop that improves relevance by incorporating survey results.

Description

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 784,374, filed December 21, 2018, which is incorporated herein by reference.

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 904,368, filed September 23, 2019, which is incorporated herein by reference. Background Technology

[0003] This disclosure may relate to attacks on vehicle electronics and vehicle equipment malfunctions. Summary of the Invention

[0004] This disclosure discloses the use of an integrated vehicle health management (IVHM) system to address anomalies related to equipment failures detected by network intrusion detection systems (IDS). The combination of network monitoring with integrated vehicle health management (IVHM) can be a high-value differentiator. As the solution matures through a learning loop, it can be customized cost-effectively for different customers, whereas developing such solutions in-house can be expensive for most original equipment manufacturers (OEMs). The IVHM symptom pattern recognition matrix links patterns of reported symptoms (e.g., anomalies) to known equipment failures (electrical connections, sensors, controllers, known network attacks, etc.). This matrix can be initialized from vehicle design data, but its entries can be updated through a learning loop that improves relevance by incorporating findings from investigations. Attached Figure Description

[0005] Figure 1 The image shows a vehicle whose electronic components have been affected by a cyberattack, and the vehicle may also have equipment malfunctions.

[0006] Figure 2 This could be an illustration of an in-vehicle network intrusion detection system (IDS), which can detect almost any anomaly and transmit them to a Security Operations Center (SOC) hosted on the company's cloud.

[0007] Figure 3 It is a diagram of a matrix containing known anomaly patterns of Integrated Vehicle Health Maintenance (IHVM);

[0008] Figure 4 This is a diagram of the IVHM matrix, which is deployed in a vehicle-mounted manner and receives reported anomalies directly from the IDS;

[0009] Figure 5 This is a diagram of the IVHM matrix, which can be hosted using the same SOC in the cloud;

[0010] Figure 6 This is a diagram of a neural network, which can be an alternative method for initializing fault models or implementing fault isolation processes; and

[0011] Figure 7 It is a diagram of a fault model that can be initialized for combined networks and IVHM systems. Detailed Implementation

[0012] In the implementations described and / or illustrated herein, the system and method may include one or more processors, computers, controllers, user interfaces, wireless and / or wired connections and / or the like.

[0013] This description may provide one or more illustrative and specific examples or ways of implementing this system and method. Numerous other examples or ways of implementing this system and method may exist.

[0014] Aspects of the system or method can be described in the accompanying drawings using symbols. Symbols can have virtually any shape (e.g., a block) and can designate hardware, objects, components, activities, states, steps, processes, and other items.

[0015] Intrusion detection systems (IDS) or intrusion detection and prevention systems (IDPS) of related technologies may suffer from high false positive rates caused by monitoring vehicle networks for malicious activity. Utilizing anomaly-based detection methods as a primary strategy against cyberattacks, machine learning can be used to model trusted or legitimate activity across the network, and any deviation from this modeled behavior may be flagged as suspicious. This could mean that previously unknown or unmodeled legitimate business may be incorrectly flagged as malicious. Currently, the vast majority of activity in vehicles that IDS / IDPS consider anomalies is caused by device malfunctions (e.g., electrical connections, sensors, controllers, etc.) and is not inherently network-related. This can lead to IDS / IDPS reporting a large number of anomalies to the Security Operations Center (SOC), which analysts will need to carefully examine before identifying and addressing a small number of genuine cyber threats. As expected, this exercise can be labor-intensive and time-consuming, and is not ideal for cyberattack monitoring, especially for large numbers of vehicles. Figure 1 This is a diagram illustrating a network failure alert problem statement. A network attack can be considered an attempt to damage or destroy computers, computer systems, or electronic communication networks, or to gain unauthorized access to them.

[0016] The combination of networking and monitoring using integrated vehicle health management (IVHM) can be a high-value differentiator. By combining networking and IVHM offerings on the same vehicle data, companies can create differentiated technologies that do not yet exist. As solutions mature through a learning loop, they can be tailored cost-effectively for different customers, whereas developing these solutions in-house can be expensive for most original equipment manufacturers (OEMs). The best IDS solutions on the market appear to achieve false positive rates of at least 10%, while OEMs can set the bar for validating IDS maturity at 1% or lower. By leveraging their expertise in IVHM to fine-tune their IDS technology, companies may have the opportunity to meet this threshold faster than their competitors in cybersecurity matters. This disclosure has been developed to overcome the problems associated with standalone IDS and SOC solutions, which may fall into the status quo of existing technologies.

[0017] This disclosure can indicate various methods for creating IVHM components of a model from design data and for integration with patterns of cyberattacks.

[0018] Figure 2-5 This can be a diagram of the solution and / or system. The IVHM symptom pattern recognition matrix links patterns of reported symptoms (e.g., anomalies) to known equipment failures (electrical connections, sensors, controllers, known cyberattacks, etc.). This matrix can be initialized from vehicle design data, but its entries can be updated through a learning loop that improves the relevance by incorporating findings from surveys. The model can be created from simulations and by collecting data during system and vehicle development testing. Alternatively, neural networks or other machine learning-based methods can also be used to detect equipment failures from observed anomalous patterns. Figure 6Neural networks can be used as an alternative mechanism to baseline inferencers and matrices. If so, the neural network does not necessarily perform detection; it performs classification / isolation. A predetermined set of features is extracted from anomalies and fed into the input layer of a trained neural network. In the simplest case, these features might indicate the state of their individual anomalies (0: not present, 1: present), or they might be more complex functions of the anomalies. The output layer of the neural network can provide the probability associated with each known failure condition or equipment failure mode. If the highest probability at the output layer also happens to be above a certain threshold, the associated failure condition can generally be attributed to that set of observed anomalies. This machine learning-based model can be particularly useful when there is not enough or reliable design data available to initialize the IVHM matrix. Training data for neural networks or any other model can be collected by injecting known failure modes and gathering all anomalies from the IDS logs. In the description below, the IVHM matrix can be understood as representing a machine learning-based model (e.g., a neural network) and also used to associate patterns of anomalies with known equipment failures.

[0019] Figure 1 This is an illustration of vehicle 11, some of which has been affected by a cyberattack 12. Furthermore, there may be equipment failure 13 within vehicle 11. A network IDS 14 can be associated with vehicle 11. It should be noted that equipment failures can be thousands of times more frequent than cyberattacks; however, both can cause IDS anomalies. Signals from network IDS 14 may travel to the company's SOC (Security Operations Center) 15, where numerous SOC analysts spend considerable time filtering equipment failure reports to identify genuine network incidents. The output from SOC 15 can be the identification of real issues 16 for the investigation.

[0020] There are many ways to implement this disclosure. Figure 2 This could be a diagram of an in-vehicle network IDS 14, which can detect almost all anomalies and transmit them to a SOC 15 hosted on the corporate cloud. The anomaly can be rerouted to another corporate cloud with IVHM 21, where it is fed into a pattern matrix 22 known to the IVHM. Figure 3 Matrix 22 is shown in the diagram. If a link is found between an anomaly pattern and a known fault, it can be forwarded to the service department as a recommended maintenance plan 23. Remaining or unidentified anomalies 24 can be sent back to the SOC 15, where human analysts carefully examine them to identify any real cyberattack issues 17 or previously unknown design flaws.

[0021] The findings of human survey 18 can be distributed to stakeholders and form a learning loop 25 to improve the performance of IVHM 21 in the future.

[0022] Humans are only involved in the analysis of new, unidentified events 24. Compared to network solutions that do not automatically handle events related to IVHM 21, the number of events requiring human analysts can be significantly reduced. This approach does not necessarily attempt to automate the analysis of unidentified events.

[0023] Furthermore, it can be said that, Figure 2 A diagram illustrating the collaborative IVHM 21 (Integrated Vehicle Health Management) solution is shown. Vehicle 11 may be affected by equipment failure 13 and cyberattacks 12. The network IDS 14 associated with vehicle 11 can provide a signal 19 to SOC 15, which is forwarded to IVHM 21 in the company cloud or elsewhere, where anomalies 19 are analyzed and IVHM symptom pattern identification occurs. IVHM 21 can be considered an inference engine. [The remaining text appears to be incomplete and requires further context.] Figure 3 The known patterns of IVHM 21 are identified in diagram 22 of the illustration. These patterns can be initialized from design data. The results from IVHM 21 can be a recommended maintenance plan 23 for service. Furthermore, IVHM 21 may send unidentified patterns 24 to the SOC 15, where analysts analyze equipment failure reports to find the real problems 17 that led to their investigation 18. Information from the investigation 18 can undergo a learning loop 25 for system improvements to IVHM 21.

[0024] Figure 4 This is a diagram illustrating the implementation of IVHM matrix 22, which can be deployed vehicle-mounted and receive reported anomalies 19 from IDS 14. Once unidentified symptoms are categorized, they can be transferred to SOC 15, which is hosted on the company cloud and monitored by human analysts. IVHM discovery of learning loops 25 and unidentified patterns 24 can be performed using methods similar to earlier versions (…). Figure 2 It is handled in a similar way. Compared to Figure 3 The implementation of this solution in the context of [the previous sentence] offers the advantage of reducing the amount of data transfer and processing across different servers, thus providing cost and security advantages. However, incorporating the IVHM 21 on-board (i.e., on the edge or ECU) is an alternative configuration.

[0025] With the described configuration Figure 4The diagram may belong to a network IVHM collaborative solution. Vehicle 11 may have network attacks 12 and equipment failures 13. Network IDS 14 can detect equipment failures 13 and network attacks 12. Based on the known pattern diagram 22, network IDS 14 may include IVHM 21 symptom pattern recognition of signals or information detected by network IDS 14. An output from network IDS 14 (as accompanied by IVHM 21) may be a recommended maintenance plan 23 for service. Also from network IDS 14 may be anomalies 19 detected by IDS filtered by IVHM 21 on edge 26. Unidentified anomalies 24 may go to SOC 15, which extracts the real problem 17 that may lead to investigation 18. Learning loop 25 can carry the information found from investigation 18 to IVHM 21 for system improvement.

[0026] Figure 5 It can be with Figure 2 The solution presented here is similar to the diagram of the previous solution, but IVHM 21 matrix 22 can be hosted by SOC 15 in the same company cloud. It may receive all reported anomalies from SOC 15 and classify them into two bins as described above, which are associated with known faults or patterns and unidentified faults or patterns 24. The remaining data processing can be the same as the previous implementation.

[0027] Figure 5 The diagram illustrates another configuration of the Network IDS 14 IVHM 21 collaborative solution. As noted above, vehicle 11 may be affected by network attacks 12 and equipment failures 13. Network IDS 14 can send anomalies detected by the IDS to SOC 15, which in turn forwards the anomalies to IVHM 21 for symptom pattern identification according to diagram 22. One outcome may be a recommended maintenance plan 23 for service provision. Another outcome may be the actual problem 17 leading to investigation 18. Information from the investigation can be followed in a learning loop between SOC 15 and IVHM 21 for system improvement.

[0028] This system may have one or more software components. The stack level can be a cloud used to provide secure, scalable infrastructure for collecting, aggregating, and storing data, thereby allowing connected “things” to communicate, enabling available providers / SaaS solutions, IaaS / PaaS, and data lakes. As a provider available via the cloud or direct remote connectivity (SaaS), the software type can be connected / connected, or it can overlay the infrastructure enabling connected services (sensing). It can have IoT (Internet of Things). There may be IoT with stack levels such as the edge, i.e., hardware devices with embedded software that can be securely connected to the cloud via wired or wireless connections. It can generate or capture data. The type of data might be anomalies in vehicle networks and can reside on the edge (vehicle-based) or in the cloud.

[0029] Figure 6 This is a diagram illustrating a neural network-based method for equipment fault detection. The left side shows features extracted from anomalies observed by the network. The right side shows the fault conditions indicated by the network.

[0030] Although neural networks can be incorporated as an alternative implementation, they are not necessarily used to initialize fault models or implement fault isolation processes.

[0031] Figure 6 and 7 It may have or show particular suitability for Figure 2-5 The elements of the diagram. For example, the content of a combined fault model is as follows: Figure 3 As shown in the diagram. It can also be called... Figure 2 A table of known patterns in IVHM. Then, it can be... Figure 4 and Figure 5 The IVHM symptom pattern recognition function includes a combined fault model.

[0032] Figure 6 This is a diagram of a neural network 31 used for equipment fault detection. Features can be extracted from observed or detected anomalies 31, such as the detected anomaly 27 in the previous figure. The network 31 can be used to process features 32 (1-n) to derive fault conditions 33 (1-m (p1-p...). m )).

[0033] A key aspect of this system is the mechanism for deriving the fault matrix from design data. A crucial element is combining a physics-based model (which encodes the failure modes of individual components) and a model of system dynamics with design data specific to the vehicle. Integration of results from simulation and design testing may be necessary.

[0034] Figure 7The diagram illustrates a fault model initialized for a combined network and IVHM system. It guides model creation and updates. The network model can include representations of each attack type and expected symptom patterns for each attack type. This model can be calibrated during development testing. The IVHM model uses design data to generate expected symptom patterns for each type of device failure. As real-world events occur and are corrected, the model can be improved through learning loops. The IVHM model can have approximately 100 times the content of the network model. Initializing the fault model from design data and a physics-based model significantly reduces the amount of training data required, provides a faster path to system maturity, and significantly reduces overall system cost.

[0035] Figure 7 This is a diagram of an initializeable fault model. Layout 41 for network modeling can be illustrated. Layout 42 for IVHM modeling can be illustrated. Layout 41 may have a network attack modeling component 43, in which more than 100 patterns are generated. Layout 42 may have a design data analysis component 44, in which more than 10,000 patterns are generated. Input 45 to the design data analysis component 44 may include physics-based models (from libraries and analysis tools, including system dynamics models and component fault models). Another input 46 to the design data analysis component 44 may include vehicle design data (from message routing tables, bus topology, schematics, and Diagnostic Trouble Code (DTC) definitions). Integration of results from simulation and design testing may be possible. The output of more than 10,000 patterns from the network attack modeling component 43 and the design data analysis component 44 can lead to a combined fault model 47. Figure 7 The output can be a combined fault model 47.

[0036] The event pattern plus the root cause input 51 can go to the initial calibration component 53. The event pattern plus the corrective action input 52 can go to the learning loop+ component 54. The output of more than 100 patterns from the initial calibration component 53 can go to the combined fault model 47. Another output of more than 1000 patterns from the learning loop+ component 54 can go to the combined fault model 47. Therefore, component 47 can process a combined fault model with four inputs of patterns.

[0037] Figure 7 The diagram illustrates the functionality of two blocks that leverage machine learning. The initial calibration function uses machine learning to initialize the IDPS anomaly detection function and records patterns in the expected alarms for each type of cyberattack. The learning loop function uses machine learning to update patterns in the combined failure model to more accurately reflect patterns in alarms for all events observed during testing and by the production team.

[0038] Using health indicators generated by a cybersecurity operations center (SOC) can improve diagnostic accuracy. Integrated Vehicle Health Management (IVHM) can be used to complement the functionality of cybersecurity systems by identifying symptom indicators similar to those generated by known equipment failures, thereby reducing the number of false alarms. This addresses the cost of servicing a large number of cyber alarms caused by equipment failures. However, this solution may introduce new problems because events actually caused by cyberattacks can be forwarded to one or more dealers for maintenance without any visibility through the SOC.

[0039] This approach can be supplemented with an additional layer of logic featuring some form of team analytics run by the SOC, independent of IVHM classification, to detect frequency spikes in events that are more indicative of a cyberattack than normal equipment failures. When this logic detects a spike, the SOC can send one or more health indicators to the IVHM to notify the affected teams and affected electronic control units (ECUs). This logic can also be used to generate alerts within the SOC indicating that a potential attack has been detected. The IVHM will use this information in its ranking algorithm if it has the effect of prioritizing cyberattacks as the most likely cause of any Diagnostic Trouble Codes (DTCs) or customer complaints related to identified ECU malfunctions.

[0040] This method may include: a mechanism for detecting spikes in the frequency of indicators; upon detection of such a spike, combining it with a notification to the SOC and sending it to the IVHM of a single team and ECU; and a method for modifying the ranking generated by the IVHM. This ranking is for fault conditions associated with indicators having abnormally high frequencies. The ranking algorithm can provide specific behavior by including health indicators generated by the SOC in the combined IVHM+ network fault model.

[0041] The elements of this method may include: (1) a mechanism for suppressing harmful messages to network analysts based on similarity to known device failure indicators; (2) a mechanism for detecting potential vehicle attacks using team-level statistics based on the frequency and location of events; and (3) a mechanism for integrating the results of items 1 and 2 to more accurately determine the likelihood that the event is a device failure or a network attack.

[0042] This approach may further include the development of common fault models and inferencers, which include flags for device failures and network attacks; and the inferencer that can use the model and the status of the reported indicators to diagnose the cause of an event.

[0043] In summary, an integrated device failure and network attack detection system can include: an Intrusion Detection System (IDS) for sensing network attacks and device failures on the vehicle; a Security Operations Center (SOC) connected to the IDS for receiving network attacks and device failures; and an Integrated Vehicle Health Management (IVHM) module connected to the SOC for handling network attacks and device failures. Network attacks and device failures can be considered anomalies. Detected anomalies with patterns from the IDS can be passed by the SOC to the IVHM module for pattern recognition. Patterns not recognized by the IVHM module can be sent to the SOC for analysis. Unrecognized patterns can be investigated, and the results are then passed from the investigation to the IVHM module via a learning loop. Patterns recognized by the IVHM module can lead to recommended maintenance plans.

[0044] Detected anomalies can include the frequency of events reported by the SOC to the IVHM module.

[0045] The IHVM module can be updated or improved by learning loops and utilizing the results.

[0046] The IVHM module can output recommended maintenance plans to service damage or prevent damage caused by network attacks or equipment failures.

[0047] This survey can be conducted by humans.

[0048] The IVHM module can compare the patterns of detected anomalies passed from the SOC with known patterns in the IVHM module's storage device to identify problems.

[0049] The pattern storage device of the IVHM module can be updated via a learning loop, utilizing new or unrecognized patterns.

[0050] Machine learning can be used to update the schema storage device of the IVHM module.

[0051] Methods for intrusion detection may include: detecting network attacks and device malfunctions on a vehicle; reviewing anomalies with patterns from one or more detected network attacks or device malfunctions, which are identified at an integrated vehicle health maintenance (IVHM) module using a symptom pattern recognition device; detecting problems by reviewing anomalies with unrecognized patterns; and investigating problems with unrecognized patterns and sending information to the IVHM module for improvement or updating of the system pattern recognition device.

[0052] Unrecognized patterns can be reviewed at the Security Operations Center (SOC).

[0053] In response to the review of the identified patterns, the IVHM module can recommend maintenance plans for servicing vehicles that may be damaged by one or more network attacks or equipment failures, based on the identified patterns.

[0054] Unidentified patterns may have issues that have been analyzed or investigated by humans.

[0055] One or more results from analyses or investigations categorized as system improvements can be sent back to the learning loop as information for improving the system's pattern recognition device.

[0056] The learning loop can use machine learning to update the patterns used by the system pattern recognition device.

[0057] The system pattern recognition device can contain a table of known patterns.

[0058] A neural network can be implemented instead of a table of known patterns. A predetermined set of features can be extracted from anomalies and fed into the input layer of the neural network.

[0059] The mechanism for developing fault models may include a network modeling module and an integrated vehicle health management (IVHM) modeling module. The network modeling module and the IVHM modeling module can be combined to output a combined fault model.

[0060] The network modeling module can include a representation of each attack type and the expected symptoms for each attack type. The IVHM modeling module can use design data to generate expected symptom patterns for each type of device failure.

[0061] The combined failure model may include: inputs for network attack modeling; inputs for initial calibration of the network modeling module; inputs from the design data analysis module; and inputs from the learning loop.

[0062] The design data analysis module may include: physics-based models, including system dynamic models and component failure models; vehicle design data, including message routing tables, bus topology, schematics, and diagnostic fault code (DTC) definitions; and simulation or test results.

[0063] Initial calibration can have event patterns and root cause inputs. The learning loop can have event patterns and corrective actions inputs.

[0064] Any published or patent document mentioned herein is incorporated herein by reference to the same extent that each published or patent document is specifically and individually indicated as incorporated by reference.

[0065] Although stated in another manner or tense in this specification, some things may have a hypothetical or predictive nature.

[0066] Although the system and / or method have been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the specification. Therefore, it is intended that the appended claims be interpreted as broadly as possible, in light of the relevant art, to include all such variations and modifications.

Claims

1. An integrated equipment failure and cyber attack detection system comprising a vehicle and a secure operations center (SOC) remote from the vehicle, wherein the vehicle comprises: an intrusion detection system (IDS) for detecting anomalies on the vehicle comprising one or more cyber attacks and equipment failures, wherein the IDS is connected to the SOC; and an integrated vehicle health management (IVHM) module on board the vehicle, the IVHM module being connected to the SOC; wherein the IVHM module is configured to: identify anomalies having a pattern matching a symptom pattern stored in an IVHM symptom pattern recognition matrix as a corresponding equipment failure; and pass anomalies having an unidentified pattern to the SOC; and wherein the SOC is configured to use a learning loop to send information to the IVHM module based on an investigation of the unidentified pattern, wherein the IVHM module is configured to update or refine the IVHM symptom pattern recognition matrix with new or unidentifiable patterns; and wherein the IVHM module is configured to output a recommended maintenance plan to repair damage or prevent damage from cyber attacks or equipment failures, and further comprising an additional logic layer having some team analysis run by the SOC independent of the IVHM classification to detect event frequency spikes more indicative of cyber attacks than normal equipment failure occurrences, the SOC can send one or more health indicators to the IVHM module to inform the IVHM module of the affected team and affected electronic control units (ECUs) when the logic layer detects a spike, the logic layer is further for generating an alert in the SOC that a possible attack has been detected.

2. The system of claim 1, wherein the detected anomalies comprise abnormal frequencies of events reported by the SOC to the IVHM module.

3. The system of claim 1, wherein the investigation is carried out by a human.

4. A method for intrusion detection comprising: detecting anomalies on a vehicle comprising one or more cyber attacks and equipment failures using an on-board intrusion detection system (IDS); identifying, at an integrated vehicle health management (IVHM) module on board the vehicle, anomalies having a pattern matching a symptom pattern stored in an IVHM symptom pattern recognition matrix as a corresponding equipment failure; passing anomalies having an unidentified pattern to a secure operations center (SOC) remote from the vehicle; and investigating, at the SOC, the issue of the unidentified pattern and sending information to the IVHM module to refine or update the IVHM symptom pattern recognition matrix with new or unidentifiable patterns, wherein the IVHM module outputs a recommended maintenance plan to repair damage or prevent damage from cyber attacks or equipment failures in response to the identification of the matching pattern, ​ ​ Also included is an additional logic layer with some team analysis run by the SOC that is independent of the IVHM classification to detect event frequency spikes that are more indicative of a cyber attack than normal equipment failure occurrences, when the logic layer detects a spike, the SOC can send one or more health indicators to the IVHM module to inform the IVHM module of the affected team and affected electronic control unit, ECU, the logic layer is also used to generate an alert in the SOC that a possible attack has been detected.

5. The method of claim 4, wherein: the unidentified pattern has questions for human analysis or investigation; and one or more results of the analysis or investigation that are classified as system improvements are sent back onto the learning loop to improve or update the IVHM symptom pattern recognition matrix as improvement information for the system pattern recognition device; and the learning loop uses machine learning to update the patterns used by the system pattern recognition device.

Images