Privileged user access could be the biggest hole in your security – don’t let it leave you vulnerable to fraud
When it comes to audit reporting and associated findings, our clients frequently ask us for recommendations on managing and monitoring privileged user access. In this article I will cover the main things that you need to know to satisfy your auditors and reduce your risk of fraud.
A privileged user is someone who has administrative type access to critical systems.
Typical job functions include:
- System / Database Administrators
- Human Resources Staff
- Support Staff
As ‘trusted’ users, they have the most powerful access of anyone within the organization. Often, they are able to carry out a wide range of system administration tasks, such as amend system configurations, install and/or upgrade software and change access for other users. They may even be able to override existing security policies, make unauthorized system changes and access confidential data.
It’s worth remembering that privileged access rights can also be granted to Service Accounts, such as those which are set up to manage integrations. Although these accounts are not intended for use by humans, they could be abused by anyone who knows the credentials.
Privileged user accounts: magnets for hackers, fraudsters and auditors!
Due to the extent of their access, these accounts can be prime targets for external attackers if they can get hold of stolen credentials. You’d be surprised at the number of people (especially contractors working for multiple clients) who write down their password on a sticky note or in a book and leave it on their desks.
Some legitimate privileged users may be tempted to sell data on a per record basis for financial gain. Others may simply make an error, such as forgetting to change the default administration account and password after an upgrade.
All these scenarios mean that privileged user access poses a significant risk to your organization. For this reason, external auditors will request to review your procedures for controlling and monitoring these users.
The growth of privileged access increases the risk of fraud
In recent years, as ERP systems become more complex, we’ve seen the number of privileged user accounts expand to cater for system expansion, such as development projects and upgrades involving many consultants. Privileged access is also used more frequently these days for automated service accounts for integrations such as mobile devices.
So there is growing concern about the potential for fraud, and rightly so. PWC’s 2018 Global Economic Crime and Fraud Survey found that “52% of all frauds are perpetrated by people inside the organization.” It is therefore imperative that you implement rigorous risk management policies to protect your organization from the dangers associated with privileged access.
Many IT Managers attempt to mitigate these users or exclude them from regular audit reporting requirements by stating they are known or trusted – but that should not be acceptable to your organization and would likely result in a deficiency on your next audit.
As with any mitigation, the objective is to reduce the probability or possibility of an event to an acceptable threshold. So you need to consider your options for mitigating privileged access, the cost vs benefit of each option, and the impacts. Risk mitigation can be costly and time consuming, but not if you have the right information and proper tools to help.
Mitigating risk for privileged users: the 3 main areas to consider
1. Manage the risk:
Implement a User Management policy that tracks specifics about privileged user accounts, e.g. effective date, usage type (system admin or integration), vendor company name, expiry date of the contract, or the date when access should cease pending contract renewal. It’s about documenting the “who, what, when and where” for these accounts.
Access Management – people often focus on controlling access to roles, but it’s more important to restrict the privileges within the roles. The roles should be created using a model of least privilege, where users only obtain access to the applications, modules and data that they need to do their job.
For example, a System Administrator in JDE may not require access to business transactional applications in the production environment, provided sufficient support resources are available. Read more about this in our blog on access management
Password Management – passwords for these users should expire more frequently, on a set schedule. They should never be set NOT to expire.
I also recommend you implement a procedure for when a user leaves the organization or vendor; network access should be removed immediately, and passwords for service accounts should be changed when possible.
For shared passwords, such as those required for service accounts, passwords should be stored in a third-party password tool or kept in a secure, password-protected location.
2. Monitor activity:
Maintain on audit trail of changes to critical or master data, such as the address book, vendor / supplier master data and human resources data. Monitoring should consist of capturing before and after results, then reviewing them for unusual activity.
Set up alerts for events such as a high number of password change attempts (eg more than 5), or a significant period since last sign-on date (eg over 30 days). This ensures that you can keep an eye on unusual activity
Segregation of Duties – when access is granted either by a change in a role or the addition of roles to a user, it is critical to check whether this new access causes an SoD conflict.
User Access Review – conduct a review of privileged users on a more frequent basis than business users. We recommend you do this monthly.
Vendor Review – in conjunction with your User Access Review, you should also check the status of ERP access granted to any vendor employees who work with your organization.
Ask your vendors to regularly supply a list of their employees who are assigned to your account. Check for spelling of names / name changes, job titles / position changes and employment status, so that you can remove any redundant access for people who no longer work for them.
Service Accounts – ask for updates / status reports on the usage of these accounts. Ensure that usage is documented and updated regularly.
Passwords – review and set a schedule for when service account passwords should be changed (note that this may require system downtime). Require evidence of execution.
Terminate redundant access – revoke access when it’s no longer required. Institute an immediate termination policy and require evidence of execution.
I hope that this brief introduction has given you some useful insights and encouraged you to clamp down on privileged access in your ERP system. Keep in mind, some of the largest data breaches were carried out by insiders with administrative access, such as Edward Snowden.
If you’d like to automate your User Access Reviews, automatically track changes to your critical data, and proactively check for SoD violations, find out more about our tools that can help you to prevent and detect fraud in your ERP system.