Case Study: PCI Risk

A good example of a tough risk decision can be found when looking at the Payment Card

Industry (PCI) requirements for protecting credit card and personal information. Although not technically a regulation, these standards come close to it for credit card processors and companies in the retail industry. Many of the large merchants have implemented full disk encryption or database level encryption to protect that data on back-end servers based on the PCI Data Security Standards (DSS) published by the major credit card companies:

PCI-DSS: Use of strong cryptography like disk encryption to protect sensitive data [2].

We already alluded to the idea that database encryption may be a suspect control in

Chapter 1. Although encryption may be a good solution for mobile devices, it fails to mitigate the real threats of an application-level attack on databases storing card numbers in data centers. Lets look at why this standard may not make sense when applied to database servers.

Think about an attack on an application that stores credit card numbers in a database.

In order to function, the application needs some way to decrypt the data regardless of whether it is stored on an encrypted drive or whether the database encrypts at a field level.

This means that the best vector for an attacker is to exploit weaknesses in the application and use it to access card numbers in the database. In this case, all you have protected against is abuse of the data by the database administrators if you encrypt at a field level, or physical theft of the server itself if you encrypt at the drive level. If the database server is in a retail store, maybe there is a real threat of physical theft, but think about databases in secure data centers. Is this control really making that sensitive data more secure? The only viable way to defeat these application attacks is to hash the sensitive data instead of encrypting it, but this only works for certain data types. It works well for an identifier or authentication credential because you can compare it in its hashed form, but for other sensitive data, you will need to present it back to the application in its raw format, which eliminates hashing as an option. Unless you are worried about an attacker physically running off with the drives in your servers, then full disk encryption isnt reducing your risk at all. If an attacker doesnt target the application as their way in but rather goes after a vulnerability on the database server directly, then the encryption is even more useless. Chances are if they can compromise the server, they will also get access to the unencrypted data fairly easily. Without a formal risk assessment and analysis methodology, many organizations will implement the controls they need to in order to be compliant, but really not reduce their risk exposure at all.

Q1: Why formal Risk Assessment is so important for the above scenario?

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________