GB2586044A - Intrusion protection - Google Patents

Abstract

A network controller (1, fig 1) receives a data stream comprising a plurality of communications from an Internet of things (IoT) device 2. Each communication is analysed 304 to identify whether the communication is malicious. In response to identifying that a communication is malicious, a security policy 16 is selectively applied to the data stream containing communications generated by the IoT device identified as malicious. The security policy permits the IoT device to continue to receive other data streams that are not associated with the malicious communications. The policy may be applied to a node adjacent to the IoT device. Applying the security policy to the data stream may include applying the policy to an application sending the communication. Security policy may be dependent on user input, IoT characteristics or the communication identified as malicious. Policies may be an instruction to cease, throttle, redirect or envelope traffic, apply IPS, constrain the IoT device or stop an application of the IoT device. The IoT device may be a network enabled sensor, the remote controller may be a network orchestrator, and the node adjacent to the IoT device may be a gateway serving the IoT device.

Description

Intellectual Property Office Application No. GII1910911.5 RTM Date:30 January 2020 The following terms are registered trade marks and should be read as such wherever they occur in this document: Raspberry Pi (Page 1) Intellectual Property Office is an operating name of the Patent Office www.gov.uk /ipo Intrusion Protection This invention relates to intrusion protection in the Internet of Things (loT). loT devices and sensors transmit data between each other, and over the network to the cloud for storage or for use by other applications.

The internet was originally created for communication purposes but over time it has evolved to embrace new concepts such as e-commerce, social media and video streaming. The Internet of Things takes the internet concept to another level by giving connectivity to smaller devices like sensors (e.g. temperature, air quality, accelerometer sensors). Some applications of the loT include people counting (footfall measurement), monitoring of traffic, air quality, temperature and other environmental measures, and operating systems such as street lights or traffic signals. The loT data is processed by applications that interpret the data and act upon it, for example turning on lights in response to detection of movement.

The use of the Internet of Things (loT) for sensing the environment is growing, and the number of devices beginning to be connected to each other and to the "Cloud" over the Internet network is in the billions. Many of these devices only have low processing power, such as Raspberry Pi's, small factor PCs and sensor devices. The loT devices typically transmit their data to a nearby gateway (small computer) that has more compute, battery and network power which is then responsible for transforming the data to be sent to the Cloud for storing or to be used by loT analytical applications.

The increasing use of loT sensors means more data is being sent over the network for analysis. Ever more complex services and especially micro-services present new opportunities for attack from malevolent forces. Security must be at the core of how these services are composed. If there is a security-critical loT application which relies on data to make decisions any latency in the response can be critical.

Although generally described as malicious attacks, other anomalous traffic, 30 caused for example through poor design or damaged sensors, can also harm the efficient operation of a network. In practice, all such potentially-damaging anomalies are handled in the same way, whether the cause is malicious or accidental.

In this specification, references to an loT device can refer to a gateway, an edge gateway or to an loT sensor with limited computing capability.

One solution to fix latency problems for critical loT apps is edge computing.

The type of data generated by such devices can vary, and some data may be more sensitive than others. The demand for this technology means that deployment is often done quickly and consequently appropriate security measures like segmentation of traffic or firewall policies may fail to be installed, or conversely, such security may be applied by default in circumstances where they are not needed and may even impede efficient operation.

loT devices which operate in public areas are vulnerable to interference from malware introduced by flaws in wireless networks, or from physical tampering. Any compromised device can spread malware to adjoining devices and even devices in other networks, resulting in attacks being replicated across multiple networks very quickly.

A number of types of attacks to loT devices exist. In a "Denial of Service" Attack, an endpoint is flooded with traffic in order to take it down. In a "Man in the Middle" attack, an attacker compromises a device and intercepts messages between two parties to gain information, or disguises itself to make other parties think the messages they are receiving are still legitimate. "Malware" is software which infects devices with malicious software which can then propagate to other devices. "Botnets" compromise many devices to steal information, exploitation of data, DoS, Spam etc. In order to detect many of these attacks, it is important to monitor the behaviour of the loT devices and the applications running on them. This includes monitoring things such as usage of system resources such as CPU, memory, use of file systems, and observation of inputs and outputs to the network. Some remediation methods include closing all unnecessary ports on loT devices, patching software on loT device to remove vulnerabilities, IP blocking -ensuring loT devices are prevented from communicating and installing malware Intrusion Detection Systems.

