Advice needed: what does your company log for SAP security role changes?

[Former Member]

My client has a situation where for many years, they never logged changes to SAP security roles. By that I mean, they never logged even basic details, like who requested a change, tested it, approved it, and what changed!! Sadly their ticketing system is terrible, completely free-form text and not even searchable.

Does anyone here use Word docs, Excel sheets, or some other way to capture security role change details? What details do you capture? What about Projects, that involve dozens of changes and testing over several months?

I plan to recommend, at least, they need to use a unique# (a ticket#, or whatever) for every change and update the same in PFCG role desc tab, plus in CTS description of transports... but what about other details, since they have a bad ticketing system? I spoke with internal audit and change Mgmnt "manager" about it, and they are clueless and will not make recommendations. It's really weird but they will get into big trouble eventually without any logs for security changes!

[Former Member]

A few things that we do to have a tracelog or Change Management for security roles are...

1. Update the Description tab with the details such as Date, Ticket/CR number, Who made the change and 2-3 words on New tcode/objects etc so that consultants know what was the last change performed on the role and by Who.

2. Update the CR/Ticket number in the TR description to make sure it is searchable in STMS or SE03 on AGRS searches.

3. If the Client has SOLMAN, CHARM can be used to move changes across landscape and Test scripts etc can be attached to that ticket to have traceability...

With the background given, it would be a tough uphill task to convince them to follow proper CM process. May be Solution Manager implementation can be their best bet or a better Ticketing mechanism should be religiously followed...

Hope it helps.

~Sri

[Former Member]

Thanks Sri. What is included in the ticket? Are certain mandatory information, like Sec.Manager approval prior to development, SOD scan results, impact analysis, etc? Are all details contained in the ticket?

I agree it is uphill battle here. Probably they will settle for bare minimum logging. But I need to advise them what is such a bare minimum. I wonder if others have worked in a place like this.

[Former Member]

Yes, A few things that go in as attachments are as below.

1. SOD Results - To make sure the role itself is violations free.

2. Approval from Role Owners (If they exist) - Else Security Manager Approval for Change

3. Functional Consultant - Test Results and Subsequent Approval to move changes to PRD.

Apart from this initial while raising the ticket we make sure the SU53 screen shots and the procedure to replicate the issue are clearly mentioned in the ticket, This helps in resolution and makes it easier to decide if the issue is a Bug fix or a new change.

So Bugfixes follow Incident -Ticket route and New changes follow a Change Request Route.

~Sri

[Former Member]

The ticket should contain the observation for the request, troubleshooting done so far & why the change was suggested needs to be documented ( including the SU53 and trace log if applicable ). The rest have been duly referred by Sri.

Regards,

Dipesh.

[Former Member]

The skills and discipline of the role administrators are more important than the rubber stampers IMO.

For example, if someone is making the menu look nice but then using "edit old status" then no pile of detailed request forms and approval emails will help you to put the roles together again.

Rather audit the roles for quality in the build and maintenance. For SOD and critical authorizations you can automate the checks and add workflows etc without paralizing the maintenance process. This is more pragmatic as well as realistic.

A role request form mentioning tcodes without the status nor the standard proposals for it is a statement in itself about the process if there isnt a request form for SU24. Imagine a request form for SU25 step 2b..

Cheers,

Julius

[Former Member]

Thank you everyone.

I will certainly suggest they use a ticket for every change, and populate the free-form text with standard information like what was presented here. I'm still not sure how they are going handle projects.

@Julius: I think your idea about auditing roles for quality during build & maintenance is excellent... but practically, how have you seen this done? My client amazingly has a situation where transports are automatically imported into QAS after release, so it's not even possible to apply a check gate such as "approved for QAS by Security Manager". I am struggling to find a way to control the work of all the security developers (who are spread around the world) to provide this kind of useful oversight. Can you offer some suggestions based on your experience?

@Shrinivasan: I wish we could implement GRC10 or ERM.. But that would take months and $$$ and I want to help these people now... thanks for mentioning it though.

[Former Member]

The problem is that lots of chickens make lots of $h!t and no one has time to go checking all roles all the time.

So together with a colleague of mine we built a ABAP tool which we use on our projects to keep an eye on the roles for all sorts of naughty things and optimization opportunities. It can also be run as a job and there is a BAdi in the CTS (Stms & Co.) from which you can run checks (such as this or code scans) when someone attempts to release a transport with a role(s) in it. This also helps to keep the sequence of the role transports correct when releasing them.

