GB2572740A

GB2572740A - Autonomous countermeasure deployment

Info

Publication number: GB2572740A
Application number: GB1802199.8A
Authority: GB
Inventors: Watkins Giles; Taher Wael
Original assignee: Nanotego Ltd
Current assignee: Nanotego Ltd
Priority date: 2018-02-09
Filing date: 2018-02-09
Publication date: 2019-10-16
Also published as: GB201802199D0

Abstract

Autonomously selecting and deploying one or more countermeasures on a computing device based on identified patterns of activity. The identification process may involve comparing or correlating events 301 with predefined combinations of events, matching them against stored pattern and setting a flag 302, and may also involve setting a priority code 304 to indicate a priority of the detected pattern. This priority 304 may be combined with the flag 302 as part of the countermeasure determination process (Fig 8, 400). The process may also involve monitoring one or more data streams (Fig 6, 200) to identify predefined signals, including by micro-algorithms. Selecting a countermeasure may involve selecting a countermeasure code (Fig 8, 401) and comparing this with a predetermined list of countermeasure codes which may be a look-up table (Fig 8, 402) indicating which countermeasure to deploy. Once a countermeasure is deployed a watch process (Fig 9, 500) may be triggered to monitor the detected patterns (Fig 9, 501) and determine whether the countermeasure should be stopped (Fig 9, 505) or additional countermeasures should be deployed (Fig 9, 504).

Description

Autonomous Countermeasure Deployment

Field of the Invention

The present disclosure relates to a method of autonomously deploying countermeasures. In particular, the disclosure related to deploying such countermeasures local to a device.

Background

The Internet and other data communications technologies, such as Wi-Fi and Bluetooth, have enabled the widespread interconnection of computing devices. However, this widespread interconnection allows 'bad actors'to find and attempt to access computing devices and to undertake malicious activities such as: taking control of the device; using the device to gain access to another part of a computer network; exfiltrating data from the device; making data on the device unreadable; or making the device unavailable to authorized users.

Protecting computing devices from such 'bad actors' has become an increasingly difficult endeavour. Information Security specialists are mostly in 'catch-up' mode, i.e. racing to respond to new attacks. This is made harder by the continual evolution of software deployed on computing devices and the proliferation of such devices. Each development potentially opens up different ways for 'bad actors' to introduce malicious code onto the device, or to otherwise communicate with the device.

Typical approaches to the problem of keeping 'bad actors' out of computer systems and networks include:

a) Providing users of the device with 'identifiers', and the granting of 'permissions' to this identifier which are used to control what the user can or cannot do on the device. This is typically the domain of'access control'.

b) Providing the device itself with some sort of identifier to mark it as 'trusted' or not and use this to grant permission to communicate with the rest of the network. This is typically the domain of Network Access Control.

c) Monitoring the type of data being sent to/from a computing network and/or device and limiting such traffic to known and trusted types. This is typically the domain of 'firewall' technology.

d) Scanning files being sent to/from computing devices, and files stored within a device, for the appearance on of a set of computing code that is known to result in malicious behaviour.

This last example is generally known by the generic term 'anti-virus' and is extremely prevalent as a protective measure in today's computing environments. However, it relies entirely on the potentially malicious code already being known to be bad. This means that the developers of such systems can only enhance security when somebody finds new code that has done something malicious. This new code then needs to be added to a 'signature file' of malicious code by sending it to each device that requires protection. This introduces two flaws. Firstly, there is a period of time in which the device is no longer protected. Secondly, there is a dependence on communication between two, or more, computing devices.

Despite the existence, and continued development, of the above types of computer security mechanisms, there continues to be a proliferation of attacks on computer systems and subsequent data breaches. The existing solutions have been proven to be unable to provide adequate security against advanced threats. Once a computing device has been compromised, the attacker or malicious code quickly spreads across the network that the device is connected to, potentially compromising many other devices and often getting the attacker closer to a particular target. Advanced attackers are often able to defeat attempts to disrupt their activity through existing security tools by blocking their ability to communicate with the local asset, or by compromising the security tools deployed on the local asset, sometimes using them against the system they are supposed to be protecting.

Additionally, attackers often use advanced techniques to obfuscate their activity, rendering attempts to track down the source and mechanism of an attack ineffective. This obfuscation generally focusses on the logs of actions taken by a user ID, or manipulation of code either within the operating system, or of applications running on the device.

Current methods do not allow for the pro-active management of potential attacks in real-time. This problem is made significantly worse with the advent of vastly more complex networks of 'things', with potentially millions of 'assets' interconnected with each other. There is therefore, a need for a new approach to securing computing devices, particularly where they form part of a complex computing network containing valuable resources that may be the subject of advanced methods of intrusion and malicious activities.

Summary of the Invention

In a first aspect, the present invention provides a method of autonomously deploying countermeasures on a computing device, the method comprising: determining, on the computing device, one or more countermeasures to deploy, based on one or more patterns of activity identified on the device; and deploying, on the device, the one or more countermeasure, based on the determination.

In a second aspect, the present invention provides a method of autonomously deploying countermeasures in a computing device, the method comprising: identifying one or more patterns of activity by analysing data on the device, determining a countermeasure to launch in response to the identifying step; launching a countermeasure on the device.

In a third aspect, the present invention provides a computer program or suite of computer programs arranged, when executed, to perform the method of aspects one or two.

In a fourth aspect, the present invention provides a computer readable-medium, having stored thereon a computer program or suite of computer programs according to the third aspect.

In a fifth aspect, the present invention provides a computing device configured to perform the method of aspects one or two.

In a sixth aspect, the present invention provides a network comprising a plurality of computing devices according to the fifth aspect.

In a seventh aspect, the present invention provides a computing device configured to: determine, on the computing device, one or more countermeasures to deploy, based on one or more patterns of activity identified on the device; and deploy, on the device, the one or more countermeasure, based on the determination.

Other features and examples are provided in the accompanying claims.

Brief Description of the Drawings

The present invention will now be described by way of example only and with reference to the accompanying drawings, in which:

Figure 1 shows a computing device in accordance with an embodiment of the disclosure;

Figure 2 shows a network in accordance with an embodiment of the disclosure;

Figure 3 shows an event layer in accordance with an embodiment of the disclosure;

Figure 4 shows a correlation layer in accordance with an embodiment of the disclosure;

Figure 5 shows a countermeasures layer in accordance with an embodiment of the disclosure;

Figure 6 is a chart showing a method in accordance with an embodiment of the disclosure;

Figure 7 is a chart showing a method in accordance with an embodiment of the disclosure;

Figure 8 is a chart showing a method in accordance with an embodiment of the disclosure;

Figure 9 is a chart showing a method in accordance with an embodiment of the disclosure;

Figure 10 is a chart showing a method in accordance with an embodiment of the disclosure; and

Figure 11 is a schematic diagram of a computing device in accordance with an embodiment of the disclosure.

Detailed Description

Figure 1 shows a local computing device 100 in accordance with an embodiment of this disclosure. The computing device 100 may be any type of computing device, such as a mobile telephone, embedded device, Internet of Things-based device (such as a smart sensor), laptop or tablet etc. The local computing device 100 includes a countermeasures system 101 which is a software architecture stored on the device. The purpose of the countermeasures system 101 is to identify anomalous events on the device 100 which may be indicative of an attack being carried out on the device 100. While the countermeasures system 101 may communicate with components located externally to the device (as will be described in more detail below), the key components of the system are designed to work autonomously on the device without the need for any external input or output.

The countermeasures system 101 includes an event layer 102, a correlation layer 103, and a countermeasures layer 104. The event layer 102, the correlation layer 103 and the countermeasures layer 104 are the primary components of the system which are involved in the process of launching countermeasures locally to the device in response to the detection of anomalous events. In addition to these components, the countermeasures system 101 includes a governance engine 105. Further details of the governance engine 105 will be provided below.

The purpose of the countermeasures system 101 is to monitor data streams generated by system components such as: local applications, computer hardware or software components, input/output devices, malicious instructions or commands and system processes. By way of example only, Figure 1 shows three components that generate data streams.

These components are a device component 106A, a system processes component 106B and an application processes component 106C. Each of these components produces a data stream which is monitored by event layer 102. In addition to the above, data streams may be generated by other core system components, such as memory operations, communications operations, CPU operations, sub-process spawning, shell commands and battery usage.

