At the SAPinsider 2020 virtual conference experience, one of our product demo attendees asked how Appsian works with SAP GRC Access Control. We get this question a lot as SAP security and system professionals explore adding attribute-based access controls (ABAC) to the native SAP role-based access controls (RBAC) to streamline and strengthen access policy management and enforcement. Sometimes there is confusion about whether ABAC is enhancing or replacing their RBAC. Let’s take a quick look at how Appsian’s ABAC works with and enhances SAP GRC Access Control.
What is SAP GRC Access Control
Organizations use SAP Governance, Risk, and Compliance (SAP GRC) to manage regulations and compliance and remove any risk in managing critical operations. One of the SAP GRC modules that helps organizations meet data security and authorization standards is SAP GRC Access Control. This module ensures that the right access is given to the right people with RBAC. It uses templates and workflow-driven access requests and approvals to streamline the process of managing and validating user access and provisioning. Without SAP GRC, for comparison, a person is creating all the roles from scratch and assigning privileges to them.
Appsian Enhances SAP GRC with Attribute-Based Access Controls
Appsian combines the SAP GRC role-based access controls with an attribute-based access control solution that delivers an ABAC + RBAC hybrid approach. This enhanced approach enables granular control and visibility that delivers a wide range of business benefits and lets you deploy data-centric security policies that leverage the context of access to reduce risk.
Appsian overcomes the limitations of traditional RBAC, allowing you to fully align SAP security policies with the objectives of your business and streamline audits and compliance.
As you can see in this illustration, ABAC begins the moment users start to access data and transactions. Where RBAC assigns access based specific roles, ABAC considers the context of access (who, what, where, when, and how) before allowing access to transactions or data. Customers can set up additional rules that allow conditional access, for example, masking specific data fields or limiting the number of transactions after a particular time of day) or entirely denying access based on factors such as an unknown IP address.
Real-Time Analytics for SAP Security & Risk Management
With Appsian360, our real-time analytics and reporting tool, Appsian can enhance the SAP GRC reporting capabilities with direct, real-time visibility into transaction usage, violations, and compliance risk. Additionally, customers can:
- Monitor transaction usage, master data changes, and SoD violations
- View actual SoD violations with user, data, and transaction correlation
- Segment reports by user/data attributes
- Drill down into end-user usage events
Appsian360 provides analytical reports to drill down into end-user usage events to capture business risks and anomalies, and usage events that tie back to compliance risks.
The ABAC + RBAC Hybrid Approach to SAP GRC Access Control
By combining data-centric security capabilities with attribute-based policies, Appsian extends and enhances the existing SAP GRC internal access controls and improves the reporting and auditing capabilities.
Contact us today and schedule a demo to see how Appsian can help you enforce access controls beyond the standard RBAC model of SAP.
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.
Thanks to TV commercials for identity protection services, you’re forgiven for thinking that that dark web is primarily a place where criminals and hackers buy and sell personal information such as credit cards, usernames and passwords, and social security numbers (and other PII). Lately, however, the dark web has seen a flurry of activity for offers to purchase corporate network access, according to a recent “Access for Sale” report from Positive Technologies.
Criminals Are Becoming More Interested in Corporate Network Access
Just a year ago, according to the report, cybercriminals were focused more on trading in access to the servers of private individuals for as little as $20. During the second half of 2019, Interest has since picked up in the sale of access to corporate networks. In Q1 2020, the number of postings advertising access to these networks increased by 69 percent from the previous quarter. Prices have also increased: the average cost of privileged access to a single local network is now in the $5,000 range. Additionally, hackers are offering a commission of up to 30 percent of the potential profit from a hack of a company’s infrastructure.
It’s bad enough that your threat surface has increased due to so many employees working from home, now you have a posse of hackers roaming the dark web looking for bounties to collect. We have a few suggestions to help you keep your ERP data safe even if hackers manage to gain access to your corporate network.
Adopt Attribute-Based Access Controls (ABAC) to Strengthen ERP Data Security
Companies using ERP systems are already leveraging role-based access controls. These controls, which align data access privileges and job function resources, provide a baseline for data governance. With the rapid expansion to a remote workforce earlier this year, organizations needed to create more detailed and more dynamic access controls—policies to determine who, what, where, when, and how workers can access ERP data and what transactions they’re allowed to perform.
With attribute-based access controls (ABAC), a company can incorporate additional context such as geolocation, time of day, and IP address to both ensure the appropriate user is accessing the resources and prevent users from having more access than they need. For example, if the organization knows that an employee should be working from Connecticut, ABAC can prevent access to resources, mask highly sensitive data, or prevent a transaction entirely if the user’s location is suddenly California – or a foreign country.
These granular, data-centric access privileges can help an organization ensure that users–internal or malicious–do not get too much access to important ERP data – limiting the potential negative effects of a network intrusion by hackers.
ABAC Should be Coupled with User Activity Monitoring
Let’s revisit how ABAC helps organizations establish roles and permissions to determine who, what, where, when, and how workers can access ERP data and what transactions they’re allowed to perform. It’s important that you don’t set these controls and “forget” them. You want to make sure what you’ve established is working and to watch for any anomalies that reveal unusual or unwelcome activity.
Most organizations are already performing some kind of monitoring of user access – but it has to extend beyond manual audits of instances of logging in and logging out of applications and what pages were displayed. Understanding data access, usage, and transactions performed is now a key requirement when maintaining visibility over business data and enforcing security policies.
Here are five details we recommend monitoring (more details here):
- Who – Details of the User Accessing the Data
- What – Details of the Data Being Accessed
- Where – Location Where the User is Accessing the Data
- When –Time of Day When User is Accessing Data
- How – Type of Device Accessing Data
Data is only as useful as the insights it provides. Using an analytics platform that includes granular access details, rapid aggregation, and visualization of user access data is a crucial requirement for data security.
You know that hackers are already looking for any and all security lapses on your perimeter to gain access to your corporate network. The “Access for Sale” report serves as an important reminder that hackers are willing to do anything to gain an advantage, and organizations must deploy a variety of ERP data security protocols in addition to the standard role-based access controls.
Appsian has helped hundreds of organizations that leverage legacy ERP applications like PeopleSoft and SAP ECC strengthen their data security posture with ABAC and user-activity monitoring.
Request a demonstration of the Appsian Security Platform today. Learn how Appsian can help you manage the risks of the dark web in little as 30 days!
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 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. 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.