We are currently looking into making a public version of it freely available. You can see this at TechEd in Madrid next week already if you are there.

Cheers,

Julius

[martin_voros]

> We are currently looking into making a public version of it freely available. You can see this at TechEd in Madrid next week already if you are there.

Looking forward to this release.

Cheers

[Former Member]

The mentioned scenarios can be well maintained if you use SAP GRC Solutions 10 (Business Role Management)

Task Based, Approvals, Risk Analysis, SOD and role generation and maintenance in a structured way (Business Role Management).

Workflow based, staged process with approvals.

PFCG transaction usage will be curtailed to minimum if implemented fully.

[Former Member]

The mentioned scenarios can be well maintained if you use SAP GRC Solutions 10 (Business Role Management)
> 
> Task Based, Approvals, Risk Analysis, SOD and role generation and maintenance in a structured way (Business Role Management).
> 
> Workflow based, staged process with approvals.

The theory is nice

> PFCG transaction usage will be curtailed to minimum if implemented fully.

I will believe it when I see it.

[OttoGold]

Does anyone here use Word docs, Excel sheets, or some other way to capture security role change details? What details do you capture? What about Projects, that involve dozens of changes and testing over several months?

I have questions:

a) Do you want to make things straight

b) Do you want to implement a versioning mechanism

c) You cannot implement anything technical, but you`re asking about best "paper" practise?

The mentioned scenarios can be well maintained if you use SAP GRC Solutions 10 (Business Role Management)
Task Based, Approvals, Risk Analysis, SOD and role generation and maintenance in a structured way (Business Role Management). Workflow based, staged process with approvals.
PFCG transaction usage will be curtailed to minimum if implemented fully.

Do we really want to do things "outside" PFCG?

@all:

a) do you guys use custom approval workflows for roles?

b) how tight your processes are? how much paperwork, workflow, tickets, requests and incidents you have to go through to change a role?

c) who is a friend of GRC here, raise your hand

Cheers Otto

p.s.: very interesting discussion, I would like to learn something here about how it works out there in the wild

[Former Member]

> @all:
> a) do you guys use custom approval workflows for roles?
> b) how tight your processes are? how much paperwork, workflow, tickets, requests and incidents you have to go through to change a role? 
> c) who is a friend of GRC here, raise your hand
> 
> Cheers Otto
> p.s.: very interesting discussion, I would like to learn something here about how it works out there in the wild

Hi Otto

a) I've not used this for a long time (I once worked on a project where a custom solution was used). I can see the benefits in some situations.

b) That really depends on the client. Some have lots (especially the FDA and SOX mandated clients), others have much leaner (but not necessarily less effective) processes. Much if it depends on the company culture, the support organisation and the ownership and approval model.

c) GRC has it's place & I am definitely a fan. However I make the big caveat that you can do good and effective security without the use of a toolset (it will just take longer to do some things).

[Former Member]

Thanks everyone for responding. It's just too wild here to control properly. Now they finally log tickets for every change and tracking basic approvals, but there is no easy to apply a quality gate for a manager to review the contents of any transports and check affected roles for quality. Some times the manager doesn't even know that a developer created a transport and changed a role (and closed the ticket). Some times the manager doesn't even get added as approver for production change request. It's crazy.

@Julius: can you please announce on this forum when/how your program is available. It sounds awesome!

[Former Member]

One way of dealing with this is that the developers only release their tasks and the request itself is then only approved and released afterwards.

I will keep you posted. The TechEd presentations are normally made available on SDN (at least they were in the past).

Cheers,

Julius

[Former Member]

One way of dealing with this is that the developers only release their tasks and the request itself is then only approved and released afterwards.

hmmm... that works for wricef developers, but security team could just modify their own role in dev or temporarily assign a role to themselves and bypass any restriction. unlike wricef team, they will have pfcg and su01. probably would never get detected in dev either.

[Former Member]

There are change documents and timestamps and audit logs.

When confronted with a "you are not authorized" message, most people also "get it".

If folks such as security admins still hobble the security, then they either:

- have to deal with an emergency, or

- are intentionally breaking the rules (and the system probably as well).

In the first case they should document it. In the second case you eventually fire them...(hence auditors and tools to scan systems).

Cheers,

Julius

[OttoGold]

Hi Kes,

I wonder what you recommended. Did the discussion help you in any way?

cheers Otto