Patent Description:
The invention relates generally to the field of security devices, and more specifically a system and method for monitoring intrusion anomalies in an automotive environment.

The number of electronic devices being installed in-vehicles is rapidly increasing. In the past, electronic devices in automobiles were discrete devices handling a particular function, operating in a stand-alone environment. In the <NUM>'s it was recognized that there would be a need to develop a network operating standard for vehicles, and the controller area network (CAN) bus was born.

Over time the number of interconnected devices utilizing a CAN bus has rapidly increased. These interconnected devices may control driving features, such as engine speed, braking control and steering control, as well as comfort features such as lighting, windows and sun-roof controls.

A further development has been the expansion of the Internet, and the ever growing demand for wireless access to the Internet. The expansion of cellular telephones and wireless Internet access ensures that in the future vehicles will be connected to external networks. In the recent past, access to the vehicle was restricted to the use of a dedicated service cable, and the only wireless access was for a radio delivering news and music. Today, an integrated infotainment system is being provided that delivers to the vehicle both entertainment and information content.

As the number of electronic devices in-vehicles have multiplied, a number of automotive manufacturers have agreed upon an open standard software architecture for automotive electronic control units (ECUs). Presently, the AUTOSAR consortium of Munich, Germany has released version <NUM> of the Autosar Classic Platform. Autosar compliant diagnostics are designed to detect actual failures, or defects, in one or more ECUs. The diagnostics use a particular communication protocol designated "Diagnostics over Internet Protocol" (DoIP), or unified diagnostic services (UDS), which are designed for communication between a test equipment and an ECU via an on-board Ethernet switch. DoIP is a transparent protocol, and does not involve translation between the test equipment and the ECU. DoIP is defined in ISO <NUM>, Part <NUM>, published by the International Organization for Standardization, Geneva, Switzerland. DoIP facilitates diagnostics related communication between external test equipment and automotive ECUs. A diagnostic communication manager (DCM) within the ECU communicates with the test equipment, transferring the relevant pre-defined diagnostic trouble code (DTC) defined by the automotive manufacture which is representative of an detected failure in the respective ECU.

Although systems for generating and communicating detected faults in the various ECUs, the prior art lacks a system to monitor and identify attacks by external attackers attempting to intrude on any portion of the automotive communication network. This includes, but is not limited to: statistical anomalies in the data being transmitted over the network, e.g. a distributed denial of service (DDOS) attack, as will be described below; attempts to spoof a MAC address of an ECU; subscription requests from IP of PORT; incorrect values in SOME/IP information; signals which deviate from a predefined model or rule; stack overflows; and return-oriented programming attacks. Additionally, no mechanism is provided for vehicle to vehicle DoIP communication, thus vehicles cannot share DTCs with each other.

European patent publication <CIT> is addressed to a system or method that may include an in-vehicle network including an interface port for connecting an external device to the in-vehicle network; and a security unit connected to the in-vehicle network, the security unit adapted to enable an external device to communicate with the in-vehicle network, over the interface port, based on a security token received from the external device. A system or method may, based on a token, prevent an external device from at least one of: communicating with a selected set of components on in an in-vehicle network, communicating with a selected set of network segments in the in-vehicle network and performing a selected set of operations.

European patent publication <CIT> is addressed to 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.

A paper titled "<NPL>, is addressed to a method and framework to detect manipulations in automotive control systems. The paper presents a context-aware intrusion detection system (CAID) framework capable to recognize manipulations of the physical system using cyber means.

US patent application publication <CIT> is addressed to a data analysis apparatus that includes: a processor; and a memory including a set of instructions that, when executed by the processor causes the processor to perform operations including: obtaining anomaly analysis results each including information identifying anomaly data of first and second vehicles provided with an in-vehicle network including one or more networks; identifying, for each of the first and second vehicles, a primary ECU having higher relevance to the anomaly data among ECUs connected to the in-vehicle network; identifying, for each of the first and second vehicles, ECUs connected to a network in the one or more networks to which the primary ECU is connected as a secondary ECU set; and identifying an ECU included in both of the secondary ECU set identified for the first vehicle and the secondary ECU set identified for the second vehicle and satisfying a predetermined condition as an anomaly-relevant ECU.

Accordingly, it is a principal object of the present invention to overcome at least some of the disadvantages of prior art bus control methods and systems. This is provided in one embodiment by a system according to claim <NUM>,.

In one embodiment, the anomaly analyzer is further arranged to determine a vehicle status grade, the vehicle status grade determined responsive to a predetermined function of the received at least one vehicle status signal, wherein the anomaly incident list comprises a plurality of sets of anomaly incident list parameter values, the comparison performed in relation to the plurality of sets of anomaly incident list parameter values, and wherein the anomaly incident list parameter values are selected responsive to the determined vehicle status grade. In another embodiment, the at least one security monitor is arranged to detect the intrusion anomalies responsive to a predetermined attribute of one or more messages not meeting a predetermined validation parameter value, and wherein responsive to the predetermined outcome of the comparison, the anomaly analyzer is further arranged to: generate an adjustment signal; and output the generated adjustment signal to the at least one security monitor, the predetermined validation parameter value of the at least one security monitor adjusted responsive to the generated adjustment signal.

In one embodiment, the received at least one vehicle status signal comprises at least one signal indicating a status of at least one internal system of the vehicle. In another embodiment, the received at least one vehicle status signal indicating a status of at least one internal system of the vehicle comprises at least one signal indicating a status of: a speed of the vehicle; a steering wheel angle of the vehicle; a gear the vehicle is in; brakes of the vehicle; an engine of the vehicle; or a position of a gyro of the vehicle.

In one embodiment, the received at least one vehicle status signal comprises at least one signal indicating a status of an environment external to the vehicle. In another embodiment, the received at least one vehicle status signal comprises at least one signal indicating a status of additional vehicles surrounding the vehicle.