Traditional security measures like intrusion prevention systems and firewalls are designed to inspect and secure traffic coming into large devices and data centres.

Conventional remediation methods exist for such attacks, but these are often designed for larger systems and do not scale well to loT devices that have limited computing resource (CPU, RAM, storage) which makes it difficult to apply conventional security measures (e.g. firewall, intrusion prevention/detection). Such measures may include suspending communications for an individual loT device, patching vulnerabilities, or installing extra security tools like intrusion detection systems.

For this reason, security is often overlooked and only applied to the endpoint (e.g. cloud) where more resources are available. Any remediation method available usually requires manual intervention which is costly and time-consuming. The types of applications running on many loT devices can change so if a security policy is applied it can quickly become outdated.

Micro-segmentation is a network security technique which divides the network into small sub-networks -for example, grouping higher risks hosts. It also allows for a smaller attack surface and limits the effects of network failures on the wider 20 network nodes.

This is done by managing data centres, computing nodes, and applications using high-level IT security policies (layer 7). Security is improved by segmenting internal components which allows fine grain control. Micro-segmentation reaches its full potential in virtualised environments due to higher visibility and control of infrastructure. This level of control and security limits attackers' ability to move laterally through devices on the networks because the security is applied closer to the applications and individual devices sending data.

Applying micro-segmentation principles allows fine grain control of specific devices and network traffic paths and reduces the need to have heavyweight security systems which are not suitable for small loT sensors and gateways.

However, micro-segmentation methods require human intervention to analyse systems and manually apply security policies. Such methods are not always appropriate for loT devices that have limited computing resource, and they may be over-specified for devices only transmitting non-sensitive data. Moreover, security policies installed on loT devices can quickly become outdated.

Unified Threat Management (UTM) systems are a type of appliance which protect devices from security and network threats by integrating multiple services into a single appliance. These appliances can include services such as firewalls, antimalware, anti-virus, intrusion detection/prevention, virtual private networks and many others. They are usually virtualised and run directly on the device needing protection. Many of these appliances operate as agents and are remotely managed by another system.

According to the invention, there is provided a method for applying security policies to a telecommunications network, the telecommunications network comprising an loT device and a remote controller for communicating with the loT device, wherein the method comprises performance by the remote controller of the steps of: receiving a data stream from the loT device, the data stream comprising a plurality of communications; analysing each said communication to identify whether the communication is a malicious communication; and, in response to identifying that a communication is a malicious communication, selectively applying a security policy to the data stream containing communications generated by the loT device identified as malicious, wherein the security policy permits the loT device to continue to receive other data streams, that are not associated with the malicious communication.

Preferably, the security policy is applied to the loT device for only the data stream containing the communication identified as malicious, and within that data stream it may be applied only to an application from which the communication was sent. The method may apply the security policy to a node in the 5 telecommunication network that is adjacent the loT device. This node may be a gateway serving the loT device.

The security policy to be applied may be determined in dependence on: an input from a user; a characteristic of the loT device; and/or a characteristic of the communication identified as malicious, and may be an instruction to: cease traffic; throttle traffic; redirect traffic; envelope traffic; apply IPS; constrain the loT device; stop an application; and/or stop the loT device.

The loT device may be a network-enabled sensor, and the remote controller may be a network orchestrator, which may be cloud-based.

The invention also provides apparatus configured to perform the method according to the invention, a computer program element comprising computer program code to, when loaded into a computer system and executed thereon, cause the computer to perform the steps of the method, and /or a computer element comprising a hardware component to, when embedded into a computer system and executed thereon, cause the computer to perform the steps of the method.

The present invention provides an automatic response and remediation for devices in distributed networks using dynamic micro-segmentation to each application on the loT devices. This is achieved by analysing traffic to trace an attack back to identify a source loT device. This provides an ability to provide dynamic analysis of loT devices and applications to be able to act accordingly to threats on loT devices specific to each application.

