Startegy for Firefighter ID

[Former Member]

Dear ALL,

Has anyone implemented Firefighter ? ..What is strategy you are following for giving FF ID's ?

We are planning to use FF ID's for SOX compliant (To give access to conflicting Job functions).

Regards,

Priyank.

[Former Member]

hi Priyank,

we have implemented FF in our envirnoment , basically we have created FF ID based on Teams and FF had the monitoring tool for audit trail - let me know if you need further info.

regards

shaik

[Former Member]

Hi,

I hope you have completed your project re-Firefighter implementation.

Our company has Firefighter, but now it needs to be locked down so that only a select few have SAP_ALL access...

How do you monitor both access and activity?

I thank you in advance!

Aman (using Liz's user id)

aman.verma

at

Halfords.co.uk

[Former Member]

Hi

For any potentially dangerous uid like FF or Emergency. That has SAP_ALL there should be a good/auditable procedure to use it. Points to consider:

1. The uid’s should normally be locked after changing the password.

2. Unlocking should only be done after:

a. A thorough check if the problem cannot be solved any other way.

b. A good description how the problem is going to be solved (including the TRX to be used)

c. Approval of a Manager On high level in the company to unlock the UID.

d. The UID should only be unlocked directly before the action is started and trace to be switched on.

e. TH password should only be disclosed to the person who is going to perform the action.

f. If possible there should be someone watching the person (four eyes principle)

g. Directly after the problem has been solved the UID should be locked and the password reset again. (use the automatic password generation and do not write down the password)

h. Trace should be read and printed.

3. All actions aforementioned should be recorded including date and time en the names of the persons involved

4. The whole process should be in a procedure, and be submitted to the auditors at first audit.

Hope this helps.

[Former Member]

Hi Aman,

I'd recommend you to get your own user-ID in SDN and open a new thread. Otherwise I'm not sure whether you are able to give points to helpfull answers or to mark this thread as "answered".

Have you got the User Guide of the firefighter ? Maybe you might find what you are looking for in

https://websmp201.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700006501632006E

[Former Member]

Keep in mind when designing the FF process / implementation strategy that FF in not the magic bullet. I wouldn't recommend granting SAP_ALL to the FF id but instead piece meal the various type of access / FF ids, i.e. FF access are granted by functions where we have FF IDs that only grant FI-CO access and few other necessary cross functional access and no security or Basis authorizations. With this strategy, you still able to demonstrate a sense of controls to the auditors where separation of duties exist between each function.

You should also identify who are the stakeholders (FF Controllers and FF ID Owners) for each module and responsible to review the usage logs and thus configure the apps to send logs to the FF Controllers.

Depending on your controls / audit requirements basic FF logging may not be sufficient where FF does not provide detail of changes made using the FF ID. FF logs show tcode, programs and table (in some instances) accessed by the user with particular FF ID but it does not always provide details the actual data changed. Therefore, some additional logging may be necessary (i.e. SM19 and SM20).

In summary, I think reckonizing all the key FF stakeholders is an important first step in designing your FF process and understand what are the controls your client is looking to meet using FF apps.

Cheers!