Transparent Data Encryption Explained

By: Cheryl Lei Bryll, OCP Senior Oracle DBA Mobile: 214-733-3869 cbryll@onshoresolutions.net http://www.onshoresolutions.net The slides for this presentation can be obtained from the website : www.onshoresolutions.net

Transparent Data Encryption Why there is a need for Transparent Data Encryption What does Transparent Data Encryption address in the security model When to use Transparent Data Encryption How to implement Transaction Data Encryption

Why there is a need for Transparent Data Encryption Security threats External threats - backup tapes Internal threats – privileged users\outsourcing U.S laws - regulatory compliance issues PCI DSS FIPS 140-2 SOX Act of 2002 HIPPA International regulations To fully understand how Oracle’s ‘data at rest’ solution will secure your private data you must first understand the type of threats your data is exposed to. You must also understand the latest regulatory standards initiated to ensure your IT organization is in compliance. These regulations were initiated to address the growing concern over brute force and other technologies used to ‘de-crypt’ secured data. While initially a encryption algorithm such as DES might have been a viable solution for data security no longer is this the case. The PCI – Payment Card Industry has defined in detail the steps a organization must adhere to when storing credit card information. Likewise, HIPPA Health Insurance Portability and Accountability Act specifies a complete set of standards to be compliant. Similar in nature, FIPS the Federal Information Processing Standard continually strives to give the highest of standards to acceptable encryption algorithms. The advantage of compliance is the protection you provide your customers. In some cases there are hefty fines if an external auditor confirms that your handling of customer data is not in compliance. The burden of protection now rests heavily on database administrators.

Security threats are an ever growing concern Findings from 2009 IOUG Data Security report : 50 percent increase in data breaches since last year Managers see internal threats more pressing than external threats Outsourcing of database administration, development and testing functions Close to half of organizations employ actual production data within non-production environments corporate management is still complacent about data security. Management commitment needed It is equally important for the Oracle DBA to keep up to date with the peer community of Oracle users, the IOUG is an exceptional resource. Each year the IOUG compiles and publishes a ‘Data Security Report’. As seen in the report, respondents are indeed concerned about protecting data. The most disturbing news from the respondents was the fact that there was a 50% increase in actual data breaches over 2008.

Internal threats do occur Think internal threats don’t exist? Think again … The biggest data security problem of organizations today is the trustworthiness of the people employed to administer or development against the organizations stored data. With the increasing trend towards outsourcing these sensitive trusted positions such as DBA or Developers within the organization further create risks of internal security breaches. Think about it, when you contract to outsource to an offshore company you no longer have an idea who is looking at your stored data and what they are doing with that data. Other ways internal threats occur: Corporate use of mobility products – laptops and usb devices Disgruntled Ex-Employees DBA and/or Sys admins not applying security patches

4/17/2008 a total of 2.1 million patients were affected by the theft of the UM backup tapes from Archive America. The good news is proprietary compression and encoding were used in writing the tapes. Therefore third party security experts verified that after a week of attempts the data was not able to extract any readable data.

The PCI – Payment Card Industry PCI DSS is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment.  Created by Visa, MasterCard, Discover card, JCB and American Express Protect Cardholder Data - requirement 3 www.pcisecuritystandards.org/security_standards/pci_dss.shtml Protect Cardholder Data Requirement 3: Protect stored cardholder data a)PCI requirement 3.6.1 states the need for a ‘strong cryptographic key’s b)PCI requirement 3.6.3 states the need for secure cryptographic storage

SOX - Sarbanes-Oxley requirement Sets standards for public companies Information technology governance for financials Section 404 Assessment of internal controls Most costly to implement 2007 showed avg. $1.9 -1.3 million to comply External auditors to access compliance Focused on ‘write events’ (tampering) Transparent Data Encryption is just one part of the Oracle Advanced Security solutiona that is meant to protect Oracle environments at the data level, network level, key management level, segregation of duties and auditing levels. Why we have SOX? Auditor conflicts of interest Boardroom failures Securities analysts’ conflicts of interest Inadequate funding of the SEC Banking practices Internet bubble Executive compensation

HIPAA - Health Insurance Portability and Accountability Act Includes privacy protection provisions for personal health information Compliance has been required since 2005 Includes a privacy rule and a security rule Require physicians to ensure they are protecting the privacy and security of patients' medical information and using a standard format when submitting electronic transactions. The privacy rule = regulations for the use and disclosure of protected health information The security rule = meant to develop national standards for the security of electronic health care information.

What does Transparent Data Encryption address? Preventing privacy and identity theft Protecting data at rest, meaning data on the disks (in datafiles) or in backup media Protecting against unauthorized access by use of encryption keys Allows for an easy to implement solution to data protection Encrypting credit card , social security, and personal identifying medical information protects privacy and identify theft. Encryption of datafiles and backup tapes protects against sensitive data exposed in case of thefts of this media. Encryption master keys are stored outside of the database. Therefore, if backup tapes are stolen the theft Does not get the master encryption key. As a result, the encrypted information is unreadable. Transparent data encryption requires no application or code changes. The DBA implements TDE using DDL. Key management is done transparent by the Oracle engine.

There has been such an increase in organizations collecting personal data from customers and storing that data. As a result an individuals personal information is fully exposed. How can we appease our customers so they know their personal information is protected? By strictly following regulatory standards we can prove to our customers that we are doing every means possible to secure their personal private information. Oracle Transparent Data Encryption addresses data protection and privacy standards such as PCI DSS

Protecting data at rest with Transaction Data Encryption The encryption is done at the operating system level, where data is stored Encryption keys are stored external of the database Table columns or entire tablespaces are encrypted The datafiles, archive logs, redo logs and backup media contain these objects in encrypted format Strong encryption algorithms are used It is not enough to implemented encryption of data, the encryption method used must be strong enough to prevent brute force attacks. The FIPS 140 standard addresses the levels of strength for a particular encryption algorithm. The definition of ‘data at rest’ includes all physical storage media: datafiles, archive logs, redo logs as well as physical backup media.

Transparent Data Encryption addresses strong encryption The need for stronger data security standards with strong encryption is a growing concern … Fun fact: in World War II the German’s used an Enigma encryption machine to encode messages. This gave them an significant advantage over the Allies, as the Allies could intercept their Navy messages but could not understand the messages due to the encryption. However, the British were finally able to decrypt these messages due to the fact that the Enigma machine had a very week encryption mechanism. As well as the fact that a U-boat was captured and the encryption key was found. This proved to be beneficial to the Allies and change the course of the war.

Need for strong encryption techniques PCI defines ‘strong encryption’ The ‘KEY’ determines the strength of an encryption algorithm. At a minimum 80 bits. FIPS (Federal Information Processing Standards) 140-2 defines strong encryption algorithms NIST (National Institute of Standards and Technology) Special publication 800-57 - Recommendation for Key Management Transparent Data Encryption uses ‘Symmetric Block Ciphers’. DES – (data encryption standard) this is the U.S. cipher and only uses 56 bit keys DES was initially thought to be a good encryption algorithm for Data storage security. However, it was then shown that DES can become insecure very quickly. If fact tests showed DES could be broken in under 24 hours with a brute force attack. The greatest benefit of DES is it is fast. DES is no longer recommended by the National Institute of Standards and Technology (NIST). AES – (advanced encryption standard) is the newest and most secured algorithm. In fact, NSA has approved the use of AES encryption algorithms for use to protect top security data. http://www.centralpaymentcorp.com/pdf/pci_dss_glossary_v1-1.pdf The National Institute of Standards and Technology (NIST) All special publications in the 800 series related to computer technology: Special publication 800-57 - Recommendation for Key Management http://csrc.nist.gov/publications/PubsSPs.html

Encryption techniques Symmetric ciphers – same key for both decryption and encryption DES,3DES,AES The NSA (National Security) has approved to use the AES 192 or 256 key length algorithms for top secret data Asymmetric ciphers – different keys for both encryption and decryption RSA/DSA Hashing algorithms - One way encryption MD5 In the world of encryption there are three main techniques. Transparent Data Encryption uses ‘Symmetric Block Ciphers’ (same key for both encryption and decryption). DES – (data encryption standard) this is the U.S. cipher and only uses 56 bit keys DES was initially thought to be a good encryption algorithm for Data storage security. However, it was then shown that DES can become insecure very quickly. If fact tests showed DES could be broken in under 24 hours with a brute force attack. DES is no longer recommended by the National Institute of Standards and Technology (NIST). AES – (advanced encryption standard) is the newest and most secured algorithm. In fact, NSA has approved the use of AES encryption algorithms for use to protect top security data.

Protects against unauthorized access For each encrypted table column or tablespace a key is created The table and tablespace keys are encrypted with a master database key The master database key is stored external to the database (external security module) The external security module is the Oracle wallet Oracle 11g supports the Hardware Storage Module With the external security module architecture a separation of duties exists. A security administrator can password encrypt the Oracle wallet , while the DBA does not have privy to this information. Likewise, the DBA has sys access to the database but the security administrator does not. Keeping the authorized access of the data from the master encryption key fulfills the SOX regulations.

Allows for an easy to implement solution to data protection Before Transparent Data Encryption Oracle 8i API for data encryption called DBMS_OBFUSCATION_TOOLKIT package Oracle 9i provided support for the 3DES algorithm Oracle 10g the package DBMS_CRYPTO package was added With Transparent Data encryption Oracle 10g rel.2 introduced TDE– with encryption at the column level Oracle 11g further enhances Transparent Data Encryption with tablespace encryption and support for HSM Oracle started addressing security of data at the start of Oracle 8i rel.2 in the year 2000. The goal was to ensure privacy protection for e-commerce organizations. Using the package DBMS_OBFUSCATION_TOOLKIT requires a lot of work by the developer , defining code to encrypt and decrypt each column separately. Additionally, a developer would use views and triggers to accomplish decryption for queries or encryption for DML respectively. In 10g the package DBMS_CRYPTO package was created and made the DBMS_OBFUSCATION_TOOLKIT package obsolete as it was intended to replace it. Less coding was needed. With 10g Rel.2 – encryption of column data was made transparent to developers and users of applications with Transparent Data Encryption.

When to use Transparent Data Encryption When ‘data at rest’ needs to be protected When only certain data needs encryption When you need to adhere to regulatory standards When used as a contributing ‘component’ of the overall security solution

How to use Transparent Data Encryption Oracle 10g column level encryption Oracle 11g tablespace level encryption Key management Backups & Exports Replication Troubleshooting

Transparent Data Encryption – 10g rel.2 Restrictions Transparent Data Encryption is not included in Standard Edition Transparent Data Encryption is an add-on product bundled with Oracle-net server or Oracle net client Transparent Data Encryption is only available in Oracle 10g rel. 2 and higher Indexes – b-tree only TDE cannot be used in foreign key constraints TDE can't be enabled on a SYS-owned table TDE cannot be used in standard export and import The COMPATIBLE initialization parameter must be at least 10.2.x.x. RMAN backups – not with image copies Materialized view logs Transportable tablespaces External large objects (BFILE) If you are setting up a new database and new application these restrictions are helpful to note during your design of the system. However, most likely you will be implementing TDE on an existing running application. Therefore, it is imperative that you initially research your database structure to ensure the columns you chose to implement TDE on do not fall into these prohibited areas. First of all, the Advanced Data Security module includes ‘Transparent Data Encryption’ and this is an add-on product. The cost is approximately $10,000 per cpu. In the case of indexes a column selected to be encrypted must not have ‘salt’ applied. Salt is used to provide randomness to data in columns that are prone to similarities. In most cases in an OLTP system you create indexes to primary keyed column or unique valued columns. In which case needing to ‘salt’ the encryption is not a concern. Also, only b-tree indexes can be used. Bitmap indexes could be huge, in the case of some very large data warehouses. And as such the processing and storage required to encrypt the index column is a hindrance. Not to mention the fact that the Oracle engine will not use a encrypted index in range conditions. Instead a full table scan will be done.

Steps for using column-level Transparent Data Encryption: Set compatibility parameter Set up wallet location Create wallet Add ‘encrypt’ to column Indexing encrypted columns Closing wallet Restarting database instance

Steps for using column-level Transparent Data Encryption: Set compatibility parameter Compatibility level of 10.2 or higher

Steps for using column-level Transparent Data Encryption: Set up wallet location search order for wallet location If exists, the wallet location specified by the parameter in the sqlnet.ora file ENCRYPTION_WALLET_LOCATION If exists, the wallet location specified by the parameter in the sqlnet.ora file WALLET_LOCATION The default location for the wallet ($ORACLE_BASE/admin/$ORACLE_SID/wallet) ENCRYPTION_WALLET_LOCATION – used to store a second wallet location. This allows you to have a separate wallet location for TDE. V$ENCRYPTION_WALLET fixed view to display wallet settings mkdir /app/oracle/admin/test/encryption_wallet

Steps for using column-level Transparent Data Encryption: Create the wallet to hold the encryption key and open the wallet Must have ‘alter system’ privilege Password is case sensitive, must use quotes The command will create a wallet file (ewallet.p12) Opens the wallet Generates database server’s master encryption key

Steps for using column-level Transparent Data Encryption: Add ‘encrypt’ to column Include the ENCRYPT clause to specific columns You can specify the encryption method using ENCRYPT USING ‘<AES192>‘ An encryption key for the table is created See all columns in your database that are encrypted SELECT * FROM DBA_ENCRYPTED_COLUMNS; CREATE TABLE tde_private ( id NUMBER(10) primary key, info VARCHAR2(50) ENCRYPT USING 'AES192' ) TABLESPACE transtable;

Demo – 10g Column level

Demo – 10g Column level

Demo – 10g Column level car car Card_num Card_num ------------------- X!wp#!9r4@ee car Card_num -------------------715088606525 In 10g encryption occurs at the Sql layer

Steps for using column-level Transparent Data Encryption: Indexing encrypted columns index columns cannot contain a salted encryption so be sure to create those columns as 'no salt‘ Only b-tree indexes Do not use an encrypted column on an index used in range scans

Steps for using column-level Transparent Data Encryption: Foreign key columns cannot be encrypted This is because every table has a unique column encryption key

Steps for using column-level Transparent Data Encryption: Salt By default all columns have salt added Salt adds an extra layer of randomness You can turn salt off alter table cust_info modify (cust_last encrypt no salt); SQL> desc DBA_ENCRYPTED_COLUMNS; Name Null? Type ----------------------------------------- -------- ---------------------------- OWNER NOT NULL VARCHAR2(30) TABLE_NAME NOT NULL VARCHAR2(30) COLUMN_NAME NOT NULL VARCHAR2(30) ENCRYPTION_ALG VARCHAR2(29) SALT VARCHAR2(3) SQL> COLUMN table_name format a15; SQL> COLUMN column_name format a15; SQL> SELECT table_name,column_name,salt FROM DBA_ENCRYPTED_COLUMNS; TABLE_NAME COLUMN_NAME SALT --------------- --------------- --------- TDE_TEST DATA YES TDE_DOCTOR DOC_FIRST YES TDE_DOCTOR DOC_LAST YES TDE_TEST_2 DATA YES TDE_PRIVATE INFO YES CUST_INFO SSN YES CUST_INFO DOB YES CUST_INFO CUST_LAST NO

Steps for using column-level Transparent Data Encryption: Closing the wallet Encrypted columns cannot be accessed Restarting the database The wallet must be manually opened ALTER SYSTEM SET WALLET CLOSE; ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY “<password>“; When the wallet is closed access is disabled to all encrypted columns. This can be helpful for READ-ONLY databases. Closing the wallet during database maintenance is also a good idea, so the data is not fully accessible to maintenance DBA’s during this time. This is assuming you have a separate ‘Security Administrator’ in charge of the wallet password.

How to prove encryption is working? SQL> conn cust_admin/<password> Connected. SQL> create table my_secrets ( v_special varchar2(100)) tablespace tde_ts; Table created. SQL> insert into my_secrets values ('TOP_SECRET'); 1 row created. SQL> COMMIT; Commit complete.

Hacker on the OS can see data in your physical files Without encryption the redo logs show cleartext of your DML bash-3.2$ pwd /app/oracle/oradata/test bash-3.2$ strings redo02.log | grep TOP_SECRET TOP_SECRET

Hacker on the OS can see data in your physical files With encryption the datafiles and redo logs do NOT show cleartext of your DML

Implementation steps Implementation Steps: 1. Identify columns that require data protection credit cards, ssn, medical info 2. Verify supported datatype no bfiles 3. Verify column is not part of a foreign key query the data dictionary to find this information 4. Encrypt existing and new data a. may want to do a 'move' of tablespace to remove ghost copies b. perform the ddl c. alter tables d. backup database and wallet !

Transparent Data Encryption 11g Tablespace encryption No more searching for columns to encrypt Eliminates the foreign key limitation Less of a performance impact Oracle E-Biz 11i version 11.5.10.2 or higher Support for SecureFiles Support for hardware security modules (HSM) Stores master key on separate hardware device Share keys across servers

Steps for using tablespace Transparent Data Encryption: No restriction on Foreign Key columns Default algorithm is AES 128 Range scans are no longer a problem view v$encrypted_tablespaces COMPATIBLE parameter to 11.1 Create tablespace securets datafile '/u99/app/oracle/oradata/fins/fins/securets_01.dbf' size 300M encryption using 'AES192' Default storage (encrypt); Only “NEW” tablespaces can be encrypted.

Demo – 11g tablespace encryption

Demo – 11g tablespace encryption

Demo – 11g tablespace encryption

Steps for SecureFile LOBsTransparent Data Encryption: COMPATIBLE parameter to 11.1 Block level encryption of LOBs Cannot change encryption algorithm, must do a rekey CREATE TABLE lob_tab ( id NUMBER, cmment_info VARCHAR2(300), clob_data CLOB ) LOB(clob_data) STORE AS SECUREFILE encrypt_lob( ENCRYPT USING 'AES256' ); ALTER TABLE lob_tab MODIFY ( clob_data CLOB ENCRYPT USING '3DES168' ); *! DOES NOT WORK** ALTER TABLE lob_tab REKEY USING 'AES192';

Demo – Lobs http://www.oracle-base.com/articles/11g/SecureFiles_11gR1.php

Transparent Data Encryption – support for HSM Support for hardware security modules (HSM) Allows master key to be stored in one place and used by many RAC nodes A rekey operation is needed to change or upgrade to using HSM in 11g http://en.wikipedia.org/wiki/Hardware_security_module

Transparent Data Encryption – HSM How does the Hardware security module work? Basically a separate ‘tamper-resistant’ hardware is used to create, store and use cryptographic keys. The HSM device adds increased processing power for encryption\decryption of keys. And should meet the proper validation to ensure it meets industry standards such as FIPS 140-2. Selecting the proper HSM for your organization is important and research must be done. The FIPS 140-2 standard provides a leveling system that you can Use to gauge the HSM vendor products. A vendor with a level 4 certified HSM solution is highly recommended. It is also important to note that the price tag of a chosen HSM solution can range from just under one thousand to many hundreds of thousands of dollars. http://csrc.nist.gov/groups/STM/index.html

Transparent Data Encryption – Implement HSM Steps to implement the Hardware security module: Modify sqlnet.ora parameter ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)) Configure PCKS#11 library /opt/oracle/extapi/[32,64]/hsm/{VENDOR}/{VERSION}/libapiname.ext Configure HSM device Create user/password Create the master key in the database ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY user_Id:password [MIGRATE USING wallet_password] Open the wallet

Transparent Data Encryption – Key Management Two-tier key architecture Resetting keys Backup and recovery of keys Autologin External security module Hardware security module Wallet

Transparent Data Encryption – Key Management Two-tier key architecture Master database key Used to encrypt the column and tablespace keys Stored in the Oracle wallet Table \ tablespace key Used to encrypt columns & indexes Stored in the data dictionary in encrypted format

Transparent Data Encryption – Key Management Reset master key ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY <password>; Rekeying the table key ALTER TABLE cust_info REKEY; Rekeying to change encryption algorithm ALTER TABLE cust_info REKEY USING '3DES168'; ALTER TABLE cust_info ENCRYPT USING ‘AES128’;

Transparent Data Encryption – Key Management Backup of keys Must backup the ewallet.p12 file Every time you reset the master you should backup the wallet file Recovery of keys To restore simply apply a backup copy of ewallet.p12 to the wallet location If wallet is not the most recent master key, then you must perform a data recovery Restore – if a recovery is needed because the latest copy of the wallet is not the most current copy of the wallet (a reset was done after the latest copy) then all recent modifications to encrypted columns are lost.

Transparent Data Encryption – Key Management Autologin Implicitly opens wallet Set up using mkwallet utility Oracle Wallet Manager Cannot have already ‘opened’ wallet Not recommended for TDE (lessens security)

Transparent Data Encryption – Key Management External security module – the storing of master keys outside of the database Hardware security module (HSM) Oracle Wallet Default database wallet Separate wallet set in sqlnet.ora ENCRYPTION_WALLET_LOCATION

EXTERNAL SECURITY MODULE SUPPORT BY DATABASE VERSION MASTER KEY FOR … … IN ORACLE WALLET … IN HSM Oracle RDBMS 10gR2 Column Encryption Yes No Oracle RDBMS 11gR1 (11.1.0.6) Tablespace Encryption (11.1.0.7) Yes (no re-key) Oracle Advanced Security Transparent Data Encryption Best Practices; August 2009 (version 11) Peter A. Wahl

Backups & Exports – RMAN TDE encrypted columns will be encrypted a second time during the backup RMAN Transparent mode is the default No DBA intervention – no need to enter a password during daily backups RMAN> configure encryption for database on; During recovery Oracle Wallet must be open Only backup sets can be encrypted, image copies cannot. This is just RMAN transparent encryption and not specially TDE.

Backups & Exports – Data Pump

Demo – Data Pump ENCRYPTION_PASSWORD= is the data pump password used and not the wallet password. This password must be similarly entered during the import

Demo – Data Pump Creating an external table with encrypted columns, type ORACLE_DATAPUMP

Demo – Data Pump Oracle Data Pump prohibits the export of an external table ORA-39214: Data Pump does not support external tables with encrypted columns.

Transparent Data Encryption – Replication Clones Materialized views Data guard Streams RAC

Cloning Production It is important that the Oracle Wallet from the ‘source’ is copied to the ‘target’. Production Development Copy When cloning a database you could use RMAN, export/import, ect. It is important that the Oracle Wallet from the ‘source’ is copied to the ‘target’.

Materialized Views Encrypted columns cannot be used with 10g Materialized view logs. When creating a materialized view the target columns do not take on the encrypt attribute of the data types.

Data Guard It is important that the Oracle Wallet from the ‘source’ is copied to the ‘target’. Creating a new wallet with the same password will not work. Encryption=data_only, all, encrypted_columns_only encryption_mode=transparent Encrption_algorithm=AES192 Primary Standby Copy Data Guard is a method to hot standby a database. The two (or more) standby databases must use the same master key and therefore the Oracle Wallet from the ‘source’ needs to be copied to the ‘target’. In Oracle 10g Data Guard with physical standby databases is supported, a master key is not needed until and unless the standby database is opened. However, In Oracle 11g Data Guard for logical standby databases “active” read-only is supported. Therefore, in addition to the requirement that the Oracle Wallet be copied from the source server to the target server the Wallet must also be open.

Streams . Local car Card_num ------------------- X!wp#!9r4@ee decrypted The data is decrypted by the streams engine prior to transporting to the target system. However, if the target system does not successfully accept the message the data is stored in a temp location encrypted. Buffered queue car Card_num -------------------715088606525 downstream encrypted Oracle supports Transparent Data Encryption with Streams in 11g. Streams are a unique case, as the encrypted data is decrypted by the Streams engine prior to moving the stream message through the network. However, to protect data if a error occurs during the transmit the data is stored encrypted in a temporary area on disk. Prior to 11g any columns set as ENCRYPT will produce an error and the table will be skipped when used with Streams. The compatibility level of 11.0.0 or higher is needed it the init.ora car Card_num ------------------- X!wp#!9r4@ee Copy wallet

Open the wallet manually on each node database. RAC RAC node 2 Copy the Oracle Wallet from the first node to each additional node servers in the Real Application Cluster. Open the wallet manually on each node database. RAC node 1 copy RAC node 3 SAN: Datafiles,redo ,archive logs With RAC implementations the first instance with the Oracle Wallet master key is the ‘source’ and must have the Oracle Wallet copied to the other RAC nodes. The same master key must be used for all RAC nodes. If a re-key is done on the master key then the ‘source’ Oracle Wallet must be copied to the other ‘target’ RAC nodes.

Troubleshooting How do you determine that Oracle Advanced Security Option is installed ? Universal installer opatch lsinventory $ORACLE_HOME/bin/adapters

Troubleshooting How do you determine that Oracle Advanced Security Option is installed ? Universal installer opatch lsinventory $ORACLE_HOME/bin/adapters

Troubleshooting How do you determine that Oracle Advanced Security Option is installed ? Universal installer opatch lsinventory $ORACLE_HOME/bin/adapters

Troubleshooting If you create a new table based on a table with encrypted columns does the ‘encrypt’ column definition transfer with the table? No

Troubleshooting What happens to my encrypted data when the Oracle wallet is closed? The data is inaccessible. However, you can still access all the other columns. Just do not perform ‘select *’ queries.

Troubleshooting SQL> CREATE TABLE cust_info 2 ( cust_id NUMBER(12) PRIMARY KEY, 3 cust_last VARCHAR2(30) ENCRYPT USING 'AES192' NO SALT, 4 cust_first VARCHAR2(30), 5 dob DATE, 6 state VARCHAR2(5), 7 ssn VARCHAR2(9) ENCRYPT USING 'AES256' 8 ) TABLESPACE tde_ts; ssn VARCHAR2(9) ENCRYPT USING 'AES256' * ERROR at line 7: ORA-28340: a different encryption algorithm has been chosen for the table Is it possible to apply to different encryption algorithms on the same table? NO! An error will result, the encryption algorithm is based on the table. Remember only one table key is created regardless of the amount of columns set to ENCRYPT.

SQL> column WRL_TYPE format a5 Troubleshooting SQL> column WRL_TYPE format a5 SQL> column WRL_PARAMETER format a50 SQL> select * from V$ENCRYPTION_WALLET; WRL_T WRL_PARAMETER STATUS ----- -------------------------------------------------- --------- file /app/oracle/admin/test/encryption_wallet/ OPEN How can the DBA determine if the wallet is open and how can the DBA determine the OS location of the wallet? Simply query the v$encryption_wallet view.

“White papers & tutorials” Questions/Comments? Slides to be posted to: http://www.onshoresolutions.net/knowledge.html “White papers & tutorials”

References: Oracle 10g Advanced Security http://download.oracle.com/docs/cd/B19306_01/network.102/b14268/asotrans.htm#CHDCGBEA Oracle 11g Advanced Security Guide http://download.oracle.com/docs/cd/B28359_01/network.111/b28530/asotrans.htm#CJADBFGF Oracle Advanced Security Transparent Data Encryption Best Practices; August 2009 (version 11) Peter A. Wahl PCI Standards www.pcisecuritystandards.org/security_standards/pci_dss.shtml