The event layer 102 monitors these data streams and looks for anomalous data. This process will be described in more detail below. When the event layer 102 identifies an event, it communicates this to the correlation layer 103 via data stream 107. In order to avoid false positives, the correlation layer 103 monitors all of the events identified by event layer 102, in order to determine when a pattern of events is indicative of a potential threat to, or an attack on, the device 100. As will be described in further detail below, the correlation layer generates identifiers 108, priority codes 109, and flags 110. Each of these is provided to the countermeasures layer 104. The countermeasure layers 104 then determines what countermeasures to launch depending upon the information provided by the correlation layer 103. Further details of these processes will be defined below.

Each of the event layer 102, correlation layer 103 and countermeasures layer 104 utilise arrays and look-up tables, as will be described in further detail below. The governance engine 105 is arranged to maintain and update these arrays and tables using data path 111. The governance engine 105 is also arranged to communicate with an external device, such as a master console, by providing system activity data to the master console via connection 112, and to receive updates to apply to the arrays and look-up tables via connection 113.

Figure 2 shows the manner in which a local computing device 100 may be connected to a master console. The local computing device 100 is connected to a network 114 via a suitable data connection. For example, this data connection may be a wireless data connection such as Wi-fi or mobile communications, or may be a wired connection. A master console 115 is connected to the same network 114 via another suitable data connection. The master console is arranged to receive status data 116 from a plurality of devices that may be connected to the network 114. It also provides configuration data 117 which again may be provided to one or more local devices.

In this embodiment, although a data connection is provided, is should be noted that the operation of the system does not require an ongoing data connection. The process of identifying malicious activity, determining what countermeasures to deploy, and deploying countermeasures, may all be done without use of, or requirement for, an ongoing data connection. In some embodiments, the master console is not required for operation. However, a data connection may be used to update information on the device, or as an input to the countermeasures deployment system. For example, a threat detected by the network may result in a change to the security posture, which could lead to policies being fed into a device so that a device can adapt its local countermeasures deployment strategy.

Figure 3 shows further details of the event layer 102. The event layer 102 monitors data streams generated by a number of operations and processes located on the local computing device 100. For example, in Figure 3, the event layer 102 monitors memory operations 118A, I/O devices 118B, comms 118C, CPU operations 118D and sub-process spawning 118E. These data streams are monitored by microalgorithms. A micro-algorithm is a piece of code arranged to monitor or analyse data. For example, it may be a monitoring process, arranged to generate a flag when a particular event is detected, such as a microphone being turned on. Alternatively, it may monitor computing instructions or commands in order to identify those which are synonymous with hacker activity. In this respect, analysis may be required to determine if a particular term should generate a flag. This analysis may involve reference to look-up tables, filtering noise from a data stream or Artificial Intelligence (A.I.) routines.

As noted above, although the system is intended to operate locally and autonomously using data analysis undertaken on the device, by the countermeasures system, the system may take data from other sources, either internal to the device, or external to it. For example, there may be third party process operating on the device which can provide the countermeasures system with additional anomalous data that may be indicative of malicious activity. Additionally, a third party network-based server may provide data to the device regarding system-wide attacks.

Figure 3 shows micro-algorithms 119A to 119E, which are each dedicated to respective data streams 118A to 118E. The micro-algorithms analyse the data streams in order to identify events or anomalous data that are indicative of malicious activity that might suggest an attack on the device. For example, in Figure 3, anomalous data 120 is present on data stream 118E. The event layer 102 also includes a look-up table 121. Each micro-algorithm has its own sub-routine which references pre-defined values in the look-up table 121 that are used to analyse each data stream in real time in order to identify anomalous values. The values provided in the look-up table 121 are based on information regarding how malicious attacks are perpetrated, the system level behaviour that they initiate and the risk tolerance of the organisation administering the device. In the example shown in Figure 3, micro-algorithm 119E identifies event 120 and generates event notification 122. The event notification 122 is then provided to the correlation layer 103. The event notifications are generated by each micro-algorithm independently from the other micro-algorithms. Micro-algorithms operate autonomously in real time on the local computing device 100, without the need for any communication to other computing environments, without the need to create reference or manipulate log files or signature files. Each micro-algorithm operates autonomously within the working memory of the local computing device, and if one microalgorithm is stopped, this will have no impact on the other micro-algorithms. As noted above, a micro-algorithm may monitor a particular piece of hardware, such as a microphone. When the microphone is turned on, the micro-algorithm detects this event, and notifies the next stage of the system. The mirco-algorithms may also look for signals in the data streams. For example, the mirco-algorithm may perform some processing on a data stream to filter out noise and identity the 'signal'. Alternatively, the 'signal' might be really easy to identify with a simple comparison to a lookup table.

