SafeNet DataSecure vs. Native SQL Server Encryption

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 1

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 common—and critical. Today, security teams looking to employ database
encryption can choose from several alternatives. This paper provides a high level comparison
of two approaches: Microsoft’s 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 Server’s 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 day-
to-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.


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 field-
level 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 Microsoft’s 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.


Table 1: Data Protection Capabilities

SafeNet
BitLocker EFS Field-Level TDE
DataSecure

Data Encryption (3DES
& AES) ü ü ü ü ü

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)

Optional Optional
Secure Master Key
Storage û û (requires HSM (requires HSM ü
purchase) purchase)

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 Microsoft’s encryption options and DataSecure,
comparing such critical areas as key security, and separation of duties.

Security of Keys
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 Microsoft’s 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


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 they’re 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 patching—which 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 DBA’s 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 organization’s 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.


Security of Data
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 Server’s 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
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 PCI-
DSS. 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.


Access Control and Leakage Prevention
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 don’t 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 all-
or-nothing approach—even 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 full-
text index files. While EFS protects those files from offline attacks, such as someone
attempting to copy the database file itself, this only offers limited protection—database
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.

1 Microsoft, “Database Encryption in SQL Server 2008 Enterprise Edition”; Section: “Impact on the
Database”—http://msdn.microsoft.com/en-us/library/cc278098.aspx#_Toc189384679


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 can’t access credit card information at 2:00 AM.

• Amount of information being accessed—Organizations 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 keys—Enables 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
Another key challenge when utilizing Microsoft’s 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 policies—across
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
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 organization—unstructured 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


Teradata—and 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
doesn’t address the full life cycle of corporate data, and so only addresses a very small
piece of an organization’s 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
institution’s 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

SafeNet
BitLocker EFS Field-Level TDE
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, HMAC-
SHA1, 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.


Total Cost of Ownership
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
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


• 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 data—such as account
numbers, credit card numbers, social security numbers, and e-mail addresses—that
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 Encryption—Page 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 basis—without 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
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 API’s, 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.


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 vendor’s 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 organization’s line-
of-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

Databases
SafeNet SafeNet
ProtectApp ProtectApp

SafeNet
DataSecure

Application and Mainframes
Web Servers

SafeNet
SafeNet ProtectFile
ProtectFile ProtectDrive
Secure Remote
Access to Network Applications

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
With native SQL Server encryption, keys are created and managed on the database server,
and administrators are tied to using Microsoft’s 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 vendor’s
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


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 functions—including 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 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 activity—even across disparate databases and
applications—and 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.


Performance and Availability
Given the vital role databases play in today’s 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
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
administration—and 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 Server’s 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
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 Microsoft, “Database Encryption in SQL Server 2008 Enterprise Edition”; Section: “Impact on the
Database”—http://msdn.microsoft.com/en-us/library/cc278098.aspx#_Toc189384684


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 hierarchy—as well as the
Windows operating system and the database itself—must 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, Microsoft’s 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


SafeNet DataSecure vs. Native SQL Server Encryption

More Related Content

What's hot

Viewers also liked

Similar to SafeNet DataSecure vs. Native SQL Server Encryption

More from SafeNet

Recently uploaded

SafeNet DataSecure vs. Native SQL Server Encryption