Article
Securing Your Database
Regulatory compliance with standards, such as the Payment Card Industry Data Security Standard (PCI-DSS), requires companies to use data encryption to protect data, such as the Primary Account Number (PAN) of a card, from theft and misuse. As most of this sensitive information is stored in databases, this means that the information in these databases may need to be encrypted.
The purpose of database encryption is to ensure the ongoing confidentiality of data, even from an attacker who has managed to gain access to the stored database file. Once an attacker has access to the database files, reading the contents of those files is a simple matter. Therefore, the goal is to protect database contents by encrypting the data thus rendering it unreadable without the keys and passwords. This methodology is useful for protecting sensitive data in scenarios such as:
# An attacker compromising the server hosting the database;
# A rogue system administrator attempting to access confidential data;
# Theft of physical media, including backups.
Database encryption provides another layer in any defence in depth strategy.
Database encryption has become less complicated now that the leading database platforms support encryption natively. Previously, businesses either purchased third-party encryption products, each with a degree of configuration complexity, or developed encryption and key management solutions in-house. By implementing encryption at a database level, key management is simplified as it is handled automatically by the database application.
Database-level encryption introduces a number of important performance implications. Each encrypt and decrypt operation increases the amount of time it takes the database to retrieve or store information. Furthermore, encrypted columns cannot be indexed as efficiently for text based searches, dramatically increasing the search time for complex queries. Therefore it is wise to encrypt only the fields that hold sensitive data.
Encryption also adds complexity to the backup process. To be effective in managing the risk of data exposure through theft of backup media, encryption keys must be stored separately from the encrypted data being backed up. When the time comes for a backup to be restored, encryption keys and their corresponding passwords are required in order to gain access to the restored data. Damaged key files or forgotten passwords will render the encrypted backup useless.
While the majority of enterprise database applications have adopted internal database encryption mechanisms, it is important to consider the implications of encryption before implementation. As long as the impact of encryption is carefully considered, organisations can gain an additional layer of security, which is increasingly required by industry standards to protect sensitive information.
For more information, see the following resources:
Transparent Data Encryption:
http://www.oracle.com/technology/oramag/oracle/05-sep/o55security.html
Understanding Encryption and Transport-Layer Security - SQL Anywhere Studio 9.0.2:
http://www.sybase.com/detail?id=1035475
Encryption Hierarchy:
http://msdn2.microsoft.com/en-us/library/ms189586(SQL.90).aspx
ervices operations of SIFT Pty Ltd, positioning the combined firm for continued growth in the Asia-Pacific information security services market.
The purpose of database encryption is to ensure the ongoing confidentiality of data, even from an attacker who has managed to gain access to the stored database file. Once an attacker has access to the database files, reading the contents of those files is a simple matter. Therefore, the goal is to protect database contents by encrypting the data thus rendering it unreadable without the keys and passwords. This methodology is useful for protecting sensitive data in scenarios such as:
# An attacker compromising the server hosting the database;
# A rogue system administrator attempting to access confidential data;
# Theft of physical media, including backups.
Database encryption provides another layer in any defence in depth strategy.
Database encryption has become less complicated now that the leading database platforms support encryption natively. Previously, businesses either purchased third-party encryption products, each with a degree of configuration complexity, or developed encryption and key management solutions in-house. By implementing encryption at a database level, key management is simplified as it is handled automatically by the database application.
Database-level encryption introduces a number of important performance implications. Each encrypt and decrypt operation increases the amount of time it takes the database to retrieve or store information. Furthermore, encrypted columns cannot be indexed as efficiently for text based searches, dramatically increasing the search time for complex queries. Therefore it is wise to encrypt only the fields that hold sensitive data.
Encryption also adds complexity to the backup process. To be effective in managing the risk of data exposure through theft of backup media, encryption keys must be stored separately from the encrypted data being backed up. When the time comes for a backup to be restored, encryption keys and their corresponding passwords are required in order to gain access to the restored data. Damaged key files or forgotten passwords will render the encrypted backup useless.
While the majority of enterprise database applications have adopted internal database encryption mechanisms, it is important to consider the implications of encryption before implementation. As long as the impact of encryption is carefully considered, organisations can gain an additional layer of security, which is increasingly required by industry standards to protect sensitive information.
For more information, see the following resources:
Transparent Data Encryption:
http://www.oracle.com/technology/oramag/oracle/05-sep/o55security.html
Understanding Encryption and Transport-Layer Security - SQL Anywhere Studio 9.0.2:
http://www.sybase.com/detail?id=1035475
Encryption Hierarchy:
http://msdn2.microsoft.com/en-us/library/ms189586(SQL.90).aspx
ervices operations of SIFT Pty Ltd, positioning the combined firm for continued growth in the Asia-Pacific information security services market.