In another embodiment, the system further comprises a communication control unit arranged to control data communication with the at least one electronic control unit, wherein the at least one anomaly incident comprises a plurality of anomaly incidents, the predetermined outcome of the comparison comprising identifying that the accumulated output information indicates the presence of one of the plurality of anomaly incidents, wherein the predetermined incident signal is selected from a plurality of predetermined incident signals responsive to the respective detected one of the plurality of anomaly incidents, and wherein, the plurality of predetermined incident signals comprises: an alert message; and a command to disable a communication function of the communication control unit.

In one embodiment, wherein the at least one electronic control unit comprises a plurality of electronic control units, and wherein the at least one security monitor comprises a plurality of local security monitors, each of the plurality of local security monitors associated with a respective one of the plurality of electronic control units.

In one independent embodiment, a method of monitoring intrusion anomalies in an automotive vehicle according to claim <NUM> is provided.

In one embodiment, the method further comprises determining a vehicle status grade, the vehicle status grade determined responsive to a predetermined function of the received at least one vehicle status signal, wherein the anomaly incident list comprises a plurality of sets of anomaly incident list parameter values, the comparison performed in relation to the plurality of sets of anomaly incident list parameter values, and wherein the anomaly incident list parameter values are selected responsive to the determined vehicle status grade. In another embodiment, the detecting the intrusion anomalies responsive to a predetermined attribute of one or more messages not meeting a predetermined validation parameter value, and wherein responsive to the predetermined outcome of the comparison, the method further comprises: generating an adjustment signal; and outputting the generated adjustment signal, the predetermined validation parameter value adjusted responsive to the output adjustment signal.

In another embodiment, the at least one anomaly incident comprises a plurality of anomaly incidents, the predetermined outcome of the comparison comprising identifying that the accumulated output information indicates the presence of one of the plurality of anomaly incidents, wherein the predetermined incident signal is selected from a plurality of predetermined incident signals responsive to the respective detected one of the plurality of anomaly incidents, and wherein, the plurality of predetermined incident signals comprises: an alert message; and a command to disable communication to the at least one electronic control unit. Additional features and advantages of the invention will become apparent from the following drawings and description.

For a better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings in which like numerals designate corresponding sections or elements throughout.

With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how several forms of the invention may be embodied in practice. In the accompanying drawings:.

<FIG> illustrates a high level block diagram of a system <NUM> for monitoring intrusion anomalies in a vehicle environment, <FIG> illustrates a high level block diagram of a system <NUM> for monitoring intrusion anomalies, <FIG> illustrates a high level block diagram of a system <NUM> for monitoring intrusion anomalies, <FIG> illustrates a high level block diagram of a system <NUM> for monitoring intrusion anomalies, <FIG> illustrates a high level block diagram of a system <NUM> for monitoring intrusion anomalies and <FIG> illustrates a high level block diagram of respective portions of systems <NUM>, <NUM>, <NUM> and <NUM>. <FIG> are described together.

System <NUM> comprises: a plurality of ECUs <NUM>, each comprising a respective security monitor <NUM>; and an anomaly analyzer <NUM>. Each ECU <NUM> is illustrated as comprising the respective security monitor <NUM>, however this is not meant to be limiting in any way. In another embodiment, each security monitor <NUM> is provided external to the respective ECU <NUM> and is in communication with the respective ECU <NUM>. Anomaly analyzer <NUM> is in communication with security monitors <NUM>.

System <NUM> comprises: a plurality of ECUs <NUM>; a security monitor <NUM>; and an anomaly analyzer <NUM>. Security monitor <NUM> is in communication with ECUs <NUM> and anomaly analyzer <NUM> is in communication with security monitor <NUM>. System <NUM> comprises: a plurality of ECUs <NUM>, each comprising a respective security monitor <NUM>; a plurality of ECUs <NUM>; a security monitor <NUM>; and an anomaly analyzer <NUM>. Security monitor <NUM> is in communication with ECUs <NUM>. Anomaly analyzer <NUM> is in communication with security monitors <NUM> of ECUs <NUM> and security monitor <NUM>.

System <NUM> comprises: an Ethernet switch/hub <NUM>; a communication control unit <NUM>; a communication control unit <NUM>; a bus <NUM>; a plurality of ECUs <NUM>; a plurality of ECUs <NUM>; and a security monitor <NUM>. In one embodiment, Ethernet switch/hub <NUM> is either an Ethernet switch or an Ethernet hub. In another embodiment, communication control unit <NUM> comprises a smart antenna. In one embodiment, communication control unit <NUM> comprises a telematic control unit (TCU). In another embodiment, communication control unit <NUM> comprises a telematics box. In one embodiment, communication control unit <NUM> comprises a wireless data link, which may be implemented by equipment compatible with global system for mobile communication (GSM), evolution data optimized (EV-DO), wideband code division multiple access (W-CDMA), high speed packet access (HSPA), worldwide interoperability for microwave access (WIMAX), and/or long term evolution (LTE), without limitation.

In one embodiment, communication control unit <NUM> comprises a gateway. In another embodiment, communication control unit <NUM> comprises a domain controller unit (DCU). In one embodiment, bus <NUM> is a CAN bus. In one further embodiment, communication control unit <NUM> acts as a CAN gateway. Each of communication control unit <NUM>, communication control unit <NUM> and ECUs <NUM> is in communication with Ethernet switch/hub <NUM>. Bus <NUM> is in communication with communication control unit <NUM> and each of ECUs <NUM> is in communication with bus <NUM>. In one embodiment, security monitor <NUM> is in communication with Ethernet switch/hub <NUM> and/or communication control unit <NUM>. In one further embodiment, security monitor <NUM> is coupled to a respective port of Ethernet switch/hub <NUM>. In another embodiment (not shown), security monitor <NUM> is implemented within Ethernet switch/hub <NUM>, as illustrated in system <NUM>. Particularly, system <NUM> is in all respects similar to system <NUM>, with the exception that security monitor <NUM> is implemented within Ethernet switch/hub <NUM>. In another embodiment (not shown), security monitor <NUM> is implemented within communication control unit <NUM>. In another embodiment (not shown), security monitor <NUM> is implemented within communication control unit <NUM>. System <NUM> is illustrated in an embodiment where a single security monitor <NUM> is provided, however this is not meant to be limiting in any way. In another embodiment, a plurality of security monitors <NUM> are provided, each in communication with, and/or implemented within, Ethernet switch/hub <NUM>, communication control unit <NUM> and/or communication control unit <NUM>.

