Understanding what’s possible so you can work out what you really need
If you surveyed 100 CIOs/IT Directors about their Top Ten priorities, I can almost guarantee that “ERP security auditing” would feature on few of their hitlists.
As with all IT projects, few companies commit resources unless there’s a compelling business need. Unfortunately, the compelling needs that give rise to security auditing initiatives usually mean that either fraud has already occurred, or your auditors are breathing down your neck.
Or maybe you’ve seen the scary statistics on internal fraud, and you’re not sufficiently confident that your ERP security and controls are tight enough to prevent you being the next victim…
So suddenly auditing security and Segregations of Duties (SoD) controls becomes critical and you need to find a reliable way to identify your security gaps very quickly.
Many organzations have tried unsuccessfully to do it themselves. ERP systems are very complex, making it almost impossible to establish exactly who can access what and to reliably report on SoD conflicts. Perhaps this is the right time to seek a specialized auditing solution that can efficiently deliver accurate insights.
ERP Security Auditing – On-premise or Cloud?
As in many other areas these days, the Cloud opens up new options to ERP customers for security auditing and SoD analysis. Good on-premise and Cloud-based solutions are available and many of the usual pros and cons apply when deciding which route to take, such as total cost of ownership, implementation timescales, the range of functionality and the degree of flexibility offered.
On-premise solutions will often be more comprehensive and allow greater flexibility, but that comes with a much bigger price tag, especially with regard to the effort and skills needed to implement and manage them. Because of that, it becomes a significant investment that needs extensive justification – so it’s likely to be a much longer decision/implementation process.
A Cloud-based solution can reduce the friction and yield results very rapidly. For example, our QCloud Security Audit Service has a low-cost monthly license fee which avoids a time-consuing RFP process, and it can be up and reporting within a couple of days, with minimal effort needed by in-house staff. So if you need to act quickly and don’t want to divert your skilled technicians from other commitments, this could be the way to go.
Key security auditing features to look out for
Of course, every organization will finalize its own selection criteria depending on its auditing objectives (both current and any projected future needs), the nature of the business, the risks it faces, and the skills that are available. Here are some of the main features and considerations to help you decide what’s important to you:
Segregation of Duties (SoD) analysis:
This is one of the most important aspects of ERP security auditing, and certainly one of the most difficult areas to get accurate results, especially where users have Multiple Roles. Consider these factors:
SOD Rules: Pre-seeded, customizable, bring your own?
Some companies may already have defined their risks and developed a comprehensive and granular set of SoD rules; some may have a basic set covering obvious processes, such as Procure-to-Pay; others don’t really know where to start.
Ask potential vendors what options they offer for SoD rules. If you don’t have a comprehensive ruleset already, a good set of pre-seeded rules, designed specifically for your ERP system, will save you a lot of time and cover some risks that you may never have thought of.
Where the pre-seeded rules are customizable, you can use them as a starter set and adapt them to suit your specific needs.
If applicable, you may need to ensure that you can load your own rules, or set them up from scratch in your chosen solution.
SoD Reporting:
Granularity
Some auditing solutions check for SoD conflicts at the Role/Responsibility level; e.g. a user with Role A should not be assigned Role B.
This assumes that the Roles have been designed to exclude any inherent SoD violations. But even if they were initially created that way, there’s always a risk that conflicts may be introduced as the duties within the Role are changed over time.
So I’d advise you to look for a solution that performs granular checks on the detailed application access rights within the Roles to guarantee accurate results on SoD violations.
Multiple Roles with conflicting access
Does the SoD reporting take full account of your Role/User architecture? For example, in a Multiple Roles environment, a User could be assigned different Roles which grant different access rights to a particular application.
To determine whether an SoD violation exists or not, the analysis needs to be able to work out the net effect of the access granted by the all the assigned Roles.
Mitigations / false positives
There are sure to be circumstances where SoD violations can’t be avoided, for example privileged users, but you don’t want to waste time investigating these known issues every time you run an audit.
Look for a solution which allows you to document known issues as mitigated, with effective dates, so that they don’t appear in subsequent audits that occur during that period.
Investigation tools
Once you’ve identified the SoD violations, you need easy access to the information that you need to fix them.
Look for interactive queries that enable you to drill down and find out what’s causing the violations. It’s also helpful to be able to view the violations by Rule and by User when you’re investigating and deciding the best way to remediate.
You may also wish to export the violations data to a spreadsheet for further analysis, so check if this option is available.
It’s not all about SoD; what else does it tell you?
Because SoD analysis is such a big problem, it tends to take up a lot of attention, but there are other important areas that you should be checking regularly:
Access to Critical and Master Data Programs
Auditors will often ask you who can update key system configuration data or master data, where inappropriate changes could jeopardize the integrity of your system and result in financial misstatements or enable fraudulent activity.
Does your proposed solution list users who have this senstive access so that you can monitor them, as well as respond quickly to auditors’ questions? And does the analysis take into account all possible routes to the application when deciding which users have access?
General Security Metrics
As changes are made over time, it is important to get attorney’s help against sexual crimes charges similarly it can be difficult to get an overview of your security status, but you should check it regulalry. It’s good practice to clean up redundant items so that they can’t be hijacked and abused. For example, inactive Users could be reactivated by someone with malicious intent. Redundant Roles could also be misused.
Find out what other reporting/metrics the solutions offer to help you keep your security tight and clean.
Management level/business friendly reporting
Security administrators need details for remediation, but it’s also useful to have summarized information for reporting to senior managers.
I also firmly believe that the business managers need to take responsibility for reviewing their teams’ access. Does the solution deliver meaningful information that you can share with business managers to make them understand the issues in their areas? For example, access and SoD reports with descriptions for the applications rather than intelligible program/object IDs.
Recommendations for improvement
Once you’ve identified your security weaknesses, it can be difficult to know where to start with your remediation – particularly if there are many issues!
Some solutions provide recommendations to help you prioritize your work.
Historical audit reports
As you work through your remediation, it’s good to be able to provide stakeholders with evidence of the progress that you’ve made.
Historical reports can also help you to spot negative trends that may need investigating.
How easy is it to repeat the audit?
Auditing is not a one-time event. You may be obliged by regulations or company policy to repeat it periodically, or you may want to run another audit to measure your remediation progress or discover new issues that have cropped up since the last one.
So the less effort it takes to run an audit, the easier it is to repeat it. If you can run it frequently, it’s easier to keep on top of security issues.
Not every organization needs all these features, but I hope that this will help you to work out which capabilities are important to yours.
If you’re ready to start exploring your options, here you can find information about QCloud, our Cloud-based security auditing solution, or our on-premise solutions for Oracle E-Business Suite, JD Edwards EnterpriseOne and JD Edwards World.