Tag: Encryption

This is one of my weakest subjects when it comes to the 12 Section of the PCI DSS, the only one at which I’m actually worse is coding stuff. That said, there are a few things I can touch on that should be self-explanatory, but for some reason are still tremendous pain-points for a lot of organisations.

In terms of cardholder data storage, what it really boils down to is one question; Is cardholder data core to your business?

This may sound like a stupid question, but unless your business IS the processing of cardholder data there’s a very good chance it’s not a core function of your business. For example, in ALL of retail, cardholder data is not core, it’s simply one means to an end. The end is receiving payment for your service / products, HOW you receive payment is not the important part.

If you accept the fact that credit cards in their current form will die over the next 5 – 10 years, any investment into your cardholder data infrastructure should match this end-of-life process. Outsource card payment if you can, if you can’t, encrypt the data from the point of interaction (POI, usually a PED / terminal of some sort) to your processor, and retain nothing except the first 6 / last 4 of the PAN post-auth. If that.

You simply don’t need to keep it for the myriad of reason you once did:

  1. Settlement – now handled by your third party processor or your acquirer
    o
  2. Fraud Investigation – There is enough information in a transaction to not require the ‘middle six’ digits of a card (this is not the same as anti-fraud processes)
    o
  3. Marketing – There was never a need for card numbers in marketing processes, and this should have been removed long ago
    o
  4. Finance – The card number is not part of any finance department reconciliation, and again, should have been removed long ago
    o
  5. Recurring Transactions – e.g. subscriptions, this can now be handled by your third-party processor or your acquirer

What you’re fighting against here is one of the worst phrases in history; “But we’ve always done it that way!” (Only “What are you thinking? and “Is that it?” are worse). Your Risk Assessment should have mapped your business needs to to your data flows, and any storage fully justified. And they should be RE-justified every year as part of the Top 5 risks to your business (just look at Target, and Michaels, and Neiman Marcus, I’ll bet they wish they had examined their business a little more closely).

Assuming you DO need to keep cardholder data, then here you should involve an encryption subject matter expert (SME), and if budget allows, a Host Security Module (HSM) to perform your key management. Unless you have significant in-house expertise, writing your own code and managing your keys manually is like pushing a car down the highway to save money on petrol.

As for encryption of data in transit, this is relatively simple. The cardholder data should never be seen on the wire outside of either data / file-level encryption, or an encrypted tunnel. SSL / VNP tunnels to / from every system in the process flow should be in place at a minimum.

However, does the PCI DSS require this for compliance? The answer is no, it doesn’t, it only says this; “4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:…“.  I assume that you consider your internal subnets / VLANS behind the DMZ to be closed and private, thus negating the need for encryption.

Of course, this exposes the data to packet sniffers on those private networks, which automatically includes the majority of Intrusion Detection Systems (IDSs), so performing transport level encryption just makes sense if latency issues are manageable. This also adds yet another ‘blanket compensating control’ to your growing portfolio of above-and-beyond security measures.

This is as much as I can BS my through encryption, but in summary;

  1. Don’t keep it if you don’t need it, and be absolutely brutal in your examination of business processes
    o
  2. If you do need it, get expert help to minimise the complexity of all key management processes
    o
  3. Encrypt the connection between all systems in the CHD process flow, regardless of trust status

As always, if you need any help on this stuff, you need to find someone who can help you ask the right questions.

Why, in the face of threats, do we humans either spend an inordinate amount of time blaming others, or insist on patching the symptoms instead of solving the root cause?

  • Target: I had my credit card data stolen, so let me buy millions of dollars of new PEDs
  • ICO: The NHS lost some data, so let’s fine them.
  • Rest of the World: The NSA is reading our emails, so let’s encrypt them.

Every one of these reactions has completely missed the point, and are the definitive closing the barn door after the horse has bolted.

Question: Do you tell your deepest secrets to your loved ones in a very loud voice in the middle of a room crowded with strangers? Or do you wait until you’re alone, and even then talk quietly just in case?

And yet you think you should have privacy on the Internet?  You could not yell any louder than that. Forget your RIGHT to privacy, focus on YOUR ability to KEEP things private.

Even with encryption, who has the best equipment and expertise; you, or the NSA? Or worse; you, or organised crime? They are extremes, so let’s bring it closer to home; you, or your IT admin? How about; you, or your children?

So now, instead of solving the problem, security vendors are going to inundate you with offers to encrypt your data, encrypt your communications, encrypt your very identity, and they will all fail. 2014 should be the Year of Identity Management & Authentication, or to put it more facetiously; The Year of Only You Being You.

Here’s a ridiculously long and complicated analogy of your identity;

Imagine that you are a 1,000 piece puzzle, and when all of the pieces are together, only then can you see the full picture. As the puzzle is broken up and distributed across many hundreds of separate locations, the picture fades from each piece until it’s just plain white. Anyone stealing even a couple of hundred pieces will never be able to re-create you, never know what the picture is, or even where to find the rest of it.

Now, image that access to your most private information was tied to the complete picture, would that not be infinitely better than a username and password, or a 4 digit PIN?

Your true identity, the everything that is you, is made of things that cannot be put into a mechanism for authentication. Yet all we have right now is 3 factors: something you know (password), something you have (physical token), and something you are (biometrics). What about your likes and dislikes? Your future plans? Your everyday interactions?

All of theses things and infinitely more make up your true identity, and until we can come up with a way to get a whole bunch of them into a practical and seamless method of authentication, your data will be at risk, regardless of encryption. Yes, encryption may add a layer of security, somewhat akin to building your fence higher than your neighbours, but any commercial encryption product that will be pushed for home PC or mobile users will be practically useless.

Instead, privacy will come from the exact same source as identity managements’ will; very wide distribution of data with extremely limited ability to piece it all together. Some may disagree with my previous blog on the benefits of ‘profiling’, but you cannot have a robust identity without it. Bitcoin has proved that you do not need single databases/sources of storage for this stuff, the interconnectivity of the Internet’s individual systems can provide that with the right front end.

So, bottom line; don’t waste your money on expensive encryption solutions unless those solutions are performing the above distribution (bitcloud for example), but then it’s not encryption as we know it, it’s the next generation of privacy.