Cybercriminals are opportunists. They steal information from wherever it's easiest to reach. They have approached data theft in a methodical way, starting at the bottom of the technology stack and working their way up to the top – the applications layer.
This is evident by looking at the initial and revised versions of the Payment Card Industry's Data Security Standard (PCI DSS). The initial version covered the network and databases. Criminals first attacked the networks and, after learning their lessons, most companies developed effective means to protect their networks. The cyber thieves then started going after databases, then data in transit over wireless networks; note the revision to the PCI DSS 1.1 standard. Next they began accessing data in transit within the enterprise, a problem that has yet to be enforced by the PCI DSS as a requirement. It is expected that the criminals will go after encryption keys next, giving them the “keys to the kingdom.”
But data can be effectively secured, in many cases, from the top of the stack down starting with applications themselves. Web and software application firewalls can go a long way toward helping, and securing the data itself may keep cybercriminals at bay.
Encryption and key management are effective weapons in the security arsenal for data in applications, databases and files. But as with any technology, issues arise that require vigilant oversight. The amount of information to potentially be encrypted and decrypted increases exponentially, leading to a corresponding encryption key management challenge.
Keys proliferate exponentially as you manage the data encryption lifecycle. If not managed properly, a new problem emerges -- how to control and protect access to the keys to assure that they don't get into the wrong hands and assure they are available when needed to unlock data.
Typical landscape
Many enterprises that handle private or confidential data have it stored in plain text in multiple locations throughout the enterprise. There are applications that handle “in-flight” data, sending and receiving data from external trading partners or other entities, and applications that handle static data, or data at rest.
The encryption and decryption of sensitive data distributed throughout the enterprise requires keys and certificates that must be managed across applications, computers and networks in a way that does not compromise security. Additionally, user and application access to these resources must be controlled, managed and audited so that authorized access is quick and reliable, while malicious attacks are thwarted. And, of course, a comprehensive approach to key management also must ask the question: “Who guards the guards?” The administration of encryption keys must itself have built-in protection against internal attack. And they must be rotated regularly and archived for future use.
Best practices
Centralize key management. The more data you encrypt, the more difficult it becomes to effectively manage proliferating keys. The most effective solutions available are designed to balance two equally important, yet opposing objectives: Keep keys safe from unauthorized exposure and make sure they are available when you need them for authorized use. Best practice calls for a centralized key manager that generates, distributes, rotates, revokes and deletes keys to enable encryption and to allow only authorized users to access sensitive data; a solution that rotates keys without requiring you to re-encrypt your data.
Centralize key management with localized encryption. Best practice calls for a hub-and-spoke architecture for centralized key management and localized encryption. Encryption and decryption nodes may exist at any point within the enterprise network. Spoke key management components are easily deployed to these nodes and integrate with the local encryption services.
Once the spoke components are active, all encryption and decryption of the formerly clear text data is performed locally, thus minimizing the risk of a network or single component failure having a large impact on the overall data security operation.
Asymmetric algorithms provide a high level of security. Rather than using a single secret key, asymmetric algorithms use a public key to encrypt data and a related private key to decrypt data. Once data is encrypted with the public key, only the private key can decrypt the data. This greatly reduces the key management requirements, since both parties no longer need to share the same, secret key. The drawback to asymmetric algorithms is they are very computationally expensive to implement. They are only suitable when encrypting a small amount of data.
Centralize key management with tokenization. Some key management solutions can enable tokenization models that intercept the data you want to protect and replace it with tokens. With tokenization, a token – or surrogate value – is returned and stored in place of the original data. The token is a reference to the actual cipher text, which is stored in a central data vault. Tokens can be safely used by any file, application, database, or backup media throughout the enterprise, minimizing the risk of exposing the data, and allowing business and analytical applications to work without modification.
This is evident by looking at the initial and revised versions of the Payment Card Industry's Data Security Standard (PCI DSS). The initial version covered the network and databases. Criminals first attacked the networks and, after learning their lessons, most companies developed effective means to protect their networks. The cyber thieves then started going after databases, then data in transit over wireless networks; note the revision to the PCI DSS 1.1 standard. Next they began accessing data in transit within the enterprise, a problem that has yet to be enforced by the PCI DSS as a requirement. It is expected that the criminals will go after encryption keys next, giving them the “keys to the kingdom.”
But data can be effectively secured, in many cases, from the top of the stack down starting with applications themselves. Web and software application firewalls can go a long way toward helping, and securing the data itself may keep cybercriminals at bay.
Encryption and key management are effective weapons in the security arsenal for data in applications, databases and files. But as with any technology, issues arise that require vigilant oversight. The amount of information to potentially be encrypted and decrypted increases exponentially, leading to a corresponding encryption key management challenge.
Keys proliferate exponentially as you manage the data encryption lifecycle. If not managed properly, a new problem emerges -- how to control and protect access to the keys to assure that they don't get into the wrong hands and assure they are available when needed to unlock data.
Typical landscape
Many enterprises that handle private or confidential data have it stored in plain text in multiple locations throughout the enterprise. There are applications that handle “in-flight” data, sending and receiving data from external trading partners or other entities, and applications that handle static data, or data at rest.
The encryption and decryption of sensitive data distributed throughout the enterprise requires keys and certificates that must be managed across applications, computers and networks in a way that does not compromise security. Additionally, user and application access to these resources must be controlled, managed and audited so that authorized access is quick and reliable, while malicious attacks are thwarted. And, of course, a comprehensive approach to key management also must ask the question: “Who guards the guards?” The administration of encryption keys must itself have built-in protection against internal attack. And they must be rotated regularly and archived for future use.
Best practices
Centralize key management. The more data you encrypt, the more difficult it becomes to effectively manage proliferating keys. The most effective solutions available are designed to balance two equally important, yet opposing objectives: Keep keys safe from unauthorized exposure and make sure they are available when you need them for authorized use. Best practice calls for a centralized key manager that generates, distributes, rotates, revokes and deletes keys to enable encryption and to allow only authorized users to access sensitive data; a solution that rotates keys without requiring you to re-encrypt your data.
Centralize key management with localized encryption. Best practice calls for a hub-and-spoke architecture for centralized key management and localized encryption. Encryption and decryption nodes may exist at any point within the enterprise network. Spoke key management components are easily deployed to these nodes and integrate with the local encryption services.
Once the spoke components are active, all encryption and decryption of the formerly clear text data is performed locally, thus minimizing the risk of a network or single component failure having a large impact on the overall data security operation.
Asymmetric algorithms provide a high level of security. Rather than using a single secret key, asymmetric algorithms use a public key to encrypt data and a related private key to decrypt data. Once data is encrypted with the public key, only the private key can decrypt the data. This greatly reduces the key management requirements, since both parties no longer need to share the same, secret key. The drawback to asymmetric algorithms is they are very computationally expensive to implement. They are only suitable when encrypting a small amount of data.
Centralize key management with tokenization. Some key management solutions can enable tokenization models that intercept the data you want to protect and replace it with tokens. With tokenization, a token – or surrogate value – is returned and stored in place of the original data. The token is a reference to the actual cipher text, which is stored in a central data vault. Tokens can be safely used by any file, application, database, or backup media throughout the enterprise, minimizing the risk of exposing the data, and allowing business and analytical applications to work without modification.