Systems <NUM>, <NUM>, <NUM> and <NUM> are illustrated and described in an embodiment where security monitors <NUM> and <NUM> are separated from anomaly analyzer <NUM>, however this is not meant to be limiting in any way. In another embodiment (not shown), anomaly analyzer <NUM> and one or more of security monitors <NUM> and/or <NUM> are implemented together as a single component, such as different code sections of a program.

In one embodiment, anomaly analyzer <NUM> is located within a first vehicle and is in communication with security monitors <NUM> and/or <NUM> of a second vehicle (not shown). In another embodiment, anomaly analyzer <NUM> is further in communication with an external anomaly monitor (not shown), optionally via a wireless Internet connection.

<FIG> illustrates a high level block diagram of a detailed embodiment of anomaly analyzer <NUM>. In the illustrated embodiment, anomaly analyzer <NUM> comprises: a communication node <NUM>; a vehicle signal functionality <NUM>; an anomaly functionality <NUM>; an adjustment functionality <NUM>; and a memory <NUM>. Although communication node <NUM>, vehicle signal functionality <NUM>, anomaly functionality <NUM> and adjustment functionality <NUM> are described herein as separate components, this is not meant to be limiting in any way. In one particular embodiment, communication node <NUM>, vehicle signal functionality <NUM>, anomaly functionality <NUM> and adjustment functionality <NUM> are each performed by a respective dedicated routine on a processor. Vehicle signal functionality <NUM> is in one embodiment in communication with Ethernet switch/hub <NUM> and/or communication control unit <NUM>. Anomaly analyzer <NUM> may be implemented in an FPGA, microcontroller, or processor with associated memory, the associated memory holding electronically readable instructions, which when implemented perform the tasks as described.

Anomaly analyzer <NUM> has stored therein an anomaly incident list. Optionally, the anomaly incident list is stored on memory <NUM>. The term 'list', as used herein, is not meant to limit the way the information of the anomaly incident list is stored and arranged in any way. The anomaly incident list comprises at least one anomaly incident, preferably a plurality of anomaly incidents. The term anomaly incident list, as used herein, is meant as information regarding predetermined attributes of the at least one anomaly incidents. In one embodiment, the anomaly incident list comprises a list of rules wherein anomaly analyzer <NUM> compares different attributes of received intrusion anomalies to predetermined rule sets, as will be described below.

In one embodiment, Ethernet switch/hub <NUM> is programmed to transmit towards security monitor <NUM> a copy of all messages traversing Ethernet switch/hub <NUM>, so that the messages are visible to security monitor <NUM> for sniffing.

In an embodiment where security monitor <NUM> is implemented in communication control unit <NUM>, and communication control unit <NUM> is implemented as a gateway, Ethernet switch/hub <NUM> optionally forwards all, or some, of the packets to gateway <NUM> for routing. In this case, security monitor <NUM> in one embodiment performs analysis on all of the packets, or certain packets that are defined for inspection. In another embodiment, Ethernet switch/hub <NUM> performs packet mirroring to copy the respective packets and send the copies to security monitor <NUM>.

In another embodiment, Ethernet switch/hub <NUM> enforces predefined security policies in the hardware. For example, Ternary Content Addressable Memory (TCAM) in the context of networking devices allows for efficient pattern matching of incoming packets to predefined patterns in the hardware. Each of these predefined patterns can have configurable actions attached to it. If a TCAM hit occurs, meaning the packet matches a predefined pattern, the defined actions are executed for the respective packet. In one embodiment, the defined actions comprise:.

Using these abilities, the Ethernet switch/hub <NUM> is configured in such an embodiment to forward defined packets for further analysis, or for reporting, to security monitor <NUM>. In another embodiment, as described above, security monitor <NUM> is implemented within Ethernet switch/hub <NUM>. In such an embodiment, when a TCAM hit occurs, an intrusion anomaly is identified by security monitor <NUM>, and security monitor <NUM> notifies anomaly analyzer <NUM> of the intrusion anomaly, as will be described below.

In one non-limiting example, a predetermined rate limit enforcement is configured to a packet using a QCI streams concept, as described in the IEEE P802.1Qci standard, the entire contents of which is incorporated herein by reference. In the event that the number of packets exceeds the predetermined rate limit, the security monitor <NUM> implemented in an internal CPU of Ethernet switch/hub <NUM> reads a defined register for its value to detect if a packet is dropped due to the rate limit violation. Then, the security monitor <NUM> in the internal CPU of the Ethernet switch/hub <NUM> notifies anomaly analyzer <NUM> about this intrusion anomaly.

In another non-limiting example, one of the TCAMs in Ethernet switch/hub <NUM> is configured to change the packet destination in the case of an unallowed packet. In one embodiment, the new packet destination is security monitor <NUM>. In another embodiment, as described above, wherein security monitor <NUM> is implemented within Ethernet switch/hub <NUM>, responsive to a TCAM hit, security monitor <NUM> detects this as an intrusion anomaly and outputs information regarding the intrusion anomaly to anomaly analyzer <NUM>, as will be described below. In one further embodiment, security monitor <NUM> changes the packet destination of the packet to anomaly analyzer <NUM>, thereby providing anomaly analyzer <NUM> with the entire packet.

