System for detecting intrusions into in-vehicle networks and method of implementing same - Patents.com

Abstract

An intrusion detection system and method for detecting intrusions in an in-vehicle network are provided. The present invention provides an architecture for an intrusion detection system (IDS) suitable for installation in a vehicle, and an efficient operation method for multiple detection techniques that can reduce required system resources while maintaining robustness against attack message or security event detection. Furthermore, the present invention provides a method for determining the severity and reliability of a detected security event and determining an action for the detected event based thereon.

Description

[Technical field]

[0001] The present invention relates to intrusion detection for in-vehicle networks. [Background technology]

[0002] The material discussed in this specification is merely intended to provide background information regarding the present invention and may not constitute prior art.

[0003] Intrusion Detection Systems (IDS) and Intrusion Protection Systems (IPS) have been widely used in network security. IDS monitors network activity to detect suspicious behavior. IDS and IPS have the function or capability to respond to detected intrusions (e.g., block signals that may affect the system). As the number of electronic control units (ECUs) installed in vehicles increases significantly and vehicles are connected to external networks through wired and wireless networks, IDS is a trend to be deployed to detect and respond to security threats in the vehicle's internal network. Summary of the Invention [Problem to be solved by the invention]

[0004] The present invention has been made in consideration of the above-mentioned conventional technology, and an object of the present invention is to provide an intrusion detection system (IDS) for detecting intrusions in an in-vehicle network having an architecture suitable for installation in a vehicle, and a method for implementing the same. [Means for solving the problem]

[0005] In order to achieve the above-mentioned object, one aspect of the present invention provides an intrusion detection system for detecting intrusions in an in-vehicle network, comprising: a message queue module for storing network messages collected from an in-vehicle network in a message queue; a repository for securely storing a ruleset, which is a collection of detection rules used for a plurality of detection techniques; a rules engine configured to apply the plurality of detection techniques to the collected network messages to detect security events and determine a severity score and a confidence score for each detected security event; and an interface manager for transmitting a detection report to a remote backend server in response to detection of the security event.

[0006] Embodiments of the intrusion detection system further include one or more of the following features.

[0007] In one embodiment, the severity score is a value indicating how dangerous the associated security event is to the safety of the vehicle or driver and is determined based on a predefined importance for the detection rule that successfully detects the associated security event.

[0008] In one embodiment, the confidence score is a value indicative of the likelihood that an associated security event is an actual attack and is determined based on a difference between a characteristic of the associated security event and a normal characteristic of the in-vehicle network, for example, the confidence score is determined based on a deviation from a normal transmission period for a security event in which a network message is transmitted at a period different from the normal transmission period.

[0009] In one embodiment, the rules engine determines an action for an associated security event based on the severity score and the confidence score.

[0010] In one embodiment, the interface manager is configured to determine an order or timing of transmission of the detection reports based on the severity score and the confidence score.

[0011] In one embodiment, the interface manager is configured to determine a priority of associated security events based on the severity score and the confidence score, transmit detection reports for security events whose priority is higher than a predefined value to the backend server in real time, and transmit detection reports for security events whose priority is equal to or lower than a predefined value to the backend server during idle time.

[0012] In one embodiment, the interface manager is configured to transmit the detection report to the backend server in the order in which the security events are detected, and if multiple security events are detected during a predefined time period, to determine a priority for each security event based on the severity score and the confidence score, and to transmit the detection report for each security event to the backend server according to the priority.

[0013] In order to achieve the above-mentioned object, a method performed by an intrusion detection system for detecting intrusions in an in-vehicle network according to one aspect of the present invention includes a step of storing network messages collected from the in-vehicle network in a message queue, a step of applying a plurality of detection techniques using a ruleset, which is a collection of detection rules, to the collected network messages to detect security events, a step of determining a severity score and a confidence score for each detected security event, and a step of transmitting a detection report to a remote backend server in response to detection of the security event. Effect of the Invention

