<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

Keeping Salesforce Secure: What You Need to Know

Anyone who uses Salesforce will agree that the solutions it offers—CRM (Sales Cloud, Service Cloud, Marketing Cloud), ERP (FinancialForce), and BI (Einstein analytics)—are ideally suited for helping businesses tackle ever-changing requirements. However, with all that power comes more risk, most of it unanticipated, into the application landscape of an organization. Typically, these risks fall under the headings of Segregation of Duties conflicts or excessive access.

As the Public Company Accounting Oversight Board (PCAOB) and other external auditors more closely scrutinize these areas, it is more important than ever to uncover these risks and implement a security strategy that addresses them. This blog discusses best practices for remediating risks within the Salesforce security model.

An Overview of the Salesforce Security Model

Before discussing risks, it’s important to understand the Salesforce security model:
A user’s access in Salesforce is made up of two types of security—record level security, such as data access, and object level security, such as functional access. Object level security is comprised of containers.

Salesforce Security - Record and Object Level
Figure 1. User access security in Salesforce contains two types: Record level and object-level.

Salesforce Security with Fastpath


Figure 2. Object level security in Salesforce is comprised of containers.

Containers are broken down into three categories:

  • Profiles define how objects and data are accessed by users. Because their purpose is to restrict access, it is important that the non-sensitive access required for each business role is captured in the profile design. Users can be assigned only one profile.
  • Permission Sets are collections of settings and permissions that provide users with access to various functions and tools. Unlike profiles, permission sets are designed to extend access. Therefore, they can be used to extend functional access without having to change the access granted by the profiles. Users can be assigned multiple permission sets.
  • CRUD (Create, Read, Update, Delete) is the access level assigned to objects. This is the access level that is assigned to the objects.

Note: There are other elements included in the Salesforce security model, this blog focuses on the security risks associated with object level security.

There are two primary steps involved in securing Salesforce

 
Step 1: Establish a Security Framework and Identify Risks

Prior to performing an evaluation of the Salesforce environment to determine the presence of security risks, it is important to understand the types of security risks that might exist and determine the relevant, specific risks. Following are areas of risk:

Area of Risk: Segregation of Duties

The concept of Segregation of Duties (SoD) is based on the idea that no employee or employee group should ever be put in a position where they can perform and conceal errors or fraud during the normal course of their duties.

The principal duties that are “incompatible” and need to be segregated are: custody of assets; authorization or approval of the related trans¬actions affecting those assets; and recording or reporting related transac¬tions.

The SoD Ruleset is the list of activities that would create risk if combined in any way, as well as the risk ranking and description. So, for example, if a company has an SoD rule called Vendor Master Data and Payments, it would be considered high risk because a single user could update a vendor’s bank account to his or her personal bank account, process a payment to that vendor so the payment goes into that account, then change the bank account information back to the original account.

In Salesforce, the process for determining if users are in violation of a SoD rule is as follows:

  1. Determine which Salesforce technical security objects allow a particular user to perform each business function.
  2. Determine if any users have been assigned objects from both sides of the rule, e.g., allowed to change vendor master data as well as processing payments. Note that this step can be performed either manually or by using automated tools like a governance, risk, and compliance (GRC) application.

Any high-risk SoD violations are identified should be remediated. In the example above, either the ability to change vendor master data or the ability to process payments would be removed from the user. If the risk cannot be remediated, the organization should identify and document a mitigating control , such as an audit trail identifying changes to the vendor bank accounts and reviewed on a regular basis.

Area of Risk: Sensitive Access

Critical business activities that should be limited to authorized users are referred to as sensitive access activities. Sensitive activities typically involve the ability to modify system configurations, organizational setups, or master data, as well as the ability to perform higher risk transactions that are considered significant to the organization, like entering journals or posting journals. The Critical Access Ruleset, which is similar to the SoD, is a list of access that the organization considers sensitive.

Unlike SoD, however, critical access involves identifying users with access to one specific activity, rather than a combination of activities. This is why organizations should expect that all high-risk critical access functionalities are assigned to at least one user, so it’s important to consider whether those users who have access are the appropriate users.

Step 2: Redesign Salesforce Security

If, after establishing its SoD and Critical Access framework and assessing its Salesforce production environment, the organization has discovered a large number of SoD risks and/or excessive critical access assignments, it should consider redesigning its Salesforce security. Unlike targeted remediation activities, a redesign allows the organization to focus on current business processes and tailor Salesforce security to meet business requirements and comply with the defined security framework.

The following phases and key activities that occur during each phase should be part of an organization’s security redesign effort:

Salesforce Security and Ongoing Governance with Fastpath

Design

  • Conduct ruleset workshops if rulesets are not already defined
  • Conduct role design workshops to understand business requirements
  • Conduct a baseline SoD assessment if one wasn’t completed prior to the redesign
  • Develop KPIs/metrics for success
  • Develop a long-term roadmap

Build

  • Develop security containers in Salesforce based on design
  • Evaluate security containers for SoD conflicts
  • Modify build where applicable

Unit Testing

  • Evaluate security containers to ensure objects are accessible/not accessible based on design
  • Modify build where applicable

User Acceptance Testing (UAT)

  • Develop UAT scenarios
  • Facilitate testing of security container functionality (testing performed by business users)
  • Update build to address identified issues (if applicable)

Pilot/Day-in-the-Life Testing (DITL)

  • Facilitate end-to-end testing of new security containers (testing performed by select business users)
  • Update build to address identified issues (if applicable)

User Mapping

  • Mapping all existing users to newly designed security containers
  • Obtain appropriate approvals for user assignments (Note: This phase occurs in parallel with UAT and DITL)

Go-Live

  • Develop production implementation package
  • Define hypercare communication strategy and SLAs
  • Define a cutover plan (including a roll-back/contingency plan
  • Transition users to newly designed security
  • Remove legacy access

Hypercare

  • Provide support for production issues for a period of time immediately following go-live (Note: This phase should cover a month-end close to ensure those activities are captured and issues can be resolved in a timely manner)

The Bottom Line: A Clean Security Environment

A holistic, high-quality access governance includes many additional components; however, all these components rely on a foundation of a clean security environment.

If you are concerned about Salesforce application security, consider starting with the objectives outlined in this blog:

  • Understand the Salesforce security model
  • Create and establish a security framework
  • Evaluate the current environment, comparing it with the organization’s framework
  • Assess risks and determine steps for remediation

Watch this on-demand webinar presented by Protiviti and Fastpath to see why Segregation of Duties is so critical for your company.

Watch the On-Demand  Segregation of Duties Video