JP7509310B2 - COMMUNICATION MONITORING DEVICE, COMMUNICATION MONITORING METHOD, AND PROGRAM - Google Patents

Description

The present invention relates to a communication monitoring device, a communication monitoring method and a program.

Technology has been developed to detect abnormal communications using Unified Diagnostic Services (UDS), which is used for fault diagnosis and reprogramming of ECUs (Electronic Control Units) installed in automobiles and other vehicles.

For example, non-patent document 1 discloses a method for detecting anomalies by using natural language processing to learn a language model of normal diagnostic communications.

M. Rumez, J. Lin, T.Fuchβ, R. Kriesten and E. Sax. "Anomaly Detection for Automotive Diagnostic Applications Based on N-Grams," In Proc. COMPSAC, 2020, pp.1423-1429

In a cyber attack, the first stage of the attack is often to send a request to the target and receive a response from the target to reconnoiter whether an attack on the target is possible. Therefore, there is a demand for detecting such reconnaissance and taking measures such as notifying the occurrence of an abnormality and blocking communication from the source of the reconnaissance. However, even in normal diagnostic communication, a diagnostic device may send a request similar to such a reconnaissance request and receive a response from the target device to perform a diagnosis, so conventional technology has the problem of erroneously determining that normal diagnostic communication is a reconnaissance attempt.

The disclosed technology aims to provide a device that performs highly accurate anomaly detection while reducing the probability of false positives in normal diagnostic communications.

The disclosed technology is a communication monitoring device that includes a communication source status update unit that monitors communications from a communication source to a communication destination and updates information indicating the status of the communication source including the number of requests for unlocking the communication destination, a reconnaissance detection unit that detects reconnaissance of the unlocked status of the communication destination by the communication source based on the information indicating the status of the communication source, and an attack detection unit that detects an attack on the communication destination from the communication source that has detected the reconnaissance.

It is possible to provide a device that performs highly accurate anomaly detection while reducing the probability of false positives in normal diagnostic communications.

FIG. 11 is a diagram for explaining an example of a communication method involving unlocking. FIG. 11 is a sequence diagram illustrating an example of a SecurityAccess evasion attack. FIG. 2 is a functional configuration diagram of the communication monitoring device. FIG. 11 is a diagram illustrating an example of communication source state information. FIG. 11 is a diagram illustrating an example of attack determination rule information. 13 is a flowchart showing an example of the flow of a communication monitoring process. 13 is a flowchart showing an example of the flow of a communication source status update process. 13 is a flowchart illustrating an example of the flow of a reconnaissance detection process. 13 is a flowchart illustrating an example of the flow of a reconnaissance completion detection process. 13 is a flowchart illustrating an example of the flow of an attack detection process. FIG. 11 is a first diagram for explaining normal diagnostic communication. FIG. 11 is a second diagram for explaining normal diagnostic communication. FIG. 11 is a third diagram for explaining normal diagnostic communication. FIG. 2 illustrates an example of a hardware configuration of a communication monitoring device. FIG. 2 is a diagram illustrating an example of a hardware configuration of an automobile according to a first embodiment. FIG. 13 is a diagram illustrating an overview of a communication monitoring system according to a second embodiment. FIG. 11 is a functional configuration diagram of a communication monitoring device according to a third embodiment. FIG. 13 is a diagram illustrating an overview of a communication monitoring system according to a fourth embodiment.

Hereinafter, an embodiment of the present invention (the present embodiment) will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applicable is not limited to the following embodiment.

(Prerequisite communication method)
First, a communication method that is the premise of this embodiment will be described. Ethernet (registered trademark), CAN (Controller Area Network), etc. are known as typical communication protocols used for in-vehicle communication in automobiles. For example, an automobile or the like that performs CAN communication is equipped with multiple electronic control units (ECUs: Electronic Control Units). Each ECU communicates with each other by broadcasting message data using the CAN. Furthermore, the message data transmitted and received in the CAN stores a payload that indicates the data body and an ID (called a CAN-ID) that is used to identify the contents of the payload. Note that the CAN message data does not include information regarding the addresses of the sender and destination.

