How you can maintain GRC compliance if you have users with dangerous SAP_ALL?
The authorization profile, SAP_ALL has such vast amounts of authorizations inside that it is mistakenly known as “the profile that can grant everything in the SAP system”. Dangerous? Sure. Very dangerous. And it’s not alone – there are other, more powerful profiles like SAP_NEW, S_A.ADMIN, S_A.SYSTEM and more.
So, why are people still using and requesting SAP_ALL?
Usually because of ego and because it’s easy.
Users tend to ask for SAP_ALL authorizations because “they know what they’re doing,” “they need lots of authorizations,” and, “so the work doesn’t stop due to annoying ‘no-authorization’ messages”. Sure, by using the SAP_ALL authorization profile, there aren’t any “no-authorizations” messages anymore, but the user becomes a hacker-favorite for taking over. Most hackers prefer to use an SAP account that was granted SAP_ALL authorization profile for their underhanded activities – it’s really a genuine time-saver and a great advantage for committing fraud or stealing information.
People grant SAP_ALL profiles because it’s a quick solution when the stress is on. System administrators often tell us it’s much simpler to grant SAP_ALL to the new developer in the IT department than to tediously identify exactly which authorizations are required.
Granting SAP_ALL and similar power profiles to user accounts creates and then expands security-holes, grants an unnecessarily huge amount of authorizations to people that can’t justify them, and exposes the organization to new possibilities of fraud and internal hacking.
Cleary, GRC auditors do not like users with powerful authorization profiles, i.e., power-users. So, organizations will try to remove SAP_ALL and grant only the required Authorization Roles. Removing SAP_ALL is easy. What’s hard is deciding which roles to assign to the user instead.
Get clean: How to really solve current SAP_ALL situations
There are two ways to solve the SAP_ALL situation: through “trial & error” and by using “behavior-based profiling”.
- “Trial & error” means taking off the powerful profiles from the user and granting him Authorization Roles that fit his job. For 1-2 users this may be a decent solution (although not perfect), but what about 10, 20 or even 50 users who have SAP_ALL?
- “Behavior-based profiling” analyzes the user’s behavior for 3-6 months and creates precise Authorization Roles for him. Xpandion’s behavior-based software tool ProfileTailor Dynamics is one such solution, or you can create a long trace file and analyze it on your own.
Assuming you’ve done this, you’re “clean”. Now, you have to stay “clean” by implementing a set of controls to avoid granting powerful authorization profiles again.
How to stay clean?
To stay on the safe side of GRC, you should do the following:
- Implement a dedicated external system like ProfileTailor Dynamics, so you can define powerful, “sensitive” authorization profiles and activate an alert for when they’re granted that gets sent to the security officer.
- Implement a practical tool like Xpandion’s Emergency Access. If users need privileged access for a limited time, this mechanism allows them to open a username or grant a special Authorization Role for that limited amount of time.