If you’ve been following the blog, you know that the California Consumer Privacy Act, or CCPA, is set to take effect on January 1, 2020. It will establish a new bar for consumer privacy rights at the US state level. The California law can count among its many innovations a broad definition of personal data covering email, browsing history, biometric, geolocation and more; consumer right to access and delete data; and a limited right to sue through the State Attorney General.
The CCPA has also given consumers a powerful right to opt-out of the sale of their information to third parties at any time. Companies must inform the public of this right through a prominently displayed “Do Not Sell My Personal Information Link” on websites. There’s even a tougher opt-in requirement for the sale of information of children (under the age of sixteen) where explicit consent is required.
A Closer Look at Data Security in the CCPA and NIST CIS Framework
There are obvious parallels between the CCPA and the EU GDPR. A law firm has mercifully put together this chart comparing the two. One of the key differences between the CCPA and the GDPR is that the EU law has very strong data security requirements. The GDPR contains both data privacy and security rules. That is not the case with the CCPA, which is focused on consumer privacy.
Over the last few months, there have been a few amendments kicking around Sacramento. One that caught my attention, AB-1035, adds very specific language about … data security.
AB-1035 takes on the challenge of defining the well-known boilerplate phrase “reasonable security”, which is often found in state data breach laws but typically with no explanation attached to it meaning. This amendment boldly proposes the NIST Framework for Improving Critical Infrastructure Cybersecurity (CIS) and another NIST standard 800-171, which is a trimmed-down version of the encyclopedic 800-53, as a potential baseline security standard for the state.
This is a big deal: not even the EU GDPR explicitly refers to outside data standards. Alas this amendment proved to be too radical for California: the CCPA was finalized on September 13, and the bill doesn’t include this particular amendment. Oh well.
Let’s give California credit for considering the CIS Framework. In case you’ve forgotten, a framework is not the same as a security standard. Instead, it’s a kind of meta-standard, which provides a list of meta-security controls that map into real security controls within existing data standards.
The CIS Framework supports mappings into, not surprisingly, NIST 800.53, and the other usual suspects, including COBIT 5, SANS CCS, ISO 270001, and ISA 62443. You can see part of the mapping below:
The big idea behind the NIST CIS Framework is that companies that are already following existing data security standards can continue to do so. They simply examine the parts of CIS they’ve covered, and then fill in shortfalls as needed. The CIS Framework as a legal basis for compliance makes good sense since it doesn’t penalize companies for having data security programs already in place!
Meanwhile in Ohio: Their Innovative Data Protection Act Deserves Attention
The CCPA is still very innovative and as one California legislator put it “the first consumer privacy act in the country”. No arguments from me. This doesn’t mean all the interesting data security news is coming from the coasts. In late 2018, Ohio passed its Data Protection Act, which provides an interesting “nudge” to get companies to become compliant.
The Act gives a legal “safe harbor” to companies facing potential lawsuits: if they follow a prescribed list of standards and frameworks (below), then they can use this as a defense in their trials.
As you can see, the NIST CIS Framework makes it to the first option of Ohio’s safe harbor list, along with all the other favorites – 800-53, 800-171, FedRAMP, CSC, etc. Good choices, Ohio.
It’s important to also mention that the Ohio law is completely voluntary. If a company doesn’t decide to follow one of the aforementioned security standards, then the thinking is they’ll likely lose cases brought my injured consumers. And therefore they’ll be incentivized toward good security practices. Let’s call this an experiment in free-market economics, data-security edition.
Legal analysts already have some quibbles with the Ohio Data Protection Act, interpreting its safe harbor as a kind of get-out-of-jail card. It’s not that simple!
According to the Ohio law, companies have to “create, maintain, and comply with a written cybersecurity program that contains administrative, technical, and physical safeguards” that follow the aforementioned security standards and frameworks. This is more than just saying you’re following security requirements — you have to show you’re “walking the walk”.
This raises the issue of what it means to follow any kind of security standards written into law. With, say, the GDPR, compliance is all about process and “showing your work”, as Mintz Levin attorney Sue Foster once told us. In short: GDPR regulators will give you some credit for having a security program in place, maintaining it, and documenting what you’re doing. This seem to be what the Ohio law is requiring.
But the GDPR also has black letter law calling for specific security measures —“Data Protection by design and default” — and a seperate enforcement system through their regulators. Not the same as Ohio.
We’ll have to wait and see whether Ohio’s nudge idea and having private parties work out their disputes in courts get companies to improve their data security.
The Future of Data Security: Identify, Protect, Monitor, Respond, and Recover
In any case, kudos to Ohio for referencing NIST CIS Framework in their law. And an “A for effort” to California as well. The IOS blog is a fan of the NIST approach to data security. Anyone who’s ever delved into different data security standards (after having chugged a large mug of coffee) has likely noticed, cough, lots of similarities between them.
With their CIS Framework, the NIST folks have done the hard work of organizing security controls into more abstract categories, which they define as Identify, Protect, Detect, Respond, and Recover. In short, give them a popular data standard and a specific control, they can map it back into one of these groups.
The advantage is you don’t become lost in highly-specific controls, and instead can see the bigger picture. And as the NIST folks have pointed out, there’s a cyclic aspect to their broad categories: once you’ve responded to an incident, you’ll want to go back to the beginning and identify and stomp our security holes that led to that last incident.
In fact, I thought the NIST CIS Framework was such a great improvement, I wrote a blog series singing its praises. In it, I explained how Varonis DatAdvantage can support these five categories, keep you on track, and help you prove in potential legal suits or hearings with regulators that you’re doing the work.