GRC Training – Process 4: FireFighter Users and Roles

Process 4: FireFighter Users and Roles

This section covers the special circumstances where users and roles are created for emergency “FireFighter” use and for changes to IS&T Support roles.
Where the term “FireFighter” is used here, it relates to the use of the GRC-EAM (Emergency Access Management) functions which have some special
features which require administration and monitoring.
The features in use at MIT are:
 Special SAP R/3 FireFighter Users and Roles – typically with limited update functionality. Access rights to the R/3 FF Users are pre-assigned in
GRC-EAM to specific business users who need occasional or emergency access to functions which would otherwise create SOD issues if
permanently assigned. Some Firefighter Users have roles with more access than others - see the various FFID types described below.
 The firefighter logs into the GRC-EAM system with their SAP Kerberos User ID run the transaction /n GRAC_SPM; they will see the Firefighter
launch pad, with the pre-assigned FireFighter user. The firefighter “logs in” to the pre-assigned Firefighter user, which allows them to access SAP
R/3 to perform the emergency or back-up business functions. When finished, they log out of their SAP R/3 session, and then log out of SAP GRC.
o A FFID can be shared, but can only one person can log into it at a time.
o The FireFighter ID Owner determines the appropriate assignment for the Firefighter ID.
o The FireFighter Controller for that FFID is notified when it is used
o The FireFighter User actions are logged and reviewed by FireFighter Controller or Delegate when the Firefighter logs out.
 All SAP Users which are set up for FireFighter usage will be named like “FF_XXX_NN” where XXX = the business area letters (can be a few more
characters if needed) and NN is a sequential number. User Type = SERVICE and special role assigned to identify it as a GRC FireFighter (see step
2A). The R/3 GRC Repository Synch job synchronizes R/3 user assignment data with production GRC. The GRC Admin creates a FFID in the
NWBC (NetWeaver Business Client) interface with the same id as the R/3 User. All Firefighter users must have their own personal SAP IDs
manually created in GRC. The different
FFID types have different roles in R/3:
o Business User FFID: has limited update transactions, specific to the business areas or job duties for the users being backed-up. This
would have SODs when combined with business user’s standard role.
o Business Analyst FFID: has update transactions with broad business access – roles are either Finance/Logistics or HR/Payroll focused.
Will always have SODs are they are broad access to deal with any issues. At MIT these are Composite Roles combining all the standard
business roles for the business area.

1
 GRC Training – Process 4: FireFighter Users and Roles

o IS&T BSA FFID and BSA Manager FFID: has update transactions with broad business access – roles are either Finance/Logistics or
HR/Payroll focused. Will always have SODs are they are broad access to deal with any issues.
o IS&T Basis Admin FFID: has some special access over and above what they already have.
o IS&T Developer FFID and Developer Manager FFID: has update transactions with broad business access to deal with any issues – and
these will always have SODs. The roles are either Finance/Logistics or HR/Payroll focused and some Developer FFIDs and the Developer
Manager FFID include EDI and Workflow support access,
 Note: Support User in IS&T BSA: has display only transactions with broad business access, so should never have an SOD for these.
 Note: Regular BA users: display only transactions with broad business access, so should never have an SOD for these.

After the initial FireFighter process set-up, the ongoing administration consists of:

 More frequently
 Creation of SAP Kerberos ID in GRC for Firefighters
 GRC Assignment of SAP Users to FireFighter Ids (adding and removing assignment)
 SAP R/3 FireFighter Role maintenance – new functionality for the business needs to be added, and discontinued functionality removed.
 Less frequently
 GRC Assignment / de-assignment of FireFighter Ids to FFID Controllers
 New SAP R/3 FireFighter Users when there are additional FFID Controllers

Some additional MIT-specific background points related to FireFighter design:

 The FireFighter SAP R/3 users do not have Kerberos ids, so they are created by SAP R/3 Security Admin, and no profiles are provisioned through
Warehouse or RolesDB.
 So that automated monitoring of BA and BSA FireFighter Id usage can go to the appropriate business manager, separate FireFighter Users have
been set up for each business area manager (the FFID Controller). Typically the same role is assigned to several FF R/3 Users, as the BA/BSA
needs the same access no matter which manager requested the FireFighter usage.
 Use of FF will require an RT Ticket to be created and justification and details of its usage are documented there.

2
 GRC Training – Process 4: FireFighter Users and Roles

GRC FireFighter terminology

 R/3 FireFighter User: - the R/3 User called up by GRC when the FireFighter requests access via GRC – it cannot be accessed in SAP R/3 directly.
 FireFighter - the business user, BA or BSA or BSA Manager or IS&T Developer or IS&T Developer Manager, SAPADM user or SAPADM
