Patent ID: 12212582

DETAILED DESCRIPTION

Many of the current cyber defence technologies are “single point solutions”, each of which operates with a narrow focus on a specific cyber defence task. As a consequence, many critical systems are currently protected by a multitude of single point solutions that operate independently and disjointedly. This lack of coordination results in “blind spots” which attackers are able to exploit by bypassing the single point solutions individually. Over the years, attackers have developed numerous methods for bypassing single point cyber defence solutions, which makes these blind spots a significant source of vulnerability.

Another problem with existing cyber defence technologies is one of over-reporting. That is, where an excessive volume of alerts or warnings may be triggered by network activity which appears suspect according to a certain set of applied criteria, but which often turns out to be legitimate. This problem is exacerbated by the use of multiple single point solutions, and grows as the number of single point solutions in use grows. Moreover, where different solutions use different reporting systems, as is common, their outputs as a whole are even harder to manage and interpret meaningfully.

An integrated cyber defence platform is disclosed herein, which provides overarching protection for a network against cyberattacks, through a combination of comprehensive network and endpoint data collection and organization, and advanced analytics applied to the resulting output. The platform operates according to an “observation-hypothesis-action” model, as will now be described. This may also be referred to herein as triangulation.

A key feature of the platform it its ability to collect and link together different types of event, and in particular (i) network events and (ii) endpoint events. This occurs at various places within the system, as described below.

Network events are generated by collecting raw network data from components (sub-systems, devices, software components etc.) across a monitored network, and re-structuring the raw network data into network events. The raw network data can for example be obtained through appropriate network tapping, to provide a comprehensive overview of activity across the network.

Endpoint events are generated using dedicated endpoint monitoring software in the form of endpoint agents that are installed on endpoints of the network being monitored. Each endpoint agent monitors local activity at the endpoint on which it is installed, and feeds the resulting data (endpoint data) into the platform for analysis.

This combination of endpoint data with network data is an extremely powerful basis for cyber defence.

In a data optimization stage, observations are captured in the form of structured, timestamped events. Both network events and endpoint events are collected at this stage and enhanced for subsequent analysis. Events generated across different data collectors are standardized, as needed, according to a predefined data model. As part of the data optimization, first stage enrichment and joining is performed. This can, to some extent at least, be performed in real-time or near-real time (processing time of around 1 second or less). That is, network and endpoint events are also enriched with additional relevant data where appropriate (enrichment data) and selectively joined (or otherwise linked together) based on short-term temporal correlations. Augmentation and joining are examples of what is referred to herein as event enhancement.

In an analytics stage, these enhanced network events are subject to sophisticated real-time analytics, by an analysis engine. This includes the use of statistical analysis techniques commonly known as “machine learning” (ML). The analysis is hypothesis-based, wherein the likelihood of different threat hypotheses being true is assessed given a set of current or historic observations.

One component of this analysis is the consideration of longer-term temporal correlations between events, and in particular different types of event such as network and endpoint event. Events that appear to be related are grouped into “cases” over time, as they arrive at the analysis engine. A case corresponds to one or more threat hypotheses. Each case has at least one assigned threat score, denoting the threat level indicated by its constituent events.

The creation and subsequent population of cases is driven by the results of analysing incoming events. A case is created for at least one defined threat hypothesis in response to an event that is classed as potentially malicious, and populated with data of that event. That is, each case is created in response to a single event received at the analysis engine. It is noted however that the event that causes a case to be created can be a joined event, which was itself created by joining two or more separate events together, an enriched event, or both.

Once a case has been created, it may be populated with data of subsequently received events that are identified as related to the case in question (which again may be joined and/or augmented events) in order to provide a timeline of events that underpin the case.

A case may alternatively or additionally be populated with data of one or more earlier events (i.e. earlier than the event or events that triggered its creation). This is appropriate, for example, where the earlier event(s) is not significant enough in itself to warrant opening a case (e.g. because it is too common), but whose potential significance becomes apparent in the context of the event(s) that triggered the creation of the case.

An event itself does not automatically create a case. An event may be subject to analysis (which may take into account other data—such as other events and/or external datasets) and it is the result of this analysis which will dictate if it will culminate in the creation of a new case or update of an existing case. A case can be created in response to one event which meets a case creation condition, or multiple events which collectively meet a case creation condition.

The criteria according to which cases are created and subsequently populated based on incoming events can be formulated around the “Mitre ATT&CK framework” or any other structured source of attack knowledge, as described later.

Generally, the threat score for a newly-created case will be low, and it is expected that a large number of cases will be created whose threat scores never become significant (because the events driving those cases turn out to be innocuous). However, in response to a threat occurring within the network being monitored, the threat score for at least one of the cases is expected to increase as the threat develops.

Another key feature of the system is the fact that cases are only rendered available via a case user interface (UI) when their threat scores reach a significance threshold, or meet some other significance condition. In other words, although a large number of cases may be created in the background, cases are only selectively escalated to an analyst, via the case UI, when they become significant according to defined significance criteria.

Case escalation is the primary driver for actions taken in response to threats or potential threats.

The cyber defence platform is implemented as a set of computer programs that perform the data processing stages disclosed herein. The computer programs are executed on one or more processors of a data processing system, such as CPUs, GPUs etc.

FIG.1shows a schematic block diagram of the cyber defence platform, which is a system that operates to monitor traffic flowing through a network as well as the activity at and the state of endpoints of that network in order to detect and report security threats. The system is shown to comprise a plurality of data collectors102which are also referred to herein as “coal-face producers”. The role of these components102is to collect network and endpoint data and, where necessary, process that data into a form suitable for cyber security, analysis. One aspect of this is the collection of raw network data from components of the network being monitored and convert that raw data into structured events (network events), as described above. The raw network data is collected based on network tapping, for example.

Event standardisation components104are also shown, each of which receives the events outputted from a respective one of the coal-face producers102. The standardisation components104standardise these structured events according to a predefined data model, to create standardized network and endpoint events.

The raw network data that is collected by the coal-face producers102is collected from a variety of different network components100. The raw network data can for example include captured data packets as transmitted and received between components of the network, as well as externally incoming and outgoing packets arriving at and leaving the network respectively.

Additionally, structured endpoint events are collected using endpoint agents316executed on endpoints throughout the network. The endpoint agents provide structured endpoint events to the coal-face producers102and those events are subject to standardization, enrichment and correlation as above.

This is described in further detail below, with reference toFIG.3.

Once standardised, the network events are stored in a message queue106(event queue), along with the endpoint events. For a large-scale system, the message queue can for example be a distributed message queue. That is, a message queue106embodied as a distributed data storage system comprising a cluster of data storage nodes (not shown inFIG.1).

An event optimisation system108is shown having an input for receiving events from the message queue106, which it processes in real-time or near real-time to provide enhanced events in the manner described below. InFIG.1, enhanced events are denoted w.esec.t, as distinct from the “raw” events (pre-enhancement) which are denoted w.raw.t. Raw events that are stored in the message queue106are shown down the left hand side of the message queue (these are the standardised, structured events provided by the standardisation components104) whereas enhanced events are shown on the right hand side. However, it will be appreciated that this is purely schematic and that the events can be stored and managed within the message queue106in any suitable manner.

The event enhancement system108is shown to comprise an enrichment component110and a joining component112. The enrichment component106operates to augment events from the message queue106with enrichment data, in a first stage enrichment. The enrichment data is data that is relevant to the event and has potential significance in a cybersecurity context. It could for example flag a file name or IP address contained in the event that is known to be malicious from a security dataset. The enrichment data can be obtained from a variety of enrichment data sources including earlier events and external information. The enrichment data used to enrich an event is stored within the event, which in turn is subsequently returned to the message queue106as described below. In this first stage enrichment, the enrichment data that is obtained is limited to data that it is practical to obtain in (near) real-time. Additional batch enrichment is performed later, without this limitation, as described below.

