SafeNet DataSecure vs.

Native SQL Server Encryption

WHITE PAPER

Contents
Executive Summary................................................................................................... 2 Solutions Overview................................................................................................... 2 SQL Server Encryption.............................................................................................. 2 Security and Compliance.......................................................................................... 4 Security of Keys.................................................................................................. 4 Security of Data.................................................................................................. 6 Separation of Duties........................................................................................... 6 Access Control and Leakage Prevention.............................................................. 7 Central Policy Control......................................................................................... 8 Infrastructure Coverage...................................................................................... 8 Integration and Administration................................................................................. 9 Total Cost of Ownership...................................................................................... 10 Set up and Integration......................................................................................... 10 Persistence Support for Cross Platform Applications.......................................... 11 Key Management and Rotation............................................................................ 12 Logging and Auditing........................................................................................... 13 Performance and Availability..................................................................................... 14 Performance....................................................................................................... 14 Availability and Recovery..................................................................................... 14 Conclusion................................................................................................................ 15 About SafeNet.......................................................................................................... 15

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

Executive Summary
Given the vital records databases hold, these systems often represent one of the most critical areas of exposure for an organization. Consequently, as organizations look to comply with security best practices and regulatory mandates, database encryption is becoming increasingly commonand critical. Today, security teams looking to employ database encryption can choose from several alternatives. This paper provides a high level comparison of two approaches: Microsofts native encryption capabilities for SQL Server and the SafeNet DataSecure platform.

Solutions Overview
SafeNet DataSecure SafeNet DataSecure is the only appliance-based data protection solution that features granular, field-level encryption capabilities that can be integrated at the file, Web server, application server, or database layer. By centralizing cryptographic processing, key and policy management, logging, and auditing in a single, hardened appliance, DataSecure maximizes overall security and helps ensure organizations are compliant with a range of security best practices and regulations. DataSecure features a centralized architecture that streamlines security administration and provides superior key and policy life cycle management. Plus, DataSecure can act as an external key management device for third-party encryption offerings. Consequently, organizations employing SQL Servers encryption capabilities can store the cryptographic keys associated with that product, as well as keys for other encryption products, on the DataSecure appliance.

SQL Server Encryption

Microsoft offers several encryption options for SQL Server: Windows BitLocker BitLocker is an encryption solution that provides disk level, sector-based, and bulk encryption of an entire drive or volume. BitLocker provides protection against data access when a machine is turned off, but does not provide any protection once the operating system is started. Information is stored on the disk in encrypted format at all times, which means performance is slowed by approximately 5-10%, even when the client or server is turned on. However, any data requested from the disk is immediately returned in a decrypted format, therefore, during dayto-day operations of database servers, BitLocker introduces significant performance latency without providing any granular data access protection. BitLocker is better suited for non-read/ write intensive usage, such as encryption of file servers or Windows clients, or for protection of hard drives while in transit between sites.

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

Encrypting File System Encrypting File System (EFS) is a file encryption feature introduced in Windows 2000, with additional features and enhancements released in subsequent years. EFS makes it possible for users to encrypt files on their computers, and control who can decrypt or recover these files. EFS uses symmetric keys to encrypt files, and it uses certificates associated with a specific user account to protect the file keys. For EFS to be used safely, an organization must have already deployed a secured public key infrastructure (PKI) with hierarchical certificate authorities (CA), and have the processes and mechanisms in place to securely manage certificates and keys. While EFS is a very robust solution for encrypting files in Windows environments, it is usually not recommended for database file encryption. EFS does not support column-level encryption, which means the entire database file must be encrypted and decrypted while in use. As a result, EFS typically introduces performance degradation of approximately 20 percent, which is especially problematic for large database files. In addition, any user connecting to the database server can access any data in an EFS encrypted database file, regardless of the EFS encryption status. When EFS is used for database file encryption, the EFS encryption keys often reside in the operating system hosting the database server, where they are vulnerable. Additionally, this requires a smartcard or HSM to be connected to each database server, which necessitates additional purchases and administrative complexity. Field-level Encryption SQL Server field-level encryption was introduced in SQL Server 2005 and is also supported unchanged in SQL Server 2008. Field-level encryption supports granular encryption of parts of a database or table by modifying the database schema and moving the data that is to be protected into a binary data type. A set of schema modifications allow the data to be read and updated in an encrypted format after the changes are implemented. Because of the significant performance and manageability impacts of setting up fieldlevel encryption, Microsoft has shifted its main focus in SQL Server 2008 towards transparent database encryption. Microsoft still recommends the use of field-level encryption in SQL 2008 for scenarios in which organizations demand a high degree of data security and access control or granular data access auditing capabilities. Microsoft cautions customers about the performance impacts of field-level encryption because each field needs to be encrypted and decrypted separately on the database server CPU, which degrades performance by 20-40 percent. Transparent Database Encryption Transparent Database Encryption (TDE) is a new capability introduced in SQL Server 2008, and is only available as part of the Enterprise and Developer Editions. TDE uses a hierarchical key management approach that is almost identical to the one employed by Microsofts field-level encryption approach. TDE provides bulk encryption of all the data in a given database. TDE does not enable column or field level encryption at this time. Rather than offering a specifically targeted key and data encryption management console, TDE is tightly integrated with SQL Server and is managed using the same DBA query interfaces and the Transact-SQL language as the database server.

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

