When searching for the culprits responsible for SAP access risk, look in your application security architecture and design. The composition of the security model, the maintenance, and provisioning of security are all critical components to minimizing access risk across your environment(s). Without an overarching governance process and key design principles, the security model could be the root of a multitude of challenges, including:

• Intra-Role and User-Level Segregation of Duties Conflicts
• Excessive and Unintended Access
• Sensitive and Critical Access Violations
• Audit Findings and Control Violations

Intra-Role Segregation of Duties Conflicts

To start, an intra-role segregation of duties (SoD) conflict is when two or more conflicting permissions coexist in the same role. This means every time the role is assigned so is the conflict. This is a critical concept and often the starting point for many security remediation or redesign projects. Oddly enough, this is a common finding following an implementation or an upgrade to an existing ERP. This could derive from deprioritizing security so as not to jeopardize the go-live, copying the standard SAP roles for user assignments, or simply inadequate controls and governance of the security design. It is imperative that the security roles are designed without intra-role SoD conflicts to facilitate compliant user assignments.

Excessive and Unintended Access

Excessive or unintended access can also stem from a variety of sources. This can exist due to poor role design or a collection of role assignments to a single user. From a role perspective, the composition and maintenance of permissions is the foundation of a compliant security design. Some of the common violations we see are asterisk (*) values being maintained which is equivalent to all permissions within that respective object field. The ‘*’ value is a common culprit for many access risks even being used for S_TCODE access in some cases. Other common findings include roles defined as display containing access beyond read-only privileges or roles containing cross-functional access.

From a user perspective, a single role or multiple roles assigned can lead to excessive or unintended access. As an example, when multiple roles are assigned, they could have object collision resulting in unintended results. Perhaps the most common role assignment activity leading to risk is the statement, “copy <insert colleague’s name here> access”. Far too often, this statement is used, resulting in an assignment of roles that may or may not align with that person’s job responsibilities. Not only does this pose a risk, but it is often compounded as the existing access is overlooked and not removed from the user. Organizations with a mature security and compliance program utilize tools such as Fastpath Assure to implement automated provisioning processes that are driven by workflow and consist of SoD and critical access checks. This is a critical preventive control for maintaining a compliant environment.

Sensitive and Critical Access Violations

Sensitive and critical access can have a different meaning to each organization as they span across a variety of industries, geographies, regulatory landscapes, and more. Within SAP there are standard transactions and authorizations that can be deemed sensitive. A transaction could be defined as critical or sensitive as it is the gatekeeper for customer information or even intellectual property. Not only is it important to know who is accessing your critical data, but organizations must also be concerned with where they keep that information. GDPR, CCPA, and other regulations impose strict guidelines on how to collect, manage, and access customer information.

Below are a couple of examples of authorizations that an organization may deem sensitive:

• Table Authorizations: Authorization objects S_TABU_DIS and S_TABU_NAM are the permissions in which control access to tables and data. These can be called from a table viewing transaction such as SE16N or a defined transaction like OB52. Object S_TABU_DIS delivers permissions to a collection of tables in the backend called authorizations groups. S_TABU_NAM allows a user to define a specific table by name. This latter is the preferred approach when granting access to end users as the standard delivered authorization groups can contain thousands of backend tables. The utilization of S_TABU_DIS and ‘*’ values are often the catalyst for excessive or unintended access leading to audit finding.
• Developer or debug access is a well-known authorization object that is deemed as sensitive. The object, S_DEVELOP with DEBUG access, can pose a serious risk as one could bypass authority checks in the code by entering in debug mode, setting breakpoints, and skipping or manipulating parameters. Fastpath comes with a standard report to easily identify users assigned this authorization with a click of a button. Below is an example of a breakpoint in set in a manner the user can manipulate the returned value to “pass” the authorization check.

Defining a Security Architecture

There are many different approaches and standards which can be leveraged when defining security architecture. The one constant each organization should strive for is a compliant security model. This can be achieved irrespective of a task-based, job-based, master-derived, or an enabler architecture is implemented. Some of the key elements to implementing a compliant security model are:

• Key Stakeholders
• Ownership and Accountability
• Compliant and Scalable Design
• Defined SoD and Critical Access Ruleset

Key Stakeholders – Stakeholders should be identified from the onset and consist of executive sponsorship, business, IT, compliance, SMEs, and other team members. Buy-in from the top is a key success factor. Keep in mind that implementing a compliant security model could impact existing processes, be resource demanding, and potentially result in organizational change. These can pose many challenges for organizations without the appropriate stakeholders.

Ownership and Accountability – Top-down buy-in is critical to empowering team members, establishing accountability, and defining metrics is vital to the success of an access management program. Ownership throughout the lifecycle facilitates buy-in and thoughtful input for defining and sustaining the security model.

Compliant and Scalable Design – Ensure the architecture facilitates the day-to-day operations seamlessly to end users and is constructed in a compliant and scalable manner. The architecture should consider things like industry, geography, organizational structure, and much more. “Key design principles” should be established and documented for ongoing governance. This could include approaches like the principle of least privilege as well as specifics to avoid SoD and critical access conflicts as highlighted above.

Defined SoD and Critical Access Ruleset – Establishing an SoD and critical access ruleset is the foundation to monitoring and managing access risk across the landscape. The ruleset should be tailored to be reflective of the organization’s risk universe and appetite. It should include defined risk criticalities, consist of customizations, established framework of when violations should be mitigated or remediation, and much more. The ruleset should be validated and approved across the business and IT, and even reviewed with internal/external audit partners for future reliance.

Tips to Catching the Culprit: System Authorizations and Accounts

There is a one-size-fits-all approach for the “culprits”. The considerations remain the same: control framework(s), policies and procedures of a compliance program, the people/owners/approvers accountable, and the technology to improve the efficiency and effectiveness of overall operations. Below are some approaches to managing these associated risks for System Authorizations and Accounts:

• Develop a customized SoD and critical access ruleset reflective of risk universe. Fastpath is delivered with an out-of-the-box ruleset to give customers a starting point for assessing access risks and developing their own framework.
• Establish a continuous access governance and controls program by developing policies and procedures laying out the framework for security architecture and ownership. This should include key design principles and processes to facilitate the deployment and ongoing maintenance of a compliant security model. Without an SoD conflict-free architecture, organizations will face an impossible battle of risk-free user assignments.
• Leverage tools to assess access risk as detective and preventative controls. The SoD and critical access analysis can be performed on a defined periodic basis utilizing tools such as Fastpath’s Access Risk Monitor (ARM). Other modules within Fastpath’s security and compliance platform, such as Security Designer and Identity Manager, enable a more proactive approach, assisting organizations in implementing preventative controls.
  • Security Designer enables administrators to model security and perform SoD and critical access analysis on security roles prior to making the change in the system. Once validated, the role can be published into the SAP development environments automatically from withing Fastpath’s single pane of glass UI.
  • Identity Manager enables organizations to evaluate risk at the user level during the provisioning or de-provisioning processes. Utilizing an automated workflow-driven process with integrated SoD and critical access checks prevents risk from entering the system. If the access risk cannot be remediated, a mitigating control can be applied prior to completing the request.
• Fastpath’s Emergency Access grants authorizations to users on a temporary basis. This is often referred to as “firefighter” or even Privileged Access Management (PAM). This can be an effective tool for delivering critical authorizations or sensitive access by layering in controls. These can include approvals of access, defined periods the access is permitted down to the minute, and even activity logs for review and approval once the access is removed.