Reprinted with Permission by Quest Software Sept. 2007

Data Security Beyond Regulatory Compliance
by Ulf Mattsson

Protecting sensitive data in a distributed environment.

In increasingly complex technical and business environments, no one security approach can deal with all the new and innovative intrusions. But the lack of a security silver bullet doesn't mean data security is impossible. It simply means that businesses have to take a multi-pronged approach to data security.

Today, enterprises must comply with industry and government regulations that require businesses to ensure the security of sensitive information. At the same time, databases are at increased risk from both internal and external attackers who no longer simply seek notoriety but, instead, want financial rewards.

Although layered approaches are required, there is one truth in data security: The sooner sensitive data gets encrypted, the more secure the environment. Early data encryption will protect sensitive data at rest and while it’s moving between the applications and databases and between different applications and data stores.

As databases become networked in more complex e-business applications, their vulnerability to attack grows. Without extra precautions taken to secure the confidential data in databases, your company’s data privacy is at risk.

For companies to avoid the nightmare of a public breach of customer privacy, organizational accountability must be established and supported by policies and processes that enforce compliance to standards and regulations.

A Database Security Strategy

Much attention has been focused on network attacks by crackers, and how to stop these. But the vulnerability of data inside the database is somewhat overlooked. Databases are far too critical to be left unsecured or incorrectly secured.

Most companies solely implement perimeter-based security solutions, even though the greatest threats are from internal sources. And information is more often the target of the attack than network resources.

The best security practices protect sensitive data as it's transferred over the network (including internal networks) and when it's at rest. One option for accomplishing this protection is to selectively parse data after the secure communication is terminated and encrypt sensitive data elements at the SSL/Web layer. Doing so allows enterprises to choose at a very granular level (usernames, passwords, and so on.) the sensitive data to secure throughout the enterprise. Application-layer encryption and mature database-layer encryption solutions allow enterprises to selectively encrypt granular data into a format that can easily be passed between applications and databases without changing the data. I'll focus on database-layer encryption in this article.

Data Encryption

The sooner data encryption occurs, the more secure the information is. Due to distributed business logic in application and database environments, organizations must be able to encrypt and decrypt data at different points in the network and at different system layers, including the database layer. Encryption performed by the DBMS can protect data at rest, but you must decide if you also require protection for data while it’s moving between the applications and the database and between different applications and data stores. Sending sensitive information over the Internet or within your corporate network as clear text defeats the point of encrypting the text in the database to provide data privacy.

DB2 Encryption Challenges and Solutions

A common misconception about DB2 and security concerns the value of encryption versus the traditional methods that DB2 uses to keep data secure from unauthorized usage. The best defense comes from a combination of encryption and the more traditional methods available through DB2 and the Resource Access Control Facility (RACF) for z/OS environments. DB2 and RACF work together to ensure that only authorized users can access DB2 data; however, those security measures are ineffective against a person who can circumvent the operating system.

RACF for access control has significant policy and people implications. If you want the database administrators to manage security, then integration with DB2 is very important. If you want security administrators to manage security, then integration with the security server is more important. As you make this change, note that roles will change and authorities will change. The implementation team needs both DB2 and RACF knowledge for implementation.

In many industries encryption is a growing requirement to satisfy the need for data security. In some industries, regulations impose a security requirement best met by data encryption. Financial services, health care, and defense have very different statements of security objectives, but some of the same principles apply. Technical challenges associated with encryption include application changes, performance overhead, and the difficulties of managing the encryption keys. DB2 and the System z platform provide the basis for meeting these challenges with hardware, software and third party products. (For information about protecting your data in a DB2 for Linux, Unix, and Windows environment, read the article "DB2 Data Security: The Naked Truth.")

DB2 Data Encryption Methods

Consider these fundamentally different methods to encrypt DB2 data on z/OS:

Encryption means some tradeoffs in function, usability and performance. In some cases, the indexes aren't encrypted; in others, encrypted data won't give correct results for comparisons other than equals or not equals. A balanced use of FIELDPROC, EDITPROC and UDF can handle most tradeoffs in an optimal way. All greater than, less than and range predicates aren't usable. FIELDPROC provides additional protection if credit card numbers are indexed. Both methods use the cryptography hardware on IBM platforms. UDF implementations provide support for additional and longer data types and additional search operations. DB2 9 for z/OS enables a fully application transparent use of UDF implementations. DB2 8 enabled a fully application transparent use of UDF implementations for Linux, UNIX, and windows.

DB2 Column- or Row-Level Encryption

With EDITPROC, encryption/decryption of the entire row is always performed regardless of sensitive columns that may be referenced in the query. This process can be costly for large rows and for queries that are searching on non-sensitive columns because decryption happens for every row accessed during SELECT even if data fails. The main disadvantage of the tool encryption solutions for DB2 databases that use EDITPROC compared to encryption solutions that are using FIELDPROC or DB2 native column-level encryption is that indexes aren't encrypted.

If multiple data elements in a table need protection and none are in INDEX, then EDITPROC is less resource intensive then multiple FIELDPROCs. If only one or few columns need protection then only those are encrypted. FIELDPROC can only be specified on short string columns, and can't be specified on ROWID or large object (LOB) columns; however, columns with those data types are allowed in TABLE. FIELDPROC can be added by ALTER TABLE, so there's no need to perform UNLOAD, DROP TABLE, CREATE TABLE, and RELOAD.

DB2 for z/OS V8 column-level data encryption requires extensive application changes. This method also requires that the SQL users supply the encryption key. The chief advantage of DB2’s column-level encryption over table-level encryption tools is that the index is encrypted with the columns; however, DB2 doesn't support native encryption of numeric columns, and the DB2 Load Utility doesn't support this native encryption.

The INSTEAD OF trigger is an SQL technique that allows a trigger to be used in place of a view, which is consistent with DB2 for Linux, Unix, and Windows. Additional overhead can be expected if the search is forcing table scans and decryption of a large number of rows during the search operation. Improved audit selectivity is needed for being able to see that security is functioning. SSL implementation provides encryption of data on the wire. Some additional techniques for data encryption will help protect data at rest and in backups.

Transparent UDF-based encryption is enabled in DB2 9. DB2 UDFs can be called by triggers and views. The enhanced support for these functions in DB2 9 for z/OS provides a higher level of application transparency than earlier DB2 versions. The lack of application transparency in earlier DB2 versions can be an issue when implementing UDF-based encryption. However, UDF-based encryption can be attractive if only a few columns need protection and if additional data type support is needed. UDF-based encryption can also support a wider range of search operations on encrypted columns. Expect additional overhead, in some cases significant, if the search is forcing table scans and decryption of a large number of rows during the search operation.

DB2 UDB 7.2 for Unix and Windows

Functions have been available since DB2 UDB V7.2 (Unix and Windows) to easily integrate data encryption into database applications. This functionality was added to DB2 7.2 by implementing SQL built-in functions that allow the application to encrypt and decrypt data. When data is inserted into the database it can be encrypted using an encryption password supplied by the user. When the data is retrieved, the same password must be supplied to decrypt the data. For situations where the same password is going to be used several times, the ENCRYPTION PASSWORD value can be set using an assignment statement and is valid for the length of a connection.

IBM Data Encryption Tool

IBM Data Encryption for IMS and DB2 databases gives you a tool for IMS and DB2 in a single product. The tool enables you to leverage the power of storage area networks (SANs) safely while complying with privacy and security regulations in place or being enacted worldwide. During encryption, IMS or DB2 application data is converted to database data that is unintelligible except to the person authorized by your security administrator. Sensitive data is protected at the row level for DB2 and the segment level for IMS. Encryption and decryption can be customized at these levels on the respective databases. The tool is implemented using standard DB2 and IMS exits. Data Encryption for IMS and DB2 databases runs as an exit. The exit code invokes the System z, zSeries and System/390 Crypto Hardware to encrypt data for storage and decrypt data for application use, thereby protecting sensitive data residing on various storage media.

IBM Data Encryption for IMS and DB2 databases requires OS/390 or z/OS Integrated Cryptographic Service Facility (ICSF), which only runs on processors that support the IBM Cryptographic Coprocessor Feature (CCF) or the CP Assist for Cryptographic Functions (CPACF). These processors include most modern mainframes, for example, G3, G4, G5, G6, Multiprise 2000, Multiprise 3000, eServer z/Series, and System z, but don't include such machines as the Flex/ES emulator machines. The hardware CCF or CPACF modules must be enabled with configuration data by the local IBM engineer, which is a separately orderable feature and requires a processor power-on-reset (POR) to complete the loading of the data into the crypto modules. Implementing IBM Data Encryption for IMS and DB2 Databases is part of a larger task that must be performed to implement data encryption/decryption.

Without this product, you need to write and maintain your own encryption software or use plug-and-play solutions from third party vendors that deliver solutions that merge the functional advantages of DB2 column-level encryption and the IBM Encryption Tool for DB2 Databases. All of these solutions exploit System z, zSeries and S/390 crypto hardware features, resulting in low overhead encryption/decryption and enabling fast software encryption options.

Cryptographic Hardware

Network-attached cryptographic hardware gives a significantly longer path length to the encryption service and has significantly lower throughput than the use of the IBM native cryptographic hardware when used on typical rows and column sizes.

The performance characteristics of the encryption solution for DB2 databases that are using FIELD PROC or EDITPROC are similar to those of DB2 table space compression. In both cases, the performance impact is much less for OLTP than for queries and utilities. The magnitude of CP cost is similar, and the row size can affect the cost. The degree of processing overhead you experience depends on how your applications access data. The z9 processors are faster than the z990/z890 processors; the IBM cryptographic hardware available on IBM models z900, z800 and earlier 9672 systems are slower. The software encryption should be functionally identical to the hardware encryption, and can be decrypted by the hardware if the site upgrades the hardware later. IBM mainframe hardware models z890, z990, z9EC and z9BC have feature code 3863, which adds cryptographic hardware to the system. Unlike earlier IBM mainframes which had a more limited cryptographic hardware, this hardware is available for each CPU within the box, and the feature code needs to be applied to each CPU by the local IBM engineer in order to turn it on. A mature solution for z/OS should optionally utilize this hardware if available.

If the IBM native encryption hardware isn't available, a mature data encryption solution should enable software encryption and decryption as an alternative. This gives a much shorter path length to the encryption service but it is significantly slower than the use of the cryptographic hardware if used on longer rows and columns.

Performance of Encryption Options

This is a rough categorization of typical differences in the performance overhead using different basic encryption approaches for DB2 databases:

Minimize Encryption Performance Hits

The best solutions minimize performance impact by encrypting only the information that's critical from a security point of view rather than entire tables. Privacy and security mandates and brand protection requirements will define which information requires this higher level of protection and audit. Focusing only on sensitive information optimizes performance and maximizes the usefulness of the encrypted security audit log. The log should contain all relevant operations on critical data elements. For example, a security log should be tamperproof and provide evidence on who read what information and when. Inadequate auditing reduces proper accountability and hampers the process of solving internal or external information breaches. Effective audit trails are crucial to understanding what actions must be taken to protect sets of sensitive data. Logging events directly associated with the sensitive data in the database is essential. A redefinition of the database structure (DDL) to divide tables with sensitive data may also improve the performance.

Cryptographic Coprocessor Facility (CCF)

Before the IBM System z 890 and 990 models, IBM processors supported “secure keys,” which used the CCF. CCF introduced the notions of secure coprocessor and master key. With a secure coprocessor, the application keys are kept outside the coprocessor and encrypted under a master key. The only instance of the master key is inside the coprocessor. When invoking data encryption, the application passes to the secure coprocessor a copy of the application key to use, encrypted under the master key. The coprocessor decrypts the application key inside its physically secure enclosure and proceeds with data encryption. “Secure” in the phrase “secure coprocessor” means that nobody will see the actual value of the application key anywhere outside the coprocessor, whether it is in system storage or on a disk device. Because CCFs were limited to CP 0 and CP 1, any application requiring encryption services needed to be dispatched on either CP 0 or 1. Thus, if many threads required encryption services, contention for these coprocessors could result in significant delays while the majority of the CPs remained underutilized. Because IBM hasn't documented the instructions to use this facility, only IBM utilities can use the hardware directly.

CPACF Reduces CP Time And Elapsed Time

The z990 processor introduced a facility called CPACF, which does not carry the concept of master key and deals only with keys provided in the clear (“clear keys”). CPACF helps reduce both the CP time and elapsed time for encryption. CPACF consists of a new instruction, called KMC, which can execute on any CP. The KMC instruction uses clear keys instead of secure keys and is considerably faster than the older cryptographic instructions that CCF uses. Because this is now a documented instruction, other non-IBM products can use the hardware. Further, you don’t need to re-dispatch an application on a different CP, and because the KMC instruction lends itself to direct use by database subsystems and access methods, KMC enables System z to reduce the software overhead of encryption. Bringing that instruction closer to the application is critical to minimizing the performance cost of encryption, especially with small rows. ICSF and the IBM Encryption Tool for IMS and DB2 Databases support both single DES and Triple DES using clear key encryption. The performance cost of clear key encryption consists of two components. The first component is the overhead, which is largely a software cost, and the second component is a function of the data length, which can be called the hardware cost.

Key Management Solutions

DB2 V8 column-level encryption has the encryption key in a dump of the DB2 master task. In a mature solution, the DB2 subtask should not expose the key in a dump of the DB2 master task. The subtask should only have the key-label, which is not enough to encrypt the data and is meaningless since it’s only the name of the key.

Encryption itself is not a protection against somebody who illicitly gains access to a password, because DB2 will happily decrypt data on behalf of an authorized user. Thus, encryption and userid/password controls are complementary aspects of security, helping to protect against different types of security exposures.

The IBM Data Encryption Tool uses DB2 EDITPROC, and a key label is stored in the EDITPROC. The assignment of an EDITPROC to a table determines which key label to use for the table. ICSF itself determines the key and associates the master key with a key label as well as keeps track of these associations in its own CKDS data set, so the security of the RACF-protected CKDS becomes the very important point for encryption security.

Any program running on z/OS can access the DB2 data sets, unless they are protected. Define userids for the started tasks and prevent almost every other id from accessing the DB2 data sets. There are some exceptions for administrators who must manage the logs or work with the DSN1* utilities. Having separate IDs for each subsystem is the standard recommendation.

Enterprise-level encryption solutions centrally manage the encryption keys across all different platforms and then use proprietary logic to invoke CPACF. Point solutions for the mainframe like the IBM Encryption Tool for IMS and DB2 Databases uses the PCIXCC or Crypto Express2 coprocessors to secure the key with the master key, then use proprietary logic to invoke CPACF.

Multilevel Security or Mandatory Access Control (MAC)

Z/OS 1.5 and RACF or Security Server 1.5 (improved in 1.6) add another type of security, called multilevel security, labeled security or mandatory access control (MAC). The only option in the past with a high degree of separation has been physical separation. In the database world that might mean another machine or LPAR or perhaps another subsystem, another database or another table. With multilevel security, we still have a high degree of security even with data in the same table. Access control is consistent across many types of resources using RACF, so that multilevel controls apply for data sets, for communications, for print and for database access – both objects and now with row level granularity. The DB2 controls are for both SQL access and for utility access.

Trusted Security Context for Connections

A system parameter can be set to indicate to DB2 that all connections are to be trusted. It's unlikely that all connection types (such as DRDA, RRS, TSO, and batch) from all sources will fit into this category. It's likely that only a subset of connection requests for any type and source may be trusted or that you want to restrict trusted connections to a specific server. More granular flexibility will allow for the definition of trusted connection objects. Once defined, connections from specific users via defined attachments and source servers will allow trusted connections to DB2. The users defined in this context can also be defined to obtain a database role.

DB2 uses the security context when possible, so transactions have security that uses a consistent identification and authentication. This is true for stored procedures from these environments as well. The large number of options, exits, environments and asynchronous or parallel work provide challenges for security. Some key applications manage security at the application level.

Session Variables

Session variables provide another way to provide information to applications. Some variables will be set by DB2. Others can be set in the connection and sign on. The new built-in function GETVARIABLE is added to retrieve the values of a session variable. This function can be used in views, triggers, stored procedures and constraints to help enforce a security policy. If your primary security need is more general, flexible controls, this information complements other security mechanisms. For example, you can have a view which provides data that is at the user's current security label.

Use of Production Data in a Test System

Production data is in many cases needed to ensure quality in system testing. Key data fields that can be used to identify an individual or corporation need to be cleansed to depersonalize the information. Cleansed data needs to be easily restored (for downstream systems and feeding systems), at least in the early stages of implementation. This requires two-way processing. The restoration process should be limited to situations for which there is no alternative to using production data (interface testing with a third party or for firefighting situations, for example). Authorization to use this process must be limited and controlled. In some situations, business rules must be maintained during any cleansing operation (addresses for processing, dates of birth for age processing, names for gender distinction). There should also be the ability to set parameters, or to select or identify fields to be scrambled, based on a combination of business rules. A solution must be based on secure encryption, robust key management, separation of duties, and auditing.

Data Encryption Conclusions

Sending sensitive information over the Internet or within your corporate network as clear text defeats the point of encrypting the text in the database. The sooner the encryption of data occurs, the more secure the environment. The decryption of the data can occur at any point throughout the data flow wherever there is a need for access. This can be done in an application transparent way that with minimum impact to the operational environment. Stronger database security policies and procedures must be in place to accommodate the regulatory compliance environment. Centralized database management security must be considered to reduce cost. Implementing "point" or manual solutions is hard to manage as the environment continues to grow and become more complex. A centralized data security management environment must be considered as a solution to increase efficiency, reduce implementation complexity, and in turn to reduce cost.

There are no guarantees that any one approach will be able to deal with new and innovative intrusions in increasingly complex technical and business environments. However, implementation of an integrated security program which is continuously audited and monitored provides the multiple layers of protection needed to maximize protection as well as historical information to support management decision-making and future policy decisions. Field-level data encryption is clearly the most versatile solution that is capable of protecting against external and internal threats. A protective layer of encryption is provided around specific sensitive data items or objects, instead of building walls around servers or hard drives. This prevents outside attacks as well as infiltration from within the server itself for production data systems and test data systems. This also allows the security administrator to define which data are sensitive and thereby focus protection on the sensitive data, which in turn minimizes the delays or burdens on the system that may occur from bulk encryption methods.

By implementing solutions documented above, we should be in a better position to face growing database security challenges, to proactively meet regulatory and compliance requirements and to better control our sensitive data.

Ulf T. Mattsson is chief technology officer at Protegrity and creator of the company's database security technology. His extensive IT and security industry experience includes 20 years with IBM as a manager of software development and a consulting resource to IBM's research and development organization in IT architecture and IT security.

This article was originally printed in DB2 Magazine.