IdM implementation. Part 3.2. How to build an access model?
In previous materials we looked at what IdM is , what are the signs of the need to implement IdM , and also outlined the need to set goals and objectives (i.e., what you and business want from an access control system).
And in the previous part, we noted how important it is to offer a prepared and thoughtful solution to business. It should be based on the study of the problem, should be consistent with the needs of this particular business, include a specific approach to achieving the goals set and describe the level of involvement of each of the stakeholders.
However, before presenting the management with a ready-made version (or several options to choose from), one should understand “which goat to drive up” to solve the problem revealed during the initial audit of the situation in the company.
')
There are a lot of approaches to the management of user accounts and user rights, as well as variations in the implementation of IdM solutions (yes, there are many of them, but this is covered in another article). Focusing on what is most often used, and determine the options that are suitable for you.
First of all, let us refer to the fact that various standards, libraries and codes of knowledge are mentioned in relation to access control. Here, the fundamental concepts are “ confidentiality ” (confidentiality), “ integrity ” (integrity) and “ availability ” (availability).
CIA is a triad of information security.
Why is this all you need to remember? Usually from the IS triad, one of the concepts is defined as a focus:
For each information system or business process, the decision can be made independently. The main thing - then do not get confused, what and where was chosen.
It is also worth remembering the following concepts: “ identification ” (identification), “ authentication ” (authentication), “ authorization ” (authorization), “ accountability ” (responsibility for their actions / accountability) and “nonrepudiation” (inability to refuse authorship).
What for? It is important to understand:
After clearing the above basic questions, let's move on to the point at which to begin the work on access control.
The main points that are useful to pay attention to are the maturity model of access control processes and the approach to building an access model .
Do you want to make the access control process truly transparent and controllable, identify and process the relevant risks, put the process on stream? To come to this, you first need to figure out how employees currently use their accounts, how they get them, after what events access is blocked, etc.
When we fixed (better, of course, to somehow write down what we were able to find out) the obtained data, we need to make a plan to achieve the goal.
You can build on the maturity model of access control processes : ( based on EY research )
To begin with, mark at what level of maturity your company is located, and determine how you can improve existing positions.
(!) Important: do not “jump over” the level, it is better to go to more mature processes gradually. You can make a long-term plan to improve the processes, gradually and progressively follow it.
In addition to the maturity model, an approach to form an access model should be taken into account.
Perhaps, about the need for a role model in the context of implementing IdM solutions, we are asked most often, although there are other approaches. Consider first what is the role and role model.
In my opinion, on a company scale, building such a role model, where each employee has only one role, due to his official duties and not having any additional access rights, is utopia. There is a chance to determine the most typical roles in a company: it is normal for a bank to have a large number of tellers and cashiers, in retail - salespeople, managers for promotion, freezing, etc., for production - engineers and analysts. But here everything is not so simple. We can easily determine which business system a user should have access to (for example, the sales manager needs a domain account, mail, CRM and EDMS), but it is not always possible to determine which access rights are needed in each of the systems.
Therefore, based on the realities, I would suggest the following steps to help build an access model :
Step 1. The minimum set of rights. We determine which systems are used by all employees (except for personnel who do not have access to IT systems at all). So we will understand which accounts to start all.
Step 2. Basic access. We look at large groups of users (formally, they may not be from one department): advertisers / marketers / PR, IT / IB, accounting, sales managers, etc. These employees are defining typical systems for creating accounts and minimum rights in each of the systems.
Step 3. We try to typify access in the context of departments (integration can be chosen - department, office, department, etc.)
Step 4. Now let's understand what typical roles are inside divisions. There may be few of them. In some cases, you can be guided by job titles, but not for every company it will work. You know that it can be difficult to distinguish the functionality of the specialists sitting at the adjacent tables, one of whom is the leading one and the other is the main one. Often they do the same job, and the only difference is in which positions were vacant at the time of their employment in the company. The reverse situation is also encountered - two analysts work in the same department, but in different areas of activity, and they do not have access to systems (except for the resources from step 1).
Step 5. Identification of unnecessary and conflicting rights. In the first four steps, we looked at the actual access rights. But we must bear in mind that some rights may be redundant or conflicting. This means that the result must be checked (and not just one) in order to identify outdated access rights, which are issued “ just in case ” and “ because we give it to everyone ”.
It is important to consider not only individual access rights (rights, groups of rights, roles in each target system), but also the entire set in order to understand whether a set of rights does not allow doing something that goes beyond the authority of an employee.
At first glance, everything is simple. Just how to collect all the necessary information? The audit can be carried out for a long time, and the data that is required from 3-4 steps, quickly become obsolete.
In this case, an IdM solution can help, which will accumulate information about the access rights of each employee, and which will provide a tool to analyze the presence of accounts (and in some cases, the frequency of their use) and access rights for all five sections described above.
Thus, an IdM solution is not only a means of automating routine operations, but also an important tool for controlling and analyzing employee access rights. More on this in the next article.
And in the previous part, we noted how important it is to offer a prepared and thoughtful solution to business. It should be based on the study of the problem, should be consistent with the needs of this particular business, include a specific approach to achieving the goals set and describe the level of involvement of each of the stakeholders.
However, before presenting the management with a ready-made version (or several options to choose from), one should understand “which goat to drive up” to solve the problem revealed during the initial audit of the situation in the company.
')
There are a lot of approaches to the management of user accounts and user rights, as well as variations in the implementation of IdM solutions (yes, there are many of them, but this is covered in another article). Focusing on what is most often used, and determine the options that are suitable for you.
First of all, let us refer to the fact that various standards, libraries and codes of knowledge are mentioned in relation to access control. Here, the fundamental concepts are “ confidentiality ” (confidentiality), “ integrity ” (integrity) and “ availability ” (availability).
CIA is a triad of information security.
Why is this all you need to remember? Usually from the IS triad, one of the concepts is defined as a focus:
- We must first ensure confidentiality , i.e. to limit access to information as much as possible?
- Or need data integrity , and we will not give anyone the rights to modify?
- Or, perhaps most importantly, the availability of business applications and the risks associated with confidentiality and integrity, we are ready to accept?
For each information system or business process, the decision can be made independently. The main thing - then do not get confused, what and where was chosen.
It is also worth remembering the following concepts: “ identification ” (identification), “ authentication ” (authentication), “ authorization ” (authorization), “ accountability ” (responsibility for their actions / accountability) and “nonrepudiation” (inability to refuse authorship).
What for? It is important to understand:
- how the user is authenticated and authenticated (by login, token with certificate, fingerprint, etc.),
- do you need strong (multifactor) authentication,
- how is the authorization,
- whether an employee can do something, and then say that it is not him (for example, the situation when several employees work under one account is more common than we would like and what you think).
After clearing the above basic questions, let's move on to the point at which to begin the work on access control.
The main points that are useful to pay attention to are the maturity model of access control processes and the approach to building an access model .
Do you want to make the access control process truly transparent and controllable, identify and process the relevant risks, put the process on stream? To come to this, you first need to figure out how employees currently use their accounts, how they get them, after what events access is blocked, etc.
When we fixed (better, of course, to somehow write down what we were able to find out) the obtained data, we need to make a plan to achieve the goal.
You can build on the maturity model of access control processes : ( based on EY research )
To begin with, mark at what level of maturity your company is located, and determine how you can improve existing positions.
Example 1. The transition from the initial level to repeatable.
Given: the company has 650 employees, access is provided manually by administrators. Administrators 5 people: two are responsible for access to file servers, one for the network, one supports databases and one serves 3 business systems. Users turn to administrators mainly by phone, calls and calls are not kept, periodically there is confusion with access to network folders (“ access was not given there ”, “ access was and disappeared ”, “ I cannot find my folder ”, “ file disappeared ” etc.)
Possible solution: Review the structure of file servers and folders and optimize it. Then, delimit access by groups, prescribe or at least agree on the rules for granting access, and bring the rules to the users. Enter a fixation of user requests (variations - from logging by administrators when a user calls by phone to the introduction of Service Desk and IdM).
Possible solution: Review the structure of file servers and folders and optimize it. Then, delimit access by groups, prescribe or at least agree on the rules for granting access, and bring the rules to the users. Enter a fixation of user requests (variations - from logging by administrators when a user calls by phone to the introduction of Service Desk and IdM).
Example 2. Transition from a set level to a controlled one.
Given: The company has 2,000 employees. The process of providing access is fixed, users follow it, but from time to time there are situations when there are too many applications and access is provided with tremendous delays. The audit periodically reveals that the accounts of already dismissed employees, despite the security policies, remain active.
Possible solution: Automate routine operations (creating accounts, providing some access rights). Develop access control procedures with understandable and executable SLA (processes, tasks, executors, responsible ones, terms and conditions of fulfillment). Consider options for internal audit of user access (from monitoring compliance with procedures to the implementation of IdM and related solutions). Develop and implement a program for training performers and users (from reading the instructions to training videos and educational platform).
Possible solution: Automate routine operations (creating accounts, providing some access rights). Develop access control procedures with understandable and executable SLA (processes, tasks, executors, responsible ones, terms and conditions of fulfillment). Consider options for internal audit of user access (from monitoring compliance with procedures to the implementation of IdM and related solutions). Develop and implement a program for training performers and users (from reading the instructions to training videos and educational platform).
(!) Important: do not “jump over” the level, it is better to go to more mature processes gradually. You can make a long-term plan to improve the processes, gradually and progressively follow it.
In addition to the maturity model, an approach to form an access model should be taken into account.
Perhaps, about the need for a role model in the context of implementing IdM solutions, we are asked most often, although there are other approaches. Consider first what is the role and role model.
- Role - a set of rights and functional duties characteristic of an employee at a certain position, which is projected on the access of this employee to the company's information systems.
- Role model - a set of roles for company employees, allowing each of them to perform work in accordance with their work duties in the most efficient way.
In my opinion, on a company scale, building such a role model, where each employee has only one role, due to his official duties and not having any additional access rights, is utopia. There is a chance to determine the most typical roles in a company: it is normal for a bank to have a large number of tellers and cashiers, in retail - salespeople, managers for promotion, freezing, etc., for production - engineers and analysts. But here everything is not so simple. We can easily determine which business system a user should have access to (for example, the sales manager needs a domain account, mail, CRM and EDMS), but it is not always possible to determine which access rights are needed in each of the systems.
Therefore, based on the realities, I would suggest the following steps to help build an access model :
Step 1. The minimum set of rights. We determine which systems are used by all employees (except for personnel who do not have access to IT systems at all). So we will understand which accounts to start all.
Example
The most typical: domain (AD), mailbox, electronic document management. At this level, we define the minimum set of rights that is characteristic of the accounts in each of the systems.
Step 2. Basic access. We look at large groups of users (formally, they may not be from one department): advertisers / marketers / PR, IT / IB, accounting, sales managers, etc. These employees are defining typical systems for creating accounts and minimum rights in each of the systems.
Example
All IT and IB employees have access to Service Desk, and all sales managers have access to CRM, accounting and personnel have access to the personnel and accounting system (say, “1C: Salary and HR Management” or SAP).
Step 3. We try to typify access in the context of departments (integration can be chosen - department, office, department, etc.)
Example
Almost every department has a network share (disk, folder, cloud, etc.), shared access groups in AD or in business systems.
Step 4. Now let's understand what typical roles are inside divisions. There may be few of them. In some cases, you can be guided by job titles, but not for every company it will work. You know that it can be difficult to distinguish the functionality of the specialists sitting at the adjacent tables, one of whom is the leading one and the other is the main one. Often they do the same job, and the only difference is in which positions were vacant at the time of their employment in the company. The reverse situation is also encountered - two analysts work in the same department, but in different areas of activity, and they do not have access to systems (except for the resources from step 1).
Example
There is a manager in the subdivision who sends the reports through the SED, and he needs not only an account to SED, but also the corresponding rights to send the report. In this case, we can be guided by the position as a factor determining job responsibilities and access rights.
In the same subdivision there are analysts and engineers, access to certain systems (presence of accounts in the same systems) is necessary for everyone, but the level of access rights (rights, roles, access groups) should be different. In this case, specific sets of access rights in several information systems form the role for the analyst and the role for the engineer.
Of course, only access rights that are common to all analysts and all engineers of the unit in question are going to the role .
In the same subdivision there are analysts and engineers, access to certain systems (presence of accounts in the same systems) is necessary for everyone, but the level of access rights (rights, roles, access groups) should be different. In this case, specific sets of access rights in several information systems form the role for the analyst and the role for the engineer.
Of course, only access rights that are common to all analysts and all engineers of the unit in question are going to the role .
Step 5. Identification of unnecessary and conflicting rights. In the first four steps, we looked at the actual access rights. But we must bear in mind that some rights may be redundant or conflicting. This means that the result must be checked (and not just one) in order to identify outdated access rights, which are issued “ just in case ” and “ because we give it to everyone ”.
It is important to consider not only individual access rights (rights, groups of rights, roles in each target system), but also the entire set in order to understand whether a set of rights does not allow doing something that goes beyond the authority of an employee.
Example
We want to make a payment by requisites. To do this, contact the bank (imagine that we do not have online banking). The first step - the operator checks the documents and generates a payment order. The second step - the operator invites the second employee (controller) to check your documents and confirm the entered data and the operation. The third step is the cashier, where the cashier checks all the data and documents again and finally takes the money from you and makes a payment. Why is everything so difficult? For security. From the point of view of access rights to the ABS (a system where payments are made and recorded), each employee can perform only his own operations, and in order to steal the client’s money, one needs collusion or broad access rights to the ABS, allowing one employee to perform all of the indicated operations.
At first glance, everything is simple. Just how to collect all the necessary information? The audit can be carried out for a long time, and the data that is required from 3-4 steps, quickly become obsolete.
In this case, an IdM solution can help, which will accumulate information about the access rights of each employee, and which will provide a tool to analyze the presence of accounts (and in some cases, the frequency of their use) and access rights for all five sections described above.
Thus, an IdM solution is not only a means of automating routine operations, but also an important tool for controlling and analyzing employee access rights. More on this in the next article.
UPD. Read on:
Source: https://habr.com/ru/post/349170/
All Articles