This website is not affiliated with, sponsored by, or approved by SAP AG.

SoD - Authorization Objects

SAP Security

Moderators: Snowy, thx4allthefish, jurjen

SoD - Authorization Objects

Postby bblom19 » Mon Apr 08, 2013 1:28 pm

We are in the process of kicking off an ad hoc SoD analysis, the outcome of which we hope pushes the business to invest in/develop a tool to help manage SoD conflicts. Until then, I need to run this analysis from the database. The two questions I have are:

1. How do I correctly identify the auth objects assigned to a give user? Looks like the combination of AGR_USERS and AGR_1251 might do the trick. Thoughts?

2. How do I identify the basic auth objects required to run a transaction? I don't want to get too granular (i.e., looking at company code, division, etc.), but I also don't want to stay at too high of a level (i.e., only looking for S_TCODE). I just need to know if a user can execute a transaction and post, change, etc. a given document.

Any thoughts would be greatly appreciated.
bblom19
 
Posts: 2
Joined: Mon Apr 08, 2013 12:48 pm

Re: SoD - Authorization Objects

Postby henrik » Tue Apr 09, 2013 10:41 pm

1) you are right, the combination of those two tables should give you most of what you are after. Just remember to adjust for validity date :-)
2) I think the only option - which is nowhere near perfect - is to look at USOBT and USOBX. Make sure you only look at the OKFLAG = Y in USOBX. These are the tables that PFCG uses to determine which objects and values to pull in when building roles. It is not complete or even entirely accurate - but in my book, it's the best you get without the proper tools.

What is the size of the user population?

/henrik
www.turnkeyconsulting.com.au
henrik
 
Posts: 493
Joined: Wed Oct 23, 2002 6:38 am
Location: London, UK

Re: SoD - Authorization Objects

Postby bblom19 » Wed Apr 10, 2013 9:29 am

Thank you for the reply!

We have approximately 1,100 dialog users. There are also approximately 100 service accounts, which we may include in the analysis - I doubt it, though. Out of curiosity, why do you ask how many users? Seems the user piece of this analysis will be the easiest, so just trying to get an idea of what you are thinking.

Again, out of curiosity, how would a tool find out which auth objects are required to execute a transaction? Our original analysis is only going to cover select transactions within the O2C, P2P and accounting processes (probably around 50 transactions), so if a more tedious approach is required, it will not have to be completed on the entire population of transactions.

Again, thank you for your guidance!


Regards,
Brandon
bblom19
 
Posts: 2
Joined: Mon Apr 08, 2013 12:48 pm

Re: SoD - Authorization Objects

Postby Al. » Wed Apr 10, 2013 1:18 pm

Hi, Tools generally take 2 approaches -

1. Take proposal values from USOB* and let you choose which to include
2. Rely on someone else having done the hard work already (typically through option 1)

Generally you end up with a subset of the SU24/USOB* values (i.e. you only need to know the main controlling auth/s) and there is a balance between being efficient in the object selection and reporting false positives.

Having been in your situation before I would strongly consider getting an SoD review as a service from a company with an appropriate tool and ruleset. Your auditors will have access to this functionality and there are plenty of niche providers who can offer this too. Very generically it's probably a week's worth of work.

Good luck.
http://www.turnkeyconsulting.com/
Al.
 
Posts: 3050
Joined: Tue Feb 25, 2003 5:35 am
Location: London

Re: SoD - Authorization Objects

Postby henrik » Thu Apr 11, 2013 6:54 pm

Regarding the tool - What Al said :-) Rule sets are what makes a tool valuable - well, not the whole picture, but you know what I'm getting at (I hope :) )

I only ask to get an idea of the magnitude of your task. There are many variables to take into consideration. For instance - how do you handle deactivated objects? How do you handle ranges in authorisation values? There are many pitfalls that could cause your reporting to be wrong.

I would also recommend getting some qualified assistance with this. Yes, it will cost you a bit of money, but you get a result that you can confidently present to management, rather than a home built solution that may or may not produce the right results... The time you will have to spend doing this could probably be spent more efficiently analysing the finding and preparing your business case.
www.turnkeyconsulting.com.au
henrik
 
Posts: 493
Joined: Wed Oct 23, 2002 6:38 am
Location: London, UK

Re: SoD - Authorization Objects

Postby MHoetjes » Thu Jul 04, 2013 6:56 am

Hi Brandon,
I agree with Al and Hendrik. I did manual SOD testing some years ago and it took me ages and I had to be very carefully, a mistake could be make easily and then the results would be incorrect.

First of all, you have to find out which authorizations to check that can perform a functionality. You have to make sure you will take all the authorizations for this functionality into account. Even if you use tooling, this step is very important to do. Luckily, if you use tooling, this finetuning step can be done using a template and it can be maintained easily for further analysis.

How the tools work: I know that the CSI Authorization Auditor will simulate the user buffer and will take any setting into account (like locked users, roles with validity dates in the past/future, reference users,etc., ) The finetuning of the SOD conflicts will be saved in a file and can be maintained en further finetuned easily.

Off course, buying a SOD tool will cost money, but only after the first run/analysis it will save money and time and you are sure you are looking at the correct results.

If you have any further questions, please let me know!
Meta
MHoetjes
 
Posts: 1
Joined: Sun Jun 16, 2013 1:23 pm


Return to SAP Security

Who is online

Users browsing this forum: No registered users and 5 guests





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.