The joining component112operates to identify short-term, i.e. small time window, correlations between events. This makes use of the timestamps in the events and also other data such as information about entities (devices, processes, users etc.) to which the events relate. The joining component112joins together events that it identifies as correlated with each other (i.e. interrelated) on the timescale considered and the resulting joined user events are returned to the message queue106. This can include joining together one or more network events with one or more endpoint events where appropriate.

InFIG.1, the joining component112is shown having an output to receive enriched events from the enrichment component110such that it operates to join events, as appropriate, after enrichment. This means that the joining component112is able to use any relevant enrichment data in the enriched events for the purposes of identifying short-term correlations. However, it will be appreciated that in some contexts at least it may be possible to perform enrichment and correlation in any order or in parallel.

An observation database manager114(storage component) is shown having an input connected to receive events from the message queue106. The observation database manager114retrieves events, and in particular enhanced (i.e. enriched and, where appropriate, joined) events from the message queue106and stores them in an observation delay line116(observation database). The observation delay line116may be a distributed database. The observation delay line116stores events on a longer time scale than events are stored in the message queue106.

A batch enrichment engine132performs additional enrichment of the events in the observation delay line116over relatively long time windows and using large enrichment data sets. A batch enrichment framework134performs a batch enrichment process, in which events in the observation delay line116are further enriched. The timing of the batch enrichment process is driven by an enrichment scheduler136which determines a schedule for the batch enrichment process. Note that this batch enrichment is a second stage enrichment, separate from the first stage enrichment that is performed before events are stored in the observation delay line116.

Network and Endpoint Events:

FIG.3shows a schematic block diagram of an example network300which is subject to monitoring, and which is a private network. The private network300is shown to comprise network infrastructure, which can be formed of various network infrastructure components such as routers, switches, hubs etc. In this example, a router304is shown via which a connection to a public network306is provided such as the Internet, e.g. via a modem (not shown). This provides an entry and exit point into and out of the private network300, via which network traffic can flow into the private network300from the public network306and vice versa. Two additional network infrastructure component308,310are shown in this example, which are internal in that they only have connections to the public network306via the router304. However, as will be appreciated, this is purely an example, and, in general, network infrastructure can be formed of any number of components having any suitable topology.

In addition, a plurality of endpoint devices312a-312fare shown, which are endpoints of the private network300. Five of these endpoints312a-312eare local endpoints shown directly connected to the network infrastructure302, whereas endpoint312fis a remote endpoint that connects remotely to the network infrastructure302via the public network306, using a VPN (virtual private network) connection or the like. It is noted in this respect that the term endpoint in relation to a private network includes both local endpoints and remote endpoints that are permitted access to the private network substantially as if they were a local endpoint. The endpoints312a-312fare user devices operated by users (client endpoints), but in addition one or more server endpoints can also be provided. By way of example, a server312gis shown connected to the network infrastructure302, which can provide any desired service or services within private network300. Although only one server is shown, any number of server endpoints can be provided in any desired configuration.

For the purposes of collecting raw network data, a plurality of network data capture component314a-314care provided. These can for example be network taps. A tap is a component which provides access to traffic flowing through the network300transparently, i.e. without disrupting the flow of network traffic. Taps are non-obtrusive and generally non-detectable. A tap can be provided in the form of a dedicated hardware tap, for example, which is coupled to one or more network infrastructure components to provide access to the raw network data flowing through it. In this example, the taps314a,314band314care shown coupled to the network infrastructure component304,308and310respectively, such that they are able to provide, in combination, copies317of any of the raw network data flowing through the network infrastructure302for the purposes of monitoring. It is this raw network data that is processed into structured network events for the purpose of analysis.

FIG.2shows a schematic illustration of certain high level structure of a network event200.

The network event200is shown to comprise a timestamp204, an entity ID206and network event description data (network event details)208. The timestamp204and entity ID206constitute metadata207for the network event details208.

The network event description data208provides a network event description. That is, details of the activity recorded by the network event that has occurred within the network being monitored. This activity could for example be the movement of a network packet or sequence of network packets through infrastructure of the network, at a particular location or at multiple locations within the network.

