topic Re: Wanted: Security Architecture perspective ... in Application Development and Automation Discussions

Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 15:01:12 GMT

Hi guys,

I'm faced with a problem regarding security architecture and I need your input.

In order to design an effective security model, I've conducted workshops and have captured transactions that are required by the business, grouped those transactions into logical tasks by involving the business leads and the functional leads, and currently have this task to transaction list. My plan is to proceed with mapping SAP role names to these tasks, doing a 3 tier role setup, with level 1 roles being display, level 2 being job roles and level 3 being admin roles. In addition, I have system admin roles for BASIS and security.

The PM on the project says my plan sucks. He insists that I should copy SAP standard roles and just use them because they would be quicker and easier to use.

Frankly, I disagree - they'd give far too many authorizations and considering that the client's business can't be mapped to the SAP standard roles, it would be a misalignment from the outset. But he won't buy my logic - he's leaning on some prior experience. As a background, this PM is a Hyperion FICO guy, or something like that - he's not an SAP person.

When I thought about it, I didn't have an overwhelmingly convincing reason for not doing the copy SAP standard roles approach.

What do you suggest? Does my plan suck, or would you think it's pretty ok?

Santosh

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 15:22:13 GMT

Hi Santosh,

I agree with you and the roles should be setup with plan like you did with your team in workshop.

This is my opinion.

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 16:00:54 GMT

Hi Santosh,

You are right & your PM is wrong. Between us I think we could write a book on why that is the case.

Cheers

Alex

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 16:04:04 GMT

Hi,

In my opinion copying SAP roles is easier project.

Although you took requirements from leads,in future they may come up with more tcodes which you will need to again add in appropriate roles.

But if you use SAP roles, you wil have all related tcodes already in roles.

Hope this helps

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 16:10:25 GMT

Trupti,

Thanks for that input. In some sense, the PM is making this argument. However I have some very fundamental issues with this.

1. Key business transactions have been captured in my model

2. Additional transactions have largely been captured as well through additional workshops and analyses

3. The client company org chart and hierarchy can't be easily mapped to the SAP roles without having to break up the roles into smaller chunks, re-organize the roles, or dive into the auth object level.

4. The client has org level restrictions that have to be considered

5. There is a lot of overlap in client employee responsibilities that internal controls have to consider

How do you address these issues when you copy the SAP roles?

Santosh

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 16:21:56 GMT

If you are creating roles from scratch, you will have to put in efforst to give org level values as SAP wont give that in their roles.

in some cases i do agree you need to break roles(but this is in some cases)

advantages

1.you won't have to think much on name of role, you can give related to to what SAP has given in accordance with your cusotmer naming policy

2.You won't have to insert in whole lot of tcode manually if you copy roles

3.appropriate values will also be maintained by sap

4.You will save lot of time and resources which should be crucial factor in an implementation project

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 18:35:36 GMT

Santosh,

From my perspective its always a better approach to not use the SAP roles for Production Access. Your approach is one I typically follow and allows to keep key security concepts such as "Least Privleged" and "Risk Based Approach". The SAP roles generally have open access and dont fit the clients needs. I agree there is a time/money issue here but in the long run you have a better/secure role design and approach for the business.

Thanks,

Matt

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 18:39:44 GMT

> 1.you won't have to think much on name of role, you can give related to to what SAP has given in accordance with your cusotmer naming policy

If you have to "think much" to come up with a naming convention then you shouldn't be working on a role build.

> 2.You won't have to insert in whole lot of tcode manually if you copy rolesThe t-codes will be wrong. Why copy wrong t-codes? Compare SAP business roles against what people execute. They often have maybe 20% commonality

> 3.appropriate values will also be maintained by sapThey will be as appropriate as that in SU24. Make of that what you will.

> 4.You will save lot of time and resources which should be crucial factor in an implementation projectAbsolutely not the case. You will have a poor role build that will not be designed to meet the customers business process requirements, support requirements, risk requirements. You are delaying implementation cost until a later date when someone has to come and do the job properly. The crucial factor in an implementation is that the job is done properly and balances meeting requirements with TCO.

The SAP delivered technical roles are pretty good, their business ones are poor. This is not just my opinion, but that of the majority of people who implement security.

When I see a customer implement SAP with absolutely no change to the processes out of the box then I will recommend they use SAP Standard roles. When they use configuration to make SAP work and do what they want then I will recommend that they develop roles to meet those requirements. By all means refer to the SAP roles, but using them as a basis for a role design will be giving the client rubbish.

Edited by: Alex Ayers on Mar 31, 2010 7:40 PM

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 21:01:51 GMT

For a start, I have more questions than answers... sorry

1) Is it a new installation, or is legacy stuff which is hard to cure involved?

2) Are the business processes alligned for the org values available to you?

3) Are there any org. charts available for what folks should be doing in the system, do they represent reality and exceptional Mr. and Mrs. so-and-so are there who have special access or tasks based on their person and not their job position.

4) How much time do you have and how skilled are the folks building roles to do some of the up-front work so that the business key users do not go into a frenzy or panic in Excel.

These are very important questions which you need to clear up-front before making decisions.

It may be that you will achieve the same level of security much faster using SAP standard role copies with some tweaks in the menu and SU24, than what you will by making it tailor made.

Worst-case scenario is to purchase out-of-the-box ready made little single roles without an Su24 set to match them, and then it is your job to design composite roles from these "building blocks". This dictates your business processes to you and will over time create a big mess once you have paid the bills.

