Lack of Software to Test Access Controls is Systemic and Why It Matters [Part 2]

In part 1 of this article series, I postulated that there is a systemic issue related to management override of controls. More concerning than the existence of this issue is that it isn’t being addressed by management or the audit community. This issue is systemic. Let’s discuss what changes we would need to see to correct the current situation.

Changes Needed in the Industry

1. Management needs to own and maintain access control software in order to have effective controls. The adoption rate for publicly traded companies having owned and implemented access control software is less than 10% based on my estimates.
2. The content used to test access controls does not fully address the risks that need to be tested.

Our risk content, ERP Armor, is the exception to this second comment. We would be happy to talk about how we can help your organization increase its effectiveness in testing access controls. We can also significantly lower the long-term cost of ownership of access control software if you would be interested.

There are a series of controls management must have in place for their control environment to be complete and effective. Access control software is needed to regularly test these controls to provide “reasonable assurance” regarding the effectiveness of the controls. I will argue that certain controls actually require a higher standard than reasonable assurance given the risks associated with certain processes.

Examples include:

• Password resets
• Logon of highly privileged accounts
• Application of patches
• Firewall configurations
• Antivirus configurations
• DDL changes
• Direct database updates (DML)
• Code migration / updates to existing code
• Vendor master data changes
• Setting up new users
• SSO configurations
• MFA configurations

Look back through the listing above. Which ones of these do not seem essential to have a comprehensive / complete control environment? I can honestly say since the implementation of Sarbanes-Oxley, the number of companies that possess appropriate control design for all ‘in-scope’ systems, implemented and operating effectively is close to 0%, if not 0%.

To prevent fraud, some controls MUST be perfect.  For some controls, reasonable assurance means 100% sample sizes by management.  Management, external auditors, and internal auditors need to stop hiding behind the concept of “reasonable assurance” as being “good enough.”  One wrong access control by a bad actor like Sam Bank-Friedman can cause a multi-billion-dollar fraud.

Why is the ownership of Access Control software essential?  Because access controls form the foundation of your control environment and controls cannot be complete or mature without the use of Access Control software.

However, it is not JUST that access control software is needed.  Another essential element that is needed is the proper content being used by this software to test the controls. This proper content we refer to as “risk content”.

Access control software is like having a car.  Effectively designed “risk content” is the gas that fuels the car.  Access control software and risk content go hand in hand.  You cannot have one without the other. Neither will work without the other.

Management needs to adopt access control software and risk content for their controls to be effective.  The software needs to be complete and accurate, and the risk content needs to be complete and accurate. Both the software and risk content need to be up-to-date.

Let’s next look at the various sub-controls related to access controls.  We will provide a high-level analysis of each control and the residual risks management is taking without the use of Access Control software and effective risk content.

Sub-Controls Related to Access Controls

These processes that require access control software are:

• Role Design
• Provisioning
• User Access Reviews / Re-Certifications
• Role Change Management
• Patch Change Management
• Development Change Management
• Cyber Incident Risk Analysis
• Testing the Independence of Controls Performers; Changes to…
• Lookback Procedures
• License Exposure

We will delve into each of these processes and discuss how access control software is needed.

Role Design

When a new custom role is built or a new vendor-provided (seeded) role is going to be assigned for the first time, the role should be reviewed to make sure it is designed appropriately. A sensitive access analysis should be run to evaluate if any of the security objects assigned to it are not appropriate for the intended purpose of the role. Once the inappropriate activities are removed from the role, then a segregation of duties conflict analysis should be done to make sure the remaining activities do not cause an unwanted conflict.

See our case studies for more info.

Provisioning

Whenever a user is being assigned a new role a sensitive access analysis and a segregation of duties conflict analysis needs to be performed. The risks identified should be presented to the process / risk owner(s) before the provisioning is done to make sure the assignments do not introduce unwanted risks (sensitive access risks or segregation of duties conflicts).

User Access Reviews / Re-Certifications

When UARs / Re-certifications are done the process / risk owner(s) should be re-presented to the process / risk owner(s) to make sure each user does not have unwanted risks (sensitive access risks or segregation of duties conflicts).

Role Change Management

When a role is being changed, the role should be reviewed to make sure its assignments do not have unwanted risks (sensitive access risks or segregation of duties conflicts). Further, if the change to the role ADDS a security object, a full analysis should be done for all users having access to that role to make sure the additional access does not cause a new segregation of duty conflict.

Patch Change Management

When a patch is applied to the system, a couple of risks need to be considered. First, consider that new security objects may be introduced as part of the patch. The first step is for management to make sure these risks are reflected in their risk content. New sensitive access risks and updates to current sensitive access risks may be needed. New Segregation of duties conflicts may be needed or updates to current segregation of duties conflicts may be needed. This is what is provided in our risk content called ERP Armor. Contact us here for more information about our affordable ERP Armor: Rules annual subscriptions.

A second risk when a patch is applied is that a role could be changed to add one or more security object(s). Further, it could also make a change to a role that isn’t currently assigned but may be assigned in the future such as a firefighter or change management role that is only temporarily assigned when justified via a change ticket. A full scan of the Sensitive Access risks and Segregation of Duties conflicts should be done before and after the patch and a comparison made of new risks that need to be considered. Often this will lead to role remediation and perhaps user provisioning changes that will need to be applied once the patch is applied to Production.

Development Change Management

When new development objects are built or changes to current objects are made, management needs to take these into account in their risk content. We recommend that a new sensitive access rule needs to be developed. Even where management may deem the new development as low risk, we still recommend that a sensitive access rule be built in their risk content library. This eliminates possible questions from auditors as to whether all custom objects have been evaluated by management in their access controls design.

Once the new sensitive access rule is developed an assessment is done to evaluate that the new object(s) were only assigned to the appropriate roles. Results should be presented to the control / risk owner before the development is migrated to production.

Cyber Incident Risk Analysis

When a breach occurs identifying the compromised credentials of one or more users, it is necessary to assess the potential impact. This is done by identifying the significant activities the user(s) can perform. Access control software is needed to evaluate the sensitive access risks and segregation of duties conflicts associated with the compromised accounts.

Testing the Independence of Controls Performers

As we identified in part 1 of this article, the independence of the control performer must be tested. This is done through these five steps:

1. The financial audit team needs to identify what controls implemented by management they would be relying on in their audit.
2. The RACM would most likely identify a job title rather than a person that is part of the control performance. Management would need to identify who is(are) the control performer(s) and financial audit team would need to verify that is consistent with their testing.
3. The IT team would need to identify the logins for the control performer(s) in each of the in-scope systems.
4. A full sensitive access analysis assessment process would need to be executed. This would consist of full details of all users, including all Control Performers and their access via assigned roles. There would need to be logical understanding and technical confirmation that the scan is complete and accurate.
5. Once it is established that the assessment is complete and accurate, the activities that a Control Performer can perform (transactions, master data, and configurations) would need to be compared to the control activities and control description to see if their access impairs their independence.

Lookback Procedures 

There are several instances where lookback procedures should be performed where access control software is necessary. They are in circumstances such as:

• A user has been identified as having too much access by management, an internal auditor, or an external auditor resulting in the removal of a role or the development of a lesser privileged role that replaces their current role.
• During a user access review / re-certification, the process owner or supervisor has identified a user having too much access or a change to the access due to a job or position change wasn’t done in a timely manner.
• A role already assigned to a user or group of users was identified as having too much access and a role change management ticket was processed to remove the excessive access.
• When a development change was moved into production, it was overprovisioned to a role.

License Exposure

Most ERP software providers clearly identify what abilities are tied to licenses. In these cases, access control software can be used to identify what is the current license usage. Access control software is particularly useful given it de-normalizes the roles assigned to users. This provides a clear understanding of what roles and security objects a user has access to. This data is also needed to understand what security objects a user has driving the demand for a software license.

In part one of this article, I discussed the lack of control performer independence testing is a systemic issue in the audit community. In this article I articulated access control software is necessary to test up to 10 different scenarios. This low adoption of access control software is a systemic issue.

We can uniquely help the C-suite increase its effectiveness and efficiency in testing access controls through our ERP Armor content. We can also help internal auditors and external auditors in their efforts to test access controls. Feel free to contact us here for more information.