44 Part I: Oracle Database Security New Features TDE Caveats Column-level TDE encrypts and decrypts data at the SQL level, making it transparent to the end user. As a result, several database features that access data at the kernel level are incompatible with column-level TDE. Using change data capture (both synchronous and asynchronous), streams (in 10g), materialized views, transportable tablespaces, and LOBs are not possible if they include objects containing encrypted columns. These limitations disappear with tablespace encryption available in 11g, as you will see in the next section. Another potential drawback in TDE’s column-based encryption is that it cannot be used in certain types of indexes or in the definition of a primary key/foreign key (PK/FK) relationship. Indexes built on encrypted columns are created using the encrypted values stored in the column. As a result, use of an index is possible for an equality match provided that the encryption was defined using the “no salt” option. The index will not be used, however, in queries that do a range scan. In fact, you will not be allowed to create an index on a column encrypted with the salt directive (failing with ORA-28338: cannot encrypt indexed column[s] with salt). In the case of PK/FK relationships, since each table is encrypted using its own table-level key, the keys are different among tables and, therefore, the encrypted values for similar strings are different. In this process, the relationship that existed between the data is lost without first decrypting the column. While many will argue that natural keys (those that are managed outside of the application, such as SSNs, employee IDs, or stock numbers) are not good candidates as primary keys for establishing uniqueness in a table, the fact is they are and have been used as primary keys and are often found in applications that have, over time, been ported from other database environments. As such, dealing with PK/FK relationships in application that require the protection offered by TDE presents a special problem with column-level TDE. This limitation is addressed in version 11g with the introduction of a new capability: tablespace encryption. Tablespace Encryption: New with Oracle 11g It is obvious that some very real business problems are satisfied by 10g’s column-level encryption capability. In a separate subset of use cases, column-level encryptions limitations make it more challenging to encrypt individual data elements to achieve the desired outcome and balance of security and performance. For instance, many times you might find that an existing application was built to use the most sensitive information as a primary key. Packaged applications often present this problem, and you have little control and limited in-depth knowledge of their data relationships. In such cases, when faced with the challenges of the PCI-DSS or with new privacy legislation such as California’s SB 1386 all organizations’ healthcare providers must make substantial investments in cataloging, analyzing, and remedying potential leaks for personal health information (PHI) or personally identifiable information (PII). Consider an insurance company’s claims system. Applications use the employee’s SSN as the primary key for the insured record. It stands to reason that they would use the insured’s SSN as part of the dependant’s record foreign key. As application developers and data architects Chapter 2: Transparent Data Encryption 45 become more security conscious, this situation becomes far less likely, but it still happens. To remedy this in 10g would have required a redevelopment effort to create a new, noncanonical, primary key. Using the tablespace encryption feature of 11g, it is possible to move all data considered to be PHI or PII into an encrypted tablespace without needing to redesign the application. Additionally, features such as streams and change data capture are again available when dealing with an encrypted tablespace, making it a good candidate for use in a wider variety of applications than column-level encryption. Once the tablespace in created, anything stored in it will be encrypted using the algorithm specified at definition time: system@AOS> CREATE TABLESPACE ts_encrypted 2 DATAFILE '/home/oracle/product/11.1.0/oradata/aos/TSE_encrypted.dbf' size 400K 3 AUTOEXTEND ON 4 ENCRYPTION USING 'AES192' 5* DEFAULT STORAGE(ENCRYPT) system@AOS> / Tablespace created. The tablespace TS_ENCRYPTED is then created using the 192-bit AES algorithm. This is confirmed with a look at the v$encrypted_tablespaces view: system@AOS> SELECT TS.name, ET.encryptedts, ET.encryptionalg 2 FROM v$tablespace TS, v$encrypted_tablespaces ET 3 WHERE 4 TS.ts# = ET.ts#; NAME ENC ENCRYPT TS_ENCRYPTED YES AES192 system@AOS> Oracle 11g Configuration In addition to tablespace encryption to protect entire collections of tables and their indexes, other enhancements have been included in Oracle Database 11g. Support for TDE has been built into Enterprise Manager’s database control graphical user interface (GUI), shown in Figure 2-8. The management of the wallet is now presented with a more intuitive GUI (a bit more intuitive than the SQLPLUS prompt). This allows for creating, opening, closing, and regenerating the TDE Master Key. The option for both closing the wallet and regenerating the Master Key are found under Advanced Options and appear as shown in Figure 2-9. While the ability to create, open, and close a wallet are still available at the SQLPLUS prompt, you can now accomplish this without ever leaving the database management console. 46 Part I: Oracle Database Security New Features FIGURE 2-8 Enterprise Manager database control FIGURE 2-9 Closing and rekeying the wallet under Advanced Options Chapter 2: Transparent Data Encryption 47 TDE to Address PCI-DSS In an effort to thwart the theft and misuse of credit card information (card numbers, cardholder name, and expiration date), major credit card companies have agreed on a set of standards to govern the storage and management of credit card data. The PCI-DSS comprises six control objectives, sets of related requirements. The industry standard is an evolution of the initial Cardholder Information Security Program (CISP) developed by Visa in 2001 to protect cardholder data, wherever it resides. MasterCard’s Site Data Protection Program (SDP) was announced in the spring of 2001 to “assist online merchants in defending against Internet hackers.” PCI requires merchants and member service providers (MSPs) who process, store, or transmit cardholder information to adhere to the following control objectives: Build and maintain a secure IT network. Protect cardholder data. Maintain a vulnerability management program. Implement strong access control measures. Regularly monitor and test networks. Maintain an information security policy. If you use a credit card in your day-to-day business, you are already familiar with the primary data elements involved in the DSS: Primary account number (PAN) Cardholder’s name Service code (a three- or four-digit number on the magnetic stripe that specifies the acceptance requirements and limitations for magnetic-stripe read transactions) Expiration date These elements are all permitted to be stored on automated systems under the PCI standard. The primary account number is special when developing a PCI strategy, as only when this account number is stored, processed, or transmitted by an organization does PCI apply. By using the PAN, like most organizations that accept credit cards as a form of payment or authentication of identity, you must comply with the PCI-DSS requirements. Requirement 3 of the Digital Security Standard for the PCI regulation deals with the storage and protection of cardholder data and is the requirement most directly addressed by the functionality of TDE. Consider the following language in the DSS: Requirement 3 of the DSS – Protect Cardholder Data Encryption is a critical component of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 48 Part I: Oracle Database Security New Features 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. AND To minimize risk, store only those data elements needed for business. NEVER store the card verification code or value or PIN verification value data elements. Section 3.4 of the DSS goes on to advise that the PAN (at a minimum) must be rendered unreadable anywhere it is stored using one of the following approaches: Strong one-way hash functions (hashed indexes) 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. Organizations are looking at the available options to protect credit card data as required to maintain day-to-day operations and comply with the DSS. All who accept and store credit card data must comply or lose the ability to accept card transactions—be it an online retailer, a traditional brick-and-mortar store, a local utility that stores credit card data for its monthly ePayment system, or a state’s department of transportation storing credit card information for its customers who are billed for toll usage. Luckily, protecting this valuable data can be accomplished in many ways. The primary benefits of using TDE to help with a PCI-DSS–compliance strategy are threefold. First, implementing the encryption to support PCI doesn’t require much, if anything, from the developers regarding changes to the application. The real work, encrypting/decrypting the data and managing the key storage, is handled by the database. The setup requires only a few cycles of a DBA and doesn’t necessarily impact day-to-day operations for other administrative staff. Second, because the encryption occurs within the database engine and not the application, it doesn’t matter if multiple applications are accessing the same data—again, since the database handles the process transparently. Last, if you were to build your own encryption logic into your application, storage of the keys used to encrypt the credit card information must be stored somewhere. Where to store these keys becomes a chicken-or-the-egg paradox, since the keys would need to be stored at a location this is accessible to the applications that need them. If the keys and the encrypted data are colocated, the protection offered by encrypting the credit card information is greatly diminished, since the security of the storage is a main consideration in the first place. For instance, you may never store Credit Verification Values (CVVs—CVV2 for Visa, CVC2 for MasterCard, and CID for American Express). Those elements that may be stored—card number, expiration date, and cardholder’s name—must use protection (such as encryption) to secure the data. ■ ■ ■ ■ ■ Chapter 2: Transparent Data Encryption 49 Operational Concerns TDE, as you know, protects data at rest with a high level of assurance. Data, however, doesn’t rest all the time. As organizations use data, other requirements come into play and data gets moved in a variety of ways. Organizations move data from production to development environments, it is loaded into data warehouses from source systems, it gets replicated to offsite disaster recovery locations, it is moved temporarily to make administrative changes to systems, and it must sometimes be moved as a result of hardware changes. When moving data is a requirement, you cannot simply discard the security you’ve used to protect your data; instead, you must extend that security to these new processes and procedures. To accomplish the move in a secure fashion, you must think about data security (is it clear or ciphertext?) and communication channel (network, file movement, and so on). Data Guard with TDE Oracle Data Guard allows you to maintain a copy of the database at a secondary location that is periodically updated with changes made to the primary database by transmitting redo logs. When used in conjunction with column-level encryption of TDE, both physical and logical standby are possible and any data encrypted in the primary database is also encrypted in the redo log. Since physical standby moves redo logs from the primary to secondary database and then applies them directly, the wallet does not need to be opened because the data in the shipped log files has already been encrypted and can be applied in its encrypted form. Logical standby moves data from the primary to secondary location in the redo log, but in contrast, it applies the changes to the secondary database using a process called SQL Apply. Since SQL Apply must read the log files before applying the changes at the secondary location, an Oracle Wallet with the same Master Key as the primary must be both present and open. Performance Most customers’ second question after, “How does TDE work?” is, “What effect will this have on the performance of my database systems?” These are both certainly fair questions. Everyone is trying to maximize their resources, get the most out of their hardware, and keep a user community satisfied with their experience using applications that the database supports. So they are disappointed to hear that while the first question is easy to answer (you’ve already got a pretty good idea of the mechanics), the answer to the second question usually starts with something like, “It depends…,” followed by a less than satisfying conversation. The truth is, that answer depends on a number of factors—index participation for candidate columns, current system performance, number of tables having encrypted columns, and the raw number of rows in the average transaction having encrypted columns. Once these are understood, it becomes apparent that applications fall into two categories: “minimal effects” or “drastic effects.” Most applications fall into the first category, and TDE can be used successfully, especially if an upgrade to 11g is an option. Since arithmetic operations are always used when encrypting and decrypting, and despite the fact that implementations use encryption algorithms designed for efficiency and elegance, they slow system actions by taking processing power from other tasks. When used to encrypt varchar2 data in 10–20 character columns, TDE averages a 5–8 percent performance impact regarding single query performance. Reports of performance degradation can generally be attributed to 50 Part I: Oracle Database Security New Features index build failures after encrypting or to an application using LIKE, BETWEEN, or other functions needing an index to perform well. Be sure to test applications thoroughly after encrypting any column to gauge the impact of encryption adequately, as you would when making any signification change. Using column-level encryption a 10g or 11g environment, the following course of action helps minimize risk, if an outage is permissible during the implementation: 1. Identify candidate columns for encryption (credit card number, national identifiers, and so on). 2. Ensure that these are TDE supported datatypes. 3. Ensure that the column doesn’t participate in an index. 4. Ensure that the column is not part of a PK/FK relationship. 5. Encrypt the column(s). 6. Reorganize the table. If an outage is not permissible during the implementation, follow these steps: 1. Identify candidate columns for encryption (credit card number, national identifiers, and so on). 2. Ensure that these are TDE supported datatypes. 3. Ensure that the column doesn’t participate in an index, 4. Ensure that the column is not part of a PK/FK relationship. 5. Use online reorganization or modify the table as shown in the “Encrypting an Existing Column” section earlier in this chapter, as it locks the tables (both old and new) for only the period of time it takes to rename the tables. By creating a very simple test case on a table with 100,000 rows of credit card data, and running a set of timed queries to select values from the columns, we are able to measure the effects of encryption versus a standard unencrypted query. It turns out that the query against encrypted data takes slightly longer than a query on unencrypted data, as long as both are indexed (see Figure 2-10). The difference between queries run on a nonindexed, unencrypted column and those on an indexed, encrypted column are much more significant. This once again highlights the need for good tuning and design of our index strategy for systems requiring quick response times. Since column-level encryption has the limitations mentioned earlier, not every application is a good fit for its use. This can be due to need for index use such as ranges, PK/FK relationships or nonsupported datatypes. In these cases, tablespace encryption provides good alternative, removing these restrictions and encrypting at course granularity. The process for migrating to tablespace-level encryption in an Oracle 11g environment can be best described as follows: 1. Identify tables containing sensitive columns. 2. Create a new encrypted tablespace. Chapter 2: Transparent Data Encryption 51 3. Move tables from an unencrypted to encrypted tablespace using ALTER TABLE customer MOVE TABLESPACE encrypted_customer;. The other area of performance to consider is storage. Column-level TDE takes more space for each encrypted column (17–51 bytes per column). This additional space is the result of three things: padding required by the algorithm, Message Authentication Code (20 bytes), and salt (16 bytes). To minimize the amount of additional storage consumed by using TDE, consider using the NO SALT and NOMAC directives when encrypting columns. When you’re dealing with relatively minor sizes (36 bytes seems very small today), it’s easy to forget that in cases of large data volumes, these can add up. For a table with one encrypted column and 2 million rows, it is only 68 megabytes, but for customer with large data sets it can become daunting (with 7 billion rows, the additional 240 gigabytes could be an issue). When faced with multiple candidate columns stored in each of multiple tables, large databases must account for storage requirements in planning and testing. FIGURE 2-10 TDE timings unencrypted nonindexed versus encrypted with index 52 Part I: Oracle Database Security New Features Exporting and Importing Encrypted Data Moving data out of one system and into another is one of a DBA’s many tasks. Generally, tools such as traditional export/import or the newer Data Pump are used to perform this task. Export does not support tables with columns encrypted with TDE. Attempting to export the example customer_enc table shows this incompatibility: [oracle@aosdb ~] (aos-db)$ exp sh/oracle11g tables=customer_enc Export: Release 11.1.0.6.0 - Production on Sat Aug 23 13:30:19 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real Application Testing options Export done in US7ASCII character set and AL16UTF16 NCHAR character set server uses WE8MSWIN1252 character set (possible charset conversion) About to export specified tables via Conventional Path EXP-00107: Feature (COLUMN ENCRYPTION) of column CUST_CREDIT_CARD_NO in table SH.CUSTOMER_ENC is not supported. The table will not be exported. EXP-00091: Exporting questionable statistics. Export terminated successfully with warnings. [oracle@aosdb ~] (aos-db)$ Instead, TDE support is built in to Oracle Data Pump. Data Pump, like its predecessor, export/ import, allows administrative users to pull data from a table, store that data in a file on the filesystem, and then pull the data from a datafile back into a table (on the same or another system). Data Pump will export data in cleartext, but it can then encrypt (using a new key) the resulting dump file. Using the Data Pump to export TDE-encrypted table data allows administrators to move data, but you must remember that the data is decrypted by Data Pump and will be stored in the filesystem as cleartext. oracle@aosdb ~] (aos-db)$ expdp system/oracle11g DUMPFILE=exports:customer_enc.dmp tables=sh. customer_enc Export: Release 11.1.0.6.0 - Production on Saturday, 23 August, 2008 14:07:01 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real Application Testing options Starting "SYSTEM"."SYS_EXPORT_TABLE_01": system/******** DUMPFILE=exports:customer_enc.dmp tables=sh.customer_enc Estimate in progress using BLOCKS method Processing object type TABLE_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 64 KB Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS . . exported "SH"."CUSTOMER_ENC" 8.843 KB 7 rows ORA-39173: Encrypted data has been stored unencrypted in dump file set. Master table "SYSTEM"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded ********************************************************************** Dump file set for SYSTEM.SYS_EXPORT_TABLE_01 is: /tmp/exports/customer_enc.dmp Job "SYSTEM"."SYS_EXPORT_TABLE_01" completed with 1 error(s) at 14:07:12 [oracle@aosdb ~] (aos-db)$ Chapter 2: Transparent Data Encryption 53 Fortunately, Data Pump reminds you that the data is now unprotected with the error message “ORA-39173: Encrypted data has been stored unencrypted in dump file set.” This process makes it easy to move data from one system to another without your worrying about having the same Master Key available when importing, but it again puts your data into the “unprotected medium” over which you have little control. Luckily, Data Pump includes a feature that allows you to encrypt the resulting file using the ENCRYPTION_PASSWORD option: [oracle@aosdb ~] (aos-db)$ expdp system/oracle11g DUMPFILE=exports:customer_enc_protected.dmp TABLES=sh.customer_enc ENCRYPTION_PASSWORD='AppliedOracleSecurity' Export: Release 11.1.0.6.0 - Production on Saturday, 23 August, 2008 14:15:07 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real Application Testing options Starting "SYSTEM"."SYS_EXPORT_TABLE_01": system/******** DUMPFILE=exports:customer_enc_protected.dmp TABLES=sh.customer_enc encryption_password=******** Estimate in progress using BLOCKS method Processing object type TABLE_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 64 KB Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS . . exported "SH"."CUSTOMER_ENC" 8.851 KB 7 rows Master table "SYSTEM"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded ****************************************************************************** Dump file set for SYSTEM.SYS_EXPORT_TABLE_01 is: /tmp/exports/customer_enc_protected.dmp Job "SYSTEM"."SYS_EXPORT_TABLE_01" successfully completed at 14:15:14 [oracle@aosdb ~] (aos-db)$ The password provided by ENCRYPTION_PASSWORD is used to encrypt the resulting file, customer_enc_protected.dmp. It can then be imported only by providing the password. Integration with Hardware Security Modules When using TDE functionality, you will in turn be using an Oracle Wallet. As TDE uses the Oracle Wallet to store and generate Master Key values to encrypt table keys and ultimately data, it does so in a simple file-based manner. As mentioned earlier, the generation of the encryption wallet sets the wallet password and generates a Master Key that is then stored in the Oracle Wallet using PKCS #12. Some customers must conform with strict policy or procedural mandates with respect to management of their encryption keys. In very highly protected (professionally paranoid) customer environments, it is considered more secure to manage keys in a hardware device (HSM) rather than on a file system. For those faced with such challenges, Oracle 11g TDE introduced the ability to integrated TDE functionality with the Key Management and Key Backup capabilities of an HSM device. Several third-party vendors produce an Oracle TDE-certified HSM devices, with more being added to the certified list every month. These devices manage several aspects of everyday management of encryption keys. First, they are built to manage the encryption keys inside the device from generation to disposal. This is important, because to keep keys protected, you need to develop good policy and process for backup, restoration, and use of cryptographic keys from all the . physical and logical standby are possible and any data encrypted in the primary database is also encrypted in the redo log. Since physical standby moves redo logs from the primary to secondary database. 2007, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real. 2007, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real