In IT, zero trust is the new buzzword. While much attention is given to the protocol level and network infrastructure, it is essential to recognize that zero trust principles also encompass IAM and IGA systems. This is a two-part article series. In part 1, we’ll delve into the goals and principles of zero trust in IGA security. Part 2 will highlight architectural and conceptual approaches.
Introduction
Zero trust is on everyone’s lips: No relevant security article without mentioning it, no security strategy that does not include it. However, a security concept is not complete without zero trust, and this is where its significance lies. When highly relevant measures are explained or derived that absolutely must be observed or implemented, the focus is very often on the network infrastructure, the consideration of the protocols used and the encryption of the same. The subject of this article will be the consideration with regards to IGA systems, and how, in addition to the measures mentioned above, other aspects must be considered, and additional measures must be taken to implement IGA security-relevant steps in each area of such an IT landscape.
Foundational Elements of Zero Trust in Identity Governance & Administration
To adopt a comprehensive security strategy, let’s define foundational elements:
Don’t Trust Anything
No component, actor, method or process should be trusted. This is the most important directive which has to be followed. Attackers can come from anywhere. They might be internal employees, or they may have already hijacked an account or penetrated a system. Therefore, trust nothing and no one – not the account, not the component used or the process that has already been built in a security-relevant way.
Place User Identities at the Forefront
No attack without an account associated with it! Without logging into a system as a user, no hacker can send a command or launch an attack. So, when we focus on the identity behind the account, a central component of any hacking action is the target of our countermeasures.
Guarantee the Highest Possible Level of Security
In some cases, there might be multiple ways to solve the IGA security-relevant issue. Some of these possibilities may vary in the security level. If this is the case, use the one with the highest level, don’t shy away from the costs, because the repair after an attack is usually many times more expensive than the savings in the project.
Do Not Rely on the Traditional Firewall Boundary with VPN
Project teams often incorporate standard zero trust policies, encrypt network traffic, strategize against man-in-the-middle attacks, and implement MFA and firewall rules, believing their job is complete. However, while these steps are essential, they’re just the beginning. Further actions are necessary to ensure comprehensive security.
Provide Practical and Secure Access to Resources
While we focus on increasing IGA security, just the identity or its account isn’t the sole factor in potential damage. Access rights, resource permissions, or entitlement memberships play a role. It’s vital that these are granted through a secure process. However, we must remember our regular users who need access to rights, groups, or entitlements for their daily tasks. Security measures shouldn’t overly complicate their work. Therefore, a balance between security and usability is essential.
Strategies for IGA Security
What are the frameworks for a safer digital environment? The following principles align with the objectives discussed earlier, aiming to maximize the challenges for any attacker trying to succeed.
Properly Defined Processes
Correct process definitions are essential. Furthermore, ensuring they are executed properly is crucial. The Joiner process is the most important process for a new employee to be able to work. However, the Leaver process is the most critical for the security aspect. If a no longer used account is not closed promptly, it poses a security risk for the time it is not locked. It is also important to note that the change of an employee’s position or job results in the loss of all rights that are no longer needed for the new job. However, the withdrawal of rights is often not the primary focus of an IAM project, as its neglect does not prevent work. Here it is important to break out of this mindset and realign the focus, taking into account the safety aspect.
Least Privilege
This is, of course, one of the core principles of an IAM system. Nevertheless, it makes it more difficult to misuse or break into an IT system and therefore belongs on the list of principles.
Privileged Access Management
The more extensive the right, the more precise the control of the use of this right must be. Therefore, the allocation of a highly privileged right also requires a separate, coordinated approval workflow. And in order to additionally be able to either recognize abuse in time or at least prove it retrospectively, suitable logging and monitoring measures are required. Since these are often not sufficiently integrated into standard IAM systems (or must be added), the use of a special PAM tool is recommended.
Segregation of Duty (SoD)
SoD is an integral part of an IGA system and justifies the “G” in the system name. In this respect, all commercially available IGA systems already fulfil this requirement and are part of any governance implementation, but nevertheless this point also belongs on the list of principles. Therefore, an IGA project is not complete until a minimum set of SoD rules is in place. In addition to the existence of the functionality, its real use is also essential.
Microsegmentation
Microsegmentation is also a way to make life difficult for an attacker. If you frequently change the type of service to get the information through the systems, and change the platform in the process, the potential attacker must firstly know this and secondly do it to get his way. So it becomes more complicated for him. This can be achieved, for example, by changing the transport layer or the automation framework from system to system, and by appropriately dividing the processes into many small ones, which in turn always have their own security methods.
Multi Factor Authentication (MFA)
MFA is one of the classics in access management to increase security. In the IGA environment, however, it is often only considered in relation to the login. But it also makes sense, for example, to check the identity of the approver again in the approval step itself using MFA, if this step grants critical rights. This puts another obstacle in the way of an attacker who has already been able to compromise the account.
Just-in-time Access
Using time restrictions on rights is another protective instrument. For instance, while it’s common to limit building access to office hours, digital rights are often available 24/7. By restricting these rights to office hours (or other agreed time windows), an attacker who compromises an account can’t misuse it outside of those hours. Moreover, if an attacker isn’t aware of the time window, they might assume that the account is useless. Thus, the hostile takeover of the account is not synonymous with resulting damage.
Practically implementing this requires careful consideration: Which rights need time-based protection? What should the exact time window be to ensure genuine users are not blocked in their normal activity? How much load does the assignment and removal of rights create in the target system at the respective time of change? These are among the questions to address.
Auditing and Tracking
Beyond preventive measures, it’s crucial not to overlook control mechanisms to notice breaches as early as possible, ideally in real-time. For this purpose, it is necessary to implement monitoring functionalities that help identify signs of potential attacks or misuse. While geofencing is common practice in the AM environment, IAM typically addresses this through risk management. But the search for anomalies in rights clusters is also an effective strategy.
When an intrusion is identified, IT forensics is useful to locate and close the attacker’s loophole. However, this presupposes that all corresponding previous steps are logged accordingly and can be viewed retrospectively. Therefore, logging such actions is helpful. Of course, this must not be misused for other purposes such as the control of employees or their supervision.
Encryption
IAM systems store large amounts of identity data, and unrestricted access to this data allows for misuse. Therefore, in addition to rights management, access to the data by a hostile account (with extended rights) must be made more difficult. Even if an attacker breaches the data store, typically a database, they shouldn’t be able to access all the data. For this purpose, in addition to self-explanatory passwords, all very sensitive data must be encrypted.
While one might consider encrypting all data, it’s often not advisable due to performance implications, as the IAM system would spend more time encrypting and decrypting than performing its primary functions. However, modern IGA systems allow attribute-level encryption, effectively addressing this concern.
As we’ve explored the foundational principles and proactive strategies of zero trust in IGA, it’s evident that the architectural framework plays a pivotal role in its successful implementation. In the second article, we delve deeper into the practical architectural measures and initiatives that can fortify IGA systems against potential threats.
Unlock the Future of IGA: Connect with iC Consult’s Experts Today
Implementing zero trust in IGA systems is not just about enhancing security; it’s about staying ahead in a rapidly evolving digital landscape. Reach out to our iC Consult experts to effectively implement these measures and ensure a robust IGA system. We can assist you in charting or embarking on your zero trust IGA journey.
