As SAP ECC customers prepare for their migration to S/4HANA, they are assessing the pros and cons of this transition in terms of cost, compliance, and data security. A critical step in an S/4HANA migration involves a thorough SAP audit of the existing roles and authorizations and optimizing license spends for the current users. Organizations need to consider three key factors during a complete SAP audit for better role management before an SAP S/4HANA migration.

SAP Role Audits Can Optimize Your License Spend

Many organizations still view their SAP licensing as a black box. They are ready to spend millions of dollars on SAP without understanding which licenses are being consumed or which licenses are required for each user. A common mistake many organizations make without realizing it is misclassifying users due to the lack of visibility into the usage of each employee.

A comprehensive role audit in SAP can help classify all users, accounts, and roles and eliminate those not in use, including the following best practices for optimizing license spend before the SAP S/4HANA migration:

Combine Users Between SAP Systems 

Often, a single license is enough to access multiple SAP applications. Combining the same user across multiple applications frees up licenses that can be allocated to other users—preventing companies from paying double the amount.

Remove Inactive or Dormant Users

Certain users access the system only a few times a year, yet they are assigned Professional or Limited Professional License types. Since many corporations do not have visibility into the actual usage data for each role, account, or user, it is difficult to identify the inactive roles. By eliminating inactive and dormant users, organizations will be able to reallocate licenses to new users immediately, providing instant savings.

Classify All Users and Roles

Most SAP users utilize only a fraction of their allocated authorizations. Focusing on the actual usage of data based on the users’ roles ensures that companies will never be under or over licensed. In addition, by classifying all users, organizations can avoid the additional costs of Professional Licenses (used only by unclassified users).

SAP Role Audits Ensure Data Security Via Dynamic Access Controls

S/4HANA migration often opens up the “crown jewels” data to the security risks of the mobile world because the network firewall no longer protects it. You need to know what type of data is being exposed to your external users. That determines how you define the roles and how data is taken from the application and delivered to the users.

This requires applying protection to the user interface layer in terms of defining how you want the data to be viewed by different personas. Organizations conducting SAP audits need to enable dynamic access controls to gain visibility into:

• Where is a user coming from?
• What data are they trying to access?
• What device are they using?
• Is that device being used by the right person?
• What data are they trying to extract onto their device?

Periodic reviews and audits of the roles ensure that only the correct user having the proper roles can view the sensitive data that is otherwise encrypted or masked. For example, not every HR employee should have the role or access rights to view employees’ payroll data.

SAP Role Audits Are an Opportunity to Verify SoD Compliance

Organizations migrating to S/4HANA need to leverage SAP access controls or security monitoring solutions to perform periodic role and user analysis. The data collected during this audit can also help verify SoD compliance. Segregation of Duties conflicts, especially in financial and procurement transactions, are a significant reason for audit failures. Role audits could be used as an opportunity to collaborate with your organization’s compliance team to ensure that you’re securing your data and adhering to mandatory compliance requirements across your SAP ecosystem.

How Appsian’s ProfileTailor GRC Helps with SAP Role Audits

Migrating to S/4HANA remains a long and complicated process for organizations. The first big step is an exhaustive audit of the new and existing roles to facilitate effective role management in the SAP system. Role management offers access simulation capabilities, enabling administrators and role owners to perform a “what if” analysis at various stages of a role’s life cycle management and support compliant user provisioning. In addition, the system provides mechanisms for role design to reduce SoD conflicts and improve administration efficiency in SAP and other ERP and business applications. This usually includes a mechanism for transporting new or updated role definitions into appropriate application environments.

Appsian Security helps businesses with its ProfileTailor GRC Solution, ensuring cross-platform ERP data security, compliance, and SAP license optimization. It delivers unprecedented visibility of real-time authorization usage, helping companies optimize their spending before migrating to S/4HANA.

Want a secure and seamless transition to S/4HANA without spending a hefty sum on your licenses? Then, download our whitepaper, Critical Steps You Should Take Before Making the Move To S/4HANA, and reach out to schedule a demo with our SAP security experts.

There is no denying that SAP applications make it easy for large organizations in almost every industry to streamline their business processes. However, that ease doesn’t include SAP software license management, which by all accounts, is considered one of the most complex compared to other ERP vendors. This complexity results in companies buying more licenses than they need or inefficient management of their existing SAP license types, which significantly impacts the overall costs. Here’s why you end up spending more than you should on your SAP licenses (and a tool that can help you save some money).

