Skip to main content
Do you build apps on Splunk or are a Splunk admin? If so, we want to hear from you. Help shape the future of Splunk and win a $35 gift card!

Take the Survey
Lantern Home
 
 
Splunk Lantern

Monitoring for credit card fraud with the Splunk App for Fraud Analytics

  1. Last updated
  2. Save as PDF

 

If you have not already installed the Splunk App for Fraud Analytics, complete the steps in the deployment guide and then come back to this article. If you are not a Splunk Enterprise Security customer or are unable to install the Splunk App for Fraud Analytics, we recommend using the Splunk platform version of this article instead.

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.

Credit card providers typically have millions of customers that perform even more millions of credit card transactions on a daily basis. These providers need the ability to monitor these consumer transactions as they occur, for the various indicators of credit card fraud. The Splunk App for Fraud Analytics ships with out-of-the-box use cases that address various use cases within the Financial Services sector.

While the credit card fraud use case is not included out-of-the-box, the application does provide the necessary frameworks to implement and enable this use case. This process will address how to detect credit card fraud using the frameworks provided within Splunk Enterprise Security and the Splunk App for Fraud Analytics.

Review and prepare data for use within the credit card fraud use case

The Splunk App for Fraud Analytics includes five data models that support numerous use cases. However, it does not include a data model for credit card fraud activity. For scaling and code reuse purposes, we recommend leveraging data models, report acceleration, or summary indexing when searching across hundreds of GBs of events in a single search. Take this into consideration when deciding how to support this data source.

The required data sources for this use case include application data of credit card activity (for example web data or database), and a custom lookup (csv or kvstore) of categorized spending by customer. The following procedure walks you through creating a data model (recommended) and preparing your data for use in the credit card fraud activity use case.

Create a data model

If you opt to use raw data (and not a data model) or summary indexing, skip this step.

  1. Navigate to Settings > Data models.
  2. Click New data model.
  3. Create a data model following the instructions in the Splunk platform documentation.

Design your data model

If you opt to use raw data (and not a data model) or summary indexing, skip this step.

To meet the requirements of the recommended detections to support the credit card fraud use case, you should include the following fields within your data model:

  • _time
  • action
  • amount
  • categories
  • category
  • customer
  • previous_tx_date

In most cases, you should be able to build this data model with a single root object based on a single data source.

Categorize spending by customer

  1. Define a kvstore collection in Splunk Web to store a list of categorized spending by customer. This will be large, which is why you should use the kvstore and not a csv lookup. For more information, see Define a KV Store lookup in Splunk Web on Splunk Docs.
  2. Output the results of the following search to your newly defined kvstore collection. 
    sourcetype=<customer information data>
| stats sum(amount) AS amount BY customer category

Prepare and configure risk rules and risk notables applicable to credit card fraud

The following content is recommended for detecting credit card fraud activity. Implement the following detections, and modify the search language to leverage your custom data model or summary index, if you are not searching directly against the raw data.

Search Name Rule Type Description Search
RR-Fraud-CC-Large and rapid credit card spending Risk Rule Notable A common sign of fraud is when a card is used to make a lot of purchases in a short time span, especially with large dollar amounts. sourcetype=<customer information data>
| eval _time=strptime('_time',"%Y/%m/%d %H:%M:%S")
| sort - _time
| streamstats earliest(_time) AS _time latest(_time) AS latest_time time_window=1m count(action) AS num_transactions sum(amount) AS total_spent by customer
| where ((total_spent > 5000) AND (num_transactions >=5))
| eval latest_time=strftime(latest_time,"%Y/%m/%d %H:%M:%S"), total_spent=tostring(round(total_spent,2),"commas")
| table customer, _time, latest_time, num_transactions, total_spent, category
RR-Fraud-CC-Outlier credit card spending by category Risk Rule Notable A common sign of fraud is when a customer starts spending large amounts of money in categories they don't usually shop in. sourcetype=<customer information data>
| eval _time=strptime('_time',"%Y/%m/%d %H:%M:%S")
| sort - _time
| lookup <name of lookup file of categorized spending>
| streamstats window=1 list(category) AS category BY customer
| where (amount > 1000)
| makemv delim="|" categories
| eval match=if(match(categories,category),1,0)
| where (match == 0)
| eval amount=tostring(round(amount,2),"commas")
| table customer, _time, amount, categories, category, action
RR-Fraud-CC-Outlier credit card spending by value Risk Rule Notable A common sign of fraud with a stolen card is rarely using a card and suddenly spending a large amount. sourcetype=<customer information data>
| eval _time=strptime('_time',"%Y/%m/%d %H:%M:%S")
| sort - _time
| stats sum(amount) as total_spent first(_time) AS _time first(previous_tx_date) AS previous_date BY customer
| where (('_time' > relative_time(strptime(previous_date,"%m/%d/%Y %H:%M:%S"),"+6mon")) AND (total_spent > 3000))
| eval total_spent=tostring(round(total_spent,2),"commas")
RR-Fraud-CC-Excessive number of credit card transactions in a short period Risk Rule Notable A common sign of fraud with a stolen card is a large number of transactions in a short time period. sourcetype=<customer information data>
| eval _time=strptime('_time',"%Y/%m/%d %H:%M:%S")
| sort - _time
| streamstats earliest(_time) AS _time latest(_time) AS latest_time time_window=1m count(action) AS num_transactions by customer
| where (num_transactions >= 10)
| eval latest_time=strftime(latest_time,"%Y-%m-%d %H:%M:%S")
| dedup customer
| table customer, _time, latest_time, num_transactions, category
RR-Fraud-CC-Credit card test purchases Risk Rule Notable A common sign of fraud is when a credit card is used to make a small purchase, immediately followed by a large purchase. sourcetype=<customer information data>
| eval _time=strptime('_time',"%Y/%m/%d %H:%M:%S")
| sort - _time
| streamstats earliest(amount) AS first_amount latest(amount) AS last_amount earliest(_time) AS _time latest(_time) AS latest_time time_window=1m count(action) AS num_transactions BY customer
| where (((first_amount < 20) AND (last_amount > 3000)) AND (num_transactions >= 2))
| eval first_amount=tostring(round(first_amount,2),"commas"), last_amount=tostring(round(last_amount,2),"commas"), latest_time=strftime(latest_time,"%Y/%m/%d %H:%M:%S")
| table customer, _time, latest_time, num_transactions, first_amount, last_amount
Notable-Fraud -- Possible Credit Card Fraud Notable This is a custom risk notable focused on detecting multiple anomalies across the credit card fraud use case. It is modeled on the Account Takeover and New Account fraud notables.

