Protecting Sensitive Data

in the Oracle E‐Business Suite
Stephen Kost
Chief Technology Officer
Integrigy Corporation
Session #8680
 Background
Speaker Company
Stephen Kost Integrigy Corporation
ƒ CTO and Founder ƒ Integrigy bridges the gap between 
databases and security
ƒ 16 years working with Oracle
ƒ Security Design and Assessment of 
ƒ 12 years focused on Oracle  Oracle Databases
security
ƒ Security Design and Assessment of 
ƒ DBA, Apps DBA, technical  the Oracle E‐Business suite
architect, IT security, …
ƒ AppSentry ‐ Security Assessment 
Software Tool
 Agenda

Sensitive Data Controlling
Overview Data Access Q&A

1 2 3 4 5
Encryption Auditing
 Agenda

Sensitive Data Controlling
Overview Data Access Q&A

1 2 3 4 5
Encryption Auditing
 Security and Compliance Drivers
ƒ Payment Card Industry ‐ Data Security Standard (PCI‐DSS)
– 12 stringent security requirements
ƒ Privacy (National/State Regulations)
– Read access to sensitive data (National Identifier and Bank 
Account Number)
– Regulations  often specifically exclude encrypted data
– California and Massachusetts data privacy laws
ƒ Sarbanes‐Oxley (SOX)
– Database object, structure, and configuration changes
– User and privilege creation, deletion, and modification
– Reports for sampling of changes to change tickets
 What is Sensitive Data in Oracle EBS?
ƒ Credit Card Number
Payment Card Industry  ƒ Primary Account Number (PAN)
ƒ CVV/CV2/CID
Data Security Standard  ƒ 3 digits on the back for Visa/MC
(PCI‐DSS 2.0) ƒ 4 digits on the front for AMEX
ƒ Magnetic Stripe Data (very rare)
ƒ First and last name
State Privacy ƒ Plus one of the following:
ƒ Social security number
Regulations ƒ Credit card number
(employees, customers, ƒ Bank account number
Vendors) ƒ Financial account number
ƒ Driver license or state ID number
ƒ First and last name
ƒ Plus one of the following (Protected Health Information)
HIPAA ƒ “the past, present, or future physical or mental 
health, or condition of an individual”
Privacy Standard/Rule ƒ “provision of health care to an individual”
ƒ “payment for the provision of health care to an 
individual”
 Where is Sensitive Data in Oracle EBS?
iby_security_segments (encrypted)
ap_bank_accounts_all
oe_order_headers_all
aso_payments
Credit Card Data oks_k_headers_*
oks_k_lines_*
iby_trxn_summaries_all
iby_credit_card
per_all_people_f
Social Security Number hr_h2pi_employees
ben_reporting
(National Identifier) ap_suppliers
(Tax ID) ap_suppliers_int
po_vendors_obs
ap_checks_all
Bank Account Number ap_invoice_payments_all
ap_selected_invoice_checks_all

Protected  Order Management
Accounts Receivables
Health Information (PHI) Human Resources
 Where else might  be Sensitive Data?
ƒ Custom tables
– Customizations may be used to store or process sensitive data
ƒ “Maintenance tables”
– DBA copies tables to make backup prior to direct SQL update
– hr.per_all_people_f_011510
ƒ Interface tables
– Credit card numbers are often accepted in external applications and 
sent to Oracle EBS
ƒ Interface files
– Flat files used for interfaces or batch processing
ƒ Log files
– Log files generated by the application (e.g., iPayment)
ƒ Oracle EBS Flexfields
– It happens – very hard to find
 Integrigy Data Protection by Option
Options
Data Access Method and Threats 1 2 3 4a 4b 4c 3 + 4
EBS Trigger Oracle  FGAC Internal  External  TDE + 
Encrypt View TDE Audit Audit Auditing

Application access by end‐users (responsibility) E E C A A A
Application access by application administrators E E C A A A
Database access by DBA E E C A~ A A
Database access by Applications DBA (SYSTEM, APPS) E~ E~ A~ A~ A~
Database access by other database accounts E E C A A A
Operating system access to database data files E E E E
On‐line or off‐line access to database backups E E E E
Exploitation of Oracle Applications security vulnerabilities E~ E~ C~ A~ A~ A~
Exploitation of Oracle Database security vulnerabilities E~ E~ C~ A~ A~ A~
Exploitation of operating system security vulnerabilities E E E E

E = Encrypted,  C = Access Controlled,   A = Access Audited,    ~ = Mostly

 Agenda

Sensitive Data Controlling
Overview Data Access Q&A

1 2 3 4 5
Encryption Auditing
 Types of Encryption
ƒ Storage (Data at rest)
– Encryption of data at rest such as when stored in files or on 
media

