Deployment Guide: Prerequisites for detecting and preventing fraud
Required software
- Splunk Enterprise (or Cloud) version 8.1.2+
- Splunk Enterprise Security version 6.5.2+
- Splunk App for Lookup File Editing
- Splunk_Fraud_Analytics.tar.gz file
Applicable data sources onboarded in the Splunk platform
The Splunk App for Fraud Analytics includes all required data models and use cases for implementation of the prescribed use cases.
- New Account Fraud / Account Takeover
- Application data for banking transactions
- To enable the account takeover and new account fraud use cases, the following specific data types are required:
- Access logs (web server) pertaining to user account activity. Typical activities include login/logout, money movement, payment activity, profile changes, etc.
- Account data (could be a variety of sources including web, dbx, etc). Expected data points are customer name, ssn, email, address, and other metadata.
- To enable the account takeover and new account fraud use cases, the following specific data types are required:
- Application data for banking transactions
- Wire Fraud
- Application data for wire transfer activity
- CSV or KV Lookup of suspicious countries
- Credit Card Fraud
- Application data for customer information
- CSV or KV Lookup of categorized spending by customer
A note on fraud data sources
The approach to fraud data sources is different from that of typical security data sources. Security data typically involves traditional data categories like authentication, web, IDS/IPS, firewall, and netflow, as these data sources align to the various data models included with Splunk Enterprise Security. These data models typically have a one-to-many correlation to the use cases they support.
In contrast, the data models included with the Splunk App for Fraud Analytics typically have a one-to-one correlation to the use cases they support. That is, the fraud_account data model maps to New Account Fraud, the fraud_web data model maps to Account Takeover Fraud, etc. As a result of this model, this means that a single fraud data model could support various types of data (for example database, syslog, csv, or web), as long as these data sources align to the required fields within those models. This means that when you think of a fraud data model, think of the fields you need to enable the use cases, and find the data source that has that information, whether it is a web log, database table, or another application log.