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.

Massachusetts Backtracking on Data Security Legislation

If you haven't heard of the Massachusetts data security law, you probably don't deal with too many security vendors. My inbox is cluttered with invitations to vendor-sponsored webinars warning of the dire consequences of this law. This "game changing" regulation requires companies to "fundamentally re-assess how you secure your assets"

Of course this isn't true. There was no need to panic before. And now there's really no need to panic, because the Massachussetts legislature may be watering the law down much further. A proposed state senate bill, SB 173, takes almost all the umphhh out of the original legislation:

- it removes the encryption requirement in favor of technological neutrality

- it defers to (much weaker) federal law when relevant

- it basically give a free pass to smaller companies

I don't know what the status of this bill is, although it seems like there is a general consensus that the original law will be watered down one way or the other.

So if you just went out and bought a bunch of fancy encryption gear or log readers or other stuff, you might want to check the return policy. Those might be great things to have, but they are probably totally irrelevant to being in compliance with state and federal laws. There is this bizarre consensus that spending money is more important than re-engineering processes in securing data, when in fact the exact opposite is true.

In case you missed this, let me say it one more time - there is absolutely no need to buy anything as a result of the Massachussetts legislation. Not for big companies. Definitely not for small or medium sized companies. In fact for companies with limited staff buying stuff will probably do more harm than good. You would be much better off locking down the configurations and enabling security features on your existing big vendor stuff (your AD, Exchange Server, Oracle, and the like) than starting to learn how to use new toys.

This isn't supposed to be a rant against security vendors. But there has been a great deal of misinformation (to put it diplomatically) surrounding these regulations. The you-should-buy-productX-because-of-the-new-Massachussetts-data-law argument was absurd to begin with and is even more absurd now that the legislation is on life-support.

The problem in the security space is that there is no real counter voice to the fallacy that you can or should buy compliance. The vendors have an obvious interest in hyping the laws. The analysts stoke the fire. Technical security types can't be bothered to read through a bunch of regulations and so they reluctantly drink the vendor Kool Aid. And everybody else doesn't care because information security legislation - with all due respect to our industry - is among the least important issues being discussed in the United States right now.

Security and the Small Business

There's one part of data security legislation that I find a bit perplexing - the small business exemption. This basically says that any security measures you need to take are only relative to the size and complexity of your business. It is a central part of the Massachussetts legislation as well as most other similar regs I have seen.

Now I get that small businesses require protection from overbearing regulations and legislation. But you can't run a nuclear power plant with a team of 10 people (well, at least I hope there's no out there running a nuclear power plan with just 10 people). Is there a minimum number of people you need to provide adequate data security?

The answer is probably not, as long as you have outsourced both your operations and their security. Really huge famous companies can be shockingly small. In one of the articles about the Craigslist/South Carolina AG feud going on these days there's one detail that really jumped out at me. Craigslist has only 30 employees. To me it's mindblowing that a company with one of the most popular websites in the world and one of the world's leading brands is run by less people than were in my subway car this morning. Yet I haven't heard any one argue that Craigslist is unable to provide sufficient security, or that they should be given a break - or need to be given a break - on their data security.

But not every company is Craigslist. To securely operate a vast complex database with a lot of personal information either requires a lot of money or a minimum number of people. Most small businesses don't have the money and will always be under enormous operational pressure to dedicate staff away from security.

Buying compliance

I have been thinking a lot about the price of compliance lately. Almost every day I get unsolicited emails from a vendor (frickin' provide-your-email-to-get-IT-content websites) pitching their product with the big label SOX COMPLIANT, HIPAA COMPLIANT in big letters (sorry for shouting, but those were direct quotes).

I still can't figure out how such misleading claims can be so prevalent. Take SOX compliance. SOX says precious little about information security, and only concerns itself with security insofar as it touches on financial controls. In other words - SOX requires you to have that security in place that prevents people from cooking your books. SOX says nothing about firewalls, and yet many firewalls are advertised as SOX compliant. 

Now part of this FUD undoubtedly originates with auditors. From my experience audit firms send their heavyweights for the financial part but tend to send some pretty inexperienced folks to do the IT audit. These recent grads sometimes are political science graduates who realized that all the good jobs are gone, did a quick CISA, and *poof* became auditors.

Here's a quick reality check for all of us in the information security industry - the IT audit is just a sideshow in the financial audit, and a pretty minor sideshow at that. And when it comes to being in IT compliance, the lion's share of that is your user access security. I'll say that again in case you missed it - when IT systems are responsible for the inaccuracy of a company's financial statements, it's because of programming errors, broken reporting processes, or someone having access to a system they weren't supposed to. It's almost never (at least not as far as I know) because someone managed to take advantage of the fact that Apache wasn't patched on the web server. When the auditor comes with a cookie-cutter checklist, you will usually be able to provide compensating controls for technical deficiencies but its much harder to fudge the integrity of your business processes.

The main area where you can fail a financial IT audit is in the area of user access to data and applications. If an organization has been sloppy about granting access to network shares or to critical systems, they are in material breach of some basic audit requirements. But there is no product in the world you can buy that will do this for you. Let me repeat that one more time because it contradicts at least 5 sales pitches you have heard in the last month - you cannot buy a product that will magically make sure everyone in your company only has access to the data they are supposed to have. This is because there is no product that can solve your office politics, and (despite the claims of some DLP vendors) there is no product that can really intelligently discern whether data is sensitive or not.

While we're on this can't-buy-me-compliance riff, let's not forget the buttons for "HIPAA Report", "SOX report" etc that some security products come with these days. There's almost a cartoon-like image to a SOX auditor coming in and asking for a report and the compliance manager saying, well, I'm glad you asked, I have this nifty SOX report button I will press here.

The somewhat heretical truth is that compliance requirements are basically the same across regulations, industry contracts, and even jurisdictions - make sure only the people who need access have it, make sure you know what happened when, and make sure you have a properly managed environment. But almost all of this is about process, not technology - and where there is a technological need, in most cases there are pre-existing modules or plugins that provide this functionality (I say in most cases, because there are some systems - most notably administrative credential management systems - that truly fulfill the spirit of compliance requirements yet have not been built into existing user management products).

The trend to built-in security and compliance has been underway for a long time, as the major vendors have integrated regulation-driven customer requests over the years. It will be hard for niche products to survive over time without being integrated into larger product suites for the simple reason that most organizations have a very strong incentive to limit the number of vendor relationships they have. Every new vendor represents a significant overhead in terms of sheer contact, interaction, contracts, etc, and of course the significant risk and complexity that it adds to the environment. 

So to circle back to buying compliance - the real costs of security related compliance are in the time and organizational capital required to bring about real business process change (the second half of that sentence sounds like buzz word drivel, but sometimes buzz words exist for a reason). While there are certain niche products that can assist with compliance requirements in certain industries, for the most part organizations - especially any midsize company - can get compliance by leveraging functionality in their existing infrastructure.