Patent ID: 12225032

SPECIFIC DESCRIPTION

FIG.1shows an Internet of Things (IoT) network100in the normal course of operation.

The network100comprises: a plurality of IoT devices110; a plurality of network nodes120; and a Cloud system130. The IoT devices110and the network nodes120are individually referred to as a network entity.

The plurality of IoT devices comprises: a first110-1, second110-2, third110-3and fourth110-4IoT device. Each of the IoT devices110is configured to communicate with at least one of the plurality of network nodes120.

The plurality of network nodes120comprises a first120-1and a second120-2network node. The network nodes120are, for example, in the form of a network gateway.

Each of the network entities110comprises an application112for facilitating the intended function of the network entity (e.g. recording measurements from a sensor in the case of an IoT device110, controlling a wireless network transceiver, etc.), and a Network Entity Unified Threat Manager (UTM)114.

The Network Entity UTM114system is configured to provide and/or facilitate security services for a network entity. Generally, a UTM is part of or forms a/an: firewall; anti-malware and/or anti-virus service; intrusion detection and/or prevention system; and/or virtual private networking interface. UTMs (including the Network Entity UTM114) are available to be in the form of a virtualised hardware component that operates wholly locally (e.g. on an IoT device) or as an agent that is remotely managed by another system, such as by the Cloud system (and in particular the Cloud UTM, which is described below).

The Cloud system130comprises, at least, a/an: Cloud UTM130-1; Security Input Interface130-2; Security Analyser130-3; Orchestrator130-4; and a Remediator130-5. The constituent components of the Cloud system130are described in more detail below. The Cloud system130is a distributed computing system, the various components of which are available to be hosted on various different networked hardware (which may change dynamically) at a number of different locations.

InFIG.1, each of the IoT devices110and the network nodes are in a normal operating state; that is, operating in the absence of any anomalous traffic, such as due to a malicious network attack or faults. The IoT devices110communicate data (such as sensor data) to the Cloud system130, and in the example ofFIG.1this is performed via the following routes (as indicated via solid lines): the first IoT device communicates to a first network node120-1, which in turn communicates with the second IoT device110-2; the second IoT device110-2communicates with a second network node120-2; the third110-3and fourth110-4IoT devices also communicate with the second network node120-2; and the second network node then communicates with the Cloud system130.

FIG.2shows a pathway (as indicated via dashed lines) of an anomalous communication within the network100; unbeknownst to an operator or user of the network100, the anomalous communication originates from the fourth110-4IoT device which has been compromised due to a malicious attack or a fault; this anomalous communication is then propagated in the following sequence, to the: second IoT device110-2; first network node120-1; first IoT device110-1; third IoT device110-3; second network node120-2; and Cloud system130.

FIG.3shows a process300for analysing the anomalous network traffic within the network1100so as to develop a full signature of the anomalous communication, and thereby to apply an appropriate security policy to remediate the anomalous communication, its effects and/or its cause. Process300is now described in combination withFIGS.1and2.

In a first step310in process300, the Security Analyser130-3receives a communication from the network100; this communication is analysed by the Security Analyser130-3, which identifies the communication to be an anomalous communication. To make this determination, the Security Analyser130-3comprises (albeit not shown inFIGS.1and2for conciseness) a network analyser and device analyser.

The network analyser is configured specifically to analyse operational characteristics of the network100, such as: traffic flows; originating addresses of traffic; HTTP response and/or request sizes; numbers of requests; port information; noisy traffic patterns; invalid attribute values; URLs; communication protocols; and payload data. The device analyser is configured to analyse the operational performance of the network entities themselves, and in particular CPU and RAM usage. In this way, the network analyser and the device analyser are configured to monitor the network100and the network entities so as to identify occurrences of anomalous communications. The Security Analyser130-3also comprises an anomaly signature builder (also not shown inFIGS.1and2). In response to identifying an anomalous communication, the anomaly signature builder compiles information that has been analysed by the network analyser and/or the device analyser relating to the anomalous communication, thereby to help develop a signature of the anomalous communication.

In process300, the information compiled by the network analyser and/or the device analyser concerning the anomalous communication is insufficient to develop a full signature of the anomalous communication, and only an incomplete signature is generated at this stage by the anomaly signature builder. The incomplete signature comprises only information from the network entity from which the anomalous communication was directly received by the Cloud system130(herein referred to as the “closest network entity”). The incomplete signature does not, however, comprise information relating to, at least, the origin within the network100of the anomalous communication. In the example ofFIG.2, the anomalous communication is received by the Cloud system130from the second network node120-2, which is therefore identified by the Security Analyser130-3as the closest network entity.

In order for an effective security policy to be applied to the network100, the Cloud system (specifically the Remediator130-4, as described in more detail below) requires an adequate signature of the anomalous communication.

To this end, at a next step320, the Security Analyser130-3instructs the Orchestrator130-5to communicate a push-back message to the closest network entity that was identified at preceding step310. As shown inFIG.2, the push-back message of step320is communicated from the Cloud system130to the second network node120-2(as indicated via a dotted line).

The push-back message is an instruction for a receiving network entity (i.e. the closest network entity at step320) to retrieve from its memory historical information associated with the anomalous communication identified at step310. The historical information includes information that allows identification of, at least, the network entity from which the anomalous communication was directly received and/or information to help develop the signature associated with the anomalous communication. For example, the historical information includes a: traffic type; network address (e.g. IP address); protocol type; port number; and/or pattern information.

In response to receiving the push-back message from the Orchestrator130-5, at step330, the Network Entity UTM114of the closest network entity instructs local retrieval of the historical information associated with the anomalous communication, and then forwards said historical information to the Security Analyser130-3.

At a next step340, the historical information that is received by the Security Analyser130-3from preceding step330is analysed by the Security Analyser (and specifically by the network analyser and the device analyser), and the results of this analysis are forwarded to the anomaly signature builder so as add to the signature any new information that characterises the anomalous communication.

Once the signature has been updated at step340, the anomaly signature builder assess whether the updated signature is now sufficiently complete so as to allow effective remediation of the anomalous communication and/or its cause. In one example, the signature is determined to be complete if, in relation to a true source of the anomalous communication, it comprises: an identifier for the exact source; a protocol; a type of data; an identifier of an application that initialised the anomalous communication; a frequency with which the anomalous communication is sent; and/or a list of other network entities through which the anomalous communication has traversed.

If the signature is determined at step350to be complete, then the Security Analyser130-3communicates the complete signature to the Remediator130-4at a next step360. Following step360, at a next step370, the Remediator130-4, in dependence on the complete signature, determines a tailored security response for countering the anomalous communication and/or its cause. The security policy is also determined by a security level for the network, which is configured by a user or an operator of the network100by means of inputs to the Security Input Interface130-2. The security policy is available to remediate the threat of the anomalous communication, for example by applying (not least by means of a given Network Entity UTM) a policy to:control a network entity, such as;shutting down a network entity; andlimiting processing resources of a network entity;control traffic to and/or from a network entity, such as by:ceasing traffic, including closing a port of a network entity, performing IP address blocking or applying other blocking techniques;throttling traffic;redirecting traffic;enveloping traffic, for example by means of a VXLAN or a VPN; and/orcontrol an application loaded on a network entity, such as:patching the application;terminating the application; and/orapply IPS signatures.

Accordingly, the Remediator130-4instructs the Orchestrator130-5to implement the determined security policy to the network, and the Orchestrator translates the security policy into an instruction (e.g. into a structured YAML format) for the Cloud UTM130-1to cause, by means of an appropriate communication, the Network Entity UTM114of the appropriate network entity (or entities) to implement the security policy.

If, however, the signature is determined at step350still to be incomplete, in a first iteration of step380, based on the historical information received at immediately-preceding step330, the Security Analyser identifies a network entity from which the closest network entity received the anomalous communication (herein referred to as the “next closest network entity”). Accordingly, the Security Analyser130-3instructs the Orchestrator130-5to send a further push-back message to this next closest network entity. In the example ofFIG.2, at this point in process300, the next closest network entity is the third IoT device110-3, accordingly the Orchestrator sends a push-back message to the third IoT device110-3(again, as indicated via a dotted line).

In response to the push-back message, at step390(and in a corresponding manner to step330) the Network Entity UTM of the next closest network entity retrieves historical information relating to the anomalous communication and reports the retrieved historical information to the Security Analyser130-3.

At this point, process300reiterates to step340such that the Security Analyser analyses the historical information from the next closest network entity received from immediately preceding step390.

In this way, it can be seen that process300will continue to reiterate until a complete signature is generated from historical information compiled in response to the push-back messages that are issued along the entire pathway (in reverse) of the anomalous communication.

In the example ofFIG.2therefore, process300will reiterate such that the historical information retrieved from the third IoT110-3indicates that only an incomplete signature is attainable, and identifies its next closest network entity as the first IoT device110-1. In a corresponding way, the first IoT device110-1allows the Security Analyser to identify the first network node120-1as its next closest network entity, and so on until the Security Analyser identifies the source of the anomalous communication as the fourth IoT device110-4, thereby compiling sufficient information relating to the anomalous communication so as to generated a completed signature.

As per steps360and370, the Remediator130-4applies a security policy to, at least, the fourth IoT device110-4, thereby to remediate the source of the anomalous communication, which has been compromised Each feature disclosed herein, and (where appropriate) as part of the claims and drawings may be provided independently or in any appropriate combination.

Any reference numerals appearing in the claims are for illustration only and shall not limit the scope of the claims.