By Dmitry Gutsko, SAP Security Expert
We know that SAP database systems are often overlooked when it comes to an organization’s security infrastructure. It’s full of siloes and blind spots, the worrying thing is – execs know it. For instance, 66% of executives are worried about the rising threat level around the world. And what about insider threats? Those incidents have risen by 44% over the past two years, costing $15.38 million per incident. So, what does the future of SAP security look like?
Right now, we have big data. Well, the future means even bigger data, and with that comes even bigger demands on understanding customers, customer data and their needs, and then there is the projected SAP migration slated for 2027 pushing further towards SAP HANA. Research published in March 2021 suggests only 24% of SAP customers had already made the transition to SAP S/4HANA, with 23% stating they did not have plans for migrating.
So, let’s begin there. Right now, (SAP) S/4HANA is underestimated within SAP Security, but with the migration only a few years ahead it is important that we understand the needs, challenges, and methods that can be used.
What are the main challenges for SAP security teams?
- How to protect data from unauthorized access?
- How to maintain control of administrators and users with high privileges?
- And, how to identify malicious ABAP code in your SAP landscape?
With that established we now need to figure out how we can easily detect all these use cases using only one log source.
As you may know, there are a huge number of SAP business modules based on an SAP NetWeaver ABAP Platform. Each module provides a lot of functionality to SAP end-users and SAP consultants. Of course, the IT-security team members can’t learn all aspects of every single module, but they can control access to tables with sensitive information at the database level instead.
Tables and SQL requests are well-known terms in the IT world and every security expert understands them. Using such an approach you no longer need to depend on new SAP technologies like FIORI, SAPUI5, and S/4 HANA. Eventually, any code executes an SQL query to database tables with data. Thus, we can unify SAP security checks, no matter what specific SAP software and technology you use. We need only to control which SQL requests go and which tables were executed at HANA level and by whom. And with that, the modern SIEM can distinguish typical requests from those that are abnormal and identify malicious access (or modification) to sensitive information in SAP.
The protection of SAP software against administrators without HANA level security looks frankly, ridiculous. The easiest way for SAP BASIS Experts to read salaries is using HANA Studio, the SAP HANA hdbsql tool, or DBCOCKPIT. In most cases, requests to databases will be under technical SAPABAP1 user (schema owner) or SYSTEM user. So, they easily get away from any detection and unwanted questions because such activity coming from technical users gaining access to the data is completely typical.
What should the security team do in this case?
Essentially, there is only one option – enable protection on SAP HANA level and enable logging for critical tables even for technical HANA users (the administrator who has bad intentions will never use his own user in the SAP HANA database).
There are a lot of cases where developers and contractors create nasty ABAP code in customer production systems and then executed it. A lifetime of such programs can be only five minutes or even ABAP programs have the ability to execute dynamic code. That’s why it is extremely tough to detect such malicious code using source code scanners. Hard to believe, but even this use case can be easily detected using HANA logs. No matter what ABAP code the infiltrators use (standard or custom) in this case it will eventually launch a specific SQL request to get to and modify, sensitive data. It could also reveal the attacker’s intentions and personality.
Nowadays the number of SAP HANA database users is ever-growing. In the beginning, only administrators received legitimate access to the SAP database. The current picture is completely different. Contractors, developers, SAP consultants, and even end-users have their own user accounts in a HANA database, making it even more paramount that we check user privileges more carefully as well as actions with user privileges, especially privileges for SAPABAP1 schema tables.
What to take into account in securing SAP HANA?
It’s vital to not forget about modern technologies like calculation views/analytics views in HANA which can contain unwanted access to sensitive data. Likewise, the number of HANA-to-HANA integrations between SAP systems is ever-growing, and all of these can generate possible security threats to your data.
HANA level security is vital and will become even more important in the future. HANA logs can help all of us in protecting our SAP systems, yet only one SAP security topic is widely recognized in the world – SoD (Segregation of Duties). Only a few deploy SIEM solutions and try to detect abnormal behavior in SAP systems. Even fewer customers think about HANA level protection. This situation, though, will change as more and more companies turn to tools like Logpoint BCS for SAP which supports the HANA log source and connects to any SIEM. Protecting your SAP landscapes has actually never been easier or more comprehensive.
