Auditing Identity and Access Management

Effective audit processes provide reporting capabilities along with operational and management dashboards for identity management and access governance scenarios. This provides IT auditors the ability to understand risks, establish controls, evaluate the existing risks, monitor them, and take corrective action. Examples of such controls are orphaned accounts, entitlement creep, SoD violations, and visibility into privileged user accounts.

Advanced auditing processes deliver a comprehensive overview of access rights based on identity intelligence from data collected across business-critical systems and applications. Identity and access data is envaulted and compared against policies and any inappropriate access rights or SoD violations will automatically be identified to enable instant remediation actions to be performed.

Analysis and reporting features deliver identity intelligence and answer the basic questions of ”who has access to what”, and “who approved that access”. Auditing evaluates policies for identities, accounts, entitlements, separation of duties, and privileged accounts against the actual state of identities and access rights, alerting system and control owners of exceptions and supports a timely and orderly remediation.

Validating the expected state of business policies against the actual state of access rights in the applications and systems being managed, warns the administrator, system owners, and security operations of any items or incidents that require attention.

Why Auditing is important

Auditing Process

As part of Omada IdentityPROCESS+, an identity governance framework focusing on best practice processes, there are several key components to Auditing that are critical to follow best practices to ensure business efficiency is optimized, security is tight, and compliance is met.

The Auditing process area includes the following process groups:

1. Audit trail
2. Audit history
3. Audit Log
4. Audit Policies
5. Audit Response

These process groups are further explained below.

Process Group: Audit Trail

Audit trail functionality enables the auditor to gain insight into why access exists and exactly who authorized it and how that access came to be. All customers are subject to one form or another of compliance regulations. This is most apparent for customers within regulated industries or organizations that are ISO certified. They should operate with scheduled and ad hoc security assessments to constantly monitor and alert the responsible teams, if policies are violated or
security is potentially compromised.

CIOs and CISO’s must ensure that security policies are followed and must be able to provide documentation for the ability to protect sensitive data, and consistently ensure that the organization adheres to compliance requirements across all systems and applications.

Audit trail is a key feature for auditors as it includes processes for documenting:

• Audit trail for all identity decisions
• Audit trail for resource assignments to determine why access has been granted
  and who authorized it
• Audit trail for resource assignments that have been overridden to determine
  why access has been given and who authorized it

Process description. The audit trail generates detailed reporting on decisions that have affected resource assignments. The audit trail offers filtering, searching, and sorting capabilities, as well as the ability to drill-down to detailed specific resource assignment reports.

Audit trail reporting and analytics functionality uncovers any improperly assigned access rights or separation of duty (SoD) violations, and answers – how, why, and when the violation was configured or approved. All decisions for identity entitlement assignments are tracked and available in the audit trail report. Answers given during access approvals, re-certification surveys and SoD reviews are all recorded, and available for reporting functionality.

Best practice IGA system functionality. An IGA solution should provide a consistent level of audit trail data that includes a complete set of information for object changes, changes to permissions, access requests, approvals and custom objects. This level of functionality is essential for auditors and stakeholders who require instant visibility of access rights and need to have the ability to document all aspects of how, when, and why they were granted, including any activity that occurred during access approvals, re-certification surveys, and SoD reviews.

Technical process flow:

1.  An employee submits an access request stating the reason for the request and the request is recorded
2.  The access request is approved both by the manager, and the resource owner of the resource, responses are recorded
3.  The access is provisioned, and the audit trail is captured including data on approval, justification, approver, approver role, and time stamp
4.  The audit trail is captured and imported into a data warehouse, and exposed in standard reports for further analysis and documentation
5.  The audit trail is archived to be available for historical analysis

Process Group: Audit History

History is a key requirement for audit reporting and enables the organization to fulfill the auditor’s documentation requirements in a prompt and efficient manner. Auditors should have access to on-demand reports and supporting documentation, including historical data for identity lifecycle processes, access requests, account changes, entitlements, and approvals.

Process description. The History process ensures all historical process data across on-premises and cloud-based systems within the management of an IGA solution. Historical data should be presentable via a dashboard for analytics and exportable in multiple reporting formats for: identities, accounts, resource assignments, policies, and systems.

Historical data should be collected and stored within the IGA solution’s data warehouse and archived properly. This will result in the ability to provide a complete overview with compliance relevant statistics. The process should provide a specific date/time-stamp functionality, for documentation of specific actions at any given time. Advanced historical auditing features point in time, changes within period, historical development, and change log reporting.

