SU24 not Maintained

[Former Member]

Hi,

We recently started a GRC project to implement CC 5.2 but found that the SU24 data is not maintained . Having said that , will it be enough to just take the existing data from the USOBT_C table , or do we need to first bring up Su24 to the latest authorization settings from the roles and then go about the CC processes.

Please advice on the best practices on updating the SU24 data in a post production environment. We are already on a LIVE system and SU24 changes now could have a significant impact on the security roles and users . right??

Thanks

Meer

[Former Member]

Hi,

We recently started a GRC project to implement CC 5.2 but found that the SU24 data is not maintained . Having said that , will it be enough to just take the existing data from the USOBT_C table , or do we need to first bring up Su24 to the latest authorization settings from the roles and then go about the CC processes.

Please advice on the best practices on updating the SU24 data in a post production environment. We are already on a LIVE system and SU24 changes now could have a significant impact on the security roles and users . right??

Thanks

Meer

[Former Member]

SU24 changes will have a significant impact. Any change in SU24 will mean that the affected roles will have to be "updated" by regenerating them so that the new default values in SU24 are accounted for. And consequently would probably mean that the security roles would have to be re-tested.

[Former Member]

JC,

Thanks. Thats what I thought would be the direct impact of not maintaining the SU24 data.

But do we have any recommendations on how to aproach this issue

I will not be surprised to find many clients where this is a problems

Please let me know

Thanks

Meer

[koehntopp]

Unfortunately this observation is true - very few customers use or even know about SU24.

This is why I would like to point to Julius' and Alex' excellent blog post on the topic:

/people/julius.vondembussche/blog/2008/04/19/how-to-get-hit-by-the-abap-authorizations-bus-and-survive-to-tell-the-tale--part-1

Understanding and using SU24 is crucial to a successful authorization management. Actually, I think it's the only way to stay in control. If your roles have many manual or changed objects, you will have huge efforts to keep control of autorizations.

If you're not using SU24: it's never too late to start.

Frank.

[Former Member]

Yes, it is better to implement SU24 if it has not been done. The blog Frank referred to is quite good and helps you to understand how SU24 works. The only thing I could recommend is to carefully work out a plan for making the changes. The changes to SU24 itself may not be so significant compared to the extensive role changes and testing that will have to come with this. On top of this, there may be impacts to any kind of SOD tool that you may be using.

[Former Member]

Great, you are correct that this is the case at a lot of clients.

We currently have around 80 custom tcodes in production ,which even more to the impact of not maintaining SU24.

What are some of the common solutions to this to update USOBT_C from a GRC perspective??

Also what if we dont update SU24 . How big is the impact on the SOD analysis ? How is the USOBT_C used during the SOD runs??

Thannks for all the inputs this far

Meer

[koehntopp]

First of all, your custom TCodes must be included in the suitable Compliance Calibrator Functions in order to be detected in SoD analysis.

If you haven't maintained SU24, this means CC will not be able to identify the objects that go with these custom transactions, which may lead to false positives in analysis.

This is ignoring the fact that not maintaining SU24 will make it harder to include those transactions in roles, as you have to add the objects manually. When you remove one of the custom transactions from a role, those objects will not be automatically removed, either.

So, again: please maintain SU24, it's the best way to stay out of trouble.

Frank.