Vague SAP License Descriptions

SAP license descriptions are not airtight, and it is mainly left to you, the customer, to decide the type and number of licenses you need. SAP licenses can be broadly categorized into three types.

• Professional License: A named user with a Professional License can perform operational tasks and has administrative privileges that allow them to make changes to the system – usually assigned to employees who are heavy users. 
• Limited Professional License: This license is ideal for employees who need to perform operational roles supported by the SAP software. It is a step down from the Professional License and is also cheaper.
• Employee License: With this license, users can perform tasks solely for their own use and not on behalf of anyone else. This license costs the least. 

An SAP license is always associated with a user who is called a named user. The ‘name’ in this context is not an actual user name but a unique ID linked to a license. There can only be one license associated with a named user at any given time. However, a named user can have multiple user names to access different SAP systems. 

This makes it increasingly complicated to assign the appropriate license type. For example, a single user could be using an ERP system for updating inventory, a second ERP system for monthly invoice approvals, and a third one for downloading reports. Which license would be applicable in such a case? Now imagine figuring out license types for thousands of employees accessing multiple systems. 

Improper User Classification 

User classification is a crucial exercise for SAP software license management that directly impacts your license cost and the recurring annual support fee. Most SAP customers classify their users with one of three parameters:  

• Amount of Activity: The amount of activity performed by the user can be one way to classify the user. SAP measures activity by ‘Dialogue Steps,’ which is the number of screens and keystrokes used. 
• Number of Different Activities: Users can also be classified based on the number of activities or the different applications they access on a regular basis.  
• Type of Activity or Activity Group: The type of activity can be used as a yardstick for license purchases. Under this classification, users are grouped together based on the type of usage. This requires customers to assess the type of activities a user needs to perform and create groups. 

Though this classification process appears straightforward, several gray areas occur when put into practice. For example, when classifying users by their amount of activity, a user could be using the corporate phone directory in the SAP system 1,000 times, but that does not mean he needs a Professional License. Or let’s say an employee is accessing multiple systems but only to generate reports. Under the second classification, this user would be eligible for a Limited Professional license, whereas an Employee License would most likely suffice since the user is only viewing and downloading data. 

Classifying users as mentioned above makes logical sense, but large organizations need to invest a significant amount of time and resources for using these methods. Also, employee roles keep shifting, and usage may vary significantly over a given period. This makes classification difficult and impossible to maintain manually without errors. 

That’s why SAP customers rely on automated tools like Appsian Security ProfileTailor LicenseAuditor to identify users based on their activities and distribute SAP licenses types accordingly. SAP software license management and auditing tools also help achieve compliance and manage SAP usage.  

Knowledge Equals Savings

SAP licenses are a huge investment for any organization. Gaining a better understanding of your overall license status, usage, and spend not only helps you manage your current licenses but also allows you to negotiate a better deal. With SAP announcing the end of support for classic SAP applications like SAP ERP, SCM, SRM, CRM, and Business Suite by 2027, all customers will eventually have to migrate to SAP S/4HANA. By auditing your current SAP usage and forecasting future license requirements, you can ensure significant savings for your company as you go through with the migration.

Appsian Security ProfileTailor LicenceAuditor provides control over your SAP licensing by combining user inspection, user behavior-analysis methods, and best practices. The solution enables you to effectively utilize your licenses by offering a clear view of licensing possibilities for optimized models and savings of 50%-90% per classified license. 

To learn more about SAP software license management, read our complete guide 5 Simple Ways to Reduce Your SAP License Spending.  

Or contact us today for a ProfileTailor LicenceAuditor demonstration. 

Here are two use cases that might sound familiar… 

While organizations spend millions combatting external threats, for example, hacking, phishing, and ransomware, we at Appsian Security have found most data security use cases are focused on data governance across the enterprise. Simply put, what can someone access depending on where they’re located, what business unit they belong to, or even what time of day it is? Ensuring SAP data security policies are followed without over-restricting access or hurting productivity is a serious juggling act. Sadly, most organizations get it wrong. Fortunately, the solution can come down to a concept as simple as data masking – what, when, and how?  

I had the opportunity to learn about two specific use cases (from Appsian customers) and how they used dynamic data masking to protect sensitive data—all without adding bottlenecks or complexity to their organization.  

Transportation Company Use Case    

