RICEF Security - best practice to develop security specs

[Former Member]

Good Morning All,

We have new ECC implementation kicked off, my question is how RICEF security is controlled? What are the standard guidelines practised in industry?

We are encouraging process teams to start use authorizations checks in custom transactions where ever necessary, ABAP team says this is in discreation of BP, ABAP will enforce checks if Business Process(BP) ask.

I not sure if BP will take that extra time to think on authorization checks for RICEFS, we security team offered help to BP saying we can help on finding appropriate auth objects for their RICEF objects.

As we cannot really enforce this or push hard, I am trying to think what is best way to get this in place.

What I think is for some custom tcodes, which are low risk reports there is really no need to induce 2nd level check(1st level being S_TCODE) but my concern is this should not be taken for granted.

I would like to hear suggestions from group.

Thank You.

Edited by: Julius Bussche on Apr 22, 2011 5:46 PM

Subject title made more meaningful.

[Former Member]

Good Morning All,

We have new ECC implementation kicked off, my question is how RICEF security is controlled? What are the standard guidelines practised in industry?

We are encouraging process teams to start use authorizations checks in custom transactions where ever necessary, ABAP team says this is in discreation of BP, ABAP will enforce checks if Business Process(BP) ask.

I not sure if BP will take that extra time to think on authorization checks for RICEFS, we security team offered help to BP saying we can help on finding appropriate auth objects for their RICEF objects.

As we cannot really enforce this or push hard, I am trying to think what is best way to get this in place.

What I think is for some custom tcodes, which are low risk reports there is really no need to induce 2nd level check(1st level being S_TCODE) but my concern is this should not be taken for granted.

I would like to hear suggestions from group.

Thank You.

Edited by: Julius Bussche on Apr 22, 2011 5:46 PM

Subject title made more meaningful.

[Former Member]

It is unfair on the developers to expect them to invent requirements, but a good one would make suggestions if interaction is possible with the end user / customer. Often it is not...

The best tactic IMO is to find a document which the BP actually use and take seriously for requirement communicatiin.

Add a section to that for application security and authorizations requirements. If you give them a "same as transaction XYZ" option they can relate to, then they will have more "ah-ha" moments and give you the infos.

If you ask them to design custom auth obkects with custom fields and custom check tables, then only the "trouble makers" will send you lots of requirements...

Good luck,

Julius

[Former Member]

Hi Julius - Thank you for the suggestion.

Per your advice, we already have a section for Security Authorization check in functional spec, expectation is when functional guy request for Custom Transaction (for RICEF), they have to ask for authorization check(Organizational/ activity level) as for now they are leaving blank as they think no greater level check is required.

ABAP team does spec review and approve for development, so neither Security or ABAP can take a call on this. It's primarily business/process team call.

My concern is process team will ignore this as they dont want to add any extra work for them though security offered a helping hand.

What guidelines you follow for RICEF security?

Thank You.

[Former Member]

If the custom programming uses APIs, then most checks will be there anyway.

I would add a bold note to the section stating that if there are no security requirements given, then anyone can access / process the data. Then give them an intuitive option to re-use existing concepts by selecting a "same as ..." drop down.

Or make it mandatory, and if they do not want to spec the security then they have to fill out some very long questionaire to request approval from the auditors...

Retro-fitting security is very expensive, disruptive and error prone. You can also show them that.

Cheers,

Julius

[mvoros]

Hi,

in my experience people (developers as well as business process guys) don't care too much about security. Their job is to make it work and security is very often seen as a barrier. Classical example is this RFC user needs SAP_ALL because it's too much work to formulate what we will use it for. So if you believe that your developers are capable of doing basic security checks (unfortunately, this is not always true) then you can try to give them a training. Otherwise you can make obligatory that each spec must be signed off by somebody from security. This can lead to a quick chat (not meeting, meetings are never quick) when security guys ask questions like: Same security restrictions as in ME23N? and so on. Basically, same what Julius proposed. with Same as dropdown option.

BTW a quick training for developers about the basic things like objects S_TCODE and S_DATASET is a good idea regardless your issue.

Cheers

[Former Member]

Their job is to make it work and security is very often seen as a barrier

This is very unfortunate but often true Security can however also offer cool solutions to spagetti code and defunct requirements!

As you correctly state, the reason is often lack of training, awareness and being under pressure from deadlines and complexity. I also suffer under this but have with time learnt that "right first time" is the best way.

The ideal solution IMO would be to integrate the authority-check statement into both the external and internal license meaurement.

- A program without any authority-check is freeware because anyone can run it.

- A program with a display auth check run by a user with display authorizations costs 1 cents each time.

- A program with change / create checks run by a user with change / create authorizations costs 2 cents each time.

- A program with delete checks run by a user with delete authorizations costs 5 cents each time.

- Any program with any checks run by a user with FROM --> TO ranges in authorizations costs 20 cents each time.

- A program with a display auth check run by a user with SAP_ALL costs 100 cents each time.

- etc...

This way, developers will add as many appropriate checks to their code so that it generates revenue from the application. Business process owners will try to restrict the authority-checks to only those really needed and will restict authorizations as much as possible to exact values when testing their roles.

Would work like a charm... but I'm sure there is a catch somewhere...

Cheers,

Julius

Edited by: Julius Bussche on Apr 24, 2011 12:07 AM

[Former Member]

Hi Julius & Martin - Thanks very much for your suggestions, you guys got it right:

1) Developers understand authorizations checks should be in but they will program it if they are asked by process teams.

2) Because of deadlines and project pressure, process team some times skip security section to save some time.

Does each RICEF needs Security auth. check? We do S_TCODE check, do I need to go second level check like activity/Org?

1)When I spoke to ABAP, they say that for "Enhancements", Security team should not be worried much as it's primarily User exits.

They agreed on creating authorization class for custom tables so that we can do our check in S_TABU_DIS.

2)For Conversions and Forms, ABAP say there is really nothing much for security checks.

In my previous experience, I never did something like this, my check was always S_TCODE, I use to put ZTCODE in role menu which means if user needs access it should be in role there ends the story.

Julius - Can you elaborate little on what you meant by

"Then give them an intuitive option to re-use existing concepts by selecting a "same as ..." drop down"

Martin - How you guys handle Security for RICEF, can you tell me for each (R, I, C, E, F)

Sorry guys asking too much, please don't mind bit new to the concept and in learning phase.

Thanks very much again.

[Former Member]

The developer should know where and how to integrate the security (training)... but the business person and functional consultant will generally only know transaction codes and tables.

Give them the option to choose the security scenario "same as" tcode ME23N and then the developer will know that if using the BAPI the checks are native. If locally ME23N has additional checks, then those might be required as well.

Interesting reading is also the "enhancement framework" and particularly the "switch framework". Educating the developers about this is very usefull for them as well, as they can localize their code and selectively test it against the standard code (particularly in the case of "exit" type or deviations from standard concepts in custom RICEF functionality).

Unfortunately a lot of Z* code in customer systems is written without documentation and the developers are long gone. No subsequent developer will easily want to maintain it on a voluntary basis, as such changes are very error prone. Same goes for restricting authorizations of a RICEF type user when they have always had SAP_ALL...

Get it right first time is the best solution IMO with co-operative developers and BP given a user friendly interface to the technical underworld.

A good project manager also helps.

Good luck,

Julius

[mvoros]

AJ,

basically, I agree with your development team.

R - on current project all functional guys write brief note about authorizations for each spec. Usually, it's just reference to standard SAP transaction. So basically requirement like user who have access to ME22N will be able to use this custom report to modify selected POs. So obviously, developers need to figure what standard objects are checked in ME22N.

I - not sure yet but I guess here they will try to cheat and say use SAP_ALL.

C - usually conversions are run using special user and using standard BAPIs to there should not be too much additional checks.

E - usually original authorization model of transaction is enough. There is sometimes requirement to enhance authorization model but security is always involved in this.

F - usually no need for additional checks.

Cheers

[Former Member]

I believe BP for custom Z transactions is, if it is a change Z transaction, it should have an additional (2nd level) object assigned. To our colleagueu2019s point, the business does not understand objects, but they may be able to describe which transaction it is most like and what it does.

Then go to SU24 and look up the transaction they named and see what objects SAP identifies as default check/maintain and at change value. Choose one of those objects that make the most sense compared the description of similar transaction and this Z tcdu2019s usage the business owner described. Maintaining Z tcodes in SU24 will also pull in object association into PFCG wherever that Z transaction is added.

One of the biggest reasons this should be done is that SOD/SOX apps can better identify if this is part of a critical combination or Segregation of Duty Compliance issue. Conversely, it could be considered side stepping or bypassing SOX compliance requirements if object and value is not identified and maintained in SU24.

Good Luck,

- Randa

[Former Member]

Hi Randa - Yup, I am going strategize in simillar lines. Actually our concern is more on encouraging BP to follow this best practise, most of the times it's security who takes the hit if the project timing turn yellow/red.

Thank you very much for participation.

AJ

Edited by: AJ on Apr 26, 2011 8:55 PM