In the previous post, I explored some recommendations for lowering the risk of unwanted access to company resources. In this article, I want to go a little deeper into the first recommendation: understanding who has access.
To make this practical, I am going to use a modern B2B gift and design company called Penelope Grace Designs Inc. as an example. I will use what we discover about the company to help shape an IAM program that fits how the organization actually works.
Discovery
Before I start building controls, I want to understand what I am securing.
Visualizing the organization helps me understand how people and systems access resources, where digital identities are stored, and which services are responsible for provisioning and revoking that access.
Action Items
During the discovery phase, I want to:
- Identify the services that store digital identities capable of accessing company resources.
- Understand the services, environments, and applications available to users, including how access is provisioned and revoked.
- Align with leadership on the organization's access requirements.
- Identify all entry points into the organization.
- Review the health of the processes used to grant and remove access.
- Understand how software is reviewed and introduced into the environment.
- Review the access policies that define the logical controls being enforced.
The point of this phase is not to produce a perfect inventory on day one. It is to expose the places where access can be created, changed, or removed so I know which paths the IAM program needs to cover.
The Approach
Identifying the organization's digital identity repositories is an important starting point. Those repositories help me understand which processes are involved in granting and revoking access to company resources.
The first question I ask is:
Which service is acting as the Identity Provider (IdP)?
In this scenario, that is Okta. The company purchased Okta to provide a federated sign-on experience for employees.
That is the obvious access path. The more interesting question is:
Which other services can provide access to company resources without going through the Identity Provider?
During discovery, I found a few examples.
External contributors could be added directly as GitHub collaborators when the company needed contributions to a codebase. Contractors and vendors could also be invited directly into Slack as single-channel or multi-channel guests.
Neither path necessarily starts with the primary IdP.
I also need to account for non-human identities associated with integrations between the company and third-party services. Those identities may have credentials and permissions of their own, and their lifecycle can be very different from an employee account.
This is why I do not want to equate "users in the IdP" with "everyone who can access company resources." The IdP is an important part of the picture, but it is not always the entire picture.
Our Findings
The discovery work highlighted a few themes.
We had three main user types, some resources could be accessed without being provisioned through the IdP, there were multiple sources of account data, and the account lifecycle processes did not consistently match the needs of the organization.
That gave me a much clearer picture of where the IAM program needed attention.
User Types
The organization was doing a poor job of populating account attributes with enough information to clearly distinguish between user types.
That matters because attributes such as employment type, department, role, or account type can be used to make better access decisions. If those attributes are missing or unreliable, it becomes harder to automate access safely.
The lifecycle processes for non-employees and non-human identities also did not align well with the business requirements. Their access controls were fragmented compared with the employee baseline, which introduced unnecessary risk.
Applications
There was no central inventory of the company's application fleet.
Without one, it is difficult to answer basic questions such as:
- Which authentication methods does an application support?
- Can it federate through the IdP?
- How are users provisioned?
- How is access revoked?
- Who owns the application?
The application provisioning process also needed to become more agile. A slow or inconsistent process creates a poor user experience and can contribute to privilege creep when access is granted manually and never revisited.
One of the more important findings was that IAM stakeholders needed to be involved earlier in software procurement. If IAM only learns about an application after it has been purchased and deployed, many of the authentication and lifecycle decisions have already been made.
Processes
The discovery also exposed gaps in the processes surrounding access:
- There were no feedback loops or review points to monitor whether the processes were still working as intended.
- User lifecycle processes were not documented against all of the access entry points we identified.
- Account provisioning still relied heavily on manual work.
These are easy gaps to overlook when reviewing only the identity provider configuration. The process around the technology matters just as much as the technology itself.
Business Objectives
The IAM program also has to support what the company is trying to accomplish.
For Penelope Grace Designs, the business requirements included:
- Giving employees a flexible and secure way to work.
- Supporting rapid growth with an access model that can change with the organization.
- Meeting SOC compliance requirements associated with important customer opportunities.
- Extending the company's data-driven approach into the IAM program so leadership can understand how it is performing.
This context helps me prioritize the findings.
A missing application inventory is not just a documentation problem. It affects how quickly the company can onboard software, how reliably access can be removed, how well controls can be demonstrated to customers and auditors, and how confidently leadership can understand the organization's access posture.
Where This Leaves Us
At this point, I have a much better picture of the organization's authentication and access landscape.
I know there are access paths outside the primary IdP. I know the company needs better application and identity inventories. I know non-employee and non-human identities need clearer lifecycle processes. I also know where those improvements connect back to the company's business goals.
That gives me a much better starting point for deciding where to focus first instead of immediately implementing new controls without understanding the environment.
In upcoming posts, I plan to explore the APIs available in the existing technology stack and how I can use them to gather more of the information needed during discovery.