New High Risk Event Types for Salesforce.com User

Description

Salesforce.com supports a variety of different event types in their event logs. This search detects users who suddenly query event types associated with data exfiltration


Use Case

Compliance, Insider Threat

Category

Data Exfiltration, GDPR, SaaS

Alert Volume

Medium (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Exfiltration
Command and Control

MITRE ATT&CK Techniques

Exfiltration
Web Service

MITRE Threat Groups

APT12
APT37
APT41
BRONZE BUTLER
Carbanak
FIN6
FIN7
Leviathan
Magic Hound
Patchwork
RTM
Turla

Kill Chain Phases

Actions on Objectives

Data Sources

Audit Trail

   GDPR Relevance

Impact:

First-time seen events, specifically high-risk types, can indicate unauthorized, non-compliant, and potentially malicious behavior.

Specific to GDPR, detecting first-time occurrences of high-risk behavior and proving that individuals within the organization are not abusing or misusing legitimate access to assets that store and process personal data is an industry best practice and can be considered an effective security control, as required by Article 32. This is applicable to processing personal data from the controller, and needs to also be addressed if contractors or sub-processors from third countries or international organizations access and transfer personal data (Article 15).

   How to Implement

Implementation of this example (or any of the First Time Seen examples) is generally very simple.

  • Validate that you have the right data onboarded, and that the fields you want to monitor are properly extracted.
  • Save the search.

For most environments, these searches can be run once a day, often overnight, without worrying too much about a slow search. If you wish to run this search more frequently, or if this search is too slow for your environment, we recommend leveraging a lookup cache. For more on this, see the lookup cache dropdown below and select the sample item. A window will pop up telling you more about this feature.

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over (or for the lookup cache feature, the first occurrence over whatever time period you built the lookup). But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.

You should not review these alerts directly (except for high sensitivity accounts), but instead use them for context, or to aggregate risk (as mentioned under How To Respond).

   How To Respond

When this search returns values, initiate your incident response process and identify the user demonstrating this behavior. Capture the time of the event, the user's role, application and number of rows exported or viewed. If possible, determine the system the user is using and its location. Contact the user and their manager to determine if it is authorized, and document that this is authorized and by whom. If not, the user credentials may have been used by another party and additional investigation is warranted.

   Help

New High Risk Event Types for Salesforce.com User Help

This is the generic search builder for First Seen Detection. Our dataset is an anonymized data collection from an actual customer environment.

SPL for New High Risk Event Types for Salesforce.com User

Demo Data

First we pull in our demo SFDC dataset.
Then we filter for what we're looking for in this use case, specifically high risk EVENT_TYPEs
Then we enrich to convert the SFDC USER_ID into a friendly username via a lookup.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
Next we calculate the most recent value in our demo dataset
We end by seeing if the earliest time we've seen this value is within the last day of the end of our demo dataset.

Live Data

First we pull in our SFDC dataset and filter for what we're looking for in this use case, specifically high risk EVENT_TYPEs
Then we enrich to convert the SFDC USER_ID into a friendly username via a lookup.
Here we use the stats command to calculate what the earliest and the latest time is that we have seen this combination of fields.
We end by seeing if the earliest time we've seen this value is within the last day.

Screenshot of Demo Data