Intrusion detection system constructing apparatus and method using intrusion detecting rule applied to can communication

Abstract

To provide an intrusion detection system constructing apparatus and method to be applied to controller area network (CAN) communication capable of setting a detection policy rule for detecting and processing a CAN message associated with a vehicle in various ways.SOLUTION: A method includes the steps of: extracting standard information by parsing an input file associated with CAN communication; setting a detection policy rule by applying at least one of a static ruleset and a custom ruleset using the extracted standard information; and creating a policy file to be applied to an intrusion detection system by packing the standard information and the detection policy rule.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present application relates to an apparatus and method for constructing an intrusion detection system applied to CAN communication. [Background technology]

[0002] Recently, there has been active development of modules to support not only electronic control of automobiles but also detailed driving assistance functions such as autonomous driving. In particular, for full self-driving automation, automotive IT fusion technology that supports sensor technology such as LiDAR (distance measurement / object recognition sensor) and external communication technology (V2X: Vehicle to Everything) is being developed.

[0003] In order to effectively transfer various information from various technologies, the control unit (Electronic Control Unit, ECU) inside the vehicle can share information and control the vehicle through the vehicle's internal network (Controller Area Network, CAN) via Vehicle Ethernet.

[0004] As a result, the need for security to protect messages transmitted inside and outside of automobiles is also increasing rapidly.For example, Intrusion Detection Systems (IDS) have been developed to detect attacks on networks inside automobiles, but there is a growing demand for technology that can detect attacks using non-periodic CAN messages and detect the risk of attacks and attacks through in-vehicle networks more accurately and efficiently. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Korean Patent Publication No. 10-2023-0094513 Summary of the Invention [Problem to be solved by the invention]

[0006] The present application is intended to solve the problems of the prior art described above, and aims to provide an apparatus and method for constructing an intrusion detection system applicable to CAN communication, which is capable of setting detection policy rules in various ways for detecting and processing CAN messages associated with a vehicle.

[0007] However, the technical objectives that the embodiments of the present application aim to achieve are not limited to those described above, and other technical objectives may exist. [Means for solving the problem]

[0008] As a technical means for achieving the above technical objectives, a method for constructing an intrusion detection system applicable to CAN communication according to one embodiment of the present application may include a step of parsing an input file associated with CAN communication to extract reference information, a step of applying at least one of a fixed rule set and a custom rule set using the extracted reference information to set a detection policy rule, and a step of packing the reference information and the detection policy rule to generate a policy file to be applied to the intrusion detection system.

[0009] Also, the reference information may include at least one of ECU information, PDU information, message information, signal information, and BUS information.

[0010] In addition, the detection policy rule may include at least one of a first detection policy associated with the BUS information, a second detection policy associated with the message information, and a third detection policy associated with the signal information.

[0011] Also, the setting of the detection policy rule may include setting at least a portion of a plurality of parameters predefined as the fixed rule set.

[0012] Also, setting the detection policy rule may include defining custom parameters applicable as the custom rule set, and determining at least one of a combination and a setting value of the custom parameters.

[0013] The policy file may also include a binary file.

[0014] Also, the binary file can be generated in a hierarchical structure including policy header information, lookup table information, and policy body information.

[0015] Additionally, the policy file may be applied to at least one of a core layer and a detection layer of the intrusion detection system.

[0016] The input files may also include CAN DBC files.

[0017] Meanwhile, an intrusion detection system construction device applicable to CAN communication according to one embodiment of the present application may include an input file analysis unit that parses an input file linked to CAN communication and extracts reference information, a policy setting unit that uses the extracted reference information to apply at least one of a fixed rule set and a custom rule set to set a detection policy rule, and a policy file generation unit that packs the reference information and the detection policy rule to generate a policy file to be applied to the intrusion detection system.

[0018] The policy setting unit can set at least a part of a plurality of parameters predefined as the fixed rule set.

[0019] The policy setting unit may also define custom parameters applicable as the custom rule set, and determine at least one of a combination and a setting value of the custom parameters.

[0020] The above-mentioned problem solving means are merely exemplary and should not be construed as limiting the present application. In addition to the above-mentioned exemplary embodiments, there may be additional embodiments in the drawings and detailed description of the invention. Effect of the Invention

[0021] According to the above-mentioned problem solving means of the present application, it is possible to provide an apparatus and method for constructing an intrusion detection system applied to CAN communication, which can set detection policy rules in various manners for detecting and processing CAN messages associated with a vehicle.

