Back to the Oracle Database Security home page

Oracle Database Security and the
Payment Card Industry Data Security Standard

Oracle Database security provides powerful data protection and access control solutions to address PCI-DSS 1.2 requirements:

  • Oracle Database Vault prevents highly privileged users from accessing credit card information and helps reduce the risk of insider threats with separation of duty, multi-factor authorization and command rules.
  • Oracle Advanced Security Transparent Data Encryption (TDE) provides the industry's most advanced database encryption solution, enabling encryption of credit card number columns in application tables with TDE column encryption, or encrypting complete application tablespaces, using TDE tablespace encryption, with complete transparency to the existing application.
  • Oracle Audit Vault consolidates and protects database audit data from across the enterprise. Oracle Audit Vault reports and alerts provide pro-active notification of access to credit card information.
  • Oracle Enterprise Manager provides secure configuration scanning to insure your databases stay configured securely.
  • Oracle Label Security extends user security authorizations to help enforce the need-to-know principle.

Chapter PCI 1.2 requirement Matching Oracle Feature
 
Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect data
 
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known in hacker communities and easily determined via public information.
2.1: Always change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts. Oracle locks and expires default accounts and passwords during installation. Passwords for administration accounts are prompted for during installation.
2.2: Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Oracle Enterprise Manager Configuration Pack ships the Center for Internet Security (CIS) benchmark out-of-the-box, enabling customers who have the configuration pack to scan their enterprise databases for compliance.
  2.2.3: Configure system security parameters to prevent misuse. Follow Oracle Database secure configuration guideline. Monitor with the Oracle Enterprise Manager Configuration Pack.

Oracle Audit Vault consolidates audit data from across Oracle databases.

Oracle Audit Vault can report and alert on audit data.

Oracle Database Vault Separation of Duty prevents unauthorized administrative actions in the Oracle Database.
2.2.4: Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. Oracle Database custom installation allows specific components to be installed or removed.
2.3: Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access. Oracle Advanced Security provides network encryption (SSL/TLS and native) to encrypt all traffic over SQL*Net between the middle tier and the database, between clients and the database and between databases. Additionally, some administrative tools such as Enterprise Manager provide a restricted use SSL license to protect administrative traffic.
2.4: Shared hosting providers must protect each entity's hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: "Additional PCI DSS Requirements for Shared Hosting Providers." See Appendix A:
 
Protect Cardholder Data
3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.

Please refer to the PCI DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of "strong cryptography" and other PCI DSS terms.
3.3: Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).
Notes:
  • This requirement does not apply to employees and other parties with a specific need to see the full PAN; nor does the requirement supersede stricter requirements in place for displays of cardholder data (for example, for point of sale [POS] receipts)
  • This requirement does not supersede stricter requirements in place for displays of cardholder data — for example, for point-of-sale (POS) receipts.
.
Application specific; Applications can leverage Virtual Private Database (VPD) with a column relevant policy to mask out the entire number. If the application stores the number in different fields VPD can be used to mask out the relevant parts of the number by field.

Security attributes provided by Oracle Label Security label factors can help determine who should have access to the number.

Oracle Database Vault Realms can be used to prevent highly privileged users from accessing any application data.
3.4: Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
  • One-way hashes based on strong cryptography
  • Truncation
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key-management processes and procedures
The MINIMUM account information that must be rendered unreadable is the PAN.

Notes:
  • If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: "Compensating Controls"
  • "Strong cryptography" is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms.
Oracle Advanced Security TDE column encryption and TDE tablespace encryption can be used to transparently encrypt the Primary Account Number on storage media.
Oracle RMAN can encrypt the entire backup when backed up to disk.
Oracle Data Pump can encrypt entire Database export files, either with the master encryption key from the source database, or a passphrase that can be securely shared with the receiving party.

Oracle Secure Backup provides a solution for backing up and encrypting directly to tape storage.

Encryption algorithms supported include 3DES and AES with 128, 192, or 256 bit key length.

Oracle Advanced Security Transparent Data Encryption (TDE) has key management built-in. Encrypted data stays encrypted in the data files, undo logs, and redo logs. SHA-1 and MD5 are used for integrity.
3.5: Protect encryption keys used for encryption of cardholder data against both disclosure and misuse: Oracle Advanced Security Transparent Data Encryption (TDE) table and tablespace keys are stored in the database and encrypted using a separate master key that is stored in the Oracle Wallet, a PKCS#12 file on the operating system, or a hardward security module (HSM).

The Oracle Wallet is encrypted using the wallet password; in order to open the wallet from within the database requires the 'alter system' privilege.

Oracle Database Vault command rules can be implemented to further restrict who, when, and where the 'alter system' command can be executed.
  3.5.1: Restrict access to cryptographic keys to the fewest number of custodians necessary. In Oracle, nobody needs access to the master encryption key. Designated individuals like a DBA or Database Security Administrator (DSA) need to know the wallet password or the HSM authentication string, plus the 'alter system' privilege, to open wallet or HSM and make the master encryption key available to the database.

Oracle Database Vault command rules can be implemented to restrict who, when, and where the 'alter system' command can be executed.
3.5.2: Store cryptographic keys securely in the fewest possible locations and forms. There is only one master encryption key per database. The key can be stored in the Oracle Wallet or an HSM device for centralized master key generation and management.
3.6: 3.6.1: Generation of strong cryptographic keys Oracle Advanced Security Transparent Data Encryption (TDE) uses a FIPS certified pseudo RNG (random number generator); master key can also be generated using certificates or PKI key pairs. If a hardware security module (HSM) is used, it takes care of all key management aspects, incl. generation, storage, re-keying, and destruction.
3.6.2: Secure cryptographic key distribution (Customer internal policy).

In distributed environments (incl. Real Application Clusters), the wallet containing the master encryption keys needs to be copied to all participating RAC instances and opened.
3.6.3: Secure cryptographic key storage Oracle Advanced Security Transparent Data Encryption (TDE) table and tablespace keys are stored in the database, encrypted with the master key, which is stored in the Oracle Wallet, or an HSM device.
3.6.4: Periodic cryptographic key changes:
  • As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically
  • At least annually
Oracle Advanced Security Transparent Data Encryption (TDE) column encryption provides the ability to independently re-key the master encryption and/or table keys; The master encryption key and tablespace keys for TDE tablespace encryption cannot be re-keyed; work-around is to move data from one encrypted tablespace into a newly generated tablespace.
3.6.5: Retirement or replacement of old or suspected compromised cryptographic keys Master keys should not be deleted from the wallet or HSM due to backup and recovery requirements.
3.6.6: Split knowledge and establishment of dual control of cryptographic keys With Oracle TDE, only the database needs 'access' to the master encryption key stored in wallet or HSM, split knowledge of the key is not possible. Instead, the wallet password can be split between any number of persons. Oracle Database Vault can be used to enforce two person login requirement during execution of the 'alter system' command used to open the TDE wallet.
3.6.7: Prevention of unauthorized substitution of cryptographic keys Enforced by Oracle Advanced Security Transparent Data Encryption (TDE)
 
4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easy and common for a hacker to intercept, modify, and divert data while in transit.
4.1: Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.
Examples of open, public networks that are in scope of the PCI DSS are:
  • The Internet
  • Wireless technologies
  • Global System for Mobile communications (GSM), and General Packet Radio Service (GPRS).
Both Oracle Database and Oracle Fusion Middleware support encryption of network traffic using SSL/TLS.

For the Oracle Database, SSL/TLS support is provided by Oracle Advanced Security.
 
Maintain a Vulnerability Management Program
6. Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches. All systems must have the most recently released, appropriate software patches to protect against exploitation by employees, external hackers, and viruses.

Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
6.1: Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release. Automated by Oracle Enterprise Manager Grid Control
6.2: Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues. (Customer internal policy)

Subscribe to the 'Electronic Subscriptions' section on OTN and be sure to check the box next to the Oracle Security Alerts and click 'Continue' to confirm.
6.3: 6.3.4: Production data (live PANs) are not used for testing or development Oracle Enterprise Manager Data Masking allows to mask ...
6.4: Follow change control procedures for all changes to system components. The procedures must include the following: Change control procedures can be automated with Oracle Enterprise Manager Change Control. Also BPEL Process manager can be used for process management of change control, security procedures in general.
6.5: 6.5.2: Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws. Addressed by 'dbms_assert'
6.5.8: Insecure cryptographic storage The TDE master encryption key is stored in an encrypted file, the Oracle Wallet, which is encrypted by a passphrase (the wallet 'password'), based on the PKCS#5 standard; for even better security and complete key management incl. FISP 140-2 level 2 or 3 certification, the TDE master encryption key can be stored in a hardware security module (HSM).
6.5.9: Insecure communications Oracle Advanced Security Network encryption allows to encrypt the traffic to and from the database either with SSL/TLS or navite encryption, which requires only to add a few lines into a database configuration file.
 
Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.

"Need to know" is when access rights are granted to only the least amount of data and privileges needed to perform a job.
7.1: Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:  
  7.1.1: Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities Oracle Database Vault realms restrict access to application / cardholder data from highly privileged users / DBA.

Oracle Database Vault factors and commands rules enable strict controls on access to applications, data and databases.

Oracle Database Vault Separation of Duty prevents unauthorized administrative actions in the Oracle Database.

Oracle Label Security label factors provide additional security attributes for determining need-to-know.

Oracle Virtual Private Database provides complete masking based on need-to-know.

Oracle Database object privileges and database roles provide basic security.

Oracle Identity Management provides enterprise user provisioning to computing resources.
7.1.2: Assignment of privileges is based on individual personnel's job classification and function
7.2: Establish an access control system for systems components with multiple users that restricts access based on a user's need to know, and is set to "deny all" unless specifically allowed. This access control system must include the following: Oracle Database Vault realms restrict access to application / cardholder data from highly privileged users / DBA.

Oracle Database Vault factors and commands rules enable strict controls on access to applications, data and databases.

Oracle Database Vault Separation of Duty prevents unauthorized administrative actions in the Oracle Database.

Oracle Label Security label factors provide additional security attributes for determining need-to-know.

Oracle Virtual Private Database provides complete masking based on need-to-know.

Oracle Database object privileges and database roles provide basic security.

Oracle Identity Management provides enterprise user provisioning.
 
8. Assign a unique ID to each person with computer access
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
8.1: Assign all users a unique ID before allowing them to access system components or cardholder data. Oracle Database authentication supports unique user name authentication for dedicated user accounts, shared schemas and proxy authentication.

Oracle Identity Management provides enterprise user provisioning.
8.2: In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:
  • Passwordor passphrase
  • Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys)
Oracle Advanced Security Option provides strong authentication via Kerberos, PKI, and RADIUS.
8.3: Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS); terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates. Oracle Advanced Security Option provides strong authentication via Kerberos, PKI, and RADIUS.
8.4: Render all passwords unreadable during transmission and storage on all system components using strong cryptography (defined in PCI DSS Glossary of Terms, Abbreviations, and Acronyms). Oracle Database encrypts database user passwords transmitted on the wire and stored in the database.
8.5: Ensure proper user authentication and password management for non-consumer users and administrators on all system components as follows: Oracle Identity Management
  8.5.1: Control addition, deletion, and modification of user IDs, credentials, and other identifier objects Limit access to Oracle administration account SYSDBA

Deploy Oracle Database Vault for additional separation of duty

Deploy Oracle Identity Management for enterprise user provisioning.
8.5.2: Verify user identity before performing password resets Oracle Database authentication

Oracle Database Vault separation of duty
8.5.3: Set first-time passwords to a unique value for each user and change immediately after the first use Create Oracle database account with password expired
8.5.4: Immediately revoke access for any terminated users Oracle Identity Management and Oracle Database Enterprise User Security
8.5.5: Remove inactive user accounts at least every 90 days Oracle Identity Management and Oracle Database Enterprise User Security
8.5.6: Enable accounts used by vendors for remote maintenance only during the time period needed Oracle Enterprise Manager account management

Oracle Database Vault factors and command rules

Oracle Database Vault realms to prevent access to application data

Oracle Database Vault separation of duty
8.5.8: Do not use group, shared, or generic accounts and passwords (Customer internal policy); Oracle Database Enterprise User Security; Oracle Database Proxy authentication
8.5.9: Change user passwords at least every 90 days Oracle Database profiles
8.5.10: Require a minimum password length of at least seven characters Oracle Database password complexity check (See here for recommendations for a strong password)
8.5.11: Use passwords containing both numeric and alphabetic characters
8.5.12: Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used Oracle Database profiles
8.5.13: Limit repeated access attempts by locking out the user ID after not more than six attempts
8.5.14: Set the lockout duration to 30 minutes or until administrator enables the user ID
8.5.15: If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal
8.5.16: Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users. Oracle Database authentication

Oracle Advanced Security Kerberos, PKI, and RADIUS support
 
9. Restrict physical access to cardholder data
 
Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis if something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
10.1: Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user. (Customer internal policy); Establish separate DBA accounts in the database. Optionally use proxy authentication to limit number of accounts with DBA privilege but still audit.

Oracle Database Vault separation of duty for more stringent controls on database administration.

Oracle Audit Vault audit data consolidation for enterprise reports and alerting.

Oracle Identity Management provides enterprise user provisioning.
10.2: Implement automated audit trails for all system components to reconstruct the following events: (see below for individual replies)
  10.2.1: All individual user accesses to cardholder data Oracle Database Auditing; Oracle Database Fine Grained Auditing (FGA) on cardholder data; Oracle Audit Vault reports and alerts
10.2.2: All actions taken by any individual with root or administrative privileges Establish separate DBA accounts in the database. Optionally use proxy authentication to limit number of accounts with DBA privilege but still audit.

Oracle Database Vault Realms and Separation of duty for more stringent controls on database administration.

Oracle Database Vault realm reports.

Oracle Audit Vault audit data consolidation for enterprise reports and alerting.

Oracle Identity Management provides enterprise user provisioning.
10.2.3: Access to all audit trails OS audit trails need to be protected on the OS level; access to audit trails generated by and stored in Oracle (Database or Oracle Audit Vault) are protected by Oracle Database Vault and Oracle Advanced Security (encryption during transist and storage)
10.2.4: Invalid logical access attempts Oracle Audit Vault is protected by Oracle Database Vault.
10.2.5: Use of identification and authentication mechanisms Oracle Database authentication

Oracle Advanced Security

Kerberos, PKI, RADIUS authentication.

Oracle Identity Management Access Management Suite
10.2.7: Creation and deletion of system-level objects Oracle Database auditing
10.3: Record at least the following audit trail entries for all system components for each event:  
  10.3.1: User identification Oracle Database Auditing

Oracle Audit Vault audit data consolidation, reporting, alerting and protection

Oracle client identifiers for identity propagation across single connection.
10.3.2: Type of event
10.3.3: Date and time
10.3.4: Success or failure indication
10.3.5: Origination of event
10.3.6: Identity or name of affected data, system component, or resource
10.5: Secure audit trails so they cannot be altered. Oracle Audit Vault audit data consolidation protects audit data in transit and storage.
  10.5.1: Limit viewing of audit trails to those with a job-related need Oracle Audit Vault separation of duty limits access to audit data.
10.5.2: Protect audit trail files from unauthorized modifications Oracle Audit Vault separation of duty prevents access and modification of audit data by administrators (DBA)
10.5.3: Promptly back-up audit trail files to a centralized log server or media that is difficult to alter Oracle Audit Vault audit data consolidation provides a scalable and secure audit warehouse
10.5.4: Copy logs for wireless networks onto a log server on the internal LAN. Audit Vault (future release) will provide the ability for customers to develop custom audit collectors (i.e. network logs, OS logs, etc.)
10.5.5: Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). Oracle Audit Vault audit data consolidation protects audit data in transit with SHA-1 and MD5 data integrity.

