BACKGROUND

[0001] Nodes within a computing network may produce logs responsive to events that occur as part of activities within the network. Data analytic techniques may derive information about the computing network from the logs.

BRIEF DESCRIPTION OF DRAWINGS

[0002] Non-limiting examples will now be described with reference to the accompanying drawings, in which:

[0003] Figure 1 is a flowchart of an example method of determining information about an event chain;

[0004] Figure 2 is a schematic drawing of an example computing network for implementing certain methods, machine-readable media and apparatus described herein;

[0005] Figure 3 is a schematic drawing of an example scenario relating to certain methods;

[0006] Figures 4A-4D are flowcharts of an example method of identifying event chains and determining which event chains are stable;

[0007] Figure 5 is schematic drawing depicting three example chains and a table with information about the chains;

[0008] Figure 6 is a schematic drawing of an example scenario showing various interactions;

[0009] Figure 7 is a flowchart of an example user-printer interaction chain along a timeline;

[0010] Figure 8 is an example simplified dataset presented in a table;

[0011] Figure 9 is an example table including the set of chains derived from the example data in Figure 8;

[0012] Figure 10 is an example graphical representation of a comparison between chains; [0013] Figure 11 is a flowchart of an example method of determining information about an event chain;

[0014] Figure 12 is a simplified schematic drawing of an example machine-readable medium associated with a node; [0015] Figure 13 is a simplified schematic drawing of an example machine-readable medium associated with a node;

[0016] Figure 14 is a simplified schematic drawing of an example machine-readable medium associated with a node;

[0017] Figure 15 is a simplified schematic drawing of an example apparatus associated with a node;

[0018] Figure 16 is a simplified schematic drawing of an example scenario involving multiple events in a timeline;

[0019] Figure 17 is a simplified schematic drawing of an example scenario involving multiple events in a timeline; [0020] Figure 18 is a simplified schematic drawing of an example scenario involving multiple events in a timeline;

[0021] Figure 19 is a flowchart of an example method of determining information about chain periodicity;

[0022] Figure 20 is a flowchart of an example method of determining information about chain periodicity;

[0023] Figure 21 is a flowchart of an example method of determining information about chain periodicity and generating a response;

[0024] Figure 22 is a simplified schematic drawing of an example machine-readable medium associated with a node; [0025] Figure 23 is a simplified schematic drawing of an example machine-readable medium associated with a node; and

[0026] Figure 24 is a simplified schematic drawing of an example apparatus associated with a node. DETAILED DESCRIPTION

[0027] A computing network may comprise a plurality of nodes where information may be collected or generated at a node within the network as part of, or in response to, activities that occur within the network. An activity that occurs within the network may be associated with at least one event that occurs as part of the activity. In some examples, a node may produce a log (or a ‘record’) as part of, or in response to, an activity that occurs within the network (e.g., at the node itself or another node within the network).

[0028] In an example, a log may be produced by a node as part of, or in response to, a single event that occurs as part of a single activity within the network.

[0029] In another example, multiple logs may be produced by a node as part of, or in response to, corresponding multiple events that occur as part of a single activity within the network.

[0030] Thus, any reference to an ‘event’ may refer to a node behavior as part of, or in response to, an activity that occurs within the network.

[0031] In some examples, the node may collect or generate information based on events that occur on the node itself. In an example, the node comprises a web client to facilitate user interaction with a web-based service. The node may collect information about the user’s activity and produce a log comprising the information. In another example, the node comprises an embedded system (e.g., of a printer or Internet of Things (loT) device) which produces logs in response to execution of code by the embedded system (e.g., due to events that occur on the embedded system).

[0032] In some examples, the node may collect or generate information based on events that occur upstream of the node. In an example, the node may receive information from another node (e.g., the web client or embedded system described above) in the network and produce a log based on the received information.

[0033] The log may comprise event information comprising information such as an event timestamp, an event identifier for identifying the event type, an identity of the node associated with the event and/or a user identity associated with the event. The log may be stored in a database in the network.

[0034] A node may comprise a computing device for implementing certain functionality depending on the setup of the network. A computing device may comprise processing circuitry for executing instructions for implementing the functionality. For example, a computing device may implement functionality such as executing a subroutine as part of an event that occurs on the computing device, producing a log (e.g., in response to executing the subroutine or in response to receiving information from the network indicative of the event occurring on another node of the network), sending a log (e.g., in a telemetry message) to another node in the network for storage or processing, performing data analytics, etc.

[0035] A set of logs may be indicative of certain information about the network such as the performance of the network, end-user behavior, suspicious activity, etc.

[0036] Data analytics may be implemented to produce alerts, metrics and/or statistics (i.e. , ‘output’) based on the set of logs. This output may be reviewed, for example by a human operator or an artificial intelligence-based operator, to determine whether or not the computing network is behaving as expected.

[0037] Data analytics may refer to a range of data processing techniques and may include machine learning-based techniques. The data analytics may be of varying complexity and may contain various configurable thresholds and parameter choices to filter and manipulate the input data to produce output. Adjusting these choices may result in different analytic output.

[0038] Some analytical tools may filter and/or aggregate the data collected from the network.

Identifying Event Chains

[0039] Enterprise information technology and security administrators may actively track activity of nodes on their network in an attempt to spot anomalous activity within the network. Raw event data such as logs (e.g., system logs or ‘syslogs’) may be collected from those devices at a networked collector node, for example, a cloud or syslog server. The raw event data may be subject to analysis by various analytical tools.

