ID-Based Firefighting vs. Role-Based Firefighting

[alessandr0]

The purpose of Emergency Access Management is to allow users to take responsibility for tasks outside their normal job function. This component allows temporary access for users when assigned with solving a problem, giving them provisionally broad, but regulated access which is monitored and recorded in the application.
SAP GRC 10.0 provides two different types of firefighting which can be used either centralized or decentralized. Following a short description of both types which can be configured in IMG using parameter 4000 (Application Type). Only one type can be configured at a given time.

 

ID-Based Firefighting

With ID-Based Firefighter each Firefighter ID has its own user master record with roles assigned directly to the Firefighter ID. The End-user (Firefighter) executes a transaction code and checks out an ID. It is possible for multiple users to check-out each Firefighter ID (which is authorized to the end-user) but only one user can have a Firefighter ID checked out at any time. A reason code and the expected activity must be documented prior to gaining Firefighter access. Relevant changes in SAP are captured in the change history under the Firefighter ID. It is important to highlight that everything is documented with the Firefighter ID and not the user’s normal user ID.

 

Role-Based Firefighting

Each role which is defined as Firefighter Role can be assigned directly to a user. This can be done through Access Request Management (ARM) if in place or directly in SU01. To use the Firefighter a user doesn’t have to check out a separate ID. Transactions and change histories are logged with the user’s own ID, which is an advantage in relation with the ID-based Firefighter. The end-user is not aware when he is utilizing emergency / firefighter access as he does not have to check out an ID and uses his own ID all the time.

 

Concept of ID-Based Firefighting

 

Concept of Role-Based Firefighting

 

Steps to set up ID-Based Firefighting

1. Create Firefighter ID
   
   
   
   • Create a user account in transaction SU01 with user type S (Service) to be used as a firefighter. This can also be done in Access Request Management if in place.
   
   
   • Assign the Firefighter ID role which is defined in configuration parameter 4010 (Firefighter ID role name) to recognize the service user as a Firefighter ID.
   
   
   • Assign necessary roles for firefighter access.
   
   
   
   


2. Define Firefighter Owner
   
   
   
   • Assign an Owner to the Firefighter ID
   
   
   
   


3. Assign Firefighter Controller
   
   
   
   • Assign a Controller to the Firefighter ID. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
   
   
   • Firefighter ID Controllers can also be Firefighter ID Owners.
   
   
   
   


4. Assign Firefighter
   
   
   
   • Assign a user (must have an existing user ID) to the Firefighter ID.
   
   
   • The user can access the Firefighter IDs (can be more than one) within the validity dates.
   
   
   
   

 

Steps to set up Role-Based Firefighting

1. Define Firefighter Role
   
   
   
   • Enable a specific role for Firefighting directly in the Business Role Management.
   
   
   
   


2. Define Firefighter Role Owner
   
   
   
   • Assign an Owner to the Firefighter Role.
   
   
   
   


3. Create Firefighter Role Controller
   
   
   
   • Assign a Controller to the Firefighter Role. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
   
   
   • Firefighter Role Controllers can also be Firefighter Role Owners.
   
   
   
   


4. Assign Firefighter
   
   
   
   • Assign a user (must have an existing user ID) to the Firefighter Role.
   
   
   • The user can access the Firefighter Roles (can be more than one) within the validity dates.
   
   
   
   

 

Please share your thoughts of both firefighting concepts and participate in upcoming discussions.
Best regards,

Alessandro

[Former Member]

Hi Alessandro Banzer

Thank u for exellent docuement form your side,i have one question here ID based and Role based FFID two things is there

when ever ID based firefighter will assigen to multiple users and only one user acceing the functionalites he loged into sytem and other users they unable do any transaction,when ever present user is logged off

come down to Role based,will assigen these roles to multiple user it will work for all users or not,other wise only one user get the fuctionalities

please let me explaine the diffrence between role based and id based scenratios

Regards

Ravikumar.ch

[mamoonr]

Hi Alessandro Banzer.

Thanks for sharing document.The user type for firefighter id as you mentioned is system user.But I have seen this id to be service user.Can you clarify this please.

Thanks,

Mamoon

[alessandr0]

Hi Mamoon,

thanks for your feedback. This was definitely a mistake from my side. For sure it is user type S - Service User. I have adjusted the document.

Thanks and regards,

Alessandro

[alessandr0]

Dear Ravikumar,

sorry for the delay in my reply.

