From stopping fraud, theft, and errors to preventing SOX compliance violations, SAP Segregation of Duties (SoD) plays a lead role in minimizing business risk. Organizations must continuously iterate their internal controls to ensure their SoD strategy is effective; however, we all know this is easier said than done.
Finite Resources & Manual Processes Can Only Address So Much
With existing capabilities, audit preparation and reporting are manually intensive processes that deliver an outdated snapshot of risk. Time and effort are wasted investigating immaterial events (i.e., false-positives, non-financial activity) because audit logs miss relevant details. Furthermore, manual analysis can be prone to errors, unscalable, and increasingly costly.
Due to resource-intensive audit processes, most organizations can only review a fraction of their SoD audit findings. This limited sample scope, typically between 3-8%, leaves the vast majority of risk unaddressed. While the sample may indicate control effectiveness, significant material risks may go undetected, and confidence will be curbed.
Leveraging Technology to Reduce Your SAP SoD Risk Exposure
Existing SAP SoD audit logs will show transaction activity but lack the data-level granularity to identify and filter out false-positive SoD violations. Manual investigation and correlation must be performed to do this – adding overhead, slowing the reporting process, and making it more difficult to prove compliance.
The bottleneck stems from technology and dictates unscalable processes. One approach to overcome this challenge is to adopt data-centric logging, which provides relevant details beyond roles and transactions – enabling customers to automate the majority of manual investigation and correlation efforts. From here, organizations can shift their valuable human resources towards remedial activities to further reduce SoD risks.
How Appsian Improves SAP Segregation of Duties Violations Management
Delivering data-centric logs paired with contextual information, Appsian360 provides visibility into SoD violations with far greater detail than what is possible with existing transaction-level audit logs. This additional information enables customers to eliminate false-positives automatically, view actual SoD violations, and prioritize events based on relevant details (e.g., dollar amount, time/location performed, etc.)
Leverage data-centric visibility to streamline SAP Segregation of Duties:
- Uncover 100% of SoD violations with data-centric continuous controls monitoring.
- Capture actionable details that would previously require manual investigation.
- Gain an always current view of SoD risks with continuous audit capabilities.
- Prioritize investigation & remediation activity by eliminating wasted effort on immaterial events.
- Simplify proving compliance with granular visibility and contextual information that is missing from existing audit logs.
- Get a Demo of Appsian360 and See for Yourself
As the burden of SAP SoD compliance grows, organizations must look towards technology to help automate tedious manual processes and strengthen internal controls. At Appsian, we’ve built our solutions with this need in mind, delivering a platform that enables SAP customers to do more with less. Contact us today for a demo, and let’s explore how we can help your organization streamline SAP segregation of duties.
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 SoD exception is made.
Here’s where things can get tricky. Once an SoD 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 and review 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 ability to logically 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 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 3rd 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 exceptions have been made.
The Solution? Enforcing 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. You can consider additional contextual attributes such as IP address, location, time, device, and transaction history. And most importantly, for SoD, you can now use data attributes 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 – ABAC + RBAC Hybrid Approach
The ABAC + RBAC 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 (ABAC + RBAC) 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 Appsian
Appsian adds an additional authorization layer to SAP GRC Access Control that correlates user, data, and transaction attributes, along with identified SoD conflicts, to block conflicting transactions at runtime.
Contact Us to learn more about how a hybrid access control approach can strengthen Segregation of Duties (SoD) at your organization.