We build a role-based access control model. Part one, preparatory

Now I work for a software vendor, in particular for access control solutions. And my “past life” experience is connected with the customer's side - a large financial organization. At that time, our group for access control in the information security department could not boast of great competencies in IdM. We learned a lot in the process, we had to fill a bunch of bumps in order to build a working mechanism for managing user rights in information systems in the company.



Having combined my experience gained in the customer with vendor knowledge and competencies, I want to share with you essentially step-by-step instructions: how to create a role-based access control model in a large company, and what it will give in the end. My instruction consists of two parts: first - we are preparing to build a model, second - we are actually building. Here is part one, preparatory.



NB 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 the company. So tune in for the long term.



First, let's define - what is role-based access control? Suppose you have a large bank with tens or even hundreds of thousands of employees (subjects), each of which has tens of access rights to hundreds of intra-bank information systems (objects). Now multiply the number of objects by the number of subjects - that is the minimum number of connections you need to first build and then control. Is it realistic to do this manually? Of course not - roles 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 permissions that are allowed to a user within this role. Roles can be tied to specific positions, departments or functional tasks of employees.







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







It is worth noting that it is simply impossible to build a 100% role model, providing all the necessary rights to employees of each position in a commercial structure. Yes, it is not necessary. After all, a role model cannot be static, because it depends on a constantly changing environment. And from the change in the company's business activities, which, accordingly, affects the change in the 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 at the expense of safety, and from many other factors. Therefore, it is necessary to build a role model that can cover up to 80% of the needs of users for the necessary basic rights when they are appointed to a position. And they will be able, if necessary, to request the remaining 20% ​​later on separate requests.



Of course, you can ask: "What, there are no 100% role models?" Well, why does this happen, for example, in non-profit structures that are not subject to frequent changes - in some research institute. Or in military-industrial complex organizations with a high level of security, where security comes first. It also happens in a commercial structure, but within the framework of a separate unit, the work of which is a fairly static and predictable process.



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



Take a retail company: it employs thousands of salespeople, but they have the same set of rights in the N system, 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, which already has all the necessary powers. You can also change the rights for thousands of sellers in one click, for example, add a new option for generating a report. You don't need to do a thousand operations, linking a new right to each account - you just need to add this option to the role, and it will appear for all sellers at the same time.



Another advantage of role-based management is the elimination of the issuance of incompatible powers. That is, an employee who has a certain role in the system cannot simultaneously have another role, the rights of which should not be combined with the rights in the first. A striking example is the prohibition on combining the functions of entering and controlling a financial transaction.



Anyone interested in how role-based access control came about can

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 is worth starting with the creation of a functional model - a top-level document that describes in detail the functionality of each department and each position. As a rule, information comes into it from various documents: job descriptions and regulations for individual divisions - departments, departments, departments. The functional model must be agreed with all interested departments (business, internal control, security) and approved by the company management. What is this document for? So that the role model can refer to it. For example, you are going to build a role model based on the existing employee rights - unloaded from the system and "brought to a common denominator. Then, when coordinating the received roles with the business owner of the system, you can refer to a specific item of the functional model,on the basis of which this or that right is included in the role.

2. -

The second step is to conduct an audit of IT systems to understand how access is organized to them. For example, my financial company was running several hundred information systems. All systems had some rudiments of role-based management, most of them had some kind of roles, but mostly on paper or in the system's manual - they were outdated long ago, and access to them was distributed on the basis of actual user requests. Naturally, it is simply impossible to build a role model in several hundred systems at once, you have to start somewhere. We conducted an in-depth review of the access control process to determine its maturity level. During the analysis, criteria for prioritizing information systems were developed - criticality, readiness, decommissioning plans, etc.With their help, we have built a sequence for the development / updating of role models for these systems. And then we included role models in our Identity Management integration plan to automate access control.



So how do you determine the criticality of a system? Answer yourself the following questions:

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

In our financial company, we conducted an audit as follows. Management has developed an Access Right Review audit process to deal with existing users and rights first on the top priority information systems. The security unit was designated as the owner of this process. But to get a complete picture of access rights in the company, it was necessary to involve the IT and business departments in the process. And here disputes, misunderstandings, 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 - - – IT general controls (ITG), - , best practice (ITIL, COBIT, IT Governance .) , , , .







