14 controls for securing SAP systems in the cloud

On-premises SAP deployments are notoriously complex with extensive customer customizations to the point where even making configuration changes for security reasons might require months-long planning and testing to make sure they break nothing in the environment. As more companies move their ERP deployments to the cloud, they have an opportunity to ensure the systems are configured securely.

The Cloud Security Alliance (CSA), a not-for-profit organization that develops and promotes best security practices for cloud computing, released a two-part implementation document this year for ERP applications in the cloud that follows 20 critical security controls. The second part was released this month with a focus and guidance on SAP deployments since it’s one of the most common ERP systems.

“The release of the document comes at a crucial time, as with the hit of the pandemic, organizations have started to streamline digital transformation and cloud migration projects, to enable more users and employees to operate from remote locations through a digital experience,” CSA said in a blog post. “Additionally, with the increase in threat activity and risks affecting ERP Applications … this document covers the controls that could prepare the organization for the increasing threat landscape on ERP applications. It’s our hope that this set of guidelines serves as a springboard for SAP administrators in their journey to implementing and securing their ERP solutions.”

SAP vulnerabilities and challenges

Security researchers have been finding serious vulnerabilities in core SAP components for years and such flaws typically impact all the SAP enterprise applications that rely on those components to function. While finding vulnerabilities in such a large software stack is not unusual, patching the issues in a timely manner has been a problem for customers.

Last year, the United States Cybersecurity and Infrastructure Security Agency (CISA) issued an alert after several easy-to-use exploits dubbed 10KBLAZE were released on GitHub. The exploits targeted insecure configurations in SAP components, some of which had been known for over a decade but continued to persist in deployments because fixing them could cause incompatibilities with customizations.

At the time, ERP security firm Onapsis, which performs security assessments for large organizations, estimated that the 10KBLAZE issues affected nine out of every ten SAP systems deployed by more than 50,000 SAP users worldwide — around 900 million systems in total. The company also warned that it often finds these configuration issues even in cloud SAP implementations, which do not have the complexity burden of on-premises deployments. This suggests organizations are not following best practices even when deploying new systems, which is something the CSA hopes to change with its 20 critical security controls and implementation guidance.

Another critical vulnerability in the SAP NetWeaver Application Server Java, which powers most SAP enterprise applications, came to light in July. Dubbed RECON (Remotely Exploitable Code on NetWeaver), the flaw had a severity score of 10 (maximum) and could be exploited by attackers over HTTP without authentication to fully compromise systems. Researchers estimated that 40,000 SAP customers worldwide might be affected, with over 2,500 vulnerable SAP systems being directly exposed to the internet.

CSA’s security controls 

The CSA’s critical security controls focus on SAP NetWeaver and ABAP-based applications and are broken down into several implementation categories: applications, integrations, data, users and business processes. For each control, the CSA provides a description of the control, the threats the control is meant to mitigate and a checklist of steps to implement that control. Some checklist steps contain more technical information than others, depending on the type of control they address. For example, business compliance steps are described more generally while baseline secure configuration steps include SAP-specific technical actions. The full list of controls is:

APP01 – Secure Landscape

Secure Landscape refers to separating lower-risk systems such as development or test from production systems by putting them in different landscapes with different access controls so that if an attacker gains access to a development system they can’t pivot to a production system.

APP02 – Baseline Secure Configurations

The Baseline Secure Configurations control includes steps to harden the configuration of critical components such as the SAP Application Server, the SAP HTTP Interface, the SAP Gateway, the SAP Message Server and the SAP Management Console. These are the core of any SAP environment and insecure configurations could allow attackers to bypass other user- or role-based controls.

APP03 – Security Vulnerabilities

The Security Vulnerabilities control covers details about how SAP issues security patches and recommendations on reviewing and applying them.

INT01 – Secure Integrations and API

The Secure Integrations and API control addresses security issues stemming from extensive integration of ERP applications with outside applications and data sources and include recommendations like mutual authentication between applications using client certificates, using separate DMZ network segments, passing requests through a web application firewall or proxy and protecting data in transit using strong cryptographic ciphers and protocols.

DAT01 – Continuous Monitoring

Continuous Monitoring involves enabling the logging capabilities of SAP applications and sending them to a centralized server for later review using a SIEM tool, as well as putting an incident response process in place for when incidents are discovered. Some of the common logs in SAP applications are the Security Audit Log (through transaction SM19), the SAP Gateway Log (through transaction SMGW), the SAP Table Change logging (by enabling parameter rec/client and transaction SE13), the HTTP access log (SMICM), the Message server log, Change documents and the Read Access Log.

