Complete Guide to Salesforce Shield

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.

What Is Salesforce Shield?

Salesforce Shield is for organizations that need extra security and compliance requirements. It comprises the following four components:

• Platform encryption: Natively encrypt data “at rest” i.e. when it’s stored in Salesforce data centers.
• Field audit trail: Tracking field changes. Retain archived field history data for up to ten years.
• Event monitoring: User activity monitoring to prevent and mitigate threats.
• Einstein Data Detect: Scan for sensitive data and deeper insights.

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.

Why You Need Salesforce Shield

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.

1. Salesforce Shield Encryption

Salesforce Shield allows you to encrypt your Salesforce data with AES 256-bit encryption at the field-level, as well as manage your own encryption keys. Key takeaways of platform encryption include:

• AES 256-bit: The highest level of encryption available within Salesforce.
• Encrypt data at field-level: Field-level encryption is something that Salesforce does not provide out of the box.
• At-rest encryption: Encrypts your data “at rest”, i.e. when it’s stored in the data center. Data is stored as Cipher text (it switches plain text into Cipher text). This means that database agents working at the Salesforce database centers won’t be able to read your real data.
• Encryption policy: For files and attachments, this policy encrypts these in an “all or nothing” manner (i.e. not selectively according to certain files).
• Manage your own encryption keys: There are three options for managing encryption keys with Salesforce. While you can use Salesforce-generated encryption keys, customers who have a key management infrastructure in place will benefit from “bring your own key” (BYOK).

To clarify, access to records and field level security is still controlled by the native field-level security you have determined within your Salesforce org. Therefore, platform encryption is mostly invisible to your Salesforce users – in other words, it doesn’t mask data in Salesforce (also known as obfuscating). Again, it’s just encrypted – “at rest” within the data center.

We said mostly invisible to your Salesforce users because there are nuances. For example, if you encrypt a field that is used in a report filter or list view, that can have an impact on the visibility within that specific report or list view (more on this later in the guide!).

Salesforce Key Options (+ BYOK)

As we mentioned in the encryption key takeaways, there are three options for how you can manage encryption keys with Salesforce:

1. Use Salesforce-generated encryption keys.
2. “Bring your own key”: Customers with a key management infrastructure in place can “bring your own key” (BYOK). This is common among enterprise customers, who require full control over the rotation of the keys. Establishing the infrastructure to BYOK can take some time, so customers may initially use the Salesforce-generated key to get platform encryption up and running, and then migrate to BYOK.
3. Cache-only: This provides a “tunnel” over the key itself, so there’s no way that Salesforce will really be able to access it. This option is for the most security-conscious organizations. Note that there are implementation considerations that you should get clued-up on.

Probabilistic vs. Deterministic Encryption Schemes

Encryption schemes apply to field-level encryption. Probabilistic encryption was the original Shield encryption scheme, with 256-bit AES encryption. Deterministic encryption (also known as Filter-Preserving) is also 256-bit AES encryption. The main difference between Probabilistic versus Deterministic Encryption is in the initialization vectors (i.e. starting variable for the encryption scheme):

A fully randomized starting variable makes Probabilistic encryption more secure. Below is a comparison table with example encryption schemes. These are two separate records in Salesforce – two different “Bobs” or “San Diegos”. You can see that the cipher text is fully randomized, even with the same input text:

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.

What Shield Encryption is Not

We’ve already touched on these, but it’s worth reiterating:

• It’s not whole disk encryption. Instead, Shield encryption is at the field-level, and for files and attachments.
• While data can be selectively encrypted (i.e. field by field), Shield cannot selectively encrypt files and attachments. In other words, encryption for files and attachments is binary – meaning that there’s a setting (an encryption policy) that’s either on or off, and applied to all files and attachments.

• When the encryption policy for files and attachments is enabled, all new files and attachments that are uploaded will be encrypted “at rest”. You will need to contact Salesforce support to have existing files and attachments encrypted.
• It does not obfuscate the data; data is still mostly transparent to your end users from the Salesforce UI.

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.

2. Field Audit Trail

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:

*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.

3. Salesforce Shield Event Monitoring

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.

There are core and real-time event monitoring:

