Encryption and hashing technologies are different and will be explained to avoid confusion, as detailed analysis of both and how they fit into the data protection strategy of the enterprise, is covered in this section. Both encryption and hashing are typically what is thought of when data protection is discussed whether in storage, transit, or in use by applications. Usually, the immediate afterthought is, this is going to complicate business processes or break something important. The teams who have the most work to do, the developers and application teams, generally will have the most heartburn over potential changes to application code, batch jobs, and processes that make the business run. Encryption and hashing are both very important to the overall security posture of the enterprise and must be an integral component of the enterprise security architecture.
There are several forms of both encryption and hashing that have various uses depending on many variables. Both have their strengths and weaknesses, complications in implementation, and overall protection capabilities. There are two distinguishing characteristics between encryption and hashing. First, the process that creates the final representation of the data, and second, the method by which the original data is retrieved. It is these characteristics that will be the deciding factor on which is used for specific data protection scenarios. Let's take a more detailed look at both and see some viable uses for each. Note that this is not meant to serve as a de facto reference on encryption and hashing, but provides enough information as to how encryption and hashing can be used in the enterprise as part of the overall security architecture.
Encryption is the method of mathematically generating a cipher text version of clear text data to render it unrecognizable. This method is based on really big numbers called prime numbers to limit the possibility of creating the same cipher text for different data and to make it as mathematically difficult as possible to derive the clear text from the known cipher text. With this stated, all standard encryption algorithms are public and can be reviewed, the algorithm is essentially the source code that shows the interworking of the encryption method. This is done to ensure the validity of the encryption algorithm, ultimately guaranteeing the users of the encryption technique that their data is protected.
There are two general types of encryption – symmetric and asymmetric. Both types of encryption require keys to perform the encrypt and decrypt functions. It is this factor in encryption that causes some security standards to consider encrypted data as having the same value as the data itself. This means if an enterprise loses encrypted data, it is the same as losing the data without it being encrypted. This is, due to encryption being a two-way algorithm. For instance, data encrypted using a symmetric key can also be decrypted with the same key. Essentially, having the key is all that is needed to transform the cipher text back to clear text, thus running the function again, the clear text can be transformed back to cipher text. This is possible because the key is mathematically related and the unique factor added to the algorithm at the time of encryption to ensure the cipher text is unique. Because the math in cryptography is extremely advanced, the subject in this chapter will remain at the level of basic operation. Coverage of asymmetric encryption is covered later in this chapter and functions differently than the previous example.
The factors that make one encryption stronger than another at a high level are the key length, rounds of encryption, and salting. Rounds refer to how many times the data is run through the encryption algorithm to generate the cipher text, and salting is the process of adding random bits, a password, or passphrase to the encryption process to increase the strength of the cipher text. There are several well-known encryption algorithms including, but not limited, to:
There are many more available options for encryption that should be considered. For example, some are faster, which may be a consideration when the system using the encryption does not have a lot of processing power.
Note
AES-128 is the recommended version to use due to a collision issue in AES-256 that results in identical cipher text for differing clear text data. An overall encryption recommendation cannot be made, as there are several factors that must be considered when selecting an algorithm for implementation.
Given next is an example of an encrypted file, text.txt, that I encrypted using OpenSSL AES-256 symmetric encryption. OpenSSL is a tool found natively on Linux and Mac OS X systems and can be installed on Windows.
The original file content is shown in the following screenshot:
The encrypted file content is shown in the following screenshot:
It is easy to see that the second picture is not readable text; it certainly does not have the clear text words from the previous screenshot. I can now decrypt this file using the same encryption algorithm, (AES-256), to view the content.
The decrypted file content can be seen in the following screenshot:
This last example illustrates the two-way function of encryption. The key used to encrypt the original data can be used to retrieve the original text from the encrypted data.
Asymmetric encryption is different than symmetric methods because the master key (private key) is never shared; it remains with one party in the encryption process. The best example of this in use is SSL certificates used for online security. When a purchase is made online at a website using SSL (browser will show padlock), the user's browser will establish an encrypted connection to the web server. All data encrypted is done so using the server's public certificate and key.
The public certificate and key pair is just that, public, everyone has access to it. The public certificate/key pair can only perform one side of the encryption process—encryption. It is not possible to use the public certificate and key to decrypt. Only the private certificate and key can decrypt data encrypted with the related public/key pair. In order for this to work there are a few things that have to happen. First, a private key and certificate must be generated, then from these items a public certificate and key can be generated. This is the process of creating the mathematical relationship between the public and private certificates and keys used. The primary benefit of this method is that the private components only have to be in one place. As with symmetric encryption all parties must have the secret key.
Another form of this type of encryption is Gnu Privacy Guard (GPG). This is an open source implementation of the now commercial PGP asymmetric key encryption solution. To understand how this works, see the following example:
Each type of encryption has its use and must be considered when making a decision on how to encrypt data and communications within the enterprise. Another consideration is key management, due to the importance of securing the private keys a process should be developed to ensure the proper creation, deletion, and rotation of keys used in the enterprise.
Data at rest that meets the encryption requirements of the data classification model may reside in several of the previously discussed data locations and they need protection. This may come in the form of encryption and can happen at the location of storage, prior to storage, or during the process of storing. Each of these methods requires discovery into interacting business processes and use of the data to ensure the processes and applications can support the method used.
Another aspect to encrypting data at rest is online versus offline encryption. Typically online encryption is in effect while data is accessible and offline is in effect when data is not directly accessible such as on backup tapes, turned off systems, and so on. Another example of offline encryption is a whole disk encryption, once the operating system is booted and the volume is decrypted for use; technically the data is no longer encrypted and can be accessed in an unauthorized manner until the next boot.
Before I present database encryption, I want to communicate that most approaches to data protection will only protect the data from unauthorized access and physical theft of system hardware. I stress unauthorized because if a web application is exploited, the access will be authorized and simply misused. If the exploit was against the database, this may not be the case. But this should not be an Internet accessible service, and database encryption in this case should be sufficient to protect the stored data.
Data stored in databases can be encrypted via two methods. The first method utilizes the built-in encryption capabilities of the database itself to protect the stored data. This can be beneficial when attempting to make encryption invisible to the applications and processes that are accessing the data. All permissions, views, and protection are managed within the database. One caveat can be the implementation of the database on the underlying system. If not configured properly the system administrators can circumvent the database encryption. The second option, which is much broader in spectrum, is encrypting at the application and process layer. All data is encrypted before it is stored in the database. This method may make sense in environments where the database is not in the control of the enterprise or in a shared environment where a pivoted attack could cause a compromise of enterprise data. Some challenges with this method include building the encryption capability into the applications and managing the encryption keys that have to be used. Management and protection of the encryption keys becomes multiplied in complexity, as only one application has to be compromised to get the key. For smaller encryption domains with little to no complexity, this method may be the most cost-effective solution, especially if all the applications are homegrown, as in-house experts can make the necessary modifications to add encryption. More detailed approaches to database security are explained in the following sections.
Typically, database encryption is a requirement of security standards that introduces significant complexity into the overall applications and processes that must access the data. This can provide little increase of security when the data at rest is live. The definition of live—the database is up and the trusted applications and processes are accessing the database, the misuse of these factors in our trust model will not be mitigated by encryption.
The primary concern of database encryption is to protect the data from prying eyes, a person, application, or process that is not trusted per the trust model to access the data. An example may be a system administrator; their access to the system should not taint access to the data in the database due to the elevated system privileges. This, in practice, would be strict adherence to the trust model, thus the reason for its existence.
It is a good practice to apply encryption when the system is not in the physical control of the enterprise, for database backup procedures, to apply strict data access controls, and to meet compliance requirements. The methods to encrypt the database data are numerous, and each has its benefits and drawbacks.
There is no right or wrong way to encrypt data as long as the encryption or hashing uses a standard method that has been independently reviewed, and does not have any known weaknesses in the algorithm. Selecting a solution should go beyond the marketing slides of the vendor and involves research and proof of concept testing. The method and complexity used by the applications and processes that must interact with the encrypted database will drive the correct implementation with possibly some modification to the applications and processes.
Application encryption, in this case, is simply stating that the encryption of the data occurs in the application not the database. The significant difference here is that the data arrives as already encrypted in the database. A challenge with data protection, especially in environments where the network equipment is not owned by the enterprise, is snooping, else a simple misconfiguration of network equipment leads to the exposure of sensitive enterprise data. A method often employed is securing the communications between systems and passing the data clearly over a secure channel.
This can be rather complex, and if the secure channel has an issue and for some reason does not provide a truly secure communication path, then the data gets exposed and can be without any indications from the application or systems involved in the communication. Regardless if the secure channel can be created, encryption of the data can be enforced at the application. This has performance benefits and reduces the complexity of the overall system. A consideration is application level encryption that will require all processes and applications to have a method to decrypt and encrypt the data that was initially encrypted at the application. Typically, this is accomplished using a shared private key, a bit of an oxymoron, but this is where we have arrived at the moment with encrypting keys. Another method leverages public/private key encryption, much like the previously mentioned authentication mechanism. A key change in the environment would be significant, potentially shutting down the application for the duration of the key rotation, also requiring testing time.
The primary benefits for using this method are:
- Database performance gains for not using encryption at the database tier
- The data is always encrypted in the databases (no DB admin or SYS admin visibility)
- Each application that must use the data in some fashion is responsible for encrypting the data
- Data encryption is implemented end to end regardless of communication channel security
Selective database encryption refers to encrypting only portions of the database; typically selected columns that contain sensitive data. This method is often employed not only to reduce the overall load on the database server for encryption, but also to make it easier for the DB admins to ensure the data inserted into the database is correct. This method of encryption is controlled at the user, process, and application level. With this configuration role assignment will control database table and columns view permissions.
The downside of this type of implementation is that the DB admin has full control over the database encryption, if the individual decides to see the data in an unauthorized method; it is a simple change the DB admin can make without peer review. With this scenario, monitoring and detection of the unauthorized change would be the only real protection from this unauthorized access. Additionally, SYS admins can have access to the data in the database simply due to having "root" access to the system. They may not be able to see the encrypted columns, but access to all clear data is feasible if the database is not configured to mitigate this vulnerability.
There are requirements for certain industries and datatypes to have a regular key rotation after a given period of time, to reduce the risk of data exposure through key compromise. It is a general principle that the longer an encryption key exists the more likely it will exposed; remember that the key is supposed to be secret, so exposure is bad. When a column or a series of selective columns is encrypted versus the entire database, time to rotate a key is greatly reduced, which affects production down time.
Example of database column encryption
Applications, processes, and users with access to the database will only be able to see what their permissions allow, including the ability to view encrypted columns. Usually, the view of encrypted columns will be asterisk for character replacement to allow recognizable field data without compromise on privacy and confidentiality. The column-level encryption will authorize an authenticated session to insert, delete, and change data accordingly.
In most cases, the application and processes accessing the database will not have access to decrypt the entire column data but just enough data to make a determination. An example of this is logging into the website of an online retailer and changing the credit card number on file. The user will see maybe the last four digits of the card number and other information, such as the expiration date, to identify the correct payment method. The viewing of only the last four digits of the credit card number is an example of partial column decryption controlled by view permissions in the database for the web applications.
Encrypting all data in a database is an example of complete database encryption, resulting in all tables being encrypted regardless of their sensitivity. This method is vulnerable to the rogue DB admin, but should thwart the snooping SYS admin. Data encrypted in this manner is also safe from database backup snooping and data loss. Not all data stored in a database is protected by law, mandate, or regulatory compliance, and requires encryption. But, not all data should be made public.
Encrypting the entire database may be the method chosen to ensure that no data is visible without the correct authorization to decrypt data, essentially a specialized view to see the encrypted data. This method will protect the data in the database from unauthorized access and reduce it's exposure in the event a backup of the data is lost or stolen. The method implemented must make sense from data protection and risk analysis perspectives.
Another method is to "tokenize" sensitive data for use in applications and storage in the database. Tokenization is a method that assigns a value to a segment of data, so that the initial sensitive data value no longer exists. All processes, systems, and applications are able to process the token value as they would process the sensitive data, however, this method ensures that the token has no real value to anyone or anything outside of the process.
A common use for tokenization is in the retail industry for the replacement of credit card data within the network and assets. Because tokenization is not encryption or hashing, there is no mathematical relationship or known reversal method known outside of the tokenization system; recovery of the initial sensitive data is nearly impossible. This allows retailers to escape the prescriptive security controls required for systems, processes, and applications that typically interact with credit card data. This method also makes it more difficult for sensitive data exposure and compromise. There may be customization required to implement tokenization, but it is an option gaining momentum.
Every enterprise has servers that store data for use in processes, applications, and for general use by users. As with databases, many operating systems offer native encryption, generally offline encryption, and can be accessed by system administrators, which may be considered as unauthorized access and a security violation.
There are technologies available that will encrypt data as it is being written to the file system. This same technology can apply permissions above the underlying operating system enforcing least privilege and ensuring only the necessary processes, applications, and users have permissions to access data. The method of encryption within the application is also a viable solution to ensure that only the necessary processes and applications have permissions to interact with the data.
Data in use is data that is being accessed, created, modified, or deleted, typically by automated processes or human beings. An example could be fraud investigators leveraging stored credit card and transaction information for an investigation. In this scenario, access to the data is necessary but should not be visible to prying eyes on the network. This can be accomplished by ensuring commercial software provides secure communication and that views can be created to ensure that only the fields needed are viewable.
The enterprise will need to understand the complexities of data access for business processes and applications to decide what methods of encryption to implements across data access technologies.
Data may need to be transmitted internally and externally to the enterprise in a secure manner to support a business function. Although not all data has to be encrypted for a business reason (laws, mandates, compliance), it is good practice to only use secure transport methods to transfer data. Typical protocols used for secure transmission include SSL, SFTP, FTP-S, and SSH, in addition to proprietary solutions. You should carefully evaluate the solution to ensure the encryption methods are sound and meet the requirements of the enterprise. If the transport cannot be secured, then the data itself must be encrypted, however, this does not mitigate unauthorized access to the encrypted data. The data may not be decrypted, but with insecure transmissions, not only is the payload accessible, but credentials are also passed in clear text, which could lead to further compromise.
A technology that is fast becoming a solution for secure transfer is web based and allows any user or organization with an Internet connection and browser the ability to securely upload and download sensitive data using a web interface to send encrypted e-mail notifications. The recipient receives an e-mail notification that there is a file waiting for them to download. The user authenticates and accesses the data uploaded. Each organization will need to assess the data transfer requirements of the business and build the correct solutions to ensure proper data protection while in transit.