[0014] According to the present invention, an intrusion detection system (IDS) architecture that efficiently utilizes multiple detection techniques suitable for installation in a vehicle can reduce the required system resources while maintaining robustness against attack message or security event detection, and by determining an action for a detected event based on a judgment of the severity and reliability of the detected security event, it is possible to rapidly respond to the threat of an attack in a vehicle environment with limited processing power and limited network bandwidth. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 is a diagram illustrating an example of where an Intrusion Detection System (IDS) may be placed on a vehicle's CAN network. [Diagram 2] FIG. 2 is a functional block diagram of an IDS for detecting security events in an in-vehicle network according to one embodiment of the present invention. [Diagram 3] 4 is a flowchart illustrating an exemplary operation of an IDS according to one embodiment of the present invention. [Figure 4] FIG. 2 is a conceptual diagram illustrating a method for collecting and distributing security events detected from a vehicle at a remote server according to an embodiment of the present invention. [Diagram 5] FIG. 2 illustrates an exemplary detection report message format used in one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Hereinafter, specific examples of the embodiment of the present invention will be described in detail with reference to the drawings. When adding reference numerals to components in each drawing, it should be noted that the same reference numerals are used for the same components as much as possible even if they are displayed in other drawings. In addition, in the description of the present invention, if it is determined that a detailed description of related publicly known configurations or functions will make the gist of the present invention unclear, the detailed description will be omitted.

[0017] In addition, when describing components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. Such terms are used to distinguish the components from other components, and do not limit the essence, order, or sequence of the components. Throughout the specification, when a part "includes" or "has" a certain component, this does not mean that other components are excluded, but that other components may be further included, unless otherwise specified. Furthermore, terms such as "part," "module," and the like used in this specification refer to a unit that processes at least one function or operation, and are embodied in hardware, software, or a combination of hardware and software.

[0018] FIG. 1 illustrates the locations {(A), (B), (C), (D), (E)} where an intrusion detection system (IDS) is placed on a vehicle's Controller Area Network (CAN) network. The central gateway (CGW) is a central communication node that acts as a router to transmit data between various domains in the vehicle and acts as a gate for communication between an external network and the in-vehicle network. The central gateway (CGW) can be considered as a gate for all data entering the vehicle. The sub-gateways are local communication nodes that are responsible for a specific functional domain such as powertrain, chassis, body, infotainment, etc. In FIG. 1, it is assumed that an ECU (Electronic Control Unit) is connected to a CAN bus in each functional domain, but some functional domains may be connected to a bus that uses other communication protocols (e.g., LIN, FlexRay, Ethernet, etc.).

[0019] The advantages and disadvantages of each location are as follows:

[0020] <(A) Installed in the central gateway> -If an IDS is installed at the central gateway that connects the outside world to all CAN domains, it can detect all attacks that enter the CAN network through the OBD (On-Board Diagnostics) port. Therefore, it is possible to detect messages with attack intent before they affect the CAN network. However, since it must process a much larger number of messages than other locations, it is difficult to distinguish between attacks that are trying to infiltrate the internal network and messages that are not, making it difficult to respond to attacks efficiently.

[0021] <(B) Behind the Central Gateway> -Inspect messages after they have passed through the central gateway's message filtering. This allows detection of fewer but more determined attackers than before they passed through (A). It also allows detection of hacking that directly accesses the CAN bus from the outside and injects malicious messages.

[0022] <(C) Installed on the sub-gateway> - By installing an IDS at a location that manages CAN messages sent to and received from a specific CAN domain, it is easy to detect discrepancies between the CAN messages in (B) and the CAN messages flowing from the specific CAN domain. Since this is a location that can also detect attacks from within the CAN domain to other domains, attackers within the CAN domain can also be detected to a certain degree.

[0023] <(D) Behind the sub-gateway> -It is not easy to hack the system by passing a specific malicious message through the double gateway. However, if the internal controller (ECU) is damaged by an attacker or a malicious controller is replaced and spoofed, and if the CAN bus of the domain is directly connected from the outside, it is still possible to send a malicious message to the CAN bus in the domain. Therefore, this installation location is a location to consider when you cannot trust the internal controller and want to monitor the network hacking of the specific CAN domain to which the controller belongs.

[0024] <Installed in (E)ECU> -The ECU receives all messages on the network, checks the ID of the required CAN message, and selectively processes the required message. The controller analyzes the context of the CAN status message and CAN command message received from outside the controller to operate. Therefore, the ECU needs a high level of security because it must be protected from both the outside and the inside. The reason for equipping the ECU with an IDS is to prevent the loss of important data or malfunction of the ECU from highly capable internal or external attackers who can modify the ECU.

[0025] Multiple IDSs are placed at at least one of the positions {(A), (B), (C), (D), (E)} in which IDSs are placed as exemplified in Fig. 1. For example, an IDS is embedded in each of the central gateway and multiple sub-gateways, or an IDS is embedded in each of the central gateway and main ECU. Also, each domain may be provided with a dedicated electronic control device that performs domain-level monitoring. These IDSs complement each other in monitoring the network to detect attempted attacks and enhance the security of the vehicle network.

[0026] FIG. 2 is a functional block diagram of an IDS for detecting security events in an in-vehicle network according to one embodiment of the present invention.

[0027] As shown in Fig. 2, the intrusion detection system IDS includes a message queue module 20, a rule engine 30, a crypto module 40, an interface manager 50, and a storage 60. The intrusion detection system IDS illustrated in Fig. 2 may be embedded in the gateway or ECU illustrated in Fig. 1, or may be embodied in a dedicated electronic control unit connected to a vehicle network.

[0028] The message queue module 20 stores all CAN traffic data collected from the CAN bus in a message queue. Requests from other modules of the IDS for the collected traffic data are handled by the message queue module 20.

[0029] The rule engine (also called the "detection engine") 30 is a module that operates as a detector and a responder, which are essential functions of an IDS. The functions of the rule engine 30 are mainly divided into a pre-process 31, a detection process 32, and a post-process 33.

[0030] In a pre-process 31, the rule engine 30 updates the rule set stored in the repository 60 with the detection rule set 10 obtained through various means (e.g., a backend server, a USB memory stick, an SD card, etc.) or resets the IDS. The detection rule set is a collection of predefined rules that are used by multiple detection techniques executed in the detection process to detect network messages related to security threats. In a detection process 32, the rule engine 30 detects the occurrence of a security event by detecting network messages related to security threats while running using multiple detection techniques. In a post process 33, the rule engine 30 decides how to handle the detected security threat message, for example, dropping the detected malicious message, logging, or generating an alarm. When a security event occurs (i.e., when a security threat message is detected), the rule engine 30 determines a severity score and a confidence score for the security event.

[0031] The encryption module 40 encrypts or decrypts the rule sets and detection logs and manages the associated keys.

[0032] The interface manager 50 manages a communication connection with the back-end server to download a new rule set 10 from the back-end server or to transmit a detection log or a detection result to the back-end server. The detection rule set and the detection log are encrypted by an encryption engine and securely stored in a repository (e.g., a flash memory) 60. The repository 60 may be provided by another node on the in-vehicle network. In this case, the interface manager 50 also manages a communication connection with the repository 60 located in the other node.

[0033] FIG. 3 is a flow chart illustrating an exemplary operation of an IDS according to one embodiment of the present invention.

[0034] The IDS is configured to execute a pre-process when the vehicle starter is turned on, and then repeatedly execute a detection process and a post-process until the vehicle starter is turned off.

[0035] In the pre-process, when the IDS restarts, it checks the version of the detection rule set, and if the detection rule set currently stored in the storage is not the latest version, it updates the detection rule set to the latest version downloaded, for example, via Automotive Over-The-Air (OTA) or received via the OBD port. The IDS then decrypts the encrypted rule set stored in the storage and loads it into its internal memory (RAM). When the pre-process ends, the detection process, which is the actual detection operation of the IDS, begins.

[0036] In the detection process, when a new CAN message arrives in the message queue, the IDS sequentially performs misuse detection, signature detection, and anomaly detection techniques to determine whether the new CAN message is a network message related to a security threat (hereinafter, may be referred to as a "security threat message," "abnormal message," "malicious message," or "attack message") or not.

