Back to the brief topic of this blog.
I have audited many Oracle databases for customers over the last more than 20 years and quite a lot of these databases support ERP type systems such as SAP, PeopleSoft, JD Edwards, Oracle E-Business Suite and so on. Quite often these are the primary product used to support the business. When I conduct a security audit of an Oracle database I do the same level of audit for all types of database use. I have found that this conflicts with the ideas of security in ERP/Big systems. Over the years I see that security of EBS, JDE etc is considered at the level of the application. Often security teams and external consultants are looking at fraud, conflicts of interest, ERP privilege models and ERP security settings BUT there is often a lack of security awareness at the Oracle database level.
I have spoken a couple of times on this subject at the UKOUG and also a security conference in Slovenia.
This is interesting and we must ask why?
There are probably a lot of reasons why the Oracle database security is ignored or not paid the same attention as the ERP level security in companies:
- Companies simply do not consider the security of the Oracle database as they have been conditioned to think that security of a large business/ERP/type system is done at the level of the ERP
- Some companies have limited Oracle database staff as the database is installed and provided via the ERP. I see this in JD Edwards installs for instance where the Oracle database underpinning it is ignored.
- Companies treat the Oracle database (and would presumably treat SQL Server or similar in the same manner) as a sealed unit not to be touched or tampered with
- Companies are frightened to change the settings of an Oracle database supporting an ERP. I have seen this with SAP and EBS databases; indeed with SAP they provide their own database screens and tools to isolate the database. They feel if they change anything at all it could break the system for the business
- Some companies feel the vendor is responsible for securing the database itself. In one sense I can see logic in this. If a database is provided as a sealed using to support an ERP then the vendor should be able to lock it exactly the same for all end customers but my experience in seeing these databases is a lack of security.
- There is an underlying feeling that security of the Oracle database cannot be changed and should not be changed as its not the customers right/job/responsibility to change it
Bear in mind I am not an ERP expert; my focus is Oracle database security so my thoughts are based on what I have seen and been told at sites rather than being an expert in any ERP
If we don't consider the database there is a problem as often these security settings, roles, menus, responsibilities, separations due to organisations and more are stored in the database.
There is of course a gap. If the security of an ERP is enabled at the ERP level that security and its settings at the ERP level is inevitably stored in the Oracle database layer. If an attacker or rogue employee can access the security and change it outside of ERP controls and can of course also access data. A good example is JDE where there are more than 4000 tables in various schemas and all except two are granted INSERT, SELECT, DELETE and UPDATE to PUBLIC. Often database passwords also share a pattern. In EBS for instance Oracle provides tools to change all the database passwords in one fell swoop using pattern passwords where a password may be long but the variable part is small. If the pattern is known then guessing the variable part and cracking all passwords is much easier. These are just a small amount of examples
We have talked about database security here BUT the same logic and ideas also apply to the operating system for the same reasons.
ERP systems tend to have audit trail mechanisms built into the ERP layers; for instance in JDE or EBS there are last updated by, last updated when type columns on tables and also triggers can be used to generate before and after audit trails. If we want to know what goes on in the database directly and avoiding ERP security then we must use database level audit techniques. We can then audit access to security both of the database and the ERP and also audit access to the ERP settings and configuration.
The message here is that we must not ignore the security of the Oracle database in an ERP system as its often too easy for a direct database user to change security or access data outside of rules enforced in the ERP.
#oracleace #23c #19c #21c #erp #oracle #database #security #jde #jdedwards #ebusinesssuite