[0022] However, the effects obtained by the present invention are not limited to the above-mentioned effects, and other effects may also exist. [Brief description of the drawings]

[0023] [Figure 1] 1 is a schematic configuration diagram of an intrusion detection system according to an embodiment of the present application. [Diagram 2] 1 is a schematic configuration diagram of an intrusion detection system according to an embodiment of the present application. [Diagram 3] 1 is a conceptual diagram for explaining an operation process of an intrusion detection system construction device applied to CAN communication according to an embodiment of the present application. [Figure 4a] 13 is a table showing an example of parameter types of a static ruleset; [Figure 4b] 13 is a table showing an example of parameter types of a static ruleset; [Figure 5a] 11 is a table showing exemplary parameters that can be adopted for a first detection policy. [Figure 5b]11 is a table showing exemplary parameters that can be adopted for a second detection policy; [Figure 5c] 11 is a diagram showing exemplary parameters that can be adopted for a third detection policy. [Figure 6] 11 is a conceptual diagram for explaining types of combinations of detection rules that can be set by a user. FIG. [Figure 7] 1 is a diagram showing exemplary parameters that can be selected for a Custom Ruleset; [Figure 8] 1 is a diagram illustrating an example of a hierarchical structure of a policy file generated by an intrusion detection system construction device applied to CAN communication according to an embodiment of the present application. [Figure 9] 13 is a diagram showing a data structure of policy header information of a binary file. [Figure 10] 13 is a diagram showing a data structure of a BUS detection rule plug. [Figure 11] 1 is a diagram showing a data structure of lookup table information of a binary file. [Figure 12] 1 is a schematic configuration diagram of an intrusion detection system construction device applied to CAN communication according to an embodiment of the present application. [Figure 13] 1 is an operational flowchart of a method for constructing an intrusion detection system applied to CAN communication according to an embodiment of the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] Hereinafter, the embodiments of the present application will be described in detail with reference to the accompanying drawings so that a person skilled in the art to which the present application pertains can easily carry out the present application. However, the present application may be embodied in various different forms and is not limited to the embodiments described herein. In order to clearly explain the present application in the drawings, parts that are not related to the description are omitted, and similar parts are designated by similar reference numerals throughout the specification.

[0025] Throughout this specification, when a part is said to be "connected" to another part, this includes not only "directly connected" but also "electrically connected" or "indirectly connected" with another element therebetween.

[0026] Throughout this specification, when an element is referred to as being "on," "upper," "top," "upper end," "lower," "lower end," or "bottom" of another element, this includes not only when the element is in contact with the other element, but also when there is another element between the two elements.

[0027] Throughout this specification, when a part "comprises" a certain element, this means that it can further include other elements, rather than excluding other elements, unless specifically stated to the contrary.

[0028] The present application relates to an apparatus and method for constructing an intrusion detection system applied to CAN communication.

[0029] 1 and 2 are schematic diagrams of an intrusion detection system according to an embodiment of the present invention. Specifically, Fig. 1 is a diagram showing a structure in which a CAN IDS is applied to a general ECU system.

[0030] 1, an intrusion detection system 10 according to an embodiment of the present application may have a hierarchical structure including a first layer 11, a second layer 12, and a third layer 13. Also, referring to FIG. 2, the intrusion detection system 10 according to an embodiment of the present application may include a controller 14.

[0031] Specifically, according to an embodiment of the present application, the first layer 11 of the intrusion detection system 10 may include an IDS Detect Layer, and the second layer 12 of the intrusion detection system 10 may include an IDS Core Layer.

[0032] In relation to this, an intrusion detection system construction device 100 (hereinafter referred to as "intrusion detection system construction device 100") applicable to CAN communication according to one embodiment of the present application can operate to define detection policy rules 1000 to be applied to at least one of the detection layer (IDS Detect Layer) and the core layer (IDS Core Layer) of the intrusion detection system 10, and to generate a policy file 2 including the defined detection policy rules.

[0033] In other words, the detection layer (IDS Detect Layer) and the core layer (IDS Core Layer) of the intrusion detection system 10 may be layers that perform the function of detecting and processing CAN messages based on the detection policy rules (Policy Rule) 1000 described in detail below.

[0034] Meanwhile, referring to FIG. 2, if the intrusion detection system 10 adopts a system configuration based on the Classic AUTOSAR platform, for example, the intrusion detection system 10 may be provided with a CAN packet monitoring system (CAN Packet Mirroring System) included in the PduR of the Communication Services Layer of the Basic Software (BSW) or included in Complex Drivers.

[0035] For reference, in the description of the embodiments of the present application, the intrusion detection system construction device 100 can be mounted in a vehicle (not shown) in which the intrusion detection system 10 is equipped in the form of a policy managing program for defining detection policy rules to be applied to the intrusion detection system 10 and generating a policy file 2 reflecting the detection policy rules, but is not limited to this.

[0036] FIG. 3 is a conceptual diagram for explaining an operation process of an intrusion detection system construction device applied to CAN communication according to an embodiment of the present application.

[0037] 3, the intrusion detection system construction device 100 can parse the input file 1 associated with CAN communication to extract reference information. Specifically, the input file 1 provided to the intrusion detection system construction device 100 can be a CAN DBC (registered trademark) file, but is not limited thereto.

[0038] Specifically, the intrusion detection system construction device 100 can acquire reference information (see "a" in FIG. 3) including at least one of ECU information, PDU information, message information, signal information, and BUS information from the input file 1. Meanwhile, the message information can also be referred to as frame information.

[0039] In addition, the intrusion detection system construction device 100 can set the detection policy rule 1000 by applying at least one of a fixed rule set (see "b" in Figure 3) and a custom rule set (see "c" in Figure 3) using the extracted reference information.

[0040] Specifically, the intrusion detection system construction device 100 can set a detection policy rule 1000 including at least one of a first detection policy associated with BUS information among the reference information, a second detection policy associated with message information, and a third detection policy associated with signal information.

[0041] In this regard, the detection policy rule 1000 disclosed in the present application operates like a detection engine base of the intrusion detection system 10, and the detection policy rule 1000 may include a BUS detection rule, a message detection rule, a signal detection rule, a periodic detection rule, etc., and each detection rule is independent and whether or not it operates can be determined based on the detection policy settings.

[0042] In addition, the intrusion detection system construction device 100 can store the contents of the defined detection policy rule 1000 as a policy file 2 in the form of a binary file (Policy Binary), which is an IDS Policy Rule file. In addition, the detection policy rule 1000 can have a buffering table and a policy rule for each message according to the policy rule of the binary file (Policy Binary).

[0043] According to an embodiment of the present application, the intrusion detection system building device 100 may set at least a portion of a plurality of predefined parameters as a static ruleset. In this regard, the static ruleset may refer to a set of detection rules that are set in advance (predetermined).

[0044] 4a and 4b are diagrams showing exemplary parameter types of a static ruleset.

[0045] Referring to Figures 4a and 4b, the intrusion detection system construction device 100 can divide and generate a first detection policy associated with BUS information, a second detection policy associated with message information, and a third detection policy associated with signal information using DBC (registered trademark) information extracted as reference information.

[0046] Figures 5a to 5c are diagrams showing exemplary parameters that can be adopted for the first to third detection policies, respectively. Specifically, Figure 5a is a diagram showing nine preset parameters that can be set for the first detection policy associated with BUS information, Figure 5b is a diagram showing four preset parameters that can be set for the second detection policy associated with message information, and Figure 5c is a diagram showing seven preset parameters that can be set for the third detection policy associated with signal information.

[0047] 5a to 5c, each parameter applied to a detection policy rule 1000 can be distinguished from each other through a policy name (Rule Name) and a policy identification number (Rule ID; Detection ID).

[0048] For example, referring to FIG. 5a, parameters that can be set for the first detection policy include “Bus Load Too High (ID:1)” for detecting when bus traffic (mps) is equal to or greater than a reference value (upper limit), “Bus Load Too Low (ID:2)” for detecting when bus traffic is equal to or less than a reference value (lower limit), “Unknown Arb ID (Arbitration) (ID:3)” for detecting a message not defined in DBC (registered trademark), “Signal Correlation Error (ID:4)” for detecting an abnormality in a Gateway Relay message, “Recv Unknown ECU Message (ID:5)” for detecting receipt of a message from an unidentified (unknown) ECU, “Detected Dos Attack (ID:6)” for detecting a denial of service attack, “Unknown DIAG ID (ID:7)” for detecting an undefined diagnostic message, and “DIAG Message (ID:8)” for detecting a controller denial of service attack using a diagnostic message. These include "Flooding (ID: 8)" to detect control machine scanning attacks using diagnostic messages, and "DIAG Scanning Detected (ID: 9)" to detect control machine scanning attacks using diagnostic messages.

