Data Security in ERP

This is my presentation to the UKOUG last December on Data Security in ERP

Slide 1 - Data Security in ERP

and Other Large Business Systems

Slide 2 - Legal notice

Data Security in ERP and Other Large Business Systems

Published by
PeteFinnigan.com Limited
Tower Court
3 Oakdale Road
York
England, YO30 4XL

Copyright © 2025 by PeteFinnigan.com Limited

No part of this publication may be stored in a retrieval system, reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, scanning, recording, or otherwise except as permitted by local statutory law, without the prior written permission of the publisher. In particular this material may not be used to provide training of any type or method. This material may not be translated into any other language or used in any translated form to provide training. Requests for permission should be addressed to the above registered address of PeteFinnigan.com Limited in writing.

Limit of Liability / Disclaimer of warranty. This information contained in this course and this material is distributed on an “as-is” basis without warranty. Whilst every precaution has been taken in the preparation of this material, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions or guidance contained within this course.

TradeMarks. Many of the designations used by manufacturers and resellers to distinguish their products are claimed as trademarks. Linux is a trademark of Linus Torvalds, Oracle is a trademark of Oracle Corporation. All other trademarks are the property of their respective owners. All other product names or services identified throughout the course material are used in an editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this course.

Slide 3 - Background

Pete Finnigan – Background, Who Am I?

• Oracle Security specialist and researcher
• CEO and founder of PeteFinnigan.com Limited in February 2003
• Writer of the longest running Oracle security blog
• Author of the Oracle Security step-by-step guide and “Oracle Expert Practices”, “Oracle Incident Response and Forensics” books
• Oracle ACE for security
• Member of the OakTable, SYM 42
• Speaker at various conferences UKOUG, PSOUG, BlackHat, more..
• Published many times, see http://www.petefinnigan.com for links

Slide 4 - Agenda

• Introduction
• Traditional ERP security
• The GAP in ERP security
• Some examples
• How to secure data in an ERP environment

Slide 5 - Introduction

Introduction

Slide 6 - Where Are We Going Today?

• My focus is database security
• I regularly audit databases that support ERP (and other big business applications)
• Usually I see a complete lack of any semblance of security at the data layer when its supporting ERP
• This discussion is not specific to one ERP/Big application
• I want to broaden the discussion beyond ERP security and focus on the data layer

Slide 7 - Traditional ERP Security

Traditional ERP Security

Slide 8 - ERP Security

• At a high level ERP security if often discussed / complied with at …:
• Separation of duties (SOD)
• Conflict of interest (COI)
• ERP level security settings – forms / menus / blocks / field level
• Fraud / Limits / Business Level
• Compliance with higher level rules / stds

Slide 9 - ERP Layers

• ERPs are not just an ERP
• There are many layers underneath of
• Application screens
• Application and web servers
• Reporting servers
• Databases
• Operating systems
• People normally access ERPs at the ERP level not lower level
• Some users often are allowed lower level access
• Customisations / Excel / Reports / SQL*Developer / TOAD…

Slide 10 - Where is ERP Security?

• The settings, configuration and other mechanisms can be in many places in an ERP
• Settings for the high level application security can be in the database for ephemeral settings and tech settings or in binaries, configuration files
• Often ERP have technical settings for the ERP in the database, servers, and configurations
• The supporting servers can be secured
• The supporting databases can be secured
• Complex layers where the DB plays two roles
• Stores business data and config of the application

Slide 11 - Black Box

• The database if often treated as a black box
• This is wrong
• Data thieves do not take this approach
• Attackers don’t care
• About ERP settings or database settings
• Or OS settings or database settings
• If an attacker can access the database or OS directly they will and they will steal data

Slide 12 - ERP Data Level Security Is Often Missing

• Often there are no database level protections on data
• Some may use TDE – but without DV or similar to prevent SQL access this protects only the files
• Some may use VPD or Database Vault
• Some use masking, redaction, etc
• BUT by default, often data is not protected at the table level

Slide 13 - The Data Attacker

• The Attacker is not a kid in his bedroom but most likely someone who works for you directly or via a 3rd party
• Hacking is not always hacking but excessive rights and misuse and authority failures
• I want to explore this loophole between data and ERP further

Slide 14 - The GAP

The GAP

Slide 15 - ERP Security – The Problem Space

• ERP systems such as JDE, EBS, Siebel, SAP and more are often focused at a business function level
• Security is at the ERP level and
• Driven on fraud, money, SOD and COI
• Often sites ignore the server and database and network levels – specifically in terms of the audit conducted
• The bridge between ERP and database and server is not considered seriously enough
• That does not mean companies do not do network security or database security or OS security but
• The ERP is treated as a “black Box” and audits focus in ERP land

Slide 16 - Security Audits of ERP

• Focused on technical settings in the ERP such as limits
• Focused on the business functionality
• Focused on the security settings in the ERP
• Focused on ERP users / responsibilities
• Focused on separation of duties and potential conflicts of interest

Slide 17 - Regulations and Reasons to Secure Better

