Secure controller operation and malware prevention

• US 10,380,344 B1
• Filed: 11/30/2018
• Issued: 08/13/2019
• Est. Priority Date: 04/06/2016
• Status: Active Grant

• Current Assignee: Karamba Security Ltd.
• Original Assignee: Karamba Security Ltd.
• Inventors: David, Tal Efraim Ben, Harel, Assaf, Dotan, Amiram, Barzilai, David
• Primary Examiner(s): Tran, Tri M
• Application Number:
  US16/205,725
• Time in Patent Office: 256 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 non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for deploying embedded runtime whitelist policies in an ECU (electronic control unit) in a vehicle, comprising:

maintaining, as embedded software within the ECU in the vehicle, a plurality of whitelist polices for runtime functionality of the ECU;

wherein a first of the plurality of whitelist policies defines permitted runnable binaries for ECU software installed on the ECU;

wherein a second of the plurality of whitelist policies defines permitted function sequences in a memory of the ECU; and

wherein the first or second of the plurality of whitelist policies includes one or more signatures corresponding to one or more verified process calls;

invoking, by at least one of the plurality of whitelist policies, a stack inspection operation;

detecting, based on the invoking, a requested operation to be performed by the ECU as part of an identified runtime process call;

identifying a process identifier associated with the identified runtime process call;

determining a verified signature from among the one or more signatures based on the process identifier;

determining that the requested operation violates at least one of the first or second of the plurality of whitelist polices, wherein the determining is based on comparing a signature (i) associated with the identified runtime process call and (ii) based on a pointer to a location in the memory with the verified signature; and

blocking, based on the determination, the requested operation from being performed by the ECU.

2. The non-transitory computer readable medium of claim 1, wherein the plurality of whitelist policies are based on factory settings of the ECU software.

3. The non-transitory computer readable medium of claim 1, wherein the plurality of whitelist policies are based on a static analysis of the ECU software.

4. The non-transitory computer readable medium of claim 1, wherein the permitted runnable binaries are defined by unique signatures associated with each runnable binary.

5. The non-transitory computer readable medium of claim 1, wherein the plurality of whitelist polices are developed in a build environment associated with the embedded software.

6. The non-transitory computer readable medium of claim 1, wherein the plurality of whitelist polices further comprise one or more network firewall policies.

7. The non-transitory computer readable medium of claim 1, wherein the operations further comprise generating an alert identifying the requested operation.

8. The non-transitory computer readable medium of claim 7, wherein the alert identifies a trail of an attack associated with the requested operation.

9. The non-transitory computer readable medium of claim 7, wherein the alert identifies a source of the requested operation.

10. A computer-implemented method for deploying embedded runtime whitelist policies in an ECU (electronic control unit) in a vehicle, the method comprising:

maintaining, as embedded software within the ECU in the vehicle, a plurality of whitelist polices for runtime functionality of the ECU;

wherein a first of the plurality of whitelist policies defines permitted runnable binaries for ECU software installed on the ECU;

wherein a second of the plurality of whitelist policies defines permitted function sequences in a memory of the ECU; and

wherein the first or second of the plurality of whitelist policies includes one or more signatures corresponding to one or more verified process calls;

invoking, by at least one of the plurality of whitelist polices, a stack inspection operation;

detecting, based on the invoking, a requested operation to be performed by the ECU as part of an identified runtime process call;

identifying a process identifier associated with the identified runtime process call;

determining a verified signature from among the one or more signatures based on the process identifier;

determining that the requested operation violates at least one of the first or second of the plurality of whitelist polices, wherein the determining is based on comparing a signature (i) associated with the identified runtime process call and (ii) based on a pointer to a location in the memory with the verified signature; and

blocking, based on the determination, the requested operation from being performed by the ECU.

11. The computer-implemented method of claim 10, wherein the plurality of whitelist policies are based on factory settings of the ECU software.

12. The computer-implemented method of claim 10, wherein the plurality of whitelist policies are based on a static analysis of the ECU software.

13. The computer-implemented method of claim 10, wherein the permitted runnable binaries are defined by unique signatures associated with each runnable binary.

14. The computer-implemented method of claim 10, wherein the plurality of whitelist polices are developed in a build environment associated with the embedded software.

15. The computer-implemented method of claim 10, wherein the plurality of whitelist polices further comprise one or more network firewall policies.

16. The computer-implemented method of claim 10, further comprising generating an alert identifying the requested operation.

17. The computer-implemented method of claim 16, wherein the alert identifies a trail of an attack associated with the requested operation.

18. The computer-implemented method of claim 16, wherein the alert identifies a source of the requested operation.