Privileged access and segregation of duties in IT environments

• Identify privileged accounts across application, database and operating system layers
• Test controls that restrict and monitor privileged activity
• Evaluate segregation of duties conflicts using a conflict matrix
• Assess mitigating controls when conflicts cannot be removed

Why privileged access gets its own lesson

AS 2110.B4 names the possibility of IT personnel gaining access privileges beyond those necessary to perform their assigned duties, thereby breaking down segregation of duties, as a specific risk from IT. Privileged users can create users, change configurations, alter data outside normal workflows, and sometimes delete the logs that would show what they did. One unmonitored administrator account can undermine every other access control.

Where privileged access lives

Ask for the listing at each layer for each in-scope application. Generic accounts deserve attention: if five people know the password to a shared administrator account, you cannot attribute activity to any one of them.

Testing privileged access controls

Common key controls and how to test them:

1. Restriction. Privileged rights are limited to people whose jobs require them. Obtain the privileged user list, validate its completeness, and inquire and inspect job descriptions for each user. Finance users with administrator rights are a red flag.
2. Approval. New privileged access is approved by a designated owner. Test as for provisioning.
3. Monitoring. Privileged activity is logged and reviewed by someone independent of the privileged users. Test a sample of reviews: was the log complete, was the reviewer independent, were unusual items investigated?
4. Vendor and emergency access. Accounts used by vendors or for emergencies are enabled only on request and disabled after use. Inspect enable and disable dates against requests.

Segregation of duties in systems

Segregation of duties (SoD) prevents one person from both initiating and approving, or recording and safeguarding. In systems, SoD is enforced by roles and permissions. A conflict exists when one user holds two permissions that together allow an error or fraud to go undetected, for example:

• create a vendor and approve payments to vendors;
• post a manual journal entry and approve it;
• change customer credit limits and release orders on credit hold;
• develop code and move it into production.

Using a conflict matrix

A conflict matrix lists the sensitive permissions on both axes and marks which pairs conflict. The audit approach:

1. Agree the conflict rules with management (they own the control).
2. Extract users and permissions from the system and test the extract.
3. Run the rules against the extract to list users with conflicts.
4. For each conflict, determine whether it is removed, accepted with a mitigating control, or unresolved.

A segregation of duties conflict matrix gives a starting layout.

Mitigating controls

Small finance teams cannot always separate duties. A conflict can be accepted when a mitigating control is designed to catch the risk the conflict creates and is precise enough. For a controller who can both post and approve entries, a mitigating control might be a monthly review by the CFO of all entries posted by the controller, using a complete system report. Test the mitigating control directly, including the completeness of the report it uses. A general statement that "the CFO reviews the financial statements" is not precise enough.

Linking to the financial statement risk

For each unresolved conflict, ask what misstatement could result and whether anything happened. Run the transactions the conflicted user both initiated and approved during the period. If none exist, the risk did not crystallize, but the deficiency remains and is evaluated on what could have happened.

Administrator rights at Cobalt Ridge Engineering