Oracle Audit Vault separation of duty prevents access and modification of audit data by administrators (DBA)
10.6: Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).
Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6.
Oracle Audit Vault provides out-of-box reports, customizable alerts and an alert dashboard for monitoring audit data.

Customized reports can be generated using Oracle Application Express, Oracle BI Publisher and 3rd party tools. The Oracle Audit Vault warehouse schema is published.
10.7: Retain audit trail history for at least one year, with a minimum of three months online availability. Oracle Audit Vault provides a scalable and secure audit warehouse for storing large volumes (Terabytes) of audit data.
 
11. Regularly test security systems and processes
 
Maintain an Information Security Policy
12. Maintain a policy that addresses information security for employees and contractors
 
Appendix A: PCI DSS Applicability for Shared Hosting Providers
A: Hosting providers protect cardholder data environment
As referenced in Requirement 12.8, all service providers with access to cardholder data (including shared hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.4 states that shared hosting providers must protect each entity’s hosted environment and data. Therefore, shared hosting providers must additionally comply with the requirements in this Appendix.
A.1: Protect each entity's (that is merchant, service provider, or other entity) hosted environment and data, per A.1.1 through A.1.4: A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.
  A.1.1: Ensure that each entity only runs processes that have access to that entity’s cardholder data environment. Oracle Database Vault realms restrict access to application / cardholder data from highly privileged users / DBA.

Oracle Database Vault factors and commands rules enable strict controls on access to applications, data and databases.

Oracle Database Vault Separation of Duty prevents unauthorized administrative actions in the Oracle Database.

Oracle Label Security label factors provide additional security attributes for determining need-to-know.

Oracle Virtual Private Database provides complete masking based on need-to-know.

Oracle Database object privileges and database roles provide basic security.

Oracle Identity Management provides enterprise user provisioning to computing resources.
A.1.2: Restrict each entity's access and privileges to own cardholder data environment only. Oracle Database Vault realms restrict access to application / cardholder data from highly privileged users / DBA.

Oracle Database Vault factors and commands rules enable strict controls on access to applications, data and databases.

Oracle Database Vault Separation of Duty prevents unauthorized administrative actions in the Oracle Database.

Oracle Label Security label factors provide additional security attributes for determining need-to-know.

Oracle Virtual Private Database provides complete masking based on need-to-know.

Oracle Database object privileges and database roles provide basic security.

Oracle Identity Management provides enterprise user provisioning to computing resources.
A.1.3: Ensure logging and audit trails are enabled and unique to each entity's cardholder data environment and consistent with PCI DSS Requirement 10. Oracle Audit Vault policies can be easily deployed to enterprise databases, enabling consistent auditing of access to cardholder data.
A.1.4: Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider. Oracle Audit Vault provides out-of-box reports, customizable alerts and an alert dashboard for monitoring audit data.

Customized reports can be generated using Oracle Application Express, Oracle BI Publisher and 3rd party tools. The Oracle Audit Vault warehouse schema is published.
 
Learn More
· Oracle by Example: Database Security

Security Options
· Oracle Database Vault
· Oracle Advanced Security
· Oracle Label Security
· Oracle Secure Backup

Security Features
· Data Encryption
· Virtual Private Database
· Database Auditing
· Backup Encryption
· Proxy Authentication
· Enterprise User Security
· Secure Application Roles
· Fine Grained Auditing

Related Technologies
· Audit Vault
· Secure Backup
· Configuration Management
· Information Rights Management
· Identity Management

Discussion Forums
· Audit Vault
· Security
· Database
E-mail this page
Printer View Printer View
Oracle Is The Information Company About Oracle | Oracle RSS Feeds | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy