Infrastructure access is not always well understood, controlled or reviewed.
IAM/IGA projects generally focus on application rights while neglecting infrastructure access. As a result, it is common to find that accounts and the rights assigned to them accumulate without anyone daring to touch them for fear of destabilizing a functioning system.
In addition, the number of systems hosted in the cloud is constantly increasing. It is clear that initiatives for the governance of this type of access are still underdeveloped.
Yet, these accounts represent a major challenge due to their sensitive nature. As proof, auditors are increasingly interested in infrastructure access.
It is time to take control of this infrastructure layer.
Why is it necessary to implement an infrastructure access review?
Application access review is not enough to ensure compliance or to reduce risk. It is crucial to consider the entire silo: infrastructure, data and applications. The infrastructure layer is especially subject to certain risks, some of which can be high, such as system corruption, data theft, etc.
Many privileged accesses are related to infrastructure, and among them figure many anonymous accesses (service accounts, technical accounts, generic accounts, etc.) that make it difficult to link them to a user or function. Because of this, historical accounts often end up accumulating and are, at times, no longer even documented at all.
Reviewing infrastructure access is a way to reconstruct and clean this history in order to meet compliance and risk reduction objectives.
What is specific to infrastructure reviews when compared to application reviews?
Access to infrastructures can be complex, varied and great in number. For example, for one application account, there can easily be five to ten infrastructure accounts. Moreover, the security model differs from that of most business applications.
For these reasons, reviews of these accesses must be planned and conducted independently of application reviews and with different business rules and participants. Careful preparation is required, as well as a clear definition of the action plan in addition to the nature and depth of the rights to be reviewed.
– Which systems will be reviewed? (Windows, Linux, PAM)
– Is the infrastructure located on-premise or in the cloud?
– What will be reviewed? How deep will the review go? Concepts are different depending on the analysis to be conducted (accounts, groups, ACLs, SUDO, etc.).
– Who are the reviewers? Who has the authority to make informed decisions about these accesses?
What are the difficulties?
Due to its large volume and dispersion among different systems, the collection of data relating to access rights is often difficult to manage. The abundance of local accounts is a good example of scattered access and should be avoided as much as possible.
In addition, the quality of the data to be analyzed is rarely satisfactory: preliminary work is sometimes necessary to reconcile user accounts, understand the purpose of technical accounts and identify who should review what.
The technical managers are those who are best for creating and analyzing reviews of infrastructure access rights. The volume of data mentioned above is a real problem, because for the same infrastructure, a technical manager may have to review a significant number of resources.
What is the key to success?
No need to reinvent the wheel each time. During the preliminary steps of access mapping, rely as much as possible on existing systems (Active Directory, PAM, Identity Analytics Solution, etc.) to facilitate the review and make the most of the data already present in the systems and middleware. Depending on the current situation at the start of the project, the its scope can be considerable. The best practice is to proceed step by step to find the list of owners and clean the data as much as possible prior to the review in order to avoid unnecessarily burdening the process.
Doing the data cleaning can help to find or rebuild the link between the account and the identity in order to locate technical and service accounts. This makes it possible to rebuild the link between the application and infrastructure areas and facilitate the implementation of the review. Therefore, when defining the application scope to be reviewed, the totality of the “infrastructure” resources that must be taken into account during the access review is easily deduced.
Another important factor in the successful completion of infrastructure access reviews is manager awareness. This can be done by setting up a dedicated process, but by relying on the willingness of upper management to include the review in the objectives of individual managers. Involving teams and promoting the project’s success also means providing them with the right tools, including a solution for mapping access and automating the review process.
Infrastructure accesses evolve less quickly than application accesses. Once the review has been carried out on the entire scope, future reviews can focus solely on changes or gaps in control. By identifying, or tagging, sensitive accesses, reviews can target only those that present a real risk (for example, in line with Sarbanes-Oxley parameters.)
To go even further, the revoking of access rights can be expected as soon as the review process is created by identifying the information that will lead to the proposal of rights to be removed within each system. Because if it is important to review the problems, it is also important to be able to correct them.
Ready to do infrastructure access reviews?
The magnitude of the task can be overwhelming at the beginning of this type of project. Nevertheless, its success can be optimized with a clear process, the use of the best practices listed above and a specifical solution chosen to handle the volume and varied nature of the data.
A solution such as Identity Analytics offered by Brainwave GRC is essential to conducting all aspects of these review campaigns while encouraging team involvement that relies on access mapping, automated functionalities and intuitive interfaces.