The micro-algorithms 119A to 119E regularly signal the governance engine 105 to inform it that they are continuing to run. If a micro-algorithm does not signal the governance engine 105, the governance engine 105 would identify this as a potentially harmful event, and this could also be fed into the correlation layer 103.

Further details of the correlation layer 103 are shown in Figure 4. The correlation layer 103 is the first stage in the architecture at which decisions are made about whether or not suspicious activity should be acted upon. In particular, the correlation layer provides the first phase of system-wide correlation based on the notifications generated in the event layer 102. By system-wide, we mean the computer programs (applications, operating system, kernel and BIOS) and infrastructure operating within the local computing device 100. Here, the events identified by the event layer 102 are matched to known patterns reflecting malicious activity. The correlation layer 103 includes an event correlator 123 which receives event notifications 122A, 122B and 122C. The event correlator 123 produces an event signal 124 indicating that the particular pattern of ongoing events appears to be suspicious. An event array 125 then generates a flag 126 when particular patterns of events are identified. The patterns of events and the contents of the array are based on the known methods of'attack' and the underlying infrastructure level signals that they produce. These methods and behaviours vary from time to time. Somebody skilled in the art of attacker techniques would be able to identify the patterns of events which might be indicative of attacker behaviour. For example, if the micro-algorithms have identified an event which suggests a particular hardware components has been switched on, combined with an event which suggests suspicious instructions or commands have been used, then the correlator could determine this to be indicative of an attack taking place.

Whenever a flag 126 is generated, it is given a unique identifier. This is because a particular flag may be generated numerous times over a particular time period. The identifier is to distinguish between different instances of the same flag. The flag identifiers can also be used for traceability and for reporting in the master console. Finally, a priority module 127 generates a priority code 128 which is appended to the flag 126. The priority codes may be maintained in a look-up table, and are based on the risk appetite of the organisation that has configured the computing device 100. Changes to the priority codes may be managed by the governance engine 105 based on the policy objectives contained within the governance engine 105. Again, these may be configurable by the organisation that maintains the device. The countermeasures layer 104 then receives the flags 126 and the priority codes 128. The countermeasures layer 104 includes a countermeasures correlation array 129. The countermeasures correlation array 129 matches the flags and priority codes to produce a countermeasures code 130. The countermeasures code 130 is fed to a countermeasures look-up table 131 in order to determine a particular action to be initiated. Possible countermeasures are numerous, and depend on the particular computing environment and use-case, however they could typically include providing a warning to a user, shutting down a malicious process, creating diversionary activity or shutting down the local computing device.

The contents of the countermeasures look-up table 131 are based on attacker methods and the most effective protective measures to take against certain system behaviours. Again, as attacker behaviour varies over time, the precise contents of this table will also vary over time. The countermeasures look-up table 131 then provides notification 132 to a countermeasures launcher 133. The countermeasures launcher launches the appropriate countermeasure via notification 134. Each countermeasure will have a piece of code associated with it that will enact the actual response (i.e. shut down a process etc.). There are various options for achieving this. For example, the code could actually be in the array or the array will contain a pointer to the actual location of the code. An instruction will then be sent to process that particular countermeasure program script.

The countermeasures layer 104 also launches a watch process 135. The watch process takes as its input the flags 126, priority codes 128 and the output of the countermeasures launcher 134. The watch process monitors for reoccurrence of the original flags and priority codes. If the flags and priority codes recur within a predetermined time period, the watch process 135 may amend the priority code via array notification 136 so that the countermeasures correlation array 129 escalates the response of the countermeasure layer 104 so that a more drastic countermeasure may be launched by the countermeasure launcher 133. If the watch process 135 confirms that the malicious activity has been terminated, for example, by non-re-occurrence of the original flag and priority code within a predetermined time period, then a de-escalation process may be initiated. The manner in which de-escalation is handled may depend on a further correlation array which may match with a series of de-escalation scripts. A de-escalation script may, for example, remove a countermeasure, or the most recent countermeasure. The de-escalation process may be the reverse of the escalation process.

All countermeasure codes and data from the watch process are also sent to the governance engine 105 via governance engine notification 137 where this information can be stored for analysis at a later date, or forwarded to a master console.

The local governance engine 105 enables user interaction with the local computing device 100 and enables the autonomous local code to be tuned to reflect a particular organisation's security posture and the requirements of the local environment and use-case.

The governance engine 105 allows the tolerance levels and countermeasure priorities within the countermeasures system to be set based on the individual security posture and risk appetite of the organisation. These updates are managed via local objective files that will contain information that can be used to update the correlation arrays and look-up tables on the local computing devices. This design allows each individual device to have its own distinct objectives, or for multiple devices to be allocated group objectives (for example, devices representing a particular business function, or operating within a particular geographic area). Local objectives can be set or updated by direct user interaction, or by instructions from a master console. The governance engine 105 also monitors all events, flags and launch countermeasures. It also reports local activity to a master console, if one is deployed.

Various methods of operation of the device will now be described with reference to the following Figures.

Figure 6 is a chart showing a method of operation of the event layer 102. In a first step 200, the event layer 102 monitors data streams for anonymous data. At step 201, anonymous data is detected by one of the micro-algorithms. The microalgorithm compares this data with the look-up table in step 202, and if there is a match, generates an event notification in step 203.

Figure 7 is a chart showing a method of operation of the correlation layer 103.

The correlation layer 103 receives event notifications at the event correlator 123 (step 300). The event correlator 123 correlates the events at step 301. Based on the output of the event correlator 123, the event array 125 generates a flag 126 in step 302. In order to distinguish between specific flags generated at different points in time, each flag is assigned an identifier in step 303. The priority module 127 then allocates a priority code to each flag in step 304.

Figure 8 shows a chart showing a method of operation of the countermeasures layer 104. The countermeasures array 129 receives the flags 126 and the priority codes 128 (step 400). At step 401, the countermeasures array selects countermeasures codes which are passed to the countermeasures look-up table 131. The countermeasures look-up table determines the necessary countermeasures at step 402. The countermeasures launcher 133 launches the relevant countermeasures script at step 403.

Figure 9 shows the method of operation of the watch process 135. After a countermeasure has been launched, the watch process is launched (step 500). The watch process monitors the flags and priority codes generated by the correlation layer 103 (step 501). At step 502, the watch process monitors for occurrence of the same flags within a predetermined period. If a flag recurs within the predetermined period, the watch process amends the priority code at step 503. The countermeasures launch at 133 then launches new countermeasures based on the revised priority claim (step 504). In the event that the same flag does not recur within the predetermined period, the watch process runs a deescalation script 505. This may be a case of ceasing all current countermeasures, or alternatively the countermeasures may be scaled back slowly. The watch process may continue to monitor for further changes to the flags during this period.

Figure 10 shows a chart showing the overall operation of the countermeasures system 101 in accordance with an embodiment of the disclosure. At step 600, the required countermeasures are determined. At step 601, the relevant countermeasures are deployed.

An advantage of the above-described system is that malicious activity is detected on the device, locally and autonomously, based on behaviour patterns. Antivirus software detects malicious code based on a priori knowledge of the code. As such, to be effective, antivirus software has to be regularly updated with the latest threats. In contrast, because the present system operates based on behavioural characteristics, it is not necessary to regularly update the system, or even update it at all. However, it is possible in some embodiments to provide examples of new behavioural characteristics, in embodiments where the devices may be connected to the master console.

Claims

1. A method of autonomously deploying countermeasures on a computing device, the method comprising:

determining, on the computing device, one or more countermeasures to deploy, based on one or more patterns of activity identified on the device; and deploying, on the device, the one or more countermeasure, based on the determination.

2. A method according to claim 1, further comprising:

prior to the step of determining, identifying the one or more patterns of activity on the device, based on one or more events detected on the device.

3. A method according to claim 2, wherein said step of identifying one or more patterns of activity comprises:

comparing, on the device, the one or more events with predefined combinations of events, and in the event of a match, generating, on the device, a flag indicative of the patter of activity.

