Complete guide of Salesforce Shield

What Is Salesforce Shield?

The effective security products from Avancer, like Salesforce Shield, are created with layers of security for your business in mind. With multiple data protection steps, protect your clients’ private information. Before using the Shield’s security features, become familiar with its workings. Salesforce Shield is for organizations that need extra security and compliance requirements.

The four parts of Salesforce Shield are as follows:

• Platform encryption: Integrate native data encryption while storing data “at rest,” or in Salesforce data centers.
• Field audit trail: Monitoring changes to a field. Keep old field history information for up to ten years.
• Event monitoring: Monitoring user activity to identify and mitigate threats
• Einstein Data Detect: Scan for sensitive data and deeper insights.

Shield’s features can be used for all of the Salesforce “cloud” products your company utilizes because it is a “Salesforce Platform” product, enabling the reduction of data risks across the spectrum.

Salesforce Shield is an add-on product that costs more than 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 provides hardware, network services, and the underlying infrastructure at a high level, but a shared security responsibility model is in place. As a result, your company and Salesforce, the provider, are both accountable (the customer). As a result, any configuration or customization of Salesforce must be handled by the customer, who is ultimately liable for any associated risk.

To assist clients in managing the shared responsibility model's security measures, Salesforce Shield adds an additional layer of security.

In addition, Salesforce Shield offers capabilities that are not included with Salesforce by default (we’ll explore these in more detail later). These are especially important for clients who use Salesforce to store sensitive data and/or work in regulated fields.

Let’s examine each of the components that make up Salesforce Shield.

1. Salesforce Shield Encryption

You may manage your encryption keys with Salesforce Shield and secure your Salesforce data at the field level using AES 256-bit encryption. Significant lessons from 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 actual data.
• Encryption policy: For files and attachments, this policy encrypts these in an “all or nothing” manner (i.e., not selectively according to specific files).
• Manage your 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 mainly 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 impact 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 critical management infrastructure in place can “bring your own key” (BYOK). This is common among enterprise customers, who require complete control over the rotation of the keys. Establishing the infrastructure for 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):

Probabilistic encryptionDeterministic encryptionEncryption level256-bit AES encryption256-bit AES encryptionInitialization vector (explained below)Fully randomized Initialization Vector for the orgStatic Initialization Vector for each field (i.e. not the whole org)Relative securityMore secureSecure, but less secure than ProbabilisticImpact on filtering and functionalityNegative impacts, interfering with filtering capabilitiesAllows matching different pieces of data together, therefore supports some filtering capabilities (Exact Match, only — no “contains”, “LIKE”, “greater than”, “starts with” etc.)

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. The table above shows 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 functional 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 need to contact Salesforce support to have existing files and attachments encrypted.
• It does not obfuscate the data; data is still primarily 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:

Standard Field Audit TrailShield Field Audit TrailNumber of fields supported:20 fields per object60 fields per objectHistory retention periods:18 months within your Salesforce org, 24 months via API*1 month to 10 years retention policies vary by object. NoYesWhere is the trail accessible?[Object] History-related list[Object] History-related list. After X months, data is sent to the field history archive. This can then be permanently deleted after some time. Your organization defines these time periods

*Customers can use Data Loader or the query () 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 a few hours.
• Real-time event monitoring: View events happening in real time. As an admin, when these defined activities occur, you can 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 specific 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 various components. You can monitor trends by a user, which reports are being downloaded, or how users access specific reports.

Many customers will 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 analyze 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

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. accounts, cases, and contacts,
• Set data policies that 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 typical example is when support agents unintentionally added information 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 potentially having sensitive patterns.

Take ​​a look by the object to see, for example, these specific fields on the account need to be reviewed and classified appropriately:

Back to the Case example — we have stored credit card information, and we can see in specific fields which patterns have been detected. Einstein Data Detect shows me that credit card numbers are 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 excellent 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 total 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 consider 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 that offers a Data Classification tool to 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 used before encrypting data.

At this stage, the inputs for the analysis are:

• We identified sensitive fields 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 discuss with the business 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 that Salesforce provides.

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 your objects, fields, and classification in a single view. Logically, we’ll set tracking up for our sensitive fields.

Icons, like the brown face, indicate that you have high-risk fields that are not being tracked. So, set the tracking on fields, 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 will be 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 that 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 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

What kind of learning curve is there when a Salesforce Admin first uses Shield?

There may be a steep learning curve because security is its own field. We have looked into extra tools to help you get started because of this. Finding partners with a wealth of subject matter experience is crucial.

Having said that, Salesforce Shield is a great chance to connect the Compliance & Security Team (CISO) and Salesforce Admins, assisting everyone in being on the same page regarding important compliance procedures.

In addition to this guide, Avancer offers excellent resources. The Security & Privacy professional credential, which includes Salesforce Shield and the Salesforce Privacy Center, is available to staff members of Salesforce partners.

Summary

If you’re still unsure as to why you require Salesforce Shield, bear the following considerations in mind:

• Always try to complete tasks correctly on the first try. You need to implement Shield and then maintain it over time; it’s not a procedure you can just set up and forget about. You don’t want to waste time defending medium- or low-risk information (or the time of your security staff).
• When it comes to fields you need to track, fields you need to encrypt, or, if you’re using event monitoring, knowing where to start watching, data classification is a wonderful method to help direct your Shield efforts.
• It is possible to take an effective strategy to Shield while safeguarding all of your most sensitive information inside the organization using event monitoring or data classification.

To continue the conversation, connect with us for Salesforce Shield expert Services.