System and method for anomaly detection in communications

Abstract

A computer-implemented method of anomaly detection. A log of one or more series of events is obtained, and the frequency of events within the log is determined 410. A graph representing patterns of ev

Description

TECHNICAL FIELD Embodiments of the invention relate to methods and systems for generating finite state machines for use in anomaly detection. Further embodiments relate to methods and systems for anomaly detection using finite state machines. BACKGROUND For important (e.g. safety-critical or sensitive) communication systems, it can sometimes be necessary to analyse communications to determine whether any anomalous activity is occurring. Anomalous activity may include intrusion from external malicious entities, technical systems failures, or rogue activity from a user. Accordingly, anomaly detection is useful as it can be applied to security or health monitoring of systems. Manual methods could be applied. These involve determining, through knowledge of the system, certain “signatures” that may represent undesired behaviour. However, these are time consuming and require access to knowledge and expertise which is not always readily available on these systems (especially for safety critical systems where such information can be kept as proprietary by third-party suppliers). A brute force solution such as storing all possibilities for normal behaviour could be tried in theory. However, this is computationally expensive and unlikely to be practical except on the most basic of systems. Even then, it results in a large amount of redundant or superfluous data needing to be stored on the target system. Accordingly, some anomaly detection systems can require significant processing power and memory, which increases cost, weight and power consumption. SUMMARY Embodiments described herein are directed towards an efficient anomaly detection system which can be implemented with a reduced computational burden and power consumption. This allows the anomaly detection system to be implemented in systems where processing power and / or power consumption may be limited. For instance, weight and power are often significant factors when it comes to designing systems for use on airborne platforms (e.g. planes, helicopters, drones, etc.). By providing an anomaly detection system that can be implemented with lower computing and power requirements, the system can be implemented with lighter hardware, thereby allowing implementation on airborne platforms. Having said this, the embodiments described herein are not limited to use on airborne platforms. It will be appreciated that the benefits anomaly detection with reduced computational and power requirements can equally be utilized to a variety of different applications. According to a first aspect there is provided a computer-implemented method comprising: obtaining a log of one or more series of events; determining the frequency of events within the log; generating a graph representing patterns of events within the log based on the frequency of events, wherein the graph includes nodes representing events and edges representing transitions between events; pruning the graph to remove edges that have less than a minimum conviction, wherein conviction indicates the strength of dependence between grouped events; and determining a finite state machine from the graph, wherein the finite state machine models valid paths through the graph and for use in determining anomalous series of events. According to an embodiment, generating the graph includes connecting nodes for each group of sequential events that have more than a threshold support, wherein the threshold is lower for less frequent events. According to an embodiment, the threshold may be lower when a minimum out of the frequencies for each event in the group of sequential events is below a threshold frequency. According to an embodiment, support for a particular pattern (or set) of N events represents the frequency of occurrence of the pattern (or set) of N events as a ratio relative to the total number of N event patterns (or sets), wherein N is an integer greater than or equal to one. According to an embodiment, connecting nodes for each group of sequential events that have more than a threshold support, wherein the threshold is lower for less frequent events, comprises, for events having a frequency within a first frequency range, applying a first support threshold, and for events having a frequency within a second frequency range, applying a second support threshold, wherein the first frequency range is lower than the second frequency range, and wherein the first support threshold is lower than the second support threshold. According to an embodiment, pruning the graph comprises determining a conviction for each edge in the graph, and removing each edge that has a conviction that is less than the minimum conviction. According to an embodiment, determining conviction comprises determining: 1 — support(Y') conviction(X -> Y) =------------777---77- support(X -> Y) support(X) wherein conviction(X -> Y) is the conviction for an edge representing a transition from event X to event Y; support^) is the support for event support(X) is the support for event X; support(X -> Y) is the support for the transition from event X to event Y. According to an embodiment, determining the finite state machine from the graph comprises: determining each potential path across the pruned graph from root to leaf; identifying valid paths within the potential paths based on matches with training data; and forming the finite state machine from the valid paths, the finite state machine including valid states and valid state transitions. According to an embodiment, the method further comprises: analysing a further series of events within a computing system using the finite state machine to determine whether any anomalies occur. According to an embodiment, the analysing comprises: determining one or more state transitions representing the further series of events; comparing the determined one or more state transitions with the finite state machine to determine if the determined one or more state transitions matches any valid sequence of one or more state transitions; and, in response to determining that at least a subset of the determined one or more state transitions does not match any valid sequence of one or more state transitions, determining that the further series of events includes an anomaly. According to an embodiment, the analysing further comprises, for any determined state transition that matches a valid state transition: comparing a timing for the determined state transition against a predefined time range associated with the valid state transition; and in response to the timing for the determine state transition not falling within the predefined time range, determining the determined state transition relates to an anomaly. According to an embodiment, the method further comprises, in response to determining the occurrence of at least one anomaly, outputting an alert. According to an embodiment, the events represent communications exchanged between computing systems. According to a further aspect there is provided a computer-implemented method for detecting anomalous series of events, the method comprising analysing a series of events within a computing system using a finite state machine determined according to any of the above methods to determine whether any anomalies occur. According to an embodiment, the analysing comprises: determining one or more state transitions representing the further series of events; comparing the determined one or more state transitions with the finite state machine to determine if the determined one or more state transitions matches any valid sequence of one or more state transitions; and, in response to determining that at least a subset of the determined one or more state transitions does not match any valid sequence of one or more state transitions, determining that the further series of events includes an anomaly. According to an embodiment, the analysing further comprises, for any determined state transition that matches a valid state transition: comparing a timing for the determined state transition against a predefined time range associated with the valid state transition; and in response to the timing for the determine state transition not falling within the predefined time range, determining the determined state transition relates to an anomaly. According to an embodiment, the method further comprises, in response to determining the occurrence of at least one anomaly, outputting an alert. According to a further aspect there is provided a computing system comprising a processor configured to implement the any of the above methods. According to an embodiment, the computing system further comprises: an interface for connecting directly to an aerial vehicle for monitoring events within the aerial vehicle; and a processor configured to implement an anomaly detection method according to one of the embodiments described here, wherein the series of events are events within the aerial vehicle. According to an embodiment, the events relate to communications between the aerial vehicle and another device. According to a further embodiment there is provided an aerial vehicle comprising a computing system as described herein. BRIEF DESCRIPTION OF THE FIGURES Arrangements of the present invention will be understood and appreciated more fully from the following detailed description, made by way of example only and taken in conjunction with the following drawings. FIG. 1 shows a computing system according to an embodiment. FIG. 2 shows a finite state machine (or finite automata) according to an embodiment. FIG. 3 shows an overall method for generating a finite state machine for anomaly detection. FIG. 4 shows a method for generating a finite state machine for anomaly detection according to an embodiment, including modifications for improved performance. FIG. 5 shows an example of a tree before and after pruning. FIG. 6 shows a method for generating a temporal automata. FIG. 7 shows a method for identifying abnormalities within a series of events. FIG. 8 shows a system for detecting anomalous events. DETAILED DESCRIPTION Frequent Pattern (FP) Growth and automata theory are techniques used for anomaly detection, in the identification of unintended or unusual behaviour changes in the operations of a system. Embodiments described herein apply modified versions of FP-Growth and automata theory to the detection of anomalous behaviour in embedded systems. The methods described herein involve analysing patterns of occurrences of transitions between states in the system. The patterns that are statistically significant are built into finite state machines (otherwise known as finite automata) based on the order and / or timing of those transitions. This allows for the detection of a change in behaviour of the system as anomalous timing or transition though comparison with the automata model. Particular embodiments include techniques for reducing the size of the automata model to allow it to be stored and run on systems with reduced computing and memory resources. For instance, certain embodiments adopt conviction as a metric for pruning the generated trees before conversion into finite state machines. This helps to remove links between states which are not strongly correlated with each other, thereby allowing the size of the model to be reduced without compromising accuracy. Potential applications include intrusion detection and / or predictive maintenance in realtime on low size, weight and power (low-SWaP) systems. That is, the methods 7 described herein are to allow implementation on systems with constraints on resources. FIG. 1 shows a computing system according to an embodiment. The computing system includes a first device 100 configured to communicate with a second device 110 through a network 115 (such as a wired and / or wireless network). It will be appreciated that whilst only two devices and one network are shown, the first device 100 may communicate with any number of devices, through any number of networks. The first device 100 comprises a communication module 120, an anomaly detection module 130, memory 140, a network interface 150, and a bus 160. The bus 160 connects the various components of the first communication device 100 to each other. Optionally, the first device 100 may comprise an I / O interface 160. The communication module 120 is configured to allow the first device 100 to send and receive messages via the network interface 150. A user may control the first device 100 through input commands. This may be through the network interface 150, for remote control of the first device 100, or through the I / O interface 160, for local control of the first device 100. In any case, the first device 100 is configured to send messages and receive messages either through the network interface 150 or the I / O interface 170. The anomaly detection module 130 is configured to monitor the messages transmitted and received by the first device 100 in order to detect anomalous behaviour. Whilst the anomaly detection module 130 is shown in this embodiment to be monitoring messages between the first device 100 and the second device 115, alternative embodiments monitor messages between two external devices. For instance, the first device 100 may monitor communications between the second device 110 and a third device 112. Furthermore, whilst the second device 110 and third device 112 are shown to be connected to the first device 100 and to each other via a network 115, these one or more of these devices may alternatively be directly connected to each other (e.g. via one or more communications buses). In addition, whilst the present embodiment is described with reference to monitoring communications between devices, the inventive concepts described herein are not limited to this specific implementation. Embodiments may be applied to monitor any form of events (e.g. activity conducted by one or more computing systems), such as internal processes within a communication system. As described in further detail below, the anomaly detection module 130 monitors behaviour through the use of a finite state machine, which defines non-anomalous (e.g. approved) behaviour. The anomaly detection module 130 can therefore detect anomalies through deviation from this non-anomalous behaviour. In response to detection of an anomaly, the anomaly detection module 130 may issue an alert (e.g. via the network interface 150 and / or the I / O interface 170). In addition or alternatively, the anomaly detection module 130 may be configured to take remedial action in response to detection of an anomaly. Remedial action may include preventing further communication, for instance, preventing communication with a source of the anomaly, such as a particular external device (e.g. the second device 110, which transmitted an anomalous message). The communication module 120 and anomaly detection module 130 may be implemented as software that is executed by one or more processors in the first device 100, or as specifically configured hardware, such as a Field Programmable Gate Array (FPGA). The memory 140 may be configured to store computer executable instructions for instructing the first device 100 to perform the method as described herein. For instance, the computer executable instructions may instruct a processor to implement the communication module 120 and / or the anomaly detection module 130. In addition, the memory 140 may store a log of communications sent and / or received by the first device 100. This log may be utilised for diagnosis following detection of an anomaly, and / or for improving the finite state machine. A finite state machine (or finite automaton) maps a system to a finite number of states and transitions. The transitions represent the switching from one state to another. This mapping of the system as a series of approved transitions (e.g. patterns) allows for anomaly detection, as deviations from previously mapped transitions indicates an anomaly. A finite state machine can be in one of a finite number of states at any given time. Each transition from one state to another can occur in response to an input. The states can form a chain, with transitions linking adjoining states. For each state, a finite state machine may have a set of rules defining when to transition to another state in the chain based on an input. For instance, one or more predefined inputs may be associated with each state transition. When an input matches one of the predefined inputs for a given transition, the finite state machine may apply the transition to move to the next state according to that transition. In the context of monitoring communications, a state may represent a particular communication having certain attributes (e.g. sender, recipient, time, size, etc.). One state may transition to another state when a subsequent communication is detected (with the subsequent state representing the attributes of the subsequent communication). Anomalous behaviour may be detected when an invalid sequence of communications is detected, i.e. a pattern of communications that do not match a path across the finite state machine. FIG. 2 shows a finite state machine (or finite automata) according to an embodiment. The simple example shown in FIG. 2 includes four states: S1, S2, S3 and S4. S1 has two potential transitions: T1 and T2. In T1, the system moves from S1 to S2. In T2, the system moves from S1 to S3. S2 has a single transition, T3, from S2 to S3. S4 has two potential transitions, T4 and T5. In T4, the system moves from S4 to S1. In T5, the system moves from S4 to S3. S3 has a single transition, T6, in which the system moves from S3 to S1. Accordingly, each state has a set of one or more associated transitions. Each transition links a starting state with an end state for that transition. When a transition is taken, the system moves from the starting state (the current state of the system) to the end state (a new state of the system) as defined by the transition. A transition is taken when the system is in the starting state for that transition and a predefined condition for the transition is met. For anomaly detection, each state may represent an event having a particular set of one or more attributes. A transition between states may occur when a subsequent event is detected. In the context of an anomaly detection system that is monitoring communications, each event (and therefore, each state) may represent a particular one or more communications having certain attributes (e.g. sender, recipient, time, size, etc.). Where an event represents multiple communications, these communications may be a group of sequential communications (e.g. a pattern of communications). In this application, the term be “a pattern of one or more communications” may be considered to include a single communication, or a sequence of multiple communications. One state may transition to another state when a subsequent pattern of one or more communications is detected (with the subsequent state representing the attributes of the subsequent pattern of one or more communications). For instance, in a simple example, a transition may be associated with the detection of a communication from a particular device. Accordingly, when the system is in the starting state for that transition, the transition may occur when a communication is received from the particular device. Given the above, a finite state machine may be allocated that defines acceptable (non-anomalous) behaviour of the system. Each transition in the finite state machine may define an acceptable event (e.g. communication) as expected based on past events (past communications). Accordingly, paths across the graph defined by the finite state machine can define acceptable (non-anomalous) sequences of events (sequences of communications). When monitoring events, the events may be compared to the rules set out in the state transitions for that state. Where a transition is made (e.g. an event is detected) that does not comply with the predefined transitions set out in the finite state machine, an anomaly may be detected. For instance, in the example of FIG. 2, S3 may be associated with a particular type of communication. When in state S2 (i.e. when the system has previously made T1 from S1), if the communication associated with S3 is detected, an anomaly might be identified, as the transition from S2 to S3 is not one of the predefined transitions associated with S2. Instead, the only acceptable transition from S2 is T3, which moves the system to S4. As an extension to the above, a timed automaton (or timed finite state machine) may be utilised. In this embodiment, one or more of the transitions may also have an associated timing range (that is, the rules for transitioning can include rules specifying the timing for the transition). Timing may be the time between the start state and the end state for the transition. Accordingly, a transition occurs when the one or more conditions forthat transition are met within a predefined timing window (e.g. relative to the time that the starting state is entered). This allows the detection not only of anomalous series of sequences of events (e.g. sequences of communications), but anomalous timings of those events. In order to define a finite state machine for anomaly detection, embodiments make use of FP-Growth in order to define acceptable state transitions. FP-Growth is a method if identifying frequent datasets within data. It can therefore be applied to logs of activity (e.g. communication logs) in order to produce representative models for finite state machines for use in monitoring complex systems of systems. Where a log includes timing data representing the relative time of each event (or the time between events), the timing data may be utilised to define a timed finite state machine. Particular embodiments apply modified FP-Growth to generate accurate finite state machines that can be implemented more efficiently (e.g. with reduced resources). FIG. 3 shows an overall method 300 for generating a finite state machine for anomaly detection. Firstly a log of event data is analysed to determine frequently recurring patterns 310. The event data may be historical data detected within one or more real-world systems. Alternatively, the event data may be simulated event data, representing the simulation of one or more systems. A modified version of an FP-Growth algorithm may be applied to analyse the event data. FP-Growth is an algorithm used to find trends in transactional datasets. The algorithm is optimised to find the most frequently occurring patterns in a dataset using a structure known as Frequent Pattern - Trees (FP-Trees). The algorithm works by clustering states that commonly occur together in the sequence, and using that information to build longer chains that are representative of a system of systems. Secondly, the results of the analysis step 310 are used for the generation of a finite state machine 320. This may be in the form of a map of non-anomalous sequences of events (e.g. states and transitions). As noted above, adaptations may be applied to the FP-Growth algorithm. These in particular can help to improve performance and reduce the size of the resulting automaton. FIG. 4 shows a method 400 for generating a finite state machine for anomaly detection according to an embodiment, including modifications for improved performance. Starting with event data (e.g. historical data) the frequency of each event within the data is determined 410. One or more trees are then built based on a support threshold 420. Support is a metric to indicate the frequency that an item set appears in a dataset. The support for a single event X can be determined as: support^X) = total number of event X in dataset total number of events in dataset For a series of pattern of events, support represents the relative frequency of the series or pattern of events. For instance, given an antecedent event X and a consequent event Y (e.g. a pair of events that follow, one after the other), the support for that pattern of events is: support(X -> Y) = support(X U Y) total number of transition X Y in dataset support(X -> Y) =---------------------------------------- total number of transitions in dataset More generally, the support for a particular pattern of N events is the total number of occurrences of that pattern in the dataset as a ratio relative to the total number of N event patterns in the dataset. For each pair of successive events, a link is added if the support for the two events is above a threshold. In particular embodiments, the threshold is conditional on the frequency of the events. The support threshold for a transition (the support for a pair of events) may be dependent on the frequency of the start event and frequency for the end event. The frequency of an individual event may be equivalent to the support for that event. As accordingly, the support for a group of events may be termed “group support”, whereas the support for a single event may be termed ““individual support”. The threshold applied to the group support when determining whether to create a link may be termed the “group support threshold”. Similarly, one or more thresholds applied when determining the level of the group support threshold may be termed one or more “individual support thresholds”. Nevertheless, for clarity, we shall refer to the individual support below as “frequency”. The group support threshold for a pair of events changes depending on the frequency (or individual support) of the respective events. The group support threshold is higher if the frequency of the events is higher, and the group support threshold is lower if the frequency of the events is lower. For instance, different support thresholds may be applied for different frequency ranges. When considering the frequency (or individual support) for individual events in a set of events, the lowest frequency (the lowest individual support value) for each event in the set may be taken. For instance, for two events in a particular transition, the group support threshold may be defined based on the lower of the frequency (or individual support) for the first event and the frequency (or individual support) for the second event. Different group support thresholds may be applied for different frequency ranges. For example, a first group support threshold may be applied for events having a first frequency range, and a second group support threshold may be applied for events having a second frequency range, wherein the first frequency range is lower than the second frequency range (e.g. encompasses a lower range of frequencies), and the first group support threshold is less than the second group support threshold. For example, the first frequency range may be a range between a first frequency (e.g. 0) and a second frequency that is higher than the first frequency, and the second frequency may be a range between a third frequency and a fourth frequency that is higher than the third frequency. The third frequency may be greater than or equal to the second frequency. In addition to this, one or more further frequency ranges may be applied above the second frequency range, each having corresponding higher group support thresholds. The ranges may be predefined or learnt (e.g. optimized). For instance, the ranges may be set based on the standard deviation of the support of each type of event. The ranges (e.g. the one or more boundaries between adjacent ranges) may be adjusted based on an evaluation of the performance of the resultant model, to optimize the ranges to improve the performance (e.g. based on supervised learning). For instance, the ranges may be adjusted (e.g. optimized) to improve performance based on event training data (e.g. event data that is labelled with indications of anomalies). Different metrics for performance may be applied when training / optimizing the system. For instance, performance may be measured based on accuracy and / or precision. Accuracy may be indicated by correlation between the detected anomalies and the ground truth anomalies (as indicated by the labelled training data). Further metrics for performance include F1 score, speed, model size, etc. As an alternative to the above, a predefined relationship may be applied between the conditional support threshold and the frequency of the events, such that the group support threshold is determined based on that relationship. For instance, the group support threshold may be calculated based on the frequency of events, e.g. based on a positive correlation, such as a directly proportional relationship. As group support is dependent on individual event frequency (individual support), transitions between less frequent events will have lower support. Accordingly, applying the same group support threshold for all events can result in infrequent but non-anomalous behaviour being falsely identified as anomalous. By lowering the group support threshold for less frequent events, the resulting automata is able to better detect anomalies. If a non-conditional method was used, lowering the group support threshold for all items would result in very unrepresentative item sets (e.g. higher frequency, low group support transitions) being included in the trees. This can cause the system to miss anomalous behaviour (an increased rate of false negatives). Having said this, by lowering the group support threshold for the infrequent items, the valid (non-anomalous) but infrequent behaviour is still captured, reducing the risk of false positives. A set of one or more trees is built using the support metric (the group support threshold). Whilst there are many methods for building these trees, one method involves growing multiple trees and, where events between trees are linked, linking the trees together. The most frequent event may be initially selected as the first node in the first tree. The trees may be built recursively, wherein connections are made for each pair of events that meet the required support threshold. Each tree is built from an initial event (e.g. a root), with any preceding / succeeding events that have transitions that meet the support metric being added. That is, a connection is added between each pair of events that meets the support metric. It may not be possible to combine all trees into a single tree (for instance, it may never be valid to transition between certain events through any combination of intermediate events). Accordingly, a set of one or more trees may be determined, defining events linked according to the support metric. These trees may represent frequently occurring patterns of events within the log data. Once the initial one or more trees (otherwise known as graphs) are produced, they are pruned based on conviction 430. This removes any edges that have a conviction that is less than a threshold conviction. Conviction denotes the strength of the dependence between items in an item set. Conviction represents whether the occurrence of a pattern of events is more significant than if the events were independent of one another. A high conviction value signifies a strong relationship, whereas a low conviction value suggests a weak, or negative, connection between patterns. The conviction of a series of events comprising event X followed by event Y can be defined as: 1 — support(Y) conviction(X -> y) =---------————- 7 support(X -> Y) support^X) wherein conviction^X -> Y) is the conviction for a transition from event X to event K; support^ is the support for event Y (the individual support for V); support(X) is the support for event X (the individual support for X); and supportQC -> Y) is the support for the transition from event X to event Y (the group support for the transition X -> Y). Calculating conviction can include the calculation of the confidence of the transition (event X to event Y): confidence(X -> Y) support(X -> Y) support^X) The confidence is the probability of event Y following event X. That is, confidence is the probability that event Y occurs, given that the current state is event X. A conviction value of approximately 1 implies that event X and event Y are not significantly related (e.g. are independent). A conviction value of greater than 1 indicates a strong association between event X and event Y. A conviction value of less than 1 indicates a negative correlation between event X and event Y, or that the two events are not strongly supported. Accordingly, the conviction can also be written as: X-support^ conviction(X ^Y) = ------—---—--— 1 — confidence(X -> Y) The conviction can therefore be considered the probability that event X occurs without event Y if they were independent divided by the frequency of event X occurring without event Y. Given the above, the conviction for each edge (each transition) in each tree is calculated, and each edge that has a conviction value that is less than a threshold conviction value is removed. By removing edges (transitions) that have a conviction that is less than a threshold conviction, the resultant pruned trees only include transitions for events that are relatively strongly correlated. Alternative methods adopt a group support threshold when pruning the trees. By implementing conviction instead, relatively low support edges may be maintained for those low frequency events added due to the conditional group support threshold. This ensures that less frequent, but valid, transitions are maintained. The particular values of the group support and conviction thresholds may be tuned according to the individual requirements for the anomaly detection system. Lower group support and higher conviction thresholds will increase the size of the resultant model and increase the chance of false negatives (missing anomalous behaviour), whilst higher group support and lower conviction thresholds will reduce the size of the resultant model and increase the chance of false positives (incorrect alerts). The one or more pruned trees are flatted and further pruned based on sequential validity 440. The one or more trees are flattened into a set of event sequences (paths) of varying length based on the paths from root to leaf. That is, each potential path across the one or more trees is extracted. The paths may be ordered from longest to shortest and highest to lowest conviction. When ordering based on conviction, the conviction for a path may be the sum of the conviction of each transition in the path. Any duplicated paths may be removed from the list. The paths may be compared to paths from a set of validation data. This validation data may be event data that is held back for validation (e.g. that is not used for the original generation of the one or more trees). The paths may be compared to sequences of events in the validation data. Any matches may be added to a list of valid paths. If a path matches a sequence of events the validation data, then it is maintained as a valid path. If a path does not match any sequence of events in the validation data, then the path is removed from the list of valid paths. If a whole path does not match any sequence of events in the validation data, it may be broken down into sub-paths for validation. Each sub-path may be compared to the validation data. If the sub-path matches a sequence of events in the validation data, then it may be added to the list of valid paths. In addition, or alternatively, if a path does not match, then it may be reordered (e.g. by adding an end event to the start, or a start event to the end), and the reordered path may be validated (compared to the validation data). A path may only be reordered if the newly created edge(s) comply with the previously defined support and conviction metrics. For instance, when breaking a path into sub-paths, the path may be searched using a moving window. For instance, a window may be adjusted across the path to select sub-paths and therefore scan the path for valid sections. A forward scan may be conducted from the start (the root) to the end (the tip) of the path. Over a forward scan, the start of the window may be moved from the start to the end of the path. The end of the window may be kept at the end of the path. Any events falling within the window are selected as a sub-path. In addition, or alternatively, a reverse scan may be conducted from the end (the tip) to the start (the root). In this case, the start of the window may be maintained at the start of the path, and the end of the window may be moved from the end of the path towards the start of the path. Accordingly, each nonmatching path may be scanned to identify any sub-paths that may be valid. The path comparisons may be efficiently conducted using hashes. For instance, each path or sub-path may be hashed using a hash function. Various sequences within the validation data may also be hashed using the hash function. The hashes may then be compared. If the hashes match, then the path or sub-path matches the sequence and is therefore valid. If the hashes do not match, then the path or sub-path does not match the sequence. When comparing a path or sub-path to a sequence, a sequence of the same length as the path or sub-path may be selected. Accordingly, the paths may be compared to the validation data and any matching sequences of events may be determined to be valid paths. When reordering or scanning paths, the methods may be repeated until either all matches are found, or a maximum number of iterations has been complete. The result is a set of valid paths representing non-anomalous behaviour (non-anomalous sequences of events). These are then converted into a finite state machine (an automaton) 450. The finite state machine may be encoded through any of a variety of formats, such as JSON or xml. The finite state machine represents the set of valid paths as a set of states (events) linked by valid transitions, as defined by the list of valid paths. The finite state machine can be used to determine whether any anomalous patterns of events occurs. FIG. 5 shows an example of a tree before and after pruning. The tree includes a number of items (events), including item 184, item 177 and item 2. Edges that are do not meet the conviction metric are removed. Following this, the only remaining paths across the tree are: 184, 184 184, 177 184, 184, 177 184, 177, 2 Assuming that each of these paths is valid, the resulting finite state machine can be represented as: version^wl ,0w enc0ding^’*UTF-8‘’ ?> O u <Tte®184> <1 tenvl ??>< / ! teml? 7> 'C / 11 1 7 *? < / roQts> The finite state machine may be generated to be a temporal automata, that is, a finite state machine that also records timing parameters for the transitions. FIG. 6 shows a method 600 for generating a temporal automata. For each transition in the finite state machine, the timing of the corresponding events in log data is obtained 610. For instance, the original log data used to generate the finite state machine might include the relative timing of each event (or the timing between events). The time for each transition (e.g. the end time minus the start time for each transition) may be determined. Accordingly, for each transition in the finite state machine, the log data may be searched to identify a timings for that transition in the log data. One or more timing statistics are then determined for the transition 620. The one or more timing statistics may include one or more of a mean time for the transition, a median time for the transition, and a standard deviation for the timings of the transition. A timing range is then determined for the transition based on the one or more timing statistics 630. For instance, a timing range may be based on an acceptable positive and negative factor of standard deviation (e.g. ±3o-, where a is the standard deviation). The method 600 may be performed for each transition in the finite state machine. Whilst the method 600 is described with reference to a single transition, it will be appreciated that steps 610, 620 and 630 may be performed for all (or a group) of transitions (that is, the ranges for each transition may be obtained in parallel). Based on the above, a finite state machine may be defined which includes an acceptable timing range for each transition. The timing range for each transition is measured from the time at which the start state is entered. If the transition is made within the acceptable timing range (i.e. if the time difference between the start state and the end state is within the acceptable timing range for the transition), then the timing of the transition is deemed non-anomalous. However, if the timing falls outside of the acceptable timing range, then the transition is deemed anomalous (e.g. even if the particular sequence of events (irrespective of timing) is valid across the finite state machine). FIG. 7 shows a method 700 for identifying abnormalities within a series of events. This method may be implemented in real time, as events are being monitored / detected, or may be implemented on a batch of events. In general, the method includes updating the state of the finite state machine according to the series of events, and identifying an abnormality when a transition that is not defined in the finite state machine is detected. In the method of FIG. 7, a state is set according to an event 710. For the first event in a series, the state may be an initial state (e.g. a root). The next event in the series is then considered. The method determines whether the transition from the state to the next state (representing the next event in the series) is a valid transition according to the finite state machine 720. A transition may be invalid if the finite state machine does not include a connection between the current state and a state corresponding to the next event. In addition, if the finite state machine is a temporal finite state machine, a transition may be invalid if the timing of the transition (the time difference between the end event and start event) does not fall within the predefined timing range for that transition. If the transition is determined to be invalid, an abnormality is identified 730. In response to the identification of an abnormality, an alert may be issued (e.g. identifying the event or series of events that caused the abnormality). Furthermore, details of the invalid transition may be stored for later consideration (e.g. diagnosis). More generally, a method of detecting an abnormality may comprise comparing a series of events to the finite state machine to determine if that series of events is a valid path across the finite state machine and, if not, identifying the series of events to be abnormal. FIG. 8 shows a system for detecting anomalous events. The system comprises a monitoring system 820 and a development system 830. The monitoring system 820 is a computing system that is configured to monitor events within a monitored system 810. The monitored system 810 may be a communication system. The monitored system 810 may be a remote radio unit of a communication system. The monitored system 810 may be an aerial vehicle or a communication module for an aerial vehicle, The monitoring system 820 may be configured to connect directly to the monitored system 810 (or may form part of the monitored system 810). For instance, where the monitored system 810 is a communication system, the monitoring system 820 may connect directly to, or form part of, the communication system. Where the monitored system 810 is or forms part of an aerial vehicle, the monitoring system 820 may be carried by and / or may be powered by the aerial vehicle. Alternatively, the monitoring system 820 may monitor activity of the monitored system 810 remotely (e.g. through a wireless connection and / or one or more sensors The monitoring system 820 may utilise a finite state machine as described herein. The monitoring system 820 obtains (e.g. generates or receives) log files detailing the series of events of the monitored system 810. The monitored system 810 may be a black box system, in that the internal operations of the monitored system 810 are unknown to the monitoring system 820. Accordingly the monitoring system 820 may monitor inputs and outputs to the monitored system 810 (such as communications to / from the monitored system 810). Nevertheless, it is not essential for the monitored system 810 to be a black box system. Accordingly, the monitored system 810 may have visibility of internal operations of the monitored system 810, and events may relate to those internal operations. In an embodiment where the monitored system 810 is a communication system, the monitored data may be communication data (communication traffic to / from the communication system). Each event may be a communication to / from the communication system, or may be a series of communications to / from the communication system. In some embodiments, the content of the communications may be obscured or inaccessible (e.g. encrypted). Nevertheless, events can be distinguished from one another based on one or more of attributes, such as one or more of: time of sending, time of receipt, message size, source identifier (ID), destination ID, source host ID, destination host ID, message content (if accessible), classification of message type, and Application Programming Interface (API) identifier (ID). Source ID and destination ID may refer to respective identifiers for one or more applications running on the sender and receiver. The source host ID and destination host ID may refer to respective identifiers for the sending system and receiving system. More generally, the source ID and source host ID may be one or more sender identifiers, and the destination ID and destination host ID may be one or more receiver identifiers. An example of a log file comprising a series of events is detailed below: Time, Message size, Source ID, Source Partition, Destination ID, Destination Partition 41432330680, 56, 9477, 5, 9733, 5 41432339240, 40, 3845, 5, 4101, 5 41432365760, 1064, 8453, 5, 8709, 5 The monitoring system 820 may perform pre-processing of the data obtained from the monitored system 810 to form event data (e.g. a series of events). Each event may be associated with a particular classification (e.g. event type). For instance, a transmission at a particular time of a particular size from a particular sender may be a associated with a particular event type. A series of events may therefore be extracted from the log data. The monitoring system 820 is configured to perform anomaly detection through comparison of the event data with a valid patterns of events as defined by the finite state machine, as discussed above. In response to an anomaly being detected, an alert may be output. The development system 830 is configured to analyse event data (log files) to generate a finite state machine for use by the monitoring system 820. The development system 830 receives the log files from the monitored system 810. The development system 830 need not process these log files in real time, and may instead store 832 the log files to be processed in a batch. Pre-processing may be performed on the log files to extract the events. As described herein, the log files are analysed 834 to produce a graph (or tree) and then compared to a log of accepted patterns to produce a valid list of paths (or a valid graph) 836. This is then used to determine a finite state machine 838, which is passed to the monitoring system 820 for use in monitoring for anomalies 824. If an anomaly is detected, then the monitoring system 820 may issue an alert 826. Through the techniques described herein, FP-Growth is applied to generate an accurate finite state machine for use in detecting anomalies. In particular, through modifications to the FP-Growth method, finite state machines can be created that have improved accuracy and reduced computational burden. For instance, the use of a conditional threshold for support when building the initial graph, and the use of conviction when pruning the graph, allows a smaller and more representative finite state machine to be built. The below table represents the relative performance of embodiments of the invention. Embodiments described herein are termed “FP-Growtomata” due to the combination of FP-Growth and Automata. The below table shows the relative performance of non-temporal embodiments (FP-Growtomata) and temporal embodiments (Temporal FP-Growtomata) compared to other methods, as applied to the monitoring of communications to / from a remote radio unit (RRU). Temporal embodiments make use of temporal automata, as discussed above. Table 1 shows performance comparisons between embodiments (Temporal FPGrowtomata and FPGrowtomata) and a system that makes use of the methods (termed herein “Iterative Automata” and “Iterative Time Automata”) described in A. Damien, M. Marcourt, V. Nicomette, E. Alata and M. Kaaniche, "Implementation of a Host-Based Intrusion Detection System for Avionic Applications," 2019 IEEE 24th Pacific Rim International Symposium on Dependable Computing (PRDC), Kyoto, Japan, 2019, pp. 178-17809. Algorithm used Matthews correlation coefficient (MCC)* Accuracy** Size of Model in Non-volatile memory FP-Growtomata 0.71 0.97 1.42Kb Temporal FPGrowtomata 0.70 0.97 5.52Kb Iterative Automata 0.70 0.97 2.35Kb Iterative Time Automata 0.73 0.98 8.62Kb Table 1: Comparison between FPGrowtomata and iterative approach * MCC is a measure of the quality of binary anomaly detection techniques, 1 = perfect, -1 perfectly wrong **Accuracy is the number of correct predictions made by a model in relation to the total number of predictions The performance shown in Table 1 for embodiments (Temporal FPGrowtomata and FPGrowtomata) are similar to that of the iterative models but with an average reduction in model size of ~40%. The similar MCC demonstrates that FPGrowtomata is able to model the data without requiring the same exhaustive search of an iterative approach. The reduced size indicates that it is achieving this without needing to store as many repeating patterns. The model also performs better than the majority of classical techniques used for the classification of anomalies as can be seen in Table 2. Algorithm used Matthews correlation coefficient (MCC) Accuracy FPGrowtomata 0.71 0.97 Decision Trees 0.44 0.70 K-Nearest Neighbours 0.23 0.61 Small Vector Machine 0.12 0.51 Table 2: Comparison between FPGrowtomata and Industry Standard techniques Additionally the iterative search process applied in alternative work using Automata and Timed Automata is unsuitable for building the models required for complex systems of systems such as those found within avionics connectivity systems, for example, a RRU. This complexity can be expressed using the Bachmann-Landau Big O time complexity concept that represents the worst-case time taken for an infinite number of iterations. With the number of operations being n (i.e. states), and d the number of unique states, the iterative search method has the complexity O(nd) meaning each state needs to be compared against all the previous unique patterns found in the data. FP-Growth is a data mining technique that can achieve the same goal as iterative search. However, FP-growth’s O(nd) complexity means that only a linear search operation is required for each unique pattern. The reason for the difference in complexity is a result of the number comparisons required to build the automata. For the use case of log data messages from a connectivity device, the iterative approach needs to compare each message against all the previous unique patterns found in the data. FP-growth only requires a linear operation to build the trees, using a single search to get the frequency of messages (n), and then a second operation to group those messages into patterns (d). This difference per pattern over a large number of transitions can correspond to orders of magnitude differences in computational time. For the test case of remote radio unit log files, which contained a combined recording of 1 hour (~20 million log lines), it was estimated to take 3 weeks to complete using the iterative approach. Comparatively, the FPGrowtomata took less than 1 hour to generate a model that produces similar anomaly detection performance. Modifications and additions are also made to the existing FP-Growth algorithm in FPGrowtomata to further improve its efficiency and applicability. Accordingly, the methods described herein can produce a finite state machine with reduce computational cost. Embodiments described herein generate an anomaly detection models that require limited on target computational cost to monitor a complex system. In safety critical and low-SWAP platforms, these options are not currently available. Implementations of the subject matter and the operations described in this specification can be realized in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. For instance, hardware may include processors, microprocessors, electronic circuitry, electronic components, integrated circuits, etc. Implementations of the subject matter described in this specification can be realized using one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially-generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices). While certain arrangements have been described, the arrangements have been presented by way of example only, and are not intended to limit the scope of protection. The inventive concepts described herein may be implemented in a variety of other forms. In addition, various omissions, substitutions and changes to the specific implementations described herein may be made without departing from the scope of protection defined in the following claims.

Claims

25CLAIMS:

1. A computer-implemented method comprising:obtaining a log of one or more series of events;5 determining the frequency of events within the log;generating a graph representing patterns of events within the log based on the frequency of events, wherein the graph includes nodes representing events and edges representing transitions between events;pruning the graph to remove edges that have less than a minimum conviction, 10 wherein conviction indicates the strength of dependence between grouped events; anddetermining a finite state machine from the graph, wherein the finite state machine models valid paths through the graph and for use in determining an anomalous series of events, wherein the anomalous series of events relates to communications between an aerial vehicle and another device.

152. The method of claim 1 wherein generating the graph includes connecting nodes for each group of sequential events that have more than a threshold support, wherein the threshold is lower for less frequent events.20 3. The method of claim 2 wherein support for a particular pattern of N eventsrepresents the frequency of occurrence of the pattern of N events as a ratio relative to the total number of N event patterns, wherein N is an integer greater than or equal to one.25 4. The method of claim 2 or claim 3, wherein connecting nodes for each group ofsequential events that have more than a threshold support, wherein the threshold is lower for less frequent events, comprises, for events having a frequency within a first frequency range, applying a first support threshold, and for events having a frequency within a second frequency range, applying a second support threshold, wherein the first30 frequency range is lower than the second frequency range, and wherein the first support threshold is lower than the second support threshold.

5. The method of any preceding claim wherein pruning the graph comprises determining a conviction for each edge in the graph, and removing each edge that has 35 a conviction that is less than the minimum conviction.

6. The method of claim 5 where determining conviction comprises determining:conviction(X -> T)1 — support(Y)_ suPPort(.X -> Y) support(X)wherein10convlctlon^X -> T) is the conviction for an edge representing a transition from event X to event Y;support(Y) is the support for event Y'support(X~) is the support for event X;support(X -> T) is the support for the transition from event X to event Y.24 06 257. The method of any preceding claim wherein determining the finite state machine from the graph comprises:determining each potential path across the pruned graph from root to 15 leaf;identifying valid paths within the potential paths based on matches with training data; andforming the finite state machine from the valid paths, the finite state machine including valid states and valid state transitions.

208. The method of any preceding claim further comprising:analysing a further series of events within a computing system using the finite state machine to determine whether any anomalies occur.25 9. The method of claim 8 wherein the analysing comprises:determining one or more state transitions representing the further series of events;comparing the determined one or more state transitions with the finite state machine to determine if the determined one or more state transitions 30 matches any valid sequence of one or more state transitions; andin response to determining that at least a subset of the determined one or more state transitions does not match any valid sequence of one or more state transitions, determining that the further series of events includes an anomaly.24 06 2510. The method of claim 9 wherein the analysing further comprises, for any determined state transition that matches a valid state transition:comparing a timing for the determined state transition against a 5 predefined time range associated with the valid state transition; andin response to the timing for the determine state transition not falling within the predefined time range, determining the determined state transition relates to an anomaly.10 11. The method of any of claims 8-10 further comprising, in response todetermining the occurrence of at least one anomaly, outputting an alert.

12. The method of any preceding claim wherein the events represent communications exchanged between computing systems.1513. A computer-implemented method for detecting anomalous series of events, the method comprising analysing a series of events within a computing system using a finite state machine determined according to the method of any of claims 1-7 to determine whether any anomalies occur.2014. The method of claim 13 wherein the analysing comprises:determining one or more state transitions representing the further series of events;comparing the determined one or more state transitions with the finite25 state machine to determine if the determined one or more state transitionsmatches any valid sequence of one or more state transitions; andin response to determining that at least a subset of the determined one or more state transitions does not match any valid sequence of one or more state transitions, determining that the further series of events includes an 30 anomaly.

15. The method of claim 14 wherein the analysing further comprises, for any determined state transition that matches a valid state transition:comparing a timing for the determined state transition against a 35 predefined time range associated with the valid state transition; and24 06 25in response to the timing for the determine state transition not falling within the predefined time range, determining the determined state transition relates to an anomaly.5 16. The method of any of claims 13-15 further comprising, in response todetermining the occurrence of at least one anomaly, outputting an alert.

17. A computing system comprising a processor configured to implement the method of any preceding claim.

018. The computing system of claim 17 further comprising:an interface for connecting directly to an aerial vehicle for monitoring events within the aerial vehicle;a processor configured to implement the method of any of claim 13-17519. An aerial vehicle comprising the computing system of claim 18 or claim 19.

Images