How To Use Attribute-Based Access Controls to Streamline the SAP Segregation Of Duties Exception Process

Secure, compliant, and efficient business processes are critical to enterprise operations. In SAP, Segregation of Duties (SoD) is a key principle in making this possible.

What Happens When an SoD Exception Is Necessary?

Often times a user will need to be granted roles and privileges that pose a conflict of interest. It could be that an employee is part of a small department or that a security clearance precludes others from involvement. Whatever the reason, this user needs the ability to handle multiple steps in a business process – and an exception is made.

Here’s where things can get tricky. Once an SAP Segregation of Duties exception is made, your standard preventive controls are no longer effective. This is one of the major shortfalls of SAP’s static, role-based access controls.

Shifting from a Preventive Approach to a Detective Approach

You must now gather access logs, filter out false positives, and finally, send them to the appropriate control owner to review and sign off. Besides the additional overhead of manual reviews and approvals, detective controls create room for human error and increase the dwell time before red flags are caught.

So Why Are Current SAP SoD Controls Limited?

Without the logic ability to decipher potential violations from actual violations, preventive controls are a non-starter. Your (preventive) SAP access controls determine authorizations based on two things: 1.) a user’s role and 2.) the role’s associated permissions (think transactions.) While this works in the vast majority of cases, enforcing SoD requires controls with more granularity.

Let’s Take a Look at What an Actual SAP SoD Violation Entails

The whole objective of SoD is to avoid conflicts of interest in your business processes. Although, conflicting transactions do not necessarily pose a conflict of interest, unless the subject is the same.

For example, a user performs the transactions to create and approve multiple purchase orders. Looking at the transactions themselves, this activity has the potential for violations. Looking deeper into the PO details, you may see that the user never created and approved the same PO – therefore, no violation was made.

SAP can show you 1.) the user and role and 2.) the transactions performed, but is missing the 3^rd component: the field-level values in the PO itself. This lack of visibility into attributes beyond roles and permissions is what makes preventive controls a non-starter and clutters SoD audit logs with false positives when SAP Segregation of Duties exceptions have been made.

The Solution? Enforcing SAP SoD Policy with Attribute-Based Access Controls

Attribute-Based Access Controls (ABAC) enable the use of “attributes” in authorization decisions. These attributes can be anything from user details such as role, department, nationality, or even a user’s security clearance level. Additionally, access context such as IP address, location, time, device, and transaction history can be considered. And most importantly for SoD, data attributes can now be used in authorization logic. This means that field-level values within SAP can be used to determine whether to block or allow a transaction, and these details can further be used in reporting activities. 

In the Purchase Order example above, data attributes can be used to identify whether a user performed the first transaction and make the correlation that performing the second transaction would result in a violation.

Combining SAP’s role-based access controls (RBAC) with an attribute-based access control (ABAC) solution enables granular control and visibility that delivers a wide range of business benefits.

Newfound Flexibility in SoD Exception Scenarios – RBAC + ABAC Hybrid Approach

The RBAC + ABAC hybrid approach opens the possibility to apply preventive controls in SoD exception scenarios. By doing so, you can offer users the flexibility an exception provides while still preventing any actual violations from happening.

Together, this hybrid approach (RBAC + ABAC) enables a dynamic SoD model that prevents violations while still allowing the flexibility of conflicting roles to be assigned (when necessary) and reinforces role-based policy to mitigate over-provisioning.

RBAC + ABAC Hybrid Approach Using Pathlock

Pathlock adds an additional authorization layer to SAP GRC Access Control that correlates user, data, and transaction attributes, along with identified SAP SoD conflicts, to block conflicting transactions at runtime.

Contact Us to learn more about how a hybrid access control approach can strengthen the Segregation of Duties (SoD) at your organization.