By Rob Burkett, Principal, Banking & Credit Union Solutions and Greg Grinberg, Director of Technology

When it comes to CRM platforms, security is a must for industries that handle a high volume of personal data from both customers and business alike. Within the realms of Financial Services, security extends beyond the need for complex passcodes. An entire ecosystem of industry regulation exists that must fit into any CRM platform for it to be financially viable and sustainable, with constant updates as needs arise.

Fortunately, Salesforce is a robust CRM platform that comes with a lot of baked-in security tools. Unfortunately, it’s common for a banking institution to begin using Salesforce without understanding the security features they own or how to best leverage them.

We’re here to cover the security measures included with an out-of-the-box Salesforce instance and demystify their features. In a future article, we’ll cover the added benefits of Shield Platform Security.

Security Tools Included with the Salesforce Platform

To explore these security tools, let’s break out security into a few easy-to-manage buckets: Access, View, Do, and Control/Monitor.

1. Access

The first level of defense for securing your data is preventing unauthorized access to it (i.e., don’t let a nefarious individual get their hands on one of your user’s passwords).

Below are the most common ways to control system access and protect sensitive data. Once you master these, there are more controls available within the system for you to explore.

• Password Policies give admins the flexibility to dictate password requirements like number of characters, character types, number of passwords remembered by the system, etc.
• IP Restrictions ensure users are on your network before they can access your data, most commonly by being in the building or logging in via VPN.
• Device Activation requires users to authenticate with another method (i.e., type in a verification code received via text or email) in addition to logging into your org with a username and password before they can access your data.
• Multi-Factor Authentication requires users to authenticate using a U2F token or on a trusted mobile application before they can access your data.
• Custom Login Flows give admins the flexibility to add additional questions and actions for the user (ex: answer a secret question or verify other information in order to log in).
• Login Hours allow admins to restrict when users can log in to the system (e.g., between 8-5pm, during normal working hours).
• Single-Sign On makes it easy for users to sign into the system without setting up a new username and password, and instead using their company username and password. This allows company IT teams to enforce the same company-wide password policies that are adhered to with other systems.

Fast Fact: Salesforce Platform Access

It’s important to note that Platform Encryption, a Salesforce product available at an additional cost, does not prevent authorized users from accessing your sensitive data or unauthorized users from logging into your Salesforce org.

2. View

Salesforce has several layers of security that can control what a user will see once successfully authenticated (i.e. their identity has been verified). There are more controls available within the system, but we’re going to cover the most common methods of controlling data visibility.

• Object Level Security gives an admin the ability to control which objects a user can view. As an example, if you only want a certain job function, let’s say executive management, to be able to view a custom “survey” object, the object can be restricted to only executive user profiles
• Field Level Security (FLS) gives an admin the ability to control which user can view which fields. FLS is set for each field in the system and can be restricted or granted by profile. Permission sets can also extend FLS to specific users (permission sets lay on top of profiles to extend permissions, not restrict). As an example, if you only want a certain job function, let’s say branch tellers, to be able to view a customer’s SSN, then you would simply make the SSN field visible to tellers and hide it from all non-teller profiles.
• Sharing Rules allow you to share records based on record ownership or certain record criteria (i.e. If owned by a user in the “Marketing” role, share with all users as “Read Only”).
• Standard Encryption gives an admin the ability to encrypt a custom field (encryption at rest) and dictate if it’s masked or not. You can grant permissions to profiles/permission sets to view all encrypted data, you just need to understand that it’s an all-or-nothing deal. A user can either view all encrypted data, which applies to all encrypted fields, or they can’t. FLS still applies and all users with access to the field will be able to view the masked value and those with the additional permission can view the entire value. Using the SSN example above, if you create a custom SSN field and mask all but the last four characters, then those users with the ability to view the SSN field will see it formatted as xxx-xxx-1234. And anyone with the ability to view encrypted data will see it formatted as 123-123-1234. And anyone without access to that field via the FLS, can’t view the field at all.

Fast Fact: Salesforce View Access

It’s important to understand that there are tools that control who can access your sensitive data after they have successfully been authenticated.