In another non-limiting example, one of the TCAMs in Ethernet switch/hub <NUM> changes the VLAN ID to a unique ID which encodes information regarding the detected intrusion anomaly. In such an embodiment, anomaly analyzer <NUM>, and/or security monitor <NUM>, are members of the VLAN ID, and will receive the respective packet.

Systems <NUM>, <NUM>, <NUM>, <NUM> are each illustrated in an embodiment where anomaly analyzer <NUM> is in direct communication with security monitors <NUM> and/or security monitor <NUM>, however this is not meant to be limiting in any way. In another embodiment (not shown), one or more additional components are provided which perform the communication between the various security monitors <NUM>, or security monitor <NUM>, and anomaly analyzer <NUM>, as will be described below. Particularly, in one embodiment, a diagnostic communication manager (DCM) is provided, which performs communication between: security monitors <NUM> and/or security monitor <NUM>; and anomaly analyzer <NUM>. Systems <NUM>, <NUM>, <NUM>, <NUM> are each illustrated, and described herein, as comprising a plurality of ECUs, however this is not meant to be limiting in any way. In another embodiment (not shown), a single ECU <NUM>, <NUM>, <NUM> or <NUM> is provided. The operations of systems <NUM>, <NUM>, <NUM> and <NUM> are described together.

<FIG> illustrates a high level flow chart of a method for monitoring intrusion anomalies in a vehicle environment, in accordance with certain embodiments. The method of <FIG> is described herein in relation to systems <NUM>, <NUM>, <NUM> and <NUM> however this is not meant to be limiting in any way, and the method of <FIG> can be implemented by any suitable system, without exceeding the scope. In stage <NUM>, security monitors <NUM> and/or security monitor <NUM> detect intrusion anomalies associated with the respective ECUs <NUM>, <NUM>, <NUM> and <NUM>. The term 'intrusion anomaly', as used herein, is defined as an anomaly associated with an attempt by an attacker to intrude on any portion of the automotive communication network. This includes, but is not limited to: statistical anomalies in the data being transmitted over the network, e.g. a distributed denial of service (DDOS) attack; attempts to spoof a media access control (MAC) address of an ECU; subscription requests from an internet protocol (IP) address of a port; incorrect values in scalable service-oriented middleware over IP (SOME/IP) information; signals which deviate from a pre-defined model or rule; stack overflows; and return-oriented programming attacks.

In one embodiment, security monitors <NUM> and/or security monitor <NUM> monitors messages directed at the respective ECUs <NUM>, <NUM>, <NUM> and <NUM>. In the embodiment of system <NUM>, security monitor <NUM> optionally snoops, or actively blocks, messages addressed to the respective ECUs <NUM> and/or <NUM>, by monitoring activity on Ethernet switch/hub <NUM>. In another embodiment, security monitor <NUM> monitors messages directed at bus <NUM>. In another embodiment (not shown), one or more security monitors <NUM> and/or <NUM> monitor messages directed at communication control unit <NUM> and/or communication control unit <NUM> to determine intrusion anomalies directed thereat.

In one embodiment, at least one predetermined attribute of one or more messages is compared to one or more values of predetermined validation parameter to identify an intrusion anomaly. In one further embodiment, a machine learning algorithm is used to compare correlation of signals with a pre-defined model. In the event that the signals deviate from the pre-defined model, an intrusion anomaly is detected. In one embodiment, each received message is snooped and the source address and target address of the snooped message are compared to a predetermined list of acceptable addresses to determine validity, i.e. the predetermined attributes are the source address and the target address and/or port number. Particularly, in an Ethernet packet there is information regarding the source's and destination's media access control (MAC) and internet protocol (IP) address, and the respective port number. In one embodiment, the respective security monitor <NUM>, or <NUM>, compares these addresses with the predetermined list of acceptable source and destination addresses. In another embodiment, the respective security monitor <NUM>, or <NUM>, determines whether the source's IP and MAC addresses belong to the same component. In another embodiment, the respective security monitor <NUM>, or <NUM>, determines whether a source with the respective IP address and port number is authorized to send data to a destination with the respective IP address and port number. In the event that any of the above described addresses, or address relations, are invalid, i.e. the at least one predetermined attribute of the message does not meet the valid values of the predetermined validation parameter, the message is determined to be an anomalous message and an intrusion anomaly is detected.

In another embodiment, each received message is snooped and the packet of the snooped message is analyzed to determine any anomalies in the message. In one further embodiment, the message is analyzed to determine whether a value in the message is valid for the respective destination, i.e. the predetermined attribute of the message is the respective value and destination. For example, in a message targeting the steering wheel, a value for adjusting the steering wheel angle is only valid if it is within a predetermined steering wheel angle range. In the event that the value is outside of the predetermined steering wheel angle range, the message is determined to be an anomalous message and an intrusion anomaly is detected.

In another further embodiment, in a message which is composed of a plurality of signals with a particular relationship between them, the respective security monitor <NUM>, or <NUM>, determines whether the relationship is valid, i.e. the predetermined attribute of the message is the relationship between the values plurality of signals. For example, a message regarding wheel speed comprising four signals is received, the four signals being: signal a - front right wheel speed; signal b - front left wheel speed; signal c - back left wheel speed; signal d - back left wheel speed. In one non-limiting embodiment, in such an example the payload of the message packet is <NUM> bytes and each signal comprises <NUM> bytes of the packet. The respective security monitor <NUM>, or <NUM>, determines, without limitation: the difference between the value of signal a and the value of signal b; the difference between the value of signal b and the value of signal c; and optionally the differences between each two of signals a, b, c and d. The respective security monitor <NUM>, or <NUM>, compares the determined differences to one or more respective predetermined thresholds, i.e. the value of the predetermined validation parameter is the respective threshold. In the event that the determined difference, or differences, is greater than the respective threshold, or thresholds, the message is determined to be an anomalous message and an intrusion anomaly is detected.