Table 1: Data Protection Capabilities

BitLocker EFS Field-Level TDE SafeNet DataSecure

Data Encryption (3DES & AES)

Optional (requires HSM purchase)

Optional (requires HSM purchase)

Encrypted Physical Backup

Column-level Access Policies

Time-based Access Policies

Separation of Duties

Encrypted Logical Backup

Offloaded Encryption (with the key outside of memory) Secure Master Key Storage

FIPS Certified

Central Key Management

Protection for Data Load (ETL) and Direct Database File Access

The table above compares the capabilities of native SQL Server encryption and those of DataSecure.

Security and Compliance

Optimizing security is the ultimate objective of employing database encryption. This section compares the security offered by Microsofts encryption options and DataSecure, comparing such critical areas as key security, and separation of duties.

Security of Keys
Native SQL Server Encryption The single most critical aspect to ensuring that encryption yields the highest level of security possible is the security of the cryptographic keys. Simply put, if keys are compromised, encrypted data is compromised. A key architectural foundation of Microsofts encryption solutions is that cryptographic keys reside on the same database server as the encrypted data. For large organizations with dozens or even hundreds of databases, this means cryptographic keys reside on dozens or hundreds of servers. This presents security exposures for a few reasons: Security best practices dictate that keys and the data they protect are separated. The reason? If a server falls into the wrong hands, whether through theft, lost in shipment for repairs, or a host of other reasons, thieves gain access to both the keys and the data. While Microsoft TDE offers a hierarchical key model, the root key is generated and protected by the underlying operating system, which is at odds with standards such as the Payment Card Industry Data Security Standard (PCI-DSS), which requires separation between data access controls and operating system security. If you look at security as a battle, the more fronts you do battle on, the harder defense is. Protecting keys on many databases represents just such a challenge. It is

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

more difficult to have visibility into whether keys have been compromised; security mechanisms need to be employed on each platform, etc. Database servers are architected to optimize data access, not security. They have multiple, unsecured access points and theyre often not stored in physically secured locations due to operational needs. Database server backups pose similar risks and further compound the number of places keys may reside, and where the security battles take place. All keys are stored in software and are, therefore, susceptible to vulnerabilities in the underlying software, and so organizations cannot be compliant with the stringent requirements of such standards as Federal Information Processing Standards (FIPS). When keys are stored in the database server and the underlying operating system, any vulnerability in either Windows server or SQL Server 2008 poses an immediate risk to data security and requires immediate patchingwhich can make an impact on business processing and data availability. To address this security exposure, Microsoft developed a capability known as Extensible Key Management (EKM), which enables administrators to store root encryption keys, such as the server master key (SMK), in third-party hardware security modules (HSMs) that are designed specifically for this purpose. Given this, administrators may use key management from SafeNet. While this offers significant safeguards, there are several factors to consider: Using EKM for HSM-based key protection is an option, not a requirement. By default, encryption keys are stored locally on the database server. Implementing EKM introduces additional complexity for database administrators (DBAs), who are, typically, already consumed with database-related tasks. Further, these efforts require subject matter expertise around HSMs and key management, which is not commonly a part of a DBAs background. Although EKM supports HSM-based storage of keys, policies for key access are still controlled on SQL Server, most often by DBAs, so there is no real separation of roles among an organizations DBAs, developers, and the security organization. This jeopardizes compliance with such standards as PCI-DSS, and makes the DBA the responsible party in the event of a data leak or compliance violation, a responsibility usually better handled by a security or compliance team. The EKM approach introduces increased complexity and the additional cost of acquiring, integrating, and managing the HSM, which is multiplied by the number of HSMs required to support each and every database server separately. DataSecure With DataSecure, organizations can centrally house the cryptographic keys used to encrypt data in virtually any number of databases. Simply by reducing the number of places they reside, DataSecure dramatically reduces the potential exposure of cryptographic keys. Further, DataSecure offers the highest level of security available in a commercial database encryption solution. DataSecure operates on a hardened appliance that is validated to FIPS and Common Criteria Evaluation. Encryption keys are securely stored on the appliance and thereby protected against application layer attacks and malicious DBAs and developers. The keys are never distributed to database servers from the appliance nor can they be viewed or copied by anyone.

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

