Now I work in a software vendor company, in particular access control solutions. And my experience "from a past life" is connected with the customer side - a large financial organization. At that time, our access control team in the information security department could not boast of large competencies in IdM. We learned a lot in the process, we had to get a bunch of bumps to build a working mechanism for managing user rights in information systems in the company.
ITKarma picture
By combining my customer’s experience with vendor knowledge and competencies, I want to share step-by-step instructions with you: how to create a role model of access control in a large company, and what it will produce in the end. My instruction consists of two parts: the first - we are preparing to build a model, the second - we are actually building. Here is part one, the preparatory.

N.B. Building a role model is, unfortunately, not a result, but a process. Or rather, even part of the process of creating an access control ecosystem in a company. So tune in the game for a long time.

First, let's decide - what exactly is role-based access control? Suppose you have a large bank with dozens, or even hundreds of thousands of employees (entities), each of which has dozens of access rights to hundreds of intra-bank information systems (facilities). And now multiply the number of objects by the number of subjects - just as many connections you need to build at least first, and then control. Really do it manually? Of course not - roles have appeared to solve this problem.

A role is a set of permissions that a user or group of users needs to perform certain work tasks. Each employee can have one or more roles, and each role can contain from one to many privileges that are allowed to the user within this role. Roles can be tied to specific positions, units, or functional tasks of employees.

ITKarma picture

Roles are usually created from the individual employee credentials in each information system. Then global business roles are formed from the roles of each system. For example, the business role of “credit manager” will include several separate roles in the information systems that are used in the client’s office of the bank. Say, in such as the main automated banking system, cash register module, electronic document management system, service manager and others. Business roles are usually tied to the organizational structure - in other words, to the set of company divisions and positions in them. This is how the global role matrix is ​​formed (I give an example in the table below).

ITKarma picture

It is worth noting that it is simply impossible to build a 100% role model, providing all the necessary rights for the employees of each position in the commercial structure. Yes, this is not necessary. After all, a role model cannot be static, because it depends on a constantly changing environment. And from a change in the business activities of the company, which, accordingly, affects the change in organizational structure and functionality. And from the lack of full provision of resources, and from non-compliance with job descriptions, and from the desire for profit to the detriment of security, and from many other factors. Therefore, it is necessary to build a role model that can cover up to 80% of users' needs for the necessary basic rights when they are appointed to the post. And they will be able to question the remaining 20%, if necessary, later on on separate applications.

Of course, you may ask: “But what, doesn’t there be 100% role models at all?” Well, why, this is found, for example, in non-profit structures that are not subject to frequent changes - in some research institute. Or in defense industry organizations with a high level of security, where security comes first. It happens in a commercial structure, but within a single unit, whose work is a fairly static and predictable process.

The main advantage of role management is the simplification of the issuance of rights, because the number of roles is much less than users of an information system. And this is true for any industry.

Take a retail company: thousands of sellers work in it, but the set of rights in the N system is the same, and only one role will be created for them. A new seller came to the company - he was automatically assigned the necessary role in the system, in which there are already all the necessary powers. Also in one click you can change the rights for thousands of sellers at once, for example, add a new option to generate a report. You don’t have to do a thousand operations, linking a new right to each account - just add this option to the role and it will appear for all sellers at the same time.

Another advantage of role management is the exclusion of incompatible credentials. That is, an employee who has a certain role in the system cannot simultaneously have another role whose rights should not be combined with the rights in the first. A striking example is the ban on combining the functions of input and control of a financial transaction.

Everyone who is interested in how role-based access control appeared in general can
dive for an excursion into history
If we turn to history, then for the first time the IT community thought about access control methods back in the 70s of the XX century. Although the applications were then quite simple, but, as now, everyone really wanted to conveniently control access to them. Provide, change and control user rights - just to make it easier to understand what access each of them has. But at that time there were no common standards, the first access control systems were being developed, and each company was based on its own ideas and rules.

Now many different access control models are already known, but they did not appear right away. Let us dwell on those who made a tangible contribution to the development of this direction.