Your assumption is correct. Assigning ID based firefighter to multiple users have the disadvantage that only one user can use the FF at once. Whereas role based firefighter can be used by a wide range of users at the same time.

Hope this helps to clarify your question.

Regards,

Alessandro

[Former Member]

Thank u for ur response Dear Alessandro.........

[dyaryura]

Hi Alessandro!

Thank you for sharing this information.Nice and simple to understand differences!.

I'm going to share my thoughts as you asked :wink:

I'm definitely against the role based model cause the user just never realize that is performing an "emergency activity". With such model you lost the concept of reason and activity that are very important for Audit purposes. The reason for role-based is simply tracking critical actions. When you have to do that (and only that!) you can use it and forget to use ID-Based, because it's not possible to use both methods.

Another disadvantage of role-based is that the checks are performed at transaction level. just to illustrate let's give an example:

the user USER1 has two roles assigned Z:OB52_DISPLAY and Z:OB52_CHANGE. The first one has S_TABU_DIS (or NAM) with 03 for table group FC31 and the latter activity 02. Both will have transaction OB52. The role Z:OB52_CHANGE has been defined as FF role and assigned to USER1.

If USER1 executes OB52 he'll get the modification permission even if he want display and the event will be tracked as a FF access even when  no modifications performed.

Well, as my point of view ID-Based is the correct option for 99% of the cases.

Cheers!

Diego.

[alessandr0]

Hi Diego,

thanks for your collaboration.

I fully agree and I do not see valuable advantages on role based firefighting. From my point of view to check-out a Firefighter ID is the first step in security as the user who checks out the ID is aware that a second person has to review the performed activities. The psychological sense of security in my opinion is a very strong blockade when it comes to criminal energy and who ever wants to defraud is highly warned. Anyways, I agree with your thoughts/concerns and definitely suggest to go for ID based firefighter.

Regards,

Alessandro

[Monsores]

Hello, Alessandro and Diego.

   First of all, I would like to thank Alessandro for this clear and valuable explanation.

   I agree with both of you about "id based" as the best type of Firefighting, mainly because it is more organized, makes it clear to the user that he will be performing an emergency activity and "forces" the justification of the activity even before it really happens.

   On the other hand, we had a hard question when trying to convince our internal controls team about it, and I confess that I partly agree with them. Their fear is specifically about SoD, because a user could begin a process with its common user id and then finish it with the firefighter id, and it wouldn't be clear at a glance that this is the same person.

   For example, there is the classic risk about buying and paying the same PO. According to their thought, I could login with my common USER1, create the PO and then login with FFUSER1 and pay for it. In this case, my fraud would not become clear in the risk materialization check procedures. In addition to modifying our developments to find the real author of the operation whenever a FFUSER is used, would you recommend something else to deal with this problem?

Regards and thanks once more.

Marcelo

[dyaryura]

Hello Marcelo!

Well... a common mistake is using Firefighter to cover SoD conflicts. I mean, if the user USER1 has to perform both functions because you cannot segregate duties, the first technical solution would be "Let's create a Firefighter and put there all the functions we cannot segregate". I have to tell you, this is the worse you can do... the user will continue performing both activities and you'll probably wont be able to trace the scenario you described. If you use FF for infrequent actions only, the FF controllers would have a few logs to analyze per month and you can rely in such controls. Let's say you have 3 access to FFUSER1 in a month, the controller can fully trace the activities performed. On the other hand if you have 3 accesses per day, the controller will rely on trusting their employees.

If as per the Bussiness Process you cannot segregate the duties, go for a FF isn't the option, You'd rather go for some mitigation control. This could be manual or automatic in some cases blocking via development some possibilities. In such case USER1 would be allowed to do both activities, and you can trace easily and block such action via some user exit :???:

A nice guide I happened to found about these best practices was:GRC Access Control - Access Risk Management Guide | SCN

definitely, it helped me a lot to understand the difference between a nice technical solution and a correct Bossiness approach.

Maybe if you're still not sure what the users are going to do with the FFs, you might take a 3-4 months period to evaluate what they're doing and find alternatives to avoid FF.

It's easy to get confused and try to resolve most of the problems via FF, but definitely you have to find the first answer to the problems from the Process Owners  and not from a computing application.

Hoe it helps...it's just my opinion, no one has the truth :wink: .... open to hear your thoughts!

Cheers,

Diego

[leos]

G’Day Alessandro,

I would like to call upon your expertise for a query I’ve got. Please excuse my ignorance if the following sounds stupid as I am still in the learning process.

From what I can gather so far, my understanding of it is as follows:

- Id Based: Logs in using own U.ID and through GRAC_SPM accesess FFID from the GRC Server and logs into the system assigned to them (ECC, SRM, CRM etc)

• Only one user at a time can use a FFID.
• Firefighter need not exist in every system assigned to them due to central logon?
• Knows exactly when FFID is being used as he/she has to login so has a psychological effect (good thing)
• Better tracking of FF tasks - Specific log reports with Reason Codes. Bonus point from Auditors!
• Two Log ins so potential to commit fraud. (1 action using own UserID and 1 action using FFID)
• Could be hard to track and find out when a fraud has been committed so can be a problem with auditors.

ID Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFIDs

ID Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> You can see  the FFIDs

- Role Based: Logs into the remote system only using U.ID, so everything gets logged  against that one ID.  

• Multiple users can use the FFROLE at once.
• Firefighter has to exist in every system assigned to them - so multiple logons.
• Hard to diferentiate between FF tasks and normal tasks as no login required  So easy to slip up
• Time consuming to track FF tasks - No Specific log reports. No Reason Codes

        Helpful from the auditor’s point of view

R.Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFROLEs

R.Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> Not applicable so wont work

So based on this there are pros and cons in both however according to SAP only one can be used. To me personally,  it makes more sense to get the best of both the worlds right? So here is my question why can’t we just use both?

    . Really critical tasks -> FFID

    . Normal tasks -> FFRole

If I were to do the following does it mean I can use both although come to think of it what exactly is stopping us from assigning someone a FFRole? Unlike FFID there is no limitation/restriction right?

    . Config Parameter: 4000 = 1 (GRC System) -> ID Based

    . Config Parameter: 4000 = 2 (Plug-In)  - > Role Based

Does this mean both ID/Role based firefighting possible? Which seems to be working on my system.

Once again, if all of this sounds silly please excuse me. I rather be silly than stupid:-)

Cheers

Leo..

[suhasku]

Hi Alessandro,

It is quite an informative Blog.
Thanks for sharing with us.

I was wondering, in case of Role-Based FF, if it is possible to get to know what changes are made with "Firefighting Role" and by which User ID!
Is this information also recorded in the Log? Or is it possible to do so?

Thanks,
Suhas K U

[alessandr0]

Hi Leo,

I try to answer all of your question.

ID based:

• Firefighter need not exist in every system assigned to them due to central logon? YES, FF ID needs to have the FF role assigned so that GRC recognizes a user a valid FF ID.


• Two Log ins so potential to commit fraud. (1 action using own UserID and 1 action using FFID) YES, basically the concept of firefigthing is not to compensate SOD conflicts. As the name says "Emergency Access Management" it's designed to use in an emergency case rather then to avoid conflicts.


• Could be hard to track and find out when a fraud has been committed so can be a problem with auditors. Therefore be careful with adding huge authorization to a FF. From my point of view a FF should be dedicated to single duties (e.g. Run payment).

Role based:

• Firefighter has to exist in every system assigned to them - so multiple logons. YES and NO; basically you are not using FF IDs hence you don't have to have dedicated FF users. The concept of role based is actually that a user gets the FF roles and can perform the emergency access with his own user id without loggin on to another.


• Hard to diferentiate between FF tasks and normal tasks as no login required  So easy to slip up. CORRECT, that's the negative point of it.

So based on this there are pros and cons in both however according to SAP only one can be used. To me personally,  it makes more sense to get the best of both the worlds right? So here is my question why can’t we just use both?

    . Really critical tasks -> FFID

    . Normal tasks -> FFRole

Per design it isn't possible to achieve both types of firefighting at the same time. It's a system limitation and hence to configurable.

If I were to do the following does it mean I can use both although come to think of it what exactly is stopping us from assigning someone a FFRole? Unlike FFID there is no limitation/restriction right?

    . Config Parameter: 4000 = 1 (GRC System) -> ID Based

    . Config Parameter: 4000 = 2 (Plug-In)  - > Role Based

I have never tried this. I will check in my system and let you know.

Regards,

Alessandro

[leos]

Dear Alessandro,

Thank you for your detailed and yet concise answers. Its so much easier to follow. Just a couple of clarifications if I may:

• Firefighter need not exist in every system assigned to them due to central logon? YES, FF ID needs to have the FF role assigned so that GRC recognizes a user a valid FF ID.

*Sorry I was referring to Firefighter as in the end user not the FFID! So 'Yes' as in he/she has to exist in every system assigned to them to do FF tasks?

Firefighter has to exist in every system assigned to them - so multiple logons.

YES and NO; basically you are not using FF IDs hence you don't have to have dedicated FF users. The concept of role based is actually that a user gets the FF roles and can perform the emergency access with his own user id without loggin on to another.

*I was referring to a situation where one Firefighter has to login to multiple systems (maybe unlikely but still you never know in a small company maybe?)

Per design it isn't possible to achieve both types of firefighting at the same time. It's a system limitation and hence to configurable.

Well this is what I can't seem to get my head around. For a FFID, there is a logon session so it has to be enabled and as far as I can tell there is no way around it.

However for FFRole, there isn't such limitations/restrictions like starting a seperate session. As you pointed out yourself FFRole is just assigned to an end user for him/her to perform those tasks using their own user ID.

• So in what way is it different from any of their other tasks/roles, other than the fact that they've got an Owner and Controller assigned to the FFRole? and
• What is stopping us from using it when ID based is the default?

In regards to the following:

If I were to do the following does it mean I can use both although come to think of it what exactly is stopping us from assigning someone a FFRole? Unlike FFID there is no limitation/restriction right?

    . Config Parameter: 4000 = 1 (GRC System) -> ID Based

    . Config Parameter: 4000 = 2 (Plug-In)  - > Role Based

I have never tried this. I will check in my system and let you know.

Please do as it seems to be working on mine and again (forgive me if my logic is a bit silly), Role Based firefighting is only done on Plug-in systems so the following should work just fine:

   . Config Parameter: 4000 = 2 (Plug-In)  - > Role Based

However for ID based, it is a Central Logon, so the following is a must:

    . Config Parameter: 4000 = 1 (GRC System) -> ID Based

Which means both ID/Role based can be used at the same time. Either way you are the expert and I hope you will shed some light on it.

Cheers

Leo..

[leos]

G'Day Alessandro,

I opened up a new question on this topic so others can benefit and join in as well. Would appreciate it if you can answer them over there please.

EAM ID based or Role based? Why settle for just one?

Regards,

Leo..

[alessandr0]

great - I will join that discussion.

Regards,

Alessandro

[alessandr0]

Hi Suhas,

generally the application logs all performed actions from the FF roles. That means if you have VA01 transaction in your FF role and you start VA01 the application starts to log. Please be aware that the system logs all executed actions that are in the FF role, also wenn an action is also assigned thur another role (which is not a FF role).

Hope this makes it clear.

Regards,

Alessandro

[Former Member]

Hi Alessandro,

Very good document.

We have implemented Role based firefighter. Risk analysis is mandatory for all the access requests.

When a user selects EAM workflow and submits a request for a firefighter role, the firefighter role owner has to go through risk analysis and mitigation for a firefighter role as well.

Can you please advice how can we skip this.

Thanks and Regards,

Zarina

[Former Member]

Hi Alessandro,

Thanks for your good document.

However i have question on this blog, why can't we use only service user for firefighting ?

what is the advantage ?

Regards,

Baburao

[alessandr0]

Dear Baburao,

in the previous version it was only possible to use service users. With the latest GRC versions (10.0 / 10.1) it is also possible to use dialog users as firefighter ID. Whenever you log-in with the firefighter the password gets changed automatically by the application so that you do not know the password.

Hope this answers your question.

Best regards,

Alessandro

[Former Member]

Dear Alessandro,

Thanks for you answer... but how the application will change the password automatically ?

can you please explain in brief.

Regards,

Baburao

[alessandr0]

Dear Baburao,

when a user logs in the application resets the password of the firefighter ID to a complex password according to the password policy. Only the application knows the password and uses that for the log-in.

Regards,

Alessandro

[ghan]

Hello Alessandro,

Thanks for your excellent document. 

I have set up Role-Based Firefighting. However i have an issue, there is no log generated in GRC to use FF role. I have already applied note 1545511.

Thanks.

Best regards,

Ghania

[rakesh-kuruba]

Hi Alessandro,

 

Thanks for your good document.

I have a question. How to see link between user and firefighter ID. I mean which FFID is assigned

to which user or vice versa. I have tried /VIRSA/ZFFUSERS this table but no luck ... Could you

please suggest here..