What-if/Impact Analysis tool for role removal

[Former Member]

Hello all - I am not new to SAP, but I am not a security person either. My security team is constantly sending me emails of the nature of: "we want to remove role xxx from users a, b & c; is it okay?" Well, I don't know the answer to that, and the only way for me to determine the answer, currently, is to look at what transactions, autiorizations (and therefore auth. objects and activities) are assigned to a user. Then, determine if we take away role xxx, will the user be negatively impacted or not. What I am looking for is: a report or tool to say:

After this change, the user will gain access to the following transaction codes:

After this change, the user will lose access to the following transaction codes:

After this change, the user will gain the following authorizations, which have the following authorization objects and activities:

After this change, the user will lose the following authorizations, which have the following authorization objects and activities:

Does such an animal exist? If so, can you guide me to it? We have Virsa, if that helps.

[arpan_paik]

 Does such an animal exist? If so, can you guide me to it? We have Virsa, if that helps. 

Well I don't think it's a animal but call call beast. Compliance Calibrator

Anyway when some security guy send you the report they must have give you the impacting side as well. Can we remove this role having ME29N as user is having ME21N via this role. Which is a conflict. SOD violation will always have 2 sides. You need to check on that and then decide.

There are many other too like Biz Rights, CSI AA etc like Compliance Calibrator. I found CC most prominent tool (My view)

Regards,

Arpan Paik

[Former Member]

Hi Justin

I'm assuming you are involved in or victim of a security access review. I'm usually one of those security guys asking for role or transaction removal and you are the main contact in the business coordinating the changes.

The process of remediation will possibly consist of checking which transactions are causing segregation of duties conflict, if they are used or not and removing one side of the conflict by removing an unused transaction.

It shouldn't require the entire contents of a role to be removed - rather swapping role A for role B without a transaction or two.

Removing transactions that aren't used can have more subtle implications which hopefully are found during UAT but is usually missed until used in anger. This what support is for after go live.

Saying all that and depending on your time and skills, you could ask for access to the security person's test user in dev or qas where they are working to run transaction SUIM on transaction for user following the proposed changes and compare that to the actual access of the real affected user in prod. If you can get access to the informer tab in virsa you can use the standard simulation reports to also check the resulting conflicts which will help you talk to the business and advise on actions available. There should be role owners involved in all this as they have to owner the result: expect a request for these for CUP later on

If you can retain control and approval of the (controlled) changes being made to users you will have a better understanding of what is happening, catch potential errors and mediate between security and the business - you have an important task!

Ask for some basic training in standard SAP reports - the security team should be more than grateful for your input

Crikey that was hard typing on an iPhone!

Cheers

Edited by: David Berry on Jan 11, 2011 8:17 PM

[Former Member]

Hi,

The approach we take for doing a user access review are:

1. Identify the SOD violations from roles assigned to users at tcode level/authorization object level

2. For roles with violations, check usage of transaction codes (contained in the roles identified in step 1) by users for previous quarters (assuming you are doing it semi-annually) and let the supervisor decide, based on the above details, if the risk has to be remediated(removed) or mitigated ( replace with some other roles to lessen the risk level)

You can use Virsa Compliance Calibrator (now known as Risk Analysis & Remediation in SAP GRC Access Controls) and run simulation in User level Risk analysis option(select permission level for conflicting tcodes and action level for conflicting authorization object level) to assess the risk/violation resulting from assigment of particular roles to a user (the risk analysis is based on rulesets defined in RAR/CC). If the request for approval is being sent to you in Virsa Access Enforcer( now called Compliant User Provisioning), you can do the User level Risk Analysis simulation before approving for remediation or even file compensating controls in case you decide to go for mitigation. The risk analysis is basically done by calling the RAR/CC component which is integrated with CUP/AE in this case.

You can also look at transaction usage for particular user in Informer tab of Virsa Role Expert ( now know as Enterprise role expert) after running alert generation job in RAR/CC. Alternately, you can look at contents of virsa_cc_actusage table or by running in backend the FM=/VIRSA/ZCC_GET_STATREC_DATA.

Hope this helps

Thanks

Sandipan

[Former Member]

One thing that I think people are confusing is SOD with role removal. These roles are not necessarily being removed due to SOD. Often times, they are being removed because they are perceived to be obsolete, or, more likely, they have duplicate TCodes/Authorizations in them. The only way that I have come up with so far is to create a user, "ZWHATIF" that is a copy of User A (or B or C or whatever); then remove the role in question from ZWHATIF, then run S_BCE_68001430 (User Comparison TCode in ECC). And only compare the differences. However, this seems awfully cumbersome.

