Monitoring for account takeover with the Splunk App for Fraud Analytics

Data required

• Financial data

Identify the risk rules applicable to account takeover fraud

1. After performing the initial configuration of the Splunk App for Fraud Analytics, as described in the deployment guide, navigate to Enterprise Security > Configure > Content Management.
2. Filter on the following:
   • Type: Correlation Search
   • App: Fraud Analytics for Splunk
   • Filter: 'RR-Fraud --'
3. The following results should appear:
   
4. Examine the SPL for each of the applicable searches to determine data source requirements. Currently, all detections applicable to account takeover fraud require data from the fraud_web data model. If you add new detections that require another data type, this should be noted for future steps.

Review and prepare data for compliance with the fraud_web data model

The fraud_web data model focuses on account activity such as login/logout, payment and trading activity, or profile changes, and allows analysts to search for and detect potentially fraudulent account behavior. The data could be in the form of web or other application-like data, but focuses on data fields rather than specific data types. So, theoretically, both the fraud_account and fraud_web data models could leverage the same source type. The difference is how they focus different lenses on this data through specific fields within the data models.

1. Review the applicable data fields for the fraud_web data model by navigating to Settings > Data Models > fraud_account. The fraud_account data model applicable fields can be seen in the table in Splunk Docs.
2. While the above fields are all of the fields available to you through the fraud_web data model, similar to how most Splunk Enterprise Security detections work, you won't need to normalize to every single field. You only need to normalize to the fields applicable to the account takeover risk rules described in the previous step. Following are the fields required for successful implementation of the account takeover risk rules described in the previous step.

   Fields required for risk rule implementation

   Risk Rule	Required Fields	Combined Required Fields
   RR-Fraud -- Brute force attack on user	logged_in username_tried src_ip	action Country ip_subnet_16s languages logged_in Region session_id src_ip username usernames username_tried
   RR-Fraud -- Country of login doesn't match browser language	Country languages usernames session_id
   RR-Fraud -- Excessive Logins - group behavior	username usernames
   RR-Fraud -- IP hitting multiple user accounts	username_tried src_ip
   RR-Fraud -- Significant edit user profile followed by quick money movement	action session_id usernames
   RR-Fraud -- Successful logins from different regions	Country Region ip_subnet_16s username
   RR-Fraud -- Successful logins from multiple ip addresses	logged_in ip_subnet_16 src_ip username username_tried
   RR-Fraud -- Suspicious attempts to login to high value accounts	username_tried username src_ip

   Fields required for dashboard implementation

   Dashboard	Panel	Required Fields	Combined Required Fields
   Financial Fraud > Web Traffic Analysis
   	Combined timechart of all events	_time	_time action src_ip Country Region City username_ex username_tried logged_in accept_language http_user_agent http_method risk_exposure risk_exposure_r screen screens session_id status uri uri_path
   	Selected events	_time
   	Multi-field investigative panel (all views)	bytes_in Country Region src_ip username_tried logged_in accept_language http_method status http_user_agent uri_path
   	Detailed web traffic activity	_time src_ip Country Region City username_tried logged_in accept_language http_user_agent http_method status uri_path
   Financial Fraud > Fraud Risk Exposure Analysis
   	Money Movement Events	action
   	Interactive investigation: User accounts and risk analysis (Countries)	src_ip username_ex Country
   	Interactive investigation: User accounts and risk analysis (Usernames)	risk_exposure src_ip username_ex
   	Interactive investigation: User accounts and risk analysis (IP Addresses)	username_ex http_user_agent risk_exposure Country
   	Interactive investigation: User accounts and risk analysis (Screen Info)	username_ex risk_exposure screens
   	Interactive investigation: User accounts and risk analysis (Session ID)	risk_exposure session_id
   	Interactive investigation: User accounts and risk analysis (User Agent)	risk_exposure http_user_agent
   	Interactive investigation: User accounts and risk analysis (Risk Level)	username_ex risk_exposure_r
   	Interactive investigation: User accounts and risk analysis (Actions)	action
   	Detailed portal activity	_time src_ip Country Region City session_id username_ex screen http_method status action uri risk_exposure http_user_agent

3. Identify the fields within the applicable dataset, and normalize those to the fraud_web data model.
4. If you need to adjust out-of-the-box risk rules based on your unique requirements, keep note of any additional fields that need to be normalized to the fraud_web data model and incorporated into the detection.

Enable the risk rules and risk notable applicable to account takeover fraud

1. Enable the Risk Rules identified in the first step in this process by navigating to Enterprise Security > Configure > Content Management, and first filtering for the new account fraud risk rules.
   • Type: Correlation Search
   • App: Fraud Analytics for Splunk
   • Filter: 'RR-Fraud --'
2. Enable all of these rules through the Content Management user interface.
3. Enable the following Risk Notables:
   • Notable-Fraud -- Possible Account Takeover Attack
   • Risk Threshold Exceeded for User - all channels

Next steps

If you want more step-by-step guidance about how to implement this use case by walking through a sample scenario, see the Multichannel fraud detection article.

After you have implemented this account takeover 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.

Finally, 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.