Every organization using SAP ERP applications faces the unique challenge of maintaining a strong security posture while enabling productive business processes. Throw in the uncertainty of today’s rapidly changing environment, and you can bet that IT professionals and business stakeholders are facing misalignment between IT controls and business rules and objectives. 

To discover how organizations are evolving their security and risk management practices, Appsian commissioned a survey of nearly 200 senior stakeholders using SAP applications through an independent market research firm. We compiled the results of our survey into the SAP Security Report: Executive Perspective on SAP Business Risk Management. 

We found that this rapid state of change in today’s environment has brought about a new normal for acceptable risk in SAP – but not by choice. While some organizations are adopting new processes and technology to address risk, legacy strategies are holding back many in their path towards efficiently managing ERP data risks. 

We also uncovered four key takeaways from the respondents: 

1. Business Process Risks Are Slipping Through the Cracks 

Executive confidence is wavering in an organization’s ability to detect business risks from fraud, theft, and human error. While concern is generally high, a lack of consistent visibility into these business processes highlights a gap that many have yet to address. 

2. IT Leaders Are Concerned About Excessive User Privileges 

Excessive user privileges continue to be a top concern of leadership – and for good reason. Users have the keys to your kingdom, and with this, pose a heightened risk if their accounts are compromised or if they engage in malicious activity. 

3. Misalignment is Hurting Confidence in SAP Security 

Tight alignment between SAP security controls and business goals and objectives is paramount to secure, compliant, and efficient business processes. However, many respondents signal that the two are not aligned effectively. 

4. Limited Visibility & Complex Controls Are Hindering Progress 

Organizations are facing the limitations of their existing technology and processes. Solving this will require a new approach to overcome complexities in controls and limited visibility into their business-critical applications. 

Want to gain a better understanding of how organizations are evolving their ERP security and risk management practices? Curious about the kinds of risks organizations are most concerned about, and how they view and prioritize user and system visibility, access control, oversight, and accountability? 

Download your free copy of the SAP Security Report today and take a deeper dive into these findings.  

In these less than ordinary times, organizations are dealing with disruption at a frequency higher than ever before. An unfortunate side-effect of this COVID crisis has been its impact on employees. Whether furloughed, laid off, or set to take on broader responsibilities, change is happening. And naturally, these changes must be reflected in your ERP applications’ access policy management.

The uptick in user provisioning is placing additional pressure on SAP security and IAM teams, already burdened with securing remote access to applications for people working from home. These days, you have to wonder if IT professionals are feeling like they’re chasing something they can’t keep up with. And that leads to problems. 

Joiners, Movers, and Leavers 

The user provisioning process typically encompasses three phases: joiners, movers, and leavers. In short, they are three separate scenarios – when employees are onboarded, when they switch positions/departments internally, and when employees leave the organization. Given COVID, leaving the organization could mean either termination or furlough.

If overburdened IT and security teams cannot address provisioning promptly, organizations are leaving themselves open to an onslaught of risk in times where cyber-attacks are peaking and employees are already feeling stressed out.  

Thanks to an enlarged threat surface from remote access, a compromised account can cause considerable damage before it is detected. Excessive privileges only multiply this risk. Alternatively, strained and disgruntled employees with excessive privileges may be tempted by fraud, especially in cases where segregation of duties (SoD) should be in play. If an employee was given extra responsibilities that necessitated new roles, potential conflicts might be overlooked.  

Three Tips for Improving SAP Access Policy Management 

Setting the roles is only one step. You don’t want to give everybody the same kind of visibility or access to data, depending on their role. This is a great time to invest in data security technology and establish more granular access policies. Here are three tips for improving your SAP access policy management: 

1: Leverage Attribute-Based Access Controls (ABAC) to Simplify User Provisioning  

Organizations with similar roles spanning multiple business units turn to role derivatives to ensure access is segmented appropriately. While effective from a control perspective, managing these roles can prove burdensome as the number of role derivatives multiply with each branch-off.

For example, a manufacturing organization has 50 functional roles shared by users across 10 different plants. Using role derivatives, they would end up managing 500 different roles to ensure access is segregated appropriately. The sheer scale can be overwhelming to your SAP security team to begin with – and now we’re adding in all the joiners, movers, and leavers from COVID-induced workforce changes.

The purpose of roles is to be scalable! We want access policies that are one-to-many, not one-to-one. To gain back simplicity and lighten the load on your IAM teams, organizations can extend their existing role-based access control (RBAC) model with attribute-based access controls (ABAC). ABAC allows you to easily bring fine-grained “attributes” into your authorization decisions. In the example above, one could go from managing 500 role derivatives down to 50 roles and 1 supplemental ABAC policy that can consider the differing factor, a user’s assigned plant code, to automatically segregate their access appropriately. 

2: Reduce Your Attack Surface with Fine-Grained Entitlements 

The Principle of Least Privilege is a crucial tenet in information security. The goal is to minimize risk by providing users with the minimum level of access needed to perform a task at hand. This is the purpose of existing role-based access controls – e.g., an HR manager should not have access to finance transactions because it is out of their scope. However, this does nothing to protect data within their scope. Should the HR manager have access to social security numbers or compensation data at all times? After hours? Remote? The answer is likely, no.  

Organizations can reduce their amount of accepted risk by applying granular business policies and access controls to strengthen data-level and transaction-level security. Leveraging ABAC, you can enforce risk-aware controls to place limitations on what users can access within your application, from where, when, how they can access, and what they can do with data. ABAC provides an additional level of security by incorporating additional context like geolocation, time of day, and IP address. This ensures appropriate user access and prevents users from having more access than they need. Want sensitive data masked when access is outside your network? Done. Want to block high-risk transactions after hours? Easy.  

3: Manage the Identity Lifecycle with User Activity Monitoring 

Organizations should always engage in some kind of user activity monitoring, regardless of the number of joiners, movers, and leavers they’re dealing with. But this monitoring must extend beyond time-consuming and potentially expensive manual audits. You want to make sure the access control policies you’ve established are working and that you’re watching for anomalies. Some user activity to consider monitoring includes: 

• Identifying high-privilege user activity and critical transactions while closely monitoring and auditing on a regular basis 
• Continuously monitoring access across peer group activity for visibility into who changed what in regard to roles and permissions 
• Setting risk-aware alerts such as location of user, device accessing network, etc. This monitoring is vital for streamlining threat detection and alleviating the manual process typically required for threat response 

Assign Ownership and Responsibility Over User Provisioning 

While you’re monitoring user activity, don’t forget to put some eyes on your IT and security teams. You’ll want to assign ownership and responsibility to whoever responds to access requests and reviews temporary team member access. Keep good records as to why approvals are made or changed. You’ll want to approach this in a way that is easily audited. (Tip: email is not that process). 

Conclusion 

There are many moving parts and people that IT staff and security teams must manage. Leveraging tools that can improve an organization’s SAP access policy management will go a long way towards protecting important data and easing the burden on stressed IT and security teams.  

Schedule a demonstration today and learn how Appsian can mitigate SAP business risks with ABAC and User Activity Monitoring. 

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 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 access logs, filter out false-positives, and finally, send 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 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 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. 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 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.