Using modern methods of detecting financial crime

SPL Rule —> alert

Combine your rules with AND (which is the implied Boolean operator) and use WHERE clauses to filter out exceptions and thresholds. More complex searches can help differentiate rules and reduce alerts that fire on unimportant issues. With fewer alerts, you can triage and respond faster.

Risk scores

Any one notable event rule might not be nefarious, but the sum of the scores for all rules leads to a total score that gives confidence that the user, customer, account ID, institution, or entity has been compromised. This accumulated value of all the risk scores can enhance an analyst's ability to triage events so that a single issue does not create a bunch of false positives to investigate. It also allows the analysts to work on the highest scoring indicators first for a use case. 

To implement this approach, add a weighted risk score to each rule. Then, turn each rule into a saved search in the Splunk platform that can be executed all at once in order to return a single, user-defined risk score per search that can be multiplied by a weight for importance. The grouping of all rules can be done by username, customer, account ID, institution, or whatever entity is a common way to identify the account.

In SPL, this could look like the following:

index=transactions 
|fields username 
| dedup username
| join type=left username
 [savedsearch RiskScore_ConnectionFromRiskyCountry]
| join type=left username
 [savedsearch RiskScore_ExcessiveLogins]
| join type=left username
 [savedsearch RiskScore_AccountPasswordChange]
| eval RiskScore_ConnectionFromRiskyCountry=RiskScore_ConnectionFromRiskyCountry*0.75
| eval RiskScore_ExcessiveLogins=RiskScore_ExcessiveLogins*1.5
| eval RiskScore_AccuntPasswordChange=RiskScore_AccountPasswordChange*.90
| eval Total_Risk=RiskScore_ConnectionFromRiskyCountry+RiskScore_AccuntPasswordChange+RiskScore_AccountPasswordChange 
 | table Username, Total_Risk

Tweak this approach as needed and architect it properly for your use case domain. For example, notice that the search above uses a left outer join to do the grouping. Rather than a join, you can use a series of appends to concatenate the results of the saved searches, and then use the Splunk stats command to group by username. This can lead to performance improvement.

Another performance improvement is to use summary indexes for a summary that is going to be looked back in time (i.e., money laundering use cases) or to use Splunk data models and data model acceleration for faster retrieval of data.

One final way to improve this search is to have each saved search run on a scattered schedule (not all at once, but with a few minute gaps) because account takeover is not a near real-time event until it happens. You can store the risk score for each username in a new summary risk index using the collect command. The Splunk platform can then run another scheduled search that uses an N-minute window with the streamstats command to group all risk scores by username from the risk index and fire an alert if the score is above a threshold.

Risk-based alerting

Although the ideas above are better than using singular rules, you can improve your process even further. What if there was a framework that does what was described above, but also handles:

• case management
• sequencing of events
• management of alerts
• context of what the user did (not just the Risk Score, but other important information such what country was used in the wire transfer and the amount)
• mapping of rules to security frameworks such as MITRE ATT&CK and Cyber Kill Chain
• serving as a platform for collecting notable events

This is called Risk Based Alerting (RBA) in Splunk Enterprise Security, which is the next level of sophistication in detecting financial crime. RBA ships out of the box with Splunk Enterprise Security and all these features come with it. What this does is collect notable events within a risk index, apply some meta-data context, and allow for alerts when alert thresholds are met. The alerts themselves can be sent to a SOAR product such as Splunk SOAR to create automated playbooks to respond to the situation. A response could be to block the inbound IP, lock out the account, notify the account holder, and notify all involved company parties to analyze the case.

To understand RBA, refer to these articles:

• Implementing risk-based alerting
• Investigating interesting behavior patterns with risk-based alerting

Advanced techniques

Since account takeover and money laundering have been mentioned a few times now, the question of how one knows who is the leader of a fraud ring comes to mind. The stats command in the Splunk platform can help you find out who conducts the most transactions to the most number of accounts in a time period.

|stats sum(amount) AS amount count BY From_Account, To_Account
|sort - count

This looks easy, but it does not give us a graph where A connects to B and B connects to C and so forth. Also, a number for connections may miss many edge cases when there are a million accounts and a few million transactions involved.

You can use directed graphs to find possible connections between accounts or users using a technique called eigenvector centrality to find the most connected nodes that may lead to fraud ring leaders. This is highlighted in this picture below with the large dot in the bottom center of the picture.

The search can still be used to find from and to accounts grouped by sender and receiver, but the graph is what does the work. It uses an app called 3D Network Topology Visualization that can be freely downloaded from Splunkbase to implement the use case. For details on how this is done for fraud ring detection, please download the free e-book, Bringing the Future Forward, and read the chapter on detecting financial crime using network topology graphs (written by Splunk Principal Architect Philipp Drieger).