Contingency Access to Enterprise Encrypted Data

Transcription

1 T E C H N I C A L W H I T E P A P E R WP 700.xxxx

2 Table of Contents No option to escrow Passphrase protection zseries example Incorporating contingency key in zseries Windows command line example Incorporating contingency key in Windows Server Administrative policies in the enterprise Contingency keys in operation Summary

3 Contingency Access to Enterprise Encrypted Data Planning for contingency access to enterprise-encrypted data is an essential element of a carefully provisioned corporate security policy, argues Joe Sturonas, Chief Technology Officer at PKWARE. Organizations are beginning to focus on data encryption from both an enterprise data center and employee perspective. Mainframes, midrange servers and Windows /UNIX /Linux servers have been encrypting data for some time. However, now that desktops and laptops are using strong data encryption methodologies, the question of contingency access has risen up the corporate agenda - after all, an enterprise should always be able to access its own data. No option to escrow Password encryption is becoming more prevalent as organizations are implementing varying levels of data security. Unlike PKI-based encryption, standard password encryption has no centralized key escrow capability. This can put companies at risk of non-compliance with laws and regulations for timely data recovery in the case of an audit, or if an employee forgets a password. This piece addresses the use of contingency keys as a way to enable widespread password-based data protection and at the same time ensure organizations retain access for audit purposes. Security has rightfully gained significant media exposure. While encryption methods are most often used by authorized personnel, they can also be used for devious means. Several security breaches have occured in the past few years, including those resulting from the loss of discs, laptops, or smart devies. Regardless of the type of security breach, the bottom line is, protecting sensitive data is crucial. For example, Bob, a sales associate who is frustrated with his position, decides to join a competing company. Before he leaves his existing company, he exports the entire customer list with all of his current company s customer names and addresses. He s this file to his home account, but since he suspects that his IT department is logging inbound and outbound s, he decides to password encrypt the customer address file before he sends it. Several weeks later, Bob s previous employer learns that Bob s new company is contacting all their customers, which is starting to impact business. Suspecting foul play, Bob s old IT department starts to search through his old computer and history. Preceding his departure, they identify an with a large file attachment that was sent to his home account. As Bob has encrypted the file, the IT department is unable to access it. Passphrase Protection Bob s former IT department tries everything, even password cracking programs to launch an exhaustive dictionary search to determine the password that Bob used. After several days they realize that Bob used a very strong passphrase to protect his data. As a result, Bob s old company fails to uncover hard evidence that Bob did anything wrong and his new company continues to contact their customers. At this point, Bob s old IT department realizes that they don t have as much control of their data as they thought they did. 3

4 Encryption can be used to protect data, but as demonstrated in the previous example, if encryption is not controlled by some type of policy, it can be used to hold data hostage. The implementation of a contingency key is one way to enforce policy over enterprise data. A contingency key is an organizational public key that is automatically used whenever data is encrypted. Whether the data is being encrypted with password- or certificate-based encryption, the contingency key is always being used to encrypt the data. Therefore, if the enterprise ever needs access to the encrypted data, a security official in the organization can use the private key to decrypt data whenever it is needed. Public-key cryptography overview Public-key cryptography provides a solution to the shared secret key encryption problem. Once the data has been encrypted with the secret key, how do you securely share the secret key with other parties that need access to the data? Public-key cryptography involves the use of a pair of keys, a public and private key that are mathematically related. When a public/private key pair is generated, they are linked together. The public key is used for encryption and the private key is used for decryption. The public key can be given out freely to anyone you would want to encrypt data for you. The private key must be kept secure and given to no one that you would not want decrypting your data. Public keys are typically distributed in the form of an X.509 public key certificate. Public key certificates come from a Certificate Authority (CA), which binds an individual to a given public key. The CA ensures the person who requested the public key is who they say they are and, through digital signatures, binds the public key in the certificate. When references are made to certificate-based encryption, they are referring to using a public key from an X.509 certificate. Multiple public keys can be used to encrypt data, but only a single private key is required to decrypt the data. Encryption software such as SecureZIP allows for a mix of password and certificate-based encryption. This is important to the concept of a contingency key because if someone just encrypts with a password, a contingency key would also need to be included in the encryption operation. 4

