Visa Embraces End-to-End Encryption

It feels like it has been a slow last few months in the information security regulatory and compliance space. That is my excuse for why it has been quiet on this blog for a while (well, that and being very busy with other stuff).

PCI was back in the news last week with an announcement by Visa in support of end-to-end encryption. With all the hundreds of requirements that PCI imposes on merchants, it can come as a bit of a surprise that data is not in fact encrypted at all stages as it travels between the Point-of-Sale and the card brand. This latest announcement by Visa is a signal that the payment industry is finally looking to fix this.

Further evidence of this shift comes from an unexpected source. This week I had the chance to hear Heartland CEO Bob Carr talk at the SC World Congress in New York about the massive data breach his company experienced in January of this year. Now you might think that the Heartland CEO addressing a security conference would be as likely as Nancy Pelosi addressing the NRA. But ever since Heartland's data breach, Carr has been aggressively engaging the IT security community.

He has called for reform of the QSA system (more on that later) and Heartland is promoting a new end-to-end encryption standard being developed with Voltage called E3. The E3 system will ensure encryption of card data from the moment a card is swiped until it is transmitted to the card brands.

Heartland is not alone in proposing a more robust system for securing card data throughout the transaction lifecycle. First Data and RSA have a competing tokenization product that basically replaces sensitive card data with random numbers and offers both advantages and disadvantages when compared with the E3 end-to-end encryption approach.

So will these new technologies reduce the number of credit card data breaches? That is hard to say, because we don't know enough about the cause of most of these breaches. But it seems like a safe bet that implementing these systems will at a minimum substantially reduce the risk of data compromise between the PoS and the acquirer.

But What About Internet Sales?

Card Not Present (CNP) transactions are a different ball game. After all, card data in a CNP transaction needs to travel a long road before it is safely in an end-to-end or tokenized environment. Removing the number of nodes that store actual unencrypted data will not do anything to secure these initial stages of CNP transactions. But it will make it easier to identify where breaches occurred. And this, in turn, will help sort out the liability issues which are at the heart of the practical problems with PCI.

Untangling the Liability Mess

Let's take a closer look at the liability issue. One reason for the poor state of application security today is that organizations are often not held accountable for data breaches that do not involve card holder data. With nearly ubiquitous data breach laws in effect, this is usually not the result of willfully concealing a breach but rather because companies don't know - and aren't motivated to uncover - whether they have been breached. In an ecosystem where many parties have handled the same data set, breaches cannot be definitively traced back to the offending party. This leaves little inherent incentive to invest in security technologies.

Take for example the fraudulent use of Social Security Numbers. If a criminal manages to take out fake credit in the name of a certain John Smith through use of his SSN, address, and birthdate, there is almost no way to realistically figure out where the leak came from. After all, John Smith has probably directly and indirectly provided this information to gazillions of service providers and others over time.

Cardholder data is a different ball of wax. The payment card industry is in a unique position to trace back its fraud and does this very successfully in the physical world. A waitress who runs cards through a skimmer in the back of the restaurant will lead to a list of fraudulent charges that will in all likelihood be traced back to the merchant. So the restaurant is incentivized (have never really been sure if that word actually exists) to prevent such fraud - whether by trying to hire trustworthy employees, keeping a closer eye on employees, etc.

In the Card Not Present environment, the lack of end-to-end encryption makes pinpointing blame slightly more difficult since the identical data set may exist in a number of different systems belonging to different entities. Perhaps not more difficult in a breach on the scale of Heartland, but more difficult for the thousands of mini-breaches that occur all the time. By securing this travelling data, it becomes easier to actually locate where smaller scale breaches have happened.

The Failure of the QSA System

As the screws tighten on data-in-transit and it becomes easier to assign blame for misused cards, the issue of QSA liability becomes even more important.

The QSA system is badly broken, and Heartland is just another example of a certified entity that was breached shortly after certification. The lack of liability is the greatest failure of the PCI system. In a normal financial audit, part of the deal is that if the company totally opens its books and does nothing to willfully mislead its auditor, then the auditor takes a certain liability with regards to the statements it produces. With PCI, nothing of the sort exists. What is the PCI audit worth if no one is responsible for its conclusions?

