The FTC charged that ControlScan had “misled consumers about how often it monitored the sites and the steps it took to verify their privacy and security practices.” Although the seals claimed that ControlScan had verified the site’s privacy practices, ControlScan did “little or no verification” of those practices, according to the FTC. The FTC also took issue with the fact that the seals had current date stamps even though ControlScan did no daily reviews.

The settlement agreement required ControlScan’s former CEO to give up $102,000 in profits. It also suspended a $750,000 penalty against the company for inability to pay.

It’s uncertain whether privacy or security seals mean much. Even when providers scan daily, how much assurance can one expect for $71.50 per month? McAfee, the big player in the market after it bought (and renamed) the “HackerSafe” seal, had its own bit of bad press a couple of years ago when it turned out that several “Hacker Safe” sites were vulnerable to cross-site scripting attacks.

Even though ControlScan appears to have been in a different category than legitimate privacy seal vendors, the FTC settlement highlights a classic reputation problem with these seals. The seals look like they mean something, but the only way to know for sure is to check the seal provider’s practices—which undermines the point of the badge in the first place.

This should be an interesting case to watch. For a discussion of how this case might affect privacy for government employees, see Orin Kerr’s post over at the Volokh Conspiracy.

The Court is deeply concerned with the harmful and widespread ramifications associated with negligent and inattentive electronic filing of court documents. Although electronic filing significantly improves the efficiency and accessibility of our court system, it also elevates the likelihood of identity theft and damage to personal privacy when lawyers fail to follow federal and local rules.

For example, suppose an employee has access to an employer’s computers for regular business purposes, but e-mails confidential data to an outside account. Later, he leaves the company and uses that confidential data to set up a competing business. Did the employee access that confidential data without authorization? The simple answer would be “no”: he had an account, he was allowed to use it, that permission had not been revoked, so any access was authorized.

The Ninth Circuit Court of Appeals recently adopted essentially this definition. LVRC Holdings, LLC v. Brekka said that such conduct is not unauthorized for purposes of the CFAA. The court looked at the language of the statute and a dictionary, and held that an employee has authorization to access a computer when the employer has given permission to use it. Because Brekka’s permission to use the computer had not been revoked when he accessed and mailed data to an outside account, the court held that his access was not unauthorized.

The Ninth Circuit rejected the agency-law analysis from a 2006 Seventh Circuit decision, International Airport Centers, LLC v. Citrin. That case had held that an employee’s authorization to access a computer ended the moment he breached his duty of loyalty to his employer—in that case, by wiping data from a laptop to hide evidence of misconduct. But in LVRC, the Ninth Circuit stuck to the text of the CFAA, noting that the CFAA is a criminal statute and should be interpreted in favor of lenience. Because the Ninth Circuit could find no agency law principles in the text of the CFAA, it held that a person uses a computer without authorization “when the person has not received permission to use the computer for any purpose . . . or when the employer has rescinded permission to access the computer and the defendant uses the computer anyway.”

An aspect of this case that might be of interest to employers is that Brekka did not have a written employment agreement and LVRC had no policies against e-mailing documents to outside accounts. Such a policy would presumably have made Brekka’s actions unauthorized. But it’s hard to write policies that cover every single thing an employee is not allowed to do. If a company wrote a policy that “employees are only authorized to use company computers to the extent that such use is consistent with company interests,” would that create the Seventh Circuit agency-law definition of unauthorized access? It seems like it might, but, as always, This Is Not Legal Advice.

The law is in Minnesota Statutes section 609.8911, which was added in 1994. It reads:

A person who has reason to believe that any provision of section 609.88, 609.89, or 609.891 is being or has been violated shall report the suspected violation to the prosecuting authority in the county in which all or part of the suspected violation occurred. A person who makes a report under this section is immune from any criminal or civil liability that otherwise might result from the person’s action, if the person is acting in good faith.

Chapter 609 is Minnesota’s criminal code, and sections 609.88, 609.89, and 609.891 are Minnesota’s computer crime statutes. Section 609.8911 therefore says that anyone who “has reason to believe” that any successful or attempted unauthorized computer access, damage, or theft has taken place must notify the county prosecutor.

Note what the statute does not say:

• It’s not limited to data an organization “owns or licenses,” as section 325E.61 is for data breach notification.