DAT02 – Data Separation

The Data Separation control covers the separation of data among the different ERP landscapes (development, testing, production, etc.) as well as between tenants in cloud environments so that no user has access to both production and non-production tenants.

DAT03 – Data Encryption

The Data Encryption control covers recommendations to secure data-at-rest on servers by enabling full disk encryption at the OS-level; encrypting data in the SAP HANA database; defining data governance policies; having processes in place to maintain, issue, revoke and control access to data encryption keys and certificates; securing data-in-transit by enabling SNC protocol for SAP GUI applications and enabling secure communication in SAP Web Dispatcher using strong protocols and crypto ciphers.

BUS01 – Inventory of Business Assets, Data and Processes; BUS02 – Business Process Controls; and BUS03 – Continuous Compliance

The controls in the Business Processes (BU) categories include implementing an inventory of applications, data and processes to have a clear understanding and single source of truth about which data resides in each application and which are the critical assets or the organization’s “crown jewels.”

Another important aspect is to put controls in place to ensure that existing privileges, especially elevated ones, cannot be used to perform fraudulent activities when critical business processes are performed in SAP applications. Finally, organizations should identify regulatory standards that impact the data processed by SAP applications and should develop the necessary controls to ensure compliance with those standards. This includes developing automated testing procedures for those controls and implementing alerting mechanisms.

USR01 – Secure Authentication

This control covers the use of single sign-on protocols, the enforcement of strong password policies and the use of additional factors during authentication. The communication protocol used for authentication should also be encrypted and secure against man-in-the-middle and replay attacks.

USR02 – User Accounts Management, USR03 – Role-based Access Control, and USR04 – Emergency Access

User account management in SAP environments can be quite complex as SAP applications include default users such as SAP*, DDIC, TMSADM, or EARLYWATCH that should never be configured with default passwords, as well as technical users that should not be configured with generic roles or profiles such as SAP_ALL. The users created in SAP clients should also be reviewed to make sure they have a valid business purpose, that they were created according to security recommendations and have a real employee associated with them.

SAP applications work with user roles that can be combined to define the permissions assigned to users. New users should only be assigned roles that they need to perform their day-to-day job duties and should be monitored and audited. A process needs to be established so that when employees change positions inside the organization or they leave the organization, their authorizations and roles are updated. Emergency access policies should also be clearly defined — who can do what, when, where and how — with responsibilities assigned for how such access is granted, monitored and terminated. Emergency access and higher privileges might be needed during a lack of sufficient personnel to achieve certain tasks or during system failures and errors.

USR05 – Segregation of Duties

Segregation of duties (SOD) is a different concept than role-based access controls. It aims to ensure that no process is controlled by a single individual from beginning to end or that incompatible tasks such as transaction approvals, accounting and reconciliation should not be performed by a single person. To implement this principle in an SAP environment, organizations can use role-based or task-based methods when building user profiles based on their organizational hierarchy and should have processes in place to assess the risks of any potential SOD conflicts and resolve them by making modifications to roles or by additional controls such as reviews and approvals.

USR06 – Secure User Provisioning/Deprovisioning

User provisioning and deprovisioning should be done uniformly across all SAP systems and landscapes by using an identity management system. Every user creation, either technical or functional, must have a valid business reason and organizations must ensure there are no dormant or unmanaged accounts left in systems that could be misused by potential attackers.

USR07 – ERP Accounts Security

The security of ERP accounts should be strengthened through the use of multi-factor authentication, mandating long passwords, analyzing user behavior to detect unusual login locations and times, implementing single sign-on, limiting user access from certain networks and ensuring session tokens are encrypted, random and expire on time. User activities and transactions should also be logged at all times.

APP04 – Secure Communications, APP05 – Change Management Controls, and APP06 – Secure Extensions

This set of cloud ERP application controls are designed to protect communication with the SAP system, prevent unmanaged changes, and avoid insecure customization through the use of extensions.

“Every ERP deployment is unique to each organization,” the CSA’s ERP Working Group, which developed the guidelines, said. “In most cases organizations spend months if not years customizing their SAP or Oracle implementations and spend a significant amount of money with third-party contractors to complete the implementations. This makes standard security measures more difficult to implement due to the differences of each deployment. With the complexity of these large implementations, combined with the criticality of data and processes housed in these applications, it is imperative that industry best practices be established to provide security guidelines to companies migrating to the cloud in order to protect the organization’s critical infrastructure.”