(The oft-quoted notion that one is never truly PCI compliant because compliance is a just snapshot in time doesn't hold much water. After all, a financial audit is also just a snapshot in time, in the sense that if someone raided the corporate bank account a week after an audit then of course the audit results are no longer valid. Liability can exist even without continuous monitoring)

Small Businesses

The liability issue is especially critical for small businesses. Although PCI has been around for a while, there are still a vast number of the 6 million odd smaller merchants in the US whose only experience with PCI is a line item on their merchant fees (many acquiring banks actually itemize a "PCI fee" to merchants). The credit crisis has left smaller merchants in a precarious situation, with merchant accounts being shut down when accounts exceed normal charging activity. Add PCI fines to the mix and a small company could easily go out of business altogether if it falls afoul of its acquiring bank.

Which means that in the short-term, increased awareness of PCI is driving an increased use of external payment gateway systems to offload card processing altogether. Most gateways are relatively inexpensive (small monthly fees and a small per transaction fee). It seems unlikely that any small company can invest the necessary funds to really make their IT systems PCI compliant. Data security regulations like the Massachussetts law go to great lengths to emphasize that small businesses are only expected to spend relative to their size. PCI is less forgiving. Level IV merchants may be under less validation requirements than Level I merchants, but the actual requirements are the same. It is no wonder that merchants are exiting the online payment business completely.

Of course those small businesses still have to deal with the PCI requirements for their non-Internet processing, but increasingly these IT environments are separate from a company's web presence. Many companies are outsourcing this processing as well. Indeed, significant amounts of card data can pop up in unlikely places. A recent British survey revealed that 97% of call centers record sensitive card holder data data. Better to have those systems outside the gate as well.

The new move to end-to-end encryption is certainly good news for the payment card industry, but will also require businesses to invest in new equipment and generally reassess their card payment architecture. For many small web merchants it may well serve as a motivation to reduce their card gathering activities even further.

Nevada Mandates PCI Standard, Part II

Did Nevada really mandate the PCI Standard into law last week?

It sure seems like it when you read Senator Wiener's bill SB 227. I am not a lawyer, but the following sentence seems pretty clear: "If a data collector doing business in this State accepts a payment card in connection with a sale of goods or services, the data collector shall comply with the current version of the Payment Card Industry (PCI) Data Security Standard, as adopted by the PCI Security Standards Council".

For anyone involved in information security management or compliance, this is a really big deal. PCI has just been catapulted from a contractual obligation to a full legal requirement.

No one seems to have seen this one coming. In fact, I am not even sure that the Nevada legislature really saw this coming and they may not have realized the very far reaching implications of this legislation. But more on that in a minute.

Ira Victor, President of the Sierra Nevada chapter of Infragard and Director of Compliance at Data Clone Labs, was kind enough to reach out to me this week after I published my original post on this topic. Ira was intimately involved in the discussions around the new Nevada PCI law and testified before the Nevada Senate Committee on Judiciary in support of the law. Ira has some terrific insight into the history of this bill that can be heard in my interview today with him on this topic.

Here's a quick history of the bill as related to me by Ira. The current law came about to replace NRS 597.970, an earlier bill mandating encryption that apparently left open the door for criminal liability and did not define encryption. To remedy these issues, the new bill is much more specific about encryption requirements and somewhat randomly also requires PCI compliance. In exchange it provides a safe harbor for companies that are PCI compliant.

There is a thick irony here. Businesses that objected to the original bill on the grounds that it was too harsh now have a much much stricter bill on their hands that actually mandates PCI. This is either a very bold and trailblazing move by Nevada, or a last minute oversight because businesses didn't understand the implications. My money is on the latter for a couple of reasons:

1. There is no precedent of any other state legally mandating PCI. Some people think PCI is good and some think it is bad. But either way there is something plain weird about a law mandating a specific contractual agreement between merchants and card issuers.

2. There is no reference to PCI in any of the discussions or testimony before the Nevada Senate Committee on Judiciary. Wouldn't such a major shift in infosec policy at least be discussed by law makers and special interest groups ahead of a vote?

My guess is that the Nevada legislature meant to waive liability for PCI compliant companies, but not to actually mandate PCI. Recent discussions in Massachusetts objected to the mere mention of encryption in that state's security regulation. I can't possibly see how the business community in Nevada would have knowingly agreed to the whole PCI enchilada without putting up a fight. Being forced to do PCI makes mandated encryption look like a walk in the park.

So if this law doesn't make sense, is it going to stick? Ira knows a lot more about the legislative process in Nevada than I do and he insists that there is very little wiggle room to delay this law. But I just don't see the state of Nevada actually enforcing this. How many small businesses can really claim to be PCI compliant? Even the PCI Council itself tacitly acknowledges as much through the publication of their Prioritized Approach.

For more on this topic you can listen to my interview with Ira here.

Nevada Mandates PCI Standard

Nevada has recently passed a law mandating PCI compliance for companies accepting payment cards that do business in the state. It is scheduled to go into effect on January 1st, 2010.

This makes Nevada the very first state to actually mandate PCI. The prize for toughest-state-data-security-law used to belong to Massachusetts. But Mass has recently been wavering and its technical requirements are almost non-existent compared to PCI.

The Nevada law is no reason to panic and doesn’t really change much for companies dealing with credit card data. Those companies already have a contractual obligation to adhere to PCI. The Nevada law ups the ante by making this an actual legal requirement, but the standard itself remains the same. And as far as actual enforcement goes, the Nevada law says nothing about penalties whereas PCI has the ability to fine non-compliant companies.

The bigger change is for companies that deal with non-credit card personal data. The Nevada law defines nonpublic personal information as a social security number, driver’s license number, or account number in combination with a password. It mandates the use of encryption for the transfer of such data outside of a company's control (this requirement existed in various forms in previous Nevada legislation as well).

One would hope that there aren’t too many companies out there sending account information together with passwords unencrypted. That leaves full Social Security Numbers and the much-less-frequently used driver’s license numbers. (Interestingly, the regulation doesn’t consider the last four digits of the SSN to be personal information. Which is kind of strange when you consider that the last four digits are the most random parts of the number. Oh well).

I suspect there are many companies out there with Nevada customers who will have to play some catch-up when it comes to SSNs. Full SSNs are still frequently used as a primary identifier for many web services related to payroll and benefits as well as many services that have nothing to do with taxes.

Most of these services already encrypt data on the interface level – it is the exception rather than the rule today to see a plain old http login page that asks for your SSN. It’s much tougher to know what is going on behind the scenes. But does the Nevada law really require companies to change their back-end data processing?

Because the law only talks about the “secure system” and the area “beyond the logical or physical controls of the data collector”, it is doubtful that this regulation requires any sort of SSL encryption of data that is not going out in cleartext over public networks. Data behind firewalls or behind some form of password protection would not appear to require encryption based on this wording.

One positive potential outcome of the Nevada law is that it may encourage organizations to move away from using SSNs when they don’t have to (a trend that has already been underway for a while, particularly at universities). There is something particularly jarring about being asked to provide your SSN to get cable service. Strict new rules around handling SSNs may be the necessary kick in the pants for SSN-addicted companies to finally overhaul their authentication methods.

One final thought about the Nevada law itself. In what I believe is a first for state laws, it directly references FIPS, NIST, and other “established standards bodies” when discussing allowable encryption methods. Most data breach notification laws give an exemption for encrypted data without giving any meaningful definition of the term. This has allowed companies to avoid notifying of a data breach when the compromised data was somehow obfuscated. This law will make it harder to claim that some light obfuscation or encoding actually constitutes encryption.

SO…DO I NEED TO BUY SOMETHING TO MAKE THIS GO AWAY?

Companies that sell encryption products have a field day with laws like this. But - like other data security regulation - you don’t need to buy anything to be in compliance with the Nevada data security law. You just need to make sure that you are not sending sensitive data in cleartext over public networks. This means a bit more messing around with certificates and configurations prior to releases but not much more. And of course you also need to make sure that anywhere you are storing this data at rest is considered part of your “secure system” or has some logical or physical controls in place.

FURTHER READING

The actual text of Nevada Senate Bill 227 can be found here.

A good overview of the evolution of data security legislation by Andrew Baer can be found here.

UPDATE: My newest post on this topic can be found here. You can also listen to my interview with Ira Victor who testified before the Nevada Senate Committee on Judiciary in support of the bill.

PCI Hearing in Congress

Last week the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology held a hearing on the effectiveness of PCI.

You know that PCI has hit primetime when Congress is taking a look at it. But PCI's Washington debut didn't go as smoothly as the Council would have liked. As Anton Chavukin points out, PCI was ripped at by both the government and the merchants for opposite reasons - the feds think it's too little, and the merchants say it's too much.

I don't think that PCI is a perfect standard, but it is wrong to assume that every data breach of a PCI-certified entity signifies the complete failure of the standard. PCI has taken positive steps recently, including laying out a "Prioritized Approach" which should help make the standard more digestible for smaller organizations.

On the whole the problem with PCI is not so much that companies declared compliant are suffering breaches, but that companies are being declared PCI compliant too readily. Oh, and no one seems to know who is liable when this happens.

But the congressional hearing didn't really focus on liability and enforcement issues. The main theme from government was that PCI was broken and that the bar needs to be raised. Chairwoman Yvette Clark's prepared statement also singles out eliminating terrorist financing as a major reason - perhaps the most important reason - to eliminate the hacking of companies housing credit card data.

This is an interesting because there is a big difference between preventing data breaches in general and preventing data breaches that benefit terrorists. Let's assume for the sake of argument that preventing terrorists from committing credit card fraud is a major priority (although somehow I fail to see why credit card fraud - a crime with many digital footprints - would be their first choice). Doesn't that mean that the standard should focus on preventing the specific types of fraud that terrorists are most likely to commit? (For example, war driving is not really a concern if we are worried about people commiting fraud from foreign countries).

In practice I don't think that it makes sense to mix national security into the PCI discussion. I think the real debate about PCI is whether a having a technology-specific standard reduces the number of data breaches. As I have written in the past, most compliance - whether SOX, HIPAA, GLBA, or others - is so non-technical as to really not require companies to do anything specific. On the other hand while government regulation is good for establishing general principles, it has done a poor job when it starts to mandate specific technological solutions. So the government would probably do a worse job at PCI than the PCI Council does.

Industry tends to be wary of government regulation, and often with good reason. The congressional hearing included the statement that the only way to protect networks is by continuously pen testing them. This may or may not be true, but I am not sure that the government is best positioned to mandate one approach over another. A further indication of the entry of opinions being accepted as fact was the repetition by one of the congressmen of the oft-quoted yet ridiculous figure of $1 trillion dollars in cybercrime losses.

PCI is in very early days, and the one thing that wasn't even mentioned at the hearing (unless I missed something...) was the issue of assessor liability. If a PCI-compliant company is breached, shoudn't the finger first be pointed at the assessor to justify why they certified the company in the first place? Until assessors are somehow on the hook for the quality of their assessments (in the same way that an accountant is), one can't really blame the standard itself for failing to enforce itself.

The Prioritized Approach to PCI

A week or two ago the folks at PCI published "The Prioritized Approach to PCI DSS Compliance".

This was a long time in coming. The original PCI list received a lot of criticism for just being a long laundry list. I don't think there's a single company in the world that could honestly claim to be in total compliance. Companies - especially those new to PCI - don't know where to start with the hundreds of new security requirements that have just landed on their lap.

So it's certainly a good thing that the PCI Council folks were kind enough to prioritize the requirements into 6 categories. (Although in the legal fine print the PCI Council insists that the prioritization is for information purposes only and that all requirements are still mandatory for compliance).

Let me start out by saying that I basically like the concept behind PCI. Too many security regulations are just empty fluff. For all its imperfections, PCI puts its money where its mouth is - detailing specific technical measures companies need to take to achieve security. PCI doesn't always get it right (more on that later in this post) and there clearly needs to be some change in the surrounding audit mechanism. But I still think that the standard as a whole kind of works in improving the overall security of the companies subject to it. This is a classical case of security economics at work; the PCI stakeholders (the credit card companies) have a direct financial interest in preventing actual breaches that lead to loss.

The PCI Standard can get away with requirements no state or federal regulation ever could. Legistlators try to avoid mentioning specific technologies in legislation. This is a good thing for limiting the influence of lobbyists and preserving technology neutrality (any one who has had the misfortunte to deal with electronic signature regulations knows how messy it can get when specific technologies find their way into legislation). But PCI is not a regulation and does not depend on a legislative process to be updated. It can specifically mention certain technological concepts and then update them over time. Although you sometimes mistakenly here in the news about "PCI being adopted as law" in certain states, this is almost always a complete misrepresentation (as in the case of Minnesota, whose PCI-inspired law only enacted a few very generalized versions of some of the PCI requirements).

The Prioritized Approach gets some priorities right and some of them can IMHO use improvement. The document says that data is culled form actual breaches, giving the PCI Council data that most of us don't have to determine what is important and what isn't.

The Prioritized Approach hits the nail on the head with priority one - removal of sensitive data and limit data retention. This information security principle seems so obvious and yet I rarely see it stated in such a clear and succint way. The lowest hanging fruit - the bananas practically falling off the branch - is the deletion of customer data you just don't need any more. It's also the easiest thing to get buy-in from the rest of your organization - it requires few resources and has a very high risk-reduction-to-effort ratio. So absolutely no argument on this no-brainer for priority #1.

The relationship between 2 and 3 is likely to generate the most controversy- it is here that the PCI Council prioritizes network security over applicaiton security. But in today's environment, is it better to have hardened applications sitting on open machines or the other way around? The actual threat from web application vulnerabilities is still not well understood, and there are a number of items on OWASP Top 10 type-lists that do not pose a particularly high risk. But something like failure to validate input (priority 3) is in my opinion responsible for more attacks than some of the networking PCI requirements (eg installing a personal firewall on employee laptops, priority 3).

Currently almost all items in PCI Requirement 6 (Develop and maintain secure systems and applications) are assigned priority 3, and almost all items in PCI Requirement 1 (Install and maintain a firewall configuration) are assigned priority 2. I predict this will probably evolve over time, since there are clearly some app security issues which are more important than network issues.

A couple of final thoughts - the Prioritized Approach puts the appropriately low priority on pyhsical security. One of my recurring pet peeves when dealing with vendor security whitepapers is the overemphasis on physical security. Physical security is well understood, is implicit in doing business, and has much stiffer criminal penalties associated with it. When looking to implement an information security program, "restricting physical access to publicly accessible network jacks" (priority 9.1.2) has been justifiably pushed down to priority 5.

All in all the Prioritized Approach is a nice addition to the PCI Standard. For all its troubles, PCI is the closest we have to an industry consensus on what is considered reasonable security.

Heartland Security Breach - Here We Go Again

If you needed to get bad news out, today was the day. With the world watching the inauguration of President elect Barack Obama, Heartland Payment Systems announced a mammoth breach of their security. Heartland who you ask? New York readers can breathe a sigh of relief - this is not Heartland Brewery and the credit card you use to pay your tab is safe. But on second thought that card number might not be so safe after all. Heartland Payment Systems is the 6th largest credit card processor in the country and serves no less than 250,000 locations. There's a good chance your credit card number is floating somewhere in their system even if you have only ever used it to buy an occasional beer.

We don't know much about the breach right now; in fact, most people don't know much about Heartland (it's wikipedia entry is two sentences long as of today, but that's bound to change in the coming days). 

We are going to be hearing a lot about this breach, and it will follow TJMaxx, Hannaford, and other looseners of the security purse strings into the salespitch of every information security consultant.

But for now we know very very little about what actually happened. We can't conclude much on the very flimsy information we have, but here goes-

Obvious lesson #1: payment processors are a very attractive target for criminals. Their resources-to-sensitive data ratio is relatively low (in relation say to a bank), which makes them a softer target. They also process pure gold - attackers do not need to sift through mountains of other data and complex architectures they might encounter elsewhere.

Obvious lesson #2: the PCI system as it is currently implemented does not stop every attempt to steal credit card data. Like Hannaford before it, Heartland was PCI certified (by Trustwave, according to the Payment Systems Blog). 

The fact that PCI ≠ end-of-all-data-breaches-for-eternity has not stopped the renewed calls for PCI to be revamped, eliminated, or replaced. In an interview with Computerworld Avivah Litan of Gartner says "More radical security moves need to be taken by payments industry as a whole ... Such incidents show that the security requirements of ...PCI DSS being pushed by the major card companies is clearly not enough."

Unless Gartner is privy to some non-public information about this case, that's quite the rush to judgment. The grandiosely named www.2008breach.com  - Heartland's official site for breach information - has very scant information on the breach. So on what basis is Gartner saying that the security requirements of PCI DSS are not enough? While that may be the case, I would argue that there are at least a few other scenarios:

1) The PCI DSS requirements are enough to prevent the vast majority of data breaches, and the payment card industry accepts that incidents like this will happen from time-to-time. I don't work for Visa or Mastercard or anyone else in the payment industry, so I have no way of knowing if this is true. But clearly the PCI standards are meant to achieve a reasonable balance between security investment and risk reduction. This incident alone, and others like it, are not in and of themselves evidence that this hasn't happened.

2) The security requirements of PCI DSS are enough, but there was a failure of the enforcement mechanism (ie. QSAs and ASVs and the like). Again, the only detail we really know is something about "malicious software". It may very well be the case that strict adherence to PCI would have prevented this malicious software from getting installed or from being effective.

3) The security requirements are not the problem, but the broad license to introduce and interpret "compensating controls". This has always been an Achilles' Heel of PCI, since it introduces an almost entirely subjective element into the PCI process. There is very little accompanying PCI documentation to define the allowable and appropriate scope of compensating controls.

In the coming days and weeks we will get a better indication of what exactly happened. This breach may well reveal gaping holes in the security requirements in PCI as Gartner claims, but for now my money is on something less radical than that.

And one final thought on the entire PCI process. Because PCI is in such early days, there has never (as far as I know) been any real legal test of the liability mechanisms behind PCI auditing. If Trustwave mistakenly certified Heartland as PCI compliant, does it bear some of the costs associated with this breach? If the answer to this question remains negative, I don't know how we will ever get effective and reliable PCI audits.