Best practice IGA system functionality. Any and all objects in the IGA system should enable the auditor to define the search scope and the parameters, which can include: effective times, validity dates, status, categories, and usage patterns based on selected values such as identities, contexts, accounts, resources, resource assignments, orphan objects, account usage, data quality, and systems. The data is extracted from the IGA data warehouse and archive to generate reports. The ability to configure dashboards and custom reporting frameworks can be configured and the data should be exportable in multiple formats for further analytics.

Technical process flow:
1.  The data object state is stored and available within the data warehouse
2.  Each object type, for example account and resource that is imported into the data warehouse, is modelled as a Slowly Changing Dimension (SCD) that tracks the history of the object state
3.  Changes to the object state is detected by comparing objects being imported to objects that are already stored in the data warehouse database. Objects comparison is performed at the attribute level
4.  If the status attribute on an object is changed, the data warehouse creates a new version of the object with the new version value
5.  The history of an object consists of all the tracked versions. Each version represents the object state for a specific point in time, indicated by an effective and expiration time
6.  Historic data is displayed from the data warehouse to the dashboard for auditing reporting

Process Group: Audit Log

To demonstrate that an organization is taking the appropriate actions to monitor access and ensure regulatory compliance measures are being adhered to all survey audits must be logged as an assurance mechanism for the auditor to validate that appropriate controls are in place.

Process description. The auditor, system administrator, and relevant system owners have the ability to view assigned survey audits and update them in real time as well as review the reports for continuous evaluation of key controls, business rules, data integrity, and performance.

The auditor should have the ability to verify and prove that a survey audit has taken place in accordance with security requirements, regulatory controls, and business policies, with a date and time log of any remediation actions.

Best practice IGA system functionality. Auditors, data protection officers (DPOs), or system administrators are provided with a dashboard view through the IGA portal. Based on the system administration view the dashboard will allow the auditor or administrator to leverage the various widgets to display information from sources such as the event viewer, application logs, IGA processes, SQL processes, etc.

Technical process flow:

1.  The auditor or IGA system owner can review all compliance surveys that have been performed by the IGA system
2.  Locate the survey additional information is required for
3.  Review the details of the desired survey in real time
4.  The ability to review responses and export to a PDF for printing is available
5.  Repeat this process for all surveys that this level of information is required for

Process Group: Audit Policies

Typically audit policies are aligned with an organization’s business rules and then incorporated into the relevant IGA processes. Audit policies should be reviewed on a routine basis to ensure they are effective in providing enforcement and the desired business results. To ensure continuous policy compliance and data integrity the organization should leverage supplementary audit policies in addition to the key controls that are built into the IGA processes.

Process description. Audit policies evaluate business rules and controls against the actual state of identities and associated access rights. In the event inconsistencies or violations are discovered, the process should include a method to alert control owners and include the option to perform remediation actions.

The process includes the ability to perform policy management through an auditing dashboard that displays all audit policies that a user is authorized to view and manage.

Best practice IGA system functionality. Audit policies should be configured to constantly review all active identities and compare the actual versus desired states. This comparison will reveal any inconsistencies to the proper support teams, such as technical accounts without owners, contractor access with missing or invalid expiration dates, roles with conflicting entitlements or violations within the separation of duty combinations, or privileged accounts / entitlements not included in recertification surveys.

1. Control Policies

Used on an ongoing basis to detect and react to inconsistency within the policies. Potential issues include objects that do not have an owner, circularities in the role hierarchy, and roles without proper descriptions and mandatory fields defined. In case of an issue within a policy an audit case workflow is launched and assigned to the policy owner to remediate.

2. Constrain Policies

Are typically used to detect conflicts or problems within separation of duty policies. The policy owner should have the ability to override and accept violations
after providing a justified reason for the need to implement compensating controls. SoD constraint policies are evaluated every time the access rights for an identity are re-evaluated within the IGA solution.

3. Risk Scoring

A focused policy used to define the risk to the enterprise for improperly configured control policies and constraint policies. Every improperly applied policy and
override of a constraint policy contribute to the risk score.

Process Group: Audit Response

Audit response processes enable the organization to ensure that exceptions are detected and handled by the responsible policy owner who can take corrective action.

Process description. The IGA solution should be configured to continuously evaluate policies on defined schedules or triggered ad hoc by an audit policy owner. Audit response processes are designed to address any policy violations or exceptions that are revealed as a result of the policy evaluation.

Policy violations should be treated as cases or incidents and tracked via an escalation workflow for actionable follow-up and remediation.

Best practice IGA system functionality. When a policy exception is detected or observed, control policies trigger a workflow that alerts the policy owner. Part of the workflow process is to determine if an incident/case already exists for that specific violation/exception and determine whether a new case/incident should be created.

The workflow alerts the policy owner, a user’s manager, or information security teams who could have a specific role to determine the correct remediation approach for the incident. Depending on the type of policy violation and exception required, the policy owner may be able to allow, correct, or mitigate the incident or close the case.

Technical process flow:
1.  Data from target systems are loaded into the data warehouse. History and KPI improvements are monitored
2.  Accounts are matched to identity master data and consolidated for a cross-platform view of identities to access risks
3.  Changes to the state are detected by comparing imported identity data to the stored data. Relevant exceptions are revealed immediately in the audit report dashboards
4.  If the status is changed an exception alert is created
5.  The policy owner receives alerts with a list of exceptions
6.  The policy owner determines whether the exception is a new or existing, and either opens a new case or overrides the exception
7.  The policy owner performs an analysis of the exception and decides whether to remediate, mitigate, or update data depending on the associated audit control policies. Automated exception mitigation processes can be applied
8.  Exceptions and actions are logged in the data warehouse to provide a historical perspective

Process Stakeholders

Within IGA processes, it is critical that multiple stakeholders are aligned and working together. For Auditing, the following teams must be involved.

1. Executive Team
   • Establish vision for Audit efforts
   • Review results to ensure Audit requirements are addressed
2. Policy Owners
   • Ensure that policies are aligned with business needs
   • Participate in reporting and certification campaign scoring and follow-up
3. Auditors
   • Define audit parameters
   • Conduct the audits
   • Participate in testing audit functions
   • Analyze and remediate exceptions
4. IGA Team
   • Configure and monitor

Key Best Practice Recommendations

Define effective audit processes

It is essential that audit policies are aligned with the business and deliver the expected results. The audit processes should always provide answers to the questions of “who has access to what, who approved that access or policy exception?” Use control policies to detect and react to inconsistency within the policies. Provide a remediation workflow to address any issues discovered within the policies. Leverage constraint policies to detect conflicts or problems within the separation of duty policies and provide a way to document policy exceptions and overrides (compensating controls). Assign each policy object a weight/score and include a risk scoring control to understand the exposure of policies not being implemented or enforced properly. Provide auditors governance dashboards and the ability to report the status of the various policies, and for continuous evaluation of key controls, business rules, data integrity, and performance to ensure each policy object is being historically documented and stored properly.

Establish effective SoD audits

The lifecycle of permissions and roles can be very dynamic. As a result, separation of duty policies (SoD) can over time become highly complex and difficult to manage. This also can lead to the policies becoming stale or dated, resulting in the generation of false policy application results. Without a business-oriented approach the organization will struggle to deliver effective SoD audits. Therefore, it is recommended to define separation of duties (SoD) policies based on business processes, supporting the standard approach of roles and permissions.

The list of business processes can be hierarchical, allowing the organization to define both fine-grained SoD but also broader operational constraints. The organization can rapidly introduce new SoD constraints without needing to rebuild their role catalogue, since the SoD policy is based on business process that changes much less frequently.

Ensure ongoing compliance

Some organizations implement scheduled security assessments once or twice a year or quarterly, an approach that has the potential to create gaps in security that can go undiscovered for months at a time. In regulated industries and for mission-critical systems, it is highly recommended to conduct audits more
frequently. To constantly monitor and alert if policies are violated or security is compromised, policy auditing processes can be set to run as a continuous activity
to achieve the following:

1. Establish constant controls of access to business-critical data and IP
2. Identify and resolve SoD issues
3. Ensure that all relevant access rights are identifiable
4. Review policies quarterly for effectiveness
5. Refine and apply granular reporting and analysis

 Summary

Advanced auditing capabilities support the business policies and should be included in the organizations’ IGA processes. Extending the IGA framework with automated processes for auditing ensures data integrity by detecting and remediating exceptions, so the desired policy results are accomplished.

Leveraging in depth reporting, analysis and evaluation of policies for identities, accounts, entitlements, separation of duties, and privileged accounts provides effective auditing. Automated audit processes provide the ability to compare the actual state of identities and access rights in comparison with the expected or desired state, the capability to alert policy owners of violations and exceptions, and deliver a workflow that facilitates a timely and orderly remediation.