Alerts

The Alerts feature is a rule-based detection approach that identifies specific patterns in the graph database.

For each alert, Linkurious Enterprise will analyze the patterns resulting from the detection rule (the query) to combine them in cases allowing the analysts to perform investigations more efficiently.

Alerts are currently only supported via Neo4j. If you are using a different graph vendor, please get in touch.

How to create an alert

On the Alert page, either click the "New alert" card or the "Create New Alert" button on the upper-right area of the screen to create a new alert.

There are two main sections on the Alert Creation modal: first, the general settings where you can setup the name, frequency and the sharing options of the alert. Then you can configure the query and the target of the alert.

General settings

On the first section of the "Alert Creation" modal, we can name the alert and set the frequency at which the query will be run by Linkurious Enterprise. You can also in this section configure the sharing settings of the alert:

• Set the alert as private (only visible by the owner)
• Set the alert as public (visible by all users who can access to the current source and who has rights to process cases)
• Set the alert visible only for specific groups

Alert Query

The query is a description of the graph pattern used for detection. Linkurious Enterprise will periodically execute this query (see Alert Settings) and assign each detection result to a case.

The user experience will vary depending on the way results are returned by the query (see more details in the following example section).

To learn how to write Cypher queries, check out the Cypher documentation.

The "Preview" button verifies that the query is correct and shows a preview of the first few detection results.

The preview feature is only used to validate the query, the results shown are raw detection results returned by the Cypher query.

The real list of cases may be different from the preview as multiple raw results may be grouped in the same case based on the target (see below).

Alert Target

The target must be a term returned by the RETURN statement in the Cypher query. This term should contain graph elements such as a node, an edge or a collection of the two (other items are not valid and will be ignored). The target helps assign the detection results from the alert query to the right case. That means that for any given alert, all new detection results with the same target will be assigned to the same open case.

A typical scenario may be when your query returns several paths but you would like to analyze all paths related to the same entity (target) in the same graph in Linkurious Enterprise. If for example, as a bank, you are monitoring the transactions of all the clients with a query similar to the following:

MATCH p = (c:Client)-[:HAS_BANK_ACCOUNT]->(a:BankAccount)-[t:HAS_TRANSFERED]-(other:BankAccount)
WHERE t.amount > 1000
RETURN p

You would be interested in having all the relevant transactions for a client (c) in the same investigation case. To achieve this, you would change the return statement to RETURN c, p and set c as the target of your alert.

Another typical scenario may be when your query already aggregates the data. Continuing with the previous example, you may be interested in analyzing cases where the total amount among all the transactions is over a predefined threshold. In this case, you can have a query similar to the following:

MATCH p = (c:Client)-[:HAS_BANK_ACCOUNT]->(a:BankAccount)-[t:HAS_TRANSFERED]-(other:BankAccount)
WITH c, collect(p) as paths, sum(t.amount) as total_amount
WHERE total_amount > 1000000
RETURN c, paths

When defining a grouping rule in your query you are most likely already implicitly defining where you want to focus the investigation. In this case, a good choice for the target would be the same set of variables used to define the grouping rule in the query (in this example, it would again be the client c).

Alert composite target

When there is the need to define multiple variables as a target, they need to be collected together in another variable.

For example, to use n1 and n2 as a composite target, use the following return statement to create a new variable t to be used as the target:

RETURN [n1, n2] as t

Alert columns

The resulting cases are shown in the case list page as a table which can be sorted by custom columns defined during the alert setup.

The order defined in your Cypher query through the ORDER BY statement doesn’t impact the whole order of the case list.

Custom columns provide additional information that can be selected from the returned values of the query. A new custom column consists of:

• The term: one of the values returned by the query. It can either be a property of a node, a property of an edge, or a computed value;
• The title: the label used as the column header in the case list;
• The type: the data type returned by the query.

Consider this cypher query snippet WITH c, sum(t.amount) as total_amount RETURN c, total_amount where c is a variable representing a node, we can use both the property of a graph element (c.name) and the variable name associated to a computed value (total_amount) as a term.

When several results are combined into a single case, the value shown in the column of the case list will be the last one returned by your cypher query.

A good practice is to choose terms associated to the target (e.g. a target’s property). If you have different needs, please get in touch.

The saved alert can be accessed in the "Alerts" page, as seen in the image below.

How to edit an alert

On the Alert page, use the edit button on the alert to change it by either using the context menu from when you right-click or from the action bar on the top-right of the screen after selecting the alert.

The next steps are the same as the alert creation.

Editing the query, the target or the columns of an existing alert will cause the deletion of all the open and in progress cases (i.e. the ongoing saved investigations and comment history will be deleted).

Closed cases are not deleted, however any new custom columns added after the closure of the case will be filled with an N/A value.

Example

Imagine a scenario where a Financial Institution is using Linkurious Enterprise and needs to perform a particular investigation described by the following:

• the system stores data about the clients and the phone numbers used to open a Bank Account
• the above information is modeled through a node of type Client connected through a direct relationship to a node of type Phone
• when different clients have used the same phone number to open a bank account, a dedicated team needs to investigate whether there were fraudulent activities behind those accounts
• the investigation team needs a tool that will facilitate the investigation of those shared phone numbers

You could use the following graph query for this alert:

MATCH (c:Client)-[e]->(p:Phone)<-[e2]-(c2:Client)
WHERE c <> c2
RETURN DISTINCT c, e, p

Such a query would return one detection result for each distinct Client connected to a Phone where there is at least another Client connected.

The image below shows all three detection results returned by the query when a Phone with number 123456789 was used by three different Clients with their respective client_id equal to 1, 2 and 3.

Since the investigator needs to focus on the Clients using the Phone, then it will be easier to have all detection results that contain the same Phone merged into the same case. To achieve this, simply declare that p is the target of this alert to generate a single case for investigation that contains all the relevant information in one place.

The case list can be enhanced by adding custom headers containing information about the target. In this example, the Phone Number will help the investigator distinguish the different cases.

The above scenario can be achieved by creating the alert as follows:

Notice how after a case is investigated and closed, a new alert execution identifying a new Client (e.g. with client_id equal to 4) connected to the previous Phone will generate a new investigation case. The new case will contain only the new Client to investigate, but the investigator has the possibility to see that there are three additional nodes connected to the phone (indicated by the small numbered badge on the node).