Solved: Security design issue

Former Member · ‎2007 Dec 19

Hi,

In the R3 enterprise implementation (enhancement to an existing production system) project we are working on, the development team has a technical specification to assign all custom programs an auth group.

The roles are process based, and we have a set of standard roles which are assigned to all end users along with their designated process based roles. What I have discovered is the standard roles have full (*) access to S_PROGRAM!!

By this, then there is no point in restricting the programs by auth groups, cause the standard roles are going to give access to them anyway!!

What has happened as a result of this is, no SU24 updates were made to the custom Tcodes(associated with the custom programs) for S_PROGRAM, since this object never failed during testing. There must be so many Tcodes which now might need an SU24 update with the proper auth group.

Though we say SE38/SA38 are not to be assigned in Production, we all know it is not always the case. It will be Christmas for anyone having knowledge and access to this kind of security!

Though I feel an object like S_PROGRAM is not the best of objects we need to give all full access, I just want to brainstorm what impacts could it have.

Appreciate your response.

-Abhishek

Former Member · ‎2007 Dec 19

i fully agree that S_program should never be given to endusers.

Would suggest to set up a test environment with all roles/users and in there remove S_program completely from all roles.

Now let functional cunsultants and powerusers test. be around to solve any prolem they encounter imediately in the test environment and replicate teh solution in your dev environment after it was proven to be the correct solution. for the future i wojld rcord all changes, So you can later update SU24, as to me it sounds like testing will behecktic so you will not find time then.

when you follw the aforementioned steps i think you will be able to make the change over, do not worry about the time frame, most important is that you can show that you are working on it, without upsetting the endusers. As in the end of the day you would not want the system to fall down, thus the company not erning money anymore.

Former Member · ‎2007 Dec 19

i fully agree that S_program should never be given to endusers.

Would suggest to set up a test environment with all roles/users and in there remove S_program completely from all roles.

Now let functional cunsultants and powerusers test. be around to solve any prolem they encounter imediately in the test environment and replicate teh solution in your dev environment after it was proven to be the correct solution. for the future i wojld rcord all changes, So you can later update SU24, as to me it sounds like testing will behecktic so you will not find time then.

when you follw the aforementioned steps i think you will be able to make the change over, do not worry about the time frame, most important is that you can show that you are working on it, without upsetting the endusers. As in the end of the day you would not want the system to fall down, thus the company not erning money anymore.

Former Member · ‎2007 Dec 19

Hi Auke,

Really appreciate your answer. I think its a good approach to start with.

The only thing in my mind is the testing needs to be done very rigorously, or else it could cause problems in a live system.

I did propose this, however, this seems to be the lowest priority in heat of all action!

Also, let me know if anything flashes your mind on what impacts this kind of security can have.

Thank you

Abhishek

Former Member · ‎2007 Dec 19

Hi Abhishek,

Security testing is usually low priority unfortunately.

A quick way to narrow down your testing could be to find which of your existing tx are configured in SU24 with S_PROGRAM and get those tested as a priority to get the relevant values. If you test that in parallel with testing your core FI roles and any other mission critical ones then you are hedging your risk somewhat.

Former Member · ‎2007 Dec 19

Hi Alex,

Thats the life of a security guy, live life with least priority during design and testing, and then be in the center seat after go-live.

OMG...this fails....that fails!! .. LOL

What you suggested makes absolute sense to me, its a structured approach to the solution

In fact, right now, I am collecting all custom transactions and fixing their auth group in SU24. Another pain is to re-generate all roles having those custom tcodes to reflect the updated SU24 !

My only fear is capturing auth groups of background id roles. Cause the way its configured, it has ranges in S_TCODE and other objects maintained manually! So it will be a difficult job to find all the custom tcodes in the range, and ensure its auth group is present in S_PROGRAM!

Thanks a lot Alex

-Abhishek

(Am closing this thread)

Former Member · ‎2007 Dec 20

Sorry for the late response, I was teaching SAP Security for a few days.

Yes, testing is allways not considered in the project plan. So it has low priority.

The only way to solve this (in the long term) is make everybody aware (especially management), that if problems arise after the go-live of the roles , it is not your fault as you have been asking for proper testing.

If your management is clever, they will alow proper testing time the next time a change has to be done.

Already now one could declare towards management that proper testing is saving money and reputation of the project! But mostly they will not beleive you!

Former Member · ‎2007 Dec 20

Something that occasionally works is telling them that they have spent £m's on config & customisation but if users aren't tested properly & they can't actually use the system then it's effectively money wasted. Use of poetic licence perhaps but the point is valid

Former Member · ‎2007 Dec 21

Thats true

Am trying my best to get this registered in their minds 😛

Thank you both. I appreciate all those valuable points you have raised.

-Abhishek