Systems, consultation and development 

Facebook E-mail

Does Compliance Equal Security

With all the news about Target and others having card data swiped, here’s a snippet from a piece I wrote a while back discussing the industry requirement for PCI…

Security basics and fundamentals

When looking to create or enhance a system that has a requirement of storing confidential information, the first thing that should be addressed is the actual need to store that data in the first place. Is it essential for the operation of the system to have this information at all, or if it is needed at least once, does it need to be kept in perpetuity?
If the need for storage is confirmed then the concerns shift to the more obvious issues, specifically the access (both physical and logical) and authentication to that system. Both access and authentication are fundamental requirements for any system regardless of what the information is, from email addresses to top-secret national security data.

So why oh why do we need PCI?

Given that we know that basic access and authentication measures are essential in any business, it occurs to the author that any means of testing a given system against known methods of attack is a valuable and worthy tool for business. In the realm of internet security these tools have existed in both the open source and closed source realm for many years.
Entire corporations have been built on the basis that they can help your business remain ‘secure’ either by actively and aggressively testing the target system for known vulnerabilities or by providing additional systems to prevent or warn of attacks and violations themselves regardless of the information your business is trying to protect.
As a specific type of confidential data, credit card information is an interesting one. For many years it was treated (especially by online retailers) like any other, just a string of numbers and letters that went into a database along with postal and email addresses and shopping cart details. However, card data is a powerful tool, the misuse of this directly violates an agreement between the customer and it’s card issuer, i.e. it doesn’t directly affect the business. Your customer at some point realises that his details have been misused, reports the abuse to the card issuer and various chargeback and insurance based remedies make sure the customer is no worse off. However, the card issuer foots the bill and that does not go down well with these large institutions. So historically each card issuer decided independently that something must be done about all these systems out there, rogue or innocent, potentially leaking all this information which represents billions of potential lost revenue and so each came up with their own set of guidelines on how to safely store the card information.

Enter the dragon
With many retailers, online and MOTO systems having the need to accept multiple issuers card types, the array of conflicting and overlapping guidelines meant that the average retailer had increasing trouble trying to meet these expectations. Between the acquirers it was decided a single body or council should bring together a specific set of guidelines to increase not only the awareness of the issues, but also the likelihood of improving security. The Payment Card Industry was formed to create a Data Security Standard.
Tokenisation to the rescue?
Recently there has been much attention to the concept of tokenisation. Under the hood of the hype is the simple premise that the merchant doesn’t store the card details, he simply looks after a unique piece of data or token that when given to the card storage facility refers to a specific set of cardholder data, the online equivalent of the coat ticket at a club or safety deposit box. Outside of the storage facility this data means nothing. This by itself adds no security to the system, it simply absolves the merchant of having to store the card details taking them out of the misuse equation (remember the first point in this article). It allows them to put their hands up and say, “We’ve never seen those card details, how can we be held responsible?”

Data at rest is data at risk
Now lets look at the service providers and card storage facilities. These are now the focus of the acquirers because they are rapidly gathering all the precious data eggs into one (very lucrative) basket. This of course also makes them a target for the criminally aligned who would have access to those eggs. The PCI council guidelines have taken an increasingly draconian approach to protecting that basket, compulsory CCTV coverage of the target machines, all systems required to be hosted on dedicated machines, even to the extent that databases and applications must reside on separate systems and dedicated hardware firewalls. Now this article will not go into detail as to how the security concerns of separating database and application can potentially have the opposite effect or indeed how hardware firewalls really give no additional security to a well configured software firewall and it won’t mention that the largest breaches have been ‘insider jobs’ and rogue employees. Nor indeed will it go into detail on how the ability to massively hike up hosting costs of this data purely on the basis of the guidelines rather than actual risk will be financially well received by the hosting companies and various QSA vendors who get paid to scan these systems.

Make the data useless
Let us consider for a moment the detail of the eggs in question. Invariably the raw card data that most merchants have previously been storing themselves and have now handed over to storage facilities to look after consists of two pieces of information
a) Card Number – 16 (or so) digit number which identifies the issuer/branch etc and identifies the holder
b) Expiry Date – A date, to be valid it must be a date after the present and within roughly 3 years
Those two pieces of information provide the merchant with the ability to charge an amount to your account.
Look at this data a little closer, the expiry date is a simple month/date combination, so for three years of possible values there are simply 3 years x 12 months = 36 possible combinations. For card numbers, they are bound by the Luhn algorithm (which most merchants use to check the number is valid before using). This algorithm also allows an interested party to generate every combination possible. So realistically, the data itself is not sacred, or hidden, or magical. It is simply the combination of these two pieces of data that make it so valuable.

And it is here, that the solution presents itself, break that data apart, keep it useless.
So, individually that data holds no power and of course this idiom can be taken further, what if the card number itself was broken up? Would that be even MORE secure? What if the individual parts of the number were then subsequently encrypted? With different keys that were not stored with the parts? Would that be secure?
The data at rest is merely a piece of the puzzle, useless by itself.

Home Uncategorized Does Compliance Equal Security