Multichannel fraud detection
Working as part of a fraud detection team, you need to be able to quickly identify when a customer’s account is taken over by a fraudster.
Some combinations of user behaviour may indicate that fraud is occurring, for example, successful logins from different regions combined with shared passwords used over multiple accounts together with excessive amounts of logins. This process walks you through how to find incidents like this.
Required data
Application data for banking transactions
Procedure
The information in this article applies to Splunk Enterprise Security (ES) versions 7.x. If you have upgraded to Splunk Enterprise Security version 8.x, some terminology and steps might not apply. For additional assistance on this use case with ES 8.x, Splunk Professional Services can help.
- Install and configure the Splunk App for Fraud Analytics, following the installation instructions.
- From the Incident Review tab in the top toolbar of Splunk Enterprise Security, sort by Risk Score Total and find an event to investigate. Click on the caret to the left of the Incident Title to view the risk rules associated with the incident. In the example below, user morga8924 has a total score of 149. You can see that the user has triggered fraud risk rules in both new account data and web traffic data, indicated by the information in the red box. Just below this are the Risk Incident Rules that have been triggered (Threat-RR-Fraud). Below that, in the blue box, are some threat objects - think of these as attack vectors or fraud connections.
- Under Contributing Events, click View the Individual Risk Attributes (indicated by the blue arrow) to see what fraud rules have triggered and how they contribute to this high score.
4. You can see the different risk rules that contributed to this notable event. In the example below, there are five rules triggered. Some of these are triggered on the account opening data (NewAcct), while others are related to login or web behavior.
5. Use this information to decide how to investigate next. Based on the number and combination of rules that were triggered, you might conclude this is clearly fraud and no further investigation is required. The shared password rule especially is a very suspicious indicator, especially where your website uses complex passwords, it is unlikely that multiple users in a short period of time would generate the same password during account sign up.
The Excessive Logins - group behavior” rule scores differently than the others. Other rules may have a single static score or may score for a few different values based on a particular metric (for example, more than 3 usernames per IP address is score 20, more than 4 is score 30), but this group behavior rule creates a risk curve by determining some maximum value in a group, with anything above that always scoring 100, and anything below that is scaled (in this case, exponentially). In this example, user morga8924 logged in more times than many others in the group, and has a higher score of 64 for this event. In this example, more than 40 logins in a time period gets a score of 100.
If you do wish to investigate further, you can navigate back to the Incident Review Events and access the Customer Accounts Analysis dashboard or Web Traffic dashboard.
Next steps
Now that you've completed this one, have a look at the other tutorials in the Detecting consumer bank account takeovers use case. In addition, this resource might help you understand and implement this guidance: