On May 30, 2009, Nevada enacted a new law, SB 227, which will basically replace NRS 597.970 in January 2010.
In many ways the new law is an improvement over the much more vague, and brief, NRS 597.970. I want to focus here on an improvement, but something that still leaves much to interpretation; that is, what is meant by “encryption”?
According to NRS 205.4742,
“‘Encryption’ means the use of any protective or disruptive measure, including, without limitation, cryptography, enciphering, encoding or a computer contaminant, to:
1. Prevent, impede, delay or disrupt access to any data, information, image, program, signal or sound;
2. Cause or make any data, information, image, program, signal or sound unintelligible or unusable; or
3. Prevent, impede, delay or disrupt the normal operation or use of any component, device, equipment, system or network.”
As I wrote in a post several months ago, this definition caused IT folks to fret, and lawyers to push for inexpensive or free non-encryption solutions that met the “letter of the law.” I actually heard lawyers ask the IT areas if they could write a program to “scramble” data and make it “unusable” themselves. Of course, the IT folks said they could, so then the business leaders, at the lawyers’ advice, vetoed any true encryption solution and asked the IT area to just scramble the data. This is very risky, and unwise; such home-grown scrambling programs are fairly easy to reverse-engineer to reveal the data.
Now SB 227 defines encryption as follows:
“(b) “Encryption” means the protection of data in electronic or optical form, in storage or in transit, using:
(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated
cryptographic keys necessary to enable decryption of such data; and
(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.”
Okay, now this is an improvement, by not just stating the data is unusable or unintelligable in it’s form. But, there are still problems. For example, what is considered to be an “established standards setting body”? They provided a good example in NIST, but what other types of organizations? I anticipate this will become a point of contention. Can an organization establish their own “standards setting body” and then have them document a standard that simply scrambling the data using some type of algorithm will be in compliance? As worded it could be argued as such.
And how about how this definition of encryption compares with the definition in Nevada’s breach notice law; SB 347?
It defines encryption according to the definition in NRS 205.4742, which is listed earlier, and is what the original NRS 597.970 (which is being replaced by SB 227) referenced.
So, there is now a law requiring data moving through networks outside the business network and on mobile devices to be encrypted to an “established standard,” such as one from NIST, but the breach notice law will not require notification for any breaches involving PII that is “encrypted” simply by scrambling it or making it unintelligible.
So, what’s the motivation for oranizations to actually use strong encryption if the breach law will not require the organizations to report a breach of PII that is simply scrambled? As the laws are written, an organization with a breach of simply scrambled PII would be liable for damages under SB 227, but according to SB 347 they wouldn’t need to report such a breach, so who would know?
Seems Nevada needs to re-align their laws so that they are in agreement with each other.
Tags: awareness and training, encryption, Information Security, IT compliance, IT training, Nevada, PII personally identifiable informaton, policies and procedures, privacy training, risk management, SB 227, SB 347, security training