In another embodiment, each received message is snooped and the packet of the snooped message is analyzed statistically to determine any anomalies in the message, i.e. the predetermined attribute is in relation to a plurality of received messages. In one further embodiment, the predetermined attribute is a timestamp of the message and is in relation to a plurality of previously received messages. For example, the respective security monitor <NUM>, or <NUM>, determines how many messages have been received, within a predetermined time interval. In the event that the number of received within the predetermined time interval, either in total or addressed to a particular ECU <NUM>, <NUM>, <NUM> or <NUM>, including the current message, is greater than a predetermined threshold, an intrusion anomaly is detected. Particularly, the value of the predetermined validation parameter is the respective threshold of the number of messages received within the predetermined time interval. As known to those skilled in the art, in case of a denial of service attack, the total number of messages for any time interval increases, and the respective security monitor <NUM>, or <NUM>, can detect such an attack.

In another further embodiment, the predetermined attribute is the difference between the value of a payload signal of a first message and the value of a corresponding payload signal of a second message. For example, in the embodiment of system <NUM>, a first message destined to bus <NUM> comprises a signal of the vehicle speed and a second message destined to a respective ECU <NUM> comprises a signal of the autonomous driving assistance system (ADAS). Security monitor <NUM> determines the difference between the value of the respective signal of the first message and the value of the respective signal of the second message. In the event that the difference is greater than a predetermined threshold, the messages are determined to be anomalous and an intrusion anomaly is detected.

In another embodiment, for periodic signals, i.e. commands which are sent to a particular system again and again for proper operation, an anomaly is detected when the periodicity is altered. Specifically, if the periodicity of received messages increases or decreases, by more than a predetermined threshold, an intrusion anomaly is detected.

In one embodiment, each security monitor <NUM> and/or <NUM> further determines the severity of any detected intrusion anomaly, in accordance with one or more predetermined severity rules. In one embodiment, <NUM> different levels of severity are assigned, however this is not meant to be limiting in any way. In another embodiment, the predetermined severity rules comprise, without limitation, one or more of: the difference between a command to a particular system and the current state of that system; the system which is the target of the anomalous message, i.e. anomalous messages targeting critical systems and safety systems will be assigned a higher severity rating; and, for a periodic signal, the degree by which the periodicity is disrupted.

Particularly, the difference between a command to a particular system and the current state of that system is measured in one embodiment by comparing the future state of the system after the command is executed to the current state of the system. For example, the speed which the vehicle will achieve after receiving a specific command is compared to the current speed of the vehicle. If the command has been detected as an intrusion anomaly, a large difference will increase the severity of the anomaly and a higher severity rating will be assigned. For periodic signals, i.e. commands which are sent to a particular system again and again for proper operation, an intrusion anomaly is detected in one embodiment when the periodicity is altered, as described above. Specifically, if the periodicity of received messages increases or decreases, by more than a predetermined threshold, an intrusion anomaly is detected. The distance of the periodicity distance from the predetermined threshold determines the severity. If the distance is large, the severity rating is higher. If the distance is smaller, the severity rating is lower.

In one embodiment, a higher value is assigned for a higher severity rating and a lower value is assigned for a lower severity rating, however this is not meant to be limiting in any way. Although the above has been described in relation to an embodiment where the severity is determined by security monitors <NUM> and/or <NUM>, this is not meant to be limiting in any way. In another embodiment, anomaly analyzer <NUM> determines the severity of the intrusion anomalies, in cooperation with security monitors <NUM> and/or <NUM>, or by itself.

In stage <NUM>, security monitors <NUM> and/or <NUM> output information regarding the detected intrusion anomalies of stage <NUM> to anomaly analyzer <NUM>. In one embodiment, the output information is transmitted using: a diagnostics over internet protocol (DoIP); a transmission control protocol (TCP); a unified diagnostic services (UDS) and/or a user datagram protocol (UDP).

In one embodiment, security monitors <NUM> and/or <NUM> generate diagnostic anomaly codes (DACs) to contain the information regarding the detected intrusion anomalies. The term DAC, as used herein, is meant as a code which indicates an anomaly which deviates from the proper configuration. As opposed to DTCs, DACs provide anomaly codes for complex anomalies, such as security flaws, safety flaws and hacking identification, as will be described further below. For example, if a DDOS attack is detected, such an attack would not constitute an anomaly associated with a standard DTC because each access attempt is proper. Only when detecting an accumulation of access attempts is the DDOS attack detected by security monitors <NUM> and/or <NUM>, and an appropriate DAC is generated. Additionally, DTCs are typically limited in size, and can usually contain only <NUM> bytes of data, whereas a DAC can be larger and contain more data, as described below.

In one embodiment, each DAC is indicative of a respective intrusion anomaly. In another embodiment, the same DAC is generated for each intrusion anomaly and the payload of the DAC carries information indicative of the respective intrusion anomaly detected. In one embodiment, security monitors <NUM> and/or <NUM> output the relevant information to a diagnostic event manager (DEM), and the DEM (not shown) generates the respective DACs. In one embodiment, the output information comprises: the type of the intrusion anomaly; the severity of the intrusion anomaly; and any other relevant information.