The first and probably the simplest model is the Discretionary access control (DAC) . This model involves the sharing of rights by all participants in the access process. Each user gets access to specific objects or operations. In fact, here a lot of subjects of rights correspond to many objects. Such a model was considered too flexible and too complex to maintain: access lists become huge and difficult to control over time.

The second model is the Mandatory Access Control (MAC) . According to this model, each user gets access to the object in accordance with the issued admission to a particular level of data confidentiality. Accordingly, objects should be categorized by level of confidentiality. Unlike the first flexible model, this one, on the contrary, turned out to be too strict and restrictive. Its application does not justify itself when a company has a wide variety of information resources: in order to differentiate access to different resources, it is necessary to introduce many categories that will not overlap.

Due to the obvious imperfection of these two methods, the IT community continued to develop models that are more flexible and at the same time more or less universal to support different types of organizational access control policies. And then the third role-based access control model appeared! This approach turned out to be the most promising, since it requires not only authorization of the user's identity, but also its working functions in the systems.

The first clearly described structure of the role model was proposed by American scientists David Ferrailo and Richard Kuhn from the United States National Institute of Standards and Technology in 1992. Then the term RBAC (Role-based access control) first appeared. These studies and descriptions of the main components, as well as their interconnections, formed the basis of the INCITS 359-2012 standard valid to this day, approved by the International Committee for Information Technology Standards (INCITS).

The standard defines a role as “a job function in the context of an organization with some associated semantics regarding the authority and responsibility assigned to the user assigned to the role”.The document establishes the basic elements of RBAC - users, sessions, roles, permissions, operations and objects, as well as the relationships and relationships between them.

The standard gives the minimum necessary structure for building a role model - combining rights in roles and then issuing access to users through these roles. The mechanisms for compiling roles from objects and operations are indicated, the hierarchy of roles and the inheritance of powers are described. Indeed, in any company there are roles that combine the elementary powers that are necessary for all employees of the company. This can be access to e-mail, to EDMS, to a corporate portal, etc. These powers can be included in one common role called “employee”, and it will not be necessary to list all elementary rights over and over in each of the roles of a higher level. Just indicate the inheritance of the employee role.

ITKarma picture

Later, the standard was supplemented with new access attributes associated with an ever-changing environment. Added the ability to introduce static and dynamic constraints. Static imply the impossibility of combining roles (the very input and control of operations mentioned above). Dynamic restrictions can be determined by changing parameters, for example, time (working/non-working hours or days), location (office/home), etc.

Separately, it is worth mentioning about Attribute-based access control (ABAC). The approach is based on providing access using attribute sharing rules. This model can be used separately, but quite often it actively complements the classic role-playing: you can add attributes of users, resources and devices, as well as time or location to a certain role. This allows you to use fewer roles, introduce additional restrictions and make access minimally sufficient, and therefore increase security.

For example, an accountant can be allowed access to accounts if he works in a certain region. Then the location of the specialist will be compared with a specific reference value. Or you can give access to accounts only if the user logs in from a device entered in the allowed registry. A good addition to the role model, but it is rarely used on its own due to the need to create many rules and tables of permissions or restrictions.

I will give an example of the use of ABAC from my “past life”. There were several branches in our bank. Employees of client offices in these branches performed exactly the same operations, but had to work in the main system only with accounts in their region. First, we began to create separate roles for each region - and such roles with repeating functionality, but with access to different accounts, it turned out sooooo much! Then, using the location attribute for the user and associating it with a specific range of accounts for verification, we significantly reduced the number of roles in the system. As a result, roles remained for only one branch, which were replicated for relevant positions in all other territorial divisions of the bank.

Now let's talk about the necessary preparatory steps, without which it is simply impossible to build a working role model.

Step 1. Create a functional model

It’s worth starting with the creation of a functional model - a top-level document that describes in detail the functionality of each unit and each position. As a rule, information falls into it from various documents: job descriptions and regulations for individual units - departments, departments, departments. The functional model should be agreed with all interested departments (business, internal control, security) and approved by the company’s management. What is this document for? So that the role model could refer to it. For example, you are going to build a role model on the basis of the existing rights of employees - unloaded from the system and “reduced to a common denominator”. Then, when coordinating the received roles with the business owner of the system, you can refer to a specific paragraph of the functional model, based on which this or that right is included in the role.