• Core event monitoring: View event streams containing different events, updated over the course of a few hours.
• Real-time event monitoring: View events happening in real-time. As an admin, when these defined activities occur, you can choose to block the user from continuing and be notified. These are defined by your transaction security policies.

Event monitoring is beneficial from both a security and a performance standpoint:

• Examples of monitoring from a security standpoint – whether they’re viewing a certain page, downloading a report, running a report with sensitive data in it, etc.
• There’s a robust set of events that Salesforce provides to monitor from a performance standpoint, for example, if certain reports are taking longer to load.

Event Monitoring Example

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.

Event Monitoring Analytics

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.

4. Einstein Data Detect

Einstein Data Detect automatically scans your Salesforce database, and identifies sensitive data based on five data patterns:

1. Credit card numbers
2. Emails
3. Social security numbers
4. URLs
5. IP addresses

That’s why Einstein Data Detect works hand-in-hand with platform encryption, informing what needs to be encrypted “at rest”.

Einstein Data Detect has an incredibly intuitive interface. In the example below, we’re going to:

• Define the objects we want to scan across, e.g. account, cases, and contacts.
• Set data policies which determine the data patterns we would like to scan for, e.g. a sensitive data scan policy (Salesforce has predefined logic that will allow you to do this).
• Set which fields we would like to scan.

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 to Implement Salesforce Shield

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.

Step 1: Run Einstein Data Detect

Start by running Einstein Data Detect. You can refer back to the “Einstein Data Detect” section to see this in action.

Step 2: Data Classification

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.

Step 3: Perform Impact Analysis

OwnBackup Secure’s “Platform Encryption Analyzer” will give you insight into where fields are being used before you encrypt data.

At this stage, the inputs for the analysis are:

• Sensitive fields that we identified with Einstein Data Detect (and OwnBackup Secure).
• Classified data (OwnBackup Secure).

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.

Step 4: Platform Encryption

Following our flow, you can kick-off encryption directly from the OwnBackup “Platform Encryption Analyzer” results table. Here are the high-level steps to encrypting a field with Salesforce Shield:

• Set up a Salesforce tenant secret, i.e. encryption key (the user needs permission set assigned “Manage Encryption Keys”).
• Decide whether you would like to use Deterministic encryption or Probabilistic encryption. Flick a switch in the Advanced Settings to enable Deterministic Encryption.
• Salesforce Shield can encrypt files and attachments (in an all-or-nothing manner). Enable file encryption by navigating to:
  • Salesforce Setup
  • Security
  • Platform Encryption
  • Encryption Policy
  • You can also choose to encrypt search indexes (how Salesforce catalogs your database for effective search), and change data encryption to capture events and platform events.

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.

Step 5: Setup Field Audit Trail (Avoiding the Metadata API!)

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.

Step 6: Set Up Event Monitoring (Transaction Security Policies)

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.

There are two options to set up transaction security policies:

1. Admin interface: Set the “if-then conditions” to block, notify you, or force MFA based on when the rogue activity occurs.
2. With custom code.

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.

Step 7: Explore the Event Monitoring Analytics App

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 Pricing

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.

How Do I Know if I have Salesforce Shield?

1. Quick find search: In Salesforce Setup, use the quick find box to search for “platform encryption”. If you see the option appear, this confirms you have Shield.
2. Check your Salesforce licenses: Alternatively, in Salesforce Setup, navigate to Company Information. Check if you have the “Salesforce Shield” license by hovering over “User Licenses”.

Options for Masking Salesforce Data

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.

Getting Skilled Up on Salesforce Shield

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.

Summary

If you’re still wondering, “Why do I need Salesforce Shield?”, it’s worth keeping the following points in mind:

• As always, aim to do it right the first time. It’s certainly not a set-and-forget process; you need to implement Shield and then maintain it over time. You don’t want to waste your (or your security team’s) time protecting medium or low-risk information.
• Data classification is a great way to help guide your Shield efforts, whether it’s for fields you need to encrypt, fields you need to track, or, if event monitoring, knowing where to monitor in the first place.
• Event monitoring or data classification is effective for making sure that you’re taking an efficient approach to Shield, while protecting all of your most sensitive information within the org.

To continue the conversation, check out OwnBackup’s Salesforce Shield Platform Encryption Checklist.