[0037] In the post-process, actions such as passing, blocking, logging, or issuing a warning are performed depending on the inspection result of the CAN message. When a security event occurs (i.e., when a security threat message is detected), the IDS identifies the source of the attack, classifies the severity of the attack, and analyzes the impact on functional safety. Furthermore, the IDS can transmit a message including a detection log (hereinafter referred to as a "detection report" or a "detection report message") via the CAN network (or via a separate communication line) to a gateway or a telematics device communicatively connected to the remote network, for example, so that a detection log regarding the security event is transmitted to a back-end server on the remote network.

[0038] The characteristics, advantages and disadvantages of the above-mentioned intrusion detection techniques are as follows.

[0039] Misuse detection is a technique to check the validity of CAN messages by comparing the CAN message ID, CAN message length (Data length code: DLC), message transmission cycle, etc. with values ​​specified in the CAN database. In other words, misuse detection checks whether the collected CAN message conforms to the "valid message format" predetermined by the manufacturer according to predefined rules.

[0040] Misuse detection consumes fewer system resources than signature detection and anomaly detection, but validity checks alone cannot detect malicious data contained in messages.

[0041] Signature detection is a technique to detect predefined (i.e. known) attack patterns through vulnerability analysis of vehicle systems. Such attack patterns are also called signatures. Signature detection checks a black list that contains the signatures of malicious messages without considering the state of the vehicle to determine whether the collected message is malicious or not.

[0042] Signature detection has the advantage of consuming less system resources and having a high detection rate, but it requires a lot of time and security personnel resources to deal with newly emerged attacks because a new signature must be defined for each new attack. This technique has the problem of false negatives, which may miss real attacks.

[0043] Anomaly detection is a technique that checks whether a message is within the range of normal messages based on the vehicle's state, and is performed based on detection rules based on the vehicle's state and command messages. Anomaly detection is a technique that collects and analyzes general behavior on the network to define normal patterns (also called "profiles"), and then detects behavior that exceeds a certain threshold from the normal pattern. Anomaly detection is also called profile-based detection. For example, anomaly detection detects when the rate of change of data included in a CAN message exceeds the normal range, or when two signals that are highly correlated during a specific period suddenly become uncorrelated.

[0044] In the case of anomaly detection, even when unknown new attacks emerge, they can be detected if they deviate from normal patterns, and they place less emphasis on security human resources than signature detection methods. However, they require a lot of system resources and can have problems with false positives, where normal activity is identified as an intrusion depending on the set threshold.

[0045] As described above, a detection rule set is a collection of predefined rules that are used by multiple detection techniques executed in a detection process to detect network messages related to security threats. The detection rule sets include a misuse rule set, a signature rule set, and an anomaly rule set that are used for misuse detection.

[0046] Tables 1 to 3 show the structure of an exemplary detection rule set. Table 1 shows a basic rule set defined based on a CAN database, Table 2 shows an example of a correlation coefficient map between signals, and Table 3 shows an example of a signature that is a known attack pattern used for signature detection. In Table 1, the CAN ID, DLC, signal ID, signal value, and bus ID are used for misuse detection, and a message having a value outside the range defined in Table 1 is considered to be abnormal. The message rate, signal value exchange rate, correlation signal ID, and correlation coefficient between signals shown in Table 2 are used for anomaly detection.

[0047] [Table 1]

[0048] [Table 2]

[0049] [Table 3]

[0050] According to the operation illustrated in Fig. 3, each message stacked in the message queue passes through a detection process consisting of three detection techniques (i.e., misuse detection → signature detection → anomaly detection) and a decision is made to block or pass the message. Therefore, in the illustrated detection process, a normal CAN message also passes through a detection process consisting of three techniques before being transmitted to the gateway or ECU application software equipped with an IDS. Furthermore, if the applied detection technique determines that the CAN message is a security threat message, the application of the remaining detection techniques to the CAN message is bypassed.

[0051] Therefore, the efficiency of the overall detection process increases as detection techniques with higher detection efficiency and lower computing power and time requirements are applied first. Note that the illustrated detection process is configured to apply techniques that are expected to require lower computing power and less time first. Through such configuration of the detection process, the efficiency of the overall detection process can be increased while maintaining robustness against malicious message detection.