[Former Member]

In that case you can create a SQVI query by joining tables AGR_USERS and AGR_1251 to get a report with User> Roles assigned> authorization object contained ( tcodes under S_TCODE) relationships and filter to see if a particular tcode/authorization is given to user via someother role except the one asked for removal

Just my 2 cents but worth a try!

[arpan_paik]

 However, this seems awfully cumbersome 

It is supposed to be like that way. As 1 tree getting removed then it will show a difference even if the value present in other tree. SAP might look into this in future to focus on value as a whole in all tree.

Regards,

Arpan Paik

[Former Member]

Hi Justin

Sorry if I took mis-interpreted the scenario, if you just want to remove unused roles would it be possible to attack this from the opposite direction?

Do you know which transactions are used? If so, would you consider mapping those to the assigned roles (or indeed other roles in your system) and assign to a test user to see if the overall access is reduced but still retains the necessary transactions and auth objects? This would need UAT before replacing the original access but may be a quicker method?

Removing complete roles and their auth objects can have a downside...

Cheers

David

[Former Member]

The question is a bit amusing as well, because the intention behind tools such as GRC is to create a more user friendly and intuitive layer for "business job roles" and their descriptions, owners, workflows, etc. All the technie stuff is in the rules which is in a lower level of abstraction from the user so that they do not have to know all the 4000 authorization objects, their myriad of fields and laborinth of values.

What is certainly very easy to perform a simulation of whether any conflicts occur as impact "what if" the change were done. This is sometimes very usefull in catching and identifying low hanging fruit.

You also need to consider that such a role could be very large. A composite role could be many fold larger than vers large. To obtain all the values and write them out to a screen output per authorization (like SUIM reports do) would make the experience for the user and the system rather painfull.

Of course if you have lots of small little roles then it might look nicer... for a short while in the UI... but this is a worst-case-scenario in the long run and maintenance. Is that why you are having "impact" problems from changes?

Cheers,

Julius

[Former Member]

Again, I am not trying to answer "conflict" questions. What I am trying to answer is what happens when we take away a particular role. I my real-world example, I have user that has a role which has 115 TCodes and I don't even know how many authorizations assigned to it. I have been asked to approve the removal of this role, as it is believed to be no longer needed. However, I can't approve this until I know what TCodes and authorizations they will truly lose access to. If they're truly losing access to say 15 TCodes (because we have duplication everywhere) and of those 15 TCodes, only 3 are necessary, then I can say "fix these three and we're good." Similarly, if they're losing access to many authorizations, but those authorizations are covered by similar authorizations elsewhere for the same objects and activities, then I don't care. I only care when they truly are losing access, and even then, I may not care. I kind of like the idea of the SQVI, but that's the best suggestion that seems to have been put forth.

[Former Member]

A feasible possibility is to build roles which are capable of "surviving" on their own without any dependencies with other roles. That way there might be duplications of some authorizations, but so what...

Then make knowledgable people responsible for them as "role owners" who know exactly what is inside them and can identify them only based on their names and descriptions (usefull here is a naming convention...).

--> Make them responsible for the decision to remove the role based on it's description and they do not need to take any responsibility for someone else's role not working as a result because then that other role owner did not test it properly.

You can also point workflows at the role owners in a second step once it is manually mastered...

Sounds feasible to me and you will not be alone in this approach.

Cheers,

Julius

[Former Member]

Hi Justin

I have been asked to approve the removal of this role, as it is believed to be no longer needed. However, I can't approve this until I know what TCodes and authorizations they will truly lose access to.

You appear to be the role owner or co-ordinator of a project to par down access - either as an independant clear out of roles after remediation or prior to and part of a future remediation (yes... I know you aren't referring to conflicts but I'm keeping this wide enouh for others to consider).

Transactions have associated authorisation objects which you are clearly aware of but unsure as to what remains if a role has been removed and you have to explain to the user community that something bad has happened and you didn't expect it.

Removal of roles in a mass clearout should be handled in a controlled environment - the security dept are (or should be) aware of the impact they will have before-hand. If they don't know and are merely removing some roles because the description doesn't appear to match the job they are doing then this could be horrendous.

How are they arriving at their decision?

Is it based on unused transactions over a 13 month period or a 'they won't need that role' approach'?

For you to sign off the removal and then possibly face weeks or months of isolated lost access emails you need the security dept to walk you through their method of working so you are fully aware of the detail that has been put into the work.

I understand you are between a rock and a hard place - get the information in the format you need from them rather than you investigating for the first few changes. If these reflect the impact during cutover/support then you may feel more comfortable. If all hell breaks loose during month end/year end etc then feel free to email your boss and copy in the world.