Furthermore, UDS (Unified Diagnostic Services) is known as a protocol for diagnosing and reprogramming ECUs using the above-mentioned Ethernet and CAN. UDS is a protocol that defines the seventh layer of the OSI (Open Systems Interconnection) reference model. UDS defines the communication method, message format, and diagnostic service method (such as memory rewriting service) when a diagnostic machine diagnoses and reprograms an ECU.

UDS also specifies an access control mechanism to allow only legitimate users to use services. Specifically, when using a service (such as a service for reprogramming an ECU) that could cause serious damage if misused by an unauthorized user, UDS requires unlocking of the ECU using the "SecurityAccess Service." The "SecurityAccess Service" is an access control mechanism specified in UDS to prevent unauthorized users from misusing UDS services. Diagnostic communication using the "SecurityAccess Service" is an example of a communication method that involves unlocking.

Figure 1 is a diagram for explaining an example of a communication method involving unlocking. The communication source (e.g., a diagnostic device) requests a "Seed" required for unlocking (requestSeed). Note that SID=0x27 is an identifier for identifying the "SecurityAccessService".

Next, the communication destination (e.g., ECU) transmits a "Seed" to the communication source. The communication source then calculates a Key from the received "Seed" and transmits it to the communication destination (sendKey). This sendKey is an example of a communication requesting unlocking. The communication destination performs unlocking and transmits an unlocking notification to the communication source (positive response).

For the unlocking method described above, it is possible to perform reconnaissance of the unlocked state using "requestSeed" and a SecurityAccess evasion attack using the reconnaissance results. In particular, depending on the implementation method, when the communication destination releases the lock, all locks will be released, not just the communication source that requested the unlock.

In particular, when communicating with an ECU using CAN, it is difficult to identify and manage the source of an unlock request due to the specifications of the CAN protocol. Therefore, if an attacking device (hereinafter referred to as the attacking device) can identify an ECU that has been unlocked by a request from another device, it can use the UDS service without requesting an unlock.

In normal operation, the time that an ECU is unlocked is short, so if an attacking device makes a UDS service request to an arbitrary ECU without reconnaissance of the unlocked state, there is a very high possibility that the ECU is locked. Therefore, the attacking device is very likely to receive a "negative response" to the service request, which means a refusal.

Incidentally, a "negative response" is equivalent to a system error or alert, and is a trace of an attack that is easily detected by a security administrator or system. Therefore, in order to execute a SecurityAccess evasion attack, it is assumed that an attacking device will identify an ECU that is already in an unlocked state by a method that does not generate a "negative response."

Next, this method will be explained in detail. As a premise, UDS specifies the following: An ECU that is already in an unlocked state sends a "Seed" with all byte values of 0x00 in response to "requestSeed". Furthermore, if the ECU receives an incorrect "Key" in "sendKey", it sends a "negative response". Furthermore, even if the communication source repeatedly attempts to obtain a "Seed" without receiving a "sendKey", the ECU will not send a "negative response".

Based on the above specifications, the attacking device can execute the following SecurityAccess evasion attack. That is, the attacking device transmits "requestSeed" to any ECU at any timing to obtain "Seed". The attacking device then determines whether all byte values of the obtained "Seed" are 0x00 or not, and if it determines that all byte values are 0x00, it determines that the ECU is in an unlocked state and executes unauthorized access.

Figure 2 is a sequence diagram showing an example of a SecurityAccess evasion attack. The communication source, which is the attacking device, transmits "requestSeed" to the first communication destination, the second communication destination, etc., to obtain "Seed". The communication source then determines whether all byte values of the obtained "Seed" are 0x00 or not, and if it determines that all byte values are not 0x00, it does nothing and further transmits "requestSeed" to the first communication destination, the second communication destination, etc., and determines whether all byte values of the obtained "Seed" are 0x00 or not. If the communication source determines that all byte values of "Seed" are 0x00, it completes the reconnaissance and executes unauthorized access.

