Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SafeNet DataSecure vs. Native SQL Server Encryption


Published on

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.

Published in: Technology
  • Be the first to comment

SafeNet DataSecure vs. Native SQL Server Encryption

  1. 1. SafeNet DataSecure vs. Native SQL Server Encryption WHITE PAPERContentsExecutive Summary...................................................................................................2Solutions Overview................................................................................................... 2SQL Server Encryption.............................................................................................. 2Security 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...................................................................................... 8Integration 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........................................................................................... 13Performance and Availability.....................................................................................14 Performance....................................................................................................... 14 Availability and Recovery..................................................................................... 14Conclusion................................................................................................................ 15About SafeNet.......................................................................................................... 15White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 1
  2. 2. Executive SummaryGiven the vital records databases hold, these systems often represent one of the mostcritical areas of exposure for an organization. Consequently, as organizations look to complywith security best practices and regulatory mandates, database encryption is becomingincreasingly common—and critical. Today, security teams looking to employ databaseencryption can choose from several alternatives. This paper provides a high level comparisonof two approaches: Microsoft’s native encryption capabilities for SQL Server and the SafeNetDataSecure platform.Solutions OverviewSafeNet DataSecureSafeNet DataSecure is the only appliance-based data protection solution that featuresgranular, field-level encryption capabilities that can be integrated at the file, Web server,application server, or database layer. By centralizing cryptographic processing, key and policymanagement, logging, and auditing in a single, hardened appliance, DataSecure maximizesoverall security and helps ensure organizations are compliant with a range of security bestpractices and regulations.DataSecure features a centralized architecture that streamlines security administration andprovides superior key and policy life cycle management. Plus, DataSecure can act as an externalkey management device for third-party encryption offerings. Consequently, organizationsemploying SQL Server’s encryption capabilities can store the cryptographic keys associated withthat product, as well as keys for other encryption products, on the DataSecure appliance.SQL Server EncryptionMicrosoft offers several encryption options for SQL Server:Windows BitLockerBitLocker is an encryption solution that provides disk level, sector-based, and bulk encryptionof an entire drive or volume. BitLocker provides protection against data access when a machineis 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 isslowed by approximately 5-10%, even when the client or server is turned on. However, any datarequested from the disk is immediately returned in a decrypted format, therefore, during day-to-day operations of database servers, BitLocker introduces significant performance latencywithout 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 ofhard drives while in transit between sites.White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 2
  3. 3. Encrypting File SystemEncrypting File System (EFS) is a file encryption feature introduced in Windows 2000,with additional features and enhancements released in subsequent years. EFS makesit possible for users to encrypt files on their computers, and control who can decrypt orrecover these files. EFS uses symmetric keys to encrypt files, and it uses certificatesassociated 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) withhierarchical certificate authorities (CA), and have the processes and mechanisms in placeto 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 supportcolumn-level encryption, which means the entire database file must be encrypted anddecrypted while in use. As a result, EFS typically introduces performance degradationof 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 EFSencrypted database file, regardless of the EFS encryption status. When EFS is used fordatabase file encryption, the EFS encryption keys often reside in the operating systemhosting the database server, where they are vulnerable. Additionally, this requiresa smartcard or HSM to be connected to each database server, which necessitatesadditional purchases and administrative complexity.Field-level EncryptionSQL Server field-level encryption was introduced in SQL Server 2005 and is alsosupported unchanged in SQL Server 2008. Field-level encryption supports granularencryption of parts of a database or table by modifying the database schema and movingthe data that is to be protected into a binary data type. A set of schema modificationsallow the data to be read and updated in an encrypted format after the changes areimplemented.Because of the significant performance and manageability impacts of setting up field-level encryption, Microsoft has shifted its main focus in SQL Server 2008 towardstransparent database encryption. Microsoft still recommends the use of field-levelencryption in SQL 2008 for scenarios in which organizations demand a high degree ofdata security and access control or granular data access auditing capabilities. Microsoftcautions customers about the performance impacts of field-level encryption becauseeach field needs to be encrypted and decrypted separately on the database server CPU,which degrades performance by 20-40 percent.Transparent Database EncryptionTransparent Database Encryption (TDE) is a new capability introduced in SQL Server2008, and is only available as part of the Enterprise and Developer Editions. TDE usesa hierarchical key management approach that is almost identical to the one employedby Microsoft’s field-level encryption approach. TDE provides bulk encryption of all thedata in a given database. TDE does not enable column or field level encryption at thistime. Rather than offering a specifically targeted key and data encryption managementconsole, TDE is tightly integrated with SQL Server and is managed using the same DBAquery interfaces and the Transact-SQL language as the database server.White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 3
  4. 4. 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 AccessThe table above compares the capabilities of native SQL Server encryption and those of DataSecure.Security and ComplianceOptimizing security is the ultimate objective of employing database encryption. Thissection compares the security offered by Microsoft’s encryption options and DataSecure,comparing such critical areas as key security, and separation of duties.Security of KeysNative SQL Server EncryptionThe single most critical aspect to ensuring that encryption yields the highest levelof security possible is the security of the cryptographic keys. Simply put, if keys arecompromised, encrypted data is compromised.A key architectural foundation of Microsoft’s encryption solutions is that cryptographickeys reside on the same database server as the encrypted data. For large organizationswith dozens or even hundreds of databases, this means cryptographic keys reside ondozens 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 isWhite Paper: SafeNet DataSecure vs. Native SQL Server Encryption 4
  5. 5. 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.White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 5
  6. 6. Security of DataNative SQL Server EncryptionSQL Server TDE encrypts information when it is read to or written from the SQL Serverbuffer pool. Consequently, information stored in the SQL Server memory cache isavailable in clear text even if encrypted in the database, and therefore might be exposedthrough the Windows swap file, SQL Server’s full text indexing, or in the event of a SQLServer memory dump.DataSecureDataSecure integrates cipher operations into the SQL statements themselves. As aresult, encrypted information is only decrypted when an actual select statement isexecuted, and is immediately encrypted when an insert or update is called. Further, evenwhen mechanisms, such as a SQL Server checksums, buffer an actual write to disk, dataremains encrypted. This ensures that sensitive information is protected regardless of theaccess mechanisms being employed.Separation of DutiesNative SQL Server EncryptionMany breaches in recent years have illustrated the risk of having one person holding allthe “keys to the kingdom.” That is why so many regulations and security policies mandatea separation of duties when it comes to securing sensitive data.When native encryption is employed on SQL Server, the DBA effectively also becomes thesecurity 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 keymanagement, set security policies, and control user access. Consequently, a singleperson controls the data, which can present a significant source of exposure. Further,DBAs are not typically trained to do security administration, which raises the potentialfor configuration errors. Finally, if one DBA decides to undertake malicious activities, theharm 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 systemadministrator still has full rights to all aspects of the security of the database server,including keys. This may present a challenge when addressing some compliancerequirements, especially given some that commercial applications require the use ofsystem administrator privileges to execute correctly.DataSecureThe DataSecure solution provides a mechanism for clearly separating securityresponsibilities from database responsibilities as required by such regulations as PCI-DSS. Separation of duties between the DBA and the other administrators prevents “superuser” access and its associated risks.DataSecure offers granular capabilities for defining roles and permissions around theability to manage keys, create keys, and modify policies. DataSecure also allows for “Mof N” approvals, which means that organizations can set up policies so that no singleadministrator can make a critical configuration change without additional approvals fromother administrators.With DataSecure, administrative privileges can be separated among a number ofroles. For example, a security administrator can be authorized to perform specific keymanagement, user access, and security policy functions; a network administrator couldhave control over device configuration and certificates; an operations administratorcould have logging controls; and the DBA could have rights to perform database softwareinstallation and configure the tables and columns to be encrypted.White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 6
  7. 7. Access Control and Leakage PreventionNative SQL Server EncryptionOver the last few years, Microsoft has invested heavily in elevating the level of securityoffered within its different product lines. As part of those investments, several impressiveencryption technologies have been introduced as part of both Windows servers andclients, as well as SQL Server. These technologies are very useful, and should be utilizedby 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 theycan 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 informationand use the data encryption keys (DEK) regardless of the context.This creates a serious threat to sensitive information, opens the door to leaks andliability, and poses a serious threat to compliance, as standards, such as PCI-DSS andGLBA, require control and management over data access rights. For example, whenTDE is employed, applications typically use a trusted subsystem account to access thedatabase. There is no way to distinguish such factors as the time of day data is beingaccessed, the server accessing the database (for example, why would a server in the DMZneed to decrypt a large number of records?), or the actual application or database userconducting the operation.The following is a quote from Microsoft: “TDE is not a form of access control. All userswho have permission to access the database are still allowed access; they do not need tobe given permission to use the DEK or a password.”1Further, when TDE is employed, data is encrypted at the database level, rather than at thecolumn level. As a result, anyone permitted to access the database can see all the data inthe 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 onlyamount to one or a few columns out of many.When field-level encryption is employed, keys can be either assigned to a database, inwhich case the keys are stored on the database server and experience the same issueoutlined for TDE, or alternately be assigned to users and protected by passwords toprevent automatic decryption, so, for example, users can have individual keys for theirown data. Assigning keys to individual users addresses the issue of having a “masterkey” managed by the DBA, but, at the same time, introduces a significant key exposureand management challenge since keys are stored on each workstation on which the userneeds to be able to decrypt the database information.When EFS is employed, access control can only be applied to the file system files holdingthe 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 someoneattempting to copy the database file itself, this only offers limited protection—databasefiles are usually protected when the operating system is shutdown by means such asfull disk encryption, and are locked and will prevent copying once the database server isrunning. Further, since the only “user” accessing the database files is the account underwhich SQL Server is running, access control applies to this user only. As a result, the EFSencryption 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 insidethe database, nor can it protect data load and transform (ETL) files, since EFS does notprovide 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”— Paper: SafeNet DataSecure vs. Native SQL Server Encryption 7
  8. 8. DataSecureDataSecure offers authorization functionality that is highly granular so that access toencrypted columns can be controlled by assigning encrypt and decrypt privileges ona per user basis. Plus, these access control features allow a security administrator orcompliance officer to secure access to sensitive data at the user level. Often, thesechanges can be implemented with little or no changes to the database architecture.While, in some cases, additional columns may be added to such database elementsas tables to support transparent data encryption, those changes have no affect on theoriginal 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 maybe allowed to see all, none, or some of the encrypted data based on the way permissionsare configured. DataSecure separates the database access control managed by the DBAand the application from the rights to use encryption keys and from the right to accessprotected sensitive database information. DataSecure provides granular control overdata 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 ControlNative SQL Server EncryptionAnother key challenge when utilizing Microsoft’s integrated encryption offerings is thelack of a central policy management console that can be used to control encryptionand policy changes. As a result, it is difficult to maintain consistent documentationof the encryption and access controls employed during a given time frame. With EFSand BitLocker, access control is managed locally on both the database server and theoperating system and must be set separately for every piece of protected information,which presents a host of security management and compliance challenges.DataSecureDataSecure provides a central, Web-based management console, that centralizes allaccess control management in a single location. As a result, administrators have efficientaccess to a data protection policy repository that displays all access policies—acrossdifferent databases, applications, and file systems. Further, DataSecure supportsstreamlined security configuration documentation, which is a requirement for securitylife cycle management and compliance with such regulations as SOX and PCI.Infrastructure CoverageNative SQL Server EncryptionIt is important to note that while Microsoft does provides data encryption solutions forSQL Server and file data, those solutions only address SQL Server on Windows operatingsystems. Further, TDE can only be employed on SQL Server 2008, not earlier versions ofthe database.The reality, however, is that sensitive data is housed and accessed in a host of otherareas throughout an organization—unstructured files, such as PDFs and spreadsheets,applications;, Web servers, and more. Further, most organizations have a mix of operatingsystems and databases installed, whether IBM DB2, Microsoft SQL Server, Oracle, orWhite Paper: SafeNet DataSecure vs. Native SQL Server Encryption 8
  9. 9. Teradata—and over the course of its lifecycle, a specific piece of data may reside on anumber of platforms. For example, a customer record might be created in a mainframeapplication using DB2, copied to SQL Server on Windows, loaded into an ERP applicationusing Oracle on Linux, and finally forwarded to a data warehouse housed in Teradata thatis used for business intelligence reporting. Consequently, native SQL Server encryptiondoesn’t address the full life cycle of corporate data, and so only addresses a very smallpiece of an organization’s overall security needs.As a result, many companies utilizing a variety of databases in their corporate networksend up deploying and supporting security solutions on a database-by-database basis.Particularly in large organizations, these point solutions prove costly and inefficient, andintroduce their own set of security problems. For example, since there is no key sharingbetween these disparate offerings data has to be decrypted and forwarded in the clearbefore it can be encrypted on another system.DataSecureDataSecure can be used to centrally manage the encryption of sensitive data in all of aninstitution’s databases, including Oracle, IBM DB2, SQL Server, and Teradata.DataSecure also provides the flexibility to encrypt data at the file level, at the columnor field level in databases, at the application layer, and during batch-driven datatransformation and transaction processes. DataSecure offers comprehensive support forsensitive 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 theenterprise and as it travels within the environment. With DataSecure, organizations canencrypt sensitive data once, and have it be secured throughout its lifecycle, while at thesame 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 forvarious security capabilities that are required beyond database encryption.Integration and AdministrationThe degree to which an encryption solution facilitates deployment and ongoingadministration efforts can play a significant role in the success of an encryption initiative.Following are details of the differing integration and administration characteristics ofeach encryption approach.White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 9
  10. 10. Total Cost of OwnershipNative SQL Server EncryptionWhile Microsoft offers both file and database level record encryption, this support is onlyavailable on SQL Server 2008, Enterprise Edition. As a result, implementing TDE requiresthat all servers within the compliance area must be upgraded to SQL Server 2008, a largeand time-consuming task that can create application compatibility issues.Further, the TDE solution is only applicable to SQL Server 2008 databases, soorganizations 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 requiredto sign a 3-year maintenance plan with Microsoft, which tends to cost around 120 percentof the initial purchase cost. The Microsoft maintenance plan does not include supportfees, which are charged separately and range from tens to hundreds of thousands ofdollars depending on the support needs. Any upgrade or fix to the encryption and keymanagement solution requires a patch of the database platform and/or the operatingsystem, a process involving compatibility testing and potential up-time implications.DataSecureDataSecure is a single, easy-to-manage solution that offers database encryption for allmajor versions of Microsoft SQL Server, as well as other leading database platforms, suchas Oracle, DB2, and Teradata. DataSecure eliminates the need for expensive and lengthyapplication 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 investmentcan be fully leveraged as the appliance re-used across database platforms. TheDataSecure maintenance plan includes full support and software updates for all aspectsof the DataSecure solution for a relatively low yearly cost, and a seamless upgradeexperience that removes any operational and testing costs.Set up and IntegrationNative SQL Server EncryptionIn all but the smallest organizations, deploying native SQL Server encryption is highlycomplex and time-consuming. All administrative efforts are manual and conducted ona per-database basis, so the more databases an organization has, the more work, andpotential errors, will be involved.In a common TDE deployment, in which the goal is to secure data and achieve regulatorycompliance, organizations must address several time consuming and complexrequirements: • 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 TDEWhite Paper: SafeNet DataSecure vs. Native SQL Server Encryption 10
  11. 11. • 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 DBAsDataSecureBy providing an out-of-the-box solution with centralized administration of cryptographicpolicies and configuration, DataSecure dramatically reduces implementation timeand expenses compared to deploying native SQL Server encryption. DataSecure offerscentralized management for securing database and applications across hundreds, oreven thousands, of geographically-distributed locations. Users can centrally manageevery facet of security administration, including key management, maintenance andtroubleshooting, policy management, logging, reporting, and software upgrades.With DataSecure, integration across various database platforms is automated andtransparent to applications. In addition, DataSecure features these toolsand 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, implementationis typically fast and efficient. Following are the common steps to setting up databaseencryption: • 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 ApplicationsNative SQL Server EncryptionWhile native SQL Server encryption protects information in the database, it does notenable organizations to integrate cryptographic operations with associated applications.However, in many cases, it is preferable to implement data encryption in the applicationlogic rather than in the database. Not only does this approach often eliminate the needto make database configuration changes and address performance degradation, but itcan help ensure end-to-end encryption of data, from the time it is entered to the point atwhich it is stored or viewed.While Microsoft does provide encryption API’s, they are stand-alone and are notintegrated with underlying key management and data access policy managementprocesses. Thus, organizations that need to protect data across the entire processinglifecycle must implement several disconnected integration and development projects toemploy application-level and database-level encryption.White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 11
  12. 12. 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 ProtectDriveSecure RemoteAccess 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 Native SQL Server Encryption 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 White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 12
  13. 13. rotation by generating a SQL script that generates a new key, backs up the existing andnew keys to a file, and re-encrypts the entire database with the new key. This operationwill switch the existing data to be encrypted using a new key, but while this operationis underway, the database will be locked, preventing any use of the database for theduration of the process. Further, a massive amount of processing overhead is incurredbecause, rather than encrypting a specific column, the entire database needs to bedecrypted and re-encrypted.Command line backup of keys to a file does provide for recoverability of data in case of adisaster 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 acentral file server directory, exposing the keys to risk and accidental deletion or loss.DataSecureThe SafeNet DataSecure solution streamlines key management, providing a centralizednetwork appliance to perform all key management functions—including creating keys,controlling access to keys, and backing up keys. DataSecure supports granular, fullyautomated key rotation, according to key expiration policies. Further, this rotation onlyaffects encrypted columns, minimizing the performance impact of encryption on thedatabase.Logging and AuditingNative SQL Server EncryptionNative SQL Server encryption only provides very basic logging information inheterogeneous environments. This can be exacerbated by the fact that each databasevendor will have its own unique log format. Because of this, administration of logs andreport generation is extremely time consuming. Further, because of the way event data isstructured in Windows and SQL Server, it is very difficult to analyze log information andspot potential threats in a timely manner. In addition, these logging mechanisms offerlittle protection against tempering or unintentional modification.DataSecureDataSecure provides comprehensive, secure, and centralized logging and auditing of allcryptographic functions and data access events. The DataSecure platform maintains avariety of detailed logs to record all administrative actions and cryptographic activity onthe appliance. Not only is every cryptographic function logged, but real-time reportingallows for immediate detection of any potential threats.DataSecure can capture all encryption activity—even across disparate databases andapplications—and house this logging data in a central, standardized fashion. Comparedto the traditional, time-consuming process of manually gathering and analyzinginformation from multiple application and database logs, this centralization providesmuch greater efficiency and control.Consolidated logging information and audit reporting enables auditors to easilyunderstand who accessed what data and which administrators made changes toencryption configurations or key management policies. DataSecure tracks administrativeactions, such as key creation, access control management and policy management to anaudit log.Further, DataSecure offers a detailed activity log, tracking all key usage and dataaccess activity, including details such as accessing user, time of day, amount of recordsaccessed, related policy and more. All logs managed by DataSecure are tamper-proofto 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 ofsuch regulations as PCI-DSS.White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 13
  14. 14. Performance and AvailabilityGiven the vital role databases play in today’s infrastructures, performance andavailability of encryption and associated processes is a critical consideration. Thefollowing section compares the performance and availability characteristics of nativeSQL Server encryption and DataSecure.PerformanceNative SQL Server EncryptionWith Native SQL Server encryption, cryptographic processing and capabilities get addedto a database platform that was not originally designed for, or optimized for, securityprocessing. Further, since cryptographic processing takes place on the same machine asother business applications, the performance of these systems often starts to suffer. Thisperformance degradation can be especially pronounced in performance-intensive batchprocessing and OLTP environments.Microsoft has officially stated that systems in heavy daily usage should expect up toa 28 percent performance hit just from employing TDE, and organizations employingEFS 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 SQL2008 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 severalorders of magnitude worse.”1To boost performance, organizations have no choice but to add more database serversto their infrastructure, which represents not only more upfront costs, but ongoingadministration—and it further compounds the risk of having keys and encryptionmanaged in a disparate fashion.DataSecureBy offloading cryptography to a dedicated and specialized cryptographic appliance,DataSecure delivers better performance than SQL Server’s native encryption, especiallyduring batch processing.DataSecure also provides special batch processing utilities for both database tablesand flat files that need to be imported or exported. These utilities are designed to takeadvantage of the high-speed cryptographic accelerator hardware in the DataSecureappliance and are ideally suited for many batch applications. As a result, DataSecure cantransform large databases into encrypted format, or rotate the keys on existing data andcompletely re-encrypt it, with minimal impact on the live database system.Both from a performance and security standpoint, it is typically recommended thatorganizations offload encryption from database platforms and onto the DataSecureappliance. However, in some cases, database administrators prefer to handle thisencryption locally on the database platform. In these cases, DataSecure will also supportthis approach, enabling organizations to employ cryptographic processing on thedatabase server itself.Availability and RecoveryNative SQL Server EncryptionTDE uses a key hierarchy comprised of a master data protection API (DPAPI) key, a servermaster key (SMK), and a set of database keys (DMK). All SMKs and DMKs are storedwithin the SQL Server master database, and the user is required to manually backupthe 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 eachdatabase server, the process of managing a secure backup repository of keys, keylocations, 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”— Paper: SafeNet DataSecure vs. Native SQL Server Encryption 14
  15. 15. 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 theWindows operating system and the database itself—must be restored from backup.This complex operation requires a precise sequence of actions, complicating recoveryprocedures and delaying recovery times.DataSecureSince all keys and policies are stored within the DataSecure appliance, there are nodependencies for recovery on the SQL Server or the operating system. In case of any issuewith the database, all that is needed is a restore of the latest version of the database, andDataSecure will automatically enforce the relevant decryption and encryption policies.Further, DataSecure supports high-availability clustering, securely replicating all keysand policies between all cluster members to ensure 99.999% uptime. DataSecureclusters can be deployed across site links to support multiple geographic locations anddisaster recovery sites. DataSecure offers integrated, secured, and automated backupsof the key and policy store for rare scenarios in which all DataSecure machines in allgeographic sites go down.ConclusionIn recent years, Microsoft’s native encryption infrastructure has been enhanced, butthese offerings still represent a series of technologies, rather than a complete solution.Today, when native SQL Server encryption is employed, cryptographic keys and policiesare managed in a disparate fashion, one database platform at a time. This can present ahost of security threats, as well as a high degree of administrative complexity, particularlyin larger organizations. With DataSecure, security administrators can leverage a single,centralized encryption solution, not only for encrypting data in multiple SQL Serverdatabases, but other database platforms, applications, files, and more. As a result,DataSecure provides significant advantages both in delivering optimal security andmanageability.About SafeNetFounded in 1983, SafeNet is a global leader in information security. SafeNet protects itscustomers’ most valuable assets, including identities, transactions, communications,data and software licensing, throughout the data lifecycle. More than 25,000 customersacross both commercial enterprises and government agencies and in over 100 countriestrust their information security needs to SafeNet.Contact Us: For all office locations and contact information, please visit www.safenet-inc.comFollow Us:©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.11White Paper: SafeNet DataSecure vs. Native SQL Server Encryption 15