Step 2.We audit IT systems and draw up a prioritization plan

At the second stage, an audit of IT systems should be carried out to understand how access is organized in them. For example, my financial company operated several hundred information systems. All systems had some rudiments of role-based management, most of them had some roles, but mostly on paper or in the system’s directory — they were outdated long ago, and access to them was granted upon actual user requests. Naturally, it is simply impossible to build a role model in several hundreds of systems at once, you have to start somewhere. We conducted an in-depth analysis of the access control process to determine its level of maturity. In the process of analysis, criteria were developed for prioritizing information systems - criticality, preparedness, plans for decommissioning, etc. With their help, they built the order of development/updating of role models for these systems. And then they included role models in the integration plan with the Identity Management solution to automate access control.

So, how to determine the criticality of the system? Answer the following questions:

  • Is the system connected with operational processes, the implementation of which depends on the core business of the company?
  • Will disruption of the system affect the integrity of company assets?
  • What is the maximum allowable downtime of a system after which it is impossible to restore activity after interruption?
  • Can a violation of the integrity of information in the system lead to irreversible consequences, both financial and reputational?
  • Criticality to fraud. The presence of functionality, with insufficient control of which, the implementation of internal/external fraudulent actions is possible;
  • What are the legal requirements and internal rules and procedures for these systems? Will there be fines from regulators for non-compliance?

In our financial company, we conducted an audit like this. The management developed an Access Right Review audit procedure to deal with existing users and rights first in those information systems that were on the list of top priority ones. The security unit has been designated the owner of this process. But to get the full picture of access rights in the company, it was necessary to connect IT and business units to the process. And here disputes, misunderstanding, and sometimes even sabotage began: no one wants to break away from their current duties and get involved in some, at first glance, incomprehensible activities.

NB Large companies with developed IT processes are probably familiar with the IT audit procedure - IT general controls (ITGС), which allows you to identify deficiencies in IT processes and establish control so as to improve processes in in accordance with best practice (ITIL, COBIT, IT Governance, etc.) This audit allows IT and business to better understand each other and develop a joint development strategy, analyze risks, optimize costs, and develop more effective approaches to work.

ITKarma picture

One of the areas of audit is the determination of the parameters of logical and physical access to information systems. We took the obtained data as a basis for further use in constructing a role model. As a result of such an audit, we had a registry of IT systems in which their technical parameters were determined and descriptions given. In addition, for each system, an owner was determined from the business area in whose interests it was operated: it was he who was responsible for the business processes that this system serviced. An IT service manager was also appointed, responsible for the technical implementation of business needs in a specific IP. The most critical systems for the company and their technical parameters, terms of commissioning and decommissioning, etc. were recorded. These parameters helped a lot in the process of preparing for the construction of a role model.

Step 3 Create a Methodology

The key to success of any business is the right method. Therefore, to build a role model and to conduct an audit, we need to create a methodology in which we describe the interaction between departments, consolidate responsibility in company regulations, etc.
First you need to examine all the available documents that establish the procedure for granting access and rights. In a good way, processes should be documented at several levels:

  • general corporate requirements;
  • requirements for areas of information security (depending on the activities of the organization);
  • process requirements (instructions, access matrices, guidelines, configuration requirements).

In our financial company, we found a lot of outdated documents - we had to bring them in line with the new processes being introduced.

By order of the leadership, a working group was created, which included representatives of the areas of security, IT, business and internal control. The order outlined the goals of creating the group, the direction of activity, the period of existence and the responsibilities of each side. In addition, we developed a methodology for conducting an audit and an order to build a role model: they were agreed by all the responsible representatives of the areas and approved by the company management.

Documents describing the order of work, terms, responsibility, etc. - the guarantee that on the way to the cherished goal, which at first is not obvious to everyone, no one will have questions "why are we doing this, why do we need it, etc." and you won’t be able to "jump off" or slow down the process.

ITKarma picture

Step 4. We fix the parameters of the existing access control model

We compose the so-called "system passport" in terms of access control. In fact, this is a questionnaire on a specific information system in which all the algorithms for controlling access to it are recorded. Companies that have already implemented IdM class solutions are probably familiar with such a questionnaire, since it is with it that the study of systems begins.

