My experience of auditing Oracle databases that are supporting ERPs such as JD Edwards, EBS, Peoplesoft, SAP and more is that often there is a tendency to not consider the database as part of the overall security of these systems. Often the security is driven from the ERP level and via settings and configuration at that level and little thought is given to the security of data at the database level. The company and others view the Oracle database as a sealed unit that cannot be changed, looked at or tampered with; i.e. security. At a high level an ERP can be looked at in a security way for Conflicts of interest. Separation of Duties, Fraud, limits, menus, access controls, business level controls, compliance and more. All of this is measured and controlled at the ERP level BUT the controls and settings are mostly stored in an Oracle database and usually that database does not have deep levels of security (sealed unit problem). Most users and security and admin access the ERP at the ERP level.
The security issue is obvious; no audit trails in the database to see what is happening directly in the database. Data thieves don't care about following the ERP route to the data they are happy to go direct to the file system or the database and there are often no controls at the database level either so access is easy. I discuss the threats to the data by direct access outside of the ERP. I show how data can be stolen and where the ERP owner should focus to make sure that the data in the Oracle database that hosts the ERP can be secured.
I show a simple example for instance in a JDE database where almost all tables have INSERT, UPDATE, DELETE and SELECT granted to PUBLIC; so any one who gets direct access to the Oracle database can change or read any data including security data.
If you run an ERP on Oracle you must consider locking and securing the Oracle database.
#oracleace #dbsec #erp #oracle #database #security #gdpr