In one embodiment, security monitors <NUM> and/or <NUM> store the information regarding the detected intrusion anomalies on a respective memory (not shown). In one further embodiment, anomaly analyzer <NUM> periodically requests the information regarding all detected intrusion anomalies. In another further embodiment, security monitors <NUM> and/or <NUM> periodically transmit the stored information to anomaly analyzer <NUM> without receiving a request therefrom, either at predetermined time intervals or responsive to predetermined rules. In one further embodiment, the predetermined rules comprise: transmitting information once at least a predetermined number of intrusion anomalies have been detected; transmitting information once at least a predetermined number of intrusion anomalies exhibiting a severity of a predetermined value have been detected; and/or transmitting information once at least a predetermined number of intrusion anomalies associated with at least a predetermined number, or types, of ECUs <NUM>, <NUM>, <NUM> and/or <NUM>. In another embodiment, the information regarding the detected intrusion anomalies are transmitted along with any DTCs associated with ECUs <NUM>, <NUM>, <NUM> and/or <NUM>. In another embodiment, the information regarding each detected intrusion anomaly is transmitted to anomaly analyzer upon detection of the respective intrusion anomaly.

In one non-limiting embodiment, the output message comprising the information of each respective intrusion anomaly comprises the following fields: message length, optionally with a size of <NUM> byte; a message identifier, optionally with a size of <NUM> bytes; an anomaly type, optionally with a size of <NUM> byte; an anomaly subtype, optionally with a size of <NUM> byte; the determined severity of the anomaly, optionally with a size of <NUM> byte; a first value field, optionally with a size of <NUM> byte; and an optional second value field, optionally with a size of <NUM> bytes.

For example, for an anomaly indicating that a value of a steering wheel angle is greater than the maximum value of the predetermined valid range of angles by <NUM> degrees, and the severity of the anomaly is <NUM>, the message is optionally as follows:.

In such an example, the second value field is not utilized. In another example, for an anomaly indicating that the difference between a value of a signal 'a' and a value of a signal 'b' is greater than a predetermined threshold, with a severity of <NUM>, the message is optionally as follows:.

In such an example, the second value field is utilized to transmit the actual signal values, along with the actual deviation value. In the event that the same message additionally comprises signals 'c' and 'd', as described above, the message is optionally as follows:.

Thus, <NUM> DAC messages are sent for the same message.

In another example, where an invalid MAC address is detected, as described above, the message is optionally as follows:.

The MAC address is <NUM> bytes long, and the first value field is only <NUM> bytes long, so the second value field is also used for the MAC address. As described above, a possible invalidity is when the source exhibiting the respective MAC address isn't authorized to send messages to the respective destination exhibiting the respective IP address. Thus, the anomaly subtype is a mismatch between MAC and IP addresses.

In another example, for an anomaly of a mismatch of values between two messages, as described above, the message is optionally as follows:.

Although the above examples illustrate an embodiment where the messages exhibit a length of <NUM> bytes, this is not meant to be limiting in any way, and messages with a variety of lengths can be generated. Although the above examples illustrate an embodiment where the relevant information of an anomaly is transmitted in a single message, this is not meant to be limiting in any way, and a plurality of messages can be generated for each detected intrusion anomaly.

In stage <NUM>, anomaly analyzer <NUM> accumulates the received output information of stage <NUM> regarding the detected intrusion anomalies. Optionally, the received information is stored on memory <NUM>. In stage <NUM>, anomaly analyzer <NUM> receives at least one vehicle status signal. In one embodiment, the at least one vehicle status signal is received by vehicle signal functionality <NUM>. In another embodiment, the at least one vehicle status signal is received from Ethernet switch/hub <NUM> and/or communication control unit <NUM>. The term 'vehicle status signal', as used herein, is defined as a signal which represents the current state of a particular system of the vehicle and/or a signal which represents conditions external to the vehicle. Specifically, in one embodiment, the at least one vehicle status signal comprises, without limitation: the speed of the vehicle; the angle of the steering wheel in relation to an initial position; which gear is the vehicle in; the position of the brakes; the status of the engine of the vehicle, e.g. the revolutions per minute (RPM); and/or the position of a gyro of the vehicle in relation to an initial position. In one further embodiment, the at least one vehicle status signal further comprises environment conditions, e.g. predetermined attributes of the weather, the amount of lighting outside of the vehicle and/or the type, or condition, of the road on which the vehicle is driving. Such signals are received from dedicated sensors of the vehicles and/or are received from an external source, such as the Internet. In another further embodiment, the at least one vehicle status signal further comprises the status of surrounding vehicles, e.g. distance from nearest vehicles, speed of surrounding vehicles and/or angular momentum of surrounding vehicles. Such signals are received from a radar system and/or via vehicle to vehicle (V2V) communication.

In one further embodiment, the at least one vehicle status signal is in relation to a respective predetermined threshold. In one example, the speed of the vehicle is compared to a predetermined speed threshold and it is determined whether the vehicle speed is greater than the predetermined speed threshold or less than the predetermined speed threshold. In another example, the angle of the steering wheel in relation to the initial position is compared to a predetermined angle threshold and it is determined whether the steering wheel angle is greater than the predetermined angle threshold or less than the predetermined angle threshold.

In another example, the current gear of the vehicle is compared to a predetermined gear threshold and it is determined whether the current gear of the vehicle is greater than the predetermined gear threshold or less than the predetermined gear threshold. In another example, the position of the brakes is compared to a predetermined brake threshold and it is determined whether the current brake position is greater than the predetermined brake threshold or less than the predetermined brake threshold. In one non-limiting embodiment, the predetermined brake threshold is given as: <MAT> where MAX is the position of the brakes when they are pressed down all the way and MIN is the position of the brakes when they are not pressed down.

In another example, the RPM of the engine is compared to a predetermined RPM threshold and it is determined whether the current RPM value is greater than the predetermined RPM threshold or less than the predetermined RPM threshold. In another example, the position of a gyro, in relation to an initial position is compared to a predetermined gyro threshold and it is determined whether the current gyro position value is greater than the predetermined gyro threshold or less than the predetermined gyro threshold.

In one embodiment, the comparison to the predetermined thresholds is performed by vehicle signal functionality <NUM>. In another embodiment, the comparison is performed by other systems in the vehicle and the relative values of the vehicle status signals, i.e. the relationship of each signal to the respective predetermined value, are received by vehicle signal functionality <NUM>. For example, a dedicated system, external to anomaly analyzer <NUM>, determines whether the vehicle is travelling at a high speed or a low speed and vehicle signal functionality <NUM> receives a respective signal indicating whether the speed of the vehicle is high or low.

