Securing Your SAP Implementation by Gilad David Maayan

SAP systems are used by many organizations to store and process significant amounts of confidential or sensitive data. This data is incredibly valuable to the organizations themselves, their customers, and attackers. While in the past, most SAP systems were only accessible from within an organization, many workloads are now in the cloud. This makes data more accessible to organizations and to hackers and requires tightened security measures.

In this article, you’ll learn some of the ways in which SAP configurations can be exploited. You’ll also learn some best practices for protecting your systems and preventing attackers from accessing your data.

Potential SAP Security Risks

Understanding how your SAP systems may be at risk is the first step to properly securing your implementation and data. Below are a few of the unique ways that SAP can be vulnerable.

Lack of Encryption for Data in Memory

SAP uses RAM to quickly process and retrieve data but you can’t encrypt this data without decreasing performance. This makes data vulnerable to RAM scraping, a technique that accesses data directly from memory to avoid encryption. It also makes SAP vulnerable to viruses or malware running in memory. These memory-based attacks leave no footprint, making attacks difficult to detect and prevent. 

Public Access Through Internet

You can find many publicly accessible SAP login pages with a simple Internet search. These pages provide a potential direct connection to SAP systems for attackers. In particular, these portals are vulnerable if you haven’t reset the passwords of your default user accounts. The credentials for these accounts are publicly accessible and provide privileged access. 

Likewise, your system is vulnerable if you do not limit the number of login attempts or if you provide overly detailed error messages. Letting an attacker endlessly try to enter or providing information that helps them narrow their attempts is an invitation. Depending on how you handle login inputs, you may also be open to SQL or other code injection attacks.

Insecure Code

Many SAP systems include significant amounts of code for customization. Any vulnerabilities in custom code transfer to your SAP systems and can provide access to otherwise protected systems. The risk potential may be even higher when open-source code is included as it may have functionalities you aren’t aware of. This is particularly true if code isn’t verified to be secure before inclusion. 

Open-source code can contain a variety of both intentional and unintentional vulnerabilities. It can also be redistributed with vulnerabilities or malware added if you take libraries or frameworks from unofficial sources.

Best Practices for Securing Your Systems

Understanding your risks is the first step but understanding can’t provide protection on its own. Rather, you need to combine this knowledge with some data loss prevention and security best practices.

Integrate SAP Security and System Protections

You should use a combination of cybersecurity and SAP security. SAP security measures typically assume that anyone on your network is supposed to be there. Cybersecurity and systemwide measures try to ensure this is the case. 

You should be using monitoring tools that incorporate SAP monitoring data. Response tools and protective measures should apply the same policies across systems for consistency and greater reliability. It is also a good idea to federate your IAM systems. Federation ensures that permissions and roles are linked across systems and makes it easier to manage credentials.

Additionally, you should be monitoring both SAP security releases and external threat data sources. SAP releases cover SAP specific threats but cannot help with protecting your host system. Vulnerability databases and threat intelligence feeds can provide you with information on threats to your overall system. These sources contain information on open-source software and affected systems as well as attacker practices.

Implement Segregation of Duties (SoD) and Role-Based Permissions

You should implement both SoD and role-based restrictions to limit malicious access from both inside and outside your systems. SoD prevents internal abuse of valid privileges by separating vital functions within an organization. For example, users can’t both create new vendors in a system and issue payments to those vendors.

Role-based permissions separate permissions into only those valid for that role. It can help you ensure non-administrative users do not have excessive system control. Role-based permissions make management easier and can help reduce the damage caused with compromised credentials. 

Ensure Strong Passwords

First, make sure that you change the default passwords of SAP generated users. For example, SAP*, DDIC, and SYSTEM. If you are not using these accounts, disable these credentials, don’t just delete accounts. Disabling accounts notifies the system not to allow use; if you just delete, some accounts, such as SAP* can still be used. 

Any passwords you change should be complex and should not match any other credentials. Likewise, you should set complexity requirements for general user passwords and not allow duplication. Passwords should expire after a set period and should not match passwords used in other systems. In SAP, you can use the RSUSR003 report to uncover problem users and help enforce these rules.

Secure Communication Channels

Securing your communication channels is vital to protecting your SAP implementation and your system as a whole. You should only activate those communication services and ports you’re using. For those that you are using, make sure to encrypt communications. Unencrypted connections provide an opportunity for attackers to steal or modify information in transit.

To contain risk within your systems, make sure to apply Access Control Lists (ACLs). ACLs can restrict movement between components and services and require credential verification for movement. These restrictions can prevent attackers from exploiting vulnerabilities in one system and moving to the other. In particular, you should make sure to secure connections between SAP Internet Connection Manager, SAP Management Console and SAP Dispatcher, and other services.

Conclusion

Hopefully, this article helped you understand some of the risks that SAP systems face and how to mitigate these risks. You can verify your system security by starting with these practices. Once you’ve implemented the practices covered here, review SAP’s practical guide to securing your system. It can provide you with specific actions you can take to secure your implementation.


About the Author:

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.

LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/

June 22, 2020
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013