While many industries struggled through the COVID-19 pandemic, a transportation and rail company based in Canada thrived. This was due to being a critical delivery component for many supply chains. The company had to transform its office-based workers into a flex-work model (hybrid workforce) and hire additional employees for fieldwork. The hybrid workers needed to continue their day-to-day managerial tasks, which contained sensitive information that the company was not comfortable exposing outside its secure corporate office. Securing access to this data was further complicated by remote workers traveling from city to city and logging into the self-service SAP modules on mobile devices from wherever they had a Wi-Fi connection.  

The company turned to Appsian to enable a dynamic data masking solution by leveraging contextual access controls that determined which sensitive data fields and Tcodes employees could access based on attributes such as location, IP address, time, data sensitivity, and more.

International Consumer Packaged Goods Use Case    

Where one company was dealing with multiple employee/user locations, an international consumer packaged goods company was dealing with multiple office locations around the world, each with its own installation of SAP. The company needed the means to protect sensitive personal data (stored in 1 of 5 unique SAP systems) while abiding by each location’s unique PII protection requirement (GDPR, PIPA, LGPD, etc.).   

For this unique situation, the company needed a centralized data masking solution that could follow each location’s unique governance policies. All while being flexible enough to manage scenarios involving multiple locations and protecting sensitive data in production and non-production environments.   

For example, a US-based employee could access the SAP system in the South American office. Yet, the dynamic policy could mask certain pieces of information or Tcodes because of the user’s nationality. The user’s location is from a legitimate IP address, but their nationality forbids them from accessing certain personal or sensitive information due to international regulations or company policies—even if that user can access that information in their own instance of SAP.    

Protecting SAP Data with a Dynamic Data Masking Solution   

The key to a successful dynamic data masking solution is the use of contextual access control policies (ABAC). ABAC allows companies to work in conjunction with existing roles-based controls (RBAC). Without it, neither one of these companies could successfully enable data masking without extensive customization, resulting in an unscalable ad-hoc solution.    

Appsian Security Platform’s (ASP) dynamic data masking capabilities provide fine-grained control over which sensitive data fields can be masked for any specified user in the context of any situation. For example, ASP allowed both companies to:   

• Centralize data masking enforcement throughout ECC and S/4HANA with a single ruleset.   
• Deploy dynamic policies that account for risk based on the context of access, such as location, IP address, time, data sensitivity, and more.   
• Protect sensitive data in production and non-production environments.   
• Align SAP data masking controls with existing governance (corporate) policies.     
• Mask sensitive PII based on the data subjects’ residency (country/nationality).    
• Mask data fields in transactions (Tcodes) that are unnecessary for a role.   

Contact the SAP experts at Appsian and see for yourself how ASP can improve SAP data security and reduce compliance risk with a fully dynamic data masking solution.   

The ERP security landscape is drastically evolving and traditionally on-premise applications such as SAP ECC and S/4HANA are falling behind. Dynamic risks posed by remote access, changing compliance requirements, and the rising number of user-centric threats have highlighted a gap in controls. The ways users access SAP has changed, and because of this, it’s time to reevaluate your security model and how the concept of Least Privilege is being enforced.

The Traditional Approach to Least Privilege in SAP is Insufficient

The Principle of Least Privilege aims to minimize risk by limiting the number of privileges given to a user based on what privileges are job-related or necessary to complete a task—reducing the opportunities for improper uses of privilege to occur.

In SAP, this has traditionally guided role design from a functional perspective. For example, an HR Manager role may have privileges such as maintaining HR master data, processing payroll, or modifying pay rates – but should not have access to transactions outside their line of work (ex. creating, maintaining PO’s).

The approach was sufficient when user access was limited to a physical office, during normal business hours, and on a secure network. However, we all know this has changed. Remote work and cloud-hosted applications have expanded the scope of access, and with it, shifted the risk landscape. Context such as the what, when, where, and how a user interacts with SAP must be considered in addition to functional access rights.

Unfortunately, this leads us to the Achilles heel in SAP security: static, role-based access controls (RBAC). Risk is dynamic. RBAC is not. Without the ability to consider contextual factors beyond a user’s role and privileges, organizations are actually constraining their ability to enforce PoLP.

This gap leads to a variety of risks, including data exfiltration, fraud & theft, policy violations, and compliance risks. It’s time for companies to take their SAP security to the next level. It’s time for Least Privilege 2.0.

Appsian’s Approach to Least Privilege 2.0

As noted earlier, a key to minimizing SAP risk exposure is context. To integrate context into controls, SAP customers can leverage attribute-based access controls (ABAC) and business rules that extend SAP’s existing authorization model.

With the Appsian Security Platform, organizations can enable security policies that align controls with real-world scenarios by considering the context. Dynamic authorizations at both the data and transaction level can be implemented to fine-tune your security measures and align exposure to your organization’s risk appetite.

Least Privilege 2.0 means going beyond static roles and privileges, allowing companies to achieve:

• Dynamic access controls to understand if a transaction should be performed remotely and incorporating attributes such as user, resource, action, and environment characteristics to limit access to and within SAP data.
• Risk-aware process controls to ensure that established business policies are enforced and prevent violations from happening in the first place
• Fine-grained data protection to determine if a user really needs access to a particular set of sensitive data and capture granular insights to uncover user activities and transaction details.

This supplemental attribute-based authorization layer enables rapid, wide-reaching changes without the need to redesign individual roles. For example, organizations can now dynamically protect data with:

Policy-Based Data Masking
Limit the exposure of PII and other high-risk information with dynamically enforced data masking throughout SAP. Policy dictates at runtime whether a user has full access to data within a transaction, limited access via full/partial mask on sensitive fields, or is blocked entirely.

Data Exfiltration Controls
Stop data leakage from both privileged accounts and normal end-users by ensuring data can only leave SAP in secure environments. Access to transactions that export data to downloadable files can be blocked in high-risk scenarios.

Let Appsian Show You How to Address Risk in SAP with Least Privilege 2.0

As business processes in SAP evolve and grow more complex, your organization’s capability to mitigate access risks must also evolve. Appsian can help you leverage Least Privilege 2.0 to extend your SAP security controls to address gaps in coverage and minimize your accepted risk. Get in touch with the experts at Appsian today to schedule a demo and learn how we can help.

2020 brought about a reckoning for organizations that were slow to adopt strong data privacy and data loss prevention strategies. As users went remote, the networks and devices used to access SAP financial data became a liability – and organizations were sent scrambling for solutions to their newfound dynamic access demands.

Why is data masking used?

Data masking is security measure used to shuffle, obscure, or encrypt data so that it cannot be accessed or deciphered without the requisite authorization. Masking of sensitive data like SSN, bank account information, healthcare records, and financial information in ERP systems like SAP allows enterprises to reduce unnecessary exposure of data while enhancing data security and reducing their overall risk. Data masking also helps private and public companies align with compliance regulations like GDPR, PCI DSS, Sarbanes Oxley, etc., which mandate the protection of all personal data from unauthorized access and theft.

Out-of-the-Box SAP Data Protection is Not Enough

In order to prevent data exfiltration and general over-exposure of enterprise data, the use of SAP data masking has grown in popularity. Unfortunately, customers have no out-of-the-box solutions for SAP data masking. In fact, the entire SAP security model hinges on static, role-based controls that offer little to actually protect the data inside the transactions that the access controls are designed to govern. In many cases, a user who has access to a transaction has access to a wide range of data within that transaction that simply isn’t necessary – providing opportunities for misuse.

To make matters more complicated, if an organization were to undergo a large-scale SAP data masking project, the sheer amount of custom development would prove to be a significant hurdle and nearly impossible to scale effectively.

Appsian Offers a Centralized, Scalable Alternative

To offer SAP ERP customers a scalable data masking solution, the Appsian Security Platform (ASP) features dynamic data masking capabilities that enable fine-grained control over which sensitive data fields customers can mask for any specified user and in the context of any situation. By implementing a full or partial mask to a data record, ASP minimizes the risk of a data breach and fulfills encryption and anonymization mandates imposed or implied by regulatory bodies. 

Unlike most off-the-shelf masking solutions, Appsian uses a single ruleset to define and mask data across the entire application:

• Centralize SAP data masking enforcement with a single ruleset
• Deploy dynamic policies that account for risk contexts such as location, IP address, time, data sensitivity, and more 
• Protect sensitive data in production and non-production environments
• Implement masking without requiring additional customizations to SAP
• Filter out sensitive data at the presentation layer, resulting in no additional maintenance requirements for updates

Why Appsian is the Essential Dynamic SAP Data Masking Solution

Simply put, when you are trying to protect data without overly-restricting access, then there is no alternative to leveraging a dynamic SAP data masking solution. Because the context of access plays such a critical role in defining risk, being able to apply full or partial masks based on context is the only real way to balance data protection and productivity. 