In optional stage <NUM>, anomaly analyzer <NUM> determines a grade for each of the received at least one vehicle status signal, further responsive to one or more predetermined grading rules. Optionally, the grades are determined by vehicle signal functionality <NUM>. In one non-limiting embodiment, a first grade value is assigned when the respective vehicle status signal value is equal to zero. In such an embodiment, a second grade value is assigned when the respective vehicle status signal value is greater than zero, but less than the respective predetermined threshold. For example, if the speed of the vehicle is greater than zero, but less than the predetermined speed threshold, the second grade value is assigned to the vehicle speed. Additionally, a third grade value is assigned when the respective vehicle status signal value is greater than, or equal to, the respective predetermined threshold.

In optional stage <NUM>, a total grade of the current vehicle status is determined by anomaly analyzer, optionally by vehicle signal functionality <NUM>, responsive to the received at least one vehicle status signal of stage <NUM> and a predetermined grading rule. In one embodiment, the predetermined grading rule is given as: <MAT> where TG is the total grade of the current vehicle status, speed_g is the vehicle speed grade of optional stage <NUM>, angle_g is the steering wheel angle grade, gear_g is the gear grade, brake_g is the brake grade, engine_g is the grade of the engine status and gyro_g is the grade of the status of the gyro, as described above, f is a function preferably defined by the original equipment manufacturer (OEM). In one non-limiting further embodiment, the total grade is defined as: <MAT> where w1 is a predetermined weight for the grade of the vehicle speed of optional stage <NUM>, w2 is a predetermined weight for the grade of the steering wheel angle of optional stage <NUM>, w3 is a predetermined weight for the grade of the gear status of optional stage <NUM>, w4 is a predetermined weight for the grade of the brake status of optional stage <NUM>, w5 is a predetermined weight for the grade of the engine status of optional stage <NUM> and w6 is a predetermined weight for the grade of the gyro status of optional stage <NUM>.

As described above, in one embodiment the at least one vehicle status signal further comprises environment conditions and/or the status of surrounding vehicles. In such an embodiment, the function of EQ. <NUM> further includes these signals, which are optionally graded, as described above in relation to optional stage <NUM>. Thus, a more accurate indication of the level of danger the vehicle is in is achieved.

Although optional stages <NUM> - <NUM> have been described in relation to an embodiment where grades are assigned to the received vehicle status signals, this is not meant to be limiting in any way. In another embodiment, an alternate method of utilizing the information of the received vehicle status signals can be used, without assigning actual grade values.

In optional stage <NUM>, anomaly analyzer <NUM>, optionally by anomaly functionality <NUM> determines the duration of each anomaly, i.e. the number of anomalous messages within a predetermined time period for a respective system.

In stage <NUM>, anomaly analyzer <NUM> compares, responsive to the received at least one vehicle status signal of stage <NUM>, the accumulated output information regarding the detected intrusion anomalies of stage <NUM> with the anomaly incident list. As described above, in one embodiment the anomaly incident list is stored on memory <NUM>. Optionally, the comparison is performed by anomaly functionality <NUM>.

The comparison is not meant to be limited to a direct item by item comparison, and identification of a range of values, or a translation of values may be utilized without exceeding the scope, and is in accordance with one or more predetermined anomaly incident list rules. In one particular embodiment, each anomaly incident in the anomaly incident list comprises a set of predetermined parameters, such that when predetermined attributes of the detected intrusion anomaly, or anomalies, meet the values of the respective parameters an anomaly incident is detected. In one embodiment, the predetermined rule sets comprise a plurality of predetermined parameters, including, without limitation: the number of detected anomalies received; the severity of the detected anomalies; the duration of the detected anomalies, as described above; and/or the number of ECUs targeted by the detected anomalies. In one embodiment, the severity and/or duration are determined in relation to the anomaly with the highest severity and longest duration, respectively. In another embodiment, the severity and/or duration are determined in relation to a predetermined number, or percentage, of the detected anomalies.

For example, anomaly analyzer <NUM> checks that there are no more than <NUM> anomalies with a severity grade greater than <NUM>, etc. In one embodiment, each rule set on the anomaly incident list has an associated flag indicating whether a warning indicator is to be sent and/ or communication is to disabled. In an alternate embodiment, a plurality of anomaly incident lists are provided, each with an associated action, or actions. In another embodiment, the associated action is responsive to the particular type, or types, of anomaly detected.

Additionally, as described above, the comparison to the anomaly incident list is further performed in relation to the received at least one vehicle status signal of stage <NUM>. Particularly, in one embodiment, the comparison is performed in relation to the determined total grade TG of the vehicle status, described above in relation to EQ. In one further embodiment, the parameter values of the predetermined events of the anomaly incident list are determined in accordance with the value of the total grade.

A non-limiting example of a plurality of anomaly incidents in an anomaly incident list is given in Table <NUM>:
<IMG>.

TG1 and TG2 are different total grades TG, where TG2 is greater than TG1. t1 is a predetermined duration threshold value. The anomaly incidents in this example are defined by different rulesets, in accordance with the respective grade TG. If the received detected anomalies meet the parameter values of a ruleset, it is determined that an anomaly incident has occurred. As shown in table <NUM>, for different grades TG there are different rule sets. For example, as illustrated above, if there is a greater total grade TG, a higher number of types and/or anomalies is required to identify an anomaly incident. This is because a higher total grade TG indicates a more dangerous state of the vehicle and therefore the rule sets are arranged so as to reduce the number of false positives. However, this is not meant to be limiting in any way and different rule sets are associated with different respective total grades TG in accordance with any predetermined association rules. For example, for anomalies with a higher severity, less anomalies are required for a higher total grade TG, so as to rapidly respond to anomalies that are clear and could rapidly cause a dangerous situation in the vehicle, as described in ruleset3.