ƒ Access (Data in use)
– Encryption of data with access permitted only to a subset of 
users in order to enforce segregation of duties 

ƒ Network (Data in motion)
– Encryption of data when transferred between two systems
– Not in scope of this analysis
Native EBS Encryption
(Credit Card Numbers)
 Oracle EBS Encryption Solutions
ƒ Patch 2809786 – “Encryption of Credit Card Numbers in Oracle EBS”
– General Patch Release October 2006
– Significant modification to application – 64 packages, 60 web pages, and 
18 forms
ƒ Oracle Transparent Data Encryption (TDE)
– Encrypts data at the file level ‐‐ always unencrypted for a database 
session
– Only provides protection in case database file is stolen or backup tape is 
lost
– Part of extra‐cost Advanced Security Option (ASO)
ƒ Custom Encryption Customization
– Use native Oracle database encryption packages (DBMS_CRYPTO)
– Use Oracle E‐Business Suite encryption packages (FND_VAULT)
ƒ Third‐party encryption solutions
– File/disk level encryption
– View/trigger encryption
 Oracle Credit Card Encryption (no TDE)

ƒ Use the Oracle E‐Business Suite encryption
– Application‐level encryption
– Better solution than other technologies such as Oracle 
Transparent Data Encryption (TDE)
ƒ Metalink Note ID 338756.1, Patch 4607647
– Consolidates card numbers into 
IBY_SECURITY_SEGMENTS table
– Encrypts card numbers in IBY_SECURITY_SEGMENTS
– Uniform masking of card numbers
– Significant functional pre‐requisites (11.5.10.2)
 Oracle Credit Card Encryption Design
iby_security_segments
ap_bank_accounts_all
Collections

oks_k_headers_*
aso_payments oe_order_headers_all
oks_k_lines_*

Service Oracle Oracle

AR
Contracts Capture Mgmt

iStore

iPayment
iby_trxn_summaries_all
iby_credit_card
Not pictured:
ƒ Internet Expenses (AP) – R12
ƒ Lease Management (AP) – same as AR
ƒ Student System (IGS) – IGS patch
Transparent Data Encryption (TDE)
 What is TDE?
ƒ Transparent database encryption
– Requires no application code or database structure 
changes to implement
– Only major change to database function is the Oracle 
Wallet must be opened during database startup
– Add‐on feature licensed with Advanced Security Option
ƒ Limited to encrypting only certain columns
– Cannot be a foreign key or used in another database 
constraint
– Only simple data types like number, varchar, date, …
– Less than 3,932 bytes in length
 What does TDE do and not do?
ƒ TDE only encrypts “data at rest”
ƒ TDE protects data if following is stolen or lost ‐
– disk drive
– database file
– backup tape of the database files
ƒ An authenticated database user sees no change
ƒ Does TDE meet legal requirements for 
encryption?
– California SB1386, Payment Card Industry Data 
Security
– Ask your legal department
Column vs. Tablespace Encryption
Column encryption
– Fairly straight forward for simple cases such as 
NATIONAL_IDENTIFIER in HR.PER_ALL_PEOPLE_F
– Encryption done in place using ALTER TABLE
– Do not use SALT for Oracle EBS columns
Tablespace encryption
– Tablespace encryption only supported in 11g for 11i/R12
– Tablespace must be exported and imported to implement 
encryption
– OATM uses large tablespaces (APPS_TS_TX_DATA)
– Data NOT encrypted in SGA
 Performance Considerations
ƒ Impact is limited to CPU performance
– Data must be encrypted and decrypted
– Highly dependent on access patterns to data
ƒ No disk I/O read or write impact
– Change is not significant
ƒ Column Encryption
– 5% to 20% CPU performance impact for several 
customers
ƒ Tablespace Encryption
– 10% to 15% CPU performance impact for one 
customer
 Performance Considerations
1. Range scan (between/like) on indexed column
– where a.birth_date between start_date and end_date
– Index will not be used – full table scan
2. Join on encrypted columns
– where a.ssn = b.ssn
– Encryption key is unique for each table
– Full table scan of both tables
– All values in both tables decrypted
 Implementation Process
ƒ Identify sensitive columns
– Manual search design document review
– Data dictionary searches (i.e., column name = 
CCNUM)
– Third‐party tools to sample rows
ƒ Determine if column level encryption or 
tablespace encryption based on version, 
limitations
ƒ Follow steps in Metalink Notes
– 11i = 403294.1 or R12 = 732764.1
 TDE and EBS Best Practices
ƒ Ensure wallet is not backed up with the db files
ƒ Protect the wallet
– Backup the wallet
– File permissions
ƒ When encrypting large volumes of data, should create 
a new tablespace and shred the old one
– Unencrypted data may remain in tablespace blocks
ƒ Mix and match column and tablespace encryption
– Column for standard tables and tablespace for custom
ƒ Avoid using PKI Certificates for master key
 Oracle EBS and TDE Specifics
EBS has a SQL script to validate column and 
generate necessary ALTER TABLE statement
– $FND_TOP/sql/aftdeval.sql
– 11i = 5693160, R12 = 7337863

Output

ALTER TABLE HR.PER_ALL_PEOPLE_F modify

(NATIONAL_IDENTIFIER encrypt no salt);
 Agenda

Sensitive Data Controlling
Overview Data Access Q&A

1 2 3 4 5
Encryption Auditing
 Access to Sensitive Data
ƒ Database access is a key problem
– APPS_READ 
ƒ All data duplicated in development and test databases
– Data not always scrambled in non‐production database
ƒ Limited data encryption capabilities
– No third‐party encryption solutions work effectively
– Oracle EBS only natively encrypts credit card numbers
– Need to encrypt sensitive data on backup media
ƒ Data and transaction retention policy 
– Oracle EBS is “data in” for life
– Seldom data is purged or archived unless for performance
– PCI Compliance = 1 to 2 years recommended retention
 Sensitive Data Access Risks
ƒ Sensitive data accessible in test & development
– All sensitive data must be scrambled in all non 
production databases
– Must periodically review database for instances of 
non‐scrambled data as often in custom, interface, and 
temporary tables
ƒ Access to sensitive data by generic accounts
– Granularity of database privileges, complexity of data 
model, and number of tables/views make it difficult to 
create limited privilege database accounts
– Must use individual database accounts with roles 
limiting access to data along with other security
Privileges and Access in Oracle EBS
ƒ Many generic and privileged accounts in application and database
– Database ‐ APPS, SYS, SYSTEM, APPLSYS, …
– Application – SYSADMIN, GUEST
– DBAs must use generic accounts for many maintenance activities
– Generic application accounts used for scheduling key batch processes
– Database access is a key problem (Again)
ƒ Generic accounts are often used for ad‐hoc database access
– APPS_READ
ƒ Limited auditing and control over the use of generic accounts
– No auditing is enabled by default in database or application
– Auditing on transactions often a major performance impact
Database Vault
with Oracle E‐Business Suite
 What is Database Vault?
ƒ Powerful protection
– Data protection realms
– Control by IP address, time, etc.
– Control SQL commands and other database 
operations
ƒ Provides segregation of duties between DBA 
and security administrator
ƒ Add‐on option licensed separately
Database Vault and EBS Scenarios
ƒ Protect some DBAs from application data
– No protection for the SYSTEM, APPS, CTXSYS, or 
Oracle EBS module schema accounts
– Named, non‐application database accounts must be 
used for this level of protection – can be granted DBA 
role
ƒ Server/Database Consolidation
– Multiple applications running in Oracle E‐Business 
Suite database (against best practice)
– DBAs for other applications cannot access EBS data
 Default Oracle EBS Realms
Realm Name What is Protected? Who is authorized to access?
All Oracle E‐Business Suite 11i 
All tables in Oracle E‐Business Suite 11i 
EBS Realm Product Schemas, and APPS, APPLSYS, 
Product Schemas
SYSTEM, CTXSYS
EBS Realm ‐ Applsys
Most tables in the APPLSYS Schema APPS, APPLSYS, SYSTEM and CTXSYS
Schema
APPS, APPLSYS, SYSTEM, CTXSYS and 
All objects in the APPS Schema (except the 
EBS Realm ‐ Apps Schema All product schemas, that uses 
views)
intermedia indexes
EBS Realm ‐ Applsyspub APPS, APPLSYS, SYSTEM, APPLSYSPUB 
Objects required for EBS authorization
Schema and CTXSYS

Tables in the MSC Schema ‐ except those that  APPS, APPLSYS, SYSTEM, CTXSYS and 

EBS Realm ‐ MSC Schema
require partitions to be exchanged MSC

All Oracle E‐Business Suite 11i 
CTXSYS Data Dictionary Objects in the CTXSYS Schema Product Schemas and APPS, APPLSYS, 
SYSTEM
Source: Oracle Metalink Note ID 428503.1
 Database Vault Implementation
1. Install Database Vault option and database 
patches
– May need to upgrade database
– Need to check database initialization parameters
2. Create EBS realms
– A number of manual steps required
– Follow manual setups for enabling patching
3. Struggle to integrate custom users
– Need to identify and review all custom user and 
programs accessing the database
Oracle E‐Business Suite Requirements
ƒ Oracle E‐Business Suite 
– 11.5.10 CU2
– 12.0
– 12.1
ƒ Oracle Database 
– 10.2.0.3 (Linux x86, IBM AIX only)
– 10.2.0.4
– 1.1.0.7
ƒ 11.5.10 CU2 on 10.2.0.4 required 12 additional 
patches
 DV and EBS Best Practices