[0052] In the operation of the IDS illustrated in FIG. 3, all three detection techniques (i.e., misuse detection, signature detection, and anomaly detection) are used in the detection process. However, some of the three detection techniques are omitted depending on the location where the IDS is placed. For example, since anomaly detection requires a lot of computing power and time, the detection process of the IDS embedded in the ECU uses only misuse search, and only misuse detection and signature search. On the other hand, the detection process of the IDS embedded in the (central / sub) gateway, which has relatively high computing power, uses all three detection techniques. As another example, the central gateway uses all three detection techniques, the sub-gateway uses only misuse detection and signature detection, and the ECU uses only misuse detection.

[0053] FIG. 4 is a conceptual diagram illustrating a method for collecting and distributing security events detected from a vehicle at a remote server according to an embodiment of the present invention.

[0054] Each vehicle transmits security events detected by the IDS to a security operations center (SOC) that manages and analyzes the security events. The IDS of each vehicle generates a detection report. The detection report is transmitted to the back-end server of the SOC via a secure channel to maintain confidentiality and integrity. The detection report includes the following items:

[0055] -Vehicle Identification Number (VIN) -Vehicle status at the time of event detection (e.g., vehicle speed provided by the transmission control unit, engine coolant temperature provided by the engine control unit, steering wheel angle provided by the body control unit, etc.) -Event timestamp (event date and time, event time) -Rule ID, which identifies the detection rule related to the detected event - The CAN ID from the CAN message related to the detected event - The contents of the CAN message related to the detected event

[0056] FIG. 5 is a diagram illustrating an exemplary detection report message format used in one embodiment of the present invention.

[0057] As shown in FIG. 5, the detection report message is composed of fields of tag, Len, VIN, vehicle status, event date, event time, rule ID, CAN ID, and message content. In the detection report, to ensure the confidentiality of data, data in the remaining fields except for the tag and Len fields is encrypted. The tag field contains a value for identifying that this message is a detection report message, the Len field contains a value indicating the data length of the encrypted fields (VIN field to message content field), and the Len field is used to analyze each data item in the back-end server of the security operation center. Furthermore, to ensure the integrity of the detection report, a digital signature is generated for all fields including the tag and Len fields and added to the detection report.

[0058] The security operations center operates a back-end server including a security information and event management system managed by security experts, and collects and statistically analyzes security events generated by the IDS in each vehicle. The security operations center provides the collected detection reports and related information (e.g., security threat level, recommended actions) to stakeholders with data access permissions, such as vehicle manufacturers (or OEMs: Original Equipment Manufacturers), vehicle drivers, vehicle owners, and third parties. Third parties include insurance companies or driving data analysis service providers.

[0059] The IDS determines a severity score and a confidence score for the detected security event. The severity score is a value indicating how dangerous the security event is to the safety of the vehicle or the driver. The severity score is determined by the importance of the particular detection rule that was violated by the security event. The importance of each detection rule is predefined by security experts. The confidence score is a value indicating the possibility that the security event detected by the IDS is an actual attack. The confidence score is dynamically calculated each time a violation of a detection rule is detected by the IDS, and is determined based on the degree of violation of the detection rule (e.g., deviation from the normal characteristics of the in-vehicle network). For example, if two suspicious messages that violate the normal message transmission period are detected and the deviations of the transmission period of each suspicious message from the normal transmission period are 10 ms and 20 ms, respectively, the IDS will give a higher confidence score to the suspicious message that shows a difference of 20 ms than to the message that shows a difference of 10 ms. As another example, the IDS will give a higher confidence score the more the data or the rate of change of data contained in the suspicious message exceeds the normal range.

[0060] The IDS determines the action for the security event based on the severity score and the confidence score. For example, when the IDS detects a security event with a high severity score that may seriously affect the safety of the vehicle, the IDS provides an alarm to the driver advising the driver to immediately stop driving the vehicle. As another example, when a security event with a low confidence score is continuously detected, the IDS provides an alarm to the driver advising the maintenance or inspection of the vehicle. As another example, when the IDS detects a security event with a low severity score, the IDS records the detection result in a log and does not provide any alarm to the driver. This is because frequent alarms regarding security events may cause the driver to miss important alarms.