Security of Data
Native SQL Server Encryption SQL Server TDE encrypts information when it is read to or written from the SQL Server buffer pool. Consequently, information stored in the SQL Server memory cache is available in clear text even if encrypted in the database, and therefore might be exposed through the Windows swap file, SQL Servers full text indexing, or in the event of a SQL Server memory dump. DataSecure DataSecure integrates cipher operations into the SQL statements themselves. As a result, encrypted information is only decrypted when an actual select statement is executed, and is immediately encrypted when an insert or update is called. Further, even when mechanisms, such as a SQL Server checksums, buffer an actual write to disk, data remains encrypted. This ensures that sensitive information is protected regardless of the access mechanisms being employed.

Separation of Duties
Native SQL Server Encryption Many breaches in recent years have illustrated the risk of having one person holding all the keys to the kingdom. That is why so many regulations and security policies mandate a separation of duties when it comes to securing sensitive data. When native encryption is employed on SQL Server, the DBA effectively also becomes the security administrator. It falls to the DBA to install and maintain the encryption solution. Not only do they handle traditional tasks, but they also must be relied upon to do key management, set security policies, and control user access. Consequently, a single person controls the data, which can present a significant source of exposure. Further, DBAs are not typically trained to do security administration, which raises the potential for configuration errors. Finally, if one DBA decides to undertake malicious activities, the harm they could inflict could be devastating. TDE allows a DBA to grant the right to manage and create keys to specific users, therefore separating the key management capabilities. However, the database system administrator still has full rights to all aspects of the security of the database server, including keys. This may present a challenge when addressing some compliance requirements, especially given some that commercial applications require the use of system administrator privileges to execute correctly. DataSecure The DataSecure solution provides a mechanism for clearly separating security responsibilities from database responsibilities as required by such regulations as PCIDSS. Separation of duties between the DBA and the other administrators prevents super user access and its associated risks. DataSecure offers granular capabilities for defining roles and permissions around the ability to manage keys, create keys, and modify policies. DataSecure also allows for M of N approvals, which means that organizations can set up policies so that no single administrator can make a critical configuration change without additional approvals from other administrators. With DataSecure, administrative privileges can be separated among a number of roles. For example, a security administrator can be authorized to perform specific key management, user access, and security policy functions; a network administrator could have control over device configuration and certificates; an operations administrator could have logging controls; and the DBA could have rights to perform database software installation and configure the tables and columns to be encrypted.

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

Access Control and Leakage Prevention

Native SQL Server Encryption Over the last few years, Microsoft has invested heavily in elevating the level of security offered within its different product lines. As part of those investments, several impressive encryption technologies have been introduced as part of both Windows servers and clients, as well as SQL Server. These technologies are very useful, and should be utilized by customers where appropriate. While Microsoft BitLocker, EFS, and TDE provides a variety of encryption mechanisms, they dont provide protection over who can access the sensitive information, when they can access it, or how much data can be accessed. In fact, these mechanisms are blind to the actual information, allowing anyone with access rights to decrypt any information and use the data encryption keys (DEK) regardless of the context. This creates a serious threat to sensitive information, opens the door to leaks and liability, and poses a serious threat to compliance, as standards, such as PCI-DSS and GLBA, require control and management over data access rights. For example, when TDE is employed, applications typically use a trusted subsystem account to access the database. There is no way to distinguish such factors as the time of day data is being accessed, the server accessing the database (for example, why would a server in the DMZ need to decrypt a large number of records?), or the actual application or database user conducting the operation. The following is a quote from Microsoft: TDE is not a form of access control. All users who have permission to access the database are still allowed access; they do not need to be given permission to use the DEK or a password.1 Further, when TDE is employed, data is encrypted at the database level, rather than at the column level. As a result, anyone permitted to access the database can see all the data in the clear. Consequently, organizations looking to employ encryption are faced with an allor-nothing approacheven though the sensitive data held in many databases will only amount to one or a few columns out of many. When field-level encryption is employed, keys can be either assigned to a database, in which case the keys are stored on the database server and experience the same issue outlined for TDE, or alternately be assigned to users and protected by passwords to prevent automatic decryption, so, for example, users can have individual keys for their own data. Assigning keys to individual users addresses the issue of having a master key managed by the DBA, but, at the same time, introduces a significant key exposure and management challenge since keys are stored on each workstation on which the user needs to be able to decrypt the database information. When EFS is employed, access control can only be applied to the file system files holding the different database contents, such as database files, transaction log files, and fulltext index files. While EFS protects those files from offline attacks, such as someone attempting to copy the database file itself, this only offers limited protectiondatabase files are usually protected when the operating system is shutdown by means such as full disk encryption, and are locked and will prevent copying once the database server is running. Further, since the only user accessing the database files is the account under which SQL Server is running, access control applies to this user only. As a result, the EFS encryption keys must be available locally on every server used to run SQL Server. EFS does not provide any access control or protection over the actual data records inside the database, nor can it protect data load and transform (ETL) files, since EFS does not provide any centralized policy over the location of files that should be encrypted. Also, system administrators must use the server console to manually encrypt files.

 icrosoft, Database Encryption in SQL Server 2008 Enterprise Edition; Section: Impact on the M Databasehttp://msdn.microsoft.com/en-us/library/cc278098.aspx#_Toc189384679

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

DataSecure DataSecure offers authorization functionality that is highly granular so that access to encrypted columns can be controlled by assigning encrypt and decrypt privileges on a per user basis. Plus, these access control features allow a security administrator or compliance officer to secure access to sensitive data at the user level. Often, these changes can be implemented with little or no changes to the database architecture. While, in some cases, additional columns may be added to such database elements as tables to support transparent data encryption, those changes have no affect on the original database fields in the schema, which helps ensure full application compatibility. With DataSecure, a database user that has access to a table with encrypted columns may be allowed to see all, none, or some of the encrypted data based on the way permissions are configured. DataSecure separates the database access control managed by the DBA and the application from the rights to use encryption keys and from the right to access protected sensitive database information. DataSecure provides granular control over data access based on the following parameters: Time of day Enables administrators to dictate when specific users and roles can access sensitive data; for example, to ensure a call center employee that works the day shift cant access credit card information at 2:00 AM. Amount of information being accessedOrganizations can control the volume of decryptions; for example a call center representative that might need to handle at most 100 customer records per shift will not be able to decrypt more than 100 records during a given day. Policies and keysEnables the segmentation of policies associated with the data and the key used to encrypt it; for example, a call center employee might be able to decrypt customer records in their line of business database but not in the VIP customer table encrypted with a different key.

Central Policy Control

Native SQL Server Encryption Another key challenge when utilizing Microsofts integrated encryption offerings is the lack of a central policy management console that can be used to control encryption and policy changes. As a result, it is difficult to maintain consistent documentation of the encryption and access controls employed during a given time frame. With EFS and BitLocker, access control is managed locally on both the database server and the operating system and must be set separately for every piece of protected information, which presents a host of security management and compliance challenges. DataSecure DataSecure provides a central, Web-based management console, that centralizes all access control management in a single location. As a result, administrators have efficient access to a data protection policy repository that displays all access policiesacross different databases, applications, and file systems. Further, DataSecure supports streamlined security configuration documentation, which is a requirement for security life cycle management and compliance with such regulations as SOX and PCI.

Infrastructure Coverage
Native SQL Server Encryption It is important to note that while Microsoft does provides data encryption solutions for SQL Server and file data, those solutions only address SQL Server on Windows operating systems. Further, TDE can only be employed on SQL Server 2008, not earlier versions of the database. The reality, however, is that sensitive data is housed and accessed in a host of other areas throughout an organizationunstructured files, such as PDFs and spreadsheets, applications;, Web servers, and more. Further, most organizations have a mix of operating systems and databases installed, whether IBM DB2, Microsoft SQL Server, Oracle, or

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

Teradataand over the course of its lifecycle, a specific piece of data may reside on a number of platforms. For example, a customer record might be created in a mainframe application using DB2, copied to SQL Server on Windows, loaded into an ERP application using Oracle on Linux, and finally forwarded to a data warehouse housed in Teradata that is used for business intelligence reporting. Consequently, native SQL Server encryption doesnt address the full life cycle of corporate data, and so only addresses a very small piece of an organizations overall security needs. As a result, many companies utilizing a variety of databases in their corporate networks end up deploying and supporting security solutions on a database-by-database basis. Particularly in large organizations, these point solutions prove costly and inefficient, and introduce their own set of security problems. For example, since there is no key sharing between these disparate offerings data has to be decrypted and forwarded in the clear before it can be encrypted on another system. DataSecure DataSecure can be used to centrally manage the encryption of sensitive data in all of an institutions databases, including Oracle, IBM DB2, SQL Server, and Teradata. DataSecure also provides the flexibility to encrypt data at the file level, at the column or field level in databases, at the application layer, and during batch-driven data transformation and transaction processes. DataSecure offers comprehensive support for sensitive database information protection, regardless of the underlying operating system, featuring support for Z/OS, Linux, Windows, and other platforms. DataSecure provides the ability to encrypt information from the moment it enters the enterprise and as it travels within the environment. With DataSecure, organizations can encrypt sensitive data once, and have it be secured throughout its lifecycle, while at the same time enabling authorized users and processes to decrypt the record when needed. This increases overall security by eliminating points of vulnerability outside the database.

Table 2: Database Information Protection Components

BitLocker EFS Field-Level TDE SafeNet DataSecure

Extensible Key Management Infrastructure1 Application-level Encryption

File Encryption (outside of SQL Server)

z/OS Integration

Integration with POS Vendors

Oracle & DB2 Support

Support for RC4, HMACSHA1, and RSA

The table above outlines the support DataSecure and Native SQL Server encryption options provide for various security capabilities that are required beyond database encryption.

Integration and Administration

The degree to which an encryption solution facilitates deployment and ongoing administration efforts can play a significant role in the success of an encryption initiative. Following are details of the differing integration and administration characteristics of each encryption approach.

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

Total Cost of Ownership

Native SQL Server Encryption While Microsoft offers both file and database level record encryption, this support is only available on SQL Server 2008, Enterprise Edition. As a result, implementing TDE requires that all servers within the compliance area must be upgraded to SQL Server 2008, a large and time-consuming task that can create application compatibility issues. Further, the TDE solution is only applicable to SQL Server 2008 databases, so organizations with other databases or operating systems are tasked with learning, implementing, and managing separate solutions for each of those platforms. To guarantee free software updates for the database platforms, customers are required to sign a 3-year maintenance plan with Microsoft, which tends to cost around 120 percent of the initial purchase cost. The Microsoft maintenance plan does not include support fees, which are charged separately and range from tens to hundreds of thousands of dollars depending on the support needs. Any upgrade or fix to the encryption and key management solution requires a patch of the database platform and/or the operating system, a process involving compatibility testing and potential up-time implications. DataSecure DataSecure is a single, easy-to-manage solution that offers database encryption for all major versions of Microsoft SQL Server, as well as other leading database platforms, such as Oracle, DB2, and Teradata. DataSecure eliminates the need for expensive and lengthy application and database migration and testing projects. Further, by having a single, easy management interface for all database platforms and the related policies and keys, DataSecure significantly lowers operational costs. While the DataSecure appliance does require an initial purchase cost, this investment can be fully leveraged as the appliance re-used across database platforms. The DataSecure maintenance plan includes full support and software updates for all aspects of the DataSecure solution for a relatively low yearly cost, and a seamless upgrade experience that removes any operational and testing costs.

Set up and Integration

Native SQL Server Encryption In all but the smallest organizations, deploying native SQL Server encryption is highly complex and time-consuming. All administrative efforts are manual and conducted on a per-database basis, so the more databases an organization has, the more work, and potential errors, will be involved. In a common TDE deployment, in which the goal is to secure data and achieve regulatory compliance, organizations must address several time consuming and complex requirements: The need to have a PKI infrastructure available to provide for recoverable server and database keys The purchase, deployment, and secure operation of a FIPS Level 2-certified HSM for each database server, in order to adhere to security best practices and regulatory compliance Manual review, outline, and implementation of data and key access policies Separate deployment of file encryption Development of scripts and command line tools to encrypt data during ETL processes and in transit Upgrade existing databases to SQL Server 2008 Enterprise Edition and associated application compatibility testing Ongoing patching of both Windows and SQL Server to address any vulnerability that might affect TDE

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

10

 Manual documentation of the key and data access rights as part of security life cycle management and regulatory compliance Institution of security training for the DBA team and establishment of a data exposure response team that is comprised of several groups, including security, compliance, application development, and DBAs DataSecure By providing an out-of-the-box solution with centralized administration of cryptographic policies and configuration, DataSecure dramatically reduces implementation time and expenses compared to deploying native SQL Server encryption. DataSecure offers centralized management for securing database and applications across hundreds, or even thousands, of geographically-distributed locations. Users can centrally manage every facet of security administration, including key management, maintenance and troubleshooting, policy management, logging, reporting, and software upgrades. With DataSecure, integration across various database platforms is automated and transparent to applications. In addition, DataSecure features these tools and capabilities: A data discovery tool that can scan databases for sensitive datasuch as account numbers, credit card numbers, social security numbers, and e-mail addressesthat is not encrypted, helping database administrators and security directors quickly identify where sensitive data exists. This saves administrators time and enables them to better secure sensitive information White Paper: SafeNet DataSecure vs. Native SQL Server EncryptionPage 11 of 15 Data migration capabilities that automatically configure the database and encrypt all of the data in the columns that have been tagged for encryption Application transparency, through support for the creation of triggers and views that hide encrypt and decrypt functions from associated applications Key rotation and versioning capabilities that enable administrators to rotate encryption key(s) on a per column basiswithout having to decrypt and re-encrypt data. Given DataSecure is provided as a turnkey, appliance-based solution, implementation is typically fast and efficient. Following are the common steps to setting up database encryption: Plugging in the DataSecure appliance and configuring network settings. Connecting the appliance to the database to be secured, and selecting the appropriate columns or fields to be protected. Assigning keys, defining access policies, and migrating data to a protected state.

Persistence Support for Cross Platform Applications

Native SQL Server Encryption While native SQL Server encryption protects information in the database, it does not enable organizations to integrate cryptographic operations with associated applications. However, in many cases, it is preferable to implement data encryption in the application logic rather than in the database. Not only does this approach often eliminate the need to make database configuration changes and address performance degradation, but it can help ensure end-to-end encryption of data, from the time it is entered to the point at which it is stored or viewed. While Microsoft does provide encryption APIs, they are stand-alone and are not integrated with underlying key management and data access policy management processes. Thus, organizations that need to protect data across the entire processing lifecycle must implement several disconnected integration and development projects to employ application-level and database-level encryption.

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

11

DataSecure The DataSecure solution was designed from the outset to support heterogeneous environments and encryption at different levels within the infrastructure. With the DataSecure platform, encryption keys used for one vendors database can be used for any other database system or line of business application. DataSecure offers an extensive set of application connectors that deliver FIPS-certified encryption to an organizations lineof-business applications. With DataSecure, encryption keys and data access policies can be re-used across different applications and database systems, providing true information life cycle protection. With its support for J2EE, .Net, COBOL, C, and other languages, DataSecure can be deployed in leading application development and run-time environments. DataSecure supports seamless encryption of the data, from its submission in a Web or line-of-business application, across enterprise connectivity and integration layers (such as message bus and EAI), and in the database.
SafeNet ProtectDB

SafeNet ProtectApp

Databases

SafeNet ProtectApp

SafeNet DataSecure
Application and Web Servers Mainframes

SafeNet ProtectFile
Secure Remote Access to Network Applications

SafeNet ProtectFile ProtectDrive

File servers

PCs and mobile handsets Network shares

UNSTRUCTURED DATA
Figure 1: DataSecure offers a centralized solution for managing keys across an enterprise infrastructure, including Web and application servers, databases, file servers, and more.

Key Management and Rotation

Native SQL Server Encryption With native SQL Server encryption, keys are created and managed on the database server, and administrators are tied to using Microsofts proprietary techniques and interface for performing these functions. When there are large numbers of database servers in an organization, the process of managing keys on each individual database server can quickly become cumbersome and subject to errors. This is especially true if granular, field-level encryption policies are employed. Further, there is no automated process to share or replicate keys among the database servers, even within a single vendors platform. Backing up the keys, which is critical for any encryption implementation, is a manual, command line process for each database on each individual server and grows increasingly complex as the number and variety of database servers are deployed throughout an organization. Further, key rotation is required to increase the security of protected data, ensuring keys and the data they protect do not get exposed over time. SQL Server 2008 supports key

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

12

rotation by generating a SQL script that generates a new key, backs up the existing and new keys to a file, and re-encrypts the entire database with the new key. This operation will switch the existing data to be encrypted using a new key, but while this operation is underway, the database will be locked, preventing any use of the database for the duration of the process. Further, a massive amount of processing overhead is incurred because, rather than encrypting a specific column, the entire database needs to be decrypted and re-encrypted. Command line backup of keys to a file does provide for recoverability of data in case of a disaster or database issues, but requires an organization to setup and maintain a manual, unmanaged, and less secure key repository, perhaps by keeping all backed-up keys in a central file server directory, exposing the keys to risk and accidental deletion or loss. DataSecure The SafeNet DataSecure solution streamlines key management, providing a centralized network appliance to perform all key management functionsincluding creating keys, controlling access to keys, and backing up keys. DataSecure supports granular, fully automated key rotation, according to key expiration policies. Further, this rotation only affects encrypted columns, minimizing the performance impact of encryption on the database.

Logging and Auditing

Native SQL Server Encryption Native SQL Server encryption only provides very basic logging information in heterogeneous environments. This can be exacerbated by the fact that each database vendor will have its own unique log format. Because of this, administration of logs and report generation is extremely time consuming. Further, because of the way event data is structured in Windows and SQL Server, it is very difficult to analyze log information and spot potential threats in a timely manner. In addition, these logging mechanisms offer little protection against tempering or unintentional modification. DataSecure DataSecure provides comprehensive, secure, and centralized logging and auditing of all cryptographic functions and data access events. The DataSecure platform maintains a variety of detailed logs to record all administrative actions and cryptographic activity on the appliance. Not only is every cryptographic function logged, but real-time reporting allows for immediate detection of any potential threats. DataSecure can capture all encryption activityeven across disparate databases and applicationsand house this logging data in a central, standardized fashion. Compared to the traditional, time-consuming process of manually gathering and analyzing information from multiple application and database logs, this centralization provides much greater efficiency and control. Consolidated logging information and audit reporting enables auditors to easily understand who accessed what data and which administrators made changes to encryption configurations or key management policies. DataSecure tracks administrative actions, such as key creation, access control management and policy management to an audit log. Further, DataSecure offers a detailed activity log, tracking all key usage and data access activity, including details such as accessing user, time of day, amount of records accessed, related policy and more. All logs managed by DataSecure are tamper-proof to allow for proof of authenticity over the events record, which guarantees a clear, auditable history of data and user activity across all sensitive information. Consequently, administrators can more efficiently comply with the logging and auditing requirements of such regulations as PCI-DSS.

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

13

Performance and Availability

Given the vital role databases play in todays infrastructures, performance and availability of encryption and associated processes is a critical consideration. The following section compares the performance and availability characteristics of native SQL Server encryption and DataSecure.

