Salesforce is one of the core platforms at Delivery Hero, dedicated to structuring and organizing the data related to all interactions with our partners restaurants and customers worldwide.

These interactions often contain information that might be sensitive. This article will explore the use of Transaction Security Policies in Salesforce to set up rules and alerts to prevent data leaks in real-time by protecting this sensitive information. 

A little background

Salesforce holds the master data of our partner vendors, which is essential for all sales related daily activities. This information includes, for example, accounts with vendor-specific information, leads for information about prospects, opportunities and commissions for negotiation related data, bank details, addresses and other sensitive data that requires protection. 

As a part of their daily activities, our Salesforce end users often require processing data from various Salesforce objects. Some users can export this data to fulfil their tasks, partly because the Report module lacks user friendliness, especially when processing large data volumes. To overcome these situations, users with the right access choose to export the data they need separately for further manipulation in external tools such as Excel or Tableau. 

Currently, users can only export data from objects they are authorised to access according to their Salesforce user setup and security profiles. Previously, there were no checks on exporting sensitive information. 

How it used to be (and still is)

Before implementing, Transaction Security Policies (TSP) in the Salesforce team, we had a more reactive approach to data related alerts. Although we had various monitoring tools in place, our response was limited to reacting after an event had already occurred.

We monitor the salesforce platform using two main methods:

• Event Monitoring, a proprietary Salesforce tool, exposes information about events occurring in a transaction from various system perspectives, such as ApexExecution, RestApi, Bulk, Queued, and Report). Our monitoring solution utilises two families of events: Hourly and near real time.
• Custom Logs, an in-house developed logging solution, allows us to capture events beyond those provided by Event Monitoring such as capturing functional and technical metrics within a transaction.

Regardless of the method of log collection, the data from both solutions is aggregated and processed in Datadog, Delivery Hero’s current monitoring solution. The following diagram illustrates the log capture process.

The challenges of relying solely on a reactive approach

The main issues with only keeping the monitoring solution were: 

• The monitoring-only approach is reactive rather than proactive, making it difficult to protect data already exposed in the event of a data leak. This solution didn’t cover proactive measures to prevent data leaks.  
• Limited retention times in Datadog could hinder the investigation of past data breaches.
• Slack alerts from Datadog have been due to an overwhelming number of daily alerts and insufficient resources for investigation
• Users could bypass the standard Export Report feature by using third-party tools to query and export information 
• While some users need to export reports for tasks like raising mass update tickets, they could export sensitive data (such as personal information, phone numbers, emails, and bank details) not required for these tasks, without any restrictions. This posed a potential security risk if sensitive data was exported without proper authorization.

Covering the gap with Transaction Security Policies

What is it

The Transaction Security Policy (TSP) is a feature provided by the Salesforce Shield add-on designed to monitor Salesforce events in real time and identify potential issues based on user created (policies). 

Transaction Security allows users to create policies comprising events, notifications, and actions. An event encompasses any activity within Salesforce, including user clicks, changes in record state, and value measurements. Events are immutable and come with timestamps.

A transaction security policy consists of: 

• A transaction or event to be monitored (e.g Report event type)
• Actions that are triggered when the event takes place (Blocking, Email Notification, In-App notification, M2F)

How it works

When an event occurs that is supported by Transaction Security, the system checks for any existing policies related to that event. If a matching policy is found, it executes either its Apex code or the Condition Builder logic to see if the event meets the criteria to trigger the policy. If the criteria are met, Transaction Security takes the specified action and issues any relevant notifications for that policy.

In our scenario, the overall idea was to use the TSPs module to create policies to track two specific event types: Report Event Type to evaluate and monitor the export report process and the List View Event Type to evaluate and monitor what users could extract from the list views they have access to. For both event types, the main interest is to check whether the request includes sensitive fields or not. 

Benefits

The main benefit of this solution is that we are able to proactively track events in real time, covering the gap left by the monitoring solution which only tracks what happens after the event takes place. Other benefits include:

• TSPs can be easily created, modified and managed by the Salesforce admin and developers depending on the complexity of the conditions that need to be evaluated.
• TSPs can be created to cover multiple Salesforce objects.
• With this solution, Salesforce triggers immediate enforcement of actions to block the requested operation, informs the end users why they are being blocked, and sends notifications to specific stakeholders within our Central Team.
• The solution allows us to accommodate exemptions for specific scenarios and users without compromising overall security measures.
• Once TSPs are triggered, logs are generated and gathered by our Monitoring solution in place, sending them to Datadog for further processing and analysis.

Our use case and implementation

As mentioned in a previous paragraph, the central idea is to evaluate if the reports being exported by our end users contain fields that have been marked as sensitive. If the report contains at least one sensitive field, and the user lacks access to bypass the security policy, the user will be blocked and the report won’t be exported until all sensitive fields are removed. If the user has access to bypass the security policy assigned, the report will be exported as expected. The following diagram illustrates this flow. 

As part of our implementation, we adopted the following approach for the Account object: 

• A new custom permission is assigned to users upon approval. This custom permission is object-based (i.e. Account custom permission) and is used as a flag to control whether TSPs should be enforced or not. For users with this custom permission assigned, TSPs tracking the specific object won’t be triggered. The users without the custom permission will be triggering the TSPs in case sensitive data from that object is included. 
• A new Apex class contains the specific event types  and the conditions to be evaluated, including:
  • The feature is enabled in the user’s entity.
  • The user has the custom permission assigned.
  • The report contains sensitive fields. 

This class looks similar to this extract of code:

• TSPs track event types and execute the logic included in the Apex class.
• A dedicated Salesforce user handles the email notifications sent when TSPs are triggered.

A new approval process was also established in our Salesforce Jira portal, allowing our users to request access to bypass the TSPs. Upon approval from the designated approver in the entity, the custom permission will be assigned.

What does it look like? 

When a user attempts to export information, either through the “Printable View button” available in some list views or by using the export report button, the TSPs conditions are evaluated. If conditions are met, the operation will be blocked as shown in the example below:

1. The user opens a report and click on the “Export report” option or the “Printable View” button in a list view

2. The TSP will be triggered if the user lacks the necessary access, blocking the export process and showing a blocking message

3. An email and notifications will be sent to the SF Central Team to notify them about the triggered TSP

Future roadmap

Currently, the TSPs are enabled globally for all our regions (APAC, LATAM, EU & MENA) for the data stored in the Account object, which is the object where the vendor specific information is stored. 

In the upcoming weeks, TSPs for more objects such as Contacts, Bank Details, Case and Address details will be enabled.