Hosted watchman

• US 10,369,942 B2
• Filed: 01/06/2015
• Issued: 08/06/2019
• Est. Priority Date: 01/06/2014
• Status: Active Grant

• Current Assignee: Argus Cyber Security Ltd. (Continental AG)
• Original Assignee: Argus Cyber Security Ltd. (Continental AG)
• Inventors: Ben Noon, Ofer, Galula, Yaron, Lavi, Oron
• Primary Examiner(s): Bayou, Yonas A
• Application Number:
  US14/590,042
• Publication Number:
  US 20150191136A1
• Time in Patent Office: 1,673 Days
• CPC Class Codes: B60R 16/023 for transmission of signals between vehicle parts or subsystems
• CPC Class Codes: B60R 25/00 Fittings or systems for preventing or indicating unauthorised use or theft of vehicles locks for vehicles E05B77/00-E05B85/00
• CPC Class Codes: G06F 11/30 Monitoring
• CPC Class Codes: G06F 21/55 Detecting local intrusion or implementing counter-measures
• CPC Class Codes: G06F 21/554 involving event detection and direct action
• CPC Class Codes: G06F 21/606 by securing the transmission between two devices or processes
• CPC Class Codes: G06F 21/6281 at program execution time, where the protection is within the operating system
• CPC Class Codes: H04L 12/4625 Single bridge functionality, e.g. connection of two networks over a single bridge
• CPC Class Codes: H04L 2012/40215 Controller Area Network CAN
• CPC Class Codes: H04L 2012/40273 the transportation system being a vehicle
• CPC Class Codes: H04L 63/0227 Filtering policies mail message filtering H04L51/212
• CPC Class Codes: H04L 63/123 received data contents, e.g. message integrity
• CPC Class Codes: H04L 63/14 for detecting or protecting against malicious traffic
• CPC Class Codes: H04L 63/1408 by monitoring network traffic monitoring network traffic per se H04L43/00
• CPC Class Codes: H04L 63/1416 Event detection, e.g. attack signature detection
• CPC Class Codes: H04L 63/1425 Traffic logging, e.g. anomaly detection
• CPC Class Codes: H04L 63/1441 Countermeasures against malicious traffic countermeasures against attacks on cryptographic mechanisms H04L9/002
• CPC Class Codes: H04L 67/12 specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Abstract

An in-vehicle communication network comprising: a bus and at least one node connected to the bus; an in-vehicle network operating system (OS) that manages OS processes, a secondary memory in which process codes for the processes are stored, and a primary memory, into which the OS loads a copy of a process code of a process to enable a processor to run the process and execute the process code; and a module hosted in the OS and having a hook in at least one position of the OS that provides information to the module responsive to operation of the OS that the module processes in accordance with executable instructions that the module comprises to determine if the in-vehicle OS is operating properly.

Claims

1. An in-vehicle communication network comprising:

an operating system (OS);

a bus;

a node having at least one communication port connected to the bus; and

a module comprising;

a memory having software comprising executable instructions, data characterizing messages that pass through the at least one communication port during normal operation of the node, and data providing measures of vehicle health during a period when the in-vehicle communication network is free of damage from a cyber-attack; and

a processor configured to process messages that the node receives or messages that the node operates to transmit via the at least one communication port based on the software to;

detect an electronic or mechanical malfunction of the vehicle;

identify an anomalous message indicative of a cyber-attack, responsive to the data characterizing the messages, the detection of the malfunction, and a measure of vehicle health based on the data providing measures of vehicle health; and

determine and undertake an action that affects the anomalous message in real time.

2. The in-vehicle communication network according to claim 1 wherein processing the messages comprises determining if a process generating the communication messages for transmission by the node is a copy of process code of a known and allowed process.

3. The in-vehicle communication network according to claim 2 wherein the node comprises a secondary memory in which process codes for processes that the node selectively runs are stored, and a primary memory, into which a copy of a process code is loaded to enable the node to run and execute the process code;

