Now I work for 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 institution. At that time, our access control group 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.
Combining my experience gained in the customer with vendor knowledge and competencies, I want to share with you essentially a step-by-step instruction: 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: the first - we are preparing to build a model, the second - we actually build it. Before you part one, preparatory.
Note 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 to the game for a long time.
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 dozens of access rights to hundreds of intra-bank information systems (objects). And now multiply the number of objects by the number of subjects - that is how many connections at least you need to build first, and then control. Is it really possible to do it 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 one to many permissions that are allowed to a user within that role. Roles can be tied to certain 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, the business role "loan manager" will include several separate roles in information systems that are used in the bank's client office. For example, in such as the main automated banking system, cash register, electronic document management system, service manager and others. Business roles, as a rule, are tied to the organizational structure - in other words, to a 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 for employees of each position in a commercial structure. Yes, this is not necessary. After all, the role model cannot be static, because it depends on the constantly changing environment. And from a 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 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 a position. And the remaining 20% they will be able, if necessary, to interrogate later on separate applications.
Of course, you can ask: “What, there are no 100% role models at all?” Well, why, this happens, 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 happens, and in a commercial structure, but within the framework of a single unit, the work of which is a fairly static and predictable process.
The main advantage of role-based management is the simplification of the issuance of rights, because the number of roles is significantly less than the number of users of the information system. And this is true for any industry.
Let's 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. Also, in one click, you can change the rights for thousands of sellers at once, 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 - just 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 avoidance of incompatible permissions. 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 one. A striking example is the ban on combining the functions of input and control of a financial transaction.
Anyone who is interested in how role-based access control came about in the first place can
dive 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 applications were then quite simple, but, as now, everyone really wanted to conveniently manage access to them. Grant, 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.
Many different access control models are now known, but they did not appear immediately. Let us dwell on those who have made a tangible contribution to the development of this direction.
The first and probably the simplest model is Discretionary (Selective) Access Control (DAC - Discretionary access control). This model implies the sharing of rights by all participants in the access process. Each user gets access to specific objects or operations. In fact, here the set of subjects of rights corresponds to the set of objects. This model was found to be too flexible and too difficult to maintain: access lists become huge and difficult to control over time.
The second model is Mandatory access control (MAC). According to this model, each user gets access to the object in accordance with the issued access to a particular level of data confidentiality. Accordingly, objects should be categorized according to the level of confidentiality. Unlike the first flexible model, this one, on the contrary, turned out to be too strict and restrictive. Its use does not justify itself when the company has a lot of various information resources: in order to delimit access to different resources, you will have to introduce many categories that will not overlap.
Due to the obvious imperfection of these two methods, the IT community has 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 that's when it appeared the third model of role-based access control! This approach turned out to be the most promising, since it requires not only authorization of the user's identity, but also his work functions in the systems.
The first well-described role model structure was proposed by American scientists David Ferrailo and Richard Kuhn of the US National Institute of Standards and Technology in 1992. Then the term first appeared RBAC (Role-based access control). These studies and descriptions of the main components, as well as their relationships, formed the basis of the INCITS 359-2012 standard, which is 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 provides 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 composing roles from objects and operations are outlined, the hierarchy of roles and the inheritance of powers are described. Indeed, in any company there are roles that combine elementary powers that are necessary for all employees of the company. This may be access to e-mail, to the EDMS, to the corporate portal, etc. These permissions can be included in one general role called "employee", and it will not be necessary in each of the higher-level roles to list all the elementary rights over and over again. It is enough just to indicate the sign of inheritance of the "employee" role.
Later, the standard was supplemented with new access attributes related to the ever-changing environment. Added the ability to introduce static and dynamic restrictions. Static ones imply the impossibility of combining roles (the same input and control of operations mentioned above). Dynamic limits can be defined by changing parameters such as time (working/non-working hours or days), location (office/home) and the like.
Separately worth saying about Attribute-based access control (ABAC). The approach is based on granting access using attribute sharing rules. This model can be used separately, but quite often it actively complements the classic role model: you can add attributes of users, resources and devices, as well as time or location to a specific 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 certain reference value. Or you can give access to accounts only if the user logs in from a device entered in the register of allowed ones. A good addition to the role model, but 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". Our bank had several branches. 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 started creating separate roles for each region - and there were sooo many such roles with repetitive functionality, but with access to different accounts! Then, by using a location attribute for a user and linking it to a specific range of accounts to check, we significantly reduced the number of roles in the system. As a result, roles remained for only one branch, which were replicated for the corresponding positions in all other territorial divisions of the bank.
And 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 unit and each position. As a rule, information enters it from various documents: job descriptions and regulations for individual divisions - divisions, departments, departments. The functional model must 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 can refer to it. For example, you are going to build a role model based on the existing rights of employees - unloaded from the system and “reduced to a common denominator”. Then, when agreeing on the received roles with the business owner of the system, one can refer to a specific item of the functional model, on the basis of 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 in order to understand how access to them is organized. For example, my financial company operated several hundred information systems. In all systems there were some rudiments of role management, in most - some roles, but mostly on paper or in the system directory - they are long outdated, and access to them was distributed at the 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 analysis of the access control process to determine its level of maturity. In the process of analysis, criteria for prioritizing information systems were developed - criticality, readiness, plans for decommissioning, etc. With their help, we built a sequence for the development / updating of role models for these systems. And then - included role models in the plan for integrating with the Identity Management solution to automate access control.
So, how to determine the criticality of the 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 downtime of the system, after reaching 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. The presence 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 penalties from regulators for non-compliance?
In our financial company, we conducted an audit like this. Management has developed an Access Right Review audit procedure to deal with existing users and rights first on those information systems that are on the top priority list. The security department has been assigned the owner of this process. But in order to get a complete picture of the access rights in the company, it was necessary to involve 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.
Note Large companies with developed IT processes are probably familiar with the IT audit procedure - IT general controls (ITGC), which allows you to identify shortcomings in IT processes and establish control so as to improve processes in accordance with best practice (ITIL, COBIT, IT Governance etc.) Such an audit allows IT and business to better understand each other and develop a joint development strategy, analyze risks, optimize costs, and develop more efficient approaches to work.
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 have a register of IT systems, in which their technical parameters were determined and descriptions were given. In addition, for each system, an owner was determined from the business direction 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, commissioning and decommissioning dates, etc. were recorded. These parameters helped a lot in the process of preparing for building a 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 will describe the interaction between departments, fix 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 the areas of information security (depend on the activities of the organization);
- requirements for technological processes (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 management, a working group was created, which included representatives from 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 have developed an audit methodology 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, deadlines, responsibilities, etc. - a 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 there will be no opportunity to “jump off” or slow down the process.
Step 4. Fixing 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 on a specific information system, in which all algorithms for managing 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 have flowed into the questionnaire from the IT registry (see step 2, audit), but new ones have been added:
- how accounts are managed (directly in the database or through program interfaces);
- how users log in to 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, 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 (blocking, renaming, etc.);
- what algorithms or rules are used to form the system user identifier;
- what attribute can be used to establish a link with a record about an employee in the personnel system (full 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., are there nested or hierarchical rights);
- mechanisms for separating access rights (by positions, divisions, functionality, etc.);
- whether the system has rules for segregation of rights (SOD - Segregation of Duties), and how they work;
- how events of absence, transfer, dismissal, update of employee data, etc. are processed in the system.
The list could go on, detailing the various parameters and other entities 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 the possible powers (rights) that can be granted to users in an information system with a detailed description of the business function that stands behind it. Often the powers in the system are encrypted with certain names, consisting of letters and numbers, and business employees cannot figure out what lies behind these characters. 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 do more testing.
It's good if there is already a business description or even if there is an association of these rights into groups and roles. For some applications, the best practice is to create such a guide at the development stage. But this does not happen often, 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, on a territorial basis or on a group of clients);
- authority code (code and name of the system function/request that can be executed using the authority);
- description of the authority (a detailed description of the actions in the IS when applying the authority and their consequences for the process;
- permission status: "Active" (if the permission is assigned to at least one user) or "Not active" (if the permission is not used).
Step 6 We unload data about users and rights from the systems and compare it with the personnel source
At the final stage of preparation, you need to upload data from information systems about all users and the rights that they currently have. Two scenarios are possible here. First, the security department has direct access to the system and has the means to download 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. It is necessary to make several approaches until the information is received in the desired form and format.
What data needs to be uploaded:
- Account name
- Name of the employee to whom it is assigned
- Status (active or blocked)
- Account creation date
- Last used date
- List of available rights/groups/roles
So, we have received unloadings from the system with all users and with all the rights that are granted to them. And they immediately put aside all blocked accounts, since 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 fired employees (this is not uncommon) 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 for some reason are not blocked - they need to be blocked. To do this, we compare the uploaded data with the personnel source. Personnel unloading must also be obtained in advance from the unit leading the personnel base.
Separately, it is necessary to set aside accounts whose owners were not found in the personnel base, not assigned to anyone - that is, ownerless. For this list, we need the date of the last use: if it is quite 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 clarify the ownership of the account, 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 active accounts are identified, and the rest are blocked.
As soon as our uploads are cleared of unnecessary records and only active accounts remain, we can begin to build a role model for a specific information system. But I will talk about this in the next article.
Author: Lyudmila Sevastyanova, Solar inRights Promotion Manager
Source: habr.com