Salesforce Shield is for organizations that need to meet extra security and compliance requirements. Four components make up Salesforce Shield (encryption, enhanced field audit trail, event monitoring, and Einstein Data Detect) with encryption being the main one.
Salesforce Shield brings the Compliance & Security Team (CISO) and Salesforce Admins together, helping everyone stay on the same page when it comes to critical compliance measures. Turning on Salesforce Shield doesn’t guarantee success – sure, it’s a security control, but it’s not the sole security control you need to consider.
This guide will cover the components that make up Salesforce Shield, as well as tips for getting more out of your Salesforce Shield investment – “the Shield path to value” as coined by our partners, OwnBackup.
As a “Salesforce Platform” product, Shield’s capabilities can span across all of the Salesforce “cloud” products your organization uses, to support the reduction of data risks in all areas of the business.
Salesforce Shield is an add-on product, meaning it comes at an additional cost to the typical Salesforce CRM license types. It’s worth noting that you can purchase the “full umbrella” (all four components), or each component can be purchased separately based on what suits your regulatory and business requirements.
Salesforce offers a first-rate service in providing infrastructure – hardware, network services, and the underlying infrastructure – however, there is a shared security responsibility model in operation. This means that responsibility is shared between Salesforce (the vendor) and your organization (the customer). The result is that any configuration/customization to Salesforce needs to be managed by the customer, and the customer is ultimately responsible for the risk that comes with that.
That’s where Salesforce Shield comes in, providing another layer of protection to help customers manage the shared responsibility model security controls.
Salesforce Shield also delivers capabilities that are not provided with Salesforce out of the box (we’ll cover these later). These are especially key for customers who have sensitive data in Salesforce and/or operate in regulated industries.
Let’s take a look at each of the components that make up Salesforce Shield.
The Static Initialization Vector means that some filtering capabilities can be maintained with Deterministic encryption. In the table above, you can see that the value “San Diego” is populated in the Account city field on two separate records. Regardless of these being two separate records, the cipher text for “San Diego” will be the same. This allows any records containing “San Diego” to be matched when using filtering capabilities.
So, yes, while Probabilistic encryption is more secure, Deterministic encryption is still secure, and a great option for its functionality benefits.
Platform encryption, Einstein Data Detect, and data classification all go hand-in-hand. We’ll show you why when we explore the “Salesforce Shield path to value” later.
Salesforce Shield field audit trail extends field history tracking for up to ten years, versus 18-24 months with Salesforce standard Field Change Tracking. Field history tracking includes what data changes, in which fields, when, and by which user.
Retaining field history for longer can allow you to adhere to business requirements (i.e. to refer back to historic data), or legal compliance requirements.
What’s the difference between the standard field audit trail and Salesforce Shield’s audit trail? Here’s an overview:
| Standard Field Audit Trail | Shield Field Audit Trail | |
|---|---|---|
| Number of fields supported: | 20 fields per object | 60 fields per object |
| History retention periods: | 18 months within your Salesforce org, 24 months via API* | 1 month to 10 years |
| Can retention policies vary by object? | No | Yes |
| Where is the trail accessible? | [Object] History related list | [Object] History related list. After X number of months, data is sent to the field history archive. This can then be permanently deleted after a period of time. These time periods are defined by your organization |
*Customers can use Data Loader or the queryAll() API to retrieve field history that‘s 18–24 months old.
Field tracking policies (i.e. what, stored for how long, deleted after how long) are set up using the metadata API which Salesforce provides out of the box.
User activity monitoring allows you to set transaction security policies to track user “events” i.e. what they are doing in the system, through browsers, the Salesforce mobile app, and the Salesforce APIs. The objective is to spot and block rogue behavior in-real time, thereby preventing and mitigating threats.
We have a report where we know sensitive information is stored. We want to identify a user’s attempt to export 5,000+ rows of data from Salesforce and prevent them from succeeding – perhaps it’s the “high net worth contacts” report and a disgruntled salesperson is leaving the organization soon.
When there’s an attempt to export the report, it will show the user a message that they don’t have permission, therefore blocking the export. This is recorded as an “event”, which can be monitored with analytics tools.
For reporting on Event Monitoring, Salesforce provides a CRM analytics app (pre-built dashboard), which comes with event monitoring (two licenses).
Events, such as our example with the disgruntled salesperson, are logged and shown in a variety of components. You can monitor trends by user, which reports are being downloaded, or how users are accessing certain reports.
Many customers will choose to bring that into Splunk or Qradar to align Salesforce event monitoring with other event monitoring from across their tech stack.
All events are stored in the Event Log File standard object, meaning you can run queries to do the analysis and forensics in the face of threats.
The chart below shows how Event Monitoring in Salesforce Shield works overall.
That’s why Einstein Data Detect works hand-in-hand with platform encryption, informing what needs to be encrypted “at rest”.
A common example is when support agents have added information unintentionally in the case description or comments field. How are you able to identify that?
The scan results will show you where you have sensitive data within your org that needs reviewing to ensure you’re protecting it. Below, you can see that there are different objects/fields, with 65k records that potentially have sensitive patterns in fields.
Take a look by object to see, for example, these specific fields on the account need to be reviewed and classified appropriately:
Back to the Case example – we do have credit card information stored, and we can see in specific fields which patterns have been detected. Einstein Data Detect is showing me that there are credit card numbers stored in the description field. We really don’t want this, so we need to ensure that those values are being stored in the appropriate places.
Einstein data detect is great to identify where you might have sensitive data stored in those unknown places.
Note: Einstein data detect is a managed package. Unlike some Einstein products, you don’t need a certain amount of record data for Einstein Data Detect to work accurately. Instead, it will scan based on whatever data is in your org, no matter the size of your org.
How you implement Shield is unique to your business, and there’s no shying away from the fact that it’s a significant investment, so you need to ensure that you’re getting full value from it.
There’s a 96-page Salesforce Shield Implementation guide (yes, it really is 96 pages!) containing the many considerations you need to take into account before encrypting a field. It’s a lot of work and is challenging to maintain.
The steps we outline below will help with the implementation, and more importantly, the maintenance over time.
Start with data detection and data classification to inform platform encryption, ultimately, to define the extent to which you should protect data.
Start by running Einstein Data Detect. You can refer back to the “Einstein Data Detect” section to see this in action.
While Einstein Data Detect will give you the baseline of where you may have sensitive field data, it doesn’t enable you to classify your data. You can use a third-party tool to support this exercise.
OwnBackup Secure is one example, which offers a Data Classification tool so you can generate your “wish list” of fields to encrypt. From there, you can assign values to the data points (e.g. “confidential”) all from one view, then use this as the input when encrypting with Shield.
The warning: “Potential high risk fields detected” appears based on keywords – for example, “SSN”, “Credit Card Number”. You can get more granular by using the filters to identify other PII data points. Then you can use the bulk classification feature to get the job done faster.
OwnBackup Secure’s “Platform Encryption Analyzer” will give you insight into where fields are being used before you encrypt data.
This paves the way to successfully encrypt your sensitive information avoiding any downstream impacts/unintended consequences on your org’s configuration, e.g. failed Apex classes, should you return encrypted data to your Salesforce org.
The results are returned, indicating the severity. For example, a “low impact” result could mean that a couple of list views might be disrupted if the analyzed field is encrypted. In this case, you can have a conversation with the business as to the true necessity of those list views.
This is covered in a demo here. It’s best to use the demo to follow along with the instructions outlined in the Salesforce Shield implementation guide.
Configuring policies for Field audit trail has to be done with the metadata API which Salesforce does provide.
However, to avoid working with the metadata API and speed up the setup (therefore, the time to value), we can see how OwnBackup Secure supports the process with its purpose-built interface which sits directly on top of the field audit trail. See all of your objects, fields, and classification in a single view. Logically, we’ll set tracking up for our sensitive fields.
Icons, like the brown face, call out that you have high-risk fields that are not being tracked. So, set the tracking on fields, then configure policies for when you’d like to remove that from the related list, and then when it should be permanently deleted.
It’s worth reiterating that this method avoids having to work with the metadata API to set up your policies – it’s all point-and-click.
Navigate to “Salesforce Setup” and search for “transaction security policies” in the quick find box. Transaction Security Policies can be configured on “Queried Entities”, which is just another term for objects.
An example Transaction Security Policy is if a user attempts to export a report on [object] with over X number of high risk fields, then the export will be blocked, and/or a notification sent to the admin or Information Security personnel.
With help from OwnBackup Secure’s Data Classification, you will be informed where there are objects (Queried Entities) with a high concentration of high risk fields, and therefore, pinpoint where to configure Transaction Security Policies.
For reporting on Event Monitoring, Salesforce provides a CRM analytics app (pre-built dashboard), which comes with event monitoring (two licenses).
Setup is minimal – assign the relevant user permissions and run the analytics app.
Salesforce Shield is an add-on product, meaning it comes at an additional cost to the typical Salesforce CRM license types. As opposed to the typical per user, per month pricing, Shield pricing is calculated as a % of your total Salesforce spend, making it a fairer pricing model for small-medium organizations.
Up to date Salesforce Shield pricing can be found on Salesforce’s official pricing page.
Again, note that you can purchase the “full umbrella” (all four components), or each component can be purchased separately based on what suits your regulatory and business requirements.
As we’ve said, Salesforce Shield platform encryption encrypts data “at rest” i.e. when it’s stored in the data center.
Going forward, the best practice to hide sensitive data from users, is field-level security, i.e. defining which fields are readable/editable for which users.
Most third-party Salesforce backup providers have “sandbox seeding” capabilities, which will mask or randomize data when it’s transferred from the production org to sandboxes.
If you want to mask (obfuscate) data from Salesforce users viewing data within the Salesforce interface, you will need to look for another option.
How much of a learning curve is there for a Salesforce Admin getting started with Shield?
Security is a separate domain, so there can be a significant learning curve. That’s why we’ve explored additional tools to guide you as you get started. It’s important to identify partners with plenty of domain expertise.
Having said that, Salesforce Shield is a fantastic opportunity to bring the Compliance & Security Team (CISO) and Salesforce Admins together, helping everyone to get themselves on the same page when it comes to critical compliance measures.
As well as this guide, there are great resources provided by OwnBackup, as well as Trailhead. Employees of Salesforce partners can achieve the Security & Privacy professional accreditation that covers Salesforce Shield alongside the Salesforce Privacy Center.
To continue the conversation, check out OwnBackup’s Salesforce Shield Platform Encryption Checklist.
