One of our company’s biggest success stories in the SAP® Security Area was the execution of a Role Redesign project in an HCM (Human Capital Management) system. This project focused on redesigning the role model and structural profiles to minimize access to modify and view sensitive information in EMT’s Human Resources system.
The Empresa Municipal de Transportes de Madrid (EMT) is a public limited company owned by the Madrid City Council. EMT is the global manager of surface mobility in the city of Madrid and is responsible for the management and operation of urban bus services; public bicycles (BiciMAD); municipal crane, public and resident parking, and the Cable Car. EMT is integrated into the Madrid Regional Transport Consortium, the authority responsible for public transport planning in Madrid.
THE CHALLENGE
The project’s difficulty was, on the one hand, defining a risk matrix specific to the critical accesses of the Human Resources organization and the definition and implementation of a new role model adapted to their needs.
The key to the project was to define roles by position (composite roles) that would improve day-to-day user management without losing focus on access restrictions at the infotype and structural profile level, as well as reducing critical and segregation of duty risks in the system.
It is worth mentioning that this project was very comprehensive, as it also involved the implementation of SSO (a single sign-on authentication procedure that enables the user to access multiple systems with a single instance of identification) and the implementation of SAP® GRC Access Control (EAM, ARA, ARM, BRM, and PSS).
INPROSEC SOLUTION
The project was divided into 4 Blocks, where the first 2 specifically related to the HR part, which we will detail below (risk matrix design and role reengineering), another block related to SSO, and another with the configuration of SAP® GRC AC.
Each of the blocks was divided into 3 phases:
- Risk Matrix Definition HCM (Block I)
-
-
- Initial Analysis
- Business Responsible Interviews
- Matrix Publication
-
- Role Model Implementation HCM (Block II)
-
- Definition of the New Role Model
- Deployment of the New Role Model
- Information Transfer
Risk Matrix Definition HCM (Block I)
The project began with the definition of the risk matrix, as it is the fundamental pillar for designing and implementing the new role model based on best practices, and using it to perform the risk analysis in SAP® GRC Access Control (Access Risk Analysis). This way, we can measure the initial risks that users have and the reduction achieved once the remediation project is completed.
HR systems are usually very customized, meaning there are a large number of custom transactions (Z transactions) in use. Therefore, the biggest challenge was to perform a detailed analysis of each custom transaction to identify its functionality and confirm whether it should be added to the risk matrix.
Once the Z transactions were analyzed, and based on the standard SAP® HR risk matrix included in SAP® GRC, a first draft of the risk matrix was created to conduct functional interviews with the responsible parties for human resources business processes and the internal audit team. The risk matrix was defined at the level of segregation of duties (SoD) risks and critical actions.
Once the first draft of the risk matrix was available, work meetings with human resources business representatives began to achieve the following objectives:
- Confirm risks and functions of the standard risk matrix.
- Identify risks and functions specific to EMT.
- Confirm custom transactions to add to the risk matrix.
- Identify risks between SAP® systems.
- Define compensatory controls associated with the risks identified in the risk matrix.
To maintain the risk and control matrices’ lifecycle over time, the associated procedures were defined to achieve this goal. Specifically, the periodic update procedure of the risk matrix and the secure code development procedure were established.
Both the risk and control matrices and the associated procedures were presented to EMT’s internal team through training sessions.
The deliverables associated with this block were as follows:
- Matrix update procedure.
- Secure code development procedure.
- Risk and control matrices.
- Analysis report of Z transactions, including actions and recommendations.
Role Model Implementation HCM (Block II)
The role model was designed for all over 300 users of EMT’s SAP® HCM system. A sustainable and scalable role model was implemented over time, with a single, easy-to-understand nomenclature aligned with the HR risk matrix defined in Block 1 of the project.
Initially, a transactional use analysis of EMT’s SAP® HCM system users was conducted to identify which transactions would be included in the new roles. Before designing and building the new roles, a role nomenclature was defined and agreed upon with EMT, allowing for efficient identification and maintenance of the new model.
The classification of transactions into roles was based on functions respecting the defined risk matrix. Enabler Roles were created to grant access to authorization objects that require specific restrictions, such as those containing the infotype field and personnel area. Accesses were also defined based on the organizational structure, using structural profiles.
Roles and structural profiles were created in the development environment and transported to the quality environment for functional testing and User Acceptance Testing (UAT). It was agreed with EMT’s responsible parties that users would perform acceptance tests of the new model, aiming to have at least one reference user for each defined job position, confirming the operability of all composite roles.
The start of this second phase coincided with the deployment of the SAP® GRC Access Control’s Access Risk Analysis tool, which was used to perform the initial risk analysis and compare it with the analysis conducted at the project’s end.
The deployment phases of the new role model for different user groups were agreed upon with EMT. This way, EMT could determine the order in which users were migrated, minimizing operational impact without affecting business processes. Additionally, new roles would not be simultaneously assigned to all users of the same user group to reduce the potential impact of the new solution’s deployment.
Parallel to the model’s deployment, information was transferred to EMT’s role management team to properly manage and maintain the new role model implemented once the support period for each deployed user group was completed. Specific training sessions were conducted to detail each of the procedures defined in the previous phases.
The deliverables associated with this block were as follows:
- Initial risk report and risk reduction simulation. This will help define one of the project’s baselines.
- Functional and technical design of the new role model to be implemented in EMT’s SAP® HCM system.
- Report on the actions taken: roles created/transactions assigned.
- Final report on residual SoD risks of the project.
- Training and maintenance manuals for the new role model.
RESULTS
The implementation of a Human Resources-specific risk matrix allowed EMT not only to identify and monitor its most critical standard accesses but also its custom accesses (Z Transactions).
Regarding the implementation of a new Role Model, the main benefits were:
- Definition of a new role nomenclature adapted to their needs, facilitating daily identification.
- Functionality-based roles, avoiding assigning a role that includes transactions with functionalities the user does not need.
- Reduction in the number of risks and accesses available with the previous role model.
- Definition of composite roles by job position, facilitating the management of “Onboarding” and “Movers”.
- Identification of the infotypes accessible to the different positions in EMT’s organization. Additionally, each was limited to the allowed permissions: View and/or Modify.
- Activation of organizational restriction by establishing structural profiles in the new role model implemented. This meant that positions with access to infotypes had limited information to the personnel division they belonged to.
- Activation of a restriction that limited access to certain infotypes through a structural profile. There are authorization objects, such as P_ORGINCON, that allow expanding access to infotype information by using a less restricted structural profile, or vice versa.