Performance
Native SQL Server Encryption With Native SQL Server encryption, cryptographic processing and capabilities get added to a database platform that was not originally designed for, or optimized for, security processing. Further, since cryptographic processing takes place on the same machine as other business applications, the performance of these systems often starts to suffer. This performance degradation can be especially pronounced in performance-intensive batch processing and OLTP environments. Microsoft has officially stated that systems in heavy daily usage should expect up to a 28 percent performance hit just from employing TDE, and organizations employing EFS or Biltlocker can expect an additional performance hit of 5-20 percent. In addition, during data migration operations (for example, when initially deploying encryption), performance suffers even more dramatically. The following is a quote from Microsoft SQL 2008 PCI compliance guide: Because the initial encryption scan spawns a new thread, performance is most sharply impacted at this time; expect to see queries perform several orders of magnitude worse.1 To boost performance, organizations have no choice but to add more database servers to their infrastructure, which represents not only more upfront costs, but ongoing administrationand it further compounds the risk of having keys and encryption managed in a disparate fashion. DataSecure By offloading cryptography to a dedicated and specialized cryptographic appliance, DataSecure delivers better performance than SQL Servers native encryption, especially during batch processing. DataSecure also provides special batch processing utilities for both database tables and flat files that need to be imported or exported. These utilities are designed to take advantage of the high-speed cryptographic accelerator hardware in the DataSecure appliance and are ideally suited for many batch applications. As a result, DataSecure can transform large databases into encrypted format, or rotate the keys on existing data and completely re-encrypt it, with minimal impact on the live database system. Both from a performance and security standpoint, it is typically recommended that organizations offload encryption from database platforms and onto the DataSecure appliance. However, in some cases, database administrators prefer to handle this encryption locally on the database platform. In these cases, DataSecure will also support this approach, enabling organizations to employ cryptographic processing on the database server itself.

Availability and Recovery

Native SQL Server Encryption TDE uses a key hierarchy comprised of a master data protection API (DPAPI) key, a server master key (SMK), and a set of database keys (DMK). All SMKs and DMKs are stored within the SQL Server master database, and the user is required to manually backup the keys to file using SQL statements to ensure data is recoverable in case of a disaster. Further, since all key backup operations are manual and need to be performed on each database server, the process of managing a secure backup repository of keys, key locations, and the intended use of keys becomes an intense and complex challenge.
1  icrosoft, Database Encryption in SQL Server 2008 Enterprise Edition; Section: Impact on the M Databasehttp://msdn.microsoft.com/en-us/library/cc278098.aspx#_Toc189384684

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

14

For an organization to be able to restore a database from backup in case of a disaster, such as storage or server failure, all elements of the key hierarchyas well as the Windows operating system and the database itselfmust be restored from backup. This complex operation requires a precise sequence of actions, complicating recovery procedures and delaying recovery times. DataSecure Since all keys and policies are stored within the DataSecure appliance, there are no dependencies for recovery on the SQL Server or the operating system. In case of any issue with the database, all that is needed is a restore of the latest version of the database, and DataSecure will automatically enforce the relevant decryption and encryption policies. Further, DataSecure supports high-availability clustering, securely replicating all keys and policies between all cluster members to ensure 99.999% uptime. DataSecure clusters can be deployed across site links to support multiple geographic locations and disaster recovery sites. DataSecure offers integrated, secured, and automated backups of the key and policy store for rare scenarios in which all DataSecure machines in all geographic sites go down.

Conclusion
In recent years, Microsofts native encryption infrastructure has been enhanced, but these offerings still represent a series of technologies, rather than a complete solution. Today, when native SQL Server encryption is employed, cryptographic keys and policies are managed in a disparate fashion, one database platform at a time. This can present a host of security threats, as well as a high degree of administrative complexity, particularly in larger organizations. With DataSecure, security administrators can leverage a single, centralized encryption solution, not only for encrypting data in multiple SQL Server databases, but other database platforms, applications, files, and more. As a result, DataSecure provides significant advantages both in delivering optimal security and manageability.

About SafeNet
Founded in 1983, SafeNet is a global leader in information security. SafeNet protects its customers most valuable assets, including identities, transactions, communications, data and software licensing, throughout the data lifecycle. More than 25,000 customers across both commercial enterprises and government agencies and in over 100 countries trust their information security needs to SafeNet.

Contact Us: For all office locations and contact information, please visit www.safenet-inc.com Follow Us: www.safenet-inc.com/connected
2011 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners. DataSecure_VS_NativeSQL_WP(EN)_A4_3.5.11

White Paper: SafeNet DataSecure vs. Native SQL Server Encryption

15