Friday, August 24, 2007

Define... "securely transferred"

Here's something for you folks out there to ponder, and I'll give my take on it as well, but first I want to pose the scenario -- and offer a chance to think it over and maybe reply publicly if you're daring...

Scenario:
You're a financial company, or rather, you work for one. You have a vested interest in protecting your clients' data; whether it be cardholder information, investor information, or banker information... it's all critical and sensitive. Now say you work with a 'partner' (or vendor) who will do something with some portion of your customer data records. To make it more concrete, let's assume that this vendor will provide outsourced "rewards redemption" on the line of credit cards you offer... "Pet Points" as an example. So if I own a "Pet Points" card you issue, and I want to redeem my points for a spa treatment for Fifi, I dial up an 1-800 number, and get your vendor-partner who's CSRs use the data you have about me to allow me to redeem all those hard-earned "points". Of course, included in the necessary data that the vendor-partner has to have about me is my card number, expiration, home address, name, maybe some other morsels of information too? Now, for this vendor-partner, let's call them Partner X for brevity, they have to have this information sent to them in a flat-file so they can input it into their system as a nightly batch job (standard for financial systems these days). This flat-file, as you would imagine, is brutal if it falls into the wrong hands, yet your partner tells you they only support "in-transit" encryption and that nothing like PGP is supported as "it is too complex and difficult to support". What do you do?

Allow me to break this down for you:
  • Sensitive cardholder information in a flat-file
  • Flat-file sent over to a 3rd party
  • Link is encrypted "edge to edge" (meaning, router to router, or firewall to firewall)
  • Flat-file encryption is not supported by your vendor
So ask yourself... "Self... what do I do?"

This is an egregious act of negligence. I'll tell you why. Feel free to disagree.
  • First, the argument that the data is "encrypted on the way over" is crap. PVC's, VPN's, even private copper (very rare) is still only part of the puzzle. That data is exposed the second it drops out of the encrypted tunnel
  • Next, how much do you trust your internal employees? If you're intelligent the answer is very little, cardholder data should never be stored unencrypted even on "internal" systems
  • Additionally, as the client, I have the right to tell my vendor how/where/when I want data secured -- if you're a vendor telling me you won't support something I feel is fundamental, I'll find someone who will
I think I'd like to take that first point a step further. Data in motion is encryped, typically, which is great. The problem is where that data is de-tunneled, or de-crypted. Are the systems that handle the data in a DMZ? Are those systems in the internal network where they are accessible by all your employees? Can I "plug" wirelessly into your network and possibly see this data? If you the answer to any of those question is yes, then you have a problem. That data is not secure. So you see, it's great that the tunnel you have established encrypts data as it passes from my firewall to yours, but that system that receives the data... which was hacked a month ago by someone from Elbonia, that's still insecure. You're still facing at least a loss of my business, at worst a lawsuit that'll put you out of business.

No comments:

Google+