Without reconciliation there is no real access governance, and at the same time, reconciliation facilitates the operation of the identity management and access governance solution.
Automated processes for the comparison and alignment of actual access data in IT systems with the desired permissions, also known as reconciliation, is an essential aspect of identity management and access governance. Done right, it paves the way to increased security, compliance, and efficiency.
For any organization, increasing the security profile of the company, nailing compliance, and ramping up efficiency is critical. One of the features of identity management and access governance is reconciliation, a functionality which allows the organization’s security team to keep a tight, permanent control of access rights after they have been provisioned successfully. But why is reconciliation such a vital aspect of a good identity management and access governance solution?
For many companies implementing an identity management and access governance solution, best practices for access request workflows and automated provisioning of access to applications is highly sought after. But when this has been accomplished, the organization’s security practitioners ask further crucial questions such as, “How can we be sure that the requested and approved access rights reflect the ‘real’ access rights inside the applications?”, “What happens if an administrator of an IT system simply overrules the approved access and adds privileges that might expose the organization to malicious activities?”, and “What happens if the central IAM solution gets out of sync with the connected IT systems? How can we get in sync again?”
The answer to all of these, reconciliation. Without reconciliation there is no real access governance, and at the same time, reconciliation facilitates the operation of the identity management and access governance solution. Done correctly, reconciliation offers many benefits to an organization.
Desired vs actual state
The basis for reconciliation is to not only provision access rights that have been explicitly requested or granted via assignment policies, but also to import the actual accounts and access rights from the connected systems. This means, that there is always a “desired state” and an “actual state” of these rights, stored with full history, for audit purposes.
An ideal identity management and access governance solution should be able to compare these two states. This means for example, if a new Active Directory account is detected and cannot be related to an individual, based on the company-specific matching rules, then this account should be marked as “orphaned”. Or, if a SAP role assignment is added by an administrator in a SAP system, this should be discovered and labeled as “not approved” because the assignment does not have a “desired state”. Differences between the actual and desired states are a clear compliance violation and the solution should show such violations to give the organization’s identity management and access governance team a comprehensive overview of the situation.
Take immediate action
The next question is: “What to do about it?”. While it is great to have violation reports, action also needs to be taken to return to the compliant state.
In addition to just having compliance reporting tools, organizations need flexible mechanisms to remediate compliance violations. For example, auditors or system owners should be able to kick off attestation workflows to approve or reject the discovered actual access rights, or to propose an owner for an orphaned system account.
In this way, reconciliation goes far beyond simple risk discovery. On an operational level, it is part of the “Plan-Do-Check-Act” (PDCA) cycle described in ISO 27001: First the organization plans and defines an access management concept, including access policies and request processes. Next, these policies and processes are configured in the access governance solution accordingly and become operational. This is then the point where an organization can use reconciliation to check deviations, uncover risks, and be able to take immediate action by assigning responsibilities to accounts, remove undesired access, or establish proper approvals.
Get back in sync
Aside from monitoring and removing risks on a permanent basis, there are at least two other scenarios where reconciliation can be used:
The first is the initial transition from an “unmanaged” to a “managed” state. After having installed a new IAM solution and having loaded access rights from different systems, this is typically the first time an organization gets a real, consolidated overview of the access that the people in the organization have. It is possible to generate a number of risk reports, which will most likely highlight some data quality issues and security threats. In an iterative process, the organization can then confirm the required accounts and access and remove unwanted objects. With this type of reconciliation, it is much easier to cope with the task of getting to a “managed” state, as at any point in time, the organization can measure the security improvements made, providing important key performance indicators for the governance of the organization.
The second scenario to highlight, is the re-synchronization in the event of a technical failure of the connection between the identity management and access governance solution and the managed systems, or of the identity management and access governance solution itself. For example, if the connection between the identity management and access governance solution and Active Directory is down, Active Directory will still be operational, and administrators may make changes to accounts and group memberships directly in Active Directory. As soon as the connection is re-established, access data can be reconciled in an automated and controlled fashion. It is possible to evaluate the differences and, if needed, decide explicitly which of the administrative actions to accept or reject, bringing the organization back into sync.
Reconciliation in “loosely coupled” scenarios
Reconciliation can also be used in cases where organizations want to control systems that lack proper management APIs or where organizations prefer to administer manually. An example is legacy applications, which do not provide APIs for managing authorizations; therefore, after new authorizations have been requested and approved in the access management solution, an administrator enters the authorization manually in the application. Any administrative error or malicious action will lead to a potential security threat. In this scenario, reconciliation can often still be applied: If existing authorizations can simply be downloaded on a regular basis, it is possible to compare desired and actual states of authorizations and detect and remove critical situations.
Reconciliation provides what security practitioners are looking for, allowing them to be confident that security issues are detected and remediated reliably. The security practitioners thereby get a mechanism which is fully aligned with compliance best practices, a key concept for a robust, fault-tolerant identity management and access governance system.
