Who should setup access in the ERP (Financial Application)?
As an IT auditor for local governments, one of the most often asked questions I get during audits is this: “Who should set up user access in the financial application?” There is a debate concerning whether it should be IT or finance staff that creates accounts and is involved with setting up access. My answer, as with many professional questions, is, “it depends.” Specifically, it depends upon other controls that might be in place. What I like to do with clients is walk them through the needs and risks to help them design and understand the process they come up with. Let’s walk thought the logic and see what the best answer for your organization may be.
This is a summary of a talk I recently gave at the 2019 CSMFO conference in Palm Springs.
The goal in access control is to control access to the financial system so that malicious factors do not cause the system to be unavailable, violate the integrity of the system or data, or expose any sensitive or confidential information. We want to ensure the financial system and the data in it maintain integrity, availability, and confidentiality. To do that we need to control access to the system and limit what users of the system can do with a principle we call ‘least access’. The principle of least access is to limit access to only what is necessary for users to perform their job functions. For example, if in their job function, they do not need to print checks, they should not be granted that level of access or permission.
I will start with a very common practice. I often see account creation and permissions set on accounts by finance staff. The rationale is that it is easier for finance staff to setup the account because they understand the permissions needed to maintain the separation of duties within financial functions and processes. The figure below illustrates this process.
Image 1
The weakness of this process is the person or people in finance that have that administration/root privileges in the financial application can always set up accounts, change permissions, and delete logs. Essentially the account with administrative privileges can perform any function within the financial application, including covering up their actions. There is no real separation of duties for financial functions within this scenario. Anyone with administrator privileges on the financial application will be a suspect in an investigation.
Another common scenario is one I like to call “pseudo two-man control”. You are probably familiar with the two-man rule from movies involving nuclear missile launches, where it takes two people to punch in codes and turn two separate keys to initiate a launch. I call it ‘pseudo’ because it appears to be a two-man rule, but it is not. The typical scenario is where IT will provision an account and then the account will show up in the financial application. There are a few different ways this can happen. Once the account is created, then someone in finance will set the appropriate permissions for the account. This is a pseudo two-man control because it does not take two people to create an account or two people to set permissions. (It would be nice if developers would add controls like this.)
In this scenario, it is possible for the person in finance to change permissions on an account or possibly hijack another person’s account to do whatever nefarious deeds they have in mind. Often within the financial application the ability to change user permissions comes with permissions to delete audit/event logs. If not, the person could easily assign permissions to themselves. Another aspect that needs to be covered is that with the ability to change permissions often comes permission to reset passwords for users. In this case, the person in finance with these privileges can hijack another person’s account to try to cover up their actions or make it look like someone else did the deed. If investigators come in, the person with these privileges will automatically be a suspect.
In general, this IT scenario is separated from all financial functions. However, there may be alternative ways for IT to gain access. It depends upon the financial application’s controls. I have an illustration of the process below.
Image 2
Another process I often see is where a request is made to IT for an account to be added or a change in permission and then it is reviewed by the finance staff. This is good for the finance staff as it ensures separation of duties on the financial side. However, the weakness is that IT still has total control and no provision for someone to check to see if IT has made any changes. In theory, a malicious IT user could make changes to the vendors, create user accounts, or grant themselves access for any financial function. See process outline below.
Image 3
For the best solution we need to add oversight to the process. The best way to do it is to have a helpdesk request for any account creation or modification along with audit logging. An independent person, internal audit, or security, can review the audit logs to ensure that only the requested changes have been made and no other unknown changes are made. This sounds easy but can become challenging because IT can often delete or possibly alter logs. So controls need to be put in place to ensure the integrity and availability of the audit logs.
One note about the audit logs. Logging needs to be done in the financial application, on the data base, on the operating system, and the virtual environment. Often IT can make changes that do not appear in the financial applications logs.
Image 4
Why do all this? For one, IT should seek 100% transparency and the ability to demonstrate that IT staff did not make any alterations to any financial information. Another reason, is because it is good internal control structure that will help reduce the risk of fraud. A good control environment only serves to benefit an organization. Poor controls leave the doors open for potential fraud.
