|
|
|
|
Abstract
Many consider the insider threat to represent the greatest vulnerability and
exposure to enterprise resources. Database attacks are on the rise even as the
risks of data breaches are increasing. Several industries must deal with
legislation and regulation on data privacy. This paper will review how to
protect sensitive data wherever the data resides: at application-level; within
databases, files and operating systems; and in storage. We will address the
management of associated encryption keys, access control and reporting --
helping organizations mitigate risk and reduce costs, while protecting consumer,
employee and partner information. The approach safeguards information by
cryptographic protection from point-of-creation to point-of-deletion, to keep
sensitive data locked down across applications, databases, and files --
including ETL data loading tools, FTP processes and EDI data transfers. This
design principle optimizes placement of functions for encryption and security
enforcement among the modules of a distributed computer system. The guiding
concept, continuous protection of data, suggests that encryption functions
placed at low levels, and typically implemented with native platform-based
toolkits, may be redundant and of little value when compared with the cost of
supporting them at that low level. The principle suggests that Enterprise levels
of Data Protection and Key Management may be cost effective in many
configurations. We also include a set of best practices that ensure not only a
successful PCI audit, but a sustained improvement in the security and protection
of sensitive data, and the limiting of theft and its costly aftermath. Whether
you decide to implement encryption inside or outside the data store, we
recommend that:
We introduce a system-solution example that complies with these requirements and provides a cost-effective implementation.
The Business Problem
The business problem of IT security is, however, more severe than the technical problems. Because current user access control solutions involve different components for authentication, authorization and administration (AAA), a solution can fail at any of these components. For example, one required component upgrade may no longer interoperate with another component, alienating users, leading to lost business, and perhaps, to security breaches. The result is that IT managers face continual, onerous cycles of development and maintenance. In short, the business problem of IT security is to prioritize that which simplifies and enhances the user experience, to support revenue and revenue growth, while reducing enterprise liability and expenditure.
Today’s IT security solutions will need to be continually updated, however, in ever faster cycles, to remain effective -- more frequent patches, upgrades, support, and perhaps replacement -- to provide the same level of value tomorrow. To date initiatives has focused on data in backup and storage systems. However regional and vertical mandates - such as U.S. state breach notification laws (e.g., California Senate Bill 1386), the European Union Data Privacy Directive, Japan's Personal Information Protection Act and the Payment Card Industry standard - are driving companies to take an aggressive stance on protecting data-at-rest. Organizations are seeking to avoid the financial and brand integrity costs associated with compromised data, while positioning themselves to take advantage of "safe harbors” which often protect companies from penalties if appropriate steps have been taken to protect sensitive information.
Security Gaps in Enterprise Security
Continual development and maintenance not only make IT security more expensive than it appears. They also make IT security solutions less secure, by increasing the number and the potential extent of security gaps that may exist at any time. In a broad generalization, two types of attacks can exploit security gaps: network and data attacks. A network attack tries to interfere with client and/or server systems in transactions, in terms of their communication processes. For example, an attack may try to gain or deny access, read files, or insert information or code that affects communication. Data attacks try to tamper with, and/or read, data in files or messages, by deleting, changing, reading, or inserting false data.
Trust, Risk and the Weakest Link
The conventional risk model used in IT security is that of a linked chain -- the system is a chain of events, where the weakest link is found and made stronger. We should question this approach because it fails to solve the problem of how to provide a secure IT system, even when a recognized weak link is made stronger. The strengthening of any link, even if made much stronger, would not make the system less vulnerable, and might make the system more vulnerable, because the security of the system would still depend on a weakest link (which might be the newly “hardened” link). Further, such solutions are actually based on the illogical presumption that "no part will fail at any time" -- if a critical part fails, the system fails. In short, there is an inevitable single point-of-failure -- that weakest link. Making the link stronger will not make the single point-of-failure go away -- at most it may shift it.
The Need to Know and the Segregation of Duties
The technical objective of information security may be stated as: “avoid unnecessary concentration of information and power; allow enough concentration to make a task possible to execute." An all-knowing, all-powerful entity would be the perfect attacker and could break any security measure. This is why we oftentimes talk about "need to know" and "separation of powers." We name these principles, respectively, information granularity and power granularity. These concepts mean that information should not be provided in its entirety to a single entity. This is the reason business information and power should be carefully distributed, for example, among local employees, the office management, the enterprise management and the customer. And, contrary to what many advocate for IT security solutions, there should be no single point of control in an IT security system. This can be the single point of failure -- no matter how trustworthy a single point of control is, its failure or compromise leaves no recourse for recovery.
A Comprehensive Approach to Enterprise Data Protection
New business models rely on open networks with multiple access points to conduct business in real time, driving down costs and improving response times to revenue generating opportunities. By leveraging the ability to quickly exchange critical information and improve their competitive position, enterprises are introducing new vulnerabilities that can be exploited to gain unauthorized access to sensitive information. By establishing appropriate enterprise architecture key management, with encryption at application-, database- and file-level, the organization maximizes benefits while minimizing potential pitfalls to operational processes farther down the line. Each type of application and storage method may need a different approach to lock down data.
This paper reviews a practical implementation of a transparent approach to keep sensitive data locked down, utilizing policy driven encryption and key management for data-at-rest and in-transit across enterprise systems. The encryption solution operates at the field, record and file levels to suit the operational needs for each type of application and data storage system.
The Primary Vulnerability of the Database and File Level Encryption
The primary vulnerability of database- and file-level encryption is that they do not protect against application-level attacks -- the encryption function is solely implemented within the DBMS. The application protection solution institutes policies and procedures that enable software developers to effectively build security into enterprise applications, employing external filters to block attacks.
Hackers, crackers, internal attacks and business evolution are facts of life; as a result, security threats, leaks and lack of scale will constantly plague user access control solutions based on password lists, access control databases, and shared secrets.
With more users, more applications and more revenue depending on Web resources, it is more important than ever before to provide remote user access while protecting the enterprise's resources. With multiple administrative domains and the need for quick response to market changes, managers often need centralized user administration and control delegation to be effective. For end-to-end web security, consider implementing application-layer encryption security to protect PINs and other sensitive data in communications between web browsers and hosts. App-level protection ensures sensitive information is protected from its point of entry until it is validated or used by the target applications. This addresses an inherent limitation in most Secure Socket Layer (SSL) implementations that terminate encryption at the web servers and create the potential exposure of clear text in the form of sensitive user credentials and business transactions.
A Framework that Includes the Following Components
This security solution helps companies protect themselves through a framework that includes the following components:
According to Gartner, Inc.: "Protecting customer data is much less expensive than dealing with a security breach in which records are exposed and potentially misused."
Specifically, Gartner estimates that compromises involving more than 1 million accounts will be close to $50 per account. Smaller breaches carry significant costs, as well -- in 2002, Gartner estimated that the cost per account will be closer to $1,500 per account, not including market cap fluctuation, when about 5,000 accounts were compromised. (Source: "Data Protection is Less Costly than Data Breaches," John Pescatore and Avivah Litan. September 16, 2005).
The Challenge to Get the Parts Together
The challenge is to get the parts together -- expertise in database encryption, application security and file encryption to be applied in the integrated solution:
Consolidation of Policy Management
There is a real need, thus, to bring together policy, management and implementation considerations influencing security assurance for each particular IT solution. Other security principles such as redundancy, diversity, no single point of failure, and least-privilege also need to be used in defining the specific requirements for a secure IT system. Such requirements need to be clearly formulated, decidable and, as much as possible, complete. An end-to-end design is important to assure effectiveness, because attacks and errors are hard to detect and prevent at interface points. Because there are no paper trails, non-repudiation is also essential for Internet and IT security systems. Non-repudiation is often defined as providing proof that a particular act had actually been performed -- example, as demonstrated by a trusted time-stamp. However, we may view the concept of non-repudiation much more strictly -- as in preventing the effective denial of an act. The first definition describes the component quality used in the IT system, where a weak component may compromise the whole system. The stricter definition focuses on the need to continuously evaluate all potential and existing threats, verifying any additional security design features that might be necessary to mitigate risks stemming from the most likely or most damaging threats to the customer environment, and eventual changes in that environment.
An Effective Data Protection Solution
An effective data protection solution needs to deal with an extensive list of security properties. A secure IT system must not "pop" like a balloon when subjected to an attack, or fail silently, leaving no trace of the attack. There should be no single point of failure. There must be multiple channels of communication and correction, even if the channels are not 100% independent. We intuit an increase in reliability by using multiple channels of information. This correlates well with our perception of how trust may be defined -- we know from experience that we trust more when we have more evidence to support trust. In an IT security system, we define trust as qualified reliance on information, based on factors independent of that information. More precisely, trust is that which is essential to a communication channel but cannot be transferred using that channel.
A True End-To-End Encryption Solution
To cope with the accelerated risks and obsolescence typical of IT security solutions, enterprises need an End-To-End IT security solution that can provide shorter, less expensive, deployment, development and maintenance cycles. The solution should minimize the probability of patches, upgrades and support during the lifetime of an IT security system. The solution also needs to integrate core security services and eliminate known or costly weak links such as password lists, access control databases, shared secrets, and client-side PKI.
What are these core security services, what else is required in order to solve both the technical and business problems of IT security? We first need to look at the security gaps that can be exploited, and what security services are necessary to prevent such breaches. Second, we need to realize that it is the combination, and interoperation, of security properties that can provide the resiliency required of a secure IT system. An IT security system needs to have the equivalent of several independent, active barriers, controlling different security aspects but complementing each barrier’s function. Lastly, an IT security solution needs to be highly scalable, supporting anywhere from hundreds to millions or tens of millions of users, compatible with the current infrastructure and standards, and extensible.
Security Management Must be Based on a Security Policy
Several key elements of a comprehensive security policy:
Centralized Administration of Security Policies
In short, with centralized user administration, security policies can remain consistent, easy-to-manage and audit. Centralized administration of users is, thus, a common operational requirement in networked environments. However, the need for centralized user administration does not mean the absence of delegation. Delegated or distributed administration is a requirement for medium-size to large enterprises, where administrative domains within an organizational unit or divisional lines are common. It is unrealistic to have one group responsible for administration for the entire enterprise. Delegated administration is also necessary for B2B/partner e-business models (e.g., a partner company administers its own employees in a constrained administrative domain within your infrastructure). Delegated administration is frequently implemented by means of control delegation, defined as allowing local sub-domain control within a domain. The need for centralized user administration also does not mean a need for centralized control in the security solution that provides it. In fact, we need to avoid the seemingly desirable scenario of a single point of control, which The Continuously Secure Data System recognizes as a single point of failure. Thus, to achieve central user administration and to provide control delegation, an IT security solution should use a distributed, highly non-local system, transparent to the users of the system. In short, one needs a distributed central control system, where different authority subdomains can be activated, suspended and revoked by a central administration.
Best Practice for Protecting Data-at-Rest
In order to mitigate this increased risk, the use of encryption is increasingly being required or recommended as a best practice for protecting data-at-rest. Financial services institutions, merchants that accept credit cards, health care services enterprises, and government agencies that maintain confidential personal information are required to consider use of encryption to protect their personally identifiable information PII. System performance scalability is critical to meeting the needs of an enterprise. Introducing a variable to the infrastructure that limits scaling in a predictable manner can “bottleneck” the flow of data and prevent the organization from achieving forecasted return on its IT investment. Encryption should be implemented to leverage the existing, high-performance infrastructure and scale, not impede overall performance.
The Continuously Secure Data Protection System
Our vision is that security needs to “own” an end-to-end property; otherwise, security breaches are possible at security point-interfaces, which may allow gaps in protection. As it is clear from the previous discussion, authentication and authorization are not sufficient for this end-to-end E2E purpose.
Providing an E2E-encryption solution for IT security and user access control, the Continuously Secure Data System establishes the medium to integrate a number of core capabilities in IT security solutions including:
The Continuously Secure Data System also recognizes the need to bind a system of trust to IT security solutions, to communicate trust not only machine-to- machine, but also human–to-machine. We need to provide these capabilities in a scalable system, supporting hundreds of users, to millions or tens of millions, and which is compatible with existing infrastructure, current & evolving Internet standards, with as much backward compatibility as possible. Finally, the Continuously Secure Data System must take business drivers into account -- quicker and less expensive deployment, development and maintenance cycles; less need for integration with other (changing) products; ease-of-use; and close back-end to front-end integration so that legacy systems can be reliably used.
Policy-Driven Data Protection
Such data protection solution helps ensure that data is encrypted everywhere it may reside, with minimal intrusiveness and maximal separation of duties. Application code and database schemas are sensitive to changes in data type and data length. Our policy-driven solution allows transparent data-level encryption that retains data field type or length. Data Transformation and Protection DTP can be added to reduce the need for changes to data structures and applications. The field-level encryption approach is very useful when dealing with EDI/FTP/flat files being transferred between discrete systems. At no time is sensitive data in an unencrypted state at-rest on any system.
How to Encrypt Data if a Binary Format is not Desirable
If data is to be managed in binary format, “varbinary” can be used as the data type to store encrypted information. On the other hand, if a binary format is not desirable, the encrypted data can be encoded and stored in a VARCHAR field. There are size and performance penalties when using an encoded format, but this may be necessary in environments that do not interface well with binary formats, if support for transparent data-level encryption is not used. In environments where it is unnecessary to encrypt all data within a data store, a solution with granular capabilities is ideal. Even if only a small subset of sensitive information needs to be encrypted, additional space will still be required if transparent data-level encryption is not used. Secure data-level encryption for data-at-rest can be based on block ciphers. The proposed solution is based on transparent data level encryption with Data Type Preservation that Does Not Change ASCII Data Field Type or length. The solution provides a cost effective implementation, avoiding changes of Millions of Lines of Business Code in larger enterprise information systems. The solution also provides an effective last line of defense: selective column-level data item encryption, cryptographically enforced authorization; key management based on hardware or software, secure audit and reporting facility, and enforced separation of duties. The method is cryptographically strong, works with any DBMS and OS, works with different character sets, no application or database changes, no programming language dependence, fail safe, requires no DBA intervention. Data loader functions normally and queries function normally. Enhanced search capabilities based on partial encryption of data can easily be added with this approach.
The Optimal Place to Encrypt Data will Always Depend on the Situation
Give careful consideration to the performance impact of implementing a data encryption solution. First, enterprises must adopt an approach to encrypting sensitive fields only. Such a solution allows the enforcement module to be installed with the file system, at the database table-space level, or at column-level to meet different operations needs. It allows the encrypt/decrypt of data as the database process reads or writes to its database files. This enables it to perform cryptographic operations in file system block segments, instead of in individual cell, rows or columns.
Allow Optional Granularity and Implementation Layers for the Data Encryption
Compared to triggers, stored procedures, external API calls and network round-trips, there is very little overhead in some operational situations. Furthermore, this solution can decrypt data before it is read into the database’s cache. Subsequent hits of this data in the cache neither incur additional overhead. Nor does this architecture diminish database index effectiveness. It depends on the situation if this exposure will meet your security requirements.
Encrypt a Few Very Sensitive Data Elements
Encryption, by its nature, slows most SQL statements. With care, the amount of overhead should be minimal. Also, encrypted data will have a significant impact on your database design. In general, it is best to encrypt a few very sensitive data elements in a schema, like Social security numbers, credit card numbers, patient names, etc. Some data values are not good candidates for encryption -- i.e., Booleans (true and false), or other small sets like integers 1-10. These values, and column names, may be easy to guess, so you want to decide whether encryption is really useful. Creating indexes on encrypted data is a good idea in some cases. Exact matches and joins of encrypted data will use the indexes you create. Since encrypted data is essentially binary data, range checking of encrypted data would require table scans. Range checking will require decrypting all the row values for a column, so avoid it if it is not tuned appropriately, with an accelerated search index.
Searching for Encrypted Value Within a Column
Searching for an exact match of an encrypted value within a column is possible, provided the same initialization vector is used for the entire column. On the other hand, searching for partial matches on encrypted data within a database can be challenging and may result in full table scans if support for accelerated index-search on encrypted data is not used. One approach to performing partial searches, without prohibitive performance constraints -- and without revealing too much sensitive information -- is to apply an HMAC to part of the sensitive data and store it in another column in the same row.
Encrypted Columns Can be a Primary Key
Encrypted columns can be a primary key or part of a primary key, since the encryption of a piece of data is stable (i.e., it always produces the same result), and no two distinct pieces of data will produce the same cipher text, provided consistent use of the key and initialization vector. However, when encrypting entire columns of an existing database, depending on the data migration method, database administrators might have to drop existing primary keys, as well as any other associated reference keys, and re-create them after the data is encrypted. For this reason, encrypting a column that is part of a primary key constraint is not recommended if support for accelerated index search on encrypted data is not used. Since primary keys are automatically indexed, there are also performance considerations, particularly if support for accelerated index-search on encrypted data is not used.
Plan Before Encrypting Information in Indexed Fields
We create indexes to facilitate the search of a particular record, or set of records, from a database table. Carefully plan before encrypting information in indexed fields. If you do not employ accelerated database indexes, look-ups and searches in large databases may be seriously degraded by the computational overhead of decrypting the field contents. This can prove frustrating at first because administrators often index fields that must be encrypted – Social Security numbers or credit card numbers. New planning considerations will need to be made when determining what fields to index if accelerated database indexes are not used. Indexes are created on a specific column or a set of columns. When the database table is selected, and WHERE conditions are provided, the database will typically use the indexes to locate the records, avoiding the need to do a full table scan. In many cases, searching on an encrypted column will require the database to perform a full table scan regardless of whether an index exists. For this reason, encrypting a column that is part of an index is not recommended, if support for accelerated index-search on encrypted data is not used.
When to Use Initialization Vectors
When using CBC mode of a block encryption algorithm, a randomly generated initialization vector is used and must be stored for future use when the data is decrypted. Since the IV does not need to be kept secret it can be stored in the database. If the application requires having an IV per column, which can be necessary to allow for searching within that column, the value can be stored in a separate table. For a more secure deployment, but with limited searching capabilities if support for accelerated index-search on encrypted data is not used, an IV can be generated per row and stored with the data. In the case where multiple columns are encrypted, but the table has space limitations, the same IV can be reused for each encrypted value in the row, even if the encryption keys for each column are different, provided the encryption algorithm and key size are the same.
The Use of Initialization Vectors Together with Certain Encryption Modes
If you are using AES-CTR Advanced Encryption Standard (AES- CTR) and DTP is functionally equivalent to a stream cipher; it generates a pseudo-random cipher stream that is XORed into plaintext to form ciphertext. The cipher stream is generated by applying the AES encrypt operation on a sequence of 128-bit counter blocks. Counter blocks, in turn, are generated based on record sequence numbers (in the case of TLS), or a combination of record sequence and epoch numbers (in the case of DTLS.) AES Counter Mode is typically used as a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS): It should be noted that although the client and server use the same sequence number space, they use different write keys and counter blocks. There is one important constraint on the use of counter mode ciphers: for a given key, a counter block value MUST never be used more than once. This constraint is required because a given key and counter block value completely specify a portion of the cipher stream. Hence, a particular counter block value when used (with a given key) to generate more than one cipher text leaks information about the corresponding plaintexts. Given this constraint, the challenge then is in the design of the counter block.
Database File Encryption will Leave your Live Database in Clear
This solution's policies can selectively encrypt individual files and do not require that “the entire database” be encrypted. Database administrators can assign one or more tables to a tablespace file -- policies may then specify which tablespaces to encrypt. In this way, you encrypt only the database tables that have sensitive data, and leave the other tables unencrypted. This said, in some situations, some customers choose to encrypt all database files because there is little performance penalty and no additional implementation effort in doing so.
Central Encryption Appliances vs. Distributed Encryption Engines
Network-attached encryption (NAED), as a network-attached encryption appliance was implemented by my teams at IBM, involving work with nCipher, Eracom and Chrysalis (SafeNet) starting in 1994. Our research and benchmarking is reported here. A NAED is a hardware device that resides on the network, houses the encryption keys and executes all crypto operations. This topology has the added security of physically separating the keys from the data. However, this added security comes at a heavy price; performance can be 10-1000 times less efficient than alternative methods. SAN /NAS proxy encryption performs close to line-speed, but it is less feasible from a scalability perspective in a terabyte configuration compared to a host based file encryption solutions using software. The heavy price paid for such network-attached encryption? Benchmarks reveal a throughput of between 440 and 1,100 row-decryptions per second. This example debunks the generally held myth that NAEDs off-load work from the database. Further, a network-attached engine does not provide high availability, unless multiple engines are configured into a high availability cluster.
An Off-Load of Work with the Network-Attached Appliance?
The short answer is “no,” there isn’t an off-load of work since this solution must perform one encryption operation in the database, which is the same for other topologies, in addition to the encryption functions at the NAED. When a user requests secured data, the security system manages the process of retrieving encrypted data from the database, ensuring that the request is from an authorized user, and performing the decryption process. In this topology, the encryption agent handles the request and retrieves the encrypted data from the database. It sends the encrypted data over the network to be decrypted by the NAED. Inside the NAED are the keys and algorithms to decrypt the data. Once decrypted, however, we have clear-text information that needs to be sent back over the wire to the database server. This requires that we re-secure the information for transit, typically through a secure communication process such as SSL. When the data arrives at the agent on the database server, it has to be returned to clear-text, and then it is served up to the calling application.
Exposing an Encryption Appliance Will Introduce an Additional Point of Attack
An integrated central and distributed solution can protect from this vulnerability. Denial-of-service attacks are another related concern with network-attached engines. Since the engine is available over TCP/IP, an attacker could flood the engine with traffic and block legitimate cryptographic requests. If required information can’t be decrypted, then a customer may not be able to place an order or access account information. If the database stores encrypted records that are critical for business operation, a successful denial-of-service attack could have severe consequences.
Scalable, Centralized Lifecycle Cycle Management for Encryption Keys
Well-worn though it may be, the saying that “the chain is only as strong as its weakest link” clearly applies to efforts of organizations to secure sensitive data and ensure data privacy. Keys are the foundation of all encryption-based security solutions. If a hacker, internal or external, gains access to your private keys, the security of all data formerly protected by encryption is gone. Not reduced—gone. That is a risk currently assumed by companies that store private keys used for data encryption in insecure locations, whether Web, application, or database servers. These servers are typically not secure because there are many people with access to them, the servers are often misconfigured, and they often aren’t kept up to date with the latest security patches. Additionally, keys are usually stored in an easily readable plaintext format. Even organizations that make efforts to protect private keys with passwords find that these passwords aren’t protected properly, are chosen poorly, and usually must be shared between multiple administrators. These keys are vulnerable to discovery. An intruder who compromises your keys can launch “eavesdropping” attacks using the stolen key to hack into vital data repositories. This could result in data theft, loss of privacy for your employees and customers, and damages to brand credibility and customer confidence. Stringent security defenses protect each sensitive element of the system -- each protected by its own unique, randomly generated key. Private keys are stored encrypted with several Triple-DES encryption keys that are nested.
Effectively and Efficiently Manage Encryption Keys
Our encryption key management solution enables organizations to effectively and efficiently manage encryption keys generated by disparate enterprise applications, helping to guarantee the seamless flow of protected information, with minimal intrusiveness. One of the primary elements of modern cryptography most often recommended by regulations and industry standards is the concept of a data encryption key. Encryption requires that a key be used to initially encrypt a piece of sensitive information and is subsequently required to decrypt that information when needed by applications. Not only is it important to effectively protect this key against misuse, it is also important to ensure that the key is quickly accessible by applications when needed. Traditionally, applications that use encryption technology have had to handle the management of encryption keys on their own—creating a host of incompatible solutions. The Key Manager is designed to help companies alleviate these problems by centralizing the lifecycle management of encryption keys across their information infrastructure. Key Manager works across a wide variety of operating platforms and development environments to ease integration and ongoing administration of applications that use encryption. It is also easily integrated into retail point-of-sale terminals, reservation systems, payment systems and other applications to protect sensitive information such as credit card magnetic stripe data and consumer data at point of entry.
Protect at the Point of Entry and Throughout the Information Lifecycle
The capability to protect at the point of entry helps ensure that the information will be both properly secured and fully accessible when needed at any point in its enterprise information lifecycle. Regulatory compliance and industry security standards such as the PCI Data Security Standards DSS continue to motivate large corporations to develop and adopt an encryption strategy for their high-risk data stores and applications. Recent high-profile security breaches exposing personal identity information have made the need for better information protection obvious to the public. However, effectively implementing an encryption strategy has traditionally required application developers and data architects that possess a high level of security knowledge. Ongoing administration and management of encryption technology is also a major concern as more applications and data stores require it in order to protect data. The Key Manager solution provides a secure storage of encryption keys. All keys in the key vault database are encrypted using a protected master encryption key. This multi-layer hierarchy of keys ensures the highest level of protection against attack with a hierarchy in which each key is protected by a parent key. Authentication and authorization for system administrators is performed using the included Access Manager. Access Manager is designed to provide the necessary separation of duties and administrator roles required for strong security over the Key Manager system as well as to meet specific PCI standard requirements.
How to Reduce the Risk of Memory Attacks
Memory attacks may be theoretical, but cryptographic keys, unlike most other data in a computer memory, are random. Looking through memory structures for random data is very likely to reveal key material. Well made libraries for use as Local Encryption Services go to great efforts to protect keys even in memory. Key-encryption keys are used to encrypt the key while it is in memory and then the encrypted key is split into several parts and spread throughout the memory space. Decoy structures might be created that look like valid key material. Memory holding the key is quickly zeroed as soon as the cryptographic operation is finished. These techniques reduce the risk of memory attacks. Separate encryption can also be used for different data. These encryption keys can be automatically rotated based on the sensitivity of the protected data. Dedicated Encryption Services are also vulnerable to memory attacks. However, a well made Dedicated Encryption Service runs only the minimal number of services.
Secure Key Back Up
A weak link in the security of many networks is the backup process. Often, private keys and certificates are archived along with configuration data from the backend servers. The backup key file may be stored in clear text or protected only by an administrative password. This password is often chosen poorly and/or shared between operators. To take advantage of this weak protection mechanism, hackers can simply launch a dictionary attack (a series of educated guesses based on dictionary words) to obtain private keys and associated certificates. Private keys should never be exported from the product in clear text. The backup file should be password protected and then encrypted using an internal key. When private keys are backed up from the solution platform, they should be encrypted twice, once using an administrative backup key and a second time with the internal Repository key. This type of key management makes it impossible for attackers to launch dictionary attacks and other password-guessing techniques aimed at exposing an administrative password and unlocking the backup file. Your private keys can never be exported in clear text and cannot be released without cracking several layers of triple-DES encryption, ensuring secure preservation of key data in all backup and storage activities.
An Optional Hardware Security Module When FIPS 140-2 Level 3 is Required
Best practice -- taking response time, added overhead and path length into account, that always occur invoicing a remote hardware routine invocations -- network-attached encryption is to use the HSM for optional key management operations. This is the only general solution that proves to be scalable in an enterprise environment. The solution includes an optional, tamper-resistant hardware security module (HSM), including HSM's certified to FIPS 140-2 Level 3, the widely accepted standard of government-specified best practices for network security. Private keys are generated and stored in encrypted form within an HSM. Keys stored in the HSM are protected from physical attacks and cannot be compromised even by stealing the HSM itself. Any attempt to tamper with or probe the card will result in the immediate destruction of all private key data, making it virtually impossible for either external or internal hackers to access this vital information. If we compare the response time for a query on unencrypted data with the response time for the same query over the same data (some or all of it encrypted), response time over encrypted data will increase due to the cost of decryption as well as additional overhead and path length that always occur with a remote hardware routine invocations (Network-attached encryption). On z/OS there are ways to avoid this by using native z/OS silicon implementation of encryption algorithms.
Centralized Control of all Key Management Operations
The Key Manager solution provides a centralized administration of all key management operations across applications and data stores that employ encryption, to help simplify the deployment and ongoing administration of the overall encryption solution. Key lifecycle management includes policy-based key generation, retrieval, automated expiration, distributed and local caching, central archival and restoration, as well as audit logging. It also includes robust fail-over and availability features to help ensure maximum uptime for critical applications that require access to keys. The solution the use of standard database technologies combined with strong security protections. And it eases implementation by presenting simple programming interfaces for developers, eliminating the need to understand keys or their management. This reduces development time as well as implementation risks.
A Secure Mechanism for Key Rotation
Data privacy solutions should also include an automated and secure mechanism for key rotation, replication, and backup. One easy solution is to store the keys in a restricted database table or file. But, all administrators with privileged access could also access these keys, decrypt any data within your system and then mask their intrusion/attack. Database security in such a situation is based not on industry best practice, but on an employee honor code. If your human resources department locks employee records in file cabinets where one person is ultimately responsible for the keys, shouldn’t similar precautions be taken to protect this same information in its electronic format? All fields in a database and different encryption keys do not need the same level of security. With tamper-proof hardware and software implemented, the encryption being provided by different encryption processes utilizing at least one process key in each of the categories master keys, key encryption keys, and data encryption keys, the process keys of different categories being held in the encryption devices; wherein the encryption processes are of at least two different security levels, where a process of a higher security level utilizes the tamper-proof hardware device to a higher degree than a process of a lower security level; wherein each data element which is to be protected is assigned an attribute indicating the level of encryption needed, the encryption level corresponding to an encryption process of a certain security level. With such a system it becomes possible to combine the benefits from hardware and software based encryption. The software-implemented device could be any data processing and storage device, such as a personal computer. The tamper-proof hardware device provides strong encryption without exposing any of the keys outside the device, but lacks the performance needed in some applications. On the other hand the software-implemented device provides higher performance in executing the encryption for short blocks, in most implementations, but exposes the keys resulting in a lower level of security.
Support for PCI Credit Card Key Management Requirements
The solution supports PCI key management requirements and helps companies meet these guidelines. A robust, open architecture leverages proven cryptographic toolkits and is built using industry-standard security practices and protocols. The product also integrates with other security technologies including authentication. Many companies facing the PCI compliance issue are wondering how they can enforce the PCI regulations without significantly increasing staff and IT costs. With the potential result of non-compliance being severe damage to the financial health and the brand reputation of an enterprise, organizations want to protect themselves to the fullest while minimizing necessary costs. After an initial PCI compliance audit is completed, there are a host of initiatives organizations should consider in order to stay in front of emerging security threats and evolving compliance mandates. This session offers an overview of the PCI mandate, including which organizations are affected, which specific rules pertain to encryption, and an overview of encryption solutions that help address these mandates. Also included is a case study outlining a sample deployment, a set of best practices that ensure not only a successful PCI audit, but a sustained improvement in the security of sensitive data that can help mitigate the threats of data theft and its costly aftermath.
Conclusion
This paper presents experience from many years of research and practical use of cryptography for safeguarding information from the point of acquisition to the point of deletion. We use the key concepts of security dictionary, type-transparent cryptography, and propose solutions on how to transparently store and search encrypted database fields. We showed that the hybrid database encryption solution is the most successful offering for most application environments. This paper presented a design principle that helps guide placement of functions for encryption and security enforcement among the modules of a distributed computer system. The principle suggests an enterprise approach to data protection. Whether you decide to implement encryption inside or outside the data store, we recommend that encrypted information should be stored separately from encryption keys, strong authentication should be used to identify users before they decrypt sensitive information, access to keys should be monitored, audited and logged, sensitive data should be encrypted end-to-end, while in transit in the application, and while in storage in enterprise data stores. We present this solution as an example of a system that complies with these requirements, and provides a cost-effective implementation. Sensitive data is never in an unencrypted state at-rest on any of the systems, including temporary files and tables.
Ulf T. Mattsson is the CTO of Protegrity. His extensive IT and security industry experience includes 20 years with IBM as a manager of software development and a consulting resource to IBM's Research and Development organization, in the areas of IT Architecture and IT Security.
