Pants Full of Unix

It’s not impossible that I’m paranoid, but my employer’s life insurance company is now offering “Identity Theft Protection” through SecurAssist, a feature of which is that I can plug “up to 10″ credit card numbers into their website, which they will then search for across “underground chat rooms where thieves sell and trade stolen personal information”.

This leads to the question: whence were those credit cards often stolen? Right, from businesses who did store customers’ credit card numbers and did not maintain security sufficiently. So, sure, I’ll totally put all of my credit cards in the same place: that sounds like a great idea!

Incidentally, a component of my job right now is to set up software on top of Splunk to help companies that do store credit cards (and other personal consumer information) demonstrate compliance with the PCI DSS Standard. No part of the current state of affairs makes me happy:

1. The standard is not written very well. There are obvious gaps and, as with SOX and HIPAA before it, expectations made of technology that are simply unrealistic, if not functionally impossible to implement algorithmically. (My favorite easy-to-grasp example of this kind of flawed thinking remains an off-handed item in HIPAA: in theory, you are required to destroy all records of a deceased party exactly two years after their date of death, including all backups of that data. Yes, really.)
2. Comprehension of the standard is worse than SOX and HIPAA, in several ways.
   • It is up to a given business, in cooperation with their auditor, to determine which of their systems fall into the several categories defined in the standard (PCI scope, systems that transfer consumer information and CCNs; cardholder, systems that store not just consumer information but actual CCNs; everything else). The standard presumes that it defines these classes clearly, but it is demonstrably not clear enough, given that ostensibly similar businesses have made different determinations about which systems fall where.
   • Different auditors demand disparate degrees of compliance with the standard and ding businesses for various miniscule details while, apparently (based on a game of telephone, of course: I just know what our customers tell me their auditors are demanding of them) disregarding whole swaths of the other requirements. The first part is theoretically okay (on the principle that a business is moving into compliance, but acknowledges that they aren’t there yet), but the second part is absurd: if the various private auditors are not holding all businesses to the same set of rules, then it’s not a “standard”.
3. Compliance with the standard is awful. (Before you panic, see also point 4.) The software I work with can help businesses comply, but because it is necessary to ensure that log data from all systems within PCI scope go into Splunk, and necessary to understand the inner workings of Splunk fairly well to know whether “no results” for a given dashboard (specific to a PCI DSS Requirement) means “no violations” or “something changed and the data’s not coming in properly”. I’m less than confident that some of the customers I’ve worked with will actually maintain this well, which doesn’t need to be a judgment of those with whom I’ve worked: it’s often just the rate of turnover at the customer.
4. Actual data security is very mixed. Some customers are doing better than the PCI DSS Standard would require them to do (and, in some cases, actually need to compromise their security standards just to make use of the software I set up with them), some are positively atrocious (minor nit: it’s 2010, people; if you’re even still cutting backups to tape, you simply have no excuse for lacking encryption). For obvious reasons, I won’t mention any names here, but if you know me personally and you’re considering giving your credit card to a business for recurring payments on anything (like, say, your phone bill), maybe you should run it past me first.

Well. That one kinda got away from me…