US20210360009A1 - Centralized controller management and anomaly detection - Google Patents

Abstract

In one implementation, a method for providing security on externally connected controllers includes receiving, at a server system, operation information for a plurality of instances of a controller, the plurality of instances being installed across a plurality of devices; statistically analyzing, by the server system, the operation information; identifying, by the server system, one or more anomalous controller behaviors based on the statistical analysis; and providing, by the server system, information regarding the one or more anomalous controller behaviors on the controller as potential security threats.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• This application is a continuation of PCT Application No. PCT/IB2017/051967 filed Apr. 5, 2017, which claims priority to U.S. Application Ser. No. 62/319,178, filed on Apr. 6, 2016, and U.S. Application Ser. No. 62/346,895, filed Jun. 7, 2016, the disclosures of which are incorporated herein by reference.
TECHNICAL FIELD
• This specification generally relates to security for computer-based controllers, such as controllers for Internet of Things (IoT) devices.
BACKGROUND
• More devices are becoming “smarter” with hardware and software that permit them to communicate via the internet, such as through cellular wireless networks, Wi-Fi, and Bluetooth. These internet-connected devices are often identified as being part of the “Internet of Things” (IoT), which is a term that broadly encompasses internet-connected devices configured to transmit and receive information related to their operation, such as status information. For example, many consumer products are now IoT devices with internet-connected features, such as home automation devices (e.g., wirelessly controllable light switches), appliances (e.g., smart refrigerators able to transmit images of the fridge's contents), and automobiles (e.g., internet-connected components, such as infotainment and navigation devices). For instance, modern vehicles can have over 100 controllers, or Electronic Control Units (ECUs), that are responsible for running most of the car's functions, such as the steering wheel, engine, braking system, airbags, and navigation systems.
• Like any other externally connected computers, IoT devices (e.g., ECUs in connected cars) are vulnerable to cyber attack and have become targets for hackers. For example, controllers on several makes and models of cars, such as the JEEP CHEROKEE, TOYOTA PRIUS, TESLA MODEL S, and NISSAN LEAF, have been successfully targeted and exploited by white hat hackers. Those hackers were able to compromise the vehicles and take command of nearly all of the control aspects, ranging from turning on the radio and windshield wipers to killing the engine while the car drove on the freeway. These exploits caused some of these car manufacturers to issue a recall on affected vehicles.
• Cyber attacks come in many forms and flavors, but they generally share the same basic concepts: find a preexisting security bug (vulnerability) in the system's software, exploit it, and run malware. A common security bugs is neglecting to verify the size of input buffers, which hackers can exploit by passing long buffers that get out of the boundaries allocated for that buffer on the software stack. By getting out of the buffer boundaries, hackers may be able to access and change the pointer structure that controls the functional flow of code, which hackers can use to direct the controller to execute malware code. Although malware code can vary (e.g., keylogger, ransomware, e-mail spam), the exploitation mechanism is often similar—find a security bug, research and learn how to exploit it in order to gain control, and use the control to run the malware code.
SUMMARY
• This document generally describes a technological solution that hardens externally connected controllers (e.g., ECUs) within an IoT device (e.g., connected automobile) against hackers. Customized security policies for controllers can be automatically generated and added to controllers with security layers without having to modify the underlying controller software. Such security policies and layers be implemented on controllers to ensure that only valid code and valid behaviors are allowed to run on the controllers, which can maintain secure operation and prevent the attacks from ever infiltrating the IoT device's infrastructure, such as a car's Controller Area Network (CAN Bus).
• By focusing on hardening the controllers within IoT devices/systems that are open to external access (via the Internet, WiFi, Bluetooth, etc.)—meaning restricting the operations and behavior of the controllers to a set of expected operations and behaviors—the controllers can be transformed from potential security vulnerabilities into gates that prevent and block hacker attempts to get into the controller's internal infrastructure, essentially stopping hacker attacks on IoT devices. Endpoint security layers can stop attacks on controller by blocking hackers at the gate—meaning an externally facing entry point into a device and/or system, such as at externally facing ECUs in an automobile that, if compromised, could provide access to the CAN Bus. As a result, attacks cannot make it inside of an IoT device/system, which can prevent access to and control of an IoT device/system's functions.
• This document describes four general aspects. First, automatic security policy generation which includes automatically generating custom security policies that can be implemented on controllers without manual design. Second, secure controller operation and malware prevention using custom security policies that have been incorporated into controllers. Third, securely logging and reporting information on controller operation, such as the current status of a controller and blocked malware attempts, back to a central management computer system in real time without affecting controller performance/operation. Fourth, providing a centralized computer system to aggregate information from multiple devices using the same controllers, to provide for global device/controller views and analytics, including identifying and detecting anomalous controller operation.
• While this document describes all four of these aspects, this document focuses the fourth aspect—a centralized computer system to aggregate information from multiple devices using the same controllers, to provide for global device/controller views and analytics, including identifying and detecting anomalous controller operation.
• In one implementation, a method for providing security on externally connected controllers includes receiving, at a server system, operation information for a plurality of instances of a controller, the plurality of instances being installed across a plurality of devices; statistically analyzing, by the server system, the operation information; identifying, by the server system, one or more anomalous controller behaviors based on the statistical analysis; and providing, by the server system, information regarding the one or more anomalous controller behaviors on the controller as potential security threats.
• Such a method can optionally include one or more of the following features, which can be combined in each possible sub-combination of features. The method can further include updating, by the server system, one or more security policies to exclude performance of the one or more anomalous controller behaviors in response to the information; and pushing out the updated one or more security policies to the plurality of devices. The plurality of instances of the controller can block the one or more anomalous controller behaviors from being performed on the controller using the updated one or more security policies. The plurality of instances of the controller can include a security middleware layer that is incorporated into operating systems on the plurality of instances of the controller. The security middleware layer can be positioned to restrict one or more kernel processes of the operating system to operations that are permitted according to the updated one or more security policies. Updating the one or more security policies can include removing information corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the one or more security policies. The one or more whitelists can define the operations that are permitted. The one or more anomalous controller behaviors can include a particular sequence of function calls. The information removed from the one or more whitelists can include function mappings outlining the particular sequence of function calls. The one or more anomalous controller behaviors can include receipt or transmission of a particular network packet. The information removed from the one or more whitelists can include one or more of: an IP address specified in the particular network packet, a network port specified in the particular network packet, and a payload content type for the particular network packet. The one or more anomalous controller behaviors can include execution of a particular process. The information removed from the one or more whitelists can include information identifying the particular process. The controller can be an automotive controller and the device is a vehicle. The operation information can include malware reports that identify malware blocked on the plurality of instances of the controller, the malware reports including copies of the blocked malware.
• In another implementation, a method for providing security on externally connected controllers can include receiving, at a server system, real-time information identifying malware blocked by a security middleware layer running on a controller that is part of a device; aggregating, by the server system, the real-time information with real-time information from other controllers; determining, by the server system, aggregate information related to the blocked malware on the controller; generating, by the server system, a report that includes information identifying the blocked malware on the controller and the aggregate information; and transmitting, by the server system and in real-time, the report to a client computing device for a user who is associated with the controller.
• Such a method can optionally include one or more of the following features, which can be combined in each possible sub-combination of features. The real-time information can include a malware report that identify the blocked malware, a portion of an operating system on the controlled that was exploited by the blocked malware, and a copy of the blocked malware. The report can include information identifying the blocked malware, the exploited portion of the operating system, and the copy of the blocked malware. The aggregate information can include information regarding a current status of other instances of the controller running on other devices. The aggregate information can include information regarding other instances of the malware being blocked on other controllers. The controller can be an automotive controller and the device is a vehicle.
• Certain implementations can provide one or more of the following advantages. For example, endpoint controller security can us an operating system (OS) agnostic security agent and is built with an OS-specific middleware and a general purpose security agent. Such a security agent can be deployed in externally connected controllers to perform a variety of security-related functions, such as enforcing automatically generated security policies, collecting forensics information and upload it to the cloud, and/or providing anti-tampering features to prohibit hackers from circumventing the security agents. Such OS-agnostic agents can allow for endpoint security to be readily configured and deployed across a wide variety of vehicle controllers and OS environments.
• In another example, the system can be integrated with the OEM/manufacturer build environment for controllers to automatically generate security agents and policies that are specific to the controllers, which can then be deployed to harden controllers and prevent security breaches. For instance, a client (or other software application/module) integrated into a build environment for a controller can scan the code and the binary for the controller, and automatically generate a security policy that is specific to the controller. Such scanning and automatic generation can include, for example, using static analysis tools and techniques to identify the universe of permitted processes, binaries, scripts, network usage, and/or other controller behaviors that are used to generate a customized security policy for the controller. Such as security policy can include, for example, a whitelist (e.g., identification of permitted processes, binaries, functions, operations), network firewall (e.g., identification of permitted network ports, IP addresses), functional graph (e.g., mapping and/or sequence of functions performed by a controller), and/or additional features that model permitted/designed behavior of the controller. Such automatic security policy generation (e.g., during build, due to static analysis (and other tools, such as simply signing on binaries to add to a whitelist)) can permit for endpoint security to be added to controllers with little to no effort on behalf of controller manufacturers/vendors, who can simply run the automated security policy generator prior to deployment in order to add endpoint security to their controller.
• In a further example, a server system (e.g., cloud-base system) can be used to manage and monitor controllers that are hardened with endpoint security. Such as server system can processes and generate reports regarding controllers, such as information on detected and blocked malware, the current state of controllers in a vehicle, and/or other relevant information. Such reports can be at any of a variety of levels of granularity, from vehicle-specific views to manufacturer-specific views to the industry-wide views, which can be based on aggregated and anonymized user/vehicle/manufacturer information. For instance, a server system can collect forensics information in order to display incident reports based on malware detection, to calculate anomaly detection, to display current state of cars on the roads, to provide a management console in order to enhance policies (in production and during build—i.e. the cloud system is also connected to the project while it's being developed), and/or other relevant features. Such features can allow for manufacturers, vendors, and/or other interested/authorized parties (e.g., government agencies) to better understand both the micro and the macro security threats that are posed by externally connected controllers as well as the current security status (e.g., secure, under attack) of vehicles on the road. Such features can additionally permit for anomaly detection based prevention, such as through analyzing device measurements (e.g., CPU load, memory usage, I/O usage, etc.) that, by themselves, are not statistically significant, but when analyzed over time can indicate anomalies. For example, taking device measurements over time, average values (e.g., avg. CPU load, avg. memory usage, avg. I/O usage, etc.) can be determined, and when N>x, the standard deviation of the average is so small (e.g., alpha<0.00001) that it can serve as a base line for anomaly prevention and not just detection—meaning it can be accurate enough to block anomalies before/while they are occurring instead of after they have occurred.
• In another example, endpoint controller security can permit detection that is much earlier than network-based solutions, which often are not able to detect that malware has compromised a controller until after the malware has had a chance to run. In contrast, endpoint security detects the malware before it has a chance to run on a controller, which not only prevents the malware from ever being executed but also determines that an operation is malware before it has been executed.
• In a further example, endpoint security can readily be retrofitted for existing externally connected controllers that were not originally designed or manufactured with endpoint security in mind. This is possible through the automatic security policy generation features described above, which allow for security policies to be generated and readily deployed for controllers with little effort from manufacturers/vendors, and allow for endpoint security to be added to controllers through simple controller updates. Retrofitting can enhance security versions for existing vehicles on the road today, regardless of whether they were originally designed to include endpoint security.
• In another example, rather than looking for hackers that are already in an IoT device/system's internal network (e.g., CAN Bus, internally-facing controllers), the disclosed technology can detect and stop an attack from getting into the internal network (e.g., CAN Bus, other controllers) in the first place. For example, the disclosed end-point solution can provide an early intrusion detection system that can protect externally connected controllers, which can allow for early intrusion detection and identification of threats targeting the IoT device/system and blocking exploits from infiltrating its internal components, which can ensure device/system and/or user safety.
• Additional and/or alternative advantages are also possible, as described below.
BRIEF DESCRIPTION OF THE ATTACHMENTS
• FIG. 1A is a conceptual diagram of an example system for generating and implementing a custom security policy on an example controller.
• FIG. 1B is a conceptual diagram of an example system for implementing generating and implementing custom security policies on example ECUs that are part of an example vehicle.
• FIG. 2 is a diagram of an example system for detecting and reporting anomalies across a population of controllers
• FIG. 3 depicts an example interface for providing an incident report for a controller.
• FIG. 4 depicts an example process for generating and transmitting real-time report data for a population of controllers.
• FIG. 5 depicts an example process for detecting anomalies across a population of controllers.
• FIG. 6 is a block diagram of example computing devices.
• Like reference numbers and designations in the various drawings indicate like elements.
DETAILED DESCRIPTION
• FIG. 1A is a conceptual diagram of anexample system100 for generating and implementing a custom security policy on an example controller. Theexample system100 includes a policy generation computer system104 (e.g., computer server system, cloud computing system, client computing device) that is programmed to automatically generate a custom security policy for a controller, an example IoT device112 (e.g., ECU) that includes anexample controller114 that will use the generated security policy to operate securely and to prevent malware, and a management computer system122 (e.g., computer server system, cloud computing system, client computing device) that is programmed to receive real-time controller information, to detect anomalous controller behavior, and to provide an interface for users to view real-time controller/device status information. Although not depicted, thesystem104, the IoT device112, and thesystem122 can communicate over one or more communication networks, such as the internet, local area networks (LAN), wide area networks (WAN), virtual private networks (VPN), wired networks, wireless networks, mobile data networks, or any combination thereof.
• The policygeneration computer system104 can receivecontroller software102, which can include an operating system and/or applications that are to be run on a controller. Thecontroller software102 can include binary code, for example, which can be disassembled (e.g., by the policy generation computer system104) prior to being analyzed to generate a custom security policy. The policygeneration computer system104 can use the controller software to automatically generate acustom security policy108 for the controller that is to execute thesoftware102, as indicated by step A (106). For example, thecomputer system104 can analyze thesoftware102 to determine a set of operations and behaviors that are expected during operation of a controller according to thesoftware102, and can incorporate those operations and behaviors into thecustom security policy108, which may include one or more whitelists of permitted operations and/or behaviors. Generating the security policy can additionally include generating one or more signatures for components of thecontroller software102, such as processes/functions that are part of thesoftware102, that can be used to verify that the code being executed as part of thesoftware102 is authentic and has not been modified/altered/replaced by malware. By automatically generating asecurity policy108 from thecontroller software102—meaning without needing manual design for implementation/generation—thesystem100 can reduce the burden, cost, and time to generate and implement security layers on controllers, which can increase controller security.
• The policy generation can be performed by thecomputer system104 in a way that does not necessitate any sort of modification to thecontroller software102. For example, thecustom policy108 can be separate from and not rely on modification of thesoftware102 in order to operate. By generating and implementing thesecurity policy108 without having to modify or alter thecontroller software102, thesystem100 can additionally reduce the burden on security layer implementation, which can increase security layer implementation and overall controller security. For example, if thecontroller software102 were to be modified in significant ways in order to incorporate thesecurity policy108, thesoftware102 would need to be verified and tested again after thesecurity policy108 has been integrated into the system, which can slow time to deployment and can delay the incorporation of security layers on controllers.
• The computer system104 (and/or other computer systems, such as original equipment manufacturers (OEM)) can load thesoftware102 and thesecurity policy108 for thecontroller114 of the IoT device112, as indicated by step B (110). For example, thecontroller software102 and thesecurity policy108 can be flashed onto thecontroller114.
• Thecontroller114 can securely operate using thecontroller software102, which is confined to operating within the confines of thesecurity policy108, as indicated by step C (116). For example, thesecurity policy108 can include whitelists (and other information) that designate authorized behaviors and operations for thecontroller114 that are within expected behavior according to thecontroller software102. Behaviors/operations that deviate from those authorized behaviors/operations can be prevented from occurring based on thesecurity policy108 hardening thecontroller114 against such behaviors/operations.
• For example, thecontroller software102 can include one or more portions of code that make thecontroller114 unsecure, which can potentially affect the security of not only thecontroller114 but the device112 (and other devices to which it is connected). As described above, security vulnerabilities can come in any of a variety of different types, such as buffer overrun vulnerabilities through which a hacker could potentially modify the software stack to causemalware120 to be loaded onto and executed by thecontroller114. By operating according thesecurity policy108 on thecontroller114, such malware attempts can be blocked before themalware120 is loaded/executed by thecontroller114, as indicated by step D (118).
• Such hardening of thecontroller114—meaning restriction of thecontroller114 to specific behaviors/operations outlined in thesecurity policy108—can provide endpoint security that provides an early intrusion detection system with a variety of benefits. For example, it can allow for early intrusion detection and warning of attacks by identifying attack attempts before they are able to install/run themalware120 on thecontroller114. It can also stops attacks at the gate—meaning preventing attacks from making it onto thecontroller114 and the device112 (as opposed to other security solutions that attempt to identify malware once it has already been installed/run on a controller). It can eliminate false positives (incorrect identification of attacks) by restricting operation of thecontroller114 to only the code and applications that have explicit permission to run on the controller, which can eliminate potential ambiguity (e.g., either the code is part of the factory settings or not). It can also eliminates risk of thepolicy108 becoming security vulnerability itself by being outdated. For instance, by custom generating thesecurity policy108 to match the current version of thecontroller software102, thesecurity policy108 can continue to harden thecontroller114 as thecontroller software102 is updated over time. Additionally, this is in contrast to other security policies that may use blacklists seeking to identify and prevent particular malware. Such blacklists may require constant updating and may continually run the risk of being outdated, which can expose thecontroller114 to potential vulnerabilities. By using whitelists in thesecurity policy108 that outline permitted behaviors/operations, thesecurity policy108 can continue to protect thecontroller114 even when new and yet unknown malware attempts are launched against thecontroller114 and device112. Quality checks can also be minimized, which can reduce time for deployment and updates. For example, endpoint security layers can be isolated within thecontroller114, so there may not be a need to rest the operation of the entire device112 (or other devices connected to the device112) as part of the security layer deployment.
• Thecontroller114 can log information about its operation, including blocked malware attempts as well as information on secure operation of thecontroller114 over time. Traces of blocked malware attempts can include a variety of information, such as the malware itself, the origin of the malware (e.g., IP address from which the malware originated), and information identifying the code segment that provided the malware exploit. Thecontroller114 report information on controller operation, as indicated by step E (124). Such reporting can be provided in real-time. For example, thecontroller114 can report malware traces in response to themalware120 is attempt being blocked. Thecontroller114 can balance reporting with controller performance against the timeliness of reporting for less critical information, such as information about secure operation of thecontroller114 during periods of time when no malware attacks were attempted/blocked. For instance, such reports can be delayed until periods of time when thecontroller114 and/or the device112 have at least a sufficient amount of processing capacity and/or network bandwidth available.
• Themanagement computer system122 can receive reports from thecontroller114 as well as from multiple other controllers and devices, and can aggregate the reports into a central database system. The reports can be used to provide real-time controller/device information, as indicated by step E (126). For example, thecomputer system122 can transmit real-time information that is presented on client computing devices (e.g., mobile computing devices, laptops, desktop computers) in user interfaces, such as theexample user interface130 that includes status information132 for example controllers C1-C6 andmalware information134 that identifies particular malware that has been blocked by these controllers. The real-time information can be at any of various levels of granularity, such as a device-level (status information for a specific device) and/or a population-level (status information across multiple devices/systems).
• Thecomputer system122 can additionally use the information reported by controllers to detect anomalies, as indicated by step E (128). For example, thecomputer system122 can use statistical analysis to identify operation/behaviors that are outside of the normal operation of a controller, such as identifying a sequence of function calls that are a statistical outlier outside of the normal operation of a controller.
• FIG. 1B is a conceptual diagram of anexample system150 for implementing generating and implementing custom security policies on example ECUs that are part of anexample vehicle152. Theexample system150 is an example implementation of thesystem100 to a specific IoT context, which in this example is thevehicle152. Thesystem100 and thesystem150 can be implemented in a variety of other IoT contexts.
• In this example, thevehicle152 includes acontrol system154 that includes multiple ECUs156a-nthat each have their own custom security policy158a-n. Although not depicted, the security policies158a-ncan be generated in a similar manner described above with regard toFIG. 1A and the policygeneration computer system104. The security policies158a-ncan harden the ECUs156a-nand can effectively block malware attempts160a-n, which can be attempts by hackers to find a way into the CAN Bus of thevehicle152. While thevehicle152 can include over a hundred ECUs connected to the CAN Bus, only a few may be open externally (accessible to external networks outside of thevehicle152, such as the internet). These external ECUs (e.g., ECUs156a-n) can be the gateways into the car and the security policies158a-ncan stop attackers at these gateways, which can significantly reduce, if not eliminate, the risk of attacks penetrating the car's network, which can disrupt the car's operation.
• For example, the security policies158a-ncan include whitelists for permitted program binaries, processes, scripts, network behavior, and/or other devices, and can be embedded within the ECUs156a-nto ensure only explicitly allowed code and behavior may run on it. By using the security policies158a-nthat are specific to the ECUs156a-n, any processes or functions that are outside of the ECUs permitted/designed operating behavior can be immediately detected and stopped from running on the ECUs156a-n. This can allow for the ECUs156a-nto stop malicious code from ever being executed by and possibly taking control of an ECUs' operation.
• For instance, hackers targeting thevehicle152 can use a “dropper,” which is a small piece of code or operation, to try to exploit a vulnerability and implant the malware160a-n. The malware160a-nis the code that ultimately tampers with or takes control of the function of thevehicle152, which can cause significant damage and put the safety of the driver and others on the road at risk. By adding an endpoint security layers and policies158a-nto ECUs156a-nso that they use policies outlining whitelists of permitted processes, binaries, etc., the ECUs156a-nare able to provide an early intrusion detection system capable of early detection of unexpected behavior or operation of a dropper (example intrusions) and immediately report on the attack attempt in real-time, as indicated bystep162. The early intrusion detection and warning can give the original equipment manufacturers (OEMs) and system providers of the vehicle152 (and its subparts) time to address the threat, as indicated by thecomputer system164 providing real-time status information to aclient computing device168 withinformation170 on malware that has been blocked across the ECUs156a-n(step166). For example, an alert on the malware160a-ncan include the complete trail of the attack on the ECUs156a-n, including its source and path, so vulnerabilities can be fixed and blocked to prevent any malware from infiltrating the CAN Bus on thevehicle152.
• Dropper and other hacker attempts to introduce the malware160a-non the externally connected ECUs156a-ncan be detected by the endpoint security layers and policies158a-nas foreign code and can be blocked when they attempts to run. For instance, such droppers and other hacker attempts are not part of the factory settings for the ECUs156a-n, so they can be blocked from running by the security layers and policies158a-n, which can stop them from running and prevent them from doing anything to disrupt the safe operation of thevehicle152. If a dropper does succeed in dropping the malware160a-nonto the externally connected ECUs156a-n, when the malware160a-nattempt to run on the ECUs156a-n, the endpoint security layer and policies158a-ncan detect it as foreign code and block its attempts to run.
• Endpoint security layers (e.g.,security policy108, security layer and policies158a-n) can be implemented on newly deployed controllers and can be retrofitted on previously released controllers that may not have previously included security layers. Such retrofitting can improve the security of devices already in use and can be added as part of regular software updates that drivers receive during regular maintenance and updating. Once retrofitted, previously deployed controllers can be protected with endpoint security will be hardened against the cyber threats targeting them.
• FIG. 2 is a diagram of anexample system200 for centrally managing a population of controllers and detecting controller anomalies. Theexample system200 can be similar to thesystems122 and164 described above with regard toFIGS. 1A-B.
• Thesystem200 can aggregate operation information, including reports of blocked malware and operational logs, from multiple controllers and devices into a central database, and can use the information to provide real-time reports on device and controller security status. Real-time reports can include, for example, current status information across a population of controllers and devices/systems, including forensic information identify of malware attacks and the security vulnerabilities in controller code that the malware was attempting to exploit.
• Thesystem200 can also use the aggregated operational information to detect anomalies in controller and device performance, which can be used to update security policies. For example, a particular sequence of functions may permitted under a custom security policy for a particular controller, but may only occur infrequently and during times when malware attacks are being blocked. Accordingly, thesystem200 can determine that such a particular sequence may be an anomaly that is a possible exploit to be used by hackers, and can be removed from a process map providing approved/validated sequences of processes that are used as part of a custom security policy.
• As shown inFIG. 2, theexample system200 includes amanagement system220. Themanagement system220, for example, can be implemented using one or more computer servers(s)210. In some examples, the computing server(s)210 can represent various forms of servers, including, but not limited to a network server, a web server, an application server, or a server farm. The computing server(s)210 may be configured to execute application code associated with a variety of software components (e.g., modules, objects, libraries, services, etc.) and/or hardware components, including an incident report aggregator222, ananomaly detector224, asecurity policy modifier226, and a report transmitter228. Two or more of thecomponents222,224,226, and228 may be implemented on the same computing device, or on different devices, such as devices included in a computer network, a peer-to-peer network, or on a special purpose computer or special purpose processor. Operations performed by each of thecomponents222,224,226, and228 may be performed by a single computing device, or may be distributed to multiple devices.
• Theexample system200 can include one or more computing device(s) (e.g.,computing devices212 and262) employed by users for sending data to and receiving data from the securitypolicy generation system220. Thecomputing devices212 and262, for example, may be any suitable type of computing device (e.g., laptop or desktop computer, tablet computer, smartphone, personal digital assistant, or other stationary or portable device). Among other components, thecomputing devices212 and262 can include one or more processors, computer readable media that store software applications, input device(s) (e.g., touch screens, keyboards, computer mice, motion sensors, microphones, etc.), output device(s) (e.g., display screens, speakers, etc.), and communications interfaces.
• Various data sources (e.g., databases, file systems, etc.) may maintain data used by theexample system200 and its components. For example, thesystem200 includes acentral database240 that can include aggregated controller/device information. Thecentral database240, for example, can implement databases, file systems, and the like to add, remove, and maintain data used by thesystem200.
• The computing server(s)210, thecomputing devices212 and262, and thecentral database240 included in theexample system200 can communicate over one ormore networks250. The network(s)250 may include a local area network (LAN), a WiFi network, a mobile telecommunications network, an intranet, the Internet, or any other suitable network or any appropriate combination thereof.
• Thesystem200 can include a plurality of controllers230a-nthat, in this example, are spread across a plurality of devices231a-n(devices/systems may each include more than one controller). The controllers230a-ncan transmit incident reports232a-nto thecomputer system210, such as reports of malware attempts blocked, operational logs (e.g., operations performed on the controllers230a-n, resource usage information at various times during controller operation), alerts regarding possible security risks (e.g., alerts regarding potential tampering with custom security layers on the controllers230a-n), and/or other appropriate information. The incident report aggregator222 of thecomputer system210 can receive and aggregate the information in a central database240 (e.g., cloud data storage system). The incident report aggregator222 can anonymize the data stored in thecentral database240 so that it is able to provide relevant and usable information for addressing specific security threats without revealing personally identifying information for users associated with the devices231a-n.
• In addition to storing reports, logs, and other information, thecomputer system210 can maintain malware code that has been blocked on the controllers230a-nin thecentral database240. Thecomputer system210 and thecentral database240 can take additional precautions to ensure that the malware code is segregated from any code for generating or inclusion in security policies. Thecomputer system210 can analyze malware code samples to identify operating system vulnerabilities on controllers and can provide malware samples to manufacturers/developers to better understand and patch these vulnerabilities.
• The incident report aggregator222 can additionally be programmed to identify malware threats and code vulnerabilities across population of similar devices231a-nand/or controllers230a-n. For example, the report aggregator222 can be programmed to identify trends, such as particular malware attack attempts (based on identification of similar malware code samples from the central database240) and particular controllers that include software bugs providing potential exploits. The report aggregator222 can, for instance, identify that a particular controller is vulnerable to a particular attack, but that other controllers are not susceptible to such an attack (i.e., other controllers do not include software bug providing potential exploit).
• Thecomputer system210 includes ananomaly detector224 that is programmed to detect anomalies and improve security policy across population of similar devices231a-nand/or controllers230a-n. For example, theanomaly detector224 can detect anomalies in controller performance and operation that, when viewed in isolation may not indicate potential malware vulnerabilities, but when viewed across a population of similar controllers can indicate anomalous behavior that is an indicator of a potential security threat. Theanomaly detector224 can use statistical analysis on the data contained within thecentral database240 to identify statistical outliers in controller performance, and can provide those outliers to asecurity policy modifier226, which can compare those outliers against controller security policies to identify modifications to prohibit (carve out) the anomalous behavior. For instance, a particular controller security policy may permit function A to call function X to call function C. However, such a sequence of function calls may be performed infrequently and, when coupled with blocked malware attacks (before, during, or after the sequence of functions calls), can indicate that such a sequence is a malware vulnerability and should be removed from the security policy (removed from the function mapping for the controller). Thesecurity policy modifier226 can be programmed to modify corresponding security policies to remove anomalous features from being permitted under the policy, and can cause policy updates to be provided to relevant devices.
• The report transmitter228 can be programmed to generate and transmit reports to computing devices that are associated with manufacturers/developers, such as thecomputing device260. The reports can include a variety of information, such the status across a population of devices231a-nand/or controllers230a-n, current security attacks, code bugs that are providing attack vulnerabilities, comparison of the population of devices231a-nand/or controllers230a-nagainst other groups of devices/controllers (e.g., other versions of those devices and/or controllers, such as versions provided by other manufacturers). The reports can include real-time information that is conveyed from the controllers230a-nin real-time to thecomputer system210, and relayed to thecomputing device260 in real-time. Manufacturers/developers (and other authorized users) of thedevice260 can additionally use report interface to drill down into the specifics of particular security vulnerabilities on a controller.Reports262 can be output in various user interfaces on thecomputing device260, such as graphical user interfaces (GUI), such as web browser interfaces, mobile app interfaces, and/or other appropriate interfaces.
• FIG. 3 depicts an example interface300 for providing an incident report for a controller. Referring toFIG. 2, for example, the example interface300 can be presented on a client computing device, such as thecomputing device212 and/or thecomputing device262 and can be used to provide incident report information (e.g., incident report(s)232a,232b, and232c) received from controller/devices (e.g., controller(s)230a,230b, and230c). The information in the interface300 can be provided by a management computer system, such as themanagement computer system122, themanagement computer system164, and/or themanagement computer system210.
• In the present example, the interface300 includes incident report information for a particular controller, including incident details302, such as a timestamp when the incident occurred, a type of malware blocked (e.g., executable, script), and actions that was taken by the security layer on the controller (e.g., blocked, restarted controller). The interface300 can also presentmalware information304, such as a name of the malware that was blocked (e.g., malware file name) and a type of file (e.g., executable, script), as well as information on the exploit (security vulnerability) on the controller that was used by the malware in the attack (306), such as a name of the infected/vulnerable process and a specific function that was exploited by the malware. The interface300 can additionally include afeature308 through which a user of the interface300 can download the actual malware that was blocked.
• The interface300 can additionally include a section of information that provides context for the malware attack on the controller, including recent network activity information310 (e.g., recent network connections with host identifications, transmission protocols, and ports), information on files that have been recently created (312), and information on active processes that are currently running on the controller (314). The interface300 can also include afeature316 through which a user can download an activity log for the controller.
• The interface300 can also include features through which other incidents and controllers within a device or system can be viewed (e.g., view information on other controllers and/or incidents within a vehicle), such as a link to view an incident list (318) andlinks320 to view other groupings of controller-related information. Other interfaces are also possible, such as the example interfaces130 and170 described above with regard toFIGS. 1A-B. Additionally, global/regional views of groups of controllers can also be provided, such as maps, charts, and/or graphs depicting the status, in aggregate, of the same controller installed across a group of devices/systems. Similar views can also be provided on a device/system level based on aggregate views of controller(s) status.
• FIG. 4 is a flowchart of an example technique400 for reporting real-time controller information to client computing devices. The example technique400 can be performed by any of a variety of management computer systems, such as themanagement computer system122, themanagement computer system164, and/or themanagement computer system210.
• Reports and other controller information can be received from multiple different devices and controllers (402). The reports and controller information can be aggregated in a central database (404). For example, thecomputer system210 can receive reports, logs, and other controller information from the controllers230a-n, which thecomputer system210 can aggregate and organize in the central database in one or more data structures to permit for ready identification of related information and fast recall. For example, thecentral database240 may store information in one or more hash tables where hashing is based on one or more parameters that may be relevant to reports, such as identifiers for types of controller and/or devices (to permit for information relevant to a particular type of controller/device to be retrieve quickly). Thecentral database240 can timestamp reports, logs, and other information received from the controllers230a-n, and may use techniques to maintain the most recent information in storage locations with faster recall (e.g., flash memory) and can relegate older information to cheaper storage locations with slower recall (e.g., hard drives).
• Malware threats and code vulnerabilities on controllers can be identified from the aggregated information (406). For example, for each particular instance in which malware attempts are blocked, information about the particular malware that was blocked can be identified (e.g., file name, type) and code exploits that were used by the malware can be identified (e.g., process, function, process/function version, controller, device/system). Some of this information can be included in malware reports that are received by thecomputer system210 from controllers230a-n, and other portions of the information can be determined from information included in the reports. Suggested code modifications/fixes can be determined, such as through analysis of the malware and the controller code that was the source of the exploit. An example of such information is presented in the interface300 as information304-306.
• In addition to determining information about a specific blocked malware instance, thecomputer system210 can determine a global context for the malware, such as determining a prevalence of the malware attack on other controllers and devices/systems (e.g., frequency of blocked instances over time on the same type of controller or device/system, frequency of blocked instances across other types of controllers or devices/systems). Thecentral database240 can provide a pool of relevant information make broader determinations about malware outside of a specific instance. Thecomputer system210 can, for example, generate statistics for a blocked malware instance, such as statistics on which devices/systems and/or controllers are affected, a context when attacks occurred (e.g., network connection, geolocation, operational state), specific code segments that are providing exploits, types of network connections over which the malware is transmitted (e.g., Wi-Fi, BLUETOOTH, cellular networks), and/or IP addresses/geolocations from which attacks originate. Additionally, thecomputer system210 can determine connections and relationships between different malwares, such as through comparing code segments and/or functional operations that are included in malware obtained through reports. Such relationships can additionally be used to provide a global context for a malware attack. Such global information can additionally be provided in an interface, such as the interface300.
• Real-time status for a population of devices/systems and/or controllers can be determined (408). For example, the same controller may be installed on many devices/systems. Thecomputer system210 can generate an aggregate view of the status of controllers in this population through accessing information contained in thecentral database240. Status information can include, for instance, a ratio of the number of controllers and/or devices/systems that are under attack versus those not under attack.
• Reports can be generated (410). For example, thecomputer system210 can generate reports that include one or more portions of the information described above with regard to steps402-408. For instance, a report can include real-time information on malware threats and code vulnerabilities, including identification of the malware attack, information on the malware attack, identification of the code vulnerability and suggested fixes, a copy of the malware, global malware information, and real-time population information for the controller and/or device/system that experienced the attack. An example report is depicted inFIG. 3. The generated report can be transmitted to a client device for presentation (412).
• FIG. 5 is a flowchart of anexample technique500 for detecting anomalies in controller operation that may indicate malware attacks. Theexample technique500 can be performed by any of a variety of management computer systems, such as themanagement computer system122, themanagement computer system164, and/or themanagement computer system210.
• Report, logs, and other controller information from multiple different devices and/or controllers can be received (502) and aggregated into a central database (504). Statistical analysis can be performed on the aggregated information (506) and can be used to determine baseline device/system and/or controller behavior (508). For example, thecomputer system210 can use theanomaly detector224 to identify baseline behavior for particular controller types, device/system types, and/or combinations of the two across one or more facets, such as process/function sequences, network packet (e.g., IP address, port, payload), process/function call frequency, device/system context (e.g., operational state, geolocation, network connection type), and/or resource usage (e.g., CPU usage, memory allocations). From these baselines, anomalies can be identified (510). For example, thecomputer system210 can identify behavior that deviates from the baseline by at least a threshold statistical deviation (e.g., two or more standard deviations). From the identified anomalies, modifications to the security policy can be generated (512). For example, thecomputer system210 can use thesecurity policy modifier226 to modify whitelists that are part of the security policy for a controller to remove portions of the whitelist that permit the anomalous behavior. Security policy updates can be pushed out to devices/systems with controllers using the security policy (514).
• FIG. 6 is a block diagram ofexample computing devices600,650 that may be used to implement the systems and methods described in this document, as either a client or as a server or plurality of servers.Computing device600 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers.Computing device600 is further intended to represent any other typically non-mobile devices, such as televisions or other electronic devices with one or more processers embedded therein or attached thereto.Computing device650 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the inventions described and/or claimed in this document.
• Computing device600 includes aprocessor602,memory604, astorage device606, a high-speed controller608 connecting tomemory604 and high-speed expansion ports610, and a low-speed controller612 connecting to low-speed bus614 andstorage device606. Each of thecomponents602,604,606,608,610, and612, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. Theprocessor602 can process instructions for execution within thecomputing device600, including instructions stored in thememory604 or on thestorage device606 to display graphical information for a GUI on an external input/output device, such asdisplay616 coupled to high-speed controller608. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also,multiple computing devices600 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).
• Thememory604 stores information within thecomputing device600. In one implementation, thememory604 is a computer-readable medium. In one implementation, thememory604 is a volatile memory unit or units. In another implementation, thememory604 is a non-volatile memory unit or units.
• Thestorage device606 is capable of providing mass storage for thecomputing device600. In one implementation, thestorage device606 is a computer-readable medium. In various different implementations, thestorage device606 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as thememory604, thestorage device606, or memory onprocessor602.
• The high-speed controller608 manages bandwidth-intensive operations for thecomputing device600, while the low-speed controller612 manages lower bandwidth-intensive operations. Such allocation of duties is an example only. In one implementation, the high-speed controller608 is coupled tomemory604, display616 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports610, which may accept various expansion cards (not shown). In the implementation, low-speed controller612 is coupled tostorage device606 and low-speed bus614. The low-speed bus614 (e.g., a low-speed expansion port), which may include various communication ports (e.g., USB, Bluetooth®, Ethernet, wireless Ethernet), may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.
• Thecomputing device600 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as astandard server620, or multiple times in a group of such servers. It may also be implemented as part of arack server system624. In addition, it may be implemented in a personal computer such as alaptop computer622. Alternatively, components fromcomputing device600 may be combined with other components in a mobile device (not shown), such ascomputing device650. Each of such devices may contain one or more ofcomputing devices600,650, and an entire system may be made up ofmultiple computing devices600,650 communicating with each other.
• Computing device650 includes aprocessor652,memory664, an input/output device such as adisplay654, acommunication interface666, and atransceiver668, among other components. Thecomputing device650 may also be provided with a storage device, such as a micro-drive or other device, to provide additional storage. Each of thecomponents650,652,664,654,666, and668, are interconnected using various buses, and several of the components may be mounted on a common motherboard or in other manners as appropriate.
• Theprocessor652 can process instructions for execution within thecomputing device650, including instructions stored in thememory664. The processor may also include separate analog and digital processors. The processor may provide, for example, for coordination of the other components of thecomputing device650, such as control of user interfaces, applications run by computingdevice650, and wireless communication bycomputing device650.
• Processor652 may communicate with a user throughcontrol interface658 anddisplay interface656 coupled to adisplay654. Thedisplay654 may be, for example, a TFT LCD display or an OLED display, or other appropriate display technology. Thedisplay interface656 may comprise appropriate circuitry for driving thedisplay654 to present graphical and other information to a user. Thecontrol interface658 may receive commands from a user and convert them for submission to theprocessor652. In addition, anexternal interface662 may be provided in communication withprocessor652, so as to enable near area communication ofcomputing device650 with other devices.External interface662 may provide, for example, for wired communication (e.g., via a docking procedure) or for wireless communication (e.g., via Bluetooth® or other such technologies).
• Thememory664 stores information within thecomputing device650. In one implementation, thememory664 is a computer-readable medium. In one implementation, thememory664 is a volatile memory unit or units. In another implementation, thememory664 is a non-volatile memory unit or units.Expansion memory674 may also be provided and connected tocomputing device650 throughexpansion interface672, which may include, for example, a subscriber identification module (SIM) card interface.Such expansion memory674 may provide extra storage space forcomputing device650, or may also store applications or other information forcomputing device650. Specifically,expansion memory674 may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example,expansion memory674 may be provide as a security module forcomputing device650, and may be programmed with instructions that permit secure use ofcomputing device650. In addition, secure applications may be provided via the SIM cards, along with additional information, such as placing identifying information on the SIM card in a non-hackable manner.
• The memory may include for example, flash memory and/or MRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as thememory664,expansion memory674, or memory onprocessor652.
• Computing device650 may communicate wirelessly throughcommunication interface666, which may include digital signal processing circuitry where necessary.Communication interface666 may provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication may occur, for example, through transceiver668 (e.g., a radio-frequency transceiver). In addition, short-range communication may occur, such as using a Bluetooth®, WiFi, or other such transceiver (not shown). In addition,GPS receiver module670 may provide additional wireless data tocomputing device650, which may be used as appropriate by applications running oncomputing device650.
• Computing device650 may also communicate audibly usingaudio codec660, which may receive spoken information from a user and convert it to usable digital information.Audio codec660 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset ofcomputing device650. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating oncomputing device650.
• Thecomputing device650 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as acellular telephone680. It may also be implemented as part of asmartphone682, personal digital assistant, or other mobile device.
• Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
• These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. Other programming paradigms can be used, e.g., functional programming, logical programming, or other programming. As used herein, the terms “machine-readable medium” “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.
• To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.
• The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.
• The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
• While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular implementations of particular inventions. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.
• Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
• Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

Claims (21)

1-25. (canceled)

26. A system for providing controller security, the system comprising:

a processor and computer-readable memory, the computer-readable memory comprising instructions that, when executed by the processor, cause the processor to perform security operations comprising:

receiving operation information for a plurality of instances of a controller, the plurality of instances being installed across a plurality of devices;

statistically analyzing the received operation information, wherein the statistically analyzing comprises identifying an operation from the received operation information that is outside of determined normal operations of the controller, the identified operation comprising at least one of:

a processor operation;

a memory operation; or

an input/output operation;

identifying one or more anomalous controller behaviors based on the statistical analysis; and

identifying information regarding the one or more anomalous controller behaviors on the controller as a potential security threat.

27. The system ofclaim 26, wherein the statistically analyzing comprises analyzing at least one of: a process sequence, a function sequence, a network packet, a process frequency, a function frequency, a device context, a system context, or a resource usage.

28. The system ofclaim 26, wherein the plurality of instances of the controller are of a common controller type.

29. The system ofclaim 28, wherein the determined normal operations of the controller comprise determined normal operations for the common controller type.

30. The system ofclaim 26, wherein the plurality of devices are of a common device type.

31. The system ofclaim 26, wherein the security operations further comprise performing at least one of: generating a security policy or modifying a security policy.

32. The system ofclaim 31, wherein the security operations further comprise modifying the security policy by performing at least one of:

removing information corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing function mappings corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing an IP address corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing a network port corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing a payload content type corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy; or

altering a process map that is part of the security policy.

33. The system ofclaim 26, wherein the security operations further comprise:

modifying an existing security policy; and

pushing out the modified security policy to at least one of the plurality of instances of the controller having the existing security policy.

34. The system ofclaim 26, wherein identifying the operation that is outside of determined normal operations of the controller comprises determining that the operation deviates from a behavioral baseline by a threshold number of standard deviations.

35. The system ofclaim 26, wherein the operation information comprises at least one malware report that identifies malware on at least one of the plurality of instances of the controller.

36. The system ofclaim 35, wherein the malware is associated with the one or more anomalous controller behaviors.

37. The system ofclaim 36, wherein the security operations further comprise:

modifying a security policy; and

deploying the modified security policy to at least one of the plurality of instances of the controller, wherein the modified security policy is configured to cause the at least one of the plurality of instances of the controller to perform at least one of:

blocking the identified malware; or

preventing the one or more anomalous controller behaviors.

38. A method for providing controller security, the method comprising:

receiving operation information for a plurality of instances of a controller, the plurality of instances being installed across a plurality of devices;

statistically analyzing the received operation information, wherein the statistically analyzing comprises identifying an operation from the received operation information that is outside of determined normal operations of the controller, the identified operation comprising at least one of:

a processor operation;

a memory operation; or

an input/output operation;

identifying one or more anomalous controller behaviors based on the statistical analysis; and

identifying information regarding the one or more anomalous controller behaviors on the controller as a potential security threat.

39. The method ofclaim 38, wherein the statistically analyzing comprises analyzing at least one of: a process sequence, a function sequence, a network packet, a process frequency, a function frequency, a device context, a system context, or a resource usage.

40. The method ofclaim 38, further comprising at least one of:

generating a security policy; or

modifying a security policy.

41. The method ofclaim 40, further comprising modifying the security policy by performing at least one of:

removing information corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing function mappings corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing an IP address corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing a network port corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy;

removing a payload content type corresponding to the one or more anomalous controller behaviors from one or more whitelists that are part of the security policy; or

altering a process map that is part of the security policy.

42. The method ofclaim 38, further comprising:

modifying an existing security policy; and

pushing out the modified security policy to at least one of the plurality of instances of the controller having the existing security policy.

43. The method ofclaim 38, wherein the operation information comprises at least one malware report that identifies malware on at least one of the plurality of instances of the controller.

44. The method ofclaim 43, wherein the malware is associated with the one or more anomalous controller behaviors.

45. The method ofclaim 44, further comprising:

modifying a security policy; and

deploying the modified security policy to at least one of the plurality of instances of the controller, wherein the modified security policy is configured to cause the at least one of the plurality of instances of the controller to perform at least one of:

blocking the identified malware; or

preventing the one or more anomalous controller behaviors.

Images