Suitable analysis procedures to identify potentially compromised devices include searching for noisy traffic patterns, invalid payloads, unusual HTTP requests, and signatures. This allows the attack to be traced back to the source loT device so that a tailored security policy and remediation measure can be created for the specific application/device based on customer's security requirements, the profile of applications running on the device, device capabilities and network capability.

The preferred embodiment uses a signalling-based approach operating in the control plane, which allows the system to send remediation data upstream to all nodes in the network path to inform them of possible malicious attacks.

Embodiments of the invention provide monitoring and insight on functional and network behaviour of loT devices to determine when a malicious network or security attacks occur. This analysis helps to identify the exact origin and circumstance of the attack which allows for bespoke micro-segmentation to be provided on demand. The invention may be used on deployment of individual loT applications and in response to a malicious network or security attack occurs.

Microsegmentation divides networks into smaller networks, and allows application of traditional network security measures (e.g. firewalls) to those smaller networks to contain a threat. However, known micro-segmentation systems isolate entire devices or groups of devices, which can constrain the operation of functions on those devices not affected by the malware attack.

The present invention solves the issue of not having visibility of the full network by analysing and learning traffic and device behaviour patterns to recognise threats. In the event of an attack, embodiments of the invention learn more about the origin of the attack all the way through the network and is able to create and apply policies dynamically, without human intervention, close to the origin of the attack. By applying micro-segmentation to individual loT applications or data streams, instead of entire devices, a tailored solution can be provided for the specific application and data which is more efficient than applying micro-segmentation policies to the whole device and its network traffic.

An embodiment of the invention will now be described with reference to the drawings, in which: Figure 1 is a high-level schematic depicting the various cloud components which co-operate to perform the invention; Figure 2 is a schematic depicting the components in an loT device operating according to the invention; Figure 3 depicts the operation of the invention; Figure 4 is a flow diagram depicting the operation of the invention in the identification of a threat Figure 5 is a flow diagram depicting the operation of the invention in the process of taking remedial action when a threat has been identified.

The embodiment has two main components which operate, respectively, in the "Cloud", and physically on the loT device. The main functional elements of the invention are hosted in the cloud and are able to interact with a UTM Add-on component which is hosted on the loT device itself.

Figure 1 is a schematic of the functions hosted in the "Cloud". These will collectively be referred to as a cloud-based controller 1 although it will be understood that as this is a distributed system, the various components will be hosted on hardware at a number of different locations, which may change dynamically.

A security requirement store 10 is a facility provided to enable a user 101 of the system to submit a security level requirement for the existing loT infrastructure. The user can be presented with a display which provides, in graphical form, the infrastructure and applications available. The user can select security requirements for each loT device, or for each application run by a device. In this embodiment, by way of example, three different levels of security can be specified, and these inputs are used to select appropriate security measures for the microsegmentation policy.

An analyser function 11 operates to receive information from monitoring tools 110, 111 which monitor, respectively, the network, and the loT devices and infrastructure connected to the network. The network monitor 110 analyses traffic flows in/out, origin of traffic, HTTP response/request sizes, the number of requests, ports open, noisy traffic patterns, invalid attribute values, and a wide number of URLs, protocols, signatures, and payloads. The infrastructure monitor monitors the health and available resources of the devices e.g. CPU, RAM, storage, and which applications are running on it, and checks responses from loT devices and applications running on edge devices against those expected. The infrastructure analyser 111 can also be triggered by the Network Analyser 110 if the network analyser detects suspicious traffic or other indications of compromise.

For both types of analysis, the user's security requirement, as stored in the security requirement store 10, is taken into consideration to determine if the level of security present is adhering to the requirement.

The network analysis tools 110 may run on the device itself, or they may be hosted in the cloud, monitoring traffic information, but in either case the traffic information is picked up by the analyser component 11. The infrastructure analysis tool 111 runs on the device itself and reports back to the analyser 11 hosted in the Cloud.

Any suspicious behaviour patterns identified by the analyser 10 are reported to a Remediator function 12. The Remediator takes the inputs from the Analyser 11 and security requirement 10 to determine which action to take, for example to deploy a new policy closer to the attack, to apply an IPS signature to network security nodes, to block devices, to create VXLANS, or to block specified ports.

These actions can all form part of the micro-segmentation policy. The remediator creates new policies or amends existing ones and sends policies to an Orchestrator component 13 to deploy the policies accordingly.

