Emergency access procedure - non GRC

[Former Member]

Hi guys,

Just wondering if you have a written Emergency Access Procedure (FireFighter), which is not based on GRC.

My client has unfortunately no GRC installed at all.

Also wondering if Solman can be utilized as currently they use it for change management..

Thanks a lot

Cheers

Greg

[Former Member · Accepted solution]

Greg,

I have experience with two different non-GRC Firefighter procedures, both role-based.

In one solution, the user submitted a Firefighter request for either the HR or the non HR Firefighter role to be assigned; the form was a custom Outlook form. A custom ABAP program monitored the assignment of these roles, logged the tcode usage of the IDs with the role assigned, sent an audit report to the user's manager which included tcode usage and if the tcodes used were in the user's regular roles or in the FF role, and the manager had to return the report to SAP security as confirmation that it had been reviewed.

In the other solution, the request logged into the IdM solution to request firecall authority. The requester must be pre-approved to request elevated SAP access. IdM provisioned the extra access to the users account and notifiedboth the user's manager and SAP Security. IdM deprovisioned the extra access at the specified time in the request. SAP Security was responsible for auditing the use and documenting the tcodes used in a report sent to the user's manager and all of this was documented in an IT incident ticket.

The second solution required a lot more manual effort from the SAP Security team, butit was not invoked often. The first solution, while much more automated, presented its own challenges, as the buffer for the tcode usage statistics  frequently overflowed, and a designated resource would have to work to resolve.

So from my experience, I would say that there is a good reason why customers choose to implement a GRC firefighter solution.

Cheers,

Gretchen

[Former Member · Accepted solution]

In my experience the ABAP-Workflow-SOLMAN solution worked like a charm.

It was user based.

You can either build it yourself or contact one of my former colleagues at IBM

[Former Member]

Thank you guys for your great insights, I will let you know which method is the client's choice.

Cheers

Greg

[Former Member]

Hi Greg,

We had a few clients who doesn't have GRC implemented, but had a solution as mentioned by TJ. Let me know if you have the bandwidth to develop it so that I can share the details.

Regards,

Raghu

[Colleen]

Hi Greg

Fire fighter is a component of GRC Access Controls

If your client does not want to implement GRC to use the Firefighter functionality then you will need to consider how to handle this via a process (such as assign a temporary role and review what the user does)

If you mean the client wants to use FF but do not want to have a separate GRC system and instead install it off Solman you might want to rethink this. Below is a section form the GRC 10.1 Installation Guide advising standalone. Althought Solman is not in the list I suspect it applies as well as you will have a headache for managing Basis Support Stacks/Upgrades/etc/

3.1Preparing to Install SAP Solutions for Governance, Risk, and Compliance (GRC) 10.1

Install SAP solutions for governance, risk, and compliance (GRC) 10.1 on a standalone system as opposed to installing them along with an SAP Business Suite or with any SAP Business Suite components such as ERP, SCM, CRM, OR SRM.

Regards

Colleen

[Former Member]

Hi Colleen,

Thank you for your quick response.

We don't want to install FF separatly.

I'm just looking for a process description/document and this one below is the only aid I have found so far:

http://scn.sap.com/thread/2096898

'... create a manual process that involves logging of all activities performed while the role was assigned, temporary assignment only, reviews and approval of logged activities.   One way is to create a generic account that is always locked and is assigned to a user group that only certain people are allowed to maintain.  Whenever the account is needed, it is "checked out" as if it was a firefighter.  SM19 would be permanently set to log all activities for this account.  To do this, you would have to close all loopholes to the process, such as tightly controlling who can change SM19 settings and who can unlock the account, who knows its password, and you would need periodic reviews of the account, showing the last time it was locked and password changed, the last time SM19 settings were change, and timely reviews of SM20 logs for the account....'

Cheers

Greg

[Colleen]

Hi Greg

It all comes down to what you consider emergency and how you want to go about doing it. End of the day you need to consider:

1. What special access do they need
2. Do you want to have separate account that is locked and unlocked (consider audit implications for proof of account usage as well as license implications as it could be seen as a shared login)
3. Do you have temporary roles the support user requests access to (proper approval process) for the duration of the emergency
4. How will you track and monitor what the user does (security audit log, etc)
5. Who will review the logs and how frequency to provide that information
6. How often would you need to enact this process

As mentioned you really need to think through audit requirements and the risk of access. The GRC FF solution covers this. I don't like the idea of a shared user Id unless you have some type of custom solution that the user launches to tide usage of that account to their identify. But hey, as soon as you go down such a path you are pretty much using your own version of FF.

I've been at places that have had "temporary roles" with the exact access built directly in Production. the technical role name was a Z_incident number and all tracking and reason behind the access was logged in the call ticket, including the approvals and auidt of what the user performed. I wasn't a fan of this solution but it was the solution without GRC to use to grant emergency access and balance with auditablity..

Regards

Colleen

[Former Member]

Hi Greg,

Yes we documented and implemented an emergency access procedure (orange envelope) utilized from SOLMAN.

Request form resided in SOLMAN, standard workflow was used, there was even an automatic check that compared the requested transaction codes and executed transaction codes. Audit Log came from the AUT* tcodes.

Best regards,

TJ