The network event data208can for example comprise one or more network event type indicators identifying the type of activity that has occurred. The entity ID206is an identifier of an entity involved in the activity, such as a device, user, process etc. Where multiple entities are involved, the network event can comprise multiple network event IDs. Two important forms of entity ID are device ID (e.g. MAC address) and network address (e.g. IP address, transport address (IP address plus port) etc.), both of which may be included in a network event.

As well as being used as part of the analysis (in conjunction with the timestamps204), entity IDs206and network event description data208can be used as a basis for querying enrichment data sources for enrichment data.

The timestamp204denotes a timing of the activity by the network event200. Such timestamps are used as a basis for associating different but related network events, together with other information in the network event200such as the entity ID206or IDs it contains.

The network event200can have structured fields in which this information is contained, such as a timestamp field, one or more entity ID fields and one more network event description fields.

The network event200is shown to comprise a network event identifier (ID)202which uniquely identifies the network event200.

Returning toFIG.3, for the purpose of collecting endpoint data, endpoint monitoring software (code) is provided which is executed on the endpoints of the network300to monitor local activity at those endpoints. This is shown in the form of endpoint agents316a-316g(corresponding to endpoint agents316inFIG.1) that are executed on the endpoints312a-312grespectively. This is representative of the fact that endpoint monitoring software can be executed on any type of endpoint, including local, remote and/or server endpoints as appropriate. This monitoring by the endpoint agents is the underlying mechanism by which endpoint events are collected within the network300.

FIG.4shows a schematic illustration of a certain high level structure of an endpoint event400.

The endpoint event400is shown to comprise at least one endpoint identifier, such as a device identifier (e.g. MAC address)402and network (e.g. IP) address404of the endpoint to which it relates, and endpoint event description data406that provides details of the local activity at the endpoint in question that triggered the creation of the endpoint event400.

One example of endpoint activity that may be valuable from a cyber defence perspective is the opening of a connection at an endpoint. For example, a TCP/IP connection is uniquely defined by a five-tuple of parameters: source IP address (IP address of the endpoint being monitored), source port, destination IP address (IP address of an e.g. external endpoint to which the connection is being opened), destination port, and protocol. A useful endpoint event may be generated and provided to the platform for analysis when an endpoint opens a connection, in which the five-tuple defining the connection is recorded, and well as, for example, an indication of a process (application, task, etc.) executed on the endpoint that opened the connection.

As noted, one of the key features of the present cyber defence platform is its ability to link together interrelated network and endpoint events. Following the above example, by linking and endpoint event recording the opening of a connection and details of the process that opened it to network events recording the flow of traffic along that connection, it becomes possible to link specific flows of network traffic to that specific process on that endpoint.

Additional examples of endpoint information that can be captured in endpoint events include information about processes running on the endpoint (a process is, broadly, a running program), the content of files on the endpoint, user accounts on the endpoint and applications installed on the endpoint. Again, such information can be linked with any corresponding activity in the network itself, to provide a rich source of information for analysis.

Such linking can occur within the platform both as part of the real-time joining performed by the joining component112.

However, network and endpoint events can also be linked together as part of the analysis performed by the analysis engine that is inherently able to consider links between events over longer time-scales, as will now be described.

Event Driven, Case-Based Analysis:

Returning toFIG.1, the analysis engine, labelled118, is shown having inputs connected to the event queue106and the observation delay line116for receiving events for analysis. The events received at the analysis engine118from the event queue106directly are used, in conjunction with the events stored in the observation delay line116, as a basis for a sophisticated cyber security analysis that is applied by the analysis engine118. Queued events as received from the message queue106permit real-time analysis, whilst the observation database116provides a record of historical events to allow threats to be assessed over longer time scales as they develop.

The analysis applied by analysis engine118is an event-driven, case-based analysis as will now be described.

As indicated above, the analysis is structured around cases herein. Cases are embodied as case records that are created in an experience database124(which may also be a distributed database).

Case creation is driven by events that are received at the analysis engine from the message queue106, in real-time or near-real time.

