This article provides a brief introduction to the architecture of Okta Identity Security Posture Management (ISPM).
The following figure provides an overview of the architecture.
We will break it up into the Input, Service, Console with Users/Roles and Output.
Input
ISPM is fed from different sources. The main source is from other customer systems, such as identity providers (currently Okta, MS Entra ID and Google), cloud platforms (AWS, GCP and Entra ID), and SaaS applications. The Integration Guides page in the product docs list the currently supported sources. These are API-based integrations.
The other source is industry context from open-source information and threat intelligence. This provides external information, such as breached account context.
Service
After an initial bulkload, the ISPM cloud service will consume identity information on a daily basis. It normalizes and contextualizes that data, performs risk classification on the usage analysis, and prioritizes identity issues based on attack chains and consolidated context. Using graphical visualization and reporting capabilities, the centralized platform helps you instantly understand the biggest gaps and risks in your organization. It leverages a graph engine to maintain the object relationships.
Console with Users/Roles
The web-based ISPM console is part of the ISPM service. It presents multiple view of the data held in the service:
- A dashboard – a summary view of the identities and their risks
- The issues – a prioritised view of all identity issues
- The inventory – view of the different objects (like users, accounts and apps)
- The controls – issues mapped to compliance framework controls
- Settings – for configuration of the service
These views are used to manage the identity security posture.
There are users defined in ISPM. They may be directly defined, or SSO in from an IdP such as Okta or Entra ID. These users are assigned different roles: Super administrator, View and dismiss issues (for all or some sources), and Integrate sources.
Output
Output from ISPM comes in two flavours – some actions can be performed automatically when a issue is detected (on the daily load) whereas others are human driven via the Console.
The detection-driven integrations are:
- Create a ticket in a ticketing system (like Jira and ServiceNow)
- Send a message to a messaging system (like Slack)
- Perform some bespoke automation via a webhook (like calling an Okta Workflow)
These actions could be for all or a select set of issues.
From within the console remediations can be performed on specific issues. These include:
- Raising a ticket (Jira or ServiceNow)
- Sending an email
- Sending a message (Slack)
There are also reports that can be downloaded (csv or pdf) from most views in ISPM. Finally there is an executive report that provides a summary of your ISPM status.
This concludes the architectural overview of ISPM.
IAMSE