Salesforce Shield

• Salesforce Shield is designed for organizations that require enhanced

security and compliance capabilities. It consists of four key components:
Platform Encryption, Enhanced Field Audit Trail, Event
Monitoring, and Einstein Data Detect, with Platform Encryption
being the most prominent feature.
• Salesforce Shield bridges the gap between the Compliance & Security
Team (CISO) and Salesforce Admins, ensuring a unified approach to
meeting critical compliance and security requirements. However, simply
enabling Salesforce Shield doesn’t guarantee complete security. While it
provides robust tools, it should be considered as part of a broader
security strategy, not a standalone solution. Other security controls and
best practices must be implemented alongside it for comprehensive
protection.
Enhanced Field Audit Trail

• Salesforce Shield's Enhanced Field Audit Trail extends the retention

period for field history tracking up to ten years, compared to the 18-24
months provided by standard Salesforce Field History Tracking. This
feature tracks changes to data, including which fields were modified,
when the changes occurred, and which user made the
[Link] field history retention helps organizations meet
business needs, such as accessing historical data for analysis, as well as
legal and regulatory compliance requirements that mandate long-term
data retention and auditing capabilities.
Enhanced
Field Audit
Trail
Comparisi
on
Salesforce Shield Event Monitoring

• User activity monitoring in Salesforce allows you to set transaction

security policies to track user actions, or "events," across browsers, the
Salesforce mobile app, and APIs. The goal is to detect and prevent
suspicious or malicious behavior in real-time, helping to mitigate potential
threats.
• Salesforce provides two types of event monitoring:
• Core Event Monitoring: Allows you to view event streams containing
various user activities, typically updated within a few hours.
• Real-time Event Monitoring: Enables you to track user activities as
they happen in real-time. When specified activities occur, based on
your transaction security policies, you can choose to block the user
immediately and receive notifications. This offers admins proactive
control over potential security risks.
Event Monitoring: Security & Performance
Benefits

• Security Benefits: Event monitoring helps track critical actions that can pose
security risks. Examples include:
• Viewing sensitive pages or data
• Downloading reports
• Running reports containing confidential information
• Performance Benefits: Salesforce also provides robust event monitoring for
performance optimization. This includes tracking events such as:
• Reports that are taking too long to load
• System performance bottlenecks
• Inefficient data queries
• By leveraging event monitoring, organizations can enhance both their security
posture and system performance, ensuring a secure and efficient Salesforce
environment.
Event Monitoring: Example Scenario

• Consider a report containing sensitive information, such as a "High Net

Worth Contacts" report. To protect this data, you can set up event
monitoring to detect when a user attempts to export 5,000+ rows from
Salesforce. For instance, if a departing salesperson tries to export large
volumes of sensitive data, the system can identify this action and block
it in real-time. By leveraging event monitoring and transaction security
policies, you can prevent unauthorized data extraction and protect
valuable information from potential misuse.
• 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: Example Scenario

• Consider a report containing sensitive information, such as a "High Net

Worth Contacts" report. To protect this data, you can set up event
monitoring to detect when a user attempts to export 5,000+ rows from
Salesforce. For instance, if a departing salesperson tries to export large
volumes of sensitive data, the system can identify this action and block
it in real-time. By leveraging event monitoring and transaction security
policies, you can prevent unauthorized data extraction and protect
valuable information from potential misuse.
• 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 offers a pre-built CRM Analytics

App (dashboard), which comes bundled with event monitoring licenses (two
included).
• Events, such as the example of a disgruntled salesperson, are logged and displayed
through various components in the dashboard. You can track user trends, monitor
which reports are being downloaded, and analyze how users are accessing specific
reports.
• Many organizations integrate Salesforce Event Monitoring with external systems like
Splunk or QRadar, allowing them to consolidate Salesforce data with other event
monitoring tools across their technology stack.
• All events are stored in the Event Log File standard object, enabling you to run
queries for in-depth analysis and threat forensics.
Overall Functionality of Salesforce Shield
Event Monitoring.
Set Up Event Monitoring (Transaction
Security Policies)

•To set up Transaction Security Policies in Salesforce, navigate to Setup, and

search for "Transaction Security Policies" in the Quick Find box. These policies
can be configured for Queried Entities, which refers to Salesforce objects.
•For example, you can create a policy that blocks the export of a report
containing over a specified number of high-risk fields. If a user attempts this
action, the export will be blocked, and a notification can be sent to the admin or
Information Security team.
•There are two methods to configure transaction security policies:
•Admin Interface: Use an intuitive interface to set "if-then" conditions that can
block actions, notify you, or require multi-factor authentication (MFA) when
rogue activities are detected.
•Custom Code: Create more complex policies by writing custom Apex code to
handle specific conditions.
Platform Shield Encryption

Salesforce Shield and Datadog

What is Shield?
•Salesforce Shield is a trio
of security tools that helps
admins and developers
build extra levels of trust,
compliance, and
governance right into
business-critical apps.

12
What is Shield? (Cont.)