(Communication monitoring device according to this embodiment)
Next, a communication monitoring device according to the present embodiment, which is intended to detect the above-mentioned Security Access evasion attack, will be described.

Figure 3 is a functional configuration diagram of the communication monitoring device. The communication monitoring device 10 includes a memory unit 11, a communication source state update unit 12, a reconnaissance detection unit 13, a reconnaissance completion detection unit 14, an attack detection unit 15, and a communication blocking unit 16.

The memory unit 11 stores various information, specifically, communication source status information 901 and attack determination rule information 902.

The communication source status information 901 is information indicating the status of the communication source, including the number of requests for unlocking to the communication destination. The attack determination rule information 902 is information that specifies the rules for determining whether the target communication is an attack or not.

The communication source status update unit 12 monitors communication from the communication source to the communication destination and updates the communication source status information 901.

The reconnaissance detection unit 13 detects reconnaissance of the unlocked state of the communication destination by the communication source based on the communication source status information 901.

The reconnaissance completion detection unit 14 detects that reconnaissance of the unlocked state from the communication source where reconnaissance was detected to the communication destination has been completed.

The attack detection unit 15 detects whether or not there is an attack from the communication source where reconnaissance has been detected to be completed to the communication destination based on the attack determination rule information 902.

The communication blocking unit 16 blocks communication from the source where an attack is detected to the destination.

Next, we will explain the information handled by the communication monitoring device 10. Figure 4 shows an example of communication source status information.

The source status information 901 includes the following items: source address, difference, status, and destination address.

The value of the "Source Address" item is a value for identifying the source of communication, such as a MAC (Media Access Control) address or an IP (Internet Protocol) address. If the source address is unknown, the value of the "Source Address" item is set to "unknown". Therefore, in the processing described below, status information for a source with an unknown source address can be obtained by referencing a record in which the value of the "Source Address" item is "unknown". For example, if the communication protocol is Ethernet, the communication monitoring device 10 can extract the source address from the communication data. On the other hand, if the communication protocol is CAN, it is difficult for the communication monitoring device 10 to extract the source address from the communication data.

The value of the "Difference" item is the "RequestSeed" from the same communication source to each communication destination.
" is the difference between the number of times "requestSeed" is sent and the number of times "sendKey" is sent. The larger the difference value, the greater the number of times "requestSeed" is sent than the number of times "sendKey" is sent. This indicates that the source of the communication is likely to be conducting the above-mentioned SecurityAccess evasion attack. The number of times "requestSeed" is sent is an example of the number of times a request for unlocking data is made to the communication destination. The number of times "sendKey" is sent is an example of the number of times a request for unlocking based on the unlocking data is made to the communication destination.

The value of the "Status" item indicates the status of each communication source, and is one of the following values: "Normal", "Reconnaissance", "Reconnaissance completed" or "Blocked".

The value of the item "Destination Address" is a value for identifying the destination, such as a MAC address, IP address, CAN-ID, etc.

As described above, the communication source status information 901 is information that includes the "difference" and "status" for each combination of communication source and communication destination.

The communication monitoring device 10 may periodically initialize the communication source status information 901. For example, if the "Difference" and "Status" values have not changed for a predefined period of time, the record in question is deleted (or the "Difference" value is changed to "0", the Status value to "Normal", and the communication destination address value to blank).

Figure 5 shows an example of attack determination rule information. Attack determination rule information 902 includes the following items: destination address and determination rule.

The value of the item "Destination Address" is a value for identifying the destination, such as a MAC address, IP address, etc.

The value of the "Decision Rule" item is a value that indicates the rule for determining whether a message is an attack. For example, the "Decision Rule" item specifies the rule for determining whether a message is an attack, such as determining that all messages addressed to the destination address are attacks, determining that all messages that do not specify a destination are attacks, or determining that messages that contain any value in the payload are attacks.