and determining if a process code is known and allowed comprises determining if a copy of the process code in the primary memory being run by the processor is substantially the same as the copy of the process code in the secondary memory.

4. The in-vehicle communication network according to claim 3 wherein the module has a hook in at least one position of the OS that provides information to the module responsive to operation of the OS that the module processes to determine if a copy of the process code in the primary memory being run by the processor is substantially the same as the copy of the process code in the secondary memory.

5. The in-vehicle communication network according to claim 2 wherein determining if a process is known and allowed comprises determining if all running threads of the process are running from the code section of the process.

6. The in-vehicle communication network according to claim 5 wherein the module has a hook in at least one position of the OS that provides information to the module responsive to operation of the OS that the module processes to determine if all the running threads are running from the code section of the process.

7. The in-vehicle communication network according to claim 2 wherein determining if the process code is known and allowed comprises verifying if the process code is properly digitally signed.

8. The in-vehicle communication network according to claim 1 wherein the module is a rule based module and comprises a menu of response actions that may be undertaken in response to identifying the anomalous message;

and a set of matching rules that may be used as, or in establishing, a criterion for determining a response action in the menu to be undertaken by the module in response to receiving the message.

9. The in-vehicle communication network according to claim 8 wherein the matching rules and response actions are configured in a decision tree having branches and the module is configured to traverse the decision tree responsive to features of the anomalous message and navigate along a branch of the decision tree that ends at the action to be undertaken by the module in response to the anomalous message.

10. The in-vehicle communication network according to claim 8 wherein the response actions in the library comprise at least one or any combination of more than one response action chosen from:

allowing the message, blocking the message, delaying the message;

limiting the frequency of the message, logging the message into a memory comprised in the module;

changing a component of a state feature vector representing a state of the vehicle; and

/or raising an alert responsive to the message.

11. The in-vehicle communication network according to claim 8 wherein the matching rules comprise at least one or any combination of more than one matching rule chosen from:

determine the message ID;

determine data content of the message;

determine a period of time from a last time that the node encountered a message with the same ID;

determine a transmission frequency at which the message is transmitted;

determine a state of the vehicle; and

/or determine a state of the in-vehicle network.

12. The in-vehicle communication network according to claim 1 wherein the module is operable in an override mode during which the module allows secure modification of its software.

13. The in-vehicle communication network according to claim 1 wherein the module is configured to enable correction of node software if the module determines that the node operates to transmit an anomalous message.

14. The in-vehicle communication network according to claim 1 wherein the malfunction is a mechanical malfunction.

15. A system comprising:

an external data monitoring and processing hub;

a plurality of in-vehicle communication networks according to claim 1, each of which is configured to communicate with the hub and transmit to the hub data responsive to identification of an anomalous message.

16. The system according to claim 15 wherein the hub is configured to process data received from an in-vehicle network of the plurality of in-vehicle networks to generate and transmit signals to at least one of the plurality of in-vehicle networks that changes the executable instructions and/or data in the in-vehicle network'"'"'s module.

17. The system according to claim 15 wherein if data received from an in-vehicle network of the plurality of in-vehicle networks indicates that the node operates to transmit an anomalous message, the hub is configured to transmit signals to the in-vehicle network that modify the node software.

18. The system according to claim 15 wherein the module is configured to accumulate and store in the memory data from a plurality of messages that it monitors.

19. The system according to claim 18 wherein the processor is configured to transmit data comprised in the accumulated data to the hub.

20. The system according to claim 15 wherein the hub determines a common operating state for two or more vehicles of the plurality of vehicles responsive to the data that the hub receives from their respective at least one module.

21. The system according to claim 20 wherein the hub is configured to determine that the two or more vehicles are under threat of an imminent cyber attack, are under a cyber attack, or have vulnerability to a cyber attack responsive to the common operating state.