•Shield is additional product provided by Salesforce which we need to purchase. So, additional
licensing cost is involved. For Sales/Service cloud need to buy shield however with health cloud it
comes with instance.

•Event Monitoring:
• Event Monitoring, a part of Salesforce Shield, gives you access to detailed performance, security,
and usage data on all your Salesforce apps in order to monitor critical business data.
• Event monitoring provides tracking for lots of types of events such as Logins, Logouts, URI (web
clicks in Salesforce Classic), Lightning (web clicks, performance, and errors in Lightning
Experience and the Salesforce mobile app), Visualforce page loads, API calls, Apex executions,
Report exports.
• All these events are stored in event log files. An event log file is generated when an event occurs
in your organization and is available to view and download after 24 hours. Log file retains:
• 1 day for developer edition
• 30 days with extra cost for Enterprise, Unlimited, and Performance Edition

13
What is Shield? (Cont.)

•Field Audit Trail:

• Field Audit Trail lets you define a policy to retain archived field history data up to 10 years from the
time the data was archived. Without it, you retain archived data for only 18 months.
• With Field Audit Trail, you can track up to 60 fields per object. Without it, you can track only 20 fields
per object.
• Field history tracking data and Field Audit Trail data don’t count against your Salesforce org’s data
storage limits.

•Shield Encryption:
• Natively encrypt sensitive and regulated data at rest when it is stored, and not just when transmitted
over a network, so your company can confidently comply with privacy policies, regulatory
requirements, and contractual obligations for handling private data.
• Industries like Finance, Health care are required to encrypt the PII (Personal identifiable information)
and PHI (Protected Health Information) data.

14
What is Shield? (Cont.)

• What can be encrypted along with fields?

• Search index files - Suppose you need to search for PII data in org,
then results are stored in search index files.
• Files and Attachments - The body of each file or attachment is
encrypted when it’s uploaded.
• Chatter - feed posts, questions and answers, link names, and all
comments. Also encrypts poll questions, but not poll choices.

15
Encryption Scheme Types

•Deterministic:
• In this type of encryption, the resulting converted information, called ciphertext, can be
repeatedly produced, given the same source text and key. For example, if you know that
the message 'hello world' has the ciphertext '&yy/ m/jyp' under some form of
deterministic encryption, then that message will always produce the same ciphertext.
• There are 2 Types of Deterministic Encryption:
• Case-Sensitive – Allows for the ability to filter data on a case-sensitive basis. ‘ACME’
and ‘Acme’ will be considered 2 unique values and the encryption scheme would
use different ciphertext strings to identify these 2 records.
• Case-Insensitive – Allows for the ability to filter data but does not factor the case of
the value. ‘ACME’ and ‘Acme’ would be considered the same value and the
encryption scheme would use the same cipher text value for both (assuming the
record is in the same field/object/org).
• Default Type: Deterministic, case in-sensitive

16
Encryption Scheme Types (Cont.)

•Probabilistic:
• Unlike deterministic, it introduces an element of chance. Source
text repeatedly encrypted with the same key will normally yield
different ciphertext. So, a simple message like 'hello world' won't
always correspond to the same ciphertext. Instead, that message
would produce one of many possible ciphertexts each time it's
encrypted.
• This is default encryption scheme used to encrypt data.

• You can mix & match probabilistic and deterministic encryption,

encrypting some fields one way and some fields the other.

17
Steps to enable Platform Shield Encryption

• Create permission set with Name as ‘Key Manager’

• From System Permissions, enable the Customize Application and Manage Encryption Keys
permissions.
• Assign yourself the View Setup and Configuration permission. This lets you enable encryption features for
fields, files, attachments, and apps.
• Assign this permission set to authorized users only.
• Setup -> Platform Encryption ->
• Advanced Settings -> Enable
• Restrict Access to Encryption Policy Settings
• Enable Deterministic Encryption
• Encryption Policy -> Enable if required
• Encrypt files and attachments
• Encrypt Chatter
• Encrypt search indexes

18
 Steps to enable Shield Platform Encryption
(Cont.)

c. Key Management -> Choose Tenant Secret Type

i. For Deterministic
ii. For Probabilistic
3. You can generate tenant secrets for the Data in Salesforce type once every 24
orgs, and once every 4 hours in
hours in production
Sandbox orgs.

19
 • Shield Platform Encryption lets you control and rotate
the key material used to encrypt your data.
• You can use Salesforce to generate a tenant secret for
you, which is then combined with a per-release master
secret to derive a data encryption key.
Key • This derived data encryption key is then used in encrypt
and decrypt functions.
Manageme • Create a strategy early for backing up and archiving

nt and
keys and data. Unlike passwords, you can’t reset a
tenant secret key. Salesforce can’t help with deleted,
destroyed, or misplaced tenant secrets. Always back up
Rotation tenant secrets.
• Grant the “Manage Encryption Keys” permission to
authorized users only. Users with this permission can
generate, export, import, and destroy org-specific keys.
• Encryption applies to all users, regardless of
permissions.
• Refreshing a sandbox from a production org creates an
exact copy of the production org. If Shield Platform
Encryption is enabled on the production org, all
encryption settings are copied, including tenant secrets
created in production.

