Protecting Your Sensitive Data in The Oracle E Business Suite
Protecting Your Sensitive Data in The Oracle E Business Suite
Your Sensitive Data
in the Oracle E‐Business Suite
Mike Miller Stephen Kost
Vice President, Service Delivery Chief Technology Officer
Data Intensity Integrigy Corporation
March 16, 2011
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
Overview Data Access Q&A
1 2 3 4 5
Encryption Auditing
Agenda
Sensitive Data
Overview Data Access Q&A
1 2 3 4 5
Encryption Auditing
Security and Compliance Drivers
Sarbanes‐Oxley (SOX)
− Database object, structure, and configuration changes
− User and privilege creation, deletion, and modification
− Reports for sampling of changes to change tickets
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)
− California and Massachusetts data privacy laws
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
Plus one of the following:
State Privacy Social security number
Credit card number
Regulations Bank account number
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
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
Oracle EBS Flexfields
− It happens – very hard to find
“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)
Agenda
Sensitive Data
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
Oracle Encryption Solutions
Patch 2809786 – “Encryption of Credit Card Numbers in Oracle EBS”
− Bug/Enhancement Request opened February 2003
− Controlled Patch Release November 2005
− 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_*
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
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
Sensitive Data
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)
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
Scrambling Data in Test and Development
Identify data locations
− Need to do on a periodic basis to identify new locations
Determine data dependencies and requirements
− Must last name be same in all scrambled tables? Usually not in EBS
− Data scrambling rules (we like to set SSN to 7xx‐xx‐xxxx)
Perform scrambling when cloning
− Requires downtime based on data volume
SQL Script vs. Third Party Product
− SQL Script
− Oracle AMP Data Scrambling
− Oracle OEM Data Masking
− Third party products
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
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
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 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
Agenda
Sensitive Data
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
Agenda
Sensitive Data
Overview Data Access Q&A
1 2 3 4 5
Encryption Auditing
Oracle Application User Group (OAUG)
Visit us at Collaborate 2011!
Enter to win Apple Giveaways
MacBook Air, iPad, iTouch, Shuffle
37
Integrigy Contact Information
Stephen Kost e‐mail: [email protected]
Chief Technology Officer blog: integrigy.com/oracle‐security‐blog
Integrigy Corporation website: www.integrigy.com
For information on ‐
Oracle Database Security Oracle Critical Patch Updates
Oracle E‐Business Suite Security Security and Compliance (PCI, SOX, HIPAA)
COLLABORATE 11 – OAUG and IOUG
Protecting Sensitive Data in the Oracle E‐Business Suite
Securing the Oracle E‐Business Suite Best Practices Panel
Security Bootcamp: Real‐life Database Security Mistakes
Credit Cards and Oracle: How to Comply with PCI‐DSS
Real‐life E‐Business Suite Security Mistakes
Copyright © 2011 Integrigy Corporation. All rights reserved.