Recently, SAP Insider sat down with the SAP experts at Fastpath for webcast Q&A around building a security and compliance program for SAP landscapes. They panel discussed topics all over the map—from how to handle audits around non-SAP systems in an SAP landscape to the ownership of an organization’s security program. Below is Part 4 in a series of 9 posts.
Security and Compliance for SAP, Part 4: Granting User Access - Who, Why, and How Much
This 9-part blog series provides insights into easing the daunting responsibility of dealing with security and audits. This area does not have to be painful nor time-consuming. With the powerful functionality within SAP, combined with technology like Fastpath and the support of security experts, you will be well on your way. The bottom line: implement processes, take a risk-based approach, and get the right controls in place to allow you to meet the demands of your auditors and improve the efficiency of your security program. The series so far includes:
- Part 1: Using processes and a risk-based approach
- Part 2: How to handle custom transaction code
- Part 3: How to talk to auditors about non-SAP systems in an SAP landscape
Granting User Access in SAP - The Who, Why, And How Much is Critical!
In our business, we get a lot of questions about user access. Who should have it? How much should they have? While there is no hard-and-fast answer—because it depends on the needs and structure of your organization, we do have some advice. In this blog, we’ve broken down the sections by the actual question that was asked.
“How much access is too much?”
Many of our customers as well as people we meet at conferences ask this: "How do I prevent any segregation of duties within my environment?" At the end of the day, preventing SoD shouldn't be any company's goal. Large companies that have a city’s worth of employees, like General Electric, are simply unable to prevent segregation of duties within their environment.
People need to be able to do their jobs, and their jobs often span both sides of conflicting duties. The moment people start complaining that they're not able to do their job because you're taking away too much of the access is when you've gone too far.
Our perspective on access is always grant the least access possible to allow people to do their job.
The answer to what is required from an access perspective is really the least access you can possibly justify by not causing inefficiencies in your business. What you need to be able to do is detect when there is a segregation of duties issue, assess it, and then mitigate the risk associated with it. This requires having some kind of monitoring aspect on whether people are actually utilizing the access that you gave them.
For example, the SM20 tables in SAP will tell you whether people are actually utilizing some of the authorization objects. To be able to grant access that people request is important, but also to be able to monitor that access and know whether it's actually being utilized so that you know whether you could take it away, theoretically, without causing breaks on your business, is also important. Being able to operate on the back end is also critical.
To further build on the idea of the least privilege access: If you've built your processes around security and educate your business process owners around the concept of least privilege access, and you're doing a risk-based approach, those two approaches executed together is going to give your auditors extreme confidence that you're not just assigning access because someone says they need it for their job.
You're not just assigning access because in the old system that same individual had that access. You're really structuring it and approaching it in a sound, proven way. The concept of least privilege access is proven. The concept of taking a business process, risk-based approach to analyzing where you need to put the controls is proven as well. Those two approaches combined produce a very good story that when supplemented with the right controls is one that auditors should feel comfortable with.
“My people need to be able to do their jobs. Shouldn't I just grant them whatever access they say they need to do so?”
From an IT perspective, it can get frustrating to try to track access, determine who really needs what, and watch the SoD risk, all at the same time. IT folks are trained to help users. Unfortunately, you also need to have the appropriate controls in place, and you need to have processes in place for compliant user provisioning. What users think they need to do their job and what they really need are often two different things, and IT folks throughout the user provisioning process who are granting access need to be careful to not give too much or too little access.
In reality, IT is the provisioning function…not the approval function. They're not the people who should be determining who needs to have access to what. That needs to come from the business process owner, the group that actually owns the data.
In the CFO organization, accounts payable data is owned by someone in that organization. That individual should be granting access and approving who should have access to that data. The same holds true for HR.
While it's easy for IT to want to help everybody and just grant access because people say they need it for their job, it’s a dangerous game. Your organization needs to have a process in place for requests and access. That process needs to include the appropriate approvals from those who own the data and ultimately, the completed requests with approvals are passed on to IT, who, in turn provisions security in a way that's commensurate with what's on the request.
Numerous times we've seen IT departments get put into tough spots around this issue. Think of the concept of the “drive-by IT help desk ticket”, where a user walks by the cubicle of an IT person and says, “Hey, I'm trying to do this, help this customer out. I can't get it to work. I think it's related to security. Could you help me out?” The IT person wants to help, of course, but their response should be, “You need to submit a ticket to request a security change and let the owner of that data then decide if you need to have access."
Otherwise, you could run into compliance issues. Yes, it’s a balancing act between helping your users and following the rules, but the rules are there for a reason, and IT should not be put in the middle, to be the one deciding who needs to have access to what. In smaller companies, it’s even more of a challenge, because IT is considered to be the group that knows who has access to what, but ideally, it should not be set up this way.
"Why are auditors constantly asking IT to validate what access people are granted, when we are only doing what managers tell us is needed?"
That's exactly what we just discussed. IT does not own security in terms of who should have access to what data; they should be in a position of provisioning only. If your auditors don't understand that concept, they need to sit down with someone who can explain to them how controls are supposed to work with user provisioning, and that you have a department and organization, ultimately individuals, who own that data that are the ones to grant approval to that data and what level of access people should have.
Unfortunately, many audit teams are using old audit programs and asking the same, outdated questions, regardless of knowing if they're applicable or not. This is not good. The auditors should not be asking that question of you. If you can't get them to move away from that question, ultimately find out who the audit manager is on that engagement and talk to them in more detail. Perhaps get a higher-level manager in IT to support the discussion. You can validate the access. They can ask you for reports that can help to validate it, but it's not your job to go through and grant approvals. Auditors should understand that.
“I am responsible for the SD area at my company. How do I see who has access only to SD-related transactions?"
If you’re accustomed to SAP, you are familiar with the SUIM reports. They can pull the access, look at your roles, dives down to see what transactions each role has access to. From the Fastpath side, that's all fully customizable, so you can identify the access a person, or a functional area, has access to — quickly.
All security changes should be checked in these days, but sometimes permissions are added to a role which was pushed to production, without anyone’s knowledge. This is a good way of creating a critical access point. Reports can be automatically generated in the background to identify who has access in the areas you’re concerned about (in this case, SD), which can be sent to you every morning.
From what we hear from customers, it’s not always about who is on the list, but the number. You want to make sure that that number stays the same. So, for example, if you have 112 users currently in when you’re considering my SD transactions, and the next day that number shoots to 250, and you weren’t aware of it, then you need to find out what’s going on and address it if necessary.
A huge aspect of security is determining who has access to what and why—and being able to monitor it.
Stay tuned for additional blogs in this series! Want them all at a glance? Check out the first blog which will have all 9 links once they are all published.