In addition, Appsian uses a “one to many” approach for creating policy-based data masking rules. This enables customers to quickly scale SAP data masking without extensive development effort at implementation or reconfiguration efforts for policy updates. 

Example Use Cases for Dynamic SAP Data Masking

1. Mask PII of Customers in SAP CRM Based on their residency
   GDPR Compliance – Ex: Mask PII Data if Customers’ Address is in the EU
2. Mask & Lock Bank Account Fields After Hours
   Fraud & Theft – Ex: Insider Changing Data at Night Before Pay-Run 
3. Obscure Data Fields in Transactions that are Unnecessary for a Role 
   Data Minimization – Ex: Customer Support Seeing Financial Spend, Pricing Info
4. Prevent Remote Access of Unpublished Financial Information
   Risk Mitigation – Ex: Mask Data when Access Occurs After Hours or Remote

Get a Demo of Appsian’s Dynamic SAP Data Masking and See for Yourself!

As business processes become more complicated, your ability to protect data must evolve as well. Fortunately, Appsian offers the fastest, most cost-effective approach for SAP data masking. Contact us today and get a demo! And find out how you can be applying dynamic data masking rules within only 4-6 weeks!

As your company’s digital footprint grows, you can enhance your security posture by complementing your existing SAP Role-Based Access Controls (RBAC) with dynamic, Attribute-Based Access Controls (ABAC) to strengthen authentication and authorization. Both RBAC and ABAC are ways that organizations can control authentication and authorization, but they perform different functions across an enterprise IT stack. 

Understanding SAP Access Control Using Roles

Functionally, a role is a collection of permissions using sets, relations, and mapping that align access needs to resources based and limit access on a “need to know” basis.

RBAC involves three basic principles:

1. Role assignment: Only users with the right login can gain access to and interact with a system or application.
2. Role authorization: When combined with role assignment, administrators authorize a set of credentials that can gain access to and interact with a system.
3. Transaction authorization: A user can only interact with a resource to which she is authorized through her role memberships while also limited on a “need to know basis.”

RBAC has since evolved to include “hierarchies.” Hierarchies assign different roles different levels of access. For example, a Chief Executive Officer (CEO) needs to have a lot of access to sensitive information. Therefore, the CEO role has access that also encompasses the type of access provided to the Vice President’s, line of business managers, and standard employees. However, since a standard employee is at the “bottom” of the hierarchy, RBAC prevents her from accessing the sensitive information that the CEO can access.

Enhancing RBAC by Using Dynamic Authorizations in SAP

RBAC provides a strong foundation for setting access controls. However, digital transformation changes the way people interact with data resources. Since RBAC was intended for on-premises data repositories, it creates a very strict, static set of permissions. You either have access or you don’t. 

Dynamic authorization – also known as attribute-based access controls (ABAC) – enhances RBAC by taking into account different “attributes.” Attributes are the adjectives of the access control world because they incorporate an additional description of either the user or resource.

Examples of user attributes:

1. Department within the organization
2. Management level
3. Citizenship / Residency
4. Security Clearance

Examples of action attributes: 

1. Read
2. Write
3. Transfer (money)

Examples of resource attributes:

1. Data Classification
2. Transaction Code
3. Document Number
4. Plant Code

Example of environment attributes:

1. Time
2. Geographic location
3. Device type
4. Connection type

By incorporating these attributes, organizations can control user access more precisely, and with the flexibility of dynamic authorizations, better balance business and security requirements.

Achieving Dynamic Access by Using Attributes

Roles act as the foundation for providing access. If you think about it like a sentence, RBAC is the subject and verb. An IT admin has what we call “superuser” access. A simple RBAC sentence might look like this:

IT administrators can read and edit all information. 

Based on RBAC, this sentence provides so much access that an IT administrator could be a data breach risk. Whether maliciously stealing sensitive information or accidentally sharing private information, the unrestricted access means organizations struggle to restrict IT administrator access while still providing enough access for the employee to do their job. 

However, if we add attributes, or additional descriptors about how/when/where IT administrators can use their access, we limit the risk. By creating an “if-then” statement, we apply restrictions based on the defined characteristics. 

If IT administrators are accessing the database (resource attribute)
from their homes (environment attribute) then
they can read (action attribute) the information. 

By adding these attributes, we can prevent IT administrators from making changes to databases while they are at home. 

Furthermore, we can use attributes to grant access as well. Taking the same statement, let’s incorporate time of day as an additional attribute. 

If IT administrators are accessing the database (resource attribute)
from their homes (environment attribute) then
they can read (action attribute) the information,
but if they access the database
between 8 AM and 10 AM (environment attribute 2),
they can edit user data (action attribute 2). 

By adding the additional environment and action attributes, you’re creating a scenario that allows IT administrators to work from home while also reducing the risk. You have created a time-bound restriction that requires them to only make user data changes during the hours of 8 AM and 10 AM if they are at home while at all other times, they can only read the database information. 

The more attributes you can incorporate, the more precisely you can define what, how, and when a user or group of users can access data. 

Creating a Robust Data Security Strategy Using a Hybrid SAP Access Control Model

As organizations accelerate their digital transformation initiatives and allow more remote access to data and transactions, they need a way to configure a layered defense using a hybrid approach to SAP access control. Starting with RBAC, organizations set the foundation of their access policies. However, by incorporating different attributes such as user, resource, action, and environment characteristics, you can more appropriately limit access to and within your SAP data.

Without a solution like Appsian, the closest and organization can come to granting dynamic access to SAP is through customization or adding roles to a user for each attribute. Both options are costly and ultimately unmanageable in the long run.

Contact us to learn how Appsian can help you extend and enhance your existing SAP access controls and improve your reporting and auditing capabilities.

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: 

1. Monitor transaction usage, master data changes, and SoD violations 
2. View actual SoD violations with user, data, and transaction correlation 
3. Segment reports by user/data attributes 
4. 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. 

A critical SAP vulnerability (CVE-2020-6287 or RECON) was recently discovered by Onapsis that gives attackers TOTAL control of vulnerable business applications. It allows hackers to gain unauthenticated access to SAP and then create new user accounts with admin (superuser) privileges. With these privileges, a malicious attacker can do limitless amounts of damage, including stealing data, changing bank account numbers, fully sabotaging systems, and more. 

RECON Shares Similarities to a Familiar Foe – 10KBLAZE 

The RECON vulnerability puts the confidentiality, integrity, and availability of SAP ERP data and processes at risk, which is very similar to the 10KBLAZE exploit from 2019. What do these two exploits have in common? Simple, they are leveraging a lack of visibility and control to be successful. There is a reason that these exploits focus on the creation of admin accounts – because once you’re an admin (legitimate or not), you have the keys to the castle. 

The Cybersecurity and Infrastructure Security Agency (CISA) encourages users and administrators of SAP products to:  

1. Analyze systems for malicious or excessive user authorizations. 
2. Monitor systems for indicators of compromised accounts resulting from the exploitation of vulnerabilities. 
3. Monitor systems for suspicious user behavior, including both privileged and non-privileged users. 
4. Apply threat intelligence on new vulnerabilities to improve the security posture against advanced targeted attacks. 
5. Define comprehensive security baselines for systems and continuously monitor for compliance violations and remediate detected deviations. 

The key recommendations align to the need for monitoring – monitoring systems, monitoring transactions, monitoring the creation of accounts, and (most importantly) monitoring data access and usage. This is where many SAP ERP customers will struggle as attaining fine-grained controls and visibility are complex, even prohibitive at times, with native functionality. This is precisely where Appsian can help. 

A Second Layer of Defense: Fine-Grained Control and Visibility 

RECON and 10KBLAZE highlight that a single, static layer of security within SAP is inadequate to combat modern-day threats. Appsian enables SAP ERP customers to layer their defenses using a comprehensive suite of fine-grained, risk-aware access controls, and continuous monitoring of data access and usage. 

Here are Appsian’s recommendations to minimize your attack surface and the risks posed by RECON – and future vulnerabilities like it (in addition to recommended security patches.) 

Attribute-Based Access Controls (ABAC) Are Essential in a Dynamic Environment  

RECON and 10KBLAZE take advantage of vulnerabilities in the open, internet-facing components of SAP (think remote access). The Appsian Security Platform (ASP) uses attribute-based access controls (ABAC) to implement data-centric, “risk-aware” controls. ABAC prevents specific transactions like user provisioning when access originates from untrusted IP addresses (or IP addresses outside your whitelist), certain geographic locations, outside work hours, mobile devices, and many other contextual attributes. Bottom line – Appsian can stop the creation of a user account (or changes in privileges) if access is coming from outside the corporate network. Fine-grained policies can be implemented to block high-risk activity, such as those matching the RECON attack patterns. 

