In our previous article, we introduced the concept of zero trust in IGA and discussed its core principles and proactive strategies. Next, we will focus on the architectural initiatives essential for a robust zero trust implementation in IGA systems. Let’s dive into the practical measures that can be adopted to enhance security.
Practical Architectural Measures for IGA Zero Trust
Let’s navigate through the topics mentioned in the first blogpost. What immediate measures can be implemented?
Encrypt Data Store
Sensitive data should be encrypted. Besides passwords, this can also include account names (as for an intrusion always both information, user and password are needed) or role memberships, as this can be an indication of how much an account is allowed in the target system.
It therefore makes sense to go through the data model of the IGA system and decide individually which objects or attributes should be encrypted.
Encrypt Network Traffic between Components
Every zero trust concept in access management suggests encrypting network traffic between components. Of course, this also applies to the IGA environment. However, this includes both the individual components of an IGA system itself and the connections to source and target systems. So, encrypted protocols must also be accessed here. This is often omitted in development environments for the purpose of development and debugging, but it is essential that there are no unencrypted data connections in the production environment.
Minimize Stored Data
IAM systems are often designed as hunters and gatherers, collecting more data than necessary. However, from a security point of view, it’s crucial to only gather and store data that will be used or forwarded.
Attention should also be paid to how long the data is needed. In the event of a password reset, for example, a password is stored in the process (and thus in the workflow engine of the IAM system) until it has arrived in all target systems in which it is to be set. Once updated, it can and should be deleted. By following this procedure, some attributes can be excluded for permanent storage – and what is not stored cannot be viewed by a hacker.
Least Privilege for Attributes
As highlighted earlier, IAM should only retain data essential for processing in target systems. It is therefore beneficial to create a data flow diagram that gathers data from sources only if deemed necessary by a target system. In this context, tracing from the target back to the source helps minimize attributes, adhering to the principle of least privilege for attributes.
Avoid User/Password Access
IGA systems “talk” to various peripheral systems and need login access. These service accounts usually possess considerable rights (otherwise they would not be able to perform their tasks in the target system). Usually, these accounts are only secured by user/password, and MFA cannot be implemented either, as access is automated. This means that they pose a significant security risk. In this respect, any authentication methods that guarantee a higher standard, such as the use of certificates, or additional safeguards via PP key procedures are to be preferred.
Execute Web Page Procedures on Server, not on Client
Nowadays, extensive scripts are executed in web pages. While no sensitive data is shared, the code that is executed and the nature of the queries sent by the web page against the IGA system can give hackers information that allows them to identify where they might expect a vulnerability. To mitigate this, it’s better to have the code run on the server instead of the client and send only the results to the web client. This way, hackers miss the calculation rule that is in the page. Therefore, server-side web page code is preferable to any client-side script.
Proactive Strategies to Prevent IGA Security Breaches
What else can be done to increase the security? Avoid mistakes before they occur. This means to think about how to avoid pitfalls in advance of implementation. This is why IGA zero trust is already fundamental part in the concept phase.
Expect the Unexpected
Think outside the box. In particular, play through the exotic, unexpected scenarios. Think of all edge cases, specially in processes. Hackers often exploit memory leaks not through regular use, but by unusual combinations and misuses. Only if you are open minded enough to think about those scenarios, and as you know your process best, you are able to avoid this misuse, as you have a knowledge advantage against the hacker. Use it!
Most Attacks Come from Inside
Most developers think of hackers as the evil nerd from a faraway land rather than the friendly colleague nearby. Yet, most attacks often originate internally, either from a seemingly trustworthy coworker or a compromised account. In this respect, the extraordinary attack scenarios are just as likely as the prue abuse in the system itself, which was only possible because the functionalities were not exhausted – e.g., no SoD rules were entered even though the IGA system can do so – or the attacker forgot to lock his screen, which allowed the attacker to bypass the dual control principle.
So, regularly challenge the scope with which a possible attack is looked at, not to overlook the obvious, but to rule out even the most unlikely scenario.
Test the Extremes
Developers often find testing tedious, especially when ensuring a scenario for successful implementation works as intended. Considering potential errors can feel overwhelming. Hackers know this and therefore often reach their goal by playing through completely unpredictable combinations of the process.
In order to prevent hackers from being successful, it is essential to store these scenarios as a test. This ensures that failure mechanisms are activated, preventing undesired outcomes.
Automize
Manual actions are the starting point of any attack or abuse. Fully automated processes are difficult to penetrate. Therefore, automation is the enemy of any attacker. Automatic processes are (after sufficient testing) less error-prone and more secure – and they can be monitored and retraced well.
Conclusion: The Future of Zero Trust in Identity Governance Systems
Zero trust is crucial not just for access management related considerations, but also for IGA systems and the environments in which they are embedded. Besides the principles that apply to the network and protocol related setup considering zero trust, additional measures have to be taken for the IGA part as well. Some of them are of technical nature, but some of them are conceptual advice and recommended guidance both in preparation and implementation phases of IGA systems and processes.
These have been explained in this blog post and are mainly focused at broadening the view beyond the direct scope of current development and to include the seemingly impossible. They are supported by functionalities of the systems such as SoD, risk management, monitoring and auditing, workflow automation and the least privilege principle.
Unlock the Future of IGA: Connect with iC Consult 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 delve deeper into the intricacies of zero trust and its practical applications in IGA. We can assist you in charting or embarking on your zero trust IGA journey.