Case creation can also be driven by events that are stored in the observation delay line116. For example, it may be that an event is only identified as potentially threat-related when that event has been enriched in the second stage enrichment.

Once created, cases are developed by matching subsequent events received from the message queue106to existing cases in the experience database124.

Events stored in the observation delay line116may also be matched to existing cases. For example, it may be that the relevance of a historic event only becomes apparent when a later event is received.

Thus, over time, a significant case will be populated with a time sequence of interrelated events, i.e. events that are potentially related to a common security threat, and as such exhibit a potential threat pattern.

Incoming events can be matched to existing cases using defined event association criteria, as applied to the content of the events—in particular the timestamps, but also other information such as entity identifiers (device identifier, IP address etc.). These can be events in the event queue106, the observation delay line116, or spread across both. Three key pieces of metadata that are used as a basis for linking events in this way are:1. timestamps,2. endpoint devices, and/or specific endpoint information such as:a. endpoint host nameb. endpoint open sockets3. IP address.

These can be multiple pieces of metadata of each type, for example source and destination IP addressed. Such metadata of cases is derived from the event or events on which the case is based. Note the above list is not exhaustive, and the types of data can be used as a basis for event linking.

For example, events may be associated with each other based on IP address where a source IP address in one event matches a destination IP address in another, and those events are within a given time window. IP addresses provide one mechanism by which endpoint events can be matched with related network events.

As another example, open sockets on an endpoint are a valuable piece of information in this context, as they are visible to the endpoint agent on the endpoint and associate specific processes running on that endpoint with specific network connections (“conversations”). That is, a socket associated with a process running on an endpoint (generally the process that opened the socket) can be associated with a specific five-tuple at a particular moment in time. This in turn can be matched to network activity within that conversation, for example by matching the five-tuple to the header data of packets tapped from the network. This in turn allows that network activity to be matched to a specific socket and the process associated with it. The endpoint itself can be identified by host name, and the combination of host name, five tuple and time is unique (and in many cases the five tuple and time will be unique depending on the network configuration and where the communication is going). This may also make use of the time-stamps in the network and endpoint events, as the association between sockets and network connections is time limited, and terminates when a socket is closed.

As noted already, in networking, a five-tuple is a tuple of (source IP, destination IP, source port, destination port, transport protocol). This uniquely identifies a network connection within relatively small time windows. In order to match events based on network connection, a hash of the five tuple can be computed from all network data and from endpoint process connection data (data relating to the network conversations individual processes on the endpoint are engaged in). By ensuring that all endpoint data also contains the host name (derived from the endpoint software), this allows any network event to be correlated with any endpoint event (network 5 tuple hash→endpoint 5 tuple hash→host name) and vice versa. This provides an efficient mechanism for linking specific network connections to specific programs (processes). Such techniques can also be used to link network activity to other event description data, e.g. a specific user account on an endpoint.

As noted, each case is assigned at least one threat score, which denotes the likelihood of the threat hypothesis (or threat hypotheses) to which the case relates. Significance in this context is assessed in terms of threat scores. When the threat score for a case reaches a significance threshold or meets some other significance condition, this causes the case to be rendered accessible via a case user interface (UI)126.

Access to the cases via the case UI126is controlled based on the threat scores in the case records in the experience database124. A user interface controller (not shown) has access to the cases in the experience database124and their threat scores, and is configured to render a case accessible via the case UI126in response to its threat score reaching an applicable significance threshold.

Such cases can be accessed via the case UI126by a human cyber defence analyst. In this example, cases are retrieved from the experience database124by submitting query requests via a case API (application programming interface)128. The case (UI)126can for example be a web interface that is accessed remotely via an analyst device130.

Thus within the analysis engine there are effectively two levels of escalation:1. Case creation, driven by individual events that are identified as potentially threat-related.2. Escalation of cases to the case UI126, for use by a human analyst, only when their threat scores become significant, which may only happen when a time sequence of interrelated events has been built up over time