One of the areas of audit is to determine the parameters of logical and physical access to information systems. We took the obtained data as a basis for further use in building a role model. As a result of such an audit, we got a register of IT systems, in which their technical parameters were determined and descriptions were given. In addition, for each system, an owner from the business line was identified, in whose interests it was operated: it was he who was responsible for the business processes that this system served. An IT service manager was also appointed, responsible for the technical implementation of business needs in a specific IS. The most critical systems for the company and their technical parameters, terms of commissioning and decommissioning, etc. were recorded.These parameters were very helpful in preparing to build the role model.

Step 3 Create a methodology

The key to the success of any business is the right method. Therefore, both to build a role model and to conduct an audit, we need to create a methodology in which we describe the interaction between departments, fix responsibility in the company's regulations, etc.

First, you need to examine all the available documents that establish the procedure for granting access and rights. In an amicable way, processes should be documented at several levels:

• general corporate requirements;
• requirements for the areas of information security (depending on the areas of activity of the organization);
• requirements for technological processes (instructions, access matrices, guidelines, requirements for configurations).

In our financial company, we found many outdated documents - we had to bring them in accordance with the new processes being introduced.



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



Documents describing the procedure for carrying out work, terms, responsibility, etc. - a guarantee that on the way to the cherished goal, which at first is not obvious to everyone, no one will have any questions "why are we doing this, why do we need it, etc." and there will be no opportunity to "jump off" or slow down the process.

Step 4. Fix the parameters of the existing access control model

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



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

• how accounts are managed (directly in the database or through software interfaces);
• how users log into the system (using a separate account or using an AD account, LDAP, etc.);
• what levels of access to the system are used (application level, system level, system use of network file resources);
• , ;
• (, ..);
• ;
• (, .);
• ;
• (, , ., );
• ( , , .);
• (SOD – Segregation of Duties), ;
• , , , ..

The list goes on and on, detailing the various parameters and other objects that are involved in the access control process.

Step 5. Create a business-oriented authorization description

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 is behind it. Often, authority in the system is encrypted with certain names consisting of letters and numbers, and business employees cannot figure out what lies behind these symbols. Then they go to the IT service, and there ... they also cannot answer the question, for example, about rarely used rights. Then you have to conduct additional testing.



It is good if the business description already exists or even there is a combination of these rights into groups and roles. For some applications, it is best practice to create such a reference at the design stage. But this happens infrequently, so again we go to the IT department to collect information about all possible rights and describe them. Our guide will eventually contain the following:

• the name of the authority, including the object to which the access right applies;
• the action that is allowed to be done with the object (viewing, changing, etc., the possibility of restriction, for example, by a territorial basis or by a group of clients);
• authorization code (code and name of the function / system request that can be executed using the authorization);
• description of authority (detailed description of actions in IS when applying authority and their consequences for the process;
• : «» ( ) « » ( ).

6

At the final stage of preparation, you need to download data from information systems about all users and the rights that they have at the moment. Two scenarios are possible here. First, the security department has direct access to the system and has a means of uploading the relevant reports, which is rare, but very convenient. Second: we send a request to IT to receive reports in the required format. Practice shows that it is not possible to negotiate with IT and get the necessary data the first time. Several approaches must be taken until the information is received in the desired form and format.



What data needs to be downloaded:

• Account name
• Full name of the employee to whom it is assigned
• Status (active or locked)
• Account creation date
• Date of last use
• List of available rights / groups / roles

So, we received unloads from the system with all users and with all the rights that were granted to them. And immediately put aside all blocked accounts, 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 a 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 must also first be obtained from the unit leading the personnel base.



Separately, it is necessary to postpone the accounts, the owners of which were not found in the personnel base, not assigned to anyone - that is, ownerless. According to this list, we need the date of last use: if it is fairly recent, then we still have to look for the owners. This may include accounts of external contractors or service accounts that are not assigned to anyone, but are associated with any processes. To find out the ownership of the accounts, you can send letters to all departments with a request to respond. When the owners are found, we enter data about them into the system: in this way, all existing 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, you can start building a role model for a specific information system. But I will talk about this in the next article.



Author: Lyudmila Sevastyanova, Promotion Manager, Solar inRights