What Is Declarative IGA?
Declarative IGA is a new paradigm for identity governance and administration that allows practitioners to focus on what things are done to pursue access risk management objectives instead of how those things are done. It is based on the proposition that we, collectively, have been doing IGA long enough that workable abstractions can be provided to reduce complexity and shift more control over access risk management to the business where it rightfully belongs.
The following statements can be considered to be a manifesto of sorts for Declarative IGA (to be updated periodically as details are fleshed out):
Access risk management
IGA is about coordinating the work of access risk management across numerous business stakeholders, not automating the work of security administrators.
The business owns access risk and should have control over management of these risks.
Policy-driven administration is the core of sound access risk management, the basis for distinguishing easily between access that is policy-compliant and access that is not — this allows risk management efforts to be concentrated on exceptional access.
There are two sides to access risk:
Positive risk — the risk that bad things might happen because of too much access
Negative risk — the risk that good things might not happen because of too little access
Decreasing positive risk necessarily increases negative risk — and vice versa — although the magnitudes of each corresponding change can differ greatly.
Effective access risk management requires discovering and achieving proper balance between procedural (manual) and automated controls — this balance can be measured and monitored over time at the organization level, the user level, and all the way down to individual entitlements or permissions.
Organizations rely excessively on procedural controls such as access requests and access reviews/certifications to control user access.
SoD (segregation of duties) risk analysis is preferred over SoD policy enforcement.
Risk scoring is a fool’s errand — vendors believe it demos well, but it is rarely used in the wild.
Information model
The IGA information model is properly understood as being composed of two complementary halves:
IT side — actual or observed state — abstractions that represent the managed environment, primarily consisting of IT systems, accounts, resources and permissions
Business side — business intent or desired state — abstractions (e.g., identities, entitlements) that provide business context for IT-side entities in a manner that makes user access legible to business stakeholders
The operation of IGA is an ongoing convergence toward equilibrium between the business and IT sides — reconciling changes that occur primarily on the business side and occasionally on the IT side.
The entities and relationships of the IGA information model serve the same purpose that a DSL (domain-specific language) does for declarative programming languages.
The IT side of the IGA information model is organized around IT systems, which is an unintuitive way to structure user access for business stakeholders.
The business side of the IGA information model requires much more than identities and entitlements (also called roles, bundles or packages depending on implementation) to provide adequate business context for user access.
Prescriptive processes
Automating an organization’s manual processes will not — and cannot — produce effective access risk management outcomes.
There is enough collective wisdom among practitioners, gathered over 25 years since the provisioning days, for IGA tools to provide prescriptive processes based on coherent control models.
Identity life cycle is the key business-side control: IGA oversees identities — human and non-human — beyond the scope of any other group in the organization, so practitioners should embrace this responsibility.
Account ownership is the key IT-side control — all accounts provided by IT systems should possess individual owners.
The life cycles of accounts are controlled by the identities that own them — no identity, no account.
Vendors of IGA solutions should rise (or fall) in the market on the strengths (or weaknesses) of their processes and control models.
Metrics are important for effective access risk management: prescriptive processes imply the inclusion of metrics to measure their performance and effectiveness.
Control monitoring
Controls in IGA exist to distinguish between levels of positive access risk (the risk that bad things might happen), and three risk levels are sufficient for this purpose:
High risk — not tolerated by the organization
Medium risk — requiring a judgment call by the right stakeholder
Low risk — accept the risk automatically
Opaque risk analytics that flag certain user access as possessing elevated risk are counterproductive — often raising more questions than they answer — regardless of how sophisticated such analytics might be; surfacing risks through transparent audit controls provides more valuable insights.
Reporting is important, but it is not a substitute for a comprehensive auditing framework.
Audit controls should support both preventive and detective/corrective postures when applicable.
History should be maintained for every audit control to allow tracking of identified risks and remediations over time.
All elements of the IGA information model, including operational data, must be addressable within the auditing framework.
Configuration and change management
IGA tools and practices should work in concert to protect organizations from unintended, negative consequences of seemingly innocuous actions.
Cloud computing technology, through its capabilities for isolating workloads, should eliminate the need for most organizations to maintain separate lower environments (development, test, QA, staging, etc.) for their IGA tools — regardless of whether deploying in the cloud or on-premises.
IGA teams should not be unreasonably large, and should not resemble application development organizations.
Locality of behavior is preferred over separation of concerns — IGA tools’ configuration units should be structured to minimizes the number of units that must be modified to reflect desired behavior.
IGA tools should provide isolated sandboxes for defining and testing individual configuration changes, and control the release of such changes within the active environment.
Prefer control over how and when configuration changes are released — requiring approvals for releasing new or updated configurations in the active environment — over restricting who can make configuration changes.
IGA tools should maintain a version history of individual configuration changes, and allow rollback to previous versions if problems are encountered.
Dark mode is not optional for the user interface.