[0049] Similarly, the policy name (Rule Name), policy identification character (Rule ID; Detection ID), and purpose / content (Description) for the configurable parameters for the second detection policy and the third detection policy, respectively, are also shown in Figures 5b and 5c.

[0050] In addition, according to one embodiment of the present application, in relation to the first detection policy, the intrusion detection system construction device 100 can set a BUS detection rule (first detection policy) in the detection rule flag of the policy header information of the policy file 2, and the IDS engine operates according to the setting of the detection rule flag of the policy header, and when an abnormality detection message occurs, the value of the policy identification number (Rule ID; Detection ID) corresponding to each parameter of the BUS detection policy is stored in the detection log buffer of the logging system.

[0051] In addition, according to one embodiment of the present application, in relation to the second detection policy, the intrusion detection system construction device 100 can set a message detection rule (second detection policy) in the detection rule flag of the message header, and the IDS engine operates according to the setting of the detection rule flag in the message header, and when an anomaly detection message occurs, the policy identification number (Rule ID; Detection ID) value corresponding to each parameter of the message detection policy is stored in the detection log buffer of the logging system.

[0052] In addition, according to one embodiment of the present application, in relation to the third detection policy, the intrusion detection system construction device 100 can set a signal detection rule (third detection policy) to the signal type of the signal header, and the IDS engine operates according to the signal type setting of the signal header, and when an anomaly detection message occurs, the policy identification number (Rule ID; Detection ID) value corresponding to each parameter of the signal detection policy is stored in the detection log buffer of the logging system.

[0053] According to another embodiment of the present application, the setting unit 120 may define custom parameters applicable as a custom rule set. Also, the intrusion detection system construction device 100 may determine at least one of a combination of the custom parameters and a setting value. In this regard, a custom rule set refers to a set of detection rules whose contents are determined by a user.

[0054] In particular, in the case of a custom rule set, a detection policy can be set based on sensor information of the CAN message signals received by the intrusion detection system 10 .

[0055] FIG. 6 is a conceptual diagram for explaining types of combinations of detection rules that can be set by the user.

[0056] Referring to Fig. 6, a detection combination that can be set by a user using a custom rule set can be determined through a number of methods shown in Fig. 6. Specifically, Fig. 6(a) shows a detection rule combination that omits an argument value and performs detection only based on a signal type such as a counter or CRC, Fig. 6(b) shows a detection rule combination based on a fixed rule set that requires a detection argument for detection such as Enum or Range Detection, Fig. 6(c) shows a detection rule combination to which a single-user defined conditional expression based on a custom rule set is applied, Fig. 6(d) shows a detection rule combination to which a multi-user defined conditional expression based on a custom rule set is applied, and Fig. 6(e) shows a composite detection rule combination to which both a fixed rule set and a custom rule set are applied.

[0057] Meanwhile, in relation to the multiple user defined conditional expressions shown in (d) of FIG. 6, for example, when the first condition (expression 1), the second condition (expression 2), and the third condition (expression 3) are all satisfied, various logical combinations such as a setting (Expression 1 AND Expression 2 AND Expression 3) in which detection is performed can be applied to the multiple user defined conditions.

[0058] FIG. 7 is a diagram showing exemplary parameters that can be selected for a Custom Ruleset.

[0059] Referring to FIG. 7, the custom parameters can be variously defined by user settings to reflect various situations or scenarios that can be controlled using various sensing information and measurement information acquired in a vehicle (not shown) to which the intrusion detection system 10 is applied, such as a parameter for detecting when the wheels are rotating with the gear lever in P, a parameter for detecting when there is an abnormally large difference in the speed of each wheel, a parameter for detecting a situation in which the vehicle is moving or the battery voltage is very low, and a parameter for detecting an abnormal situation in which a heating wire and a ventilation sheet are attached at the same time.

[0060] Furthermore, the intrusion detection system construction device 100 can generate a policy file to be applied to the intrusion detection system 10 by packaging the reference information and the detection policy rules.

[0061] In other words, the intrusion detection system construction device 100 can set a detection policy rule 1000 based on at least one of a fixed rule set and a custom rule set using the parsed DBC (registered trademark) information, and generate a policy file 2 in the form of a binary file through packing that combines the information thus generated (DBC (registered trademark) information and policy rule information).

[0062] The data structure of the policy file 2 generated by the intrusion detection system construction device 100 will be specifically described below with reference to FIGS.

[0063] FIG. 8 is a diagram illustrating an example of a hierarchical structure of a policy file generated by an intrusion detection system construction apparatus applied to CAN communication according to an embodiment of the present application.

