The modernisation of data platforms and the ever-growing availability of data mean that analysts need tools that highlight the information they need to know and when they need to know it. Alerting has become a core feature in many case management and intelligence applications, helping intelligence analysts and investigators keep on top of the changing information landscape for their entities of interest.
The traditional alerting systems allow for entities to be tagged, and for alerts to be generated when the attributes or the immediate information surrounding an entity are updated or changed. For example, if an entity’s phone number or address changes, or if they call a person of interest then an alert can be generated. Graph-based alerting takes this functionality and extends it with the capabilities of a graph database. Rather than being limited to single entity attribute and 1-hop changes, graph-based alerts can be generated on complex, deep graph patterns that occur in the graph. This capability allows for complex and flexible alert logic to be created, such as “alert me these two organisations indirectly communicate”, or “alert me to any indirect links between these two persons”. In this blog post, we walk through three examples of graph-based alerts and how GraphAware’s Hume provides a framework for building and managing these alerts.
Single Entity Alerting
Let’s imagine that we are intelligence analysts that have been tasked with monitoring the activity of an organised crime leader Jessica Kelly. We want to be alerted to any communication that occurs between Jessica Kelly and Ann Fox or Louis Hughes. Traditional alerting systems that are based on relational databases would require us here to manually add in each of the mobile phones that are used by Jessica Kelly and would be inflexible to new phones that are registered and used to make a connecting call. However, with graph-based alerts, we can define logic where any current or future phone that is linked to Ms Kelly that makes a call to a phone registered to either of our persons of interest will trigger an alert. This gives us the flexibility in our alerting logic to react to any new phones that are used by any of the persons of interest.
The figure below shows how this alerting logic can be defined in Hume, as well as the change detection types and the frequency of alert checks. For this example, we will define our graph pattern in the cypher window, select new and updated records and have the system check for alerts every hour.
In our pre-alert dataset, we can see that both Jessica Kelly and Ann Fox are known to possess a single phone number each, with no phone number known for Louis. There are currently no calls between any of the parties.
In the second figure below, we can see an example of the changes within the data that trigger this alert. Jessica Kelly has been linked to a new phone number, which has then made two calls to a newly identified phone number owned by Louis Hughes. Existing phone numbers for Ann Fox and Jessica Kelly have also been used to make a call to one another. By using a graph pattern, rather than a hard-coded pattern, this alert was still able to be triggered, even with new numbers being registered and used. The directionality of the graph pattern has also not been defined, and is therefore flexible, meaning we are able to identify calls between these persons of interest regardless of who initiated the call.
The alert event window in Hume allows each of these alert events to be seen, categorised and triaged, allowing analysts to effectively manage their alert workflow. Alerts can also be configured to send notifications to email servers and other external alerting systems if and when required.
Multi-Entity Pathfinding Alerts
Let’s look at another alerting example using the Ms Kelly organised crime use case. Let’s imagine that we are interested in Ms Kelly’s activity with Kelly Peterson. Ms Peterson is the leader of a rival gang, and we are interested in any possible way these two individuals may be communicating, meeting, or transacting with one another. Pathfinding examples such as this one are where graph-based alerts shine. Graph data stores allow for easy and efficient implementation of pathfinding algorithms that would otherwise be resource intensive if not impossible with traditional relational databases.
In the figure below, we simply define a graph pattern that is flexible enough to identify paths of interest that include locations, phone calls, associations and family relations. Any new path between Ms Kelly and Ms Peterson that is found using this logic will trigger an alert.
In our example, we see that two alerts are triggered for indirect interactions between Ms Kelly and Ms Peterson. In the first new path, we see that Ms Kelly lives with Mr Morales, who made a phone call to Ms Peterson. This implies an indirect, but significant interaction between these rival organisations. Our alerting logic was flexible enough to identify and alert on this interaction, even when the connection was indirect. Similarly in the second alert example, we see that Ms Kelly has a family relationship with Ms Murrary, who then made a call to Ms Warren, who lives with Ms Peterson. Again, our graph alerting logic is flexible and capable enough to identify this indirect relationship of interest.
Finding direct and indirect links
Let’s look at one final alerting example where we examine the indirect links and activities between two outlaw motorcycle gangs. Here we are interested in any direct or indirect associations between the two clubs, and any crimes that they may have both been involved in. This would be a difficult alert to generate in a traditional alerting system, as we would be required to strictly define the links that we want to alert on. Using graph-based alerts, we are able to define a flexible graph pattern with a couple of lines of cypher code. This alert will trigger if there are any new direct or indirect relationships between the two clubs.
In our results we see there are two new indirect links between the clubs. In the first alert, we see that gang members Billy Moore and Bennie Boar are both party to a crime, showing perhaps that the two gangs are cooperating in some way. In the second path, we see a phone call between Ernest Thompson and Ruby Reynolds, suggesting that these individuals may be involved in some inter-gang communications.
Alert set-up in Hume
This video shows an alert that specifies the monitoring of a certain data set and how it detects an event that is displayed in Hume.
Conclusion
Traditional alerting systems that rely on ‘1-hop’ relational database queries fail to provide analysts and investigators with complex and flexible alerting logic capabilities. Graph-based alerting allows for complex graph patterns to be defined for alerting purposes. With graph alerting, analysts can define a graph pattern and be notified when that pattern is created, updated, or deleted. GraphAware’s Hume provides a framework for defining and managing graph-based alerts. These graph patterns benefit from the flexibility and traversal capabilities that are available in a graph database.