Next, the operation of the communication monitoring device 10 according to this embodiment will be described. Figure 6 is a flowchart showing an example of the flow of the communication monitoring process.

The communication monitoring device 10 executes a communication monitoring process in response to a user operation or periodically. Specifically, the communication source state update unit 12 of the communication monitoring device 10 executes a communication source state update process to update the communication source state information 901 (step S1). Next, the reconnaissance detection unit 13 executes a reconnaissance detection process to detect reconnaissance by each communication source (step S2).

Next, the reconnaissance completion detection unit 14 executes a reconnaissance completion detection process to detect that the reconnaissance by the communication source whose reconnaissance was detected has been completed (step S3). Then, the attack detection unit 15 executes an attack detection process to detect an attack by the communication source whose reconnaissance was detected to have been completed (step S4).

Next, the communication cutoff unit 16 cuts off the communication for which an attack has been detected (step S5). Then, the communication cutoff unit 16 updates the value of the "Status" item in the communication source status information 901 related to the communication for which the attack has been detected to "Cutoff" (step S6).

Next, the details of each process from step S1 to step S4 will be described. FIG. 7 is a flowchart showing an example of the flow of the communication source status update process. The communication source status update unit 12 determines whether the application layer protocol of the communication to be monitored is UDS (step S11). Then, when the communication source status update unit 12 determines that the protocol is not UDS (step S11: No), it terminates the communication source status update process.

When the communication source state update unit 12 determines that the protocol is UDS (step S11: Yes), it determines whether the SID specified in the communication is 0x27 (step S12). When the communication source state update unit 12 determines that the SID is not 0x27 (step S12: No), it ends the communication source state update process.

If the communication source state update unit 12 determines that SID=0x27 (step S12: Yes), it determines whether or not sub-function=requestSeed (step S13). If the communication source state update unit 12 determines that sub-function=requestSeed (step S13: Yes), it adds 1 to the value of the "Difference" item in the communication source state information 901 (step S15).

If the communication source state update unit 12 determines that the sub-function is not equal to requestSeed (step S13: No), it further determines whether or not the sub-function is equal to sendKey (step S14). If the communication source state update unit 12 determines that the sub-function is not equal to sendKey (step S14: No), it terminates the communication source state update process.

When the communication source state update unit 12 determines that sub-function = sendKey (step S14: Yes), it subtracts 1 from the value of the "Difference" item in the communication source state information 901 (step S16).

In this way, the communication source status update unit 12 adds 1 to the value of the item "Difference" if the communication being monitored is "requestSeed", and subtracts 1 from the value of the item "Difference" if the communication being monitored is "sendKey".

Figure 8 is a flowchart showing an example of the flow of the reconnaissance detection process. The reconnaissance detection unit 13 determines whether the value of the "Difference" item in the communication source state information 901 exceeds a preset threshold value (step S21). The threshold value may be set by the user as an arbitrary value, for example, 2 or more.

When the reconnaissance detection unit 13 determines that the value of the "Difference" item exceeds the threshold (step S21: Yes), it updates the value of the "Status" item in the communication source status information 901 to "Reconnaissance in progress" (step S22). When the reconnaissance detection unit 13 determines that the value of the "Difference" item does not exceed the threshold (step S21: No), it updates the value of the "Status" item in the communication source status information 901 to "Normal" (step S23).

Figure 9 is a flowchart showing an example of the flow of the reconnaissance completion detection process. The reconnaissance completion detection unit 14 determines whether the application layer protocol of the communication to be monitored is UDS (step S31). Then, when the reconnaissance completion detection unit 14 determines that the protocol is not UDS (step S31: No), it ends the reconnaissance completion detection process.

