By Andrew Morris
With the vast majority of ERP user activity taking place at the application level, it stands to reason that security professionals should focus their Access Management efforts in this domain.
Yet in doing so, they often neglect the infrastructure on which those applications run – despite the fact that all data stored in the programme layer is equally available via the infrastructure.
An organisation’s underlying infrastructure is a complex web of operating systems, databases, network connections, servers and interfaces, all pushing and pulling data around the business. As such, it represents an almost infinite array of access points that pose significant risk without proper Access Controls.
In many cases though, these risks are overlooked, with infrastructure managed purely for performance, not security.
While ERP security experts take care of the application layer, infrastructure is often passed off to operational teams with more limited knowledge of ERP security and Access Management best practices.
These teams are usually tasked with just one key goal; to keep your enterprise applications up and running.
As a result, while access may be managed appropriately at the application level, access to infrastructure often remains wide open.
At the very least, this puts the organisation at significant risk of regulatory compliance breaches – with today’s key legislation covering all places where data is stored, processed and transmitted.
Auditors, too, are increasingly looking beyond application controls and into infrastructure, providing more cause for concern for organisations failing to cover both bases.
That’s not to mention the potential downtime and disruption that would be caused by an actual incident, the likelihood of which also naturally increases with poor access management provisions.
Gaining control over infrastructure
Rising levels of threat and legislation mean it’s time for organisations to take firmer control over infrastructure – taking access management beyond the application layer.
Here are four key questions you should be asking to determine your current levels of control…
1. Who has access to your infrastructure?
It should be straightforward. In an ideal world, only the basis team, database admins, backup administrators and some Unix administrators or operating system administrators should have access at infrastructure level.
More often than not though, access extends much further. There may be old accounts still in existence, left behind from team members or third parties who have since moved on. In most instances, these accounts would not be closed automatically.
Depending on your validation protocols, password sharing could also be taking place, spreading the network of access further still.
2. Are users’ changes being logged appropriately?
Enabling logging functionality is essential to maintain visibility on who’s accessing your infrastructure and what they’re doing.
It will enable you to monitor critical changes, system restarts or any other significant events, and to detect any instances of inappropriate use.
However, in order for your logging to be effective and insightful, it’s crucial that users are logging in with their own identifiable credentials. More often than not, that isn’t the case – they’re using shared accounts, or accounts incompatible with your naming conventions.
3. Do you know if access is appropriate?
Once you’ve ascertained who has access to your infrastructure, you also need to know if that access is appropriate in every case.
Why do the individuals in question require the access they have? Who are they, what is their job role, and what part of that role makes access a necessity? Are they even using their access?
If you don’t have this kind of insight on your users, it’s impossible to know if your permissions are appropriate.
Ultimately, the key question you need to answer here is what access should a user have, as opposed to what access do they have?
Even if access has historically been given (with justification) to certain roles, it may not be necessary for every individual in that position – and unnecessary access is simply unnecessary risk.
4. How quickly could you act in the event of an incident?
While assessing how your infrastructure access is secured and controlled, it’s important to take the worst case scenario into consideration.
If controls were to fail and your database went down, how quickly would you be able to act? How soon before you could get your systems back online?
Beyond that – how quickly and easily could you find out what happened and who caused it? Would you be able to prove any of it?
Regardless of how fast you might be able to get up and running again, it’s these final two points that will ensure disaster doesn’t strike twice.
While ERP security professionals focus heavily on access management across the application layer, securing access to the underlying infrastructure is often something of an afterthought.
Yet all the data stored within the application itself is also available via the infrastructure – and the risk of malicious data access or internal misuse at this level is often just as high.
Organisations must, therefore, start to take firmer control on infrastructure access management, starting by addressing the four key questions above to define their current status.
For those unable to answer in a satisfactory fashion, a more thorough investigation into infrastructure access will be required to ascertain the risks, and tighten the lock on your business data’s back-door.