In the previous post, we explored some recommendations to help lower the risk of unwanted access to company resources. Here we will dive a bit deeper into the first of these recommendations: "Understanding who has access."
To aid us, we will use a modern B2B gift and design company named "Penelope Grace Designs Inc." We will use the details to help design an IAM program that best fits the organization's needs.
By visualizing the organization, we can better understand how resources are accessed and which services are responsible for provisioning digital identities used for accessing company resources.
Before we start building solutions, we want to understand better what we are securing; during the "discovery" phase, we will want to:
- Identify which services store a database of digital identities that can provide access to a resource(s)
- Understand all the services, environments and applications available to your users and how access is provisioned and revoked.
- Align with leadership on the access requirements for the organization
- Determine all entry points to the organization
Health Checks on:
- The processes related to accessing resources and ensuring alignment with leadership.
- How software is reviewed and implemented
- Access policies which define the logical controls implemented
Identifying our digital identity repositories is very important. It is the starting point for determining the processes involved in granting or revoking access to organization resources.
Which resource is acting as your Identity Provider ( IdP )?
In our current scenario, we can give this title to Okta; it is marketed as an IdP and was purchased by the company to provide a Federated Sign On experience for employees.
What other services that can provide access to a company resource without the need of our Identity Provider?
We noted that currently, users could be added as Github Collaborators when we require external contributions to our code base and Slack multi or single-channel guest typically used by external contractors and vendors.
We also discovered we need to scope in digital identities associated with various integrations we have with third-party solutions.
Here is a synopsis of our discovery project; it highlighted we have three main user types; some access can be provided to resources without being provisioned through our IdP solution, we have multiple account directory sources, and our account lifecycles processes are not aligned with the best practices nor with the needs of the organization.
- We are doing a poor job of populating user account attributes with details to identify these differences.
- The lifecycle process for our non-employee and non-human user types was not aligned with business requirements, and access controls were too fragmented from our baseline. This was found to be introducing unwanted risks to the organization.
- There is no central repository of the entire fleet of applications. Resulting in a lapse in valuable insights like what authentication types are supported and how users are provisioned.
- Application provisioning process needs to be more agile to improve user experiences and lower the risk of privilege creep.
- IAM stakeholders must be at the table during the software procurement process.
- No feedback loops or review tripwires are in place to monitor the health of our processes.
- No documentation on user lifecycle processes mapped to the access entry points.
- Lack of automation during account provisioning
- A flexible and secure means for employees to do work
- Rapid growth and Innovative nature require an agile access model.
- Key customer acquisitions require SOC compliance
- A data-driven company and leadership want to see this extend into our IAM program.
We are much closer to levelling out our IAM program; we have a better idea of where to focus our efforts for maximum impact and the groundwork needed for long-term wins.
In the upcoming posts, explore the APIs our existing tech stack provided to gather the details needed in our discovery.