[0064] 8, the intrusion detection system construction device 100 can generate a binary file having a hierarchical structure including policy header information 21, lookup table information 22, and policy body information 23 as the policy file 2. In particular, the policy body information 23 can include information on the detection policy rule 1000 applied to each CAN message.

[0065] FIG. 9 is a diagram showing the data structure of policy header information of a binary file.

[0066] 9, the policy header information 21 is located at the beginning of the policy file 2 and may include a policy version, a creation date and time, and a detection setting applied to the CAN BUS. According to an embodiment of the present application, the policy header information 21 may be configured to integrally set policies for a plurality of pre-set bus information (e.g., six bus information), and may reflect a detection policy rule generated based on the BUS information extracted by DBC (registered trademark). Exemplarily, the policy header information 21 has a size of 48 bytes and may include the following data fields:

[0067] First, the policy version (8 Bytes) is a data field indicating version information of the binary file, and may include, for example, vehicle type information (vehicle type; 2 Bytes), major version information (major version; 2 Bytes), minor version information (minor version, 2 Bytes), and detailed version information (detail version, 2 Bytes).

[0068] Also, the created timestamp (4 Bytes) is a data field indicating information on the creation date (time) of the binary file, and may be expressed in a format such as 1900-01-01.00:00:00 to 2037-12-31.23:59:59.

[0069] In addition, the data field may further include a bus count (2 Bytes) data field indicating the total number of BUS, a message count data field indicating the total number of messages, a buf-5-rec-num (2 Bytes) data field indicating the number of messages when the number of CAN Standard messages being buffered is 5, a buf-10-rec-num (2 Bytes) data field indicating the number of messages when the number of CAN Standard messages being buffered is 10, an fd-buf-5-rec-num (2 Bytes) data field indicating the number of messages when the number of CAN FD messages being buffered is 5, and an fd-buf-10-rec-num (2 Bytes) data field indicating the number of messages when the number of CAN FD messages being buffered is 10.

[0070] In addition, when setting a detection policy rule for multiple pre-set CAN BUS information, a bus number (1 byte) data field indicating the CAN BUS number, a detection rule flag (1 byte) data field indicating the detection rule setting flag to be applied to the BUS, etc. can be applied.

[0071] In relation to this, FIG. 10 is a diagram showing a data structure of a BUS detection rule plug.

[0072] Referring to FIG. 10, the BUS detection rule plug may include a “Bus detect ON / OFF” field to determine whether all detection rules for the BUS itself are applied. If the field is 0, the BUS is excluded from all detection targets, and if the field is 1, the detection rules can be applied only.

[0073] In addition, the BUS detection rule plug may include an “Unknown Arbitration ID detect” field for detecting when a message having an Arbitration ID that does not exist in the detection policy is flowing into the BUS, a “Bus load detect” field for detecting when the BUS load is outside the appropriate range, an “Invalid DIAG detect” field for detecting an invalid diagnostic message flowing into the BUS, a “DoS attack detect” field for detecting a denial of service attack (DoS) against the BUS, an “Unknown DIAG ID detect” field for detecting a diagnostic message that does not exist in the DBC (registered trademark), a “DIAG Flooding detect” field for detecting a controller service attack using a diagnostic message, and a “DIAG Scanning detect” field for detecting a controller scanning attack using a diagnostic message.

[0074] For reference, in the case of the "Bus load detect" field, additional setting of the minimum / maximum load value may be required. In relation to this, a maximum load mps(1Byte) field which is a value for setting the maximum load on the BUS and a minimum load mps(1Byte) field which is a value for setting the minimum load on the BUS may be defined, and the maximum load setting value and the minimum load setting value may be set within a range of 0 to 25500mps in 1 / 100 scale in the form of an mps(messages for second) value, but are not limited thereto.

[0075] In addition, such BUS detection rules can be set by the intrusion detection system construction device 100, and the operation of the IDS Engine of the intrusion detection system 10 can be changed depending on the value of the detection rule setting plug, and when an abnormality detection occurs, the Detection ID value of the BUS detection parameter can be stored in the Log Buffer.

[0076] FIG. 11 is a diagram showing the data structure of lookup table information of a binary file.

[0077] Referring to FIG. 11, the lookup table information 22 may include a set detection policy rule 1000 and information for storing and searching data of a received message in a buffer.