20
 •Field – Considerations
• Can’t use Shield Platform Encryption with Custom Metadata Types,
Can be used with Custom setting.
• Cannot reference encrypted fields in flows and processes for
filtering or sorting contexts.
• Cannot use Encrypted custom fields in criteria-based sharing rule
• You can’t sort records in list views by fields that contain encrypted
data.
• You can’t use Schema Builder to create an encrypted custom field.

Consideratio • Following fields cannot be encrypted:

• Fields on external data objects

ns • Fields that are used in an account contact relation

• Fields with data translation enabled cannot be encrypted.
• Currency and Number fields can’t be encrypted because they
could have broad functional consequences across the platform,
such as disruptions to roll-up summary reports, report timeframes,
and calculations.
• Shield Platform Encryption is compatible with several operators
and functions, and can render encrypted data in text, date, and
date/time formats, and reference quick actions.

21
Considerations (Cont.)

• Up to 200 formula fields can reference a given encrypted custom field. A field that is referenced by
more than 200 formula fields can’t be encrypted.
• After a custom field is encrypted, you can’t change the field type.
• Date/DateTime supports only probabilistic encryption.
• Platform Encryption cannot be enabled for standard fields when Portals are enabled. Go to Salesforce
Classic UI and search under Setup for “Customer Portal” and Disable Login Enabled.
• Deterministic encryption is available for custom URL, email, phone, text, and text area field types. It is
not available for Custom date, date/time, long text area, rich text area, or description field types of
Chatter and Files and attachments.
• In reports and list views, the operators' “equals” and “not equal to” are supported with case-sensitive
deterministic encryption. Other operators, like “contains” or “starts with,” don’t return an exact match
and aren’t supported.
• Matching rules used in duplicate management don’t support probabilistically encrypted data. When
you rotate your keys, you must deactivate and then reactivate custom matching rules that reference
encrypted fields. If you don’t take this step after updating your key material, matching rules don’t find
all your encrypted data.

22
Considerations (Cont.)

• Formula Field – Supported functions are -> & and + (concatenate), BLANKVALUE,
CASE, HYPERLINK, IF, IMAGE, ISBLANK, ISNULL, NULLVALUE
• & and + (concatenate) operators
• (encryptedField__c & encryptedField__c) – Works
• LOWER(encryptedField__c & encryptedField__c) – Does not work. Lower is
not supported
• If the email field is encrypted using probabilistic encryption, wellness check surveys
can’t be used. Deterministic encryption is fully supported.
• Web-to-Case is supported, but the Web Company, Web Email, Web Name, and Web
Phone fields aren’t encrypted at rest.
• You can have up to 50 active and archived tenant secrets of each type. For example,
you can have one active and 49 archived Data in Salesforce tenant secrets.
• Implement Shield early to reduce challenges.

23
Considerations (Cont.)

•SOQL – Considerations
• Probabilistic encrypted fields cannot be used with
• Aggregate functions such as MAX(), MIN(), and COUNT_DISTINCT() –
• WHERE clause
• GROUP BY clause
• ORDER BY clause
• TIP - Consider whether you can replace a WHERE clause in a SOQL query with a FIND query in SOSL.
• Deterministic encrypted fields does not support
• GROUP BY clause
• ORDER BY Clause
• Deterministic does not support functions - Like /StartsWith for encrypted fields in List Views/SOQL
• Compound Name SOQL (Deterministic Encryption)
• Select Id from Contact Where Name = 'William Jones’ – Does not work
• Select Id from Contact Where FirstName = 'William’ And LastName ='Jones’ - Works

24
Best Practices

• As a best practice, rotate tenant secrets on sandboxes after a refresh. Rotation ensures that production and
sandbox use different tenant secrets.
• Encrypt only where necessary. Not all data is sensitive. Unnecessarily encrypting data, impacts functionality
and performance.
• Create a strategy early for backing up and archiving keys and data. If your tenant secrets are destroyed,
reimport them to access your data. You are solely responsible for making sure that your data and tenant
secrets are backed up and stored in a safe place. Salesforce cannot help you with deleted, destroyed, or
misplaced tenant secrets.
• Grant the Manage Encryption Keys user permission to authorized users only.
• Read the Shield Platform Encryption considerations and understand their implications on your organization.
• Analyze and test AppExchange apps before deploying them.
• Synchronize your existing data with your active key material. Encrypt your data using the most current key.
When you generate a new tenant secret, any new data is encrypted using this key. However, existing
sensitive data remains encrypted using previous keys. In this situation, Salesforce strongly recommends re-
encrypting these fields using the latest key. Contact Salesforce for help with re-encrypting your data.
• The encryption statistics detail view shows you which fields in an object contain encrypted data. Use this
information to periodically evaluate whether your encryption policies match your organization’s encryption
strategy.

25