• Reasons to take data security seriously
• GDPR – Since May 2018
• Protects citizens rights over personal data
• Sarbanes Oxley – US parents?
• Stops financial balance sheet reporting fraud
• PCI – process or store cards
• Many more…

Slide 18 - ERPs Often Implement Security in Oracle

• ERPs have many levels of security including
• Parameters
• Profiles
• ERP users and passwords
• ERP responsibilities, roles..
• ERP screens, menus, forms
• SOD and COI issues are based on complex build up of permissions on multi-elements and screens
• ERPs in general control access to data through all of these components
• This is usually not at the data level

Slide 19 - BUT…

• Most of ERPs are implemented in the database itself as:
• Tables,
• Views,
• Metadata
• Code such as PL/SQL
• These are not controlled by ERP security controls inside of the ERP itself
• Recursive security is missing

Slide 20 - BUT … (2)

• The database is software running on a server or multiple servers (Unix often but can be Windows)
• The data and metadata are stored in datafiles on disk (SAN, ASM, Network Storage, Local disks)
• Users are expected to access the ERP front end but often some users are allowed:
• Reporting interfaces
• Development tools such as TOAD, SQL*Developer etc

Slide 21 - Threats to an ERP Outside of the ERP

• System admins can access anything
• Root  oracle  database as sysdba  all data (steal PII, finance)  security controls
• Oracle  database as sysdba  all data (steal PII, finance)  security controls
• DBA – database as DBA  all data (steal PII, finance)  security controls
• Business User database as user  all data (steal PII, finance)  security controls

Slide 22 - Actual Threats

• The security of the ERP can be changed by editing metadata in ERP tables
• ERP users can have passwords reset by database UPDATE
• ERP responsibilities can be changed by INSERT, UPDATE
• ERP rule trees can be edited to allow a COI
• ERP processes (check printing?) can be run outside of the ERP

Slide 23 - Data Theft

• Data theft can occur completely outside of ERP controls
• A DBA, admin, reporting user allowed direct access can access data outside of ERP controls
• Data can be stolen from
• Database, SGA, redo logs, archive logs, report files, data files, test systems, network sniffing, many many more

Slide 24 - Some Examples

Some Examples

Slide 25 - Example: JDE Data Level Security Controls

Literally everything except passwords are granted I,U,D,S to PUBLIC (99.9%)

Slide 26 - Example: JDE Database Level Audit Trail

• A sample JDE installation has no database level audit trails
• SYSDBA audit is enabled but this does not track data level actions by other users

Slide 27 - Example: JDE Critical Security Could be Changed

A very small percentage of critical tables are not granted to PUBLIC in JDE but DBA can change!

Slide 28 - Secure Data in an ERP

Secure Data in an ERP

Slide 29 - We Must Secure the Database and Server

• To properly secure an ERP we must also:
• Secure the operating system
• Secure the core database against general threats
• Secure the core database against ERP level threats
• Secure the network between the ERP and the database (often not segregated or encrypted)

Slide 30 - Database Security High Level

Database Security High Level

Slide 31 - Threats – Platform and Data

• There are two key threats
• Data Theft: The attackers goal is to steal your data, PII, Cards, Health, Business confidential or more
• Platform Access: The attacker is not interested in your data or simply does not see the value in it. Instead he sees your Oracle database as an easy target to attack and from there to access what he really wants – other services, websites or more
• Therefore we must protect data as a key task but we must not neglect the Oracle platform as a potential target and lock it down as well

Slide 32 - Securing A Database is Complex

• The focus for years is on hardening and patching – CPU and CIS for instance
• This is fine BUT it does not secure your data at all
• Data security is harder to do as its specific
• User level security – permissions, profiles
• Access controls – grants, roles, objects
• Context based security
• We must consider ERP data in the database

Slide 33 - Implement Comprehensive Audit Trails

• In general ERP systems usually have some level of audit trails at the ERP level
• The database engine does not audit itself generally
• We must implement audit trails in the database using standard audit, Unified audit, FGA or triggers
• We must also audit the data itself in the database
• We must audit ERP security (metadata and controls)
• You must be able to find out if someone abuses the ERP from the database

Slide 34 - Layers of Database Security

• Patch
• Harden
• User rights / control = Least Rights
• Data access controls = Least Right
• Access controls to the database
• Context based security
• Secure Coding

Slide 35 - Context Based Security

• ERP controls do not control access to data tables
• Database table level controls are too granular
• Context based controls needed
• Can use Oracle products – DV, VPD, OLS, TSDP, …
• Can also use encryption as a context control
• Home grown controls can be created using triggers, views, procedures and contexts

Slide 36 - Conclusions

• ERP security is generally in the ERP
• The assumption is that the ERP is controlled at the ERP level
• We must understand that an attacker (or employee) can access data or security directly in the database or operating system
• We must secure the core database
• We must secure the ERP in the database
• We must implement audit trails in the database

Slide 37 - Questions

Questions

Slide 38 - Data Security in ERP

and Other Large Business Systems