firefighter log review

[Former Member]

Hello. My team is responsible for montoring firefighter ID usage on SAP GRC 5.3_21.7. Currently updates a master log documenting each time a user logs in with a firefighter ID regardless as to whether they execute a transaction code. Is there any risk (from an audit perspective) associated with logging in but not executing a transaction code. I'm fairly new on the job and I want to remove governance processes that may be redundant. We pull detail reports for t-codes that are executed on production for a specified period on weekly basis. I'm just not sure whether requiring management to log firefighter login's when no t-code has been executed in necessary. Open for suggestions.

[former_member1152207]

Hi James,

I am now working in the same area of governance and compliance.

Interested in knowing if you got better way of reviewing the Logs or any other way to work around the same?

Regards,

Manthan

[Colleen]

Hi Roosevelt

Currently updates a master log documenting each time a user logs in with a firefighter ID regardless as to whether they execute a transaction code. 

Is this a manual log that you maintain or do you mean the FF Log?

 Is there any risk (from an audit perspective) associated with logging in but not executing a transaction code.

With FF you will launch into SAPGUI session (Easy Access Menu). You will have to execute a transaction code to get somewhere. However, you could also potentially have a URL in your favourites that launches a webdynpro. That will not trigger S_TCODE check. It will trigger other authorisation checks and SSO/trust will need to enabled or user will get pop-up dialog for password.

 We pull detail reports for t-codes that are executed on production for a specified period on weekly basis

What do you mean by this? Are these the FF log reports?

I'm just not sure whether requiring management to log firefighter login's when no t-code has been executed in necessary.

How is your FF configured? Do you send out login and usage notifications? What procedures and training do you have for your users to access FF? What level of access and account set up do you have for FF?

It's great that you are trying to avoid non-value add activities but it's hard to provide advise without knowing some of the specifics of your setup

Although this is for version 10.x it does give you some context on FF so might be worth a read:

Regards

Colleen

[Former Member]

Hello Colleen Lee. Thanks for the response and for the reading materials. I responded to your questions (see below) to best of my ability. I'm certain this is not a complex issue. The basis of my question really relates to whether or not it's necessary for management to log session time vs t-code execution sessions, or both. Right they are logging both, but after speaking with IT Security, it seems only necessary to log t-execution sessions.

Is this a manual log that you maintain or do you mean the FF Log? Yes, its a manual log (excel spreadsheet) maintained on a sharepoint site. During the week, management updates the manual log documenting users who've logged in to include the log-in date, FF ID, username, review date, and reviewer's ID. On a weekly basis, I pull the Log Summary Report from the Superuser Privilege Management module to detect instances in which FF ID sessions were exercised. This specific report does not indicate whether t-codes were executed during the session (the Log Report report contains that information). If a user executed a t-code during the FF ID session, the reviewer uploads a detail report (Log Report) to the sharepoint site indicating which t-codes were executed and the date, time, system, FF ID that the t-codes were executed on. The assumption is if the Log Report does not return t-codes for a specific session time indicated on the Log Summary Report, the user did not perform any transactions under the FF ID therefore not exposing the company to any risk, intentional or incidental. (I think this sentence best underscores the purpose of my question)

With FF you will launch into SAPGUI session (Easy Access Menu). You will have to execute a transaction code to get somewhere. However, you could also potentially have a URL in your favourites that launches a webdynpro. That will not trigger S_TCODE check. It will trigger other authorisation checks and SSO/trust will need to enabled or user will get pop-up dialog for password.  I'm not sure I'm following your response here as I'm not an IT guy (background is Accounting and Audit), but it seems like you're saying that typically users cannot perform transaction without executing a transaction code, however utilizing a webdynpro feature in which a transaction code can be entered (and remain undetected on a txn history report) will enable the user to perform certain functions equivalent to that of directly entering a transaction in SAP GUI. Please confirm whether this is the gist of what you're saying.

What do you mean by this? Are these the FF log reports? Addressed above.

How is your FF configured? Do you send out login and usage notifications? What procedures and training do you have for your users to access FF? What level of access and account set up do you have for FF? I'm certain as to the actual configuration of the FF codes considering I just started I don't have an IT background. We do not send out log in and usage notifications. We (governance) rely on management to update the manual log when FF IDs are logged into by a user, and we review the Log Summary Report to ensure management is performing this (completeness check). I will look into the training aspect for users with FF ID access, but please note in my experience (2 weeks), most users who log in with FF IDs are IT / IT Security persons. I don't have FF ID access as FF IDs are assigned on a temporary, as needed basis. My access is solely SAP GRC authority.

[Colleen]

Hi Roosevelt

Thanks for the details

I do wonder what the value and reasoning behind SharePoint. It does seem like a bit of effort and perhap you could look at reviewing the process

1. User wants to use FF Id - they have the set available
2. Logon to FF Id - force them to enter a Service Call Reference number, etc and have them put all support evidence and justification in there. FF logon has a drop down for Request types that are configured so you could have categories like (incident, request, regular maintenance, change request).
3. FF Logon notification automatically sent to the controller - they will receive the Logon Summary and justification that the person enter. Train the controllers to read these emails and follow up immediately if they are concerned of account being used
4. Training to make sure support person exits the FF Id each time they finish an activity (Controller should chase them down.. refer later)
5. Schedule FF Log report scheduled weekly or whatever frequency to go to each controller
6. Have you process/sharepoint step and have the Controller upload their review and sign off once they have reviewed. If the FF User follows process the Controller will see Reference to to service calls, etc to check if activity was appropriate. Have a process for managing non-compliance (even friendly reminders and training if they keep forgetting to logout)

As far as the tech side of it goes - my next point is that the FF Ids should only have the access that are needed on the account so reduce the size of the log. I.e don't include non-sensitive reporting if you don't want it in the log.

Webyndpro/short-cut - yes - but the SICF service has to be activated and authorisations can restrict that.

My recommendation is that you visit your security team and get them to give you a high level training of FF and security so you can understand the risk a bit better. Also, trying to find out the reason for reviewers adding items to sharepoint. If you were on version 10.x then you could have used workflow to automate the FF log review and be done with sharepoint and XLS!

Regards

Colleen

[Former Member]

I think I will continue this conversation with IT security next week, however, it seems the only risk with logging in is associated with actually executing a transaction code. Just to clarify, my reference to management = reviewer = controllers. The purpose of management (Controllers) updating the master log, and uploading the log reports to the sharepoint is our (Governance) evidence that management reviewed and approval the activity for the respective FF sessions. Essentially, it's the reviewer's approval that sessions were used appropriately. When management does not or forgets to update the master log, we send them a reminder to do so because we see the activity on the Log Summary Report which we pull weekly. I will look into you other suggestions, and see if I can make this process less cumbersome (reduce the amount documentation). Also, we are upgrading to GRC 10.x on 1/1/14. Scheduled to go live in March. Thanks again.

Roosevelt

[Colleen]

Good luck with GRC 10.X

Try to get your requirements in and configure it to automate as much as possible! Keep the log review in workflow if you can and you can then schedule reminder notices