5 zseries example SecureZIP operates on all major platforms, but we will look at zseries and Windows Server command line to show examples of some basic data encryption operations. These examples don t cover some of the setup steps that are required for brevity, but rather go directly into the operational examples. One of the most common uses for data encryption on zseries involves encrypting database backups before they are sent offsite for disaster recovery or archive retention. This example takes a look at incorporating SecureZIP into an existing DB2 backup with minimal impact. We will focus on a common DB2 image copy scenario that makes full image copies for a local and recovery site. In Figure 1, the box on the left shows a DB2 full image copy procedure that creates two parallel copies, one for the local site and one for the recovery site. The box on the right represents an added step to secure the remote copy. In this step, SecureZIP compresses and encrypts the copy into a ZIP archive. This protects the copy onsite, in transit, and at the recovery site. As shown in Figure 2, this example uses public key encryption. A backup encrypted with the public key can be decrypted only by applying the private key. The owner of the key pair (DB2 administrator, in this case) keeps the private key in his or her own possession and publishes the public key (e.g. to an LDAP server) so that it is available to anyone who needs to encrypt data. With the public key, anyone can encrypt database backups, but only the DB2 administrator (or a delegate having access to the DB2 administrator private key) can decrypt them. The jobstream in Figure 2 encrypts a DB2 image copy of the CUST01 tablespace in the DSNDB01 database. The procedure has two steps: 1) make the copies; and 2) encrypt the copy for the remote site. In this example, ENCRYPTION_METHOD(BSAFE_AES256) specifies the RSA BSAFE version of the AES 256-bit encryption algorithm. The Advanced Encryption Standard (AES) algorithm is the latest generation of encryption standards used by the US Government. SecureZIP supports three key sizes for the AES algorithm: 128-, 192- and 256-bits. Longer key sizes make for greater security. 5

6 RECIPIENT (LDAP:CN-REMOTESITE*) specifies a recipient search. A recipient is the owner of a key pair. We are searching for the digital certificate that contains the recipient s public key that we will use to encrypt the database backup. In this case, we are searching for the public key certificate that starts with a common name of REMOTESITE. When the example is run, it first creates the image copy and then encrypts the database backup into the compressed archive DB2.BACKUP.CUST01.RB.ZIP. Only the recipient owner of the REMOTESITE private key can decrypt the backup. Incorporating contingency key in zseries There are basically two ways to implement contingency key in the zseries example, directly and indirectly. To directly include a contingency key in Figure two, you simply need to include a MASTER_RECIPIENT command. To indirectly include a contingency key, it is necessary to provide the contingency key in the defaults module that is assembled and included with every SecureZIP job. The defaults module, ACZDFLT, is a data-only CSECT that is used to generate the table data. Windows command line example Sticking with a database backup theme in the Windows command line, this example shows a Transact-SQL procedure used to back up an SQL Server database to a disk device. SecureZIP provides a command-line interface for easy process integration and can be used to backup SQL Server in a number of ways. The Transact-SQL procedure shown illustrates a common case. The example assumes that the disk backup devices have already been created using the following commands. These commands need to be executed only once. Once the backup devices have been created, the Transact-SQL backup procedures can be executed as usual. These procedures can be stored by SQLAgent or batch processes executed by ISQL. 6

7 The image on the left hand side of Figure 3 shows the backup procedures for the existing backup. The procedure on the right is added to compress and encrypt the database backups and transaction log backups. Compression makes the encryption process more efficient by reducing the amount of data to be encrypted. This can reduce the overall time needed, minimizing the impact on the backup window. By default, SecureZIP compresses the database backups before encrypting them. This is significant because database backups usually have a very high compression ratio, so compressing them first greatly reduces the amount of data to encrypt. For example, if a 1.5MB pubs database backup yields a not unreasonable compression ratio of 89.7%, the resulting encrypted ZIP archive is only 155KB. After the data encryption procedure is complete, the encrypted archive can be sent to a remote site, or another database backup can be added to the archive. This example, like the previous one, uses asymmetric, public key encryption. The owner of the key pair (the SQL Server administrator) holds the private key and publishes the public key so that anyone can use it to encrypt database backups, but only the holder of the corresponding private key can decrypt the backups. The procedure to back up the pubs database in the example and to compress and encrypt the subsequent backup device is given below. In this example, we run SecureZIP in the SQL Server XP_CMDSHELL extended stored procedure. We encrypt with the backup certificate located on the LDAP server located at , port 389. The resulting encrypted archive is located at: c:\sqldata\mssql\backup\pubsbackup.zip, identified by the backup device c:\sqldata\mssql\ BACKUP\PubsBackup.bak. The procedure to back up the Pubs transaction log and compress and encrypt the backup device is shown below. 7

8 Like the database backup, the backup of the transaction log is executed using the SQL Server extended stored procedure XP_CMDSHELL and is encrypted with the certificate. Incorporating contingency key in Windows Server Including a contingency key in Windows Server command line (which is also roughly the same process for SecureZIP for UNIX) involves a separate program called the PKWARE Policy Manager. The Policy Manager is a tool included with the SecureZIP Server which enables administrators to define contingency keys that are contained in a policy file. We are creating a policy file that contains the certificates for the contingency keys to use. To define the certificates to be used as contingency keys, we need to start the Policy Manager and define a new policy: When New is clicked, we will begin to define the policy. For the server, we are just concerned with the Contingency Keys tab, where we can choose the certificate that is desired. 8

9 Administrative policies in the enterprise We have looked at examples where contingency key can be incorporated into mainframe and server platforms, which typically exist in a controlled environment. To come full circle and discuss the situation where Bob was able to encrypt data that his IT department could not access, we need to discuss administrative policy on the desktop. A policy defines a particular set of configuration options for use by SecureZIP when compressing, encrypting, and digitally signing files and attachments on the Windows Desktop. SecureZIP enforces a policy by locking selected options to specified settings. Policies are administered by means of a Microsoft Management Console (MMC) snap-in application - the Policy Manager. The Policy Manager makes it easy to manage multiple policies appropriate for different organizational roles from a single MMC interface. If a policy needs to be modified, changes can be made and distributed to end-users smoothly and efficiently. When SecureZIP for Windows Desktop options are locked, the controls (such as check boxes) for setting the options are disabled and greyed on client machines, preventing the end-user from changing the settings. Controls for options that are incompatible with locked settings are also disabled. One way that Bob s former IT department could have prevented the data hostage situation would have been to deploy a SecureZIP desktop policy with a contingency key. Contingency keys in operation Within an organization, it is certainly conceivable that more than one contingency key would be in use. For example, there could be an organizational contingency key that would be included in every encryption operation, but then each department could also have their own contingency key that could be segregated by departmental policy. This would give each department the authority to decrypt at their own level, without involving the security administrator at the enterprise level. Contingency keys would also not have to differ at the platform level. Each platform could operate using the same contingency keys at the enterprise and departmental level. Summary We have discussed an example where uncontrolled encryption can be harmful to an organization. Contingency keys provide a mechanism by which an organization can keep control of the data within the enterprise. We looked at some common use cases for encryption and how contingency keys can be incorporated into those scenarios with little or no impact to the operation. Contingency keys in operation have no platform boundaries or restrictions. It is possible for an enterprise to achieve contingency access to data even when the end-user is employing password-based encryption, because the contingency key is still included in the encryption operation. United States 648 N. Plankinton Ave. Suite220 Milwaukee, WI PKWARE UK/EMEA Crown House 72 Hammersmith Road London W14 8TH United Kingdom APAC Cerulean Tower 15F 26-1 Sakuragaoka-cho, Shibuya-ku Tokyo Japan PKWARE, Inc. All rights reserved. PKWARE, PKZIP, SecureZIP, and SecureZIP Mail Gateway are trademarks or registered trademarks in the U.S.A. and other countries. Any other trademarks are used for identification purposes only and remain the property of their respective owners. 9