Secure controller operation and malware prevention

• US 10,176,326 B2
• Filed: 06/19/2018
• Issued: 01/08/2019
• Est. Priority Date: 04/06/2016
• Status: Active Grant

• Current Assignee: Karamba Security Ltd.
• Original Assignee: Karamba Security
• Inventors: David, Tal Efraim Ben, Harel, Assaf, Dotan, Amiram, Barzilai, David
• Primary Examiner(s): Tran, Tri M
• Application Number:
  US16/011,906
• Publication Number:
  US 20180307840A1
• Time in Patent Office: 203 Days
• CPC Class Codes: G06F 21/52 during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
• CPC Class Codes: G06F 21/554 involving event detection and direct action
• CPC Class Codes: G06F 21/566 Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
• CPC Class Codes: G06F 21/568 eliminating virus, restoring damaged files
• CPC Class Codes: G06F 21/577 Assessing vulnerabilities and evaluating computer system security
• CPC Class Codes: G06F 21/606 by securing the transmission between two devices or processes
• CPC Class Codes: G06F 21/64 Protecting data integrity, e.g. using checksums, certificates or signatures
• CPC Class Codes: H04L 2209/84 Vehicles
• CPC Class Codes: H04L 63/101 Access control lists [ACL]
• CPC Class Codes: H04L 63/1441 Countermeasures against malicious traffic countermeasures against attacks on cryptographic mechanisms H04L9/002
• CPC Class Codes: H04L 63/145 the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227
• 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
• CPC Class Codes: H04W 12/128 Anti-malware arrangements, e.g. protection against SMS fraud or mobile malware

Abstract

In one implementation, a method for providing security on an externally connected controller includes launching, by the controller, a kernel level security layer that includes a whitelist of permitted processes on the controller, the whitelist being part of a custom security policy for the controller; receiving, at the security layer, a request to run a particular process; determining, by the security layer, a signature for the particular process; identifying, by the security layer, a verified signature for the process from the whitelist; determining, by the security layer, whether the particular process is permitted to be run on the controller based on a comparison of the determined signature with the verified signature from the whitelist; and blocking, by the security layer, the particular process from running on the automotive controller based on the determined signature not matching the verified signature for the process.

Claims

1. A system for providing security on an externally connected automotive electronic control unit (ECU), the system comprising:

a processor and computer-readable memory comprising instructions that, when processed by the processor, cause the processor to perform operations comprising;

launching, by the automotive ECU, a kernel level security layer that includes a whitelist of permitted processes on the automotive ECU, the whitelist being part of a custom security policy for the automotive ECU;

receiving, at the security layer, a request to run a particular process;

determining, by the security layer, a signature for the particular process;

identifying, by the security layer, a verified signature for the process from the whitelist;

determining, by the security layer, whether the particular process is permitted to be run on the automotive ECU based on a comparison of the determined signature with the verified signature from the whitelist;

blocking, by the security layer, the particular process from running on the automotive controller automotive ECU based on the determined signature not matching the verified signature for the process;

identifying, by the security layer, a network packet to be transmitted or received as part of an identified network process on the automotive ECU;

determining, by the security layer, an IP address and a port for the network packet;

identifying, by the security layer, one or more verified IP addresses and one or more verified ports for the identified network process from a network and port whitelist; and

determining, by the security layer, whether the network packet is permitted to be transmitted or received through the particular process based on a comparison of (i) the determined IP address and port with (ii) the verified IP address and port for the identified network process from the network and port whitelist.

2. The system of claim 1, wherein the whitelist was generated for the automotive ECU based on static analysis of an operating system for the automotive ECU.

3. The system of claim 1, the operations further comprising:

reporting, by the automotive ECU and to a server system, information that identifies the particular process as being blocked, wherein the information is reported to the server system without the particular process being executed by the automotive ECU and without prior transmission with the server system regarding the particular process.

4. The system of claim 1, wherein launching the security layer comprises:

registering, by the security layer, one or more hooks for one or more kernel level processes on the automotive ECU, the hooks causing calls to the one or more kernel level processes to be forwarded to the security layer with (i) process information identifying a kernel level process being called and (ii) a pointer to the called process,

wherein;

the request to run the particular process is received through the one or more hooks,

the signature for the particular process is determined using a particular pointer for the particular process, and

the verified signature is identified using a particular process information for the particular process.

5. The system of claim 1, the operations further comprising:

invoking, by the security layer, a stack inspection operation, the stack inspection operation comprising;

obtaining, by the security layer, a snapshot of a software stack for the automotive ECU;

accessing, by the security layer, a process map from the custom security policy for the automotive ECU, the process map identifying permitted sequential process calls on the automotive ECU;