As an additional safeguarding measure, the user interface controller may also escalate a series of low-scoring cases related to a particular entity to the case UI126. This is because a series of low-scoring cases may represent suspicious activity in themselves (e.g. a threat that is evading detection). Accordingly, the platform allows patterns of low-scoring cases that are related by some common entity (e.g. user) to be detected, and escalated to the case UI126. That is, information about a set of multiple cases is rendered available via the case US126, in response to those cases meeting a collective significance condition (indicating that set of cases as a whole is significant).

The event-driven nature of the analysis inherently accommodates different types of threats that develop on different time scales, which can be anything from seconds to months. The ability to handle threats developing on different timescales is further enhanced by the combination or real-time and non-real time processing within the system. The real-time enrichment, joining and providing of queued events from the message queue106allows fast-developing threats to be detected sufficiently quickly, whilst the long-term storage of events in the observation delay line116, together with batch enrichment, provide a basis for non-real time analysis to support this.

The above mechanisms can be used both to match incoming events from the message queue106and events stored in the observation delay line116(e.g. earlier events, whose relevance only becomes apparent after later event(s) have been received) to cases. Appropriate timers may be used to determine when to look for related observations in the observation delay line116based on the type of observation, after an observation is made. Depending on the attacker techniques to which a particular observation relates, there will be a limited set of possible related observations in the observation delay line116. These related observations may only occur within a particular time window after the original observation (threat time window). The platform can use timers based on the original observation type to determine when to look for related observations. The length of the timer can be determined based on the threat hypothesis associated with the case.

Analysis Framework:

The analysis engine is shown to comprise a machine reasoning framework120and a human reasoning framework122. The machine reasoning framework120applies computer-implemented data analysis algorithms to the events in the observation delay line116, such as ML techniques.

Individual observations may be related to other observations in various ways but only a subset of these relationships will be meaningful for the purpose of detecting threats. The analysis engine118uses structured knowledge about attacker techniques to infer the relationships it should attempt to find for particular observation types.

This can involve matching a received event or sets of events to known tactics that are associated with known types of attack (attack techniques). Within the analysis engine118, a plurality of analysis modules (“analytics”) are provided, each of which queries the events (and possibly other data) to detect suspicious activity. Each analytic is associated with a tactic and technique that describes respective activity it can find. A hypothesis defines a case creation condition as a “triggering event”, which in turn is defined as a specific analytic result or set of analytic results that triggers the creation of a case (the case being an instance of that hypothesis). A hypothesis also defines a set of possible subsequent or prior tactics or techniques that may occur proximate in time to the triggering events (and related to the same, or some of the same, infrastructure) and be relevant to proving the hypothesis. Because each hypothesis is expressed as tactics or techniques, there may be many different analytics that can contribute information to a case. Multiple hypotheses can be defined, and cases are created as instances of those hypotheses in dependence on the analysis of the events. Tactics are high level attacker objectives like “Credential Access”, whereas techniques are specific technical methods to achieve a tactic. In practice it is likely that many techniques will be associated with each tactic.

For example, it might be that after observing a browser crashing and identifying it as a possible symptom of a “Drive-by Compromise” technique (and creating a case in response), another observation proximate in time indicating the download of an executable file may be recognized as additional evidence symptomatic of “Drive-by Compromise” (and used to build up the case). Drive-by Compromise is one of a number of techniques associated with an initial access tactic.

As another example, an endpoint event may indicate that an external storage device (e.g. USB drive) has been connected to an endpoint and this may be matched to a potential a “Hardware Additions” technique associated with the initial access tactic. The analysis engine118then monitors for related activity such as network activity that might confirm whether or not this is actually an attack targeting the relevant infrastructure.