[0078] Specifically, the lookup table information 22 stores items (contents) for CAN information extracted by DBC (registered trademark), and at this time, a lookup key is generated by combining CAN BUS + Arbitration ID (CAN message ID), and policy body information 23 in which a detection policy for the CAN message is stored and information on a buffering table can be stored. For this reason, for example, the lookup table information 22 can be designed with a 6-byte data structure, and can be generated as many times as the total number of messages in DBC (registered trademark).

[0079] Meanwhile, regarding each data field of the lookup table information 22, the “lookup key (2 Bytes)” field, which is a key for searching the Policy Body and Buffering Table, which are detection policy rules, can be composed of a “BUS ID (5 bits)” field indicating the BUS ID stored in the Policy Header and an “Arbitration ID (11 bits)” indicating the CAN message ID, and can include a “policy index (2 Bytes)” field indicating index information of the detection policy rule of the policy body information 23, an “entry index (2 Bytes)” field indicating index information for the buffering table, etc.

[0080] In addition, the entry index field can be composed of a "buffer type (2 bits)" field indicating information for storing the CAN message in the buffering table and a "buffer index (14 bits)" field indicating address information of the buffering table.

[0081] In summary, the operation of storing the received CAN message in the Buffering Table can be performed through the policy index and entry index information of the policy body information 23.

[0082] More specifically, when a CAN message is received, it is stored in the Buffering Table based on the buffer type and index information of the Lookup Table through the Lookup Key (BUS+Arbitration ID). CAN messages are classified into Standard and FD, and the Buffering Table has storage space for all CAN messages in the Lookup Table, and the location where the message is stored varies depending on the type of message. The Buffering Table is allocated to a RAM area (fixed address area) that is already determined during the initialization process. When a CAN message is received, it is determined whether to store the message in a table set with 5 buffers or a table set with 10 buffers based on the buffer type corresponding to the CAN message in the Lookup Table. If the received message is a CAN Standard message and the buffer type is 00, the message is stored in the address corresponding to the buffer index number of the buf-5-rec-num table. The first item in the Lookup Table is used when detecting a message that is not registered in DBC. This item is designated as an item that requires buffering and is allocated to the Buffering Table.

[0083] In addition, when a CAN message is stored in the Buffering Table, the policy index information is used to search for the CAN message detection policy rule in the Policy Body, and the searched information can be used to determine whether the CAN message is valid data.

[0084] The policy body information 23 may include a detection policy rule for each CAN message, and may consist of a “Message Header” field and a “Signal Policy Rule” field for setting a detection policy rule for each CAN message.

[0085] Specifically, the message header field is used in both CAN Standard and CAN FD in the policy body information 23. Based on information obtained from DBC, quick configuration values ​​related to the detection policy rule (normal cycle, upper / lower limit range, detection rule usage plug) are added, and the data structure of the message header field is 5 bytes and can be configured as follows.

[0086] Specifically, the message header fields are: CAN FD (1 bit) field, which is set to 0 if the CAN Standard Message is CAN FD and 1 if the CAN FD is CAN; Periodic (1 bit) field, which is set to 1 if the CAN Message is Periodic; Event (1 bit) field, which is set to 1 if the CAN Message is an event; Reverse (1 bit) field, which indicates when the message flow direction is wrong; DLC (4 bits) field, which indicates the data length of the CAN Message; Average period (1 byte) field, which indicates the average period of the message (can be set in 10 ms increments from 0 to 2550 ms on a 1 / 10 scale); Signal count (6 bits) field, which indicates the number of signals included in the message; Upper period margin (5 bits) field, which indicates the upper limit correction value for determining the average period (can be set in 1 ms increments up to 32 ms); Lower Period margin (5 bits) field, which indicates the lower limit correction value for determining the average period (can be set in 1 ms increments up to 32 ms); Detection rule (4 bits) field, which indicates DLC abnormality detection activation, period detection activation, etc. It can include a flag (4 bits) field, a message body size (12 bits) field (maximum 4095 bytes) that indicates the size of the signal policy rule after the message header, etc.

[0087] In addition, the signal policy rule field can include a signal header in which basic signal information such as the bit position and length of the signal, code, byte order, etc., and the signal type are stored. At this time, the signal type can be inferred from DBC (registered trademark) or determined by the type found by analyzing the dump data.

[0088] Meanwhile, the signal header is used by both CAN Standard and CAN FD, and is a maximum of 64 bytes. The signal start position must be between 0 and 511, and the maximum signal size must not exceed 128 bits (16 bytes). The data structure of the signal header specifically includes a bit index (9 bits) field of size 0 to 512, a length (7 bits) field of size 0 to 127, an order (1 bit) field, a sign (1 bit) field, a signal type (6 bits) field of size 0 to 63, and a signal body size (1 byte) field of size 0 to 255.

[0089] In addition, with regard to the type of signal, "enum(0x00)" is an enumerated signal with limited characteristics with several values ​​(e.g., 0: inactive, 1: on, 2: off, 3: invalid, etc.), "counter(0x01)" is a counter pattern signal whose value changes sequentially, "CRC(0x02)" is a signal that requires CRC calculation and requires a bit range to be used for CRC calculation, "const(0x03)" is a signal for expressing unused bit areas and has characteristics for which there is no separate information in the actual DBC (registered trademark), "sensor(0x04)" is a signal having a general irregular sensor value and has a range of values, and "binary(0x05)" is a signal of 1 bit length expressed as 0 or 1.

[0090] In addition, the Detection Argument is located after the Signal Header and contains the factor value information used in the detection rule. Since there are various factor values ​​depending on the type of detection rule, it is designed to be flexibly implemented using factor codes. The Detection Argument is composed of the Detect Header and the Detect Body, and the Detect Header predetermines the value type and type of the Argument by the combination of the Argument Code and Sub Code.

[0091] Each data field of the detection factor may specifically include an 'argument code (5 bits)' field, a 'sub code (3 bits)' field, an 'argument body size (1 byte)' field, an 'argument body (2 bytes)' field, etc.

[0092] FIG. 12 is a schematic diagram of an intrusion detection system construction device applied to CAN communication according to an embodiment of the present application.

[0093] Referring to FIG. 12, the build device 100 may include an input file analyzer 110, a policy setting unit 120, and a policy file generator .

[0094] The input file analyzer 110 can parse the input file 1 associated with the CAN communication to extract reference information.

[0095] Specifically, the input file analyzer 110 can obtain reference information including at least one of ECU information, PDU information, message information, signal information, and BUS information from the input file 1.

[0096] The policy setting unit 120 can set a detection policy rule by applying at least one of a fixed rule set and a custom rule set using the extracted criteria information.

[0097] Specifically, the policy setting unit 120 can set a detection policy rule including at least one of a first detection policy associated with BUS information among the reference information, a second detection policy associated with message information, and a third detection policy associated with signal information.

[0098] In this regard, according to one embodiment of the present application, the policy setting unit 120 may set at least a portion of a plurality of predefined parameters as a fixed rule set.

[0099] According to another embodiment of the present application, the configuration unit 120 may define custom parameters applicable as a custom rule set, and the policy configuration unit 120 may determine at least one of a combination of custom parameters and a set value.

[0100] The policy file generator 130 can generate a policy file to be applied to the intrusion detection system 10 by packaging the criteria information and the detection policy rules.

[0101] Specifically, the policy file generator 130 can generate a hierarchical binary file including policy header information, lookup table information, and policy body information as a policy file.

[0102] The following briefly describes the operation flow of the present application based on the above detailed description.

[0103] FIG. 13 is a flowchart illustrating an operation of a method for constructing an intrusion detection system applied to CAN communication according to an embodiment of the present application.

[0104] 13 may be performed by the above-mentioned construction device 100. Therefore, even if the following content is omitted, the content described about the construction device 100 may be equally applied to the description of the construction method for an intrusion detection system applied to CAN communication.

[0105] Referring to FIG. 13, in step S11, the input file analyzer 110 may parse the input file 1 associated with the CAN communication to extract reference information.

[0106] Specifically, in step S11, the input file analyzer 110 may obtain reference information from the input file 1, the reference information including at least one of ECU information, PDU information, message information, signal information, and BUS information.

[0107] Next, in step S12, the policy setting unit 120 can set a detection policy rule by applying at least one of a fixed rule set and a custom rule set using the extracted criteria information.

[0108] Specifically, in step S12, the policy setting unit 120 can set a detection policy rule including at least one of a first detection policy associated with BUS information among the reference information, a second detection policy associated with message information, and a third detection policy associated with signal information.

[0109] According to an embodiment of the present application, in step S12, the policy setting unit 120 may set at least a portion of a plurality of predefined parameters as a fixed rule set.

[0110] According to another embodiment of the present application, in step S12, the policy setting unit 120 may define custom parameters applicable as a custom rule set, and may determine at least one of a combination and a set value of the custom parameters.

[0111] Next, in step S13, the policy file generator 130 may generate a policy file to be applied to the intrusion detection system 10 by packaging the reference information and the detection policy rules.

[0112] Specifically, in step S13, the policy file generator 130 may generate a hierarchical binary file including policy header information, lookup table information, and policy body information as a policy file.

[0113] In the above description, steps S11 to S13 may be further divided into additional steps or combined into fewer steps depending on the embodiment of the present application. Also, some steps may be omitted or the order of steps may be changed as necessary.

[0114] The method for constructing an intrusion detection system applied to CAN communication according to an embodiment of the present application may be embodied in the form of program instructions that can be executed by various computer means and recorded on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions recorded on the medium may be those specifically designed and constructed for the present invention, or may be those known and available to those skilled in the art of computer software. Examples of computer readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, and the like. The above hardware devices may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

[0115] In addition, the above-described method for constructing an intrusion detection system applicable to CAN communication may be embodied in the form of a computer program or application stored on a recording medium and executed by a computer.

[0116] The above description of the present application is for illustrative purposes only, and a person having ordinary skill in the art to which the present application pertains will understand that the present application can be easily modified into other specific forms without changing the technical idea or essential features of the present application. Therefore, it should be understood that the above-described embodiments are illustrative in all respects and are not limiting. For example, each component described as a single type may be implemented in a distributed form, and similarly, each component described as a distributed type may be implemented in a combined form.

[0117] The scope of the present application is defined by the claims set forth below rather than the above detailed description, and all modifications and variations derived from the meaning and scope of the claims and their equivalent concepts should be interpreted as being included in the scope of the present application. [Explanation of symbols]

[0118] 10: Intrusion detection system 11: 1st layer 12: Second layer 13: 3rd layer 14: Controller 100: Intrusion detection system construction device applied to CAN communication 110: Input file analysis section 120: Policy setting section 130: Policy file generator 1: Input file 2: Policy files

Claims

1. A method for constructing an intrusion detection system applied to CAN communication, comprising: Parsing an input file in conjunction with CAN communication to extract reference information; setting a detection policy rule by applying at least one of a fixed rule set and a custom rule set using the extracted reference information; packing the criteria information and the detection policy rules to generate a policy file to be applied to the intrusion detection system; A method comprising:

2. The reference information is The method of claim 1 , comprising at least one of ECU information, PDU information, message information, signal information, and BUS information.

3. The detection policy rule is: The method of claim 2 , further comprising at least one of a first detection policy associated with the BUS information, a second detection policy associated with the message information, and a third detection policy associated with the signal information.

4. The step of setting the detection policy rule includes: The method according to claim 3 , further comprising setting at least a portion of a plurality of predefined parameters as the fixed rule set.

5. The step of setting the detection policy rule includes: defining custom parameters applicable as the custom rule set; determining at least one of a combination and a set value of the custom parameters; The method of claim 3 , comprising:

6. The method of claim 1 , wherein the policy file is a binary file.

7. The binary file is The method according to claim 6, wherein the policy information is generated in a hierarchical structure including policy header information, lookup table information, and policy body information.

8. The method of claim 1 , wherein the policy file is applied to at least one of a core layer and a detection layer of the intrusion detection system.

9. The method of claim 1 , wherein the input file comprises a CAN DBC file.

10. In a construction device for an intrusion detection system applied to CAN communication, an input file analyzer that parses an input file in conjunction with CAN communication to extract reference information; a policy setting unit that sets a detection policy rule by applying at least one of a fixed rule set and a custom rule set using the extracted reference information; a policy file generating unit that generates a policy file to be applied to the intrusion detection system by packing the reference information and the detection policy rule; 13. An apparatus comprising:

11. The reference information is The apparatus of claim 10, further comprising at least one of ECU information, PDU information, message information, signal information, and BUS information.

12. The detection policy rule is: The apparatus of claim 11 , comprising at least one of a first detection policy associated with the BUS information, a second detection policy associated with the message information, and a third detection policy associated with the signal information.

13. The policy setting unit The apparatus according to claim 12 , further comprising: setting at least a portion of a plurality of predefined parameters as the fixed rule set.

14. The policy setting unit The apparatus of claim 12 , further comprising: defining custom parameters applicable as the custom rule set; and determining at least one of combinations and setting values ​​of the custom parameters.

15. The policy file is The apparatus according to claim 10, wherein the policy information is a binary file generated in a hierarchical structure including policy header information, lookup table information, and policy body information.

Images