determining, by the security layer, whether a current sequence of process calls in the software stack is permitted under the custom security policy based on a comparison of the snapshot with the process map; and

blocking, by the security layer, operation of one or more processes on the automotive ECU in response to determining that the current sequence of process calls is not permitted.

6. The system of claim 5, wherein:

the stack inspection operation is invoked in response to the request to run the particular process, and

the one or more processes that are blocked comprise the particular process.

7. The system of claim 5, wherein the stack inspection operation is invoked in response to a non-maskable interrupt being triggered on the automotive ECU.

8. The system of claim 1, the operations further comprising:

blocking, by the security layer, the network packet from being transmitted or received by the automotive ECU based on the determined IP address or port not matching the verified IP address and port.

9. The system of claim 8, wherein the network and port whitelist is part of the custom security policy and was generated for the automotive ECU based on static analysis of an operating system for the automotive ECU.

10. The system of claim 1, the operations further comprising:

running, by the security layer, one or more anti-tampering agents that check operation of the security layer; and

providing, by the one or more anti-tampering agents, an alert in response to determining that one or more portions of the security layer are not operating according to one or more parameters.

11. A method for providing security on an externally connected automotive ECU, the method comprising:

launching, by the automotive ECU, a kernel level security layer that includes a whitelist of permitted processes on the automotive ECU, the whitelist being part of a custom security policy for the automotive ECU, wherein the automotive ECU comprises an automotive electronic control unit (ECU);

receiving, at the security layer, a request to run a particular process;

determining, by the security layer, a signature for the particular process;

identifying, by the security layer, a verified signature for the process from the whitelist;

determining, by the security layer, whether the particular process is permitted to be run on the controller automotive ECU based on a comparison of the determined signature with the verified signature from the whitelist;

blocking, by the security layer, the particular process from running on the automotive ECU based on the determined signature not matching the verified signature for the process;

identifying, by the security layer, a network packet to be transmitted or received as part of an identified network process on the controller automotive ECU;

determining, by the security layer, an IP address and a port for the network packet;

identifying, by the security layer, one or more verified IP addresses and one or more verified ports for the identified network process from a network and port whitelist; and

determining, by the security layer, whether the network packet is permitted to be transmitted or received through the particular process based on a comparison of (i) the determined IP address and port with (ii) the verified IP address and port for the identified network process from the network and port whitelist.

12. The method of claim 11, wherein the whitelist was generated for the automotive ECU based on static analysis of an operating system for the automotive ECU.

13. The method of claim 11, further comprising:

reporting, by the automotive ECU and to a server system, information that identifies the particular process as being blocked, wherein the information is reported to the server system without the particular process being executed by the automotive ECU and without prior transmission with the server system regarding the particular process.

14. The method of claim 11, wherein launching the security layer comprises:

registering, by the security layer, one or more hooks for one or more kernel level processes on the controller automotive ECU, the hooks causing calls to the one or more kernel level processes to be forwarded to the security layer with (i) process information identifying a kernel level process being called and (ii) a pointer to the called process,

wherein;

the request to run the particular process is received through the one or more hooks,

the signature for the particular process is determined using a particular pointer for the particular process, and

the verified signature is identified using a particular process information for the particular process.

15. The method of claim 11, further comprising:

invoking, by the security layer, a stack inspection operation, the stack inspection operation comprising;

obtaining, by the security layer, a snapshot of a software stack for the automotive ECU;

accessing, by the security layer, a process map from the custom security policy for the automotive ECU, the process map identifying permitted sequential process calls on the automotive ECU;

determining, by the security layer, whether a current sequence of process calls in the software stack is permitted under the custom security policy based on a comparison of the snapshot with the process map; and

blocking, by the security layer, operation of one or more processes on the automotive ECU in response to determining that the current sequence of process calls is not permitted.

16. The method of claim 15, wherein:

the stack inspection operation is invoked in response to the request to run the particular process, and

the one or more processes that are blocked comprise the particular process.

17. The method of claim 15, wherein the stack inspection operation is invoked in response to a non-maskable interrupt being triggered on the automotive ECU.

18. The method of claim 11, automotive ECU, the method further comprising:

blocking, by the security layer, the network packet from being transmitted or received by the automotive ECU based on the determined IP address or port not matching the verified IP address and port.

19. The method of claim 18, wherein the network and port whitelist is part of the custom security policy and was generated for the automotive ECU based on static analysis of an operating system for the automotive ECU.

20. The method of claim 11, further comprising:

running, by the security layer, one or more anti-tampering agents that check operation of the security layer; and

providing, by the one or more anti-tampering agents, an alert in response to determining that one or more portions of the security layer are not operating according to one or more parameters.