For the last several years, the payment card industry has had a tremendous impact on the field of information security. The PCI - Data Security Standard (PCI-DSS), in particular, has forced companies of all sizes to institute a number of security controls for protecting cardholder data. Today we’re going to dive head first into one of its more challenging requirements – database encryption.
Within the standard, there is an entire section dedicated to protecting stored data. As stated in the description for requirement 3 “Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person.”
When working to address PCI compliance issues within an organization, I generally tend to recommend a two-pronged approach for data protection. The first is really quite easy, but requires a deep investigation into the storage and use of cardholder data in your environment - delete what you don’t need! This is easier said than done in most cases, so your other option is to encrypt what you think you need. Even so, it’s well worth it to go back and take a good look at what data you are keeping, why you are keeping it, and how long you are keeping it for – consider this as part of your long-term compliance strategy.
The problem with database encryption is that it’s often done incorrectly, or in a way that limits the protective nature of encryption technologies. Let me explain; with encryption you are relying on two primary components to ensure the proper protection of customer data – the encryption algorithm itself, and the key (or keys) used to encode the data. So long as you choose an acceptable encryption algorithm – one that is based on an open standard and has stood up to rigorous testing (like AES), you don’t really have to worry too much about the algorithm. It’s the keys that matter most.
Encryption keys are used to encode and decode the data – they literally lock or unlock the ability to read information, hence the term “key”. In some cases, you may have a single key that is used to both encrypt (scramble) and decrypt (unscramble) the data - this is known as symmetric key encryption. The other encryption method requires two separate keys and is referred to as asymmetric encryption. In this type of arrangement two different, but mathematically related keys are generated – one is called the public key, and the other is called a private key. When you are encrypting data you use the public key, then to decrypt the data you would use the private key.
Many organizations look to symmetric key encryption options for speed and simplicity. When I stated earlier that encryption is often done incorrectly or with limited success, it’s because there are a couple of common mistakes that tend to creep up while building out a database encryption solution. If you are using a symmetric key encryption method (one key that does both the encryption and the decryption), you need to make that key available to any application that needs to interact with the data. You can do this either by embedding the key in the application somehow (considered a VERY bad idea by most security professionals), or you can place the key somewhere within the database itself and have a call to the key included as part of your application code (there are a few other options if you look at native encryption built into the database, but key management is still an issue).
Either way, there is still a huge hole in this encryption scheme. The key is directly in the application pathway – an attacker can compromise the key at multiple points within the communications process. Once an attacker has access to the key, your encryption solution is just transaction overhead.
