This blog post is part of the Zero Trust Journey series, where we present simplified ways to implement a Zero Trust architecture. If this is the first time you read about this subject, we recommend you check out the initial steps. Here you can check out the requirements for implementing access control.
Previously, we listed the requirements for implementing access control according to the requirements of a Zero Trust architecture based on ISO/IEC 27002. Now, we will go through the steps of system and application access management and control, where those requirements are put into practice.
User Access Management
Preventing unauthorized access to systems and services is fundamental to the proper functioning of a Zero Trust architecture. ISO/IEC 27002 establishes a set of best practices that follow the same purpose and have the formalization of processes as their main activity.
Formalization of Access Control Processes
We must highlight the importance of records and formalization when practicing the Zero Trust philosophy. Documenting processes provides the necessary visibility to monitor, analyze and improve the security of IT assets and services, and the same goes for controlling access to them.
Therefore, access management requires a formal process for registering, disabling, and removing user IDs, aiming to establish the following rules:
- use of unique user IDs: this is a way of linking each user to their responsibilities and actions, so that any further permissions are only granted upon approval and its respective documentation;
- immediate removal, revocation or disabling of IDs of users who have left the organization: as we explained in the first post on access control, it is important to follow the criteria of criticality and sensitivity of the assets and resources involved and to perform critical analysis frequently, especially for system users such as “sysadmin”, “root”, “administrator”, and others;
- removal and periodic identification or disabling of redundant users with IDs: removing repeated IDs, avoiding ID collision and ensuring that IDs are not reissued to other users is important for several reasons, including ensuring the use of unique IDs. Issuing temporary IDs is a best practice in such cases, as long-term credentials are conducive to redundancy.
- token and IDs cannot be sequential: if the implementation delivers sequential values when defining a pattern for the generation of a session token, it can be violated via reverse engineering.
It’s important to note that the rules also apply, as far as possible, to machine identities. The idea is that any permission to be granted or revoked for all types of users should go through a proper and formal process, which should be documented.
Another point to be taken into consideration is provisioning for user access, which we will explore below.
Provisioning User Access
User provisioning is the granting/revoking of permissions to services and applications within the work environment. In the Zero Trust sphere, the formalization of this process is mandatory and must fit the requirements of access control and policies.
This facilitates the execution of another important procedure for access control: the analysis of the access level granted. In this procedure, the access policy — built in the previous phases of the journey — is the parameter to determine if the request is consistent with the requirements, and no privilege can be granted without full verification.
In addition, all the procedures mentioned in the previous topic apply to provisioning, such as documentation, revocation of rights regarding users who have left the organization, change of rights for users who have changed roles, and frequent critical reviews with the participation of the asset owner.
It’s recommended to assign contractual clauses to human identities (including partners and service providers) that specify sanctions for unauthorized access attempts.
Privileged Access Rights
Formalizing the control and restriction on the granting and usage of privileged access rights is a critical process, whose execution must be strictly aligned with the access control policies, considering the minimum requirements for performing the task.
We can build an analogy between privileged access and a treasure kept in a safe, which only two elements of the organization can access and bring out the exact amount needed for their purposes: the guard and the owner.
They work together in the steps where the user identifies themselves, has their responsibilities critically analyzed, and acquires the temporary credentials with sufficient rights to reach the vault room, checking at each step if the access control requirements have been met.
After the checks are performed, the rights are assigned and the user is given a different ID from the one used for their usual activities. The guard then opens the safe for the owner to retrieve the requested amount and give it to the user, who must consume it within a specified period.
Back to the Zero Trust context, while privileged access is active, specific procedures to prevent unauthorized use of the ID granted to the user must be executed and maintained, preferably using solutions that allow the granular creation of rules.
It is also highly recommended that the rights granted have a set expiration date and are revoked at the end of the activity, as malicious access, such as ransomware or malware, will only succeed if it obtains permission to perform certain actions.
System and Application Access Control
Among the ISO/IEC 27002 guidelines focused on system and application access control, we have two important types of control for a future-proof Zero Trust architecture, applied to the use of programs capable of overriding system and application controls and to program source code.
The access policies should ensure the protection of users and their authentication information, as well as describe the minimum requirements necessary to grant access to assets and other systems. Thus, insider threat risks are minimized and, at the same time, users, developers, and other stakeholders are educated on the best security practices for access credentials.
Due to the sensitivity of these components, it’s essential that the access to them is strictly controlled through identification, authentication and authorization procedures, segregation of utility programs from application software, recording the use of these programs, among other actions.
To receive the next chapters on our Zero Trust series, subscribe to our newsletter by filling out the form below!
