dss | General Musing

Since I started working for my company I’ve been exposed to PCI DSS (Payment Card Industry Data Security Standard), “It was developed by the major credit card companies as a guideline to help organizations that process card payments prevent credit card fraud, hacking and various other security issues.“¹ There are only a small amount of requirements that need to be implemented, although these can be pretty substantial for some customers. I can also be difficult to understand the details of these 12 requirements for compliance.²

Being a programmer by nature I’ve often been told that the nuts and bolts of what I do, the part I enjoy, are a little complex. PCI is something different, everybody can understand that credit card data needs to be protected from unauthorized access. Not just credit card data, but all data that could potentially be used in identity theft. Which means that a policy or control needs to be implemented to control this, and note any non-compliance.

PCI is just about protecting your “Cardholder Data“:

Primary Account Number (PAN)

Cardholder Name

Service Code

Expiration Date

I know first hand that most of the banks in the Netherlands, and in most of the world, are quick to discover credit card fraud. They are also quick to payout and correct the issue for the customer, because the chance that customers will loose faith in the bank is high if they don’t. Yet ultimately these customers are still paying for all the fraud committed with all the credit cards. Banks, payment service providers or retail merchants, who have your Cardholder Data, have all the data needed for this kind of financial identity theft and fraud, and more…

It may seem obvious that this data is stored securely, credit card use is ubiquitous. Yet the large banks have had the same problems with data leakage as small retailers, which means the data must be secured from the customer right to the bank who finally processes the payment to avoid this type of leakage. The problem is that payment service providers or merchants have traditionally not done this. They may handle the temporary authorization requests for the PAN or use the Bank Identification Number (BIN) from the card number for routing the payments to the specific issuer, so they may need the number. That’s fine, as long as they store the data securely and have a log of who accessed the data and why the data was accessed.

Now that’s out of the way I can tell you what I’m doing, I’m playing with RSA Database Security Manager [now EOL’d] and RSA Key Manager. Simply put DBSM is a framework which encrypts the data as in goes into the database and decrypts it as it comes out. It’s something that anybody who is paranoid like me had already been doing for a while, but the way I was doing it required me to write custom fragments of code for every application which needed to access the data. DBSM does it transparently, while at the same time checking the users who try to access it, so only the correct users gain access. RKM hooks into this by providing a framework for the policies or controls which grants the correct people/devices/programs a key to lock-up or unlock the data, different policies can be implemented for different types of data or device.

Now you know what I do.