State of CA – Split Personality Syndrome?

It’s interesting to see that the state of CA has a split personality disorder! I wrote in a blog about a year ago how the state of CA is being a model citizen by forcing companies to protect consumer sensitive data by protecting the PII information (such as zipcodes and other sensitive information by classifying them as PII) and imposing penalties on companies that don’t comply. (Link here) But now, they sided with Apple stating that for on-line transactions the vendors can collect additional PII information that is not necessary for brick-and-mortar vendors. This means if you are an online retailer and collect such PII data, you need to have a mechanism to protect all this information you are collecting from your consumers, not just the PCI data but the PII data as well. In order to comply with this dual personality, you will need a solution that can encrypt and tokenize the sensitive information as necessary and as seamlessly as possible.

http://news.cnet.com/8301-13579_3-57567526-37/apple-wins-california-credit-card-privacy-case/

Effective PCI tokenization methods

Recently a colleague and a friend of mine wrote a great article about different ways to be PCI 2.0 compliant by tokenizing PAN data. If in case you missed it I want to draw your attention to it.

Essentially, if you are looking to be PCI-DSS 2.0 compliant there are few ways you can achieve that. The most painful would be obviously a rip-and-replace strategy and the easiest would be to do it in an incremental, less intrusive method.

First approach, the Monolithic big bang approach, is the legacy way of doing things. Once you figure out the areas of your system that are non-compliant (that is either storing PAN data –encrypted or not, or processing PAN in clear), you decide whether you need that component to be PCI compliant. As the PCI audit is very extensive, time consuming and very methodical, in which every process, application, storage, database, and system will be looked at and thereby it becomes very expensive. Once you figure out which components need to be PCI compliant you can do the rip and replace approach in which you will touch every system component that needs to be modified and rewrite the system to become compliant. This might involve touching every component and change your entire architecture. This essentially will be the most expensive, painful and the slowest before you can be compliant. While this can be the most effective for spot solutions, this could be an issue if you have to do this every time when the PCI-DSS needs change (which seems to be every year).