3.Do

Once a user has authenticated and can access the fields available to them, admins have a few tools to control their permissions and what they can do within the system.

• Profiles control what a user can do with specific objects. An an example, you can set permissions on the Account object to read, create, edit, and delete. This controls what a user can do with Accounts they own. Additionally, “View All” and “Modify All” permissions can be extended on the profile, which controls what a user can do with Accounts other user’s own. Roles help extend this permission, which we’ll detail further below.If you extend “delete” permission to the Account object for a profile, the user can delete accounts they own, but they cannot delete accounts other users own (unless they have the “Modify All”) permission. Profiles additionally control over 100 general and administrative permissions, but we won’t dive that deep in this piece.
• Org-Wide Settings control what you can do with other’s records. As an example, if the org-wide setting for Accounts is private, then a user can only view the following:
  • Accounts they created
  • Accounts of users below them in the role hierarchy
  • Accounts that were manually shared with them
  • Accounts that were systematically shared with them via sharing rules/apex sharing

  If the org-wide setting for Accounts is Public Read Only, then a user can view all accounts regardless of ownership.

NOTE: If you need some Accounts to be private, then you would set the org-wide defaults to Private and open up sharing with sharing rules.

• Page Layouts control if a field is editable to end users. This is often the case for customer data sent to Salesforce via integration. If a customer exists in both Salesforce and your core system, or another system is the source of truth, the admin can lock down the integration fields on the layout to prevent users from editing. While this isn’t a foolproof way to lock down these fields, it’s fairly common practice and typically acceptable to the financial institution. Of course, if you have inline editing turned on (for example), users can still find ways to edit these fields, they will just be reverted to the previous values after the integration runs.

Luckily, you can use validation rules in conjunction with page layouts to ensure edits cannot be made.

• Validation Rules prevent users from editing a record based on conditional logic. For example: you can prevent a user from editing certain fields on an Account if the record type is “Individual Customer.”
• Roles extend user permissions for things they “own” to those above them in the role hierarchy (i.e. their manager and their manager’s manager).
• Sharing Rules allow you to share records based on record ownership (If owned by a user in the “Marketing” role, share with all users as “Read/Write”) or certain record criteria.

Of course there are many other security features worth exploring that we won’t cover here — we’re just focusing high-level on platform encryption capabilities and not detailing an exhaustive of all security measures available.

Fast Fact: Salesforce Profiles

It’s important to understand that there are tools that control what data users can see in the system and what they can do with the data after they have successfully been authenticated.

4. Monitor/Control

Once your users are in the system, what happens if someone goes rogue and attempts to steal data? Salesforce has tools available to help with that.

• Export Reports is a profile permission that can be left unchecked to prevent users from exporting data (i.e. exporting all the customers in the system into an Excel file). You can also use session-based permission sets to allow a user to export reports only when logged in from certain locations.
• Report Folder Security can be used to to limit exposure of non-essential data to users. As an example, you can create a “Sales Reports” folder that shows only “My Pipeline” or “My Activities” to prevent users from viewing institution-wide data. This reduces the ability to view other user data and take screenshots as a means of pilfering system data.
• Field History can be set on up to 20 fields on an object (up to 60 if you purchase SHIELD) and will track changes including the user, prior value, new value, and date/time of the change. This is also fully reportable.
• Setup Audit Trail allows the administration team to view what configuration/administration changes have been made in the system. This tracks a ton of configuration changes like if a profile was created, a page layout deleted, a workflow or validation criteria was changed, etc.

Fast Fact: Salesforce Monitor/Control Tools

It’s important to understand that there are tools that allow administrators the ability to monitor what users have done in the system and prevent data theft or other suspicious user activity.

What if we Need More Security Than Salesforce Offers Out of the Box?

If you cannot accomplish what you need to accomplish with standard Salesforce security, then your financial institution should check out Platform Encryption, the subject of our next article.

Silverline’s Financial Services Practice Team has deep experience within each Financial Services vertical to help you explore all the security functions Salesforce has at your fingertips. Learn more about Silverline’s Security Services.