My 2 cents,

Julius

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 21:15:19 GMT

Dear Mr. Bussche:

The answers are:

1) Is it a new installation, or is legacy stuff which is hard to cure involved?

It's a new installation. The client is moving from Great Plains to ECC and SRM.

2) Are the business processes alligned for the org values available to you?

Not really. They have some overlap in their business processes, and they have only company code org level restrictions that are required.

Nope. When asked, they gave me their Great Plains roles. Unfortunately, that wasn't useful because it suggested monolithic roles, which I didn't feel would be a good idea.

4) How much time do you have and how skilled are the folks building roles to do some of the up-front work so that the business key users do not go into a frenzy or panic in Excel.

Excel panic happened. It was dramatic. There was some confusion on how to sort data, and that the same spreadsheet could be sorted and that didn't make it a different spreadsheet. Once we got beyond that, I got them to define tasks that each area identified, and had them assign transactions to those tasks. I'd like to think it has been successful because it covers a lot of tcodes and seems to represent their business need properly.

As far as your question on "folks building roles" - they have one guy who's been to ADM940, and he has an excellent blank stare. Besides, him, there's me. This encourages me to give as much access as possible (to keep his life simple), but the controls folks want it locked down.

Now here's the sanity check that I performed. Based on the transactions that I've had them group together as logical tasks, I did a quick MS Access join against the AGR_TCODE dump from ECC for the SAP roles. I found that using SAP standard roles wouldn't be a good idea from a time effectiveness perspective simply because there is far too much analysis involved. Either that analysis would have to be done, or I would have to get the business folks to simply pick roles that they think are acceptable, and I don't like either of those options.

Besides, don't you guys script the role creation? I sure do ... but apparently that's not done by many security folks.

Let me know what you think.

Santosh

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 21:16:52 GMT

> If you have to "think much" to come up with a naming convention then you shouldn't be working on a role build.

I think you missed the "small print"...

> you can give related to to what SAP has given in accordance with your cusotmer naming policy

It is very usefull to first know how the roles are assigned and what they will be looking for, before designing the naming convention.

If there is decentral role assignment based on org. units, or "global" responsibility areas for business processes, or even a classification of access based on a tiered "level" indicator... then it is very necessary to consider this -also for making the search easier (of course keeping the number of roles down to a minimum helps, but in specific name spaces they might explode into the thousands.

I must confess that I have thought a lot about this when considering naming conventions, but the main problem still remains enforcing them.

For this there is however a usefull table in the STMS which can block exceptions for specific (classed as critical) object types and names - they cannot be transported. I have a variant for RSUSR070 which reports them to me -here you have more flexibility in the selection options than what you do in authorization fields. But again, I confess that it is not endlessly scalable.

Well built single roles: The way to go!

Cheers,

Julius

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 21:50:42 GMT

You think (and type) very fast...

The break-point is here:

> Excel panic happened. It was dramatic. There was some confusion on how to sort data, and that the same spreadsheet could be sorted and that didn't make it a different spreadsheet. Once we got beyond that, I got them to define tasks that each area identified, and had them assign transactions to those tasks. I'd like to think it has been successful because it covers a lot of tcodes and seems to represent their business need properly.

They are picking tcodes from an F4 list offered to them? Or some one else is picking the tcodes for them. How involved are the functional consultants? - are they delivering the transaction contexts in their blueprint with the authorization values needed and the ones to be restricted for some functions, at application object level? (implication = more roles).

In all honesty and between just the two of us... I would consider a copy of SAP standard roles (depending on your time lines).

If you have the clout and time and the infos are not delivered, then escalate it.

You should not be a bottle-neck for the project, but at the same time the security requirements need to be met.

If the PM mentions Area Menus then let us know...

Cheers,

Julius

Re: Wanted: Security Architecture perspective ...

Former Member — Wed, 31 Mar 2010 23:18:45 GMT

Hi Julius,

No, they're not picking from an F4 list. What they're doing is reviewing a list of transactions that the functional leads have compiled from their config workshops. In other words, there's an initial set of transactions that have been determined by the functional leads and the BPOs.

I also have lists from my previous projects that associate, logically, transactions that go with specific tasks.

After reviewing this information, they've determined which transactions need to go into which task - in other words, they're not picking transactions, they're associating transactions with a task name (e.g. CO Internal Order Create).

As far as the object level stuff goes, it's mostly straightforward except for org levels.

Santosh

Re: Wanted: Security Architecture perspective ...

Former Member — Thu, 01 Apr 2010 07:12:26 GMT

> > If you have to "think much" to come up with a naming convention then you shouldn't be working on a role build.

> I think you missed the "small print"...

> > you can give related to to what SAP has given in accordance with your cusotmer naming policy

Just a slightly different interpretation

> It is very usefull to first know how the roles are assigned and what they will be looking for, before designing the naming convention.

Absolutely. I am always suspicious of a naming convention or role design that is preconceived before requirements have been gathered and support and provisioning processes identified.

Re: Wanted: Security Architecture perspective ...

Former Member — Thu, 08 Apr 2010 13:59:40 GMT

My model of building roles based on the client workshops, and then expanding it as needed, rather than copying the SAP delivered roles is gaining acceptance with the client as it (really) makes sense to them.

Thanks for all your comments and help.

Santosh

Re: Wanted: Security Architecture perspective ...

Former Member — Thu, 08 Apr 2010 14:38:28 GMT

That's good news Santosh. Have fun with the build!