manager who needs access to the R/3 FireFighter User in Production.
 FireFighter Id - the GRC object used to control access to the R/3 FireFighter User – it links the R/3 FireFighter User to the FireFighter.
 FireFighter’s R/3 Role Owner - like the standard R/3 Security Role Owner – will usually be the same as the FireFighter ID Owner.
 FireFighter ID Owner - requests/approves GRC assignment of Users to FF Ids. GRC functionality for FFID Owner is not being used.
 FireFighter ID Controller - informed of FF usage at start and end of session and reviews logs. Typically the Business Role Owner.
 FireFighter ID Controller’s Delegate Not currently being used at MIT.

Roles & Responsibilities for Process 4:

 SAP R/3 Security Admin Maintain FireFighter and Support Users in SAP, and their assignment to MIT personnel
 GRC Admin Maintain FFIDs and assignments - also can maintain R/3 Users.
 FFID Owner Requests user assignment to FFIDs and any new FFIDs
 For VPF, this varies per business area. May be Risk Owner or Role Owner.
 For IS&T, these are Frank and Siobhan
 FFID Controller Review FFID actions.
 For VPF, this is Controller or Director level. May be Role Owner or Business Area manager.
 For IS&T this is Bart
 FireFighter

3
 GRC Training – Process 4: FireFighter Users and Roles

Process 4: FireFighter Users and Roles - Detailed Steps

P.4 Business Role Responsibility / Output Details

1a R/3 Security Create FireFighter  Roles There are several types of FF roles :
Admin Roles  Business Analysts (BA)
 IS&T Business System Analysts (BSA)
 IS&T Basis Role
 IS&T Developers
 IS&T Managers
 Business users – limited and specific to each requirement (mostly for
back-up)
The Role Provisioning process (requesting, approving, auctioning, and testing)
is no different to any other role – except that SOD issues are not relevant.
1b R/3 Security Maintain FireFighter  Roles updated Changes should be infrequent, once the system matures :
Admin Roles  Add new Functionality
 Remove
The Role Provisioning process (requesting, approving, auctioning, and testing)
is no different to any other role – except that SOD issues are not relevant.
There are special designated approvers for changes to FF roles :
 FFID Owner for BAs
 FFID Owner for IS&T FireFighters
 FFID Owner for Business FF = Risk Owner of the business area?
1c R/3 Security Maintain IS&T  Roles updated IS&T Support Roles
Admin Support Roles  These are Display only roles and are in daily use.
 They are not part of the “FireFighter” control process.
The Role Provisioning process (requesting, approving, auctioning, and testing)
is no different to any other role. There must be NO SOD ISSUES in these
roles.

4
 GRC Training – Process 4: FireFighter Users and Roles

P.4 Business Role Responsibility / Output Details

2A R/3 Security Maintain FireFighter  Users updated The R/3 FireFighter Users are generic in that they are assigned to anyone /
Admin Users  Business Roles more than one person via the GRC system. See Step 4.c
assigned New R/3 FireFighter Users will be infrequent - perhaps if there is a whole new
 FireFighter role area of SAP implemented.
assigned  Creation of R/3 FF Users is a manual process (cf. regular Kerberos R/3
users are automatically created during MIT on-boarding.)
 The R/3 FireFighter User is assigned the special FireFighter role with some
RFC access privileges (identified in the GRC system parameter 4010 as
Z_SAP_GRAC_EAM_FFID). This identifies the FireFighter R/3 User to GRC
as a FireFighter.
 Also the User Type = SERVICE, as the login is activated/controlled by a call
from the GRC system when the user logs into the FF ID from GRC.
2B R/3 Security Lock/Unlock R/3  R/3 User locked or Like any other R/3 User, the R/3 FireFighter user can have validity periods (not
Admin Users unlocked used much at MIT) or can be locked / unlocked to control access.
 Users are created in Production – so may be locked until needed.
3 Basis / GRC Synch systems : SAP  GRC = ECC An automated process makes sure that the GRC system has up-to-date
to GRC Repository information from SAP R/3 about roles and users. In this case, specific to
FireFighters :
 The FireFighter R/3 User needed for step 4.A
 The Business R/3 Users are needed for step 4A, 4B and 4C
 Any new FireFighter roles – in case GRC-ARA analysis is needed (not at
MIT).

5
 GRC Training – Process 4: FireFighter Users and Roles

P.4 Business Role Responsibility / Output Details

4A GRC Admin Maintain FFIDs  FF Ids in GRC-EAM The GRC FFID attribute settings are central to the control and usage of the
FireFighter roles in R/3
 In this step the following updates are made in the GRC-EAM system :
o The FFID is created– with the same naming convention as the SAP
R/3 FireFighter user - like FF_FAR_01.
o The FFID is assigned to the matching SAP R/3 FireFighter User.
o The FFID is assigned to an FFID Owner – at MIT this is mostly for
information only, as the FFID Owner will not be logging in to GRC
to maintain user assignment.
o Additional information for the FFID can be added if required.
The GRC FFIDs are mostly set up during the initial phase of the GRC project,
and is related to the business organization, so additions will be less frequent.
4B GRC Admin Assign FFID  FF Id assigned to In this step an FFID is assigned an FFID Controller (which is another R/3 User) :
Controllers FFID Controller  The FFID Controller is emailed when the FFID user logs in and logs out –
(SAP R/3 User) with a link to the FFID detailed usage logs after logging out.
NOTE : FFID  For the VPF business areas, the VPF business managers are the FFID
Controller Controllers – for the Business FF, BA FF and BSA FF.
“Delegates” not  For non-VPF areas, there are FFID Controllers in IS&T so that the BSA FFID
currently used at MIT usage can be monitored.
4C GRC Admin Assign FFID to SAP  FF Id assigned to In this step an FFID is assigned the R/3 User who is the actual FF person - and
Users SAP R/3 Users this is a different R/3 user than the FFID’s Controller.
 An FFID can be assigned to several R/3 users
 An R/3 User can be assigned to several FFIDs
 The assignment can be for a limited period.

6
 GRC Training – Process 4: FireFighter Users and Roles

P.4 Business Role Responsibility / Output Details

5A GRC Admin Grant appropriate  Assign GRC access There are several types of GRC users who need specific access privileges in
access to the GRC rights to R/3 Users GRC – predefined in GRC access roles :
system a. FFID Owners (although MIT is not really using this feature) – GRC
Role = Z_FFID_OWNER
b. FFID Controllers GRC Role = Z_FF_CONTROLLER
c. FFID Users – those who have to log in to the FFID. GRC Role =
Z_FF_ENDUSER
d. Other MIT users who may want to run FF-related reports.
This data will typically need updating as users change their job positions or
when they join / leave the MIT workforce.
5B GRC Admin Amend FFID /  FF Id assigned to This assignment will typically need updating where the FFID Controller
Controller different Controller changes jobs, leaves MIT or if there is a Departmental Reorganization.
assignment o Change the assignment (an FFID has only one Controller)
An RT Ticket is required, plus a new Form – GRC FireFighter ID Assignment
Change request.
Note: if this reassignment is made after the event, the FFID logs can still be
reviewed through FRC-EAM reporting.
5C GRC Admin Amend FFID / SAP  FF Id assigned to This assignment in GRC will need updating when the R/3 User changes jobs,
User assignment different SAP Users leaves MIT or perhaps if there is a Departmental Reorganization.
o Add an assignment – with a future “Valid From” date if known in
advance.
o Remove an assignment ad amend the “Valid To” date if move is
know in advance?
An RT Ticket is required, plus a new Form – GRC FireFighter ID Assignment
Change request.

7
 GRC Training – Process 4: FireFighter Users and Roles

P.4 Business Role Responsibility / Output Details

6 FireFighter Request FF usage  RT ticket An RT Ticket is required where the business manager has requested support
Controller / from BA/BSA etc. - with justification and details of expected usage.
Business
Manager
7a SAP User Log into the FFID  RT ticket, if not The Business FireFighters performing back-up / unusual work do not need a
already created ticket. Otherwise there is an RT Ticket either from step 6. or created by the
 Email to FFID BA or BSA based on email from the Business Manager (FireFighter Controller).
Controller Also, a “Reason Code” is selected when logging in to the FFID, and additional
information can be entered by the FireFighter.
When the FFID is used,
 an email is sent immediately to the FFID Controller
 an activity log is started and is updated hourly
7b SAP User Log out of the FFID Where there is an RT Ticket, any additional / unexpected FireFighter usage
will be noted on the RT ticket by the FireFighter.
When the user logs out of the FFID, within the hour the activity log is updated
and an email is sent to the FFID Controller with a link to the Activity Log for
that FFID and time period it was used.

8
 GRC Training – Process 4: FireFighter Users and Roles

P.4 Business Role Responsibility / Output Details

8 FFID Review, Question,  Approval or action  The email from GRC to the FFID Controller is a request for approval and a
Controller Follow-up list link to the details action log.
 Action logs are reviewed – looking for unusual activities in general, and
activities inconsistent with the
o Business FireFighters have limited, pre-approved access, so it is
unlikely that anything will result from review of the logs alone.
o For the other FireFighters, any master data changes or financial
postings need to be reviewed and approved – a common
technique for this is printing the log and initialing each line that
was verified. In SAP the master data change history and financial
documents are available for review at any point afterwards.
 The reviewer’s options are to :
o Request the FireFighter to provide more details
o Approve the whole log.
o “Hold” the log – i.e. not approve it yet. The work item will stay in
their GRC inbox for subsequent processing.
 Additional notes can be made on the log for any action to be taken.
9 Reporting Review FFID usage  Reports – some of
Actions and Activity Logs at the standard
any time reports will be used
– Log Summary and
Consolidated Log
(see next two
pages)

9
GRC Training – Process 4: FireFighter Users and Roles

10
GRC Training – Process 4: FireFighter Users and Roles

11