What Every Organization Should Know to Keep Salesforce Secure

Salesforce offers a variety of tools and solutions to help power organizations – from CRM tools such as Sales Cloud, Service Cloud, and Marketing Cloud, to ERP tools such as FinancialForce, to BI tools, such as Einstein analytics. While these tools are bringing effective new solutions to evolving business requirements, they can also introduce unanticipated risks into an organization’s application landscape. Some of these risks include application security risks such as Segregation of Duties conflicts and excessive access.

As security and Segregation of Duties (SoD) risks are becoming more scrutinized by the Public Company Accounting Oversight Board (PCAOB) and external auditors, it is becoming increasingly important to have insights into application security risks and implement a strong security design. In this post, we provide an introduction to the Salesforce security model, along with leading practices for remediating key risks.

The Salesforce Security Model

There are two types of security that make up a user’s access in Salesforce: record level security (i.e. data access) and object level security (i.e. functional access).

Furthermore, object level security is made up of security “containers”:

Profiles: Profiles define how users access objects and data. Profiles were designed to restrict access; therefore, non-sensitive access required for each business role should be captured in the profile design. Only one profile can be assigned per user.
Permission Sets: A permission set is a collection of settings and permissions that give users access to various tools and functions. Permission sets were designed to extend access – they can be leveraged to extend functional access without changing the access granted by the profiles. Multiple permission sets can be assigned per user.
CRUD: This is the access level that is assigned to the objects. CRUD stands for Create, Read, Update, Delete.

While there are additional elements that make up the Salesforce security model, the remainder of this post will focus understanding security risks around object level security.

Establishing a Security Framework and Identifying Security Risks

Before evaluating whether security risks are present within the Salesforce environment, organizations must first understand the types of security risks that may exist and determine the specific, relevant risks.

Segregation of Duties

The basic idea supporting SoD is that no employee or group of employees should be in a position to perform and conceal errors or fraud in the normal course of their duties. In general, the principal incompatible duties to be segregated are:

Custody of assets
Authorization or approval of related transactions affecting those assets
Recording or reporting of related transactions.

The “list” of business activities that would present a risk if combined with one another, along with the risk ranking and risk description, are what make up an organization’s SoD Ruleset.

For example, an organization may consider the SoD rule “Vendor Master Data and Vendor Payments” as a high risk, because a user could update a vendor’s bank account to his or her own bank account, process a payment to that vendor and revert the bank account information back.

In order to determine whether any Salesforce users are in violation of a SoD rule, the next step is to determine which Salesforce technical security objects allow a user to perform each business function, and analyze whether any users are assigned objects from both “sides” of the rule. (This step can be performed manually or by leveraging automated tools such as a Governance, Risk, and Compliance “GRC” application.)

If high-risk SoD violations are identified, ideally, they should be remediated (i.e. access to one of the business functions is removed from the user). If certain high risks cannot be remediated, a mitigating control for the risk should be identified and documented.

Sensitive Access

Sensitive access refers to critical business activities that should be limited to authorized users. Sensitive activities tend to be the ability to modify organizational setups, master data, or system configurations. Additionally, the ability to perform higher risk transactions that are significant to the organization (enter journals, post journals, bank reconciliations, etc.) may be considered sensitive. Similar to SoD, the “list” of access that would be considered sensitive by an organization is what makes up their Critical Access Ruleset.

The difference between SoD and critical access is identifying users with access to one particular business activity, and not a combination of activities. For this reason, expect that all high-risk critical access functionalities are assigned to at least one user. The important element to consider is whether the users who do have that access are appropriate.

Redesigning Salesforce Security

If the organization has established the SoD and Critical Access framework, assessed its current Salesforce production environment, and found a large number of SoD risks and/or excessive critical access assignments, it may be appropriate to consider a security redesign. As opposed to targeted remediation activities, redesigns allow organizations to hone in on current business processes and tailor the security to both meet business requirements and comply with the defined security framework.

There are several phases that should occur as part of a security redesign effort. The below outlines the project phases along with key activities that occur during each phase.

Design: Conducting ruleset workshops (if rulesets are not already defined); conducting role design workshops to understand business requirements; conducting a baseline SoD assessment (if not already completed leading up to the redesign); developing KPI’s / metrics for success; and developing a long term roadmap.
Build: Developing security containers within Salesforce based on design; evaluating security containers for SoD conflicts; and modifying build where applicable.
Unit Testing: Evaluating security containers to ensure objects are accessible or not accessible based on design; and modifying build where applicable.
User Acceptance Testing (UAT): Developing UAT scenarios, facilitating testing of security container functionality (testing performed by business users), updating build to address identified issues, if applicable.
Pilot/Day-in-the-Life Testing (DITL): Facilitating end-to-end testing of new security containers (testing performed by select business users); updating build to address identified issues, if applicable.
User Mapping: Mapping all existing users to newly designed security containers; obtaining appropriate approvals for user assignments (note: this phase occurs in parallel with UAT and DITL).
Go-Live: Developing production implementation package; defining hypercare communication strategy and SLAs; defining a cutover plan, including roll-back (contingency) plan; transitioning users to newly designed security; and removing legacy access.
Hypercare: Providing support for any production issues for a period of time immediately following go-live (note: this phase should span over month-end close to ensure those activities are captured and any issues can be resolved timely).

Conclusion

While there are many additional components that comprise high-quality, holistic access governance (periodic user access reviews, temporary access management, etc.), these components rely on the foundation of a clean security environment. Organizations unsure about Salesforce application security should consider beginning with the following objectives: