Case Study #6 - Encryption can be a waste of time
So, why do security professionals harp on the need for encryption so much? Because we assume encryption safeguards will be done properly, and in conjunction with other layers of security that will complement them.
In this breach (summarized HERE, and originally reported HERE), a server containing credit card numbers was compromised by hackers from the Internet. The company was a provider of news and ad syndication for the web. The breach allowed the credit card information of 4500 customers to be stolen.
Most security managers who read this will immediately guess that “they weren’t complying with the Payment Card Industry Data Security Standard” (in PDF format HERE). This is the standard to which credit card companies hold their merchants and other partners handling information related to their payment card systems.
One requirement of the PCI standard is that any sensitive information is stored and transmitted in encrypted form. But the card numbers “WERE” encrypted by the company …and they were still compromised! So, what good are these encryption requirements?
Here are some important things to know about encryption of stored data:
- When data is stored in encrypted form (such as in an encrypted data base or encrypted files - often called File Encryption), it is analogous to putting it into a safe. Usually a safe is pretty secure.
- The critical vulnerability for this type of security is usually in how you protect the access mechanism (for a safe, either a key or combination). If you don’t keep the safe’s key in a safe place where it is only accessible to people who need it, there is a good chance it will be seen and misused. If you write down a combination and don’t put it in a safe place, the same thing can happen.
- For most types of commonly used encryption, it is usually easier to try to find the key (or password that the key is derived from), than to break the encryption algorithm that protects the data file.
In this case, the key for the encrypted files was found by the hackers on an Application Server. Application servers usually do need to use the encryption key to processes the data as it is collected, or when the transaction information is sent to other parties in the payment system.
The Bottom Line
Encryption is intended to be a temporary thing. There is always an intent to be able to decrypt the information at some point. So, after encryption, the key must be kept accessible to those who need it, but secure from anyone else.
Remember the following things about encryption:
- Encryption is not considered a total safeguard in most situations.
- You usually need other safeguards to protect the keys as they are being created, used, stored and destroyed.
- You can encrypt keys, but then you need to protect the key that was used to encrypt the original key. Hackers know this, and will look for a “root key” that will allow them to work through the chain until they find the one that decrypts the data.
- Protecting encryption keys in an operational environment often involves the elements of strong physical security, authentication and access control.
While the details of this breach aren’t clear, it is very likely that the PCI standard was not implemented correctly. However, in looking at Sections 3.4, 3.5 and 3.6 of the PCI standard, very little is said about how they expect keys to be protected when in use by Application Servers. Is this a weakness in the standard?
So, encryption can be a waste of time if the keys aren’t managed securely. It’s like locking your car in the driveway and leaving the key on the front step.


Scott on 15 Sep 2007 at 7:21 am #
An interesting afterthought is that the company ultimately decided to outsource their payment card processing. This transfers the risk to the service provider, who will hopefully do a good job and will limit the costs for security. Probably a good move in this case.
mroonie on 17 Sep 2007 at 2:46 pm #
Scott,
Do you have any recommendations as far as where a safe place to store your keys would be? Or what are your thoughts on creating a key management policy? Any tips as far as how to go about creating one?
Identity Theft on 17 Sep 2007 at 6:24 pm #
Storing your encryption keys on the network is the equivalent of locking all the doors to your home and placing the key under the doormat. Experienced thieves and hackers alike know where to check first when looking for keys.
Scott on 17 Sep 2007 at 10:27 pm #
It all goes back to layered security safeguards for protecting sensitive information in an Operations Zone.
1) Starting with deterrent safeguards, make sure that all authorized user accounts have the obligatory strong banner warnings against abuse, and that multiple safeguards and penalties are in place. See my other posts on why this seemingly “weak” form of safeguard is important.
2) Harden all servers and network devices, including, but not limited to: disabling all unnecessary services and ports; allowing only necessary user accounts required for administrators; setting up file permissions for only authorized users; setting up system and application logging; setting up malicious code defense (A/V and File Integrity), etc…
3) All authorized accounts should require 2-factor authentication so that compromised passwords are not enough to gain access to an account.
4) A critical element is creating a logically and physically zoned network architecture to provide perimeter defense and access controls to strictly limit the paths and protocols allowed to the application servers.
5) For additional assurance, although more appropriate for protecting keys of certification authorities than of merchants, tamperproof “Hardware Security Modules” (HSMs) can be attached directly to servers so that all cryptographic operations take place on the device, and keys may only be extracted by having multiple administrators’ approval.
The amount of protection (and cost of safeguards) should be proportional to the value of the sensitive information. There are often economies of scale that make it more cost effective to implement some of these safeguards in larger data centers.
That’s why it can make sense to use outsourced service providers who can leverage multiple customer operations to achieve lower costs. Then, the key issue becomes the trustworthiness of the service provider, and due diligence to ensure that their policies and Service Level Agreements are acceptable.
Scott on 26 Sep 2007 at 9:21 am #
Well, thanks to a Feedblitz message from Martin McKeay (http://www.mckeay.net/secure) I’ve learned that the PCI standard is being beefed up to address “Application Security” going even farther than I had outlined. They are looking at requiring code reviews and other System Development Lifecycle (SDLC) safeguards, which I didn’t go into earlier (mostly for brevity).
They are calling it the PA-DSS for Payment Application Data Security Standard.
A more detailed discussion of the most recent PCI meeting in Toronto can be found at http://www.veracode.com/blog/?p=63 .