Ruslan Rakhmetov, Security Vision
When managing information security in a company, one of the most important issues is choosing the right access control model. Depending on the applicable regulatory requirements and the company's needs, one can choose a discretionary, mandate, role-based or attribute-based access control model, as well as consider a number of less common approaches. In this article, we will briefly review the major access control models, but focus on the role-based security model and how it differs from the attribute-based model.
First, we should familiarise ourselves with the basic definitions. Thus, in the guiding document of the State Technical Commission of Russia (the predecessor regulator of the FSTEC of Russia) from 30 March 1992 ‘Protection against unauthorised access to information. Terms and Definitions’ gives the following definitions:
- An access subject is a person or process whose actions are governed by access delimitation rules;
- Access object is a unit of information resource of the automated system, access to which is regulated by the rules of access differentiation;
- Access delimitation rules are a set of rules regulating the access rights of access subjects to access objects.
The subject can be understood not only as a real user (in the form of an account assigned to a certain employee of the company), but also as a service user who is created to run processes, services, perform technical actions - for example, forwarding security logs or creating backups. In any case, service users must be assigned to a company employee (for example, a system administrator or an IS specialist), depersonalised (temporary or not assigned to a certain employee) and shared (the password for which is known to several employees at once) accounts must not be created, their passwords must be subject to the rules of the corporate password policy, and their authority in the systems must be regularly reviewed.
Both subjects and objects of access have attributes: for subjects these are properties of the account (user name, position, department, chain of command, etc.), and for objects these are properties of a file, information system, technical means. Access subjects have privileges (powers / permissions / access rights) - i.e. rights to perform certain operations with access objects (e.g. read, write, execute, add a new user, audit, etc.), which are regulated by access delimitation rules set by the company-owner of information in the access policy, and which can be performed only under certain specified conditions (e.g. successful authentication, connection from a certain VLAN of the corporate network, access during working hours). There are also attributes of the information system environment - current date and time, network properties (wireless/wired network, VLAN) and geographical belonging (GeoIP) of the access device, security level of the device (e.g., unpatched vulnerabilities) and infrastructure (e.g., number of unclosed cyber incidents), application and network port used, etc.
Authentication is the verification of the authenticity of the credentials presented by the subject (identifier / login, password, one-time code, biometrics), which is performed by a trusted party (system process, domain controller, authentication provider). Authorisation (access control) is a procedure for deciding whether to grant or deny a subject access to a protected access object, depending on compliance with the conditions and rules of access differentiation, with further granting the subject the necessary privileges to perform the requested operations.
In addition, it is important to remember the 8 principles of secure system architecture and implementation of protection mechanisms, which were formulated in 1975 by scientists Jerome Salzer and Michael Schroeder in the work ‘Information Protection in Computer Systems’:
1. Simplicity of defence mechanisms: the architecture of the security system should be as simple as possible;
2. default security: subject access should be denied by default, and defence mechanisms should define a limited set of conditions under which access will be allowed;
3. Fully mediated: every attempt to access an entity must pass through and be verified by defence mechanisms;
4. open architecture: the security architecture should not be secret (which is difficult to achieve and would make auditing the system more difficult), but should be based on secret keys and passwords (which are easier to protect);
5. Privilege separation: to access sensitive objects, the security mechanism should request confirmation from at least two independent entities (which makes it impossible for one person to perform critical actions);
6. Privilege minimisation: each subject should work in the system only with a limited set of privileges, the minimum necessary to perform work tasks;
7. Minimise the number of shared security mechanisms: the number of security mechanisms shared between actors should be minimised to reduce the number of likely points of failure and potential channels for uncontrolled information exchange between actors;
8. Psychological acceptability: it is important that the user interface of the defence mechanisms be understandable and convenient for access subjects (which reduces human error and simplifies the work with the system).
Access control model (access control model / access delimitation model / security model) is a system of control over compliance with the conditions and rules for delimiting and granting access of subjects to objects, designed to ensure information security of objects, audit access attempts and prevent unauthorised access to them. Access control models are implemented in the form of security mechanisms that provide the functionality of controlling and granting access on the basis of access delimitation rules. Access control rules describe possible access rights of subjects to objects, which are recorded in the form of an access control list (ACL, access control list) consisting of access control entries (ACE, access control entries). An ACL list can be represented as a set of ACE entries of the following form:
- user User1 has the rights to read, write, execute File1;
- user User2 is not allowed to write to file File2;
- the system with IP-address IP1 can access the system with IP-address IP2 on TCP:443 port on weekdays from 9:00 to 18:00.
The most popular access control models are:
1. Discretionary access control model (DAC, Discretionary Access Control), in which the owner of the object can independently set and change the access rights of subjects, as well as transfer the rights to manage the object to another subject. In modern information systems such an owner is usually an administrator who forms and changes the access matrix (a variant of ACL-list), which lists the subjects and defines their powers for all objects (e.g. read, write, execute). The discretionary model of access differentiation is used in most modern operating systems, but it has certain disadvantages:
- Difficulty in controlling access to objects due to multiple ACLs that can be reconfigured by owners in violation of IS policy, which can lead to unauthorised access and data leakage;
- Information confidentiality can be compromised if data is read from one file and then written to another file with a less stringent ACL;
- If the VPO is running in the context of a compromised account with administrator or object owner privileges, information confidentiality can be easily compromised;
- The complexity of access auditing, as it is necessary to go through all objects and obtain ACLs for each of them;
- The complexity of centralised management of ACLs for all objects across all company information systems.
2. Mandate Access Control (MAC, Mandatory Access Control) model, in which the security mechanism allows controlling and granting access based on the objects‘ privacy labels and the subjects’ form of admission. Thus, in the mandated security model there is a centralised independent access control mechanism and there is no owner who can change access rights at will. The access rules of the credential model are described, for example, as follows: User1 with Clearance3 has the right to read File1 with the Classification3 confidentiality label. This access model is used, as a rule, in state systems and is implemented in Linux (security modules SELinux, AppArmor) and in a number of certified Russian operating systems. The advantage of the mandate model is a high level of information protection from leaks, but the disadvantages include the complexity of configuration and difficulties in co-operation with other access control models in one system.
3. Role-Based Access Control (RBAC, Role-Based Access Control), in which access rights are granted not to individual subjects, but to certain roles that correspond to the functionality of business units and reproduce the organisational structure of the company. In contrast to the mandate model, the role-based security model is more focused on controlling access to applications, business functions and information than to information alone. Unlike the discretionary model, users cannot grant access rights to other users at will, and to organise access, the system administrator gives the user a new role - for example, includes him in a particular domain user group. Since the role-based model of access differentiation allows to operate with the roles corresponding to the business structure of the company (divisions, departments, divisions, groups, etc.), the possibilities and simplicity of administration are significantly increased - for example, when an employee moves to a new division, he is assigned a new role, which is already granted all the necessary powers for work. In addition, the role-based access model allows you to implement static separation of powers (impossibility of simultaneous assignment of several critical roles to a subject) and dynamic separation of powers (a subject can perform certain functions only in one of the roles assigned to him at any given time). The role-based access control model allows to implement the principles of least privileges and separation of powers, to avoid excessive assignment of privileges (authorisation creep / privilege creep / permission drift) when employees move to other departments, and can also reduce the administrative burden in case of high staff turnover.
4. Attribute Based Access Control (ABAC, Attribute Based Access Control) model, in which access rights are granted depending on the attributes of the subject, object, system environment and requested action in accordance with the rules set by the administrator. The attributes of a subject can be its position, grade, department, project role, clearance form, and the role assigned under RBAC. The attributes of a subject can be the file type, application, network protocol and port, and file confidentiality label. Operating environment attributes can be network type (wired or wireless), device characteristics and location, date and time, and the presence of malicious activity on the network segment. The use of attributes allows for more flexible access differentiation by modifying the values of attributes of subjects and objects without changing their relationships and the entire access policy - for example, a user's access to critical files can be temporarily denied while he is working from a personal device outside the office. ABAC model is flexible enough and allows using XACML (eXtensible Access Control Markup Language) to describe access control rules, so it is increasingly used in various modern applications and API interactions. However, a significant disadvantage of ABAC is the difficulty of auditing effective access rights of users, because they depend on a lot of continuously changing attributes of subjects, objects, and environment.
Having briefly described the main models of access control, let's proceed to enumerating the characteristics of the role model of security and its comparison with the attribute model. So, the role model of access control has the following features:
- For the initial configuration and further support of RBAC, a list of roles and their privileges that correspond to the organisational structure of the company (so-called role engineering) will need to be created and regularly reviewed. This approach is justified in the case of large companies and public institutions, where new divisions do not appear very often, and the job functions of employees are relatively static. If the company has a small number of employees with a wide range of functions (‘generalist employees’) or if the company is mainly engaged in project activities, then ABAC may be a more appropriate security model.
- The RBAC model is embedded in many modern operating systems and applications in a limited format - usually by creating roles or groups of users who are assigned certain powers in the system. For example, the default domain structure of Microsoft Windows OS has a number of roles used for administrative tasks: Enterprise Admins, Domain Admins, DHCP Administrators, DnsAdmins, Backup Operators, Event Log Readers, etc. When configuring user roles in Windows, accounts are created for employees, then they are grouped into groups, then these user groups are granted permissions to perform actions (for example, the ‘Secretariat’ group is granted permission to send large files outside the corporate network via email) and to access directories and files (for example, the ‘Corporate Sales Department’ group is granted permission to read and modify files in the \\\FileServer\SalesDepartment\B2B folder). When a new employee joins the corporate sales department, he/she is immediately included in the corresponding user group ‘Corporate Sales Department’, which reduces the administrative load and allows providing all users from the same department with the same access rights that are minimally necessary for them to fulfil their job duties. When an employee moves from one division to another (for example, from sales to secretaries), his account is excluded from the old group ‘Corporate Sales Department’ and included in the new group ‘Secretariat’ - this approach makes it easy to update the employee's authority, comply with the principle of separation and minimisation of authority, and avoid excessive assignment of privileges (authorisation creep). At the same time, the standard functionality of user groups in Windows does not allow you to implement static and dynamic separation of powers, and also provides only limited opportunities to maintain a hierarchical structure of roles.
- The role-based access control model, when fine-tuned, avoids both excessive and insufficient authorisation. Overentitlement can increase the risk of information leakage or negative impact on the infrastructure (for example, a user with excessive rights can accidentally or deliberately delete a large amount of information from a file server). Insufficient authority (underentitlement) also carries certain risks: an employee will either be unable to work effectively or will try to circumvent the imposed restrictions (e.g., asking a colleague for a login and password to do his or her job), which, in turn, will lead to less controllable access to information and to difficulties in auditing.
- The role-based security model allows to improve both ‘paper’ and practical IS by maintaining a register of roles with a description of their powers, assigning access rights to applications and file directories to groups (rather than individual users), the ability to quickly audit the access rights of a particular employee to all company assets (by analysing the roles assigned to him and the inclusion of his account in domain groups), simplifying the formation of reports for the relevant regulators, as well as complying with the principles of separation, minimisation of costs, and the use of a single password.
- The RBAC security model reduces the cost of administering accounts and granting access rights, reduces the downtime for new employees before they start their job duties with all the necessary authorisations, and increases team productivity.
Comparing the role and attribute models, it should be noted that RBAC is less flexible, but easier to configure under the condition of a relatively static organisational and staff structure and information infrastructure, while ABAC is more flexible, but also more difficult to configure and maintain relevance. An optimal solution may be a combination of both security models, e.g. by:
- Accounting for various additional attributes when assigning roles - for example, by setting an attribute in the form of an expiry date for each role, after which the role becomes inactive;
- Forming dynamic roles, where attributes define a role that is assigned to a user at a particular moment - for example, depending on the current time or location of the subject;
- Formation of an attribute-centric access model, where a role is not a set of permissions, but just one of the attributes;
- Forming a role-centric access model in which attributes only limit the rights of a role assigned by RBAC, but cannot extend them.
We conclude with a list of other, slightly less popular access control models:
- The RuBAC (Rule-Based Access Control) model consists of granting access to subjects according to logical conditions of the ‘If-Then’ kind set by the system administrator. To some extent RuBAC is similar to ABAC, but in terms of the mechanics of application RuBAC is more like network rules set up on a firewall and applied to all users at once (each access request for any account goes through the entire list of conditions);
- The Risk-Based Access Control model consists of granting access depending on the risk profile of the subject and object of access and the level of risk assessed for the requested action;
- Content-Dependent Access Control (CDAC, Content-Dependent Access Control) is to grant access to a subject depending on the content of the object (e.g., access can be granted only to certain information in a database);
- Context-Dependent Access Control (CDAC) is to grant access to a subject depending on previous access requests to the object (e.g., when deciding whether to allow or block traffic, the state of the network connection is taken into account, and when deciding whether to grant access to a record in a database, previous user requests that may indicate that the user has deliberately collected sensitive information are taken into account);
- Graph-Based Access Control (GBAC, Graph-Based Access Control) model consists in forming a graph of relations between subjects and objects, which allows controlling access to nested data structures (for example, a social network allows allowing access to information on a user's page not only to ‘friends’ but also to ‘friends of friends’);
- Organisation-Based Access Control (OrBAC) is the formation of an additional level of abstraction of the security model, which includes roles (rather than individual subjects), activities (rather than individual operations), and information representation (rather than individual objects).