Good luck

David

[Former Member]

Dave, you've hit the perverbial nail on the head, through and through. It's an independent clear-out before remediation. Decisions are being made on both the period of time (less than 13 months, but at least they're being consistent) and the "they won't need that, based on the description" approach. I am now challenging them to provide me the security analysis so that I can do the business impact analysis. The question that I keep coming back to and asking my security team to answer is:

After this role removal (composite role of 115 transactions), what transaction codes, authorization objects and authorization activities will truly be lost? If the security team can answer this question then I can answer the question of "Will this negatively imact the way these users interact with the system?" My assumption has been that there would be a relatively straightforward way for my security team to execute the security analysis as I have outlined above so that I can then execute the business impact analysis. However, I am getting the feeling that this analysis is not as easy as I have made it sound to be. The UAT would theoretically identify the issues as well, but that does not seem to me to be much different than creating the dummy Z-user as a copy of the real user, removing the role from the dummy user and then comparing the real user to the dummy user as I previously suggested.

I appreciate everyone's continued insight into this issue.

[Former Member]

Again, if the other roles which remain assigned are built in such a way that they can survive on their own and have been tested to do so, then an owner of the role to be removed (try to focus here on the owner of the application data it gives access to) should be able to make such a decision without considering dependencies. This is ideal role design!

An idea for your for the analysis anyway --> report RSUSR050 gives you the possibility to perform a local or a remote user comparison.

- You could copy the user, remove the role from the copy and run the report.

- You could run a remote comparison from QAS with the removed role to PROD with the role still assigned.

- You could take one of the blades out of the DB raid and and make it available to a real virtual system to perform the comparison from.

Another possibility to copy the original user to a reference user (JBUSSCHE --> JBUSSCHE_R) and then take a calculated risk to remove the role from JBUSSCHE. If something goes wrong, then you can assign JBUSSCHE_R back to JBUSSCHE as a reference user for additional authorizations (he then has the access of both users).

I have used all of these approaches and developed user friendly applications to make the decision (and re-instatement of the previous access) available to the user themselves (with workflows, alerts about something having gone wrong, etc).

Typical candidates are missing "basic common functionality" which is often sensible to include in a common role for all users and background job processing running under their user ID's (sometimes from previous jobs they had as they moved around).

Giving them the ability to react and alerting you about it is IMO the fastest strategy with the highest user acceptance for changes.

Lots of options to choose from...

Cheers,

Julius

[Former Member]

Hi Julius

Let's approach this from Justin's perspective...

Justin

Please could you ask your security team if ( and when) they are using transaction SU24 to keep authorisation objects maintained? If they immediately come back to you with a 'yes - we actively do that' then then you have a good start.

Next ask how additional transaction access has been tested - if at single role level using a test user (not a prod user copied to qas) you are closer to the result.

What you need are a set of single role that will work independently regardless off other roles being removed from user.

In reality this usually is a goal - previous testing in isolation using a specific test ID is rare.

The reference user option can be found in the searches and can help enormously If the 'pear shaped' scenarios begin after role removal - used it myself but may unusual outputs...

Best approach is to have a team meeting including the project manager (don't do anything without that person included) and air your concerns fully or you could be left apologising for an indefinate period

Regards

David

Edited by: David Berry on Jan 12, 2011 10:21 PM

[Former Member]

There have been enough tips and tricks to get me through this. I still think that SAP needs an easier way to do this.

[Former Member]

An efficient role design will remove most of the effort in this area. I can understand why SAP would not prioritise an area of reporting that existed to make up for sub-optimal design (oh the irony of that statement).

[Former Member]

I completely agree with Alex when he says:

An efficient role design will remove most of the effort in this area. 

A role must be built in such a way that it can survive on it's own. Otherwise it would be a manual profile..

Exceptions I make are only for very selective "delta roles" whether the business function accepts the responsibility that the access is an "all or nothing" and the delta clearly documents what happens when you have it and any dependencies it might have to give additional access (e.g. see all doc types and the whole balance sheet).

If you have built lots of little task-related which are easy-to-create single roles and now mave to maintain them, then learn your lesson well, suffer galantly and repent...

Cheers,

Julius

[Former Member]

>

> If you have built lots of little task-related which are easy-to-create single roles and now mave to maintain them, then learn your lesson well, suffer galantly and repent... 
>

Unfortunately for Justin I get the impression that he is at the whim of a design that he is not responsible for. In this case I would put the onus on the security team to be providing this information as it is a result of their design decisions.