• It does not limit the reporting duty to situations where there’s a reasonable chance that the data was obtained by a third party. Because Minnesota’s computer crime statute outlaws attempted acts of computer crime, it seems to be irrelevant whether the attempted computer theft, damage, or unauthorized access was successful.
• It’s not even limited to data the organization handles—the language of the statute would seem to require telling the county attorney that someone else was hacked.

That’s broad. For example, a literal reading of the statute’s language would require calling the county prosecutor every time a virus scanner finds a virus. A virus either accesses a computer without authorization or damages it. As soon as the virus scanner alerts the user to the the presence of the virus, that user has reason to know that someone committed a computer crime. Does it matter that the user doesn’t know who committed the crime, that the county prosecutor can’t do anything with the information, or that universal compliance with the letter of the law would flood the prosecutor’s phone line with nothing but “I just got a virus” calls? Maybe in the real world, but there’s nothing in the statute to suggest that these concerns relieve anyone of the duty to report.

The statute is missing something else: penalty provisions. Any self-respecting criminal statute has two parts: (1) a list of things not to do, and (2) the penalties for doing those things. Criminal penalties can be specific, or they can just categorize the crime (as a felony, misdemeanor, etc.), but to have any force, they have to say what the cost of violating the law would be. There’s some question whether this is even a criminal statute—it’s in the criminal code, but it states an affirmative duty, not a prohibition, and it has no penalty provision. If it is a criminal statute, it’s mostly toothless.

It also appears that the statute has never been used. A search of Minnesota cases reveals no instance in which the statute was even cited, much less used to convict someone.

Becuase the statute has no penalties and has never been enforced, can you ignore it? Maybe. The stakes of doing so certainly seem low. But just try to find a lawyer who will say it’s okay to ignore any statute, even a toothless unenforced statute.

One reason to comply with the statute is that even a statute without penalty provisions can form the basis of a negligence per se claim. Negligence per se is a way for a plaintiff to use a statutory requirement to skip the usual inquiry into whether the defendant used reasonable care. There are technical requirements for negligence per se claims, but if those are met, a plaintiff’s case is made much easier. Here’s how it might work with section 609.8911:

1. A company sees an attempted attack, but doesn’t reasonably believe the attacker obtained any personal information, so does not report it.

2. The attacker, who actually did obtain data, misuses it, harming one of the data subjects.
3. The data subjects file a class-action against the company, claiming that the company was negligent in not telling them about the breach. To establish negligence, the plaintiffs point to section 609.8911, which says the company should have reported the attempted breach to the county prosecutor.

And—voila—a statute with no penalty provision has just become a problem for the company. Admittedly, that’s a stretch, and there are those “technical requirements” referred to earlier, but lawyers have advised their clients to avoid less probable risks.

The language of the statute, the lack of a penalty, and its immunity provision might make one wonder about the original purpose of the statute. It turns out that it was actually an early attempt at requiring data breach notification. In Minnesota House Judiciary Committee hearings held March 18, 1994, Rep. Phyllis Kahn, author of the original Minnesota computer crime law and the duty-to-report provision, said that her bill was an attempt to force banks and financial institutions to report computer crimes they might otherwise prefer to hide. It was “generally believed,” she said, that computer crimes were under-reported because these institutions preferred maintaining an appearance of security that could be hurt by disclosing a breach. She acknowledged that the section did not include any penalties for failing to report, but said that her bill would be a “good step forward,” and that she couldn’t imagine what a good penalty would be.

A few states have similar duties to report computer crimes, including Ohio and Utah. Georgia had a similar statute that was repealed in 1991. A handful of other states have general duties to report any crimes (or sometimes felonies), but in most states, there is no duty to report that one has seen a crime. The computer duty-to-report statutes appear to be isolated exceptions to this general rule.

Minnesota has a real data breach notification statute for a few years now. Perhaps it is time for the legislature to repeal or substantially modify section 609.8911. But until that happens, the safest course for any organization is to send the county prosecutor notice of any attempted data breach. It may seem silly (partly because, in many cases, it is), but that’s the letter of the law. With any luck, the busy prosecutor will respond with, “Thanks, but please don’t bother me again.”

The new law, S.B. 1017, makes two small changes to North Carolina’s notification requirements. First, it requires telling the state Attorney General about breaches of any size, not just those that affect more than one thousand people. Second, it requires the notifications to include contact information for the consumer reporting agencies (CRAs), the FTC, and the North Carolina Attorney General’s office.