In one example, on receiving a total of <NUM> messages:.

and for a total vehicle grade TG1, the intrusion anomalies meet the respective parameters of the anomaly incident list, since they meet the conditions of ruleset1, i.e. there are <NUM> anomalies with different types and the severity is greater than <NUM>.

However, the following anomalies will not meet the respective parameters of the anomaly incident list, i.e. they won't meet the conditions of any of the rule sets:.

Although there are <NUM> anomalies with a severity greater than <NUM>, the anomalies have the same type, thus not meeting the conditions of ruleset1, ruleset2, or ruleset3.

Although the above has been described in relation to the type of the anomalies, this is not meant to be limiting in any way. In another embodiment, the rule sets of the anomaly incident list further comprise conditions regarding the subtypes of the anomalies, in addition to the conditions regarding the type of the anomalies.

In stage <NUM>, responsive to a predetermined outcome of the comparison of stage <NUM>, anomaly analyzer <NUM> outputs at least one predetermined incident signal. The predetermined incident signal comprises an indication that an anomaly incident has been detected. In one embodiment, responsive to a first outcome of the comparison of stage <NUM> the predetermined incident signal is output and responsive to a second outcome of the comparison of stage <NUM> the predetermined incident signal is not output. The first outcome is a determination that an anomaly incident has been detected and the second outcome is a determination than an anomaly incident has not been detected. In the embodiment described above where the comparison determines whether predetermined attribute/s of the respective intrusion anomalies meet the values of predetermined parameters of an anomaly incident in the anomaly incident list, the first outcome of the comparison is a determination that the predetermined attribute/s of the respective intrusion anomalies does meet the values of predetermined parameters of an anomaly incident and the second outcome of the comparison is a determination that the predetermined attribute/s of the respective intrusion anomalies does not meet the values of predetermined parameters of an anomaly incident.

In one embodiment, the predetermined incident signal is selected from a plurality of predetermined incident signals. The plurality of predetermined incident signals comprises: an alert message; and a command to disable communication to ECUs <NUM>, <NUM>, <NUM> and/or <NUM> for a predetermined time interval. In one embodiment, disabling communication comprises disabling a communication function of communication control unit <NUM> or communication control unit <NUM>. In one further embodiment, the alert message is transmitted to a server. In another further embodiment, the alert message is displayed to a driver of the vehicle. Optionally, the displayed alert message can prompt the driver to pull over and stop the car. Further optionally, in an autonomous car, the alert message can cause the car to pull over and stop. In one embodiment, the command to disable a communication function of communication control unit <NUM> or communication control unit <NUM> is performed by utilizing a Unified Diagnostic Services (UDS) protocol message as defined in ISO <NUM>-<NUM>. In this particular embodiment, anomaly analyzer <NUM> uses a service 0x31 request over UDS with communication control unit <NUM> or communication control unit <NUM> as a target of the message to modify the state of communication control unit <NUM> or communication control unit <NUM> so as to block any incoming request.

In one embodiment, the predetermined incident signal is selected from the plurality of incident signals responsive to the respective detected one of the plurality of anomaly incidents, i.e. for each detected anomaly incident a different predetermined incident signal is selected. In another embodiment, an alert message is always generated and the command to disable a communication function of communication control unit <NUM> or communication control unit <NUM> is generated only responsive to: the detection of certain predetermined anomaly incidents; and/or the received at least one vehicle signal meeting one or more predetermined parameters, such as a predetermined vehicle grade.

In optional stage <NUM>, responsive to an detected anomaly incident of stage <NUM>, anomaly analyzer <NUM>, optionally adjustment functionality <NUM> thereof, generates an adjustment signal which is output to one or more of: ECUs <NUM>, <NUM>, <NUM> or <NUM>; security monitors <NUM> and/or <NUM>; or communication control unit <NUM> and/or <NUM>. Responsive to the generated adjustment signal, future anomaly identification is performed in accordance with an adjusted set of validation values. Particularly, as described above, an anomaly is detected responsive to a predetermined set of anomaly rules. If an anomaly incident has been detected, a more stringent set of anomaly rules are utilized, because the security risk has increased. For example, if a denial of service attack has been detected, the generated adjustment signal causes security monitors <NUM> and/or <NUM> to adjust the respective validation values, such that the number of messages within the predetermined time interval which triggers detection of the anomaly is reduced.

Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination. In particular, the invention has been described with an identification of each powered device by a class, however this is not meant to be limiting in any way. In an alternative embodiment, all powered device are treated equally, and thus the identification of class with its associated power requirements is not required.

Unless otherwise defined, all technical and scientific terms used herein have the same meanings as are commonly understood by one of ordinary skill in the art to which this invention belongs. Although methods similar or equivalent to those described herein can be used in the practice or testing of the present invention, suitable methods are described herein.

Claim 1:
A system (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) for monitoring intrusion anomalies on any portion of the communication network of an automotive vehicle, the system comprising:
at least one electronic control unit (<NUM>, <NUM>, <NUM>, <NUM>); and
at least one security monitor (<NUM>, <NUM>) arranged to detect intrusion anomalies associated with said at least one electronic control unit and to output information regarding said detected intrusion anomalies,
CHARACTERIZED BY:
an anomaly analyzer (<NUM>) arranged to:
accumulate said output information regarding said detected intrusion anomalies;
receive at least one vehicle status signal;
compare, responsive to said received at least one vehicle status signal, the accumulated output information regarding said detected intrusion anomalies with an anomaly incident list, the anomaly incident list comprising information regarding predetermined attributes of at least one anomaly incident; and
responsive to a predetermined outcome of said comparison, output a predetermined incident signal.