Strong IGA as a strong foundation for Zero Trust Architecture
A colleague and I recently had a discussion of Zero Trust Architecture (ZTA). There is no one-shoe-fits-all solution out there. Zero Trust is a journey more than it is a turn-key solution. But there are some common features and the NIST 800-207 standard or Microsoft’s Zero Trust advisory are not bad places to start reading. However – with my background at one of the major IGA solution vendors, I started wondering why Identity Governance and Administration (IGA) was never in the pictures when ZTA was discussed. The policy engine always assumes that if an account is member of a certain AD group or Azure role then it is OK and the role of “zero trust” is to check the identity’s device, location, time of day and other ad-hoc factors to decide whether to accept the request, enforce multi-factor authentication or even reject the request.
Zero Trust needs to be able to trust something
Having spent the past 4½ years with various IGA engagements, I am sorry to say that always trusting that an identity’s granted accesses have been approved and are in fact given according to the principle of least privilege is naïve. In many companies, access is granted by the service desk based on emails or perhaps tickets in ServiceNow. When the identity changes work or leaves a project, there is no follow-up, and the accesses are accumulation as time goes by. Another challenge is that accesses are not role based. When a new employee or contractor joins a team, often she or he is given the same access as a co-worker who has been in the company for years and probably has too much access in the first place. But then, of course, you avoid the situation where the new employee or contractor cannot work efficiently because of too few access rights.
Strong IGA is not achieved simply by buying an IGA solution. I am aware that most of the IGA vendors in the market offer “up-an-running-in-8-weeks” packages where you attach an HR source and a single AD to the IGA solution. That is a bit like believing that you can win the Nobel’s prize in literature just by installing Word on your laptop.
The hardest part of achieving a strong IGA solution is not configuring the IGA application (or at least it shouldn’t be) but assessing your data:
- Assess and rate your applications. Which ones are most critical and which ones are less?
- Assess and rate the entitlements in your directories. Again, which ones are most critical and which ones are less – and assign entitlements to applications.
- Assess your job roles. Depending on the size of your organization, this may be a few or thousands. Describe all the access rights that are necessary to perform every role.
- Who is to accept or reject access requests? For critical accesses that shouldn’t be left to people managers alone!
- Also set up procedures for periodical access reviews to verify that people are not carrying around too much luggage.
- Describe roles that can be given or removed automatically due to identity attributes e.g., organizational belonging, job title and geographic location.
- Describe the separation of duties policies that must be enforced. In the case above, the software did have check functions. But due to lack of separation of duties policies, the social services board employee had been given access to create fictious social projects, accept payments and verify that a financial statement had been received from the fictious social project.
- When all the assessments have been done, you can start onboarding your IGA application and relevant processes around it. And when your IGA system and all processes around it have been established then the policy engine of your Zero Trust Architecture can trust that the identities indeed has the access rights they claim.
Stories from the frontline
I would expect that everyone working in the IGA field can tell “stories from the frontline” about what not to do. Here are a few of mine, which will help you understand the importance of a strong IGA solution to ensure that the ZTA can trust its own data.
Implementing role-based access fixed audit findings?
Recently I was working for a customer in the financial sector. They had been executing an IGA project for almost two years where thousands of access rights had been removed because of assessing the various job roles and defining what was needed to perform the jobs. Their IGA system readily marked all assessed access rights for which it did not have any approvals registered. We also quickly managed to identify several active AD accounts with administrative rights to various servers and databases, which belonged to employees who had long left the company! No surprise the project was initiated after audit remarks from the financial supervisory authority (FSA). An important part of the project was to identify approx. 200 job roles. As a rule of thumb, we made only job roles requestable in the IGA application. All accesses that had previously been given on low-level entitlements where revoked and access had to be requested and approved again on job role level.
USD 17 million stolen due to lack of Separation of Duties policies
When rules to enforce separation of duties are ignored, it may have a severe impact on security. In Denmark this resulted in a high-profile case in 2018 where an employee of the social services board stole a sum of money equivalent to USD 17 million of government funding. The employee did not hack her way into the systems but had simply applied for and received accesses to the systems and the Oracle databases that enabled her to transfer funds to her own accounts and afterwards remove the log entries exposing her acts from the databases. Even if the social services board had had all Zero Trust artefacts in place, she could have carried out her criminal acts because there was no strong IGA In place.
Who does this account belong to?
Assessing entitlements is usually relatively straight-forward. An organization may have applications where user accounts are not AD based, but at least the account ID is often equal to or like the AD account name. I have, however, been working with a major Telecom in Europe where some of the important applications where using account names that had no relation at all to the primary AD account. These where even AD-based, but the users had different accounts for these applications – actually, we ended up identifying 25 different account types in the AD! It took a lot of investigation to match up these accounts to the actual employees and contractors in the HR system. Obviously, there were also issues with the making sure that the accounts were shut down on employees and contractors leaving the company.