A signalling approach can be used as a way to propagate the remediation actions by sending remediation data upstream to all devices on the path. Devices which have the loT UTM Add-On component (as will be discussed with reference to Figure 2) can access and apply the remediation actions and broadcast them out to multiple devices. For example, this can inform devices to redirect traffic to another location, or to block traffic from a specific IP address. To ensure the devices trust the messages they are signed by the remediator and can be further signed by other devices creating a chain of trust. This method works for security measures which are not specific to individual loT devices or applications.

The Orchestrator component 13 receives an action from the Remediator (e.g. a policy and a device) and translates the policy into a format acceptable by the existing UTM system used on the device. For example, this could be done by translating the policy into structured YAML format that the UTM will understand.

The Orchestrator determines the required format by consulting a Resource Store 14, which is a database that stores information regarding the loT infrastructure, such as security policies, the user security requirements received through the security requirement input 10, and significant results from the Analyser.

Figure 2 depicts an loT Device 2 configured to co-operate with the control system depicted in Figure 1.

In general loT devices are configured with one or more applications 20, 21 to monitor or control their environment, such as an application taking in temperature data from an loT sensor, transforming it and passing it on to another application or storage in the cloud, or an application taking an input from another application to operate an actuator. As depicted, a monitoring function 22 is also installed to monitor the functioning of the network, application and device.

The loT device is also provided with a communications interface 23 for connection to a communications network such as the "Internet". The connection may be wireless, or by a fixed connection.

Typically, loT devices also have an loT Unified Threat Management System 24 installed thereon. Such systems provide functions such as firewalls, antimalware, anti-virus, intrusion detection/prevention, virtual private networks and many others. They are usually virtualised and run directly on the device needing protection. Typically these functions are integrated into a single installation on the appliance, which provides multiple network and security functions. The UTM element 24 co-operates with a corresponding element 14 based in the cloud.

In embodiments of the invention, an additional loT UTM Add-On component 25 is provided which takes in messages from the cloud-based control system 1 and applies it to the existing loT UTM 20. The add-on component can apply policies such as: * Cease traffic * Throttle traffic * Redirect traffic * Envelope traffic (VXLAN or VPN) * Apply IPS * Constrain device * Stop application * Stop device Figure 3 is a high-level depiction of data flows when malicious or otherwise damaging software ("malware") enters the network. The dashed arrows signify the malicious traffic.

Initially, when an infected loT sensor 30 starts to spread malware (step 301) it may go undetected by one or more loT devices 2 because no policy is set in the device's UTM 24, for example because of resource restrictions on the individual loT devices 2. Consequently the malicious traffic is able to propagate further (step 302).

