A very different event: Data Security for SAP.live
I’m going to try very hard not to use the phrase ‘new normal’. Firstly because I’m sick of hearing it (not sick like that, you don’t need to recoil to the back of the room and hide behind the curtains), but secondly because there is nothing normal about this and it changes day to day.
Recently, I took part in our sap .live virtual event. For the last six years, EPI-USE Labs has been running regional User Group events, as well as other in-person conferences. I’ve had the pleasure of travelling the world to speak at them, and meet some of the great people that use our software every day. Since March, we have been sharing more content via digital platforms, but our virtual conference, Data Security for SAP .live, was something altogether new. The two-day event was co-ordinated across the globe with clients, partners and internal experts presenting from Europe, Africa and the Americas, all on security focused topics,including Data Privacy regulations, GRC, Risk Monitoring and more. If you missed it, you can catch specific session recordings here.
I was responsible for the last session of the first day called 'Common SAP hacks: Is your SAP data as secure as you think? and that’s what I mainly want to focus on here.
Working around versus hacking
I wanted to do something a bit different for this event, since the event itself was going to be something different. I was also cognisant that attendees would have seen a lot of slides by the time it came to the last session of the day. So I decided to keep slides to an absolute minimum and share my screen to show some 'hacks' that could be happening, particularly in non-production systems. I use the word ‘hack’ with a note of caution. This isn’t someone accessing a system illegally from outside the organisation; this is someone given access to do A, B and C in a system, and finding a way to do D. In many cases D was part of the activity, or essential in delivering the activity for which I was engaged.
The intention of the session was to make administrators and authorisations controllers aware of how SAP technically works around transactions, programs and function calls, but anyone reading this with the intention of circumnavigating authorisations checks themselves, please do so with thought, consideration and integrity. If you are questioned about your activity, can you justify accessing D when it wasn’t available through the most direct approach? Was this an oversight in your access, and you were saving everyone effort by working around it? Or are you accessing something you know you weren’t intended to be able to do?
If it's the latter, or if you’re in any doubt, I strongly suggest you ask for the additional access via the normal routes.
The role of code
The session included three of these…workarounds (you thought I was going to say ‘hacks’ again didn't you?). One of the points raised in the keynote was that while working from home, people may be more inclined to ‘test’ their permissions, knowing there is no-one watching over their shoulder as there might have been in an office. That wasn’t something I’d really considered even while preparing the session, but I think is quite pertinent.
All three workarounds involve a slightly more technical understanding of SAP than most SAP users will be likely to have. There are two main ways authorisations are checked:
Firstly as a result of something the programmer intended. Within their code they can use the keyword ‘AUTHORITY-CHECK’ and pass in an authorisation object e.g. S_TABU_DIS with one or more ID values. These are the values the user’s master record must have in a pattern with the specified authorisation object, for example:
AUTHORITY-CHECK OBJECT 'S_TABU_DIS'
ID 'ACTVT' FIELD ‘03’
ID 'DICBERCLS' FIELD pd_group.
In this example, the field value for ACTVT is being explicitly stated, and the other ID value is a variable in the code. But also, in this case all the ID values of the object are being checked. Which isn’t always the case. A pattern in a role like this:
could be assigned to allow a user access to something which runs an authority check only on the IDs Activity and Object Category. To better see the alignment with what the code calls, you can also switch technical names on:
But SAP will warn you if you don’t maintain the fields at all, so typically you would add the dummy value to those fields not required for the check you’re trying to pass. This ensures you don’t inadvertently give access for something else which checks different IDs.
The second way an authorisation check happens is when it's automatically triggered by the kernel. For example, when someone executes a transaction code the S_TCODE authority check is run for the ID TCD (the only ID on the object) with the transaction name. And that leads you nicely to the first hack.
Here's information about 'How to prevent the three most common SAP hacks' as a download.
Leave a Comment: