SafeNet DataSecure vs. Native Oracle Encryption

Transcription

1 SafeNet vs. Native Encryption Executive Summary Given the vital records databases hold, these systems often represent one of the most critical areas of exposure for an enterprise. Consequently, as enterprises 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: s native encryption and the SafeNet platform. Table of Contents Table of Contents... 1 Solutions Introduction... 1 SafeNet... 1 Native Encryption of Keys... 2 Separation of Duties... 3 Access Control... 4 Infrastructure Coverage... 4 Integration and Administration... 6 Set Up and Integration... 6 Persistence Support for Cross Platform Applications... 7 Key Management... 8 Logging and Auditing... 9 Performance... 9 Conclusion About SafeNet Solutions Introduction SafeNet SafeNet is the only appliance-based data protection solution that features granular, field-level encryption capabilities that can be integrated at the Web server, application server, or database layer. By centralizing cryptographic processing, key and policy management, logging, and auditing in a single, hardened appliance, maximizes overall security and manageability and helps ensure that organizations are compliant with a range of security best practices and regulations. By storing cryptographic keys in a central, hardened appliance, streamlines security administration and provides superior key policy life cycle management. Further, can act as a key management device for third-party encryption offerings. Consequently, organizations can use native encryption and store the cryptographic keys associated with that product, as well as keys for other encryption products, on the appliance. Native Encryption first unveiled encryption capabilities with its 10g R2 product release. Organizations looking to employ native encryption will need to purchase up to four separate modules from s family of database security products:, Label, Database Vault, and Secure Backup.

2 Table 1: Data Protection Capabilities + Label + Label + Database Vault + Label + Database Vault + Secure Backup SafeNet 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) Secure Master Key Storage The table above outlines the capabilities each security module provides, and offers a comparison of those offerings with. Optimizing security is the ultimate objective of employing database encryption. This section compares the security offered by native encryption and, comparing such critical areas as key security, and separation of duties. 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. When native encryption is employed, 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 several reasons: o Generally, 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. o Further, 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. o Finally, database servers are simply not architected with security in mind. They have multiple, unsecured access points and they re often not stored in physically secure Competitive Brief: SafeNet vs. Native Encryption Page 2 of 10

3 locations. Database server backups pose similar risks, and further compound the number of places keys may reside, and where the security battles take place. To address this security exposure, unveiled a key externalization option in its 11g product. With 11g, customers have the option of storing the master encryption key on an external hardware security module (HSM). (Given this, administrators may use the HSM capabilities of the appliance to store the master encryption key.) While this offers significant safeguards, there are several factors to consider: o First, this is an option, not a requirement, one that database administrators (DBAs) may choose not to implement, or simply not get around to deploying. By default, master encryption keys are stored locally on the database server. o Second, only allows externalization of the master wallet key and not the individual keys. Because all cryptography is performed on the database server, the table-specific keys remain in, and can not be externalized. As a result, these keys reside in memory, which could enable a hacker to gain access to the key in the clear. o Third, native encryption puts the onus of protecting the credentials used to access the Key Wallet on the end user. Because the credentials that open the Key Wallet are stored in the clear on the file system, significant security vulnerabilities still exist. o Fourth, policies for data access are still managed on the database, most often by DBAs, so there is no real separation of roles between an organization s DBAs, developers, and the security organization. With, 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, SafeNet dramatically reduces the potential exposure of cryptographic keys. Further, offers the highest level of security available in a commercial database encryption solution. 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. 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, 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. Further, if one DBA decides to undertake malicious activities, the harm they could inflict could be devastating. To combat this threat, unveiled support for separation of duties in its 11g offering. However, this control is typically associated with an upper-level DBA, who would most often retain super-user control over data. In essence, it s still the DBA, rather than the security organization, that retains control over security policy. Competitive Brief: SafeNet vs. Native Encryption Page 3 of 10

4 The solution provides a mechanism for clearly separating security responsibilities from database responsibilities. Separation of duties between the DBA and the other administrators prevents super user access and its associated risks. 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, 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 the database software installation and configure the tables and columns to be encrypted. Access Control With native encryption, rights to encrypt or decrypt data are typically based solely on read and write privileges at the table or view level, rather than at the column level. This means that any database user with access to a table containing encrypted data will be able to see the data in the clear. To help address this security gap, released Database Vault for 11g, which includes capabilities for controlling access based on multiple factors, such as time of day, IP address, application name, and authentication method. s authorization functionality is highly granular so that access to encrypted columns can be controlled by assigning encrypt and decrypt privileges on a per user level. Plus, these access control features allow a security administrator to secure access to sensitive data at the user level without requiring any changes to the database architecture. With, 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. These privileges can be further restricted by limiting cryptographic operations based on time of day and rate. For example, a security administrator could set a policy that a given user in customer service could decrypt no more than 25 credit cards per hour, and that he or she could decrypt no data between 6:00 pm and 6:00 am. Consequently, organizations can effectively limit the potential damage of a malicious insider. Infrastructure Coverage did not introduce native encryption capabilities until the release of 10g R2, so organizations with 10g R1 and earlier versions of the database can t employ s native encryption capabilities. Further, with s native encryption, data can only be encrypted in one place: in the column of an 10g R2 or 11g database. The reality, however, is that sensitive data is housed and accessed in a host of other areas throughout an enterprise unstructured files, such as PDFs and spreadsheets, applications, Web servers, and more. Further, most enterprises have a mix of databases installed, whether IBM DB2, Microsoft SQL Server,, or Teradata and over the course of its life cycle, a specific piece of data may reside on a number of platforms. For example, a customer record might be created Competitive Brief: SafeNet vs. Native Encryption Page 4 of 10

5 in SQL server, copied to, and finally forwarded to a data warehouse housed in Teradata that is used for business intelligence reporting. Consequently, native 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. Table 2: Version Support + Label + Label + Database Vault + Label + Database Vault + Secure Backup SafeNet 8i 9i 10g R1 10g R2 (limited functionality) (limited functionality) (limited functionality) (limited functionality) 11g The table above outlines the support of s security modules and SafeNet s for various versions of s database. can be used to centrally manage the encryption of sensitive data in all of an enterprise s databases, including 8i, 9i, 10g, and 11g as well as IBM DB2, Microsoft SQL Server, and Teradata. In addition, given 11g s capabilities for employing an external HSM to protect the master key, administrators can use 11g native encryption while employing as the secure key repository. Plus, provides the flexibility to encrypt data at the file level, at the column or field level in databases, the application layer, and during batch-driven data transformation and transaction processes. SafeNet also provides the ability to encrypt information from the moment it enters the enterprise such as in a data center and as it travels within the environment such as out to endpoints. With, organizations can encrypt sensitive data once and have it be secured throughout its life cycle, 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. Competitive Brief: SafeNet vs. Native Encryption Page 5 of 10

6 Table 3: Capabilities Beyond Encryption Extensible Key Management Infrastructure 1 + Label + Label + Database Vault + Label + Database Vault + Secure Backup SafeNet Application-level Encryption File Encryption (outside of ) z/os Integration Integration with POS Vendors SQL Server & DB2 Support Support for RC4, HMAC-SHA1, and RSA Algorithms The table above outlines the support and security modules 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 around the differing integration and administration characteristics of each encryption approach. Set up and Integration In all but the smallest organizations, deploying native 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. By providing an out-of-the-box solution with centralized administration of cryptographic policies and configuration, dramatically reduces implementation time and expenses compared to deploying native encryption. 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. Competitive Brief: SafeNet vs. Native Encryption Page 6 of 10

7 With, integration across various database platforms is automated and transparent to applications. In addition, features these tools and capabilities: o A data discovery tool that can scan databases for sensitive data such as account numbers, credit card numbers, social security numbers, and 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. o Data migration capabilities that automatically configure the database and encrypt all of the data in the columns that have been tagged for encryption. o Application transparency, through support for the creation of triggers and views that hide encrypt and decrypt functions from associated applications. o 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. Persistence Support for Cross Platform Applications Native database encryption from does not provide a solution for encrypting data persistently across heterogeneous database environments or for simultaneously managing database, application, and file encryption. Consequently, this native approach will represent only a fraction of a complex, enterprise-wide initiative for securing sensitive data, one which will require multiple point solutions and present a high degree of administrative complexity. This is compounded by the fact that native encryption essentially represents an island of encryption. Since there are no industry standards for database encryption, each vendor s implementation is unique and does not allow sharing keys or policies. As a result, these approaches prevent the integration of encrypted data between platforms. Given this, the only way to share encrypted data between an database and a Z/OS mainframe, for example, would be to decrypt that data, and then submit it to Z/OS, where it would need to be encrypted again. As a result, the complexity of implementing encryption in a heterogeneous environment is complex and incurs a high processing cost, losing persistence control of data security. The solution was designed from the outset to support heterogeneous enterprise environments, persistence for securing sensitive data encryption at different levels within the infrastructure. With the platform, encryption keys used for one vendor s database can be used for any other system. When data is shared between two vendor s systems, the data does not have to be decrypted and then re-encrypted with a new key. Instead, ciphertext can be securely, and efficiently passed from one system to another. Competitive Brief: SafeNet vs. Native Encryption Page 7 of 10

8 Figure 1: offers a centralized solution for managing keys across an enterprise infrastructure, including Web and application servers, databases, file servers, and more. Key Management With s native database encryption solutions, keys are created and managed on the database server and administrators are tied to using s proprietary techniques and interface for performing these functions. When there are large numbers of database servers in an enterprise, the process of managing keys on each individual database server can quickly become cumbersome and subject to errors. Typically, 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, grows increasingly complex as the number and variety of database servers are deployed throughout an enterprise. The SafeNet 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. Competitive Brief: SafeNet vs. Native Encryption Page 8 of 10

9 Logging and Auditing native encryption only provides very basic logging information, and the log files are cumbersome to consolidate because they are saved locally on each disparate database platform. 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 this information isn t housed centrally, it is very difficult to analyze the information and spot potential threats in a timely manner. provides comprehensive, secure, and centralized logging and auditing of all cryptographic functions and data access events. The 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. 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. Consequently, administrators can more efficiently comply with the logging and auditing requirements of such regulations as the Payment Card Industry Data Standard (PCI DSS). Performance With native 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. 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 further compounds the risk of having keys and encryption managed in a disparate fashion. By offloading cryptography to a dedicated and specialized cryptographic appliance, delivers better performance than s native encryption, especially during batch processing. 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 appliance and are ideally suited for many batch applications. From both a performance and security standpoint, it is typically recommended that organizations offload encryption from database platforms and onto the appliance. However, in some cases, database administrators prefer to handle this encryption locally on the database platform. In these cases, will also support this approach, enabling organizations to employ cryptographic processing on the database server itself. Competitive Brief: SafeNet vs. Native Encryption Page 9 of 10

10 Conclusion When native 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 great deal of administrative complexity, particularly in larger enterprises. With SafeNet, security administrators can leverage a single, centralized encryption solution, not only for encrypting data in multiple databases, but other database platforms, applications, files, and more. As a result, provides significant advantages both in delivering the highest level of security and ease of manageability. About SafeNet In 2007, SafeNet was acquired by Vector Capital, a $2 billion private equity firm specializing in the technology sector. Vector Capital acquired Aladdin in March of 2009, and placed it under common management with SafeNet. Together, these leading global companies are the third largest information security company in the world, which brings to market integrated solutions required to solve customers increasing security challenges. SafeNet s encryption technology solutions protect communications, intellectual property and digital identities for enterprises and government organizations. Aladdin s software protection, licensing and authentication solutions protect companies information assets and employees from piracy and fraud. Together, SafeNet and Aladdin have more than 50 years of security expertise in more than 100 countries around the world. Aladdin is expected to be fully integrated into SafeNet in the future. For more information, visit or SafeNet Corporate Headquarters 4690 Millennium Drive Belcamp, MD Tel: Tel: Sales TTY Users: FAX: SafeNet, Inc. All rights reserved. SafeNet and the SafeNet logo are registered trademarks of SafeNet, Inc. All other product names are trademarks of their respective owners. Competitive Brief: SafeNet vs. Native Encryption Page 10 of 10