When the reconnaissance completion detection unit 14 determines that the protocol is UDS (step S31: Yes), it determines whether the SID specified in the communication is 0x67 (step S32). When the reconnaissance completion detection unit 14 determines that the SID is not 0x67 (step S32: No), it ends the reconnaissance completion detection process.

If the reconnaissance completion detection unit 14 determines that SID = 0x67 (step S32: Yes), it determines whether or not sub-function = requestSeed (step S33). If the reconnaissance completion detection unit 14 determines that sub-function = requestSeed is not true (step S33: No), it ends the reconnaissance completion detection process.

If the reconnaissance completion detection unit 14 determines that sub-function=requestSeed (step S33: Yes), it determines whether all byte values of "Seed" are "0x00" (step S34). If the reconnaissance completion detection unit 14 determines that any byte value of "Seed" is not "0x00" (step S34: No), it ends the reconnaissance completion detection process.

If the reconnaissance completion detection unit 14 determines that all bytes of "Seed" are "0x00" (step S34: Yes), it determines whether the value of the "Status" item in the communication source status information 901 is "Reconnaissance in progress" (step S35). If the reconnaissance completion detection unit 14 determines that the value of the "Status" item is not "Reconnaissance in progress" (step S35: No), it terminates the reconnaissance completion detection process.

When the reconnaissance completion detection unit 14 determines that the value of the item "status" is "reconnaissance in progress" (step S35: Yes), it updates the value of the item "status" in the communication source status information 901 to "reconnaissance completed" and the value of the item "destination address" to the detected communication destination address (step S36).

Figure 10 is a flowchart showing an example of the flow of the attack detection process. The attack detection unit 15 determines whether the application layer protocol of the communication to be monitored is UDS (step S41). Then, when the attack detection unit 15 determines that the protocol is not UDS (step S41: No), it ends the attack detection process.

When the attack detection unit 15 determines that the protocol is UDS (step S41: Yes), it determines whether the value of the "Status" item in the communication source status information 901 is "Reconnaissance Completed" or "Blocked" (step S42). When the attack detection unit 15 determines that the value of the "Status" item in the communication source status information 901 is neither "Reconnaissance Completed" nor "Blocked" (step S42: No), it terminates the attack detection process.

When the attack detection unit 15 determines that the value of the item "Status" is "Reconnaissance Completed" or "Blocked" (step S42: Yes), it determines whether the judgment rules defined in the attack judgment rule information 902 are satisfied (step S43). When the attack detection unit 15 determines that the judgment rules are not satisfied (step S43: No), it terminates the attack detection process.

If the attack detection unit 15 determines that the judgment rules are satisfied (step S43: Yes), it judges the target communication to be an attack (step S44).

(Operation of the communication monitoring device 10 according to the present embodiment for normal diagnostic communication)
Next, the operation of the communication monitoring device 10 according to the present embodiment for normal diagnostic communication will be described.

Figure 11 is the first diagram to explain normal diagnostic communication. The case in Figure 11 is a case of normal diagnostic communication because it occurs when the diagnostic device, which is the source of communication, requests "Seed" again after failing to receive "Seed" for some reason after requesting "Seed".

In this case, for example, if machine learning were used to determine whether or not there is an anomaly, as has been done in the past, it would be determined that the probability of occurrence is low because cases in which the "Seed" fails to be received for some reason are rare, and the case would be detected as an anomaly.

In contrast, the communication monitoring device 10 according to this embodiment does not immediately determine an abnormality based on a single abnormal communication, but by appropriately setting the threshold, it is possible to determine the difference between the number of times "requestSeed" is sent and the number of times "sendKey" is sent based on the cumulative value. Therefore, the communication monitoring device 10 according to this embodiment can determine the case in FIG. 11 as normal communication. Also, even if the threshold is set to 1 and the reconnaissance detection unit 13 detects reconnaissance, the communication monitoring device 10 can determine the case in FIG. 11 as normal communication based on the result of the determination by the reconnaissance completion detection unit 14 or the attack detection unit 15.

Figure 12 is the second diagram to explain normal diagnostic communication. The case in Figure 12 is a case of normal diagnostic communication because it occurs when a diagnostic device, which is the communication source, evaluates the ECUs of each communication destination, for example, in a security evaluation at the time of type approval of an automobile.

Even in this case, for example, if machine learning is used to determine whether or not there is an anomaly, as in the past, it is rare for a "requestSeed" to be repeatedly sent to multiple communication destinations, so it is determined that this is a case with a low probability of occurrence and is likely to be detected as an anomaly.

In contrast, according to the communication monitoring device 10 of this embodiment, even if the reconnaissance detection unit 13 detects reconnaissance, the case of Figure 12 can be determined to be normal communication based on the result of judgment by the reconnaissance completion detection unit 14 or the attack detection unit 15.

Figure 13 is a third diagram for explaining normal diagnostic communication. The case in Figure 13 is a case where a "requestSeed" is sent by another diagnostic machine, which is the second communication source, to a communication destination ECU that has been unlocked by a diagnostic machine, which is the first communication source, by chance, and is a case of normal diagnostic communication.

Even in this case, for example, if machine learning is used to determine whether or not an anomaly has occurred, as in the past, the second communication source sends a "requestSeed", and after a "Seed" with all byte values of "0x00" is returned as a response, reprogramming is performed. Therefore, it is determined that this is a case with a low probability of occurrence, and it is likely to be detected as an anomaly.

In contrast, according to the communication monitoring device 10 of this embodiment, since reconnaissance such as repeatedly executing "requestSeed" is not performed in the communication from the second communication source, it is considered that the reconnaissance detection unit 13 does not detect reconnaissance. Therefore, the communication monitoring device 10 can determine that the case in Figure 13 is normal communication.

(Example of hardware configuration of communication monitoring device)
The communication monitoring device 10 can be realized, for example, by making a computer execute a program describing the processing contents described in this embodiment. Note that this "computer" may be a physical machine or a virtual machine on the cloud. When a virtual machine is used, the "hardware" described here is virtual hardware.

The above program can be recorded on a computer-readable recording medium (such as a portable memory) and can be stored or distributed. The above program can also be provided via a network such as the Internet or e-mail.

Figure 14 is a diagram showing an example of the hardware configuration of the computer. The computer in Figure 14 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., which are all interconnected by a bus B.

The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 via the drive device 1000 into the auxiliary storage device 1002. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

When an instruction to start a program is received, the memory device 1003 reads out and stores the program from the auxiliary storage device 1002. The CPU 1004 realizes the functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network. The display device 1006 displays a GUI (Graphical User Interface) based on a program, etc. The input device 1007 is composed of a keyboard and mouse, buttons, a touch panel, etc., and is used to input various operational instructions. The output device 1008 outputs the results of calculations.

Next, examples 1, 2, 3 and 4 will be described as specific examples of this embodiment.

Example 1
The first embodiment is an example in which a communication monitoring device 10 is mounted on an in-vehicle network of an automobile.

Figure 15 is a diagram showing an example of the hardware configuration of an automobile according to Example 1. The automobile 1 includes a communication monitoring device 10, an ECU 20, and an external communication interface 30. In this configuration, the communication monitoring device 10 can monitor communications via the external communication interface 30, identify the source of the communication and the ECU 20 that is the destination of the communication, and block communications that are detected as an attack.

Example 2
The second embodiment is an example in which communication monitoring is performed by a device other than the automobile 1 (which may be implemented by a cloud server or the like), and the communication device 40 provided in the automobile 1 has a function of blocking communication.

Figure 16 is a diagram showing an overview of a communication monitoring system according to Example 2. The communication monitoring system includes an automobile 1 and a communication monitoring device 10. The automobile 1 and the communication monitoring device 10 are connected to each other so as to be able to communicate with each other via wireless communication or the like.