4. A method according to claim 3, wherein the step of comparing comprises correlating the one or more events, and the step of matching comprises matching the result of the correlation to the predefined combinations of events.

5. A method according to claim 3, further comprising:

after a flag has been generated, generating a priority code to indicate a priority of one or more patterns of activity.

6. A method according to claim 5, wherein the step of determining which countermeasure to deploy is based on the flag and/or the priority code.

7. A method according to any preceding claim, further comprising:

prior to the step of determining which countermeasure to deploy, detecting one or more events one the device.

8. A method according to claim 7, wherein the step of detecting one or more events comprises, monitoring one or more data streams generated by one or more system components on the device.

9. A method according to claim 8, wherein the step of monitoring comprises processing the data streams to identify predefined signals.

10. A method according to claims 7 or 8, wherein the step of detecting events is done by one or more micro-algorithms.

11. A method according to any preceding claim, further comprising:

selecting a countermeasures code, on the device, in response to the identified one or more patterns of activity; wherein the step of determining which countermeasures is based on the at least one countermeasures code.

12. A method according to claim 11, wherein the step of determining which countermeasure to deploy comprises:

comparing the countermeasure code with a predetermined list of countermeasures codes, the list indicating which countermeasure to deploy.

13 A method according to claim 12, wherein the list of countermeasures codes is maintained as a look-up table on the device.

14. A method according to any preceding claim, further comprising:

starting a watch process, on the device, in response to deployment of at least one countermeasure, the watch process configured to monitor the one or more patterns of activity.

15. A method according to claim 14, wherein the watch process is configured to: stop the one or more countermeasures if the one or more patterns of activity stop within a predetermined time period.

16. A method according to claim 14, wherein the watch process is configured to: determine, on the computing device, one or more additional countermeasures to deploy, if the one or more patterns of activity identified on the device continue after a predetermined time period; wherein the method further comprises:

deploying, on the device, the one or more additional countermeasures, based on the determination.

17. A method according to claim 16, further comprising:

generating at least one additional countermeasures code, in response to the one or more patterns of activity identified on the device continuing after the predetermined time period.

18. A method according to any preceding claim, wherein the step of determining is done using a look-up table or array located on the device.

19. A method according to any preceding claim, wherein the method is carried out without communicating with any other device.

20. A method according to any of claims 1 to 19, further comprising: determining, on the computing device, one or more countermeasures to deploy, based on a notification received from a third party source; and deploying, on the device, the one or more countermeasures, based on the determination.

21. A method according to claim 20, wherein the third party source may be one or more of: a source external to the device, or a source on the device external to the system performing the steps of determining and deploying.

22. A method according to any preceding claim, wherein the countermeasure may be one or more of: a warning to a user, shutting down a process, creating a diversionary activity or shutting down the local computing device.

23. A method of autonomously deploying countermeasures in a computing device, the method comprising: identifying one or more patterns of activity by analysing data on the device, determining a countermeasure to launch in response to the identifying step; launching a countermeasure on the device.

24. A computer program or suite of computer programs arranged, when executed, to perform the method of claim of claims 1 to 23.

25. A computer readable-medium, having stored thereon a computer program or suite of computer programs according to claim 24.

26. A computing device configured to perform the method of any of claims 1 to 23.

27. A network comprising a plurality of computing devices according to claim 26.

28. A network according to claim 27, further comprising a master console, wherein the computing devices are arranged to communicate with the master console, and the master console is configured to provide the computing devices with configuration data.

29. A network according to claim 28, wherein the configuration data may be one or more of: look-up table updates, array updates and priority code updates.

30. A computing device configured to: determine, on the computing device, one or more countermeasures to deploy, based on one or more patterns of activity identified on the device; and deploy, on the device, the one or more countermeasure, based on the determination.

31. A computing device according to claim 30, further comprising:

a countermeasures correlation array, configured to generate at least one countermeasures code, in response to one or more detected patterns of activity;

a countermeasures lookup table comprising data correlating countermeasures codes and countermeasures, wherein the device is configured to use the lookup table to determine what countermeasures to deploy, based on the at least one countermeasures code;

a countermeasures deployment module configured to deploy at least one countermeasure, based on the determination.