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).
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 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.