[0040] Certain individual data points (e.g., individual syslogs) may not, by themselves, describe a complete interaction (or ’task', ’action', or ’transaction') associated with a specified activity of the node. For example, a specified (e.g., single or distinct) activity such as a reboot or a print job may generate multiple data points at distinct (but similar) times. However, these data points may be considered to be related to the same specified activity. In another example, the specified activity may correspond to a single event that is distinct from other, adjacent, events in the event timeline. Certain examples herein describe methods that attempt to map raw event data according to whether individual events or groups of events are regarded as being potentially associated with a specified activity (e.g., a single task such as a print job, reboot, etc., which is a higher-level task than producing a log). When mapped to a specified activity, the individual events or groups of events associated with the specified activity may be referred to as a ‘chain’ or ‘event chain’.

[0041] An example chain could be the three raw events {‘login’ ‘logout’} corresponding to a user print job task.

[0042] Certain systems, for example embedded systems, may have a certain number and/or predictable set of system states that are transitioned between as either the system completes autonomous tasks, or users interact with the system. Such systems may be regarded as carrying out an event upon transition to a new state. Upon each event occurrence, the embedded system may produce a log, which may be sent to an aggregation system, such as a syslog server.

[0043] Certain systems may analyze various nodes in a computing network that are associated with activity on the network. For example, a web activity tracker implemented on a node may monitor device behavior, user activity and/or bot chains in clickstreams for shopping sites, etc. A node may monitor activity on the node itself or on other nodes and produce logs responsive to the activity. In some examples, there may be chains of interest that may span across multiple nodes within the network.

[0044] In some examples, the state transitions of a system may not be documented in detail or at all, or do not contain enough contextual data within the event stream. The event data obtained from the system may need to be analyzed to obtain the probable set of system state transitions. These state transitions can then be used for many applications, such as monitoring the security of a system or to confirm proper operation of the system. In some examples, the event data may not contain enough information to determine which events are associated with a specified activity.

[0045] Raw event streams and device telemetry may describe activity at quite a granular level, so that singular activities such as a user administering a device, or engaging with its functionality, may produce a multitude of corresponding events. For example, to print, a user may log into the printer, perform their print job, and sign back out. This single (higher-level) task may produce 3 individual events (with corresponding logs produced for each event).

[0046] In some examples, these individual events may have less interpretability to a human analyst without the additional higher-level context that these events are part of a broader transaction. [0047] In some examples, these individual events may contain a less clean signal than if they were grouped along with related events into something representing a single transaction.

[0048] In some examples, these individual events may hide potential correlations and interdependencies between individual events, which may otherwise cause data biases and other problems, from automated analytics and human analysts.

[0049] However, it may not be possible to know when particular combinations of individual events are related due to being part of a single task, or if the apparent correlation is an accidental correlation. When this is not documented or easily understood, we can attempt to infer such correlations with certain examples described herein.

[0050] Figure 1 depicts a flowchart of an example method 100, which may be a computer-implemented method, of determining information about an event chain (which may also be referred to as a ‘chain’ or ‘interaction chain’). The information determined by the method 100 may indicate whether the event chain is associated with a stable pattern of activity. In other words, the method 100 may determine whether an identified event chain is ‘stable’. The method 100 may be implemented by processing circuitry of a computing device implemented at a node within a computing network, as described in more detail below.

[0051] The method 100 comprises, at block 102, determining whether an occurrence of a specified event chain comprising at least one event is associated with a stable pattern of activity within a computing network.

[0052] The event chain is identified from a set of logs produced by a computing device within the computing network in response to activities that occur within the computing network. Each log comprises event information indicative of an activity that caused the computing device to produce the log. Examples of how the event chains may be initially identified, prior to implementing the method 100, from the set of logs are described below.

[0053] An event chain may link together at least one event, to indicate that the event(s) in the event chain are associated with a specified activity, which may be a higher-level activity than the ‘task’ of producing the log(s).

[0054] In some examples, an event chain may provide information corresponding to an event that is on its ‘own’ and is distinct from another event. In such examples, an event chain comprises a single event (e.g., that is distinct from other events that occur in the computing network). Thus, the single event of the event chain may be associated with the specified activity. In other words, an occurrence of the specified activity in the computing network triggers a log (corresponding to a single event) to be produced by a node within the network.

[0055] In some examples, an event chain may provide information corresponding to a chain of consecutive (or adjacent) events that are associated with each other. In such examples, an event chain comprises multiple events (e.g., multiple consecutive events that are associated with each other e.g., by virtue of a distance metric, as described herein). Thus, the multiple events of the event chain may be associated with the specified activity. In other words, an occurrence of the specified activity in the computing network triggers multiple logs (corresponding to the multiple events) to be produced by a node within the network.

[0056] Each event chain may be associated with a specified activity of the computing device. An event chain may not be mutually exclusive. For example, the same event may show up in two different event chains as long as the other events are different.

[0057] In some examples, the set of logs (or 'record(s)’) made by the computing device may refer to a certain set of logs (e.g., syslogs) produced by the computing device itself or produced at another node within the computing network. The set of logs may be associated with certain tasks (e.g., the ‘specified activity’) carried out at a node (e.g., the computing device itself or another device within the computing network) within the computing network.

[0058] In some examples, an individual user (e.g., admin, end-user, etc.) may interact with the node, which may result in a set of logs being produced which are also associated with the individual user. An example scenario may be where multiple users log in to a node such as a printer and syslogs are produced by the node in response to the activities that occur as the users interact with the node. Thus, the set of syslogs may be associated with the node itself. However, a subset of the syslogs may be associated with a specified user. In some examples, the specified activity may refer to node activity irrespective of which user interacted with the node. In some examples, the specified activity may refer to individual user activity when interacting with the node.

[0059] The event information may comprise an indication of an event (e.g., an event code or event identifier) and an associated timestamp for the event. Other information may be included such as a user identity, node identity, etc.

[0060] The association with the stable pattern of activity may be determined from the event information from the set of logs by determining whether a parameter derived from the event chain meets a relationship condition indicative of the event chain being linked to a specified activity within the computing network. The association with the stable pattern of activity may be determined from the event information from the set of logs by further determining whether the event chain meets a statistical condition.

[0061] In some examples, the stable pattern of activity may refer to the identified event chain corresponding to a consistent or repeatable behavior within the computing network, where the identified event chain may be associated with a higher-level task or activity of a node within the computing network. In other words, providing certain conditions are met, the event(s) in the identified event chain may be considered to be potentially associated with each other (where there are multiple events in the event chain) or distinct as a ‘single’ event (where the event chain comprises a single event) that is distinguishable from other events in the timeline.

[0062] As mentioned above, certain conditions are defined for determining, based on information derived from the set of logs, whether or not the event chain is associated with the stable pattern of activity. Block 102 of the method 100 may establish whether an identified event chain is associated with the specified activity and whether or not the event chain occurs consistently enough to indicate that, in all likelihood, the event(s) in the event chain correspond to the specified activity. In other words, block 102 of the method 100 may determine whether or not the event chain is ‘stable’.

[0063] As referred to in the method 100, the ‘parameter’ may be derived from the event chain (i.e. , derived from the event information). In some examples, the parameter may refer to a time frame over which an event occurs (e.g., 0 seconds ‘duration’ for a single event) or the time difference between each of a consecutive sequence of events. In such examples, the event information may comprise a timestamp associated with the event. Thus, the timestamp may be used to determine the relevant timing information. In some examples, the parameter may refer to a subroutine sequence executed at a node as part of, or in response to, each event that occurs on the node as part of an activity within the network. Similarly, the subroutine sequence may be derived from the event information (e.g., an event identifier in the event information may be used to lookup, in a database, the subroutine(s) associated with the event or the event identifier may explicitly identify the subroutine).

[0064] As referred to in the method 100, the relationship condition is indicative of the event chain being linked to the specified activity within the computing network. If the relationship condition is met, this may indicate that the event(s) in the event chain are related to each other (or are distinct from an adjacent event not identified within the event chain). For example, if the parameter is below multiple different thresholds (i.e., ‘relationship indicators’), this may indicate a link between events in an event chain. Further examples of how the relationship condition may be met are described below.

[0065] As referred to in the method 100, meeting the statistical condition may be indicative of the event chain being associated with the stable pattern of activity. In some examples, the statistical condition may be a measure of how frequently a specified log or sequence of logs is observed over a time period (e.g., it could be a minimum number such as >1000 or be statistically significant in another way). In some examples, the statistical condition may refer to a statistical property of a set of identified event chains (i.e., multiple identified chains) that is indicative of the identified event chain being associated with a specified activity within the computing network. A combination of these examples may also be used to ascertain whether the event chain meets the statistical condition.

[0066] In response to determining that both: the relationship condition and the statistical condition are met, the method 100 further comprises, at block 104, causing information regarding the event chain to be recorded in a dataset.

[0067] A determination that both the relationship condition and the statistical condition are met for an identified event chain may indicate that both: the event chain is associated with a specified activity within the computing network; and that the event(s) in the event chain are ‘stable’ to the extent that they are associated with a stable pattern of activity within the computing network.

[0068] In some examples, the information recorded in the dataset may comprise an indication of which event(s) are in the event chain. In some examples, the information may comprise metrics or other data about the event chain such as statistical information.

[0069] In some examples, the dataset may be stored in a node within the computing network such as a server or in the cloud that can be accessed by an analyst or analytical tool e.g., for performing data analytics.

[0070] As events occur within the computing network, the set of logs may be updated to reflect changes. The method 100 may be re-run in response to individual logs being produced or in response to a batch of logs being produced. As more data is produced, this data may be used to update a list of event chains, which may be analyzed to identify whether the event chains are stable or not.

[0071] Certain methods described herein (e.g., including method 100) may efficiently aggregate raw events into chains of events representing tasks (or ‘specified activities’). [0072] Certain methods described herein (e.g., including method 100) may provide an automated method of empirically determining how to map individual events or combinations of individual events into a single datapoint (i.e., an event chain) describing a single task, such that the mapping is consistent over multiple relationship indicators. Where the mapping is consistent over multiple relationship indicators, this may indicate that the identified event chain represents a single task or specified activity (or that the event chain is ‘stable’ with a good correlation between the events in the event chain). In other words, certain methods described herein may minimize the chance that an identified event chain occurs by coincidence due to inappropriate or restricted choice of relationship indicator(s).

[0073] In some examples, individual events may be organized into chains comprising at least one event according to a Markov probability model while a set of relationship indicators may be selected to maximize the quantity of (non-trivial) stable event chains.

[0074] Certain methods described herein (including method 100) may provide certain technical functions. For example, on its own, the raw data produced within the computing network may be difficult to analyze due to, for example, the amount of information produced, the lack of contextual understanding for each of the data points and/or the lack of intuition about whether there is any connection (or lack of connection) between the data points. Thus, when performing data analytics on the raw data, there may be no information that can identify certain types of behavior that may be of interest (e.g., periodic behavior, masking behavior, etc., associated with event chains).

[0075] However, identified stable event chains may provide a level of confidence that the event(s) in the event chain are not randomly associated with each other or random occurrences. Rather, when performing data analytics, the level of confidence may be such that additional insight can be derived about the behavior within the computing network that is not directly identifiable from the raw data. Further, there may be less data to analyze or the data may be less ‘noisy’ if the data is organized into event chains. In other words, the it may not be possible to know, a priori, what chains exist and when a particular event or set of events form one chain over another. The identification of stable event chains may provide the additional insight that may not otherwise be apparent from the raw data.

[0076] In some examples, by determining that an event chain is associated with a stable pattern of activity, this information may provide an improved or complementary understanding of behavior in the computing network. Such information may be leveraged to identify periodic behavior and/or masking behavior, which may represent a security or privacy issue or may otherwise be interesting for another reason.

[0077] In some examples, certain methods described herein (e.g., including method 100) may reduce the size of the data (compared with the raw data) to be analyzed, reduce data ‘noise’, identify certain potentially relevant data points and/or enhance the data to help with identifying security issues, privacy issues and/or unexpected patterns of behavior within the network.

[0078] Processing and/or storage resource may be better deployed when performing data analytics using the identified stable event chains, compared with performing data analytics on raw data alone.

[0079] Figure 2 depicts an example computing network 200 for implementing certain methods, machine-readable media and apparatus described herein. The computing network 200 comprises cloud 202 and a set of nodes 204a, 204b, 204c, 204d, 204e which are either within the cloud 202 or communicatively coupled to the cloud 202. In this example, the nodes 204a-204d are not ‘in’ the cloud 202 itself and may produce logs and/or submit data such as syslog messages to the cloud 202. The node 204d is associated with a user 206, who may interact with the node 204d and cause the node 204d to produce logs according to the interaction. The node 204e is in the cloud 202 and may collect information and/or produce logs in response to events that occur within the network 200. The node 204e may be an example of a networked collector node. Any node within the network 200 may implement certain methods described herein. In this example, the node 204e implements the method 100 and, in accordance with block 104, causes information regarding the (stable) event chain to be recorded in a dataset stored by a database 208 in the cloud 202. Various network configurations are possible with different numbers and locations of nodes. In some examples, a data analytics provider may operate a node such as a server to collect raw event data from connected nodes.

[0080] In this example, information about events may be recorded in logs responsive to certain activity within the network 200 (e.g., on any of the nodes 202a-202e). Such logs may be produced responsive to, for example, execution of code on an embedded system of a node 202 and/or when the user 206 interacts with the node 202d (such as signing into the node 202d) or triggering some of its functionality. An event may be identified by the user 206 who performed the action (where applicable) and/or by an identifier for the node 202 (such as a hostname, internet protocol (IP) address, etc.). [0081] As mentioned above, a determination may be made as to whether a relationship condition is met, which may be indicative of the event chain being linked to a specified activity within the computing network. In some examples, a set of relationship indicators may be used for transforming raw data into event chains corresponding to specified activities within the computing network. As described in more detail below, a relationship indicator may be used to generate a list of candidate event chains.

[0082] An example criteria for determining whether two events are candidates for being included in the same chain are whether the two events are close to each other. For example, a ‘distance’ metric (referred to as a ‘parameter’ in some examples) may be used to determine, from event information, how close two events are to each other. For example, the distance metric may be compared with a threshold (an example of a ‘relationship indicator’) to identify chains comprising events that appear to be sufficiently close to each other (or a single event that is sufficiently far away from other single events) to indicate that the event(s) are potentially linked to a specified activity within the computing network.

[0083] It may be tempting to regard the common or ‘probable’ chains as corresponding to tasks, or specified activities. However, if the threshold is varied, different chains may be generated from the raw data. A chain which was probable or frequent for one threshold choice may be uncommon for another threshold choice. The generation of different chains depending on threshold choice may undermine a conclusion that a certain chain represented a specified activity. In some cases, a threshold choice may coincidentally result in a chain being frequent even though the events in the chain are not linked. The relationship condition may be met if an identified chain is frequent across multiple threshold choices. In other words, providing a chain is common for at least a minimum proportion of a set of thresholds (i.e. , a set of relationship indicators), this may indicate that the chain is associated with a stable pattern of activity. Such chains may be referred to as ‘stable’ chains. In some examples, the threshold choice which produces the greatest number of stable chains may provide a further indication of stability.

[0084] Figure 3 depicts an example scenario where different relationship indicators are selected from a set of relationship indicators to identify candidate event chains. In this example, the relationship indicator is a time range and the distance metric, or ‘parameter’, is a time difference between adjacent events.

[0085] In some examples, the upper end of the time range may be referred to as a threshold or a so-called ‘MAXPAUSE’ value. Time is an example of a ‘distance’ measure indicative of the proximity between two consecutive events. Providing the time between the consecutive events is less than the time range, this may be indicative of a potential link between the consecutive events (i.e. , the consecutive events may be potentially associated with a specified activity within the computing network).

[0086] As shown by Figure 3, four raw events (‘Event 1’, ‘Event 2’, ‘Event 3’ and ‘Event 4’) are arranged along a timeline. The distance (i.e., a time difference) between Event 1 and Event 2 is ‘dT. The distance between Event 2 and Event 3 is ‘d2’. The distance between Event 3 and Event 4 is ‘d3’. The distances are different. In this example, as shown by Figure 3, the relative distances are d2 < d1 < d3. By selecting different ‘threshold’ values (i.e., the upper end of each of a set of time ranges), several sets of chains may emerge, as shown by Figure 3.

[0087] In some examples, the consecutive events may be from the same node and/or due to interaction between a specified user and the node. In some examples, the consecutive events may be derived from events that occur on multiple nodes within the network.

[0088] A first set of chains emerge for d2 < threshold < d1 ,d3. In this case the threshold is set at a time duration larger than d2 but less than d1,d3. This threshold selection results in the emergence of: a first chain comprising the single Event 1 since the threshold is less than d1 (and hence cannot form a chain with Event 2); a second chain comprising Events 2 and 3 since the threshold is greater than d2; and a third chain comprising the single Event 4 since the threshold is less than d3 (and hence cannot form a chain with Event 3). The first and third chains have a time duration of 0 (zero) seconds because they are not associated with any other event. The second chain has a time duration of d2. The intuition here is that the first, second and third chains may each be (potentially) linked to different specified activities within the computing network

[0089] By selecting different threshold values, different chains may emerge.

[0090] For example, a second set of chains emerge for d2, d1 < threshold < d3. Since the ‘distance’ between Events 3 and 4 is larger than the threshold, Event 4 does not form a chain with the other events. However, since the distance between the adjacent events Event 1 to Event 2 (d1) and Event 2 to Event 3 (d2) is less than the threshold, all three events Eventl to Event 3 form a chain. The intuition here is that Events 1 to 3 may be (potentially) linked to a first specified activity within the computing network while Event 4 may be (potentially) linked to a second specified activity.

[0091] A third set of chains emerge for d2, d1, d3 < threshold. Since the ‘distances’ between adjacent events is less than the threshold, all four events are considered to be part of the same chain. In other words, all four events may be potentially linked to the same specified activity within the computing network.

[0092] The parameter of interest in the above examples is ‘time’. Time is a type of distance metric for establishing the likelihood of adjacent events being linked to a specified, higher-level, activity within the computing network. Another example parameter is a subroutine sequence executed by the node as part of each event, as described below. In some examples, both time and subroutine sequences may be parameters used in the identification of chains.

[0093] In Figure 3, each event is associated with a certain subroutine sequence executed by a node of the network. Event Ts subroutine sequence is denoted ‘a.b.c’. Event 2’s subroutine sequence is also denoted ‘a.b.c’. Event 3’s subroutine sequence is denoted ‘a.b.d’. Event 4’s subroutine sequence is denoted ‘x.y.z’. In some examples, a number of common subroutines is another example of a ‘distance’ measure, where the greater the number of common subroutines in each of adjacent events, the closer in ‘distance’ between the adjacent events. For example, the subroutine sequences of Event 1 and Event 2 are the same such that the ‘distance’ is effectively ‘zero’. Event 3 is similar to Events 1 and 2 but the ‘distance’ is larger as the events have subroutines ‘a’ and ‘b’ in common. Nonetheless, in some examples, Event 3 may form a chain with Events 1 and 2 if the threshold choice is that there are at least two common subroutines. The subroutine sequence of Event 4 does not have any commonality with any of the other events, which may prevent Event 4 from forming a chain with any of the other events. This example highlights how different parameters derived from the event information may lead to different chains being formed.

[0094] In some examples, a relationship indicator may be based on combined selection of the time and subroutine parameters.

[0095] As highlighted by the above examples, different thresholds (i.e., relationship indicators) may lead to the appearance and disappearance of chains. It follows that not all of these chains may truly correspond to a specified activity within the computing network. In other words, certain events may be linked to other events even though no chains exist (which may indicate threshold selection could be improved) or certain events may have no associated with an adjacent event even though a chain exists (which may again indicate threshold selection could be improved). In some examples, a list of chains that emerge from a set of different thresholds may be filtered based on various criteria such as which threshold resulted in the maximum number of chains emerging, which may in some cases indicate that the threshold was the ‘optimal’ choice from the set of thresholds. As discussed below, the chains that are sufficiently common within the raw data are selected to increase the probability that they are real chains corresponding to a specified activity.

[0096] As an example, a Markov model may be used to create chains. In this example, the distance metric is ‘time’ (say, minutes) between events, thresholds are fixed lengths of time and two events are classed as in the same chain if they are within some time frame less than the selected threshold. The Markov probabilities of the resulting chains can be used to identify which chains are most common (and therefore are candidates to represent a task) for the choice of threshold. If a chain is also common over multiple threshold choices (i.e. is stable), then this indicates that a chain may correspond to a task/specified activity.

[0097] As another example, distance between events may be measured by the corresponding subroutine (in addition to or instead of ‘time’). For example, event a.b.c may be ‘closer’ to event ‘a.b.d’ than ‘x.y.z’. In some examples, the function mapping events to chains can be a measure combining the time and subroutine data for adjacent events. Common chains may then be measured by noting which chains are most frequent. Again, a chain is stable if it is deemed to be frequent over multiple threshold values.

[0098] Figures 4A-4D depict a flowchart of an example method 400, which may be a computer-implemented method, of identifying event chains and determining which event chains are stable. The method 400 comprises the method 100, which refers to determining chain stability. The method 400 may be implemented by processing circuitry of a computing device implemented at a node within a computing network such as described above in relation to Figure 2. Certain blocks may be omitted as indicated below and/or the method 400 may be implemented in a different order to that shown by Figures 4A-4D.

[0099] The method 400 may be partitioned into several portions as shown by Figure 4A. A first portion 402 of the method 400 shown by Figure 4B refers to the initial generation of a list of candidate chains. A second portion 404 of the method 400 shown by Figure 4C refers to ‘creating barcodes’, which is an example graphical representation of certain information derived by the method 400. A third portion 406 of the method 400 shown by Figure 4D refers to determining chain stability. The same or different processing circuitry (e.g., at different nodes) may be used to implement the procedure at each of the portions 402, 404, 406 of the method 400. A fourth portion 407 of the method 400 refers to use of information derived from the identified stable chains and/or other data derived from the events. For example, metrics such as time-difference data, periodicity data and other information that may be indicative of behavior within the computing network may be obtained at the fourth portion 407. In some examples, as part of the fourth portion 407, alerts may be output in response to an analysis of the metrics and other information.

[00100] The blocks of the method 400 are described below.

[00101] In this method 400, a set of variables is defined. A first variable is 1_threshold’, which is a list of candidate ‘THRESHOLD’ values (an example of a ‘relationship indicator’) in the units of distance, such as 0.5, 1 , 2, 4, 8, 16,... , 2048. In another example, a linear scale for the distance such as 1 ,5, 10, 15,... , 360 may be used. A second variable is ‘s_current_chains’, which is a list of empty sets. A third variable is ‘s_all_chains’, in which ‘set()’ is an empty set. A fourth variable is barcode, in which ‘array[][]’ is an empty 2 dimensional array holding a binary value 0 or 1 , where 0 (zero) stands for infrequent and 1 (one) stands for frequent.

[00102] As part of the first portion 402 of the method 400, the next threshold in the list, ‘l_threshold’ is selected at block 408. For example, the first threshold in the list may be selected initially and then the subsequent thresholds may be selected next. A list of frequent candidate chains is created using the distance function at block 410 based on thresholds selected at block 408. In some examples, the list of candidate chains is created per user-host combination using the distance function. For example, a separate list of chains for each user and host combination may be created.

[00103] In some examples, the list of the frequent chains ‘s_current_chains’ may be the top ‘n’ most frequent chains (e.g., 1%) within the list. Other percentiles and functions are also possible (e.g. plotting the chain frequency and obtaining the empirical distribution function (e.g., to estimate the cumulative distribution function (CDF)) and defining a cutoff such as 1 - F(x) = P[X > x] where x is a certain cut off value). In other similar words, the cut-off may be based on an absolute number of occurrences of a chain within a time period or a relative number of occurrences of a chain within the time period where the most frequent chains are selected.

[00104] At block 412, the list of frequent candidate chains obtained at block 410 are appended to a set of all the frequent chains over the different ‘THRESHOLD’ values for each ‘THRESHOLD’, such as ‘s_all_chains’ = ‘s_all_chains. union (s_current_chains[threshold])’, for all thresholds in l_threshold. This block 412 creates a list of chains, chain_k, as described below. [00105] At block 414, if there are any further thresholds in the list (i.e., ‘no’), the method 400 reruns the first portion 402. Otherwise, the method 400 proceeds to the second portion 404 (i.e., ‘yes’).

[00106] As part of the second portion 404 of the method 400, the set ‘s_all_chains’ may be iterated for each chain, ‘chain_k’ in ‘s_all_chains’ and all thresholds in ‘l_threshold’ values to determine which chains are frequent for the different thresholds. Thus, at block 416, the next chain, ‘chain_k’, from ‘s_all_chains’ and the next threshold from 1_threshold’ is chosen. At block 418, a determination is made regarding whether the chain is ‘frequent’ (e.g., meets at least part of a ‘statistical condition’). If ‘no’, the method 400 proceeds to block 416 again. If ‘yes’, the method 400 proceeds to block 420 where the array is updated with information to indicate that the chain is frequent. In other words, if ‘chain_k’ is in ‘s_current_chain[threshold]’ where [threshold] is the selected threshold, then mark the pair ‘barcode[chain_k, threshold] = T, otherwise ‘barcode[chain_k, threshold] = O’. In some examples, the barcode may be represented as a graphical table showing which chains are frequent for each of the thresholds. The method 400 continues to until the end of the list of chains and thresholds is reached.

[00107] As part of the third portion 406 of the method 400, the stability of the frequent chains generated at the second portion 404 is determined. Stability may be determined providing a sufficient number of the thresholds selected from the list indicate that a chain, ‘chain_k’, emerges for each of the selected thresholds.

[00108] For example, the stability of a ‘chain_k’ is determined by iterating over the ‘barcode[chain_k, threshold]’ where ‘barcode[chain_k, threshold] == T for x consecutive iterations. The method 400 may return the maximum number of consecutive “true” barcodes (i.e., max(x)) if a stability Boolean is defined as ‘true’ if x > the threshold. A ‘barcode’ is an example graphical representation of the stability for each chain and may not necessarily be used in practice.

[00109] At block 422 of the method 400, the next threshold from the list is selected for ‘chain_k’. At block 424, a determination is made regarding whether another (consecutive) threshold is indicative of ‘chain_k’ being stable. If ‘yes’, a counter is incremented at block 426 and the method 400 proceeds again to block 422 (to select the next threshold for ‘chain_k’). If ‘no’, the counter is reset at block 428. The counter corresponds to the number of thresholds from the list of thresholds where the ‘chain_k’ exists. At block 430, the (maximum) value for the counter is obtained for ‘chain_k’. [00110] At block 432, a determination is made regarding whether the ‘chain_k’ is stable. Stability is determined if a sufficient number of the thresholds leads to existence of the chains. For example, if there are 10 thresholds in the list and the sufficient number is 7’, then the chains that exist for 6 or fewer thresholds (i.e., ‘no’) are removed at block 434. Otherwise, if the chains exist for 7 or more thresholds (i.e., ‘yes’), the ‘chain_k’ is kept at block 436. In some examples, a stability value may be calculated. For example, a stability value may be a ratio of the counter value for ‘chain_k’ to the total number of thresholds in the list.

[00111] In some examples, the overall best fitting threshold value may be determined for ‘s_all_chains’ by counting the number of stable chains per threshold. The threshold that results in the maximum number of stable chains may be considered to be the ‘best fitting threshold value’.

[00112] In some examples, once the chains have been determined, streams of individual raw events can be combined into chains, based on the list of chains already obtained by the above method 400. As raw events are streamed (e.g., produced at the node or received by the node), the method 400 may create a new output from the raw one, on which analytics may be applied (e.g., to detect anomalous behavior of the network in real time).

[00113] A further description of chain stability is now given.

[00114] The chain stability may describe the number of consecutive thresholds (i.e., relationship indicators) where a chain remains frequent.

[00115] The higher the number of consecutive cases where a threshold reproduces the chain, the higher the stability of a particular chain since the chain may be considered to not be sensitive to changes of the threshold.

[00116] In some examples, a cutoff value can be defined that removes chains based on a low number of thresholds reproducing the claim. Such chains may be considered to be ‘unstable chains’.

[00117] Figure 5 shows a graphical representation of three example chains, chain_k-1 , chain_k, chain_k+1 , that may or may not emerge based on three different threshold values, threshold_t-1 , threshold_t, threshold_t+1. A chain emerges for a threshold if the corresponding cell is ‘grey’ in Figure 5. Otherwise, the cell is ‘white’. In this example, chain_k+1 emerges for 3 consecutive thresholds, chain_k emerges for 2 consecutive thresholds and chain_k-1 emerges for 1 threshold. Further, threshold_t intersects with all three chains, threshold_t-1 intersects with two of the chains and threshold_t+1 intersects with one of the chains. In this example, threshold^ is deemed the best-fitting threshold value for this set of chains (i.e. , chain_k-1 to chain_k+1) because this threshold appears to have the highest number of intersections (3). The table in Figure 5 indicates the chain stability (i.e., the ratio of the number of consecutive cells to the total number of thresholds) for each of the chains. The events for each chain are also indicated in the table where the number of consecutive events (Event 1 through to Event 5 in that order) is derived from the events of that chain.

[00118] A description of different modes for receiving information regarding raw events is now given. At least part of certain methods described herein (including the methods 100, 400 referred to above) may be implemented based on the raw event data. Such raw data may be stored in a database (e.g., database 208), stored in another location, processed, at least partially discarded, as appropriate for the scenario.

[00119] The raw data may be obtained as a batch mode or a streaming mode.

[00120] In the batch mode, a large sample set of raw data is used to generate the chains. Periodically (e.g., once every few months or another appropriate period of time), at least part of the method 100, 400 may be re-run to get an updated set of chains, which may reflect any potential changes in the dataset.

[00121] In streaming mode, a rolling sample taken from the last ‘n’ ingested raw datapoints can be used to perform at least part of the method 100, 400 to derive the chains. As a new raw datapoint is obtained (or once every ‘k’ datapoints, or Ύ minutes, in order to reduce computation overhead), at least part of the method 100, 400 may be re-run to obtain a new updated set of chains. In this mode, the raw data may be transformed into chains differently every time a datapoint is ingested. This level of granularity may or may not be useful, depending on the scenario.

[00122] An example scenario is now described where a user interacts with a printer infrastructure.

[00123] Figure 6 is a schematic illustration of the example scenario 600 showing the various interactions which occur when the user interacts with the printer infrastructure.

[00124] In this example, the ‘distance’ metric between the events is the time elapsed.

[00125] In some examples, interaction chains may be created by a user-printer interaction such as a user 602 logging into the control panel of a printer 604, printing a document and logging out. In some examples, interaction chains may be created a printer- infrastructure interaction with automated management services 606 such as Network Time Protocol (NTP) synchronizations or Dynamic Host Configuration Protocol (DHCP) address renewals.

[00126] Figure 7 is a flowchart of an example user-printer interaction chain along a timeline.

[00127] The example interaction chain shown in Figure 7 represents a user-printer interaction comprising three logs (e.g., syslogs). The time between the adjacent events “control panel sign-in authentication” and “print job completion” is 10 seconds. The time between the adjacent events “print job completion” and “control panel session terminated” is 15 seconds. For this interaction chain to be classified as a chain linked to the specified activity, a ‘threshold’ time of >15 seconds is to be selected, otherwise the chains would be split into two or more sub-chains. In an example, every chain begins with a ‘START’ label and ends with an ‘END’ label. This may be useful for determining the likelihood of chain starting and ending with a particular event.

[00128] A description of the format of example syslogs and how information from the syslogs is derived now given.

[00129] Initially, the events are captured in raw syslog format and are ingested into, for example, an event management system.

[00130] Figure 8 depicts an example simplified dataset presented in a table. The table includes fields such as the timestamp, hostname, user identity, message and outcome of the event (i.e. , success or failure of the event) for various events that occur for various user-hostname interactions.

[00131] In order to transform the sample dataset into more meaningful chains of interaction, a threshold value is selected. The threshold value describes the maximum time difference between two adjacent events in a chain. A chain consists of ‘n’ events in a row where the time difference between adjacent events does not exceed the selected threshold. Chains are constructed on a hostname and user basis, i.e., events from the same hostname and user pair are eligible to be part of the same chain. A unique hostname and user pair can have multiple chains of interaction if the selected threshold in between two events is exceeded.

[00132] By selecting a threshold value of 10 minutes, it is possible to obtain multiple chains of interaction from the example data in Figure 8. [00133] Figure 9 depicts an example table including the set of chains derived from the example data in Figure 8 based on the selected threshold value of 10 minutes. The duration of the single events is 0 seconds and they belong in their own chains providing the distance to the adjacent event (for the same user-hostname combination) is greater than 10 minutes. The duration of chains comprising multiple events is calculated from the time difference between ‘start’ and ‘end’ of the events in the interaction.

[00134] As depicted by Figure 9, causal user-printer interactions have been successfully extracted from the dataset and the event stream is now more interpretable than the raw syslog data. Single events that are neither correlated nor causal have been isolated whereas interaction chains have been merged together.

[00135] A description of a determination of chain stability for the above example is now given.

[00136] Chain stability may be evaluated by determining if the chains remain stable when modifying the threshold value. Hence, the dataset can be tested with a set of different threshold values. For example, the chain with the ID 0 (see Figure 9) would be cut off after the “print job completion” event if the threshold value was smaller than 10 minutes. On the other hand, if the threshold value would be 25 hours, the chains with IDs 4 and 5 would be inadvertently merged into one single chain, which does not reflect the causality of the underlying syslogs.

[00137] In some examples, a graphical representation may help to indicate the relative stability of a list of chains although the graphical representation may not be necessarily used in practice.

[00138] Figure 10 depicts an example graphical representation, in table form, of whether a comparison between the parameter (time) derived from the event information for each identified chain and each of the set of thresholds (x-axis) is indicative of chain stability. A subset of the ‘s_all_chains’ set is shown on the left-hand side of Error! Reference source not found.10 (for ease, these are represented by the ID numbers 0 to 10). The corresponding threshold values in minutes are shown on an exponential scale of [0.25; 2048]

[00139] In this example, a cell colored in grey represents >1000 occurrences (i.e. , for this example, at least part of a statistical condition is met) for a particular chain and is thus classified as ‘frequent’. This could also be done more generally, such as fitting a distribution to the frequencies (e.g. cumulative distribution function) and calculating a corresponding percentile value. The chain stability value on the right-hand side represents the maximum number of consecutive grey cells in relation to the total number of threshold values. In this case, a chain stability value of 1 is the highest possible value; a value of 0 means that a chain does not appear to be frequent for this list of threshold values.

[00140] A list of chains may be produced (‘s_all_chains’), which may then be used to transform raw events into chains. Certain chains react to changes in the threshold value at some point (white cells). The white cells may also indicate that a chain ‘lost’ its status as being frequent, which can be traced back to events that get added to the chain but which are statistically independent and/or chains split into incomplete sub-chains due to a threshold value that is too small.

[00141] As raw events are obtained, the distance between the raw events (in this example the time differences) may be kept track of, and chains may be created for the entities in the event (e.g., printer, user, etc.). Once the chain terminates (i.e. the time since the latest raw event exceeds the selected threshold value) the chain may be terminated and compared to ‘s_all_chains’. If it is within the list ‘s_all_chains’, then the individual events in the chain may be combined into a chain (since it is determined to be stable), and added to the transformed dataset. Otherwise, the chain elements may be separated back out and kept as individual raw events in the transformed dataset.

[00142] Some examples relating to the above methods are described below.

[00143] In some examples, the method 400 comprises, at block 407, determining a periodicity metric based on a time difference between consecutive occurrences of the event chain determined from the information in the dataset. In response to determining that the periodicity metric is indicative of an unexpected pattern of activity within the computing network, the method 400 further comprises outputting an alert. A further description of determining metrics such as the periodicity metric and alert outputs is given below in the section on determining chain periodicity metrics.

[00144] In some examples, the event chain comprises a consecutive sequence of events and the relationship condition is met where the parameter is indicative of a link between adjacent events in the consecutive sequence of events.

[00145] In some examples, the event chain is associated with a single event and the relationship condition is met where the parameter is indicative of there being no link between the single event and an adjacent event in the dataset. For example, if the time difference between adjacent events is greater than a specified number of threshold values, this may indicate that the chain is single event chain. [00146] In some examples, the specified activity is a higher-level task than producing the set of logs.

[00147] In some examples, the event chain is produced in response to a specified user interacting with a node in the computing network. For example, the user’s interaction with a service (provided by a host identified by ‘hostname’) may trigger the production of logs at the computing device (which may be at the node itself or another node in the computing network).

[00148] In some examples, the relationship condition is met where, for an identified event chain comprising a consecutive sequence of events, a time difference between adjacent events within the identified event chain is within each time range of at least a specified proportion of a set of different time ranges (i.e. , ‘relationship indicators’ or ‘thresholds’). The specified proportion may refer to a proportion of the set of different time ranges that is considered sufficient to indicate that the relationship condition is met. For example, if the chain remains stable (and does not split into sub-chains or merge into other chains) for enough of the set of different time ranges, then the relationship condition may be considered met.

[00149] In some examples, the relationship condition is met where for an identified event chain that is associated with a single event, a time difference between the single event and an adjacent event is larger than each time range of at least a specified proportion of the set of different time ranges. For example, the event chain may be associated with a single event providing enough (i.e., a specified proportion) of the set of different time ranges is below the time difference between the single event and an adjacent event.

[00150] In some examples, the relationship condition is met where, for an identified event chain comprising a consecutive sequence of events, at least a specified proportion of subroutines executed as part of each event are the same subroutine for each of the events in the identified event chain.

[00151] In some examples, the relationship condition is met where, for an identified event chain that is associated with a single event, fewer than a specified proportion of the subroutines executed as part of the single event are the same as the subroutines executed as part of an adjacent event.

[00152] An example of the implementation of how subroutine information is used to determine whether the relationship condition is met is given below. [00153] In an above example, the distance metric has been measured in terms of time, e.g., so that d(ev1,ev2) = abs(timediff(ev1,ev2)). However, the event information may include information about the subroutine sequences. For example, Event 1 = a.b.c.d and Event 2 = w.x.y.z. In this example, the subroutine sequences are organized, for example, hierarchically as system. subsystem. module. function (i.e., each of these are regarded as ‘subroutines’).

[00154] It is possible to define a distance metric as follows:

[00155] d(ev1 ,ev2) = 0 if a=w, b=x, c=y, d=z [00156] d(ev1,ev2) = 1 if a=w, b=x, c=y, d!=z

[00157] d(ev1,ev2) = 2 if a=w, b=x, c!=y, d!=z

[00158] d(ev1,ev2) = 3 if a=w, b!=x, c!=y, d!=z [00159] d(ev1,ev2) = 4 otherwise.

[00160] Then, the distance metric is in the set 0,1, 2, 3, 4 so that the distance is ‘smaller’ if there are more subroutines in common between the events.

[00161] In an example, for a relationship indicator of ‘2’, then the following two chains are created for the following sequence of events (assuming the relationship is a “less than or equals to” relationship). The sequence of events {a.b.c.d, a.b.c.e, a.b.c.d, a.b.y.z, a.x.y.z, a.x.m.n} maps to the two chains, {[a.b.c.d, a.b.c.e, a.b.c.d, a.b.y.z], [a.x.y.z.a.x.m.n]}.

[00162] In addition, the frequency of these chains may be used to determine whether they are “common” over multiple other “distances”, as per this metric. If they are frequent, and if the relationship condition is 60%, then both of these chains would be regarded as ‘stable’ since the condition is satisfied for 2,3,4 but not 0,1 (hence 3/5 = 60% of thresholds).

[00163] In some examples, the statistical condition is a specified number of repeated occurrences of the event chain within a time period or a specified proportion of a plurality of events within a time period being repeated occurrences of the event chain. For example, the statistical condition may be a minimum number such as >1000 and/or may be based on a CDF as described above.

[00164] In some examples, the statistical condition is met where the identified event chain occurs at least a specified number of times within a timeframe or a specified proportion of a plurality of events within a timeframe are repeated occurrences of the identified event chain. An identified relationship indicator (e.g., a threshold or number of subroutines across events) may be indicative of the identified event chain meeting the relationship condition. The identified relationship indicator may be from a set of relationship indicators. In some examples, the relationship indicator may be identified as being the most common relationship indicator from the set that is used for transforming the dataset into event chains corresponding to specified activities within the computing network. For example, the chains linked to the ‘optimal’ or ‘most common’ relationship indicator (i.e., an ‘optimal relationship indicator’) may be selected.

[00165] In some examples, in accordance with at least part of portion 402, the method 400 comprises generating a list of candidate event chains from the event information from the set of logs. The list of candidate event chains may be identified by selecting at least one relationship indicator from a set of relationship indicators for determining whether or not adjacent events are related to each other. The at least one selected relationship indicator may be used to identify, based on the event information from the set of logs, a list of candidate event chains. Each candidate event chain may have an associated parameter (e.g., time, duration of time, subroutine, etc.) which, when compared with the selected relationship indicator, may be indicative of the candidate event chain being potentially linked to the specified activity within the computing network. In response to determining that an identified candidate event chain meets the statistical condition, the method 400 may comprise adding the identified candidate event chain to the list of candidate event chains.

[00166] In some examples, in accordance with at least part of portion 406, the method 400 comprises selecting the identified candidate event chain from the list of candidate event chains; and comparing the associated parameter of the selected candidate event chain with the set of relationship indicators (i.e., determining whether the selected chain is stable). In response to a determination being made that a specified proportion of the comparisons between the associated parameter and the set of relationship indicators is indicative of the selected candidate event chain being linked to the specified activity within the computing network, the method 400 comprises determining that the selected candidate event chain meets the relationship condition and causing information regarding the selected candidate event chain to be recorded in the dataset.

[00167] In some examples, in accordance with the principle depicted by Figure 5, the method 400 comprises identifying which relationship indicator from the set of relationship indicators is most likely (e.g., the greatest number of ‘intersections’) for transforming the dataset into event chains corresponding to the specified activity within the computing network by determining which relationship indicator was used to identify the greatest number of candidate event chains in the list. The method 400 further comprises causing information regarding the identified relationship indicator to be recorded in the dataset.

[00168] The examples described above may be combined in any appropriate way. For example, examples which relate to further defining the event chain may be combined with each other and with examples which relate to: further defining the relationship condition; the statistical condition; generating and/or selecting candidate event chains; and determining metrics and/or outputting an alert. Any of these examples may be combined with each other and with any other examples described herein.

[00169] Figure 11 depicts a flowchart of an example method 1100, which may be a computer-implemented method, of determining information about an event chain. The information determined by the method 1100 may indicate whether the event chain is associated with a stable pattern of pattern and this information may be used to determine certain metrics about the computing network, as described herein. The method 1100 may be implemented by processing circuitry of a computing device implemented at a node within a computing network, as described above. The method 1100 may implement functionality of certain examples described above.

[00170] The method 1100 comprises, at block 1102, determining whether an event chain is associated with a specified activity within a computing network. The event chain is identified from a set of logs produced by a computing device in response to activities that occur within the computing network. Each log comprises event information indicative of an activity that caused the computing device to produce the log. The specified activity is a higher-level task than producing the set of logs. The association with the specified activity is determined from the event information from the set of logs by determining whether a duration of time associated with the event chain is indicative of a relationship condition being met by establishing whether the duration of time is within each of a minimum number of a set of different time ranges. The association with the specified activity is determined from the event information from the set of logs by further determining whether the event chain meets a statistical condition.

[00171] In response to determining that both: the relationship condition and the statistical condition are met, the method 1100 further comprises, at block 1104, causing information regarding the event chain to be recorded in a dataset.

[00172] The method 1100 further comprises, at block 1106, determining a pattern of activity within the computing network based on timestamps of consecutive occurrences of the event chain determined from the information in the dataset. [00173] In response to determining that the pattern of activity is unexpected, the method 1100 further comprises, at block 1108, outputting an alert.

[00174] Figure 12 schematically illustrates an example machine-readable medium 1200 (e.g., a tangible machine-readable medium) which stores instructions 1202 which, when executed by processing circuitry 1204 (e.g., at least one processor), cause the processing circuitry 1204 to carry out certain methods described herein (e.g., method 100, 400, 1100). The machine-readable medium 1200 may implement certain functionality within a node of the computing network.

[00175] In some examples, the instructions 1202 comprise instructions 1206 to cause the processing circuitry 1204 to implement the functionality of blocks 102 to 104 of the method 100. In some examples, the instructions 1202 comprises instructions 1206 to implement at least one of the blocks in the portions 402 to 407 of the method 400 and/or any other related examples. In some examples, the instructions 1202 comprises instructions 1206 to implement the blocks 1102 to 1108 of the method 1100.

[00176] Figure 13 schematically illustrates an example machine-readable medium 1300 (e.g., a tangible machine-readable medium) which stores instructions 1302 which, when executed by processing circuitry 1304 (e.g., at least one processor), cause the processing circuitry 1304 to carry out certain methods described herein. The machine-readable medium 1300 may implement certain functionality within a node of the computing network.

[00177] In this example, the instructions 1302 comprise instructions 1306 to identify, from event information derived from a record (e.g., a ‘log’) produced by a computing device within a computing network, a chain comprising at least one event that occurred within the computing network. The chain is identified based on the chain being potentially indicative of a specified activity within the computing network. The record is produced responsive to activities that occur within the computing network

[00178] The instructions 1302 further comprise instructions 1308 to, in response to determining that: the identified chain meets a statistical condition and a result of a comparison between a distance metric (e.g., a ‘parameter’) derived from the identified chain and a set of relationship indicators is indicative of a relationship condition being met, cause information regarding the identified chain to be recorded in a dataset.

[00179] Figure 14 schematically illustrates an example machine-readable medium 1400 (e.g., a tangible machine-readable medium) which stores instructions 1402 (comprising instructions 1302 of Figure 13) which, when executed by processing circuitry 1404 (e.g., at least one processor), cause the processing circuitry 1404 to carry out certain methods described herein. The machine-readable medium 1400 may implement certain functionality within a node of the computing network.

[00180] In some examples, the instructions 1402 further comprise instructions 1406 to determine a time-based metric from information regarding occurrences of the chain in the dataset. In response to determining that the time-based metric is indicative of an unexpected behavior in the computing network, the instructions 1406 are to output an update regarding the unexpected behavior.

[00181] In some examples, the instructions 1402 further comprise instructions 1408 to determine a time-based metric from information regarding occurrences of the chain in the dataset. The instructions 1408 further determine whether an additional record (e.g., an additional log) produced by the computing device is indicative of a change that has occurred. In an example, the change comprises the statistical condition no longer being met and/or the result of the comparison no longer being indicative of the relationship condition being met. In another example, the change comprises a number of occurrences of a different identified chain being indicative of the statistical condition being met. The different identified chain may be potentially indicative of a different specified activity within the computing network. A result of a comparison between a distance metric derived from the different identified chain and the set of relationship indicators may be indicative of the relationship condition being met. In response to determining that the change has occurred, the instructions 1408 are to update the dataset with information regarding the change.

[00182] Figure 15 is a schematic illustration of an example apparatus 1500 for implementing or at least partially facilitating certain methods or machine-readable media described herein (e.g., certain blocks of methods 100, 400, 1100 or certain instructions of machine-readable media 1200, 1300, 1400). The apparatus 1500 comprises at least one processor 1502 communicatively coupled to an interface 1504 (e.g., implemented by a communication interface) for communicating with another node in the computing network. In an example, the interface may receive information, via the interface 1504, from another node, which information is used by the apparatus 1500 when implementing certain methods or machine-readable media described herein. In another example, the interface may transmit information such as an information for a dataset, an ‘output’ and/or ‘alert’ via the interface 1504. The apparatus 1500 further comprises a tangible machine-readable medium 1506 (e.g., ‘memory’) storing instructions 1508 readable and executable by the at least one processor 1502 to perform a method according to various examples described herein (e.g., certain blocks of method methods 100, 400, 1100) or implement the functionality of machine-readable media instructions according to various examples described herein (e.g., certain instructions of machine-readable media 1200, 1300, 1400).

Determining Chain Periodicity Metrics

[00183] The section above describes how certain information and insights can be derived from raw event data. This section describes examples of how such information and insights can be used.

[00184] Raw event streams may be examined to analyze activity (e.g., user web activity), detect anomalous activity and/or detect misconfigurations or interesting activity in a network. As referred to in the section above, logs may be produced by nodes such as networked collectors, printers and loT devices, etc. In some cases, time difference metrics are influenced by co-occurring events (e.g., multiple consecutive events) which represent a single interaction (or ‘task’, ‘action’, or ‘transaction’). The informational content and value of an interaction may be held exclusively by the first event in a sequence, since this event signals the start of an interaction. Taking the time differences of the subsequent events in an interaction into account may lead to disturbances of the time difference metric. In other similar words, depending on the timing of the various events that occur in a network, any analysis of the activity within the network based on the timing information may lead to a misinterpretation of the data.

[00185] In some examples, the timing information may be used to detect periodicity of events in the data. Periodicity may be indicative of anomalous behavior such as ‘beaconing’, which may be indicative of malware being present in the network.

[00186] There are several scenarios that may cause issues when using time difference metrics to analyze the periodicity of signals.

[00187] Figure 16 depicts an example scenario involving multiple events in a timeline. In this example scenario, there is a low time resolution of the log timestamps. For example, a time difference metric may define a signal as ‘periodic’ because the time resolution is defined in seconds rather than milliseconds. The signal shown in Error! Reference source not found.6 is clearly aperiodic. However, since the time resolution does not take milliseconds into consideration, the signal appears to send bursts of 3 messages every second. This signal characteristic may falsely be detected as ‘periodic’ (i.e. , a ‘false positive’).

[00188] Figure 17 depicts another example scenario involving multiple events in a timeline. In this example scenario, single events that can be part of co-occurring logs (i.e. logs that are triggered by the same interaction and therefore appear together - in Figure 17 this is a dark grey event co-occurring with a light grey event) may also appear in isolation (i.e. , a light grey event without an adjacent dark grey event). A single event that is part of a bigger transaction (such as the light grey event shown in Error! Reference source not found.17) may be detected as aperiodic since the single light grey events reduce the overall periodicity of the light grey event signal. However, the underlying interaction chain (dark grey followed by light grey) is clearly periodic. In this case, looking at the light grey event stream in isolation results in a false classification of the periodicity of the interactions. In other words, the result of a time metric analysis may be a false negative for periodicity.

[00189] Figure 18 depicts another example scenario involving multiple events in a timeline. Figure 18 is the opposite scenario to that of Figure 17. In this scenario, an event signal that is formed of co-occurring messages that, when grouped together in a transaction, is clearly aperiodic. However, looking at the light grey event in isolation results in a false ‘periodic’ classification. By extracting the light grey event in combination with the dark grey event, the overall periodicity of the light grey event signal is reduced. In other words, the extraction may result in a false positive for periodicity. Exclusively measuring the time differences between the single light grey events may result in detecting a more periodic signal than is actually the case.

[00190] Examples described herein may provide a way of removing false-positives and false-negatives by feeding time difference metrics with a ‘cleaner’ signal using, for example, the first timestamp in an interaction (which is an example of a relevant timestamp since it signals the start of an interaction). The above section regarding identifying event chains is referred to in this section since it refers to identifying or distinguishing between different event chains (or ‘interaction chains’).

[00191] In some examples, the low time resolution of event streams and/or the interpretation of single events without a context may cause the time difference metrics to detect periodicity in data where there is none or vice versa. Therefore, by aggregating and transforming event logs (e.g., as described in the above section) prior to determining the time differences between events, it may be possible to derive a ‘cleaner’ event signal and hence derive a ‘true’ periodicity of the interaction chains, thus reducing false positives and false negatives.

[00192] Figure 19 depicts a flowchart of an example method 1900, which may be a computer-implemented method, of determining information about chain periodicity. In some examples, the information determined by the method 1900 may be used to determine information that may not otherwise be observable (e.g., false positives, false negatives, etc.) based on an analysis of a single event signal. The method 1900 may be implemented by processing circuitry of a computing device implemented at a node within a computing network, as described in the section above.

[00193] The method 1900 comprises determining, at block 1902, temporal data (e.g., time difference data, timestamps, etc.) from adjacent occurrences of a specified event chain in a dataset. The dataset comprises a set of identified event chains. Each event chain in the set is identified as being potentially associated with a stable pattern of activity within a computing network based on a determination that both: a parameter derived from the identified event chain meets a relationship condition indicative of the identified event chain being linked to a specified activity within the computing network; and the identified event chain meets a statistical condition.

[00194] In some examples, the temporal data may refer to any timing information derived from the timestamps of the specified event chain (e.g., the start point of each occurrence of the specified chain). The timing information could be the timestamps themselves, a time difference between adjacent timestamps, or some other indication of the ‘distance’ between adjacent occurrences of the specified event chain.

[00195] The method 1900, at block 1902, further comprises determining a chain periodicity metric from the temporal data. The chain periodicity metric may be indicative of a proportion of the occurrences of the specified event chain that follow a periodic pattern.

[00196] In some examples, determining the chain periodicity metric may comprise applying a modular arithmetic operation to the temporal data, and applying a statistical operation to a result of the modular arithmetic operation to determine the chain periodicity metric.

[00197] In some examples, a modular arithmetic operation may be performed on the difference between the timestamps of adjacent occurrences of the specified event chain. The modular arithmetic operation may be performed in relation to an integer such as a prime number. An example operation would be dividing the time difference (e.g., Ί0’ seconds) by an integer such as 7’. This example operation (10 mod 7) results in the value ‘3’.

[00198] In some examples, a statistical operation may collect the results from the modular arithmetic operation and indicate whether or not there is periodic behavior, or a percentage of the results that exhibit periodic behavior. If the distribution of all the values modulo 7 (from the example above) are reasonably ‘consistent’ and similar, this may indicate periodicity (i.e., since the result of operation is relying on the signal periodicity and the modulus being coprime). For example, the number of time differences that result in the value 3 being calculated by the modular operation compared with the number of time differences that result in another value being calculated may be examined. The distribution of the results from the modular arithmetic operations may provide information regarding the periodicity (e.g., a similar number of values of ‘3’ compared to the other values may indicate those chains that are associated with the analysis are periodic).

[00199] In some examples, the chain periodicity metric may be provided as a ratio (e.g., a proportion of time or occurrences that correspond to periodic behavior by the specified event chain). For example, the proportion of occurrences could be a ‘number’ of times which correspond to periodicity, or working out the number of time slots within a time period that contain occurrences of the event chain that are associated with the periodic behavior.

[00200] Thus, the ratio may be determined in terms of the time within a timeframe where periodic behavior is observed and/or as a percentage of the event chains forming part of a periodic signal.

[00201] In an example, without event chains being identified, an event Ί3’, say, may beacon 10% of the time. This means that 10% of the occurrences of Ί3’ are part of a periodic sequence. When the event chains are extracted, the percentage of such associations beginning with Ί3’ may be higher, say 60%. That is, of all event chains beginning with Ί3’, 60% of them form part of a periodic sequence. Likewise, it is possible to obtain the chain periodic metric as a ratio of time. This can indicate that without event chains, there may be correlations and/or causations with other events (such as ‘A’, ‘C’, etc.) that break some of this periodicity. The event chains may indicate that perhaps ‘B’ is periodic, and this would not have been revealed without the event chains.

[00202] Other example methods of detecting periodicity in signals include autocorrelation, a rolling mean, and an Auto Regressive Integrated Moving Average (ARIMA) model. A statistical operation as described above may be applied to the result of these example methods to determine the periodicity metric.

[00203] The method 1900 further comprises, at block 1904, causing information regarding the determined chain periodicity metric to be recorded in a dataset.

[00204] This information may be used in various ways for data analytics. Such information may reveal additional insights into the network that would not otherwise be directly observable by applying data analytics to the raw event data. [00205] Certain methods described herein (including method 1900) may provide certain technical functions. For example, on its own, the raw data produced within the computing network may be difficult to analyze due to, for example, the amount of information produced, the lack of contextual understanding for each of the data points and/or the lack of intuition about whether there is any connection (or lack of connection) between the data points. Thus, when performing data analytics on the raw data, there may be no information that can identify certain types of behavior that may be of interest (e.g., periodic behavior, masking behavior, etc., associated with event chains).

[00206] Certain methods described herein (including method 1900) may remove noise in time difference metrics. By aggregating the event data as described in the above section and performing temporal analysis on the resulting chains, it may be possible to disregard redundant or misleading timing signals.

[00207] When performing data analytics, the level of confidence may be such that additional insight can be derived about the behavior within the computing network that is not directly identifiable from the raw data. Further, there may be less data to analyze or the data may be less ‘noisy’ if the data is organized into event chains.

[00208] In some examples, by determining the chain periodicity metric from the temporal data based on the identified chains, this information may provide an improved or complementary understanding of behavior in the computing network. Such information may be leveraged to identify periodic behavior and/or masking behavior, which may represent a security or privacy issue.

[00209] In some examples, certain methods described herein (including method 1900) may improve identification of unexpected and/or inappropriate behavior in the network, extract more meaningful information than would otherwise be observable from the raw data, reduce the probability of returning false negatives/positives, reduce data volumes and thus lead to more efficient computation to achieve valuable results and insights in less time. Further, processing and/or storage resource may be better deployed when performing data analytics using the information derived according to certain methods described herein (including method 1900), compared with performing data analytics on raw data alone.

[00210] An example application which may use the approach of certain examples described herein may include analyzing data telemetry from networked nodes comprising embedded systems (such as in a printer). However, applications may extend beyond data telemetry such as in analyzing web activity. Further, the results from examples described herein may have implications beyond security or privacy issues such as examining general network performance, admin activity and any other activity on a network that may of interest to network administrators, etc.

[00211] Certain examples described herein may provide a way of identifying regular patterns in data streams by ‘cleaning’ the data and then applying periodicity detection to gain an improved understanding of the behavior in the network. In the example application given above, automated processes operating on fleets of printers may be identified as well as detecting changes in behavior. Such processes or changes can then be reported to analysts and experts, or even directly to the customer in the form of an alert or a report.

[00212] In addition, the results provided by certain examples described herein may be useful for providing, for example, a more insightful notion of periodicity of events by looking at chains (of interactions), an automated analysis and detection on the data and/or a tool for more manual human triage and investigation of the data.

[00213] A description is now given of an example procedure for extracting the metrics from the chain data, as described the above section on identifying event chains.

[00214] Figure 20 depicts a flowchart of an example method 2000, which may be a computer-implemented method, of determining information about chain periodicity. The method 2000 implements functionality corresponding to the method 1900 as well as the functionality described in relation to certain examples described below. The method 2000 may be implemented by processing circuitry of a computing device implemented at a node within a computing network, as described in the section above. Certain blocks may be omitted as indicated below and/or the method 2000 may be implemented in a different order to that shown by Figure 20.

[00215] The method 2000 refers to certain variables and data structures as set out in more detail below.

[00216] 1_chains’ refers to a list of identified event chains such as the candidate event chains.

[00217] ‘R_DATA’ refers to the raw dataset (i.e. , comprising the set of logs or event information derived from such logs).

[00218] ‘l_DATA’ is a translation of the ‘R_DATA’ into a dataset that comprises any chains listed in 1_chains’. These event chains may or may not refer to the list of ‘stable’ chains which are obtained as described above. In some examples, the list of stable event chains is further refined based on which relationship indicator resulted in the most stable event chains.

[00219] ‘EVENTS’ refers to a list of distinct, single, events seen in the dataset. For example, [A,B,C].

[00220] 1_periodicity’ refers to a dictionary inputted on distinct ‘EVENTS’ in the dataset (e.g., logs).

[00221] For each event in ‘EVENTS’, 1_periodicity[event]’ refers to a dictionary which stores statistics for the time difference metrics for the individual event (i.e. , the input is ‘INDIVIDUAL’), and the statistics for time difference metrics for any chains in l_DATA beginning with event. In some examples, the statistics may be percentage of instances where that chain is part of a periodic signal. For example, if chain A->A->B beacons 80% of the time, then 0.8 is stored.

[00222] An example dataset (timestamp omitted for brevity) based on the above variables is described below.

[00223] R_DATA = [‘A’, ‘A’, ‘B’, ‘B’, ‘A’, ‘A’, ‘C’, ‘A’, ‘C’, Ό’]. This is an example sequence of events.

[00224] l_chains = [‘A-^A-^B’, ‘B-^A’, Ά-CT]. Thus, there are three chains in the list in this example.

[00225] l_DATA = [‘A^A^B’, ‘B^A’, ‘A^C’, ‘A^C’, Ό’]. There are five event chains or events that may or may not be considered stable.

[00226] EVENTS = [‘A’,’B’,’C’, Ό’]. These are the individual events.

[00227] Example statistics for the periodicity of the chains and events are described below, for example:

[00228] Lperiodicity =

[00229] { “A”: {“INDIVIDUAL”:0.37, “A^B”:0.7,“A^A^B”:0.8, “A”:0.4},

[00230] “B”: {“INDIVIDUAL”:0.02, “B^A”:0.23},

[00231] “C” : {“I NDIVI DUAL”:0.31},

[00232] “D” : {“I NDIVI DUAL”:0.31 , “D”:0.2}}.

[00233] Notice that because no chain begins with event ’C’, there are no corresponding chains stored in l_periodicity[‘C’]; leaving the result for the INDIVIDUAL calculation. Note that in l_DATA, ‘D’ forms a chain of length ‘T. In this example, the values associated with each event or chain refers to a periodicity metric such as the proportion of time where periodic behavior for that event or chain is observed.

[00234] Referring now to Figure 20, the method 2000 comprises, at block 2002, generating a list of event chains 1_chains’ as described above.

[00235] In some examples, the method 2000 further comprises, at block 2004, determining the optimal relationship indicator. This information may be used to filter down the list of identified event chains.

[00236] The above procedure of block 2002 (and in some examples block 2004) translates the raw dataset ‘R_DATA’ into a dataset comprising event chains ‘l_DATA’ and any other event information that may be needed. Again, note that some chains may have length Ί event’. These are the individual datapoints that may still be regarded as chains.

[00237] The method 2000 further comprises, at block 2006, for each distinct event ‘EVENT’ in ‘R_DATA’, calculating the time difference metric. This provides an indication of the periodicity for each event in the series. In some examples, the time difference metric may indicate how often each distinct event is classified as ‘beaconing’. The result of block 2006 is stored in ‘l_periodicity[EVENT][l N Dl VI DUAL]’.

[00238] The method 2000 further comprises, at block 2008, for each distinct ‘CHAIN’ in ‘l_DATA’, calculating the time difference metric for each relationship indicator. In some examples, this time difference metric provides an indication regarding how often each chain is classified as ‘beaconing’.

[00239] As part of block 2008, the method 2000 comprises finding the ‘EVENT’ with which ‘CHAIN’ starts (e.g. for CHAIN = ‘A- -^B’ this is ‘A’). The results for each such distinct chain in ‘l_DATA’ (of length 1 or otherwise) are stored in 1_pehodicity[EVENT][CHAIN]’. Note that this means that if an ‘EVENT’ is never the start of a chain, ‘l_periodicity[EVENT]’ contains the dictionary with the input ‘INDIVIDUAL’ (as is the case for EVENT ‘C’ in the above example).

[00240] In some examples, the method 2000 further comprises, at block 2010, determining the periodicity of data as a percentage of time or occurrences where periodic behavior is observed in the data.

[00241] In some examples, the method 2000 further comprises, at block 2012, comparing the output of blocks 2006 and 2008 (e.g., by calculating a difference or a ratio between the values). The comparison may be referred to as a ‘noise ratio’ and is described in more detail below. [00242] Thus, in some examples, the method 2000 further comprises, at block 2014, obtaining or recording (e.g., in the dataset) the noise ratios for associated with each event. In an example, the noise ratio is the difference of the periodicity percentages of 1_periodicity[EVENT][INDIVIDUAL]’ and 1_periodicity[EVENT][CHAIN]’. Other noise ratios may be calculated, for example, by taking a ratio of these values.

[00243] The data output by the method 2000 may be used to provide certain insights. For example, if the noise ratio is high, this may alert that there is a periodicity in the dataset which is being hidden by irregular co-occurrences of events. This information can be used adjust how subsequent processing of the data. For example, analytics may be deployed that targets the subsequent processing and classification of periodic events.

[00244] In this regard, the method 2000 further comprises, at block 2016, analyzing and/or recording the data (e.g., any of the metrics obtained by the method 2000) in a dataset and, if needed, outputting an alert (e.g., in response to determining that periodicity in the data is a potential concern about activity in the network). Examples of how the data is analyzed are given below. In some examples, an alert threshold may be defined such as a periodicity value which, when exceeded, indicates there is a concerning level of periodicity associated with the chain.

[00245] Some examples relating to the above methods are described below.

[00246] In some examples, in response to determining that the proportion of the occurrences of the specified event chain follow the periodic pattern is above an alert threshold, the method further comprises outputting an alert (e.g., as referred to in block 2016).

[00247] In some examples, each event chain in the set is identified from a set of logs produced by a computing device within the computing network in response to activities that occur within the computing network. Each log comprises event information indicative of an activity that caused the computing device to produce the log. The association with the stable pattern of activity is determined from the event information from the set of logs. This example is referred to in the section above regarding identifying event chains.

[00248] In some examples, the specified activity within the computing network is a higher-level task than producing, by the computing device, the set of logs. This example is referred to in the section above regarding identifying event chains.

[00249] In some examples, the relationship condition is met where, for an identified event chain comprising a consecutive sequence of events, a time difference between adjacent events within the identified event chain is within each time range of at least a specified proportion of a set of different time ranges. This example is referred to in the section above regarding identifying event chains.

[00250] In some examples, the relationship condition is met where, for an identified event chain that is associated with a single event, a time difference between the single event and an adjacent event is larger than each time range of at least a specified proportion of the set of different time ranges. This example is referred to in the section above regarding identifying event chains.

[00251] In some examples, the relationship condition is met where, for an identified event chain comprising a consecutive sequence of events, at least a specified proportion of subroutines executed as part of each event are the same subroutine for each of the events in the identified event chain. This example is referred to in the section above regarding identifying event chains.

[00252] In some examples, the relationship condition is met where, for an identified event chain that is associated with a single event, fewer than a specified proportion of the subroutines executed as part of the single event are the same as the subroutines executed as part of an adjacent event. This example is referred to in the section above regarding identifying event chains.

[00253] In some examples, the statistical condition is a specified number of repeated occurrences within a timeframe or a specified proportion of a plurality of events within a timeframe being repeated occurrences of the identified event chain. This example is referred to in the section above regarding identifying event chains.

[00254] In some examples, the statistical condition is met where the identified event chain occurs at least a specified number of times within a timeframe or a specified proportion of a plurality of events within a timeframe are repeated occurrences of the identified event chain. The statistical condition may further be met where an identified relationship indicator is indicative of the identified event chain meeting the relationship condition. The identified relationship indicator is from a set of relationship indicators, and is identified as being the most common relationship indicator from the set that is used for transforming the dataset into event chains corresponding to specified activities within the computing network. This example is referred to in the section above regarding identifying event chains.

[00255] In some examples, the method comprises determining an event periodicity metric from timestamps of adjacent occurrences of a specified type of event (e.g., as part of a specified type of activity) within the time period (e.g., in accordance with block 2010 of the method 2000 where the periodicity percentage is an example of an event periodicity metric). The timestamps may be determined from event information derived from a set of logs produced by a computing device within the computing network in response to each occurrence of the specified type of event within the computing network. The method further comprises causing information regarding the determined event periodicity metric to be recorded in the dataset (e.g., in accordance with part of block 2016 of the method 2000).

[00256] In some examples, the method comprises determining a noise metric based on a comparison between the event periodicity metric and the chain periodicity metric (e.g., in accordance with part of block 2016 of the method 2000). The method may further comprise causing information regarding the noise metric to be recorded in the dataset (e.g., also in accordance with part of block 2016 of the method 2000).

[00257] As an example, a fraction, such as A[‘A->B’] / A[individual] (making adjustments where to avoid dividing by 0, etc.), may be calculated as the ‘noise metric’. That is, ‘A-^B’ is a chain and has an associated chain periodicity metric. Similarly, event ‘A’ by itself has an associated ‘chain’ periodicity metric. The ratio of these metrics may provide insights regarding whether or not co-occurring events are masking behavior or distorting how activity in the network is perceived by data analytics.

[00258] Example comparisons include a ‘difference’ (e.g., subtraction) or a fraction.

[00259] The discrepancy between the two values may be represented by noise metric. In an example, if the above fraction is larger, (say, much bigger than 1), then that may indicate that the chain ‘A->B’ beacons more frequently than ‘A’ by itself, which could be an interesting activity to analyze.

[00260] In some examples, the method comprises comparing the noise metric with a masking threshold to determine whether or not the noise metric is indicative of masking behavior within the computing network (e.g., in accordance with part of block 2016 of the method 2000). In response to determining that the noise metric is indicative of masking behavior, the method 2000 further comprises outputting a corresponding alert (e.g., in accordance with part of block 2016 of the method 2000).

[00261] There may be scenarios where beaconing or other interesting activity occurs in the network that may be revealed by the noise metric. Whether the noise metric is ‘low’ or ‘high’ may provide an indication about such activity. [00262] In an example, an event Ί3’ may be the start of a chain (or be a chain by itself), or Ί3’ might be caused by ‘A’ (i.e., A-^B are associated with a ‘specified activity’). If ‘A’ is aperiodic but ‘B’ is otherwise periodic, then the A-^B relationship and the fact that ‘A’ is aperiodic can mask the fact that ‘B’ is actually periodic. In this manner, the additional insight provided by identifying the event chains can help reveal this hidden periodicity.

[00263] In some examples the method comprises, prior to determining the temporal data, generating a list of candidate event chains from event information activities events that occur within the computing network. The event information is derived from a set of logs produced by a computing device within the computing network in response to the activities. Generating the list comprises selecting at least one relationship indicator from a set of relationship indicators for determining whether or not adjacent events are related to each other. Generating the list further comprises using the at least one selected relationship indicator to identify, based on the event information from the set of logs, a list of candidate event chains, each candidate event chain having an associated parameter which, when compared with the selected relationship indicator, is indicative of the candidate event chain being potentially linked to the specified activity within the computing network. In response to determining that an identified candidate event chain meets the statistical condition, the method further comprises adding the identified candidate event chain to the list of candidate event chains. In response to determining that the identified candidate event chain is potentially associated with the stable pattern of activity within the computing network, the method further comprises recording information about the identified candidate event chain to the dataset comprising the set of identified event chains. This example is referred to in the section above regarding identifying event chains.

[00264] In some examples, the method comprises identifying which relationship indicator from the set of relationship indicators is most likely for transforming the dataset into event chains corresponding to the specified activity within the computing network by determining which relationship indicator was used to identify the greatest number of candidate event chains in the list (e.g., in accordance with block 2004 of the method 2000). The method may further comprise causing information regarding the identified relationship indicator to be recorded in the dataset (as shown by Figure 20).

[00265] In some examples, the list of all stable chains may be useful for certain analysis according to various examples described herein. In some examples, a sub-selection is made from the list of stable chains based on an ‘optimal’ relationship indicator from the set of relationship indicators. This sub-selection may be used in various methods described herein such as methods 1900 and 2000. [00266] The optimal relationship indicator may be useful for determining the event chains. Because the relationship indicators may be fixed values, there may be some stable chains that may be discounted if they are not stable for that particular relationship indicator. This is because, in some examples, it may not be appropriate to have more than one relationship indicator used to generate a given dataset. Therefore, the ‘optimal’ relationship indicator may be the one that maximizes the number of stable chains. Such an approach may be useful where there are, for example, 10 candidate chains, but no choice of relationship indicator that results in all 10 getting selected. However, there may be two choices of relationship indicators where 9 chains emerge. In that case, one chain that might have been stable at another relationship indicator selection may have to be discarded.

[00267] Figure 21 depicts a flowchart of an example method 2100, which may be a computer-implemented method, of determining information about chain periodicity and generating a response such as an alert. The method 2100 may be implemented by processing circuitry of a computing device implemented at a node within a computing network, as described above. The method 2100 may implement functionality of certain examples described above.

[00268] The method 2100 comprises, at block 2102, determining temporal data from adjacent occurrences of a specified event chain in a dataset comprising a set of identified event chains. Each event chain in the set is identified as being potentially associated with a stable pattern of activity within a computing network based on a determination. The determination is that both: a duration of time associated with the identified event chain is indicative of a relationship condition being met by establishing whether the duration of time is within each of a minimum number of a set of different time ranges; and the identified event chain meets a statistical condition.

[00269] The method 2100 further comprises, at block 2104, determining a chain periodicity metric from the temporal data. The chain periodicity metric is indicative of a proportion of the occurrences of the specified event chain that follow a periodic pattern.

[00270] The method 2100 further comprises, at block 2106, determining an event periodicity metric from timestamps of adjacent occurrences of a specified type of event (e.g., as part of a specified type of activity). The timestamps are determined from event information derived from a set of logs produced by a computing device within the computing network in response to each occurrence of the specified type of event within the computing network. [00271] The method 2100 further comprises, at block 2108, determining a noise metric based on a comparison of the event periodicity metric and the chain periodicity metric.

[00272] The method 2100 further comprises, at block 2110, comparing the noise metric with a masking threshold to determine whether or not the noise metric is indicative of masking behavior within the computing network.

[00273] In response to determining that the noise metric is indicative of masking behavior, the method 2100 further comprises, at block 2112, outputting a corresponding alert.

[00274] Figure 22 schematically illustrates an example machine-readable medium 2200 (e.g., a tangible machine-readable medium) which stores instructions 2202 which, when executed by processing circuitry 2204 (e.g., at least one processor), cause the processing circuitry 2204 to carry out certain methods described herein (e.g., method 1900, 2000, 2100). The machine-readable medium 1200 may implement certain functionality within a node of the computing network.

[00275] In some examples, the instructions 2202 comprise instructions 2206 to cause the processing circuitry 2204 to implement the functionality of blocks 1902 to 1904 of the method 1900. In some examples, the instructions 2202 comprises instructions 2206 to implement at least one of the blocks of the method 2000 and/or any other related examples. In some examples, the instructions 2202 comprises instructions 2206 to implement the blocks 2102 to 2112 of the method 2100.

[00276] Figure 23 schematically illustrates an example machine-readable medium 2300 (e.g., a tangible machine-readable medium) which stores instructions 2302 which, when executed by processing circuitry 2304 (e.g., at least one processor), cause the processing circuitry 2304 to implement similar functionality of certain methods or machine-readable media described herein (e.g., method 1900). The machine-readable medium 2300 may implement certain functionality within a node of the computing network.

[00277] In this example, the instructions 2302 comprise instructions 2306 to determine time difference data from a dataset comprising information regarding adjacent occurrences of an identified chain comprising at least one event. The chain is identified, from event information derived from a record produced by a computing device within a computing network, responsive to a determination being made that both: a result of a comparison between a distance metric derived from the identified chain and a set of relationship indicators is indicative of a relationship condition being met; and the identified chain meets a statistical condition. [00278] The instructions 2302 further comprise instructions 2308 to determine a chain periodicity metric from the time difference data. The chain periodicity metric is indicative of the identified chain following a periodic pattern.

[00279] The instructions 2302 further comprise instructions 2310 to cause information regarding the determined chain periodicity metric to be recorded in a dataset.

[00280] Figure 24 is a schematic illustration of an example apparatus 2400 for implementing or at least partially facilitating certain methods or machine-readable media described herein (e.g., certain blocks of methods 1900, 2000, 2100 or certain instructions of machine-readable media 2200, 2300). The apparatus 2400 comprises at least one processor 2402 communicatively coupled to an interface 2404 (e.g., implemented by a communication interface) for communicating with another node in the computing network. In an example, the interface may receive information, via the interface 2404, from another node, which information is used by the apparatus 2400 when implementing certain methods or machine-readable media described herein. In another example, the interface 2404 may transmit information such as an information for a dataset, an ‘output’ and/or ‘alert’ via the interface 2404. The apparatus 2400 further comprises a tangible machine- readable medium 2406 (e.g., ‘memory’) storing instructions 2408 readable and executable by the at least one processor 2402 to perform a method according to various examples described herein (e.g., certain blocks of method methods 1900, 2000, 2100) or implement the functionality of machine-readable media instructions according to various examples described herein (e.g., certain instructions of machine-readable media 2200, 2300).

[00281] The examples described above may be combined in any appropriate way. For example, examples which relate to applying the modular arithmetic operation, statistical operation and outputting alerts may be combined with each other and with examples which relate to: further defining the relationship condition; the statistical condition; generating and/or selecting candidate event chains; and determining metrics and/or outputting an alert. Any of these examples may be combined with each other and with any other examples described herein. In addition, any examples in the section on identifying event chains may be combined with or used to modify any examples in the present section on determining metrics, and vice versa.

[00282] Any of the blocks, nodes, instructions or modules described in relation to the figures may be combined with, implement the functionality of or replace any of the blocks, nodes, instructions or modules described in relation to any other of the figures. For example, methods may be implemented as machine-readable media or apparatus, machine-readable media may be implemented as methods or apparatus, and apparatus may be implemented as machine-readable media or methods. Further, any of the functionality described in relation to any one of a method, machine readable medium or apparatus described herein may be implemented in any other one of the method, machine readable medium or apparatus described herein. Any claims written in single dependent form may be re-written, where appropriate, in multiple dependency form since the various examples described herein may be combined with each other.

[00283] Examples in the present disclosure can be provided as methods, systems or as a combination of machine-readable instructions and processing circuitry. Such machine-readable instructions may be included on a non-transitory machine (for example, computer) readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon.

[00284] The present disclosure is described with reference to flow charts and block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow charts described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. It shall be understood that each block in the flow charts and/or block diagrams, as well as combinations of the blocks in the flow charts and/or block diagrams can be realized by machine readable instructions.

[00285] The machine-readable instructions may, for example, be executed by a general-purpose computer, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing circuitry, or a module thereof, may execute the machine-readable instructions. Thus, functional nodes, modules or apparatus of the system and other devices may be implemented by a processor executing machine readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term ‘processor’ is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate array etc. The methods and functional modules may all be performed by a single processor or divided amongst several processors.

[00286] Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. [00287] Such machine readable instructions may also be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices realize functions specified by block(s) in the flow charts and/or in the block diagrams.

[00288] Further, the teachings herein may be implemented in the form of a computer program product, the computer program product being stored in a storage medium and comprising a plurality of instructions for making a computer device implement the methods recited in the examples of the present disclosure.

[00289] While the method, apparatus and related aspects have been described with reference to certain examples, various modifications, changes, omissions, and substitutions can be made without departing from the scope of the present disclosure. It is intended, therefore, that the method, apparatus and related aspects be limited by the scope of the following claims and their equivalents. It should be noted that the above- mentioned examples illustrate rather than limit what is described herein, and that many implementations may be designed without departing from the scope of the appended claims. Features described in relation to one example may be combined with features of another example.

[00290] The word “comprising” does not exclude the presence of elements other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims.

[00291] The features of any dependent claim may be combined with the features of any of the independent claims or other dependent claims.