HOSTED WATCHMAN

• US 20150191136A1
• Filed: 01/06/2015
• Published: 07/09/2015
• 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
• Granted Patent: US 10,369,942 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• 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:

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 and/or data that the module comprises to determine if the in-vehicle OS is operating properly.

2. The in-vehicle communication network according to claim 1 wherein the at least one position in the OS comprises at least one or any combination of more than one of:

a fork ( ), exec ( ), spawn ( ), or open ( ).

3. The in-vehicle communication network according to claim 1 wherein processing the information comprises determining if a copy of a process code in the primary memory being run by the processor and generating communication messages for transmission via the in-vehicle communication network is a copy of process code of a known process.

4. The in-vehicle communication network according to claim 3 wherein processing the information comprises determining if the 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 3 wherein processing the information comprises determining if all running threads of the process code in primary memory are running from the code section of the copy of the process code and not from data stored in the primary or secondary memory.

6. The in-vehicle communication network according to claim 3 wherein processing the information comprises determining if all dynamic libraries associated with the process code being run from the primary memory are known and allowed.

7. The in-vehicle communication network according to claim 1 wherein the OS is an OS chosen from the group consisting of:

QNX, Linux, or an Android OS.

8. The in-vehicle communication network according to claim 1 wherein the module executable instructions and/or data are configured to:

monitor messages in communication traffic propagating in the in-vehicle network;

identify an anomalous message in the monitored messages indicative of exposure of the in-vehicle network to damage from a cyber attack; and

take an action that affects the anomalous message in the in-vehicle network.

9. The in-vehicle communication network according to claim 8 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.

10. The in-vehicle communication network according to claim 9 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.

11. The in-vehicle communication network according to claim 9 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.

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

determine a message ID;

determine a transmission frequency at which the message is transmitted in the portion of the in-vehicle network;

determine a state of the vehicle; and

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

13. A system comprising:

a 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 operation of the OS if the module determines that the OS is not operating properly.

14. The system according to claim 13 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.