| from datamodel:"Risk.All_Risk"
| search source="*RR-Fraud-CC*"
| dedup risk_object risk_object_type source
| eval source_short=replace(source, "(?i).*? -- (.*?)( - Rule)", "\1")
| eventstats sum(calculated_risk_score) AS risk_score_total, dc(source) AS source_count, values(sourc*) AS sourc* BY risk_object risk_object_type
| where risk_score_total >= 10
| eval severity=case(risk_score_total<20,"low",
risk_score_total<30,"medium",
risk_score_total<40,"high",
risk_score_total>=40,"critical")

| fillnull AF__app AF__dash
| stats values(DM) AS DMs, first(severity) AS severity, first(urgency) AS urgency, values(threat*) AS threat*, first(risk_score_total) AS risk_score_total, values(sourc*) AS sourc*, values(AF__qs) AS AF__qs BY risk_object risk_object_type AF__app AF__dash
| sort 0 - source_count risk_object risk_object_type
| streamstats c(eval(if(len(AF__app)>1,1,null()))) as c by risk_object risk_object_type
| where c<10
| eval AF__DD0{c}_app=if(AF__app=0, null(), AF__app)
| eval AF__DD0{c}_app=`AF__app`
| eval AF__DD0{c}_app="SplunkEnterpriseSecuritySuite"
| eval AF__DD0{c}_dash=if(AF__dash=0, null(), AF__dash)
| eval AF__DD0{c}_qs="( " . mvjoin(AF__qs, " OR ") . " )"
| eval AF__DD0{c}=if(AF__dash=0, null(), "Investigate Notable: Possible ATO (" . risk_object_type . "=" . risk_object . ") via [" . AF__dash . "] dashboard")
| stats values(DMs) AS DMs, first(severity) AS severity, first(urgency) AS urgency, values(threat*) AS threat*, first(risk_score_total) AS risk_score_total, values(sourc*) AS sourc*, values(AF__DD*) AS AF__DD* by risk_object risk_object_type
| sort 0 - source_count risk_score_total risk_object risk_object_type
| dedup source
| table sev* urg* risk* thr* calc* tot* sou* DM* AF__D*


Fraud dashboard content customization

There are various dashboards included with the Splunk App for Fraud Analytics that pertain to financial services fraud. As this data is identified and normalized, it is important to incorporate this data into the applicable dashboards, including the following:

  • Fraud Risk Exposure Analysis (Recommended). Only looks at the fraud_web data model. If needed, modify the searches to also leverage your non-conforming data sources. If your data source for credit card or wire transfer activity is already in web format, there is nothing additional to do other than ensure it is normalized to the fraud_web data model.
  • Customer Accounts Analysis (Recommended). Looks at the fraud_account data model, which is a repository of customer information (name, address, email, ip, etc). Any customer information data source you have should be incorporated into this data model, or you can modify the searches as mentioned above, to incorporate into this dashboard.
  • Web Traffic Analysis (Optional). This only applies if your data source is truly in web format. If so, ensure it is normalized to the fraud_web data model, and this dashboard will populate as expected.

Click here to the see the data model definitions.

Verify

The following steps ensure that you have performed initial configuration correctly and you can monitor for and detect both new account and account takeover fraud activity, using the Splunk App for Fraud Analytics.

  1. Validate the data sources are populated in the expected fraud_account and fraud_web data models, respectively, and you are able to search across each data model for the applicable datasets. These data sources should also have the required fields normalized to each of the data models, as described above.
  2. Ensure all applicable correlation searches are enabled within Splunk Enterprise Security and scheduled appropriately.
  3. Review scheduled search activity to ensure searches are running and not being skipped excessively. Adjust search windows, and perform additional troubleshooting as necessary.
  4. Ensure the following dashboards are populating by navigating to Enterprise Security > Fraud Analytics:
    • Fraud Incident Review
    • Financial Fraud > Web Traffic Analysis
    • Financial Fraud > Fraud Risk Exposure Analysis
    • Financial Fraud > Customer Accounts Analysis
  5. Test each enabled correlation search for functionality:
    • Does the search work or does it return any fatal errors?
    • If the search returns data, is it the expected data, and in the expected format?
    • If the search does not return data, is it because the data does not exist, or the data does exist, and there are simply no results?
  6. Troubleshoot correlation searches, as necessary.

Troubleshooting

Review Splunk Documentation on the Splunk App for Fraud Analytics for additional information and application troubleshooting.

Next steps

After you have implemented this credit card fraud use case, you might be interested in other ways to protect your financial services organization and its customers. Return to the fraud detection and prevention deployment guide for instructions on implementing additional use cases.

If you would like more hands-on assistance with this or any other fraud detection and protection use case, Splunk Professional Services can help. Find more information here or reach out directly to sales.