The statute still has the same notification triggers as before: it applies to any business that “owns or licenses” personal information. The law applies to businesses that own or license data, but the statute’s definition of a “security breach” is not limited to breaches of information the business owns or licenses. It may just be a quirk of wording, but it looks like the law requires any business that owns or licenses data to notify people affected by any security breach. In fact, there’s nothing in the language saying that companies only have to disclose their own breaches:

N.C. Gen. Stat. § 75-65(a): Any business that owns or licenses personal information of residents of North Carolina or any business that conducts business in North Carolina that owns or licenses personal information in any form (whether computerized, paper, or otherwise) shall provide notice to the affected person that there has been a security breach following discovery or notification of the breach. . . .

I doubt that’s the intention of the law, but there’s the language: companies that own or license data shall notify the affected person that “there has been a security breach.” So, maybe it’s a business’s duty to inform consumers that a competitor has been breached?

Also note the statute’s broad interstate reach, pulling in “any business that conducts business in North Carolina that owns or licenses personal information in any form.” It doesn’t even bother to limit the reach of the statute to businesses that own or license personal information about North Carolina residents.

The law’s big changes are to consumer credit reporting. It made quite a few changes to the state’s security freeze law. It reduced the time Consumer Reporting Agencies (CRAs) can take to initiate or remove a freeze from five days to three, gives CRAs fifteen minutes to temporarily lift a freeze once the consumer has requested a temporary lift by phone or e-mail (if the request is by mail, the CRA has three days), prohibits the CRAs from charging for placing, removing, or temporarily lifting a credit freeze unless the request was by mail (the old law allowed charging $10 per request), and requires that credit reports under a freeze say that the freeze does not reflect a negative score, history, report, or rating.

Finally, the law adds a “Credit Monitoring Services Act,” which might as well be titled the “freecreditreport.com” act. It requires anyone who provides credit monitoring or obtains a credit report on behalf of a consumer for a fee to give clear and conspicuous notice of the consumer’s right to a free credit report.

The law itself is pretty standard, at least as much as anything with fifty-five versions can be called “standard.” It requires anyone with personal information about a Missouri resident to notify the resident of a breach of security, defines “personal data” as any of the usual suspects plus a name (although, as John Bambenek points out, a name isn’t actually needed to steal money from someone’s checking account with ACH), requires the notice to be made “without unreasonable delay,” and allows safe harbors for encryption and cases where the data handler determines identity fraud is not likely. Notification can be written, by phone, or with certain electronic notice. The law allows substitute notice if personal notice would cost over $100,000, if more than 50,000 people are affected, or if there isn’t enough contact information to contact people directly. A data handler who has to notify more than one thousand people also has to alert the media, the attorney general’s office, and the credit reporting agencies. Enforcement is by the attorney general, with a civil penalty of $50,000 per breach for willful violations.

Senator Feinstein’s national data breach notification bill hasn’t emerged from committee since she introduced it in January. It’s now a bit of a race to see which happens first: a nationwide breach notification bill, or the remaining states passing their own versions.

The new law repeals the previous encryption statute, and adds a new one to Nevada Revised Statutes section 603A. The previous law was criticized for not clearly defining “encryption;” the new law tries to fix that by defining encryption as something adopted by NIST or any other “established standards setting body”:

(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.

Although “adopted” is not necessarily the word I’d use to describe FIPS approval of encryption protocols, the Nevada legislators should get credit for paying some attention to key management.

Unfortunately, Nevada did not do so well when it decided to add a PCI DSS requirement to the law. Unlike Minnesota, which requires compliance with a specific narrow provision of PCI DSS, Nevada simply mandated compliance with the whole standard:

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 or its successor organization, with respect to those transactions, not later than the date for compliance set forth in the Payment Card Industry (PCI) Data Security Standard or by the PCI Security Standards Council or its successor organization.

In computer programming lingo, that’s PCI by reference, and it’s a huge delegation of power by the Nevada legislature to the PCI Standards Council. The PCI Standards Council is not elected, nor is it appointed by elected officials. Giving the force of law to anything the PCI Standards Council says raises constitutionality questions. At least the law said “with respect to those transactions,” so the PCI Standards Council only has the power to enact laws related to payment processing. If the Standards Council decides that all payment processors must pay the Standards Council $1 billion per year, that would only have the force of Nevada law if the payments are related to transactions. Maybe.

The other problem with the new law is that still applies to any “data collector doing business in” Nevada. It does not apply only to transactions through Nevada, or to transactions involving Nevada residents, but to anyone with business in Nevada. Suppose my business is located in Missouri, but sets up a booth at a Las Vegas trade show every year. Is that “doing business” in Nevada? Are my Missouri-only transactions now subject to the Nevada law?

Nevada’s law lacks the penalties prescribed in Minnesota’s law. The Minnesota law allows card issuers to recover the cost of replacing cards due to a data breach; Nevada’s law includes no such provision. Instead, the penalties for not complying with PCI DSS are the same as for a data breach: the breached entity can sue the data thief, and the attorney general can get an injunction against anyone violating the statute.

Even without that penalty, however, the official codification as a statutory requirement could make PCI DSS the basis of a negligence per se claim. When it applies, negligence per se allows a plaintiff to skip the whole “reasonable person” evaluation of a standard of care in a negligence suit by pointing to a statute. For example, a pedestrian hit by a driver running a red light could point to the statutes requiring people to obey traffic signals as showing that the driver was negligent per se. The statutory PCI DSS requirement might do the same thing for that standard: allow plaintiffs to say that PCI DSS itself establishes the standard of data security due care. In practice, however, it may not matter, because plaintiffs have had too much problem showing cause-in-fact and harm to ever reach the standard-of-care questions.

Even so, the PCI DSS requirement-by-reference is troubling, and a little sloppy. Legislating technology is hard: write something that’s too general, and it can become meaningless; write something that’s too specific, and you have to re-write the law every year. But that’s no excuse for giving up by pointing to a private standard and saying, “do that.”

LifeLock—infamous for its TV ads in which the founder puts his Social Security Number on the side of trucks—exploits an opportunity in fraud protection law. 15 U.S.C. § 1681c-1 allows “a consumer, or an individual acting on behalf of or as a personal representative of a consumer” to put a free ninety-day fraud alert on her credit file. This “initial” fraud alert requires the consumer to claim “a suspicion that [she] has been or is about to become a victim of fraud or related crime.” The law also allows for an “extended” alert, which lasts for seven years, but requires that the consumer have suffered actual fraud. What LifeLock does is place and renew initial fraud alerts every ninety days on behalf of customers, creating a sort of permanent initial fraud alert.

Experian doesn’t like that, partly because it has to expend resources processing all those repeating fraud alerts. So it sued LifeLock, claiming unfair competition, among a host of other complaints. The court agreed.

Its reasoning, in a nutshell, was this: the credit freeze law only allows fraud alerts to be placed by the consumer or an individual acting on her behalf. According to the legislative history of § 1681c-1, the word “individual” was specifically chosen over “person” so that individuals such as family members, attorneys, and guardians could place fraud alerts, but not companies (which are legally considered to be “people”). The court found that language to show a public policy against companies placing fraud alerts. Because the “unfair” business practices prohibited by California’s Unfair Competition Law include not only illegal practices, but also those contrary to public policy, the court found LifeLock’s placement of initial fraud alerts on behalf of individuals to be an unfair business practice, and thus illegal.

What’s interesting about this ruling—other than its implications for LifeLock—is that it reached its result without ever considering whether permanent initial fraud alerts themselves are contrary to the statute. It only says that organizations cannot place fraud alerts. But what about the practice of continually renewing an “initial” fraud alert so that it’s essentially permanent? The statute seems to contemplate specific remedies under specific situations: if you think you might be at risk of fraud, you get a ninety day alert that puts some restrictions on anyone who pulls your credit report. If you have been the victim of fraud, you get a seven-year alert with stricter restrictions. Arguably, if Congress had intended to allow for a permanent fraud alert, it would have provided for one. This ruling doesn’t address that issue.

This doesn’t seem to slam the door on all permanent initial fraud alerts. An individual consumer could always call all three credit reporting agencies every ninety days to place the fraud alert herself. She could also have an attorney, acting as her personal representative, do it for her. What this ruling says is that organizations can’t place fraud alerts: only individuals. It also effectively outlaws LifeLock’s business in California—or will, once the appeals are exhausted.

CardSystems was a payment processor that experienced a massive security breach in 2005. Intruders compromised tens of millions of credit card numbers, leading to millions of dollars in fraudulent charges. In the wake of the breach, banks canceled and re-issued thousands of credit cards. Mastercard and Visa terminated their contracts with CardSystems, and CardSystems eventually filed for bankruptcy. It was the first example of a data breach killing a major company.

Merrick Bank is an acquiring bank, which means that it contracts with merchants to handle their credit card sales. Merrick used CardSystems to process those payments. Because the card association operating agreements make acquiring banks reimburse losses created by card processors, Merrick paid about $16 million to the associations after the CardSystems breach.

But Merrick does not just blame CardSystems for the breach. It also blames Savvis, the IT consulting firm that certified CardSystems’s compliance with Visa’s Cardholder Information Security Program (CISP). In May 2008, Merrick sued Savvis for negligence and negligent misrepresentation in certifying CardSystems as CISP compliant. Last week, the federal district court in Missouri transferred the case to Arizona and joined it with some similar cases, which is why a year-old case is being reported as if it were new.

New or not, the lawsuit is another example of an unfortunate tendency to equate compliance with security. I blogged before about a PCI DSS trainer who said that no one who was PCI DSS compliant had ever been breached—implying, if not directly stating, that PCI DSS compliance creates perfect security. Unfortunately, that seems to be the official line: Robert Russo, Director of the Payment Card Industry Data Security Standards Council, said much the same thing in Congressional testimony in March (p. 8: “[No] entity that has been subject to a data breach . . . was also in full compliance with the PCI DSS at the time of the breach”). Calling something a magic cure-all is a sure sign of snake oil; the PCI Council would do well to stop selling PCI DSS as a magic elixir.

Security assessment malpractice suits could have a long-term effect on the way assessments are conducted. Version 1.1 of PCI DSS started allowing compensating controls that permit compliance even when some requirements are not met. An assessor that requires strict adherence to PCI DSS requirements, with no allowance for compensating controls, can always point to those requirements when faced with a negligence claim. But when an assessor certifies compliance using compensating controls, it exercises more independent judgment, creating room for a negligence claim. The result could be less use of compensating controls.

There could also be some positive effects. Compliance requirements without liability for assessors make it too tempting for both parties to rush through the process. Sloppy consultants will assess as quickly as possible then hop to the next paying assessment. Some clients, more interested in the certification than security, will shop for the lowest-priced certification they can find. Not all assessments are like that, but security certifications make them more likely. Malpractice liability gives the consultant something to think about other than how quickly he can get paid for calling someone secure. But even security consultants who do things right need to be careful about how they structure engagement contracts, because these lawsuits will probably become more common.

One lesson for security consultants, and especially PCI assessors, is to be careful with engagement contracts. Savvis is not being sued by a client, but by a customer of a client—someone with whom Savvis had no contractual relationship. A limitation of liability and disclaimer of warranty have no force against someone who is not a party to the contract. A consulting firm would therefore want an indemnification clause in its contract, which would require the client to protect the consultant against anyone else in a claim arising from the engagement. But indemnification clauses aren’t always possible, and the client probably wants the assessor to indemnify it.

Of course, the risks are lower if the negligence claims fail. Negligence cases against processors and merchants have not fared well overall; it would seem even harder to recover against an assessor who certified a breached organization. The assessor could always raise the “Richard Russo defense” by blaming the breached organization for post-assessment changes. The basic negligence case is also harder: the plaintiff would have to show not only that the breached organization was negligent, but that the assessor knew or should have known that the breached organization was non-compliant at the time of the assessment, and that certification of the organization rose to the level of negligence. Proximate cause is probably harder to show, because the causality chain is the breached organization’s chain plus whatever was wrong with the assessment. Apportionment of fault could also be an issue: how much fault lies with the assessor for certifying compliance, and how much lies with the company for being non-compliant? The answer would be fact-specific, but the issues suggest that a case against an assessor would not be an easy win.

Issues like these are probably why PCI DSS assessors must carry cyber-risk and privacy liability insurance (QSA Validation Requirements v.1.1a, p. 40). The more people think that certification is all there is to security, the more the firms who provide those certifications will have to deal with lawsuits like these.