The automobile 1 includes an ECU 20, an external communication interface 30, and a communication device 40. The communication device 40 includes a communication unit 41 and a communication cutoff unit 42.

The communication monitoring device 10 has a communication unit 17 instead of the communication cut-off unit 16 of the communication monitoring device 10 shown in Figure 3.

The communication device 40 transmits data indicating the content of communication between the ECU 20 and external equipment via the external communication interface 30 to the communication monitoring device 10 via the communication unit 41. The communication monitoring device 10 executes each process according to the present embodiment described above, except for the communication cut-off unit 16, based on the data received via the communication unit 17. The communication monitoring device 10 then transmits information about the communication in which an attack has been detected to the communication device 40. The communication cut-off unit 42 of the communication device 40 cuts off the communication in which an attack has been detected, based on the information received from the communication monitoring device 10.

Example 3
The third embodiment is an example in which a detection result is transmitted to a pre-specified destination instead of cutting off communication. Fig. 17 is a functional configuration diagram of a communication monitoring device according to the third embodiment. The communication monitoring device 10 according to the third embodiment includes a detection result transmission unit 18 instead of the communication cutoff unit 16 of the communication monitoring device 10 shown in Fig. 3.

The detection result transmission unit 18 sends information about the communication detected as an attack via email, message, SNS, etc. to a pre-specified destination.

The hardware configuration of the automobile according to the third embodiment is the same as that shown in FIG. 15. The detection result transmission unit 18 of the communication monitoring device 10 transmits the detection result to an external device via the external communication interface 30. The detection result transmission unit 18 may also display the detection result on a display device or the like provided in the automobile 1.

Example 4
The fourth embodiment is an example in which communication monitoring is performed by a device different from the automobile 1 (which may be implemented by a cloud server or the like), and the device transmits the detection results.

Figure 18 is a diagram showing an overview of a communication monitoring system according to Example 4. The communication monitoring system includes an automobile 1 and a communication monitoring device 10. The automobile 1 and the communication monitoring device 10 are connected to each other so as to be able to communicate with each other via wireless communication or the like.

The automobile 1 includes an ECU 20, an external communication interface 30, and a communication device 40. The communication device 40 includes a communication unit 41.

The communication monitoring device 10 has the same functional configuration as the communication monitoring device 10 shown in Fig. 17. The detection result transmission unit 18 of the communication monitoring device 10 according to the fourth embodiment transmits information about the communication detected as an attack to a pre-specified destination by email, message, SNS, etc.

According to the communication monitoring device 10 of this embodiment, communication from a communication source to a communication destination is monitored, communication source status information 901 including the number of requests for unlocking the communication destination is updated, and reconnaissance of the unlocked state of the communication destination by the communication source is detected based on the communication source status information 901. This enables detection according to the state of the communication source, and reduces the probability of false detection of normal diagnostic communication. In addition, by detecting an attack on the communication destination from a communication source where reconnaissance has been detected, it is possible to block communication from the communication source to the communication destination or send the detection result to a specified destination.

The above-mentioned attack detection unit 15 may detect attacks using the results of various machine learning techniques (detecting abnormal communications as a result of anomaly detection of diagnostic communications) or rules using time (for example, detecting diagnostic communications sent within 1 second after a "Seed" whose all-byte value is "0x00" is observed) instead of the attack determination rule information 902.

(Summary of the embodiment)
This specification describes at least the communication monitoring device, communication monitoring method, and program described in the following sections.
(Section 1)
a communication source status update unit that monitors communication from a communication source to a communication destination and updates information indicating a status of the communication source, including the number of requests for unlocking made to the communication destination;
a reconnaissance detection unit that detects reconnaissance of an unlocked state of the communication destination by the communication source based on information indicating the state of the communication source;
an attack detection unit that detects an attack from the communication source where the reconnaissance has been detected to the communication destination,
Communications monitoring equipment.
(Section 2)
The information indicating the state of the communication source is information indicating a difference between the number of times a data request for unlocking is transmitted to the communication destination and the number of times request data for unlocking based on the data is transmitted,
The reconnaissance detection unit detects reconnaissance of an unlocked state of the communication destination by the communication source based on the difference.
2. A communications monitoring device as recited in claim 1.
(Section 3)
a communication cutoff unit that cuts off communication from the communication source where the attack has been detected to the communication destination,
3. A communication monitoring device according to claim 1 or 2.
(Section 4)
Further comprising a detection result transmission unit that transmits information indicating the detection result.
4. A communication monitoring device according to any one of claims 1 to 3.
(Section 5)
A reconnaissance completion detection unit detects that reconnaissance from a communication source where reconnaissance has been detected to a communication destination has been completed,
The communication monitoring device according to any one of claims 1 to 4, wherein the attack detection unit detects an attack from the communication source, for which completion of reconnaissance has been detected, to the communication destination.
(Section 6)
The communication destination is an ECU, and the communication is for diagnosing the ECU.
6. A communication monitoring device according to any one of claims 1 to 5.
(Section 7)
1. A computer-implemented method comprising:
monitoring communication from a communication source to a communication destination and updating information indicating a state of the communication source, including a number of requests for unlocking to the communication destination;
detecting a reconnaissance of an unlocked state of the communication destination by the communication source based on information indicating the state of the communication source;
detecting an attack from the communication source from which the reconnaissance was detected to the communication destination,
Communications monitoring methods.
(Section 8)
A program for causing a computer to function as each unit in the communication monitoring device according to any one of claims 1 to 6.

Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention as described in the claims.

REFERENCE SIGNS LIST 1 Automobile 10 Communication monitoring device 11 Memory unit 12 Communication source state update unit 13 Reconnaissance detection unit 14 Reconnaissance completion detection unit 15 Attack detection unit 16 Communication cutoff unit 17 Communication unit 18 Detection result transmission unit 20 ECU
30 External communication interface 40 Communication device 41 Communication unit 42 Communication cutoff unit 901 Communication source state information 902 Attack determination rule information 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU
1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims (8)

a communication source status update unit that monitors communication from a communication source to a communication destination and updates information indicating a status of the communication source, including the number of requests for unlocking made to the communication destination;
a reconnaissance detection unit that detects reconnaissance of an unlocked state of the communication destination by the communication source based on information indicating the state of the communication source;
an attack detection unit that detects an attack from the communication source where the reconnaissance has been detected to the communication destination,
Communications monitoring equipment. The information indicating the state of the communication source is information indicating a difference between the number of times data for unlocking is requested to the communication destination and the number of times unlocking is requested based on the data,
The reconnaissance detection unit detects reconnaissance of an unlocked state of the communication destination by the communication source based on the difference.
The communication monitoring device according to claim 1. a communication cutoff unit that cuts off communication from the communication source where the attack has been detected to the communication destination,
3. A communication monitoring device according to claim 1 or 2. Further comprising a detection result transmission unit that transmits information indicating the detection result.
The communication monitoring device according to any one of claims 1 to 3. A reconnaissance completion detection unit detects that reconnaissance from a communication source where reconnaissance has been detected to a communication destination has been completed,
The communication monitoring device according to claim 1 , wherein the attack detection unit detects an attack from the communication source, for which completion of reconnaissance has been detected, to the communication destination. The communication destination is an ECU, and the communication is for diagnosing the ECU.
The communication monitoring device according to any one of claims 1 to 5. 1. A computer-implemented method comprising:
monitoring communication from a communication source to a communication destination and updating information indicating a state of the communication source, including a number of requests for unlocking to the communication destination;
detecting a reconnaissance of an unlocked state of the communication destination by the communication source based on information indicating the state of the communication source;
detecting an attack from the communication source from which the reconnaissance was detected to the communication destination,
Communications monitoring methods. A program for causing a computer to function as each component of a communication monitoring device described in any one of claims 1 to 6.

Images