Bill and Ben discuss PCI-DSS V1.1

(Okay, I’ll apologise to the purists, but I am a bit young to have watched the cartoon, so all oddle-poddle errors are mine.)

Bill: Isn’t it great new that after 31st December everyone will have to use the new Version 1.1 of the Payment Card Industry Data Security Standards? (WARNING - irritating American legalese click-through required.) It will be a real improvement in security at online retailers and it should help reduce the massive spate of data leakage incidents (although not as much as wide-spread laptop encryption.)

Ben: Flob’a’lob’a’dob

Bill: Surely not?

Ben: Flob’a’lob’a’lob a’dob’a’dob

Bill: No, you’ve got to show me some evidence. This cannot just be a cynical arse-covering attempt by the Cards Schemes based on dodgy security principles and poorly thought out practices.

Ben: Lob’a’flob

Bill: Surely not – You mean that with the vast majority of (hacker) attacks occurring in the application space, there is no requirement for comprehensive pre-production application level pen-testing? What about 11.3.2?

Ben: Flob’a’dob

Bill: Oh I see: “significant … application upgrade or modification” and then all the examples they give are for infrastructure changes. Yes, and I do remember that it is often the small or emergency changes, that will have been through less QA, that cause issues.

Ben: Lob’a’flob’a’dob.

Bill: I didn’t know that. You mean that the Cards Schemes are considering the forensic recovery from disk of CCV2 values associated with PANs as fully probative evidence of a breach of 3.2.2? Haven’t they ever heard of asynchronous comms? Oh well, have you seen Weed anywhere?

What Bill is hinting at, here, is the weird contradiction between the requirement of 3.2.2 and the requirement to actually authenticate the transaction: at some point all of the transaction data captured is going to be assembled, encrypted and sent, by a normal asynchronous comms method, to the acquiring bank or financial institution. It will be kept in, probably in memory, until the accept / deny message (and the authorisation code) comes back. The computer is likely to suspend the relevant process / thread and there is a chance that this will mean that the memory is paged onto disk storage. Ergo, unless there is a requirement for the assembly to take place in a Hardware Security Module (expensive, and introduce security management issues of their own), any computer which is regularly used to process cards transactions is likely to have, somewhere on disk storage that was once used as virtual memory, multiple instances all of the sensitive card and transaction data. Without any intent to breach Section 3.2 or even with good technical and procedural measures to comply with it.

Sometimes, my job just makes me cry. Oh, and a little birdie told me that the auditing practices are so rigid for this standard that nearly no company can pass 1st time round, so it is another great money-spinner (and reputation killer) for the information security industry.

Ho hum. It's the weekend and Scotland really shouldn't lose at the rugby tomorrow. :)