Post Upgrade: Search for New Authorization Checks Implemented and Impact

[nabheetscn]

Dear Experts

We have a situation and would need your help in resoling it. After an upgrade usually SAP add new authority check statement in function modules/programs/includes etc. Now those function module might be used by different standard/custom transactions.

Now do we have any tool builtin which can help us identifying clearly which all tcodes/reports(standard/custom) have got impacted because of the new checks being introduced.

What we tried at our end from technical side

We identified the change by searching for string Authority-Check statement in all programs and comparing with our non upgraded version.  We found the location of Function Module. The where used list of funciton module leads us to 100+ includes/programs which in turn leads us to more places. It kind of becomes like a infinite loop leading us nowhere.

So how are we taking care of such situation in different upgrades?

Thanks in advance for all the help provided.

Thanks

Nabheet

[Former Member]

The intended way of doing this is to run the upgrade steps in transaction SU25. These are as good as what SAP maintained SU22 content accurate and the quality of your roles for the corresponding transactions to correctly propose the new and changed authorizations to those roles.

In practice this does leave some gaps to be filled, sometimes very big ones...

We built our own tools in the end to complement the standard ones, GRC (which makes assumptions based on SU24) and enhance Z-transaction proposals for customers own applications.

The trick in the code scanning part is to know whether you already scanned the object or not so that you don't get stuck in a loop and to start the scan from the top of the call-stack as the start of the transaction needs to be remembered to work out what to tie the change in authority-check back to.

If you can also bolt-on to functional testing going on as a part of the upgrade, then there are some nifty tricks to combine the authorizations testing passively or actively with these other tests going on.

To cut a long story short: you have opened a can of worms and there is no easy answer to it. 🙂

Cheers,

Julius

[Former Member]

Hi Nabheet,

I find your concern great. I think your point is one of the biggest SAP Security problems when patching.

I sincerely don't know any SAP tool to do that, however I think your internal technical process was correct. I think that is the right process, but highly expensive...

I don't know how often SU22/SU24 are updated, but I am not sure if I fully trust on them (yes, I am very skeptical ). The real authorization check is in the code, so in your position I would have done the same process.

I think this is a very interesting topic, how are other companies doing this? I mean, are they proceeding by trial and error (a very valid approach) or are they doing any other kind of analysis as Nabheet did?

Cheers,

Sergio

[Former Member]

SU24 works only for Tcodes? I just tested it with RFC_READ_TABLE and BAPI_USER_CREATE1 (RFC_FUNCTION_MODULE) and no authorization objects showed up...

[Former Member]

If you get the right mix of high quality roles from the start (only via menu and standard or maintained status) combined with a well maintained SU24 and tools to analyse the changes, then you can easily upgrade SU25 and your roles in 1 day.

I do this regularly  - so it is possible and also easy even once you have done it a few times (properly).

However... there are 2 big restraints / show stoppers / performance optimizers:

1) If the roles are not menu based or not in sync with SU24 before the upgrade (changed and manually status authorizations, and merging brings in new status objects), then the mess only gets bigger with SU25. You normally are better off by starting over.

2) You have to be able to compare the transaction execution or code scanning to the available SU24 data to find the gaps. This was the point where I built my own tools for it.

As an additional note which is important: it is worth looking into transaction SACF for the control framework for adding authorization checks which are downward compatible and need activation if wanted.

If the quality of your role design and SU24 is good, then it is a breeze to upgrade from anything 7.00 based to current releases (7.50 / EHP8 / S/4 HANA / etc).

Cheers,

Julius

ps @ nahbeet: from / to which EHP or release are you upgrading? Can you provide us with some statistics on your roles?

[Former Member]

Yep, it works for several object types and the majority of them can be added to the menu in PFCG (not just tcodes).

These "other object types" such as RFC and WYDA are my main motivation to find better ways to find accurate information sources to maintain Su24 for these objects and build role menus based on the "application start" object actually used.

If they are complete in the menu, and SU24 is well maintained, then an upgrade only needs to trap the delta missing in the role and ideally even trap the delta missing for the SU24 proposal even if it is in the role -> complete "where used lists".

But it is easier said than done and requires some puzzle pieces to be in place in the authorization concept (role design and SU24 maintained beforehand must be intact and not a brain-**** from the past...).

Cheers,

Julius

[Former Member]

@Julius are you using the same process when implementing SAP Security Notes? I mean.. many times SAP Security Notes add new authorization checks. Do you know if following your procedure for notes (not support packages), SU22/SU24 will be updated too?

Cheers!

[Former Member]

Yep. In fact in the case of SNOTE implementable corrections, you can scan the SNOTE changes before you implement the note -> a code scan is just a READ REPORT of the source text into an internal table of the program doing the scan. Via SNOTE you can download the source corrections and append / insert them into the internal table of the source they are correcting, and then use the scan patterns to look for statements.

So you can compare unpatched code to patched code and see what the difference is and then view these differences from various perspectives, including SU24 "view" of the differences.

Cheers,

Julius

[nabheetscn]

Dear Julius/Sergio

Thanks for the valuable comments. The upgrade in our case has been done including the regression testing.

One of the scenario where we had the big issue was related to batch master.  One of the custom report which was related to batches creation and was using function module VB_CREATE_BATCH had added a new authorization check at a very deep rooted level.  During testing of this in quality the Functional Expert had more authorization so no issue was reported But sadly the moment it went live it affected everything.

I am sorry but i did not understand how SU22/SU24/SU25 etc. would have helped in such scenario( please bear with my limited knowledge related to Secuirty )?

Seconldy I am thinking purely from a developer point of view, do we have tool which clearly highlights even if we missed in testing, that so and so tcodes/reports are impacted?

Thanks

Nabheet

[Former Member]

Well.. in the case of custom code, SU25 will not help you because SAP will not deliver anything for your custom transaction proposals. At most you would be able to reuse some proposals for BAPIs, if they had proposals and you were using a BAPI - which is not the case.

So yes, your options to spot this sort of thing is either:

1) Testing - despite having missed this opportunity in the regression testing you should still point out to the "functional expert" that testing an application should be done with authorizations to use the application correctly. It is also a part of the test, otherwise this sort of thing will happen. You must provoke the error by getting someone to execute the code with the correct authorizations for it.

2) Code scan - there is however no standard tool in SAP which will deliver this information about authority-checks which changed between two versions of the same program. I also had a discussion with the developers of SAP's "Vulnerability Scanner" tool and authorizations with SU24 connection are not in scope or focus. They are too close to the application itself and not a technical defect or vulnerability per se.

So we built our own tool for it to scan a call-stack for such things starting at the top object being a role, without having to execute the code in a test. There was no other way of doing it - or at least we could not find one nor any tool on the market capable of such an analysis.

Disclaimer: it is not freeware, so you would have to contact me offline or via "Direct Message" if you are interested. SCN is not a platform for commercial topics.

Cheers,

Julius