Visibility into Data Access and Usage is Essential for Combatting Configuration Gaps 

Both RECON and 10KBLAZE center around the unauthorized creation of high privileged user accounts. Appsian360, the latest real-time analytics solution by Appsian, captures and visualizes data access and usage, which is essential for monitoring user provisioning activity like user creation/deletion and role/profile changes. Appsian360 can detect and alert organizations at the point of initial account creation, minimizing the damage by reducing how long a threat goes undetected.     

Appsian360 can also detect suspicious transaction activity if the compromised and illegitimate accounts are not addressed at the point of creation. Furthermore, this creates an audit trail that acts independently from existing SAP logs and can expedite breach forensics activities. 

Prepare Yourself for the Next Critical SAP Vulnerability – Layer Your Defenses (While and After you Patch Your Applications) 

RECON isn’t the first critical vulnerability to affect SAP, nor will it be the last. While there are security patches available to keep their ERP systems safe, these can take time (and resources) to implement, which results in significant downtime of production systems. Furthermore, the time to apply the patches depends on the complexity and the components involved. By all means, stay up to date on system updates, but bugs like RECON and 10KBLAZE serve as a reminder that patches aren’t enough to protect critical SAP data. 

Talk to the SAP Security Experts at Appsian today to discuss how your organization can address the risks posed by RECON and other vulnerabilities.

A critical SAP vulnerability (CVE-2020-6287 or RECON) was recently discovered by Onapsis that gives attackers TOTAL control of vulnerable business applications. The RECON vulnerability allows hackers to penetrate SAP systems and create new users with administrative privileges, allowing them to manage (read/modify/delete) every record/file/report in the system. 

The RECON bug is one of those rare vulnerabilities that received a maximum of 10 out of 10 rating on the CVSSv3 vulnerability severity scale, so it is crucial that organizations move quickly to apply patches. 

Remote and unauthenticated attackers can exploit the vulnerability to create a new SAP admin user, bypassing access and authorization controls and gaining full control of the SAP system. Exploitation will impact the confidentiality, integrity, and availability of SAP applications. With an admin-level user account at their disposal, an attacker can: 

1. Steal personal identifiable information (PII) from employees, customers, and suppliers 
2. Read, modify or delete financial records 
3. Change banking details (account number, IBAN number, etc.) 
4. Administer purchasing processes 
5. Disrupt the operation of the system by corrupting data or shutting it down completely 
6. Perform unrestricted actions through operating system command execution 
7. Delete or modify traces, logs and other files 

The RECON Attack Path 

The RECON vulnerability is easy to exploit and resides in the LM Configuration Wizard component of the SAP NetWeaver Application Server (AS) JAVA. The LM Configuration Wizard of SAP NetWeaver AS JAVA does not perform an authentication check, allowing an attacker without prior authentication to execute configuration tasks to perform critical actions against the SAP Java system, including the ability to create an administrative user. This compromises the Confidentiality, Integrity, and Availability of the system. 

The vulnerability not only compromises the security of the NetWeaver Java applications but can also be used to exfiltrate credentials to an ABAP system through the ABAP secure storage and potentially lead to the exposure of ERP data-sensitive PII and financial information. 

SAP Guidance: Apply the Patch or Enable a Workaround 

The critical nature of this vulnerability caused the Cybersecurity and Infrastructure Security Agency (CISA) to strongly recommend organizations immediately apply patches, as noted in SAP Security Note #2934135. 

If you cannot apply the patch, then at least disable the tc~lm~ctc~cul~startup_app application, as described in SAP Security Note 2939665. Note 2939665 is a workaround and a defense-in-depth, but not a solution. 

Further Risk Mitigation Measures 

Being up to date on the patches will help mitigate the vulnerability. Still, because of the number of security patches released in recent years, several customers are behind on these as the application of these patches requires downtime of the production systems. Moreover, the time to apply the patches depends on the complexity and the components involved. It can require a significant amount of time and effort, especially if the systems are a couple of patches behind.   

All this ends up increasing the risk and the timeframe for which the systems are exposed. Having application security in the form of multi-factor authentication or additional policy-based controls and logging will help mitigate the risks and control sensitive data exposure in mission-critical systems. 

Talk to the SAP Security Experts at Appsian today to discuss how your organization can address the risks posed by RECON and other vulnerabilities.