[0061] The IDS determines a transmission order priority of the detection reports based on the severity scores and reliability scores of the associated security events. The transmission order priority is determined based on the severity scores and reliability scores of the security events. For example, the priority is determined arithmetically using the sum, weight, or average of the severity scores and reliability scores. In one embodiment, the IDS transmits the detection reports to the backend server according to the detection order of the associated security events, and when detecting various security events within a short period of time, transmits the associated detection reports to the backend server of the security operation center according to the priority of the detected security events.

[0062] The IDS determines the timing of transmitting the detection report based on the severity score and confidence score or priority of the associated security event. For example, the IDS transmits the detection report to the backend server of the security operations center in real time (i.e., immediately after detection) for security events whose calculated priority (or severity score) is higher than a predefined value, and transmits the detection report to the backend server of the security operations center in non-real time (i.e., during idling time) for other security events.

[0063] The above-described reporting scheme enables rapid response to attack threats in a vehicular environment with limited processing power and limited network bandwidth.

[0064] For example, by determining the transmission order of detection reports based on the priority, the occurrence of a high-priority attack threat can be quickly notified by the security operation center, and the security operation center can quickly guide the driver, etc., to get out of the threat situation. In the case of a method in which attacks occurring in a vehicle are reported in sequence regardless of the level of threat, the reporting of the attack threat may be delayed in order to report events that do not pose a major threat, and the driver's ability to respond to the threat may be significantly reduced.

[0065] In one embodiment, the IDS determines whether to omit transmission of a detection report to the back-end server of the security operations center based on the severity score, the confidence score, or the priority. For example, the IDS of the vehicle omits transmission of a detection report for security events having a severity score below a predefined value. As another example, the IDS transmits a detection report to the back-end server of the security operations center for security events having a severity score higher than a predefined value, regardless of the confidence score. In one embodiment, for security events having a severity score below a predefined value, the IDS transmits summarized detection information about the event to the back-end server instead of the detection report in the above-mentioned format. This results in efficient use of the vehicle's limited resources and reduces the load on the back-end server that must receive detection reports from a large number of vehicles.

[0066] It should be understood that the exemplary embodiments described above can be embodied in many different ways. In one embodiment, the various methods, devices, and systems described herein are embodied by or included in an electronic control device, gateway, etc., having a processor, memory, communication interface, etc. For example, an electronic control device functions as a device that performs the above-described methods by loading software instructions into a processor and then executing the instructions to perform the functions described herein.

[0067] Meanwhile, various methods described herein may be embodied in instructions stored in a non-transitory recording medium that may be read and executed by one or more processors. Non-transitory recording media may include any type of recording device in which data is stored in a format readable by a computer system. For example, non-transitory recording media may include storage media such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, optical drives, magnetic hard drives, solid-state drives (SSD), etc.

[0068] The above description is merely illustrative of the technical ideas of the embodiments of the present invention, and various modifications and variations are possible within the scope of the essential characteristics of the present invention, if one has ordinary knowledge in the technical field to which the present invention belongs. Therefore, the present embodiment is for the purpose of explanation, not for the purpose of limiting the technical ideas of the present invention, and the scope of the technical ideas of the present invention is not limited by such embodiments.

[0069] [CROSS-REFERENCE TO RELATED APPLICATION] This patent application claims priority to Patent Application No. 10-2020-0018611 filed in Korea on February 14, 2020, and Patent Application No. 10-2021-0019258 filed in Korea on February 10, 2021, the entireties of which are incorporated by reference into this specification. [Explanation of symbols]

[0070] 10 Received detection ruleset 20 Message Queue Module 30 Rule engine (or "detection engine") 31 Pre-process 32 Detection process 33 Post process 40 Crypto module 50 Interface Manager 60 storage

Claims

1. 1. An intrusion detection system for detecting intrusions in an in-vehicle network, comprising: a message queue module configured to store network messages collected from the in-vehicle network in a message queue; an encryption module configured to encrypt or decrypt a rule set, which is a collection of detection rules used for a plurality of detection techniques, and a detection log; a repository configured to securely store the rule set encrypted using the encryption module and the encrypted detection log; a rules engine configured to apply the plurality of detection techniques to the collected network messages to detect security events and to determine a severity score and a confidence score for each detected security event; an interface manager configured to transmit a detection report to a remote backend server in response to detecting the security event; The interface manager includes: transmitting the detection report to the backend server in the order in which the security events are detected; determining a priority of each security event based on the severity score and the confidence score when multiple security events are detected during a predefined time period during the detection of the security events; An intrusion detection system configured to transmit detection reports for each security event to the backend server according to the priority.

2. 2. The intrusion detection system of claim 1, wherein the severity score is a value indicating how dangerous the associated security event is to the safety of a vehicle or driver, and is determined based on a predefined importance for a detection rule that successfully detects the associated security event.

3. 2. The intrusion detection system of claim 1, wherein the confidence score is a value indicative of the likelihood that an associated security event is an actual attack and is determined based on a difference between characteristics of the associated security event and normal characteristics of the in-vehicle network.

4. 4. The intrusion detection system of claim 3, wherein the confidence score is determined based on a deviation from a normal transmission period for a security event in which a network message is transmitted at a period different from the normal transmission period.

5. The intrusion detection system of claim 1 , wherein the rules engine is configured to determine an action for an associated security event based on the severity score and the confidence score.

6. The intrusion detection system of claim 1 , wherein the interface manager is configured to determine an order of transmission of the detection reports based on the severity score and the confidence score.

7. The intrusion detection system of claim 1 , wherein the interface manager is configured to determine a timing for transmitting the detection report based on the severity score and the confidence score.

8. The interface manager includes: prioritizing associated security events based on the severity scores and the confidence scores; transmitting a detection report for the security event having a priority higher than a predefined value to the backend server in real time; 2. The intrusion detection system according to claim 1, further comprising: a detection report for a security event whose priority is equal to or lower than a predefined value, the detection report being transmitted to the backend server during idle time.

9. The intrusion detection system of claim 1 , wherein the interface manager is configured to determine whether to omit transmission of a detection report for an associated security event based on the severity score and the confidence score.

10. 1. A method performed by an intrusion detection system for detecting intrusions in an in-vehicle network, comprising: storing network messages collected from an in-vehicle network in a message queue; applying a plurality of detection techniques using a rule set, which is a collection of detection rules, to the collected network messages to detect security events; determining a severity score and a confidence score for each detected security event; transmitting a detection report to a remote backend server in response to detecting the security event; The step of transmitting the detection report to a remote back-and-server includes: transmitting the detection report to the backend server in the order in which the security events are detected; determining a priority of each security event based on the severity score and the confidence score when multiple security events are detected during a predefined time period during the detection of the security events; transmitting detection reports for each security event to the backend server according to the priority.

11. 11. The method of claim 10, wherein the severity score is a value indicating how dangerous the associated security event is to the safety of a vehicle or driver and is determined based on a predefined importance for a detection rule that successfully detects the associated security event.

12. 11. The method of claim 10, wherein the confidence score is a value indicative of the likelihood that an associated security event is an actual attack and is determined based on a difference between characteristics of the associated security event and normal characteristics of the in-vehicle network.

13. 13. The method of claim 12, wherein the confidence score is determined based on a deviation from a normal transmission period for a security event in which a network message is transmitted at a period different from the normal transmission period.

14. 11. The method of claim 10, further comprising determining an action for an associated security event based on the severity score and the confidence score.

15. The method of claim 10 , further comprising determining an order of transmission of the detection reports based on the severity score and the confidence score.

16. The method of claim 10 , further comprising determining a timing for transmitting the detection report based on the severity score and the confidence score.

17. determining whether to transmit a detection report for an associated security event to the backend server in real time, the detection report being prioritized based on the severity score and the confidence score; A detection report for a security event having a priority higher than a predefined value is transmitted to the backend server in real time; The method of claim 10, wherein detection reports for security events whose priority is equal to or less than a predefined value are transmitted to the backend server during idle times.

18. 11. The method of claim 10, further comprising determining whether to omit transmission of a detection report for an associated security event based on the severity score and the confidence score.

Images