Security Models 3-Tier Vs 4-Tier

[Former Member]

Hello Security Colleagues,

We are evaluating the two models for our brand new ECC implementation.

We have license for GRC5.3,IDM 7.1.

Would you please share your thoughts/experiences ? much appreciated...

I am also searching for SAP recommendations.

Regards,

[Former Member]

Hi Raghu,

Can you please explain what you mean by 3-tier & 4-tier.

I've worked with various models before & not come across that terminology. If you can define them then it will help some of us who may know them under different names/terms

[Former Member]

Hi Alex:

My forum thread is on security role design.

piece based/task based approach followed till 4.5B ( profile based security).

Later, 3-tier approach followed for security roles from NW.

Now, 4-tier is being evaluated for security roles in ECC.

3- tier

organization level access role, most generic roles for a fucntion module and job specific roles.

It will have master/derived roles.

4-tier

In addition to 3-tier roles, roles with only organization level values...

Hope this clarifies...

[Former Member]

Thanks Raghu,

I won't re-hash old discussions so if you do a search on the term "enabler" with date range = all then you will get a few discussions where we have talked about the pro's and cons of using the Tier 4 approach.

Peraonally I do not recommend it for ECC implementations. There are some notable exceptions to the rule but the majority of implementations I have seen using this have been a disaster from a security perspective.

I would also debate the merit of using a task based approach, if you have a look for a recent thread with "composite" in the title you will get various opinions for and against this method.

Cheers

Alex

[Former Member]

Alex,

Thank you for the advice.

I have gone through the previous thread.

The requirements may drive the decision. In the previous thread, it is for a small business with one company code.

In our case, we have key restrictions 10+ org levels and also considering to use indirect provisioning(position based).

Regards,

[Former Member]

Hi Raghu,

It is the concept that is important. Typically this is used for companies with lots of org levels.

Bear in mind the following:

- You will not be able to run single role level SOD analysis using RAR (actually you will but the results will be meaningless).

- You will break the standard auth concept and every transaction addition will take more work for every addition.

- When you remove a transaction you need to evaluate all the auth objects associated with that transaction to judge if they need removing too.

- You will likely introduce additional risks if you have 1 enabler/org/value role which applies to more than 1 transaction role

- Your implementation will be harder to review/audit. This will increase your audit costs as they will likely need to perform more substantive tests as a result of not being able to check SOD so easy (you could say it is their problem, but it will also become your problem)

- As soon as the originators of the design leave then history shows that the implementation will end up a mess as staff are onboarded who do not understand this method.

- Increased support costs if outsourced.

Out of the many, many implementations I have audited, this concept has left most of them in a complete mess. I don't know if you work for an end user or a consultancy, if it is the latter then it would not be without precedent that your company is forced to pay for a rebuild one or two years after implementation. Very few have done it well.

This is just my 2p based on seeing & fixing it.

Cheers

Alex