Data Extraction in SAP: 5 Critical Dangers You Must Address
Chapters
Share Article
Introduction
Data leaks can be anywhere. We can all remember typical examples where sensitive data gets ‘on the street’ via a lost USB memory stick that got lost, right? The prevalence of low-tech data extractions has been reduced thanks to technical restrictions and security awareness. However, data extraction in organizations is still very common and is certainly still a risk without proper control. In this article, we highlight the Top 5 points to consider when it comes to data extraction in SAP environments. Let’s dive in!
1. The modern IT landscape – where is your data?
Looking back at earlier times, IT landscapes were comprehensible and resided in well-known locations with clear physical and network perimeters. In other words, it is quite manageable compared to today’s dynamics. That is not to say that SAP landscapes were never complex, of course not. But looking at the highly connected IT landscape of today, with several types of cloud services in a globalized context, we live in an entirely different era. The impact of these developments on organizations is enormous, and the same applies to IT security. From a ‘data’ perspective, it makes a huge difference. Data is no longer (mainly) processed and isolated in silos but is further and further distributed by several connected systems and services. Think about traditional SAP landscapes, now using BTP services and other cloud-based applications. The basic challenge here is: do you know where your data is and where it goes? Regulations like the General Data Protection Regulation (GDPR) certainly play a role by enforcing data protection for personal data. But for non-EU regions or other business-critical data, clear oversight is needed.
Consideration: create insight by mapping out integrated systems or services and specify data flows.
2. Production AND beyond
SAP systems typically hold business-critical and sensitive data, often referred to as the ‘crown jewels’ of an organization. And when it comes to protecting that data, organizations focus on their production systems first because issues on those systems have the greatest impact. So far, so good, but it shouldn’t end there. In many organizations, it is not uncommon to copy production systems or their data to other systems for a range of reasons. For example, test systems are often ‘refreshed’ with their production counterpart to provide better quality assurance. Migration or upgrade projects are also common reasons to have copies of production systems. Having copies of production data is already a major additional concern, but when we consider this in the highly integrated
modern IT landscape (1st point), we quickly see how the use of copied production data can become a serious problem. Controlling the flow of production data alone is a challenge, now imagine the difficulties when this data is also distributed through non-production channels…
Consideration: implement clear procedures to prevent or efficiently control copies of production data
3. Authorisation management
Hopefully, any IT security professional will understand the importance of a proper setup of authorizations. However, it is a common finding in SAP audits that users exist in systems that no longer should be there or that authorizations are assigned way too broadly. It is important to implement a clear authorization concept where access is only granted to those who need it and only to the data that is required for their role, etc. As obvious as this may sound, this proves to be a lot harder to achieve in real life. Again, this aspect is enlarged by the points earlier made above. Enforcing proper authorizations is a lot harder in the modern IT landscape. And it is not only production systems that need this. Not only because of possible production data being there but also because of the risk of ‘lateral’ movement, for example. It is not uncommon to see non-production systems with users having much broader authorizations than needed. This often creates a starting point that can be used to ‘move up the tiers’ from non-production to production systems. As demonstrated by penetration tests but also actual hacks by malicious actors…
Consideration: manage authorization across all system tiers, including on-premise and cloud-based products.
4. No more data dumps!
Direct exports by users
SAP systems are designed to enable business processes and provide users with proper functionality to interact with the system. In an ideal world, this facilitates every requirement, and the system offers each user a proper functional user interface (UI) for whatever they need. Reality usually tells a different story. It is not uncommon for organizations to allow users direct access to data in systems. Reasons for this can be many: insufficient UI functionality or reporting purposes, for example. Or – and this may be the most common example! – users that are used to working in a certain way and want the ‘raw’ data to create their spreadsheets, reports, or even client-side databases that act as a ‘shadow Business Warehouse’ system! A common example is the SAP transaction SE16, which allows direct table access. It is no exception to see this transaction being used by several users, like business-as-usual in organizations. Whatever the reason, without additional controls, this allows for direct access AND downloads of data to client devices, which is a major concern to keep data secure. These downloads completely surpass intended authorization controls. Downloads can be stored in any location, accessible by who-knows-who, sent out by e-mail to audiences of any kind, etc. Intentionally or by accident. This is not hypothetical, but real-life situations that simply happen frequently.
Consideration: restrict direct access and downloads of application data and foster user awareness.
File-based integration
Besides data extractions by users, there is the risk of data extractions for system integration. Secure integration of systems is preferably done via modern technologies like APIs or web services, for example. Or in the case of SAP ABAP systems, the RFC protocol. These can be properly secured to the latest standards. However, integration scenarios often exist that are a lot less sophisticated and rely on file-based integration. These often concern (large) exports of data that are written to files and transferred to another system for further processing. We name two common reasons for this:
- Technology: many (legacy) systems lack modern integration options and can only work with the import and export of bulk data, like CSV files, etc.
- Knowledge/Skills: APIs, web services, encryption, it all require a higher skill level than working with exporting data to files. That’s part of the appeal; everyone understands it! And so, these integration scenarios often start their life from those assumptions. “Let’s first get this data into a file, and then we’ll see how to handle that”. Does that sound familiar?
There can be reasons to export data to files, but it should be avoided if possible. Reason: when using files as a medium, you don’t only need to handle the ‘data-in-transit’ security but also the ‘data-at-rest’ security. That’s a lot of extra concerns compared to an API, for example. Let’s name a few:
- Direct encryption of the exported data is often not a default option and needs to be handled separately.
- Files need to be stored, processed, and removed after successful processing. This all requires additional technical handling, which can easily result in files remaining stored outside the original application.
- Files need a secure location with restricted access. This is often only partly possible to realize, and users like system administrators and similar users will likely still have access.
And finally, exporting data to files often stems from a desire to have a lot of (combined) data in a single medium. The main concern is that all this data is taken out of the application context and put together in a flat file without any restrictions. Think about that from an authorization perspective! Many organizations spent a lot of effort in designing clear roles, separating access to data based on roles, etc. But when the same data is exported in a file, all it takes is access to that file, and any control is gone.
Consideration: apply modern integration technologies to prevent file-based integration where possible.
5. Encryption – always!
It should be obvious in 2025, but let’s spell it out: always-use-encryption. We already mentioned data-in-transit (transport of data) and data-at-rest (storage of data). Encrypting data on these levels is not an option it must be a mandatory step where data is extracted or processed from the application context.
Consideration: apply encryption for any data either at ‘rest’ or ‘in transit’.
Conclusion
We briefly named five important points to consider for data extraction in SAP landscapes. At SecurityBridge, we work constantly on enhancements for customers to offer a complete security solution for their SAP landscape. With features like Interface Traffic Monitor, Data Loss Prevention, and Vulnerability Management, the SecurityBridge platform can be the cornerstone of an SAP Security Architecture that truly protects your company’s mission-critical data. Contact us for a free demo to learn more!