This is performed as part of the analysis of events that is performed to create new cases and match events to existing cases. As indicated, this can be formulated around the “MITRE ATT&CK framework”. The MITRE ATT&CK framework is a set of public documentation and models for cyber adversary behaviour. It is designed as a tool for cyber security experts. In the present context, the MITRE framework can be used as a basis for creating and managing cases. In the context of managing existing cases, the MITRE framework can be used to identify patterns of suspect (potentially threat-related behaviour), which in turn can be used as a basis for matching events received at the analysis engine118to existing cases. In the context of case creation, it can be used as a basis for identifying suspect events, which in turn drives case creation. This analysis is also used as a basis for assigning threat scores to cases and updating the assigned threat scores as the cases are populated with additional data. However it will be appreciated that these principles can be extended to the use of any structured source of knowledge about attacker techniques. The above examples are based on tactics and associated techniques defined by the Mitre framework.

Case Content:

Each case record is populated with data of the event or events which are identified as relevant to the case. Preferably, the events are captured within the case records such that a timeline of the relevant events can be rendered via the case UI126. A case provides a timeline of events that have occurred and a description of why it is meaningful, i.e. a description of a potential threat indicated by those events.

In addition to the event timeline, a case record contains attributes that are determined based on its constituent events. Four key attributes are:1. people (users)2. processes3. devices4. network connections

A case record covering a timeline of multiple events may relate to multiple people, multiple devices and multiple users. Attribute fields of the case record are populated with these attributed based on its constituent events.

A database case schema dictates how cases are created and updated, how they are related to each other, and how they are presented at the case UI126.

Case User Interface:

FIG.5shows an example of a page rendered by the case UI126at the analyst device130. A list of cases502is shown, each of which is selectable to view further details of the case in question. Cases are only displayed in the case list502if their respective threats scores have reached the required thresholds. The cases in the case list502are shown ordered according to threat score. By way of example, the first case504in the case list502has a threat score of 9.6 (labelled as element506). Further details of the currently selected case are shown in a region508adjacent to the case list502. In particular, a timeline510of the events on which the case is based is shown. That is, the events with which the case is populated in the experience database124. In addition, a graphical illustration512of network components to which those events relate is shown in association with the timeline510. This can, for example, include endpoints, infrastructure components, software components and also external components which components of the network are in communication with. Additional information that is relevant to the case is also shown, including a threat summary514that provides a natural language summary of the threat to which the case relates. This additional information is provided in the form of “widgets” (separable threat information elements), of which the threat summary514is one.

As shown inFIGS.5A through5E, the timeline510comprises selectable elements corresponding to the underlying events, which are labelled510ato510erespectively. This can be seen, selecting these timeline elements causes the accompanying graphical representation512to be updated to focus on the corresponding network components. The widgets below the timeline are also updated to show the information that is most relevant to the currently selected timeline element.

Enrichment Micro Services:

Returning toFIG.1, micro services138are provided, from which enrichment data can be obtained, both by the batch enrichment framework134(second stage enrichment) and the enrichment component110(first stage enrichment). These can for example be cloud services which can be queried based on the events to obtain relevant enrichment data. The enrichment data can be obtained by submitting queries to the micro services based on the content of the events. For example, enrichment data could be obtained by querying based on IP address (e.g. to obtain data about IP addresses known to be malicious), file name (e.g. to obtain data about malicious file names) etc.

Hunting Ground:

In addition to the case UI126, a “hunting” UI140is provided via which the analyst can access recent events from the message queue106. These can be events which have not yet made it to the observation delay line116, but which have been subject to first stage enrichment and correlation at the event enhancement system108. Copies of the events from the message queue106are stored in a hunting ground142, which may be a distributed database and which can be queried via the hunting UI140. This can for example be used by an analyst who has been alerted to a potential threat through the creation of a case that is made available via the case UI126, in order to look for additional events that might be relevant to the potential threat.

In addition, copies of the raw network data itself, as obtained through tapping etc., are also selectively stored in a packet store150. This is subject to filtering by a packet filter152, according to suitable packet filtering criteria, where it can be accessed via the analyst device130. An index150ais provided to allow a lookup of packet data150b, according to IP address and timestamps. This allows the analyst to trace back from events in the hunting ground to raw packets that relate to those events, for example.

It will be appreciated that, whilst the specific embodiments of the invention have been described, variants of the described embodiments will be apparent to the skilled person. The scope of the invention is not defined by the described embodiments but only by the appendant claims.