Some of the parameters about the system and owners flowed into the questionnaire from the IT registry (see step 2, audit), but new ones were added:

  • how to manage accounts (directly in the database or through program interfaces);
  • how users log in (using a separate account or using an AD, LDAP, or other account);
  • what levels of access to the system are used (application level, system level, use of network file resources by the system);
  • description and parameters of the servers on which the system is running;
  • what account management operations are supported (lock, rename, etc.);
  • by which algorithms or rules the system user identifier is generated;
  • what attribute can be used to establish a connection with the employee record in the personnel system (name, personnel number, etc.);
  • all possible account attributes and rules for filling them out;
  • what access rights exist in the system (roles, groups, atomic rights, etc., whether there are nested or hierarchical rights);
  • mechanisms for sharing access rights (by position, unit, function, etc.);
  • whether there are Segregation of Duties rules in the system, and how they work;
  • how events of absence, transfer, dismissal, updating data about employees, etc. are processed in the system

You can continue this list with details on various parameters and other objects that are involved in the access control process.

Step 5. Create a business-oriented description of authority

Another document that we will need when building a role model is a guide to all possible powers (rights) that can be provided to users in the information system with a detailed description of the business function that stands behind it. Often the authority in the system is encrypted with certain names consisting of letters and numbers, and business employees cannot figure out what is behind these symbols. Then they go to the IT service, and there... they also cannot answer the question, for example, on rarely used rights. Then you have to conduct additional testing.

It’s good if the business description already exists or even there is an association of these rights into groups and roles.For some applications, the best practice is to create such a directory even at the stage of their development. But this is not common, so again we go to the IT department to collect information about all possible rights and describe them. Our guide will ultimately contain the following:

  • name of the authority, including the object to which the right of access applies;
  • the action that is allowed to be done with the object (viewing, changing, etc., the possibility of restriction, for example, on a territorial basis or on a group of clients);
  • authority code (code and name of the function/request of the system that can be executed using the authority);
  • description of authority (a detailed description of actions in the IP when applying authority and their consequences for the process;
  • permission status: Active (if the permission is assigned to at least one user) or Inactive (if the permission is not used).

Step 6 Unload user and rights data from the systems and compare it with the personnel source

At the final stage of preparation, you need to unload data from information systems about all the users and the rights that they currently have. Two scenarios are possible here. First: the security division has direct access to the system and there are means for uploading the relevant reports, which is rare, but very convenient. Second: send a request to IT to receive reports in the desired format. Practice shows: it is not possible to agree with IT and get the necessary data the first time. It is necessary to make several approaches until the information is received in the right form and format.

What data needs to be uploaded:

  • Account Name
  • Name of the employee to whom she is assigned
  • Status (active or blocked)
  • Account Creation Date
  • Last used date
  • List of available rights/groups/roles

So, we got the unloading from the system with all users and with all the rights that are granted to them. And immediately all the blocked accounts were put aside, since the work on building a role model will be carried out only for active users.

Then, if your company does not have automated means of closing access to dismissed employees (this is often the case) or there is patchwork automation that does not always work correctly, you need to identify all the "dead souls". We are talking about the accounts of already dismissed employees whose rights are not blocked for some reason - they need to be blocked. To do this, we compare the downloaded data with the personnel source. Personnel unloading, too, must first be obtained from the unit leading the personnel base.

Separately, it is necessary to postpone accounts whose owners were not found in the personnel base, not assigned to anyone, that is, ownerless. For this list we will need the date of the last use: if it is quite fresh, then you still have to look for owners. This may include accounts of external contractors or official records that are not assigned to anyone, but are associated with any processes. To determine the ownership of the accounts, you can send letters to all departments asking them to respond. When the owners are found, we enter the data about them into the system: in this way all valid accounts are identified, and the rest are blocked.

As soon as our uploads are cleared of unnecessary records and there are only active accounts left, we can begin to build a role model for a specific information system. But I’ll talk about this in the next article.

Posted by Lyudmila Sevastyanova, Solar inRights Promotion Manager .