Designing a role model
in 2 days instead of 12 months
A cost-effective approach
to role model design
As a small European bank, our client has to adhere to the same regulatory requirements as the major banks, but with far less resources.
To adhere to the requirements of the National Bank, they needed a more structured approach to assign access rights, specifically a role model that is accepted by the business and can be used by IT to assign access rights.
Working with mass interviews and huge spreadsheets was not feasible for our client however, this would take them too long and cost too much.
Instead, we applied a data-driven and iterative approach and provided the client a suitable role model in just 2 days, allowing them to prove that they're in control.
A multi-layered role model consisting of business roles (also known as user classes) and technical roles. This model allows for the necessary flexibility when including multiple applications with potentially different levels of access rights.
Iterative: We started with identifying those applications that were the most crucial. For those applications, a role model to better control the accesses is a priority. The first scope: Active Directory and Temenos Transact (previously T24).
Iterative within this scope of applications: We believe it’s the combination of technology and human judgement that will result in a suitable role model fast. That’s why our approach includes a feedback loop. Hereby the candidate role model, that’s generated by powerful algorithms, was shown to the business. We gathered and analyzed the feedback, and adapted the algorithms accordingly. A new - and better - candidate role model could then be generated.
Iterative across the scope of applications: Once the role model for this scope got accepted, we selected a new set of applications. That way the role model expanded to include more applications, gradually increasing role model coverage.
Data-driven: To generate a candidate role model, we collected the relevant identity data from AD, Temenos and HR in our platform and started an initial analysis. As we’ll use this data to design the initial set of candidate roles, we defined the relevant data to base the model on: only active employees. Based on visualizations such as peer analyses, an understanding of the organizational structure and the access patterns could already be formed.
Hybrid: We took into account both the values in attributes that employees have (to ensure a logical role model), as well as the assigned access rights (to ensure an effective role model).
Trade-off between security and usability: Visual data analytics and machine learning algorithms enabled us to define the business and technical roles based on group coherence scores, and map entitlements to technical roles and technical roles to business roles. This is always strongly influenced by the trade-off that a client makes between security and usability. In this case, our client chose to minimize the total number of overgranted and undergranted access rights in case the role was to be enforced. Read the box for more details.
Trade-off between usability and security
A full focus on usability would result in ‘everyone in the organization can do everything’, leading to an enormous amount of overgranted access rights if that role model was to be enforced. Almost everyone would suddenly be able to do more than they can at this point.
A full focus on security would result in ‘a different role for every employee’, most likely leading to a number of undergranted access rights. In other words, some people would probably lose some access rights when the role model was to be enforced. On top of that, the benefits in terms of lower administrative burden that a role model would bring, are completely nullified.
Somewhere in between is where most organizations end up. Optimally, an organization would choose to minimize the total number of overgranted and undergranted access rights, supplemented with some specific constraints. For example, for certain sensitive access rights security prevails and overgranting those access rights should be minimized or even zero.
This gave us a candidate role model for Active Directory and Temenos Transact in 2 days. We then measured how well this role model mapped with the current situation: around 80% for AD and 60% for Temenos. This indicated that the access assignments in Temenos Transact were quite dispersed in practice and needed some cleaning up.
Our client also uses our platform to follow up on the mapping scores and the platform’s role analytics to clean up access assignments.
Using technology to generate role candidates and measuring mapping scores enabled our client to have something that they could use to go to the business. But maybe even more importantly, something that they could use to prove to the National Bank that they were working on it. Already in a matter of weeks.
They didn’t need spreadsheets, sorting and filtering, mass interviews, and so on. Elimity’s approach and technology opened up a cost-effective way to design a role model.