New Application Accessing Salesforce.com API
New Application Accessing Salesforce.com API
Salesforce.com contains the most critical information for many companies. This search looks for users who connect to SFDC's reporting API with new clients.
This content is not mapped to any local saved search. Add mapping
Many organizations maintain business-critical information within SaaS applications such as Salesforce.com. Salesforce is an example of a CRM business application which is used to store and process personal data relating to customers, partners, prospects and often employees. As part of a Salesforce.com deployment, other applications interact with this sensitive data, via push or pull APIs that automate data exchange - for example integrations into finance and human resources applications such as Workday, or marketing automation tools such as Eloqua and Marketo. Attackers can attempt to use the Salesforce.com API as a vector to gain access to sensitive data. Because Salesforce.com is a cloud application with a publicly accessible domain, this vector only requires valid credentials, and can be exploited for access to sensitive data by adversaries, even if they lack access to internal resources.
Under the GDPR Article 30, organizations are required to maintain a record of processing activities including contact details of the controller, the purposes of processing, description of the categories of data subjects and personal data processed -- as well as the categories of recipients to whom the personal data has been or will be disclosed including recipients in any other countries. Interactions from new applications -- whether for legitimate purposes or as a result of malicious activity -- can create a non-compliance condition if they are not documented properly. This situation may not impact organizations who employ fewer than 250 persons and therefore may not have critical categories of personal data for processing.
Monitoring Salesforce.com API activity can help identify connections from new applications or clients that might not be whitelisted or documented. The timely and accurate reporting of a non-compliance state can prompt the Data Privacy Officer to proactively follow up and update documentation, and report to the authorities in a timely manner if appropriate.
How to Implement
Implementation of this example (or any of the First Time Seen examples) is generally very simple.
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 application. 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.
New Application Accessing Salesforce.com API Help
This is the generic search builder for First Seen Detection. Our dataset is an anonymized data collection from an actual customer environment.
|First we pull in our SFDC dataset and filter for what we're looking for in this use case, specifically export EVENT_TYPEs where the CLIENT_NAME is defined.|
|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.|