ƒ Ensure all pre‐requisite DB patches are applied
– 20+ Database and DV bugs need to be fixed
ƒ For custom code there are two options –
1. Use custom realms and only provide access to 
required objects
2. Register as an application and database schema 
in EBS and will use the EBS realms
 Database Vault Useful Scripts
ƒ fnddbvebs.sql
– Creates the standard Oracle E‐Business suite 11i realms – use as template for custom realm creation
ƒ fnddbvuser.sql
– Adds or removes realm authorization in Oracle E‐Business Suite 11i realms
ƒ fnddbvstatus.sql
– Use to enable or disable realms during testing
ƒ fnddbvpatch.sql
– Enables or disables Oracle Database Vault triggers – used to be used during patching – no longer needed
ƒ fnddbvpatch2.sql
– Update command rule for grant on DBMS_RLS. Must be run as the DV Owner.
ƒ fnddbvpatch3.sql
– Grants or revokes DV_ACCTMGR role from SYSTEM. Must be run by a user with the DV_ACCTMGR role.
ƒ check_enabled_using_dv_control.sql
– Check to see if the command rule modified by fnddbvpatch2.sql is in production mode
ƒ check_enabled_using_sysdba.sql
– Check to see if the database is in Production mode with Database Vault enabled. Reports any discrepancies found.
 EBS and DV Metalink Notes
ƒ 11i and 10.2.0.3  = 744172.1
ƒ 11i and 10.2.0.4  = 428503.1
ƒ 11i and 11.1.0.7  = 859399.1
ƒ R12 and 10.2.0.4 = 566841.1
ƒ R12 and 11.1.0.7 = 859397.1
 Agenda

Sensitive Data Controlling
Overview Data Access Q&A

1 2 3 4 5
Encryption Auditing
 Auditing Access to Sensitive Data
ƒ Encryption may not be possible
– TDE is not sufficient or too costly
ƒ Sensitive Data access is required
– DBAs must use the APPS
ƒ Auditing should be used to mitigate risk
– Accurate and reliable audit trail of access
 Auditing Access to Sensitive Data
ƒ Native audit trail in Oracle Database and 
Oracle EBS can be accessed and manipulated 
by the DBA
– SYSLOG auditing can be used to protect native 
database audit trail – DBA can disable it
ƒ External auditing solution required
– Protect audit trail in external database/appliance
– Provide reporting and archiving of audit data
 Integrigy Data Protection by Option
Options
Data Access Method and Threats 1 2 3 4a 4b 4c 3 + 4
Appl Trigger Oracle  FGAC Internal  External  TDE + 
Encrypt View TDE Audit Audit Auditing

Application access by end‐users (responsibility) E E C A A A
Application access by application administrators E E C A A A
Database access by DBA E E C A~ A A
Database access by Applications DBA (SYSTEM, APPS) E~ E~ A~ A~ A~
Database access by other database accounts E E C A A A
Operating system access to database data files E E E E
On‐line or off‐line access to database backups E E E E
Exploitation of Oracle Applications security vulnerabilities E~ E~ C~ A~ A~ A~
Exploitation of Oracle Database security vulnerabilities E~ E~ C~ A~ A~ A~
Exploitation of operating system security vulnerabilities E E E E

E = Encrypted,  C = Access Controlled,   A = Access Audited,    ~ = Mostly

 Agenda

Sensitive Data Controlling
Overview Data Access Q&A

1 2 3 4 5
Encryption Auditing
 Integrigy Sessions
Securing the Oracle E‐Business Suite  Credit Cards and Oracle: How to 
Best Practices Panel Comply with PCI‐DSS
OAUG Session #4967 IOUG Session #1718
Monday, April 11 Tuesday, April 12
3:45pm – 4:45pm 11:45am – 12:12pm

IOUG Security Bootcamp: Real‐life  Real‐life Oracle E‐Business Suite 

Database Security Mistakes Security Mistakes
IOUG Session #1573 OAUG Session #8387
Tuesday, April 12 Wednesday, April 13
9:15am – 10:15am 2:15pm – 3:15pm
 Protecting Sensitive Data in the Oracle EBS Session #8680

Stephen Kost
e‐mail: info@integrigy.com
Chief Technology Officer
blog: integrigy.com/oracle‐security‐blog
Integrigy Corporation

For information on ‐
ƒ Oracle Database Security
ƒ Oracle E‐Business Suite Security www.integrigy.com
ƒ Oracle Critical Patch Updates
ƒ Oracle Security Blog

Copyright © 2011 Integrigy Corporation.  All rights reserved.