Role-based Access Controls and Role Assignment Review

In our last article, “Security, Risk, and Compliance in EnterpriseOne”, we touched on governance, risk, and compliance (GRC), Segregation of Duties (SOD), and the relevant considerations for your enterprise applications, specifically EnterpriseOne. The full article can be found here: Security, Risk, and Compliance in EnterpriseOne,In this article we will explore a sometimes-overlooked aspect of GRC, reviewing the list of users who have access to your enterprise applications and what access they have through their role assignments.The Importance of RolesWe talked last time about how a good security structure for any enterprise application, and especially EnterpriseOne (E1), is rooted in Role-Based Access Controls (RBAC). That is, defining security access at the role level and then assigning the role or combination of roles to the users. Strategies for a RBAC design and related best practices are enough to fill multiple articles and we won’t cover those here but let’s take a quick overview of RBAC.

Role-Based Access Controls

Roles control access to applications and reports (UBEs) and the actions a user can perform in the system. Roles can also limit the data a user can access – either specific fields in an application or rows from a table. We will discuss data security strategies in a future article so we will leave it at that for now. For our purposes, it’s sufficient to understand that whatever an application’s security model uses as an access point (tables for example), they are defined as permissions within a role. This applies to EnterpriseOne and other enterprise applications as well.How Roles WorkRoles are usually limited to a group of activities within a specific department in an organization and the role definitions set the permissions for the activities. Roles are usually split wherever a segregation of duties (SOD) conflict is present.For example, in Accounts Payable, we might see the following roles:

• AP Inquiries and Reports
• AP Invoice Processing
• AP Payment Processing
• AP Payment Approvals

These roles are then assigned to users in the Accounts Payable department in some combination that reflects the job they are expected to perform.As discussed in our GRC article, Segregation of Duties analysis is used to evaluate for any toxic combinations that are created through the role assignment process.

But Segregation of Duties is only one part of the controls related to access on your enterprise systems. Even if there are no bad combinations assigned to a user, are the roles appropriate for their job or responsibilities? You need a role assignment review to find out.

Role Assignment Review

The fundamental task in the role assignment review is to ensure that the users on your system are correct and have the right roles assigned.It is a widespread problem that access is not fully removed when a user leaves the organization. Or, if a user changes positions within the company, their old access is not removed.Step One: Role OwnershipLike SOD, we recommend that owners are named for each role. Role owners are responsible for reviewing the list of users assigned to their roles and approving or rejecting the access periodically.Step Two: DocumentationThe next step is to document the additional information that a role owner needs to perform the review.  This could include data points such as:

• Detailed role description
• Contact information for user
• Users’ manager and related contact information
• Location and status of user.

To help with these data points, we suggest keeping a “role narrative” document that is available to the role owners and is periodically reviewed by the security admins against the live application security for accuracy. This should be in plain, non-technical language and provide an overview of each role’s permissions in one or two sentences. As there is no place to store a detailed description in E1, this will have to be stored externally.If the user contact information and reporting structure is stored in E1, the data just needs to be assembled from the various sources. If not, this data must be pulled in from external sources. The same applies for location data as there is no place to store that directly in E1. This could be a great use case for using an Orchestration between E1 and HCM system or connecting multiple systems through a business intelligence tool.

Fig. 3: Role Assignment Review ProcessStep Three: Process DefinitionOne last point on the process is to work with your compliance department to decide on the frequency and scope of each review. One example might be a full review once a year with quarterly reviews focusing on users or user-role assignments that have been added or changed.The organization’s governance model will set these standards and your role assignment review process becomes the compliance tool to ensure the control is being met.ToolsThere are many tools that can help store, combine, distribute, and update this data. Some examples are here.

1. Q Software has a Periodic Access Review module that allows organizations to store most of the additional attributes and include them in the review data. It also allows system administrators to automatically update the user-role relationships based on role owner actions, making the follow up work more accurate and efficient.
2. E1 Orchestrator Studio can connect multiple sources of information, but a central place to put the data is still needed. On the end of the process, Orchestrator could be used to update system records but again, it will need a source data. With this approach the listing, distribution, and review process will likely be managed outside the system.
3. Business Intelligence systems like PowerBI and ReportsNow can serve the purpose of displaying the information but the approval process and any required updates will be managed outside the system.

We see many examples where this documentation is not done at all or the process is very manual, using Excel as the data repository, merging data through myriad of lookup references, and distributing multiple copies of a spreadsheet to the role owners. Then, when the administrators get the spreadsheets back, they have a manual task to update the user-role relationship records in the system.

Conclusion

Security and related controls are about risk. If users have access to sections of your enterprise application that are not relevant for their job, what risk does that present? Are they accessing something they aren’t licensed for? Are they needlessly performing tasks outside of their job responsibilities? Even in the absence of an internal threat, this process is often part of SOX controls that companies must attest to.The data needed to support this process is generally available somewhere in the organization so the work is finding a system to combine the data into useful information, managing the review process, and ideally, automatically updating the records.Automation and workflow are two key aspects of this process that will help overcome friction within the business to take part in these reviews. The role owners that handle signing off on this review are inevitably busy, so the process needs to present them with easy-to-understand information and a smooth process to interact with the data.

Author – Matt Vanderkooy, ERP-One Consulting