New Tables Queried by Salesforce.com Peer Group

Description

Salesforce.com supports a simplified query language called SOQL. This search detects users who begin querying sensitive tables that have never been contacted by peer group.


Use Case

Compliance, Insider Threat

Category

Data Exfiltration, GDPR, SaaS

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 3

MITRE ATT&CK Tactics

Discovery
Collection

MITRE ATT&CK Techniques

Data from Information Repositories
Remote System Discovery

MITRE Threat Groups

APT28
APT3
APT32
BRONZE BUTLER
Deep Panda
Dragonfly 2.0
FIN5
FIN6
FIN8
Ke3chang
Leafminer
Soft Cell
Threat Group-3390
Turla
menuPass

Kill Chain Phases

Actions on Objectives

Data Sources

Audit Trail

   GDPR Relevance

Impact:

Detecting first-time query attempts to sensitive tables by a peer group that has previously not accessed the tables in question, can help prove that individuals within the organization are not abusing or misusing legitimate access to assets that store and process personal data. This method is an industry best practice.

Specific to GDPR, this 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, though the peer group makes things slightly more complicated.

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

To configure the Peer Group:

  1. Start with a data source that gives you visibility into the peer group -- easiest is usually querying Active Directory via the SA-ldapsearch add-on, but you could get lists of users and their teams / departments / etc from any source you have.
  2. Next you will need to convert that log source into a format that this lookup is expecting, which is as follows:
    userpeergroup (order not important)
    johnjohn|sarah
    sarahjohn|sarah
    markmark
    The easiest way to do this is with a search like | inputlookup LDAPSearch.csv | stats values(user) as user by department | eval peergroup=mvjoin(user, "|") | mvexpand user

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, and tables queried. 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 Tables Queried by Salesforce.com Peer Group 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 Tables Queried by Salesforce.com Peer Group

Demo Data

First we pull in our demo SFDC dataset.
Then we filter for what we're looking for in this use case, specifically queries of sensitive tables (Account, Contact, or Opportunity), or their derivatives.
Then we enrich to convert the SFDC USER_ID into a friendly username via a lookup.
Find where the most recent value is less than -1d@d from either now() or the value showing your most recent data point (depending on your particular search desires)
Enrich primary with peer group
Here we are comparing the # of 'Secondary Field's viewed today and historically by the 'Primary Field'. multireport is a search operator that allows you to leverage the power of stats, but multiple times.
Now we join the two | stats output together into one, so that we can analyze them together
Filtering out null earliest will handle corner cases to make a clean report.

Live Data

First we pull in our SFDC dataset and filter for EVENT_TYPEs that can have SOQL queries attached.
Then we extract out the table name from the query.
Finally we filter for queries of sensitive tables (Account, Contact, or Opportunity), or their derivatives.
Then we enrich to convert the SFDC USER_ID into a friendly username via a lookup.
Find where the most recent value is less than -1d@d from either now() or the value showing your most recent data point (depending on your particular search desires)
Enrich primary with peer group
Here we are comparing the # of 'Secondary Field's viewed today and historically by the 'Primary Field'. multireport is a search operator that allows you to leverage the power of stats, but multiple times.
Now we join the two | stats output together into one, so that we can analyze them together

Screenshot of Demo Data