If no policy is already set in UTM functionality 14 in the cloud, the traffic will also be allowed at that level (step 303). However, the traffic is also monitored by the analyser 11 (step 304). The network Analyser 110 checks a number of indications of compromise (loC's) such as invalid attribute values, unusual HTTP request content, signatures, and the origin of an attack. The Infrastructure Analyser 111 checks which applications are running on the loT devices, and their expected output. This information is passed to the Remediator 12, which identifies that a new policy is required, or that an existing policy needs to be applied to one or more loT devices 2 identified as closer to the source 30 of the attack, and generates an instruction 305 to the orchestrator 13. The Orchestrator then transmits an instruction 306 to the UTM in the loT device 24 and its corresponding cloud based elements 14 to implement the new policy 16.

The process performed by the cloud-based control system 1 to recognise a threat and take remedial action is depicted in Figure 4. On detection of traffic 302 forwarded from the UTM 24 of an loT device 2, the analysis function 11 identifies any unusual traffic, such as anomalous data or high traffic volumes, and analyses it to determine whether it is symptomatic of a malicious attack (or other anomalous traffic which may be deleterious to the operation of the network) (step 41).

If it is determined that the anomalous traffic is potentially harmful to the network or other edge devices (loT sensors) connected to the network (411), it is referred to the Remediator 12 (step 412). Otherwise (410) the analyser resumes its monitoring function.

The Remediator 12 analyses the anomalous traffic, identifies a threat level and, by reference to data in the resource store relating to the requirements of security policies, and the capabilities and requirements of the devices and the applications running on the devices, generates a suitable policy to threat identified (step 42). The orchestrator 13 translates this policy into instructions to send to all loT devices closer to the origin 30 of the attack (step 43), in order to attempt to contain the anomalous and potentially damaging traffic. In the loT device 2, the UTM add-on 25 applies the policy in accordance with the instructions transmitted from the orchestrator 13.

The process may be repeated if, as a result of the implementation of the policy, the source of the attack can be identified more precisely, with more restrictive policies applied to a smaller group of loT devices, up to and including, in suitable 20 cases, shutting one or more devices down.

Figure 5 depicts a Remediation Signalling Flow in the process according to this embodiment of the invention. The malicious attack originates, or appears to originate, from a first loT device 2 and propagates through network nodes 26, 27 and further loT devices 28, 29 to the cloud-based system 1. The remediation message 306 generated by the orchestrator 13 is propagated back through the network 29, 28, 27, 26, 2, the policy 16 being implemented in all the devices and nodes in the chain which have the capability to apply remediation methods stated in the policy to protect itself.

Remediation policies may include: * Cease traffic * Throttle traffic * Redirect traffic * Envelope traffic (VXLAN or VPN) * Apply IPS * Constrain device * Stop application * Stop device The Remediation message may have the following attributes * ID * Source/Destination -address and port * Target content type * Target payload or regular expression * Schedule of mediation -forever, time-based, delayed * Remediation policies By dynamic application of micro-segmentation policies to loT applications, specific data streams and loT devices/gateways, embodiments of the invention allow automatic response and remediation of malicious attacks by dynamic analysis of traffic to trace the attack back to the source by looking for noisy traffic patterns, invalid payloads, unusual HTTP requests, signatures (an indication of compromise), and the creation of a tailored security policy for the specific application/device based on the users' security requirements. Remediation is applied in the form of security policies on all points along the network path, as close as possible to the origin of the attack, including downstream infected network nodes as well as loT sensors. The security policies can be configured to take into account application, device and network requirements and limitations.

Claims (13)

1. CLAIMS1. A method for applying security policies to a telecommunications network, the telecommunications network comprising an loT device and a remote controller for communicating with the loT device, wherein the method comprises performance by the remote controller of the steps of: receiving a data stream from the loT device, the data stream comprising a plurality of communications; analysing each said communication to identify whether the communication is a malicious communication; and, in response to identifying that a communication is a malicious communication, selectively applying a security policy to the data stream containing communications generated by the loT device identified as malicious, wherein the security policy permits the loT device to continue to receive other data streams, that are not associated with the malicious communication.
2. 2. A method according to any preceding claim, wherein the security policy is applied to the loT device for only the data stream containing the communication identified as malicious.
3. 3. A method according to any preceding claim, further comprising the step of applying the security policy to a node in the telecommunication network that is adjacent the loT device.
4. 4. A method according to Claim 2 or 3, when dependent on claim 2, wherein applying the security policy only to the data stream includes applying the security policy to an application from which the communication was sent.
5. 5. A method according to any preceding claim, further comprising the step of determining the security policy in dependence on: an input from a user: a characteristic of the loT device; and/or a characteristic of the communication identified as malicious.
6. 6. A method according to any preceding claim, wherein the security policy is an instruction to: cease traffic; throttle traffic; redirect traffic; envelope traffic; apply IPS; constrain the loT device; stop an application; and/or stop the loT device.
7. 7. A method according to any preceding claim, wherein the loT device is a network-enabled sensor.
8. 8. A method according to any preceding claim, wherein the remote controller is a network orchestrator
9. 9. A method according to Claim 8, wherein the remote controller is cloud-based.
10. 10. A method according to any of Claims 3 to 9, when dependent on Claim 3, wherein the node adjacent the loT device is a gateway serving the loT device.
11. 11. Apparatus configured to perform a method according to any of the preceding claims.
12. 12. A computer program element comprising computer program code to, when loaded into a computer system and executed thereon, cause the computer to perform the steps of a method as claimed in any of claims 1 to 10.
13. 13. A computer element comprising a hardware component to, when embedded into a computer system and executed thereon, cause the computer to perform the steps of a method as claimed in any of claims 1 to 10.