If You Want Your AUP to Stick, Stick to Your AUP

Many have already written about Quon v. Arch Wireless Operating Company (opinion), the 9th Circuit decision finding a reasonable expectation of privacy in text messages. The results may be more fact-specific than some suggest, but it’s also a cautionary tale about acceptable-use policies (AUPs).

The city of Ontario, California has a typical AUP: it says that Internet access can be recorded and monitored, that such information isn’t confidential, that the systems shouldn’t be used for personal communication, and so forth. The city issued police officers two-way alphanumeric pagers, owned & operated by Arch Wireless. When an officer would go over his 25,000 character limit for the month, he’d pay for the overage. The lieutenant in charge of the pagers made it clear that an officer’s messages wouldn’t be audited as long as he paid for the extra messages. When that lieutenant got tired of being a “bill collector” for pager overages, the department audited message logs to find out how many messages were work-related (so that the message limit could be increased if there were a legitimate need). In that audit, the department found many personal—and sexually-explicit—messages.

Note the fact scenario here. It’s a police department, so the Fourth Amendment applies to the employer—which wouldn’t be the case for a private company. Arch Wireless was a third-party provider, so the case wasn’t about an internal e-mail system. And, critically, the court found that the department’s “operational reality” overrode its AUP. Because the department had a months-long practice of letting officers go over their message limits without auditing as long as they paid for the overages, the court held that the officers could reasonably expect that their text messages would be private even if the AUP said otherwise.

The lesson for employers is that operational practice can trump written policy. One solution is to draft AUPs that reflect reality, allowing “limited personal use” as long as that use doesn’t interfere with job functions and system performance. If that kind of wiggle room is unacceptable, then a company with an absolutist AUP needs to be sure that its policy is enforced absolutely.

Published in:  on June 19, 2008 at 9:55 pm Comments (3)

CMU Study: Breach Laws Don’t Reduce Identity Theft

According to a study out of Carnegie Mellon’s Heinz School, data breach laws have “no statistically significant effect” on reducing identity theft. The researchers performed a regression analysis using FTC identity theft data, factoring in income, strictness of the laws, and some interstate effects.

I have a couple of minor quibbles, but otherwise the results aren’t surprising.

First, the quibbles. Although the study considers some interstate commerce effects, I don’t think it accounted for them quite enough. Interstate commerce effects are those where one state’s data breach law affects identity theft rates in other states because of corporations with customers in multiple states.

For each state, the study tried to compensate for interstate effects by including variables for (1) the state’s level of interstate activity, (2) the number of that state’s neighbors with data breach notification laws, and (3) the percentage of all U.S. states with identity theft laws. What I think this still misses is the extent to which one large, populous state can force nationwide compliance. For example, consider what happened when California was the only state with a breach notification law. Companies who suffered a breach could choose to notify only their California customers, but if the breach were large, the publicity would still be nationwide—and customers in other states might wonder why the company didn’t tell them, too. Preventive measures don’t split along state lines as neatly. A company with weak security that wanted to avoid having to tell California customers about a data breach couldn’t improve only security for its California data; a security change would affect all its customers.

It’s therefore a matter of diminishing returns as more states pass data breach notification laws: when one large state has a notification law, it has a significant nationwide effect. Adding ten more states increases that effect, but not tenfold. By the time thirty-eight states have data breach notification laws (my count as of sometime early this year), one or two more won’t have that much more impact on nationwide compliance requirements. Any adjustment for the number of states with data breach laws should take this into account.

Another small criticism I have of the report is that it expects secondary effects to show up too quickly. Secondary effects of data breach notification laws are the incentives for companies to improve their data security practices. These process improvements take time to implement, and it wouldn’t be surprising to see a two or three year delay between passage of a data breach notification law and any sign of lowered identity theft.

The CMU report found that when (or whether) a state had passed a data breach law made little difference in the rates at which identity theft rates increased or declined. Overall identity theft rates increased at about the same rate in each category through 2005, and then, interestingly enough, declined at about the same rate in each category from 2005 to 2006:

Average ID theft rate, categorized by year of data breach notification law

This overall drop could reflect a delayed nationwide impact from California’s law, to which laws in additional states haven’t add as much as we might think.

Despite these complaints, I think the report’s ultimate findings are valid. Data breach notification laws probably don’t have a significant effect on identity theft rates, for a number of reasons:

  • Data breach events account for a small portion of identity thefts: 12% to 26%, depending on the study.
  • People may or many not receive notice of a breach, pay attention to it, or take action to avoid identity theft. Failure to do any of these reduces data breach laws’ effectiveness on the primary effects of a data breach.
  • Data handlers want to avoid data breach announcements, but they might think they’ll never have a breach, or they might accept the risk of a breach, or they might decide that the cost of improving security is higher than the expected cost of a breach. These reduce a data breach law’s effectiveness in creating secondary effects.
  • Consumers don’t have the ability to control how their data is handled. In a perfect market, we could choose to do business with companies that carefully handle data. But it’s not a perfect market, and a lot of our data is collected without our knowledge or consent, so we only have a limited ability to keep our data out of the hands of people who are sloppy with it, even when we know they’re sloppy.

Data breach laws are useful and necessary. If someone misplaces my data, they should have to tell me about it. But these laws alone aren’t enough to make companies handle data securely.

 


“Data breach laws have no effect on prevention, researchers say” [SearchSecurity.com]

Published in:  on June 12, 2008 at 3:46 am Leave a Comment

Why is Minnesota the Only State with a PCI DSS law?

When Minnesota passed its PCI DSS law last year1, one of the small questions was whether other states would follow suit. California’s data breach notification law (also known by its legislative bill number, SB 1386) spawned a parade of similar bills from other states, so it was fair to wonder whether Minnesota’s bill would have a similar effect.

So far, the answer is no, even though legislators in ten states have introduced bills: Alabama (2008 HB 816), California (AB 779), Illinois (HB 5311), Indiana (SB 206), Iowa (2007 HSB 721), Michigan (SB 1022), New Jersey (A2270), Texas (HB 3222), Washington (HB 2838), and Wisconsin (SB439).

California came closest. It overwhelmingly passed AB 779 by a 30-6 vote in the Senate and a unanimous vote in the Assembly. But Governor Schwarzenegger vetoed the bill. His veto letter said that the payment industry was in a better position to maintain the standards, and that if passed into law, the measure could end up conflicting with PCI DSS as the industry standard was revised.

Most states didn’t get so far. All the bills other than California’s died in committee or when the legislature adjourned. Some of them didn’t get past the initial committee referral.

What’s to blame for the lack of traction? Some of it is probably just a matter of packed legislative calendars. Lots of bills never see more than a committee referral, and it’s not necessarily because the bills are bad, just that the committees are busy. But still, there may be reasons why most of these bills haven’t been priorities. Retailers have opposed the laws, worrying that they would drive up compliance costs (for example, Governor Schwarzenegger vetoed the California bill after lobbying by the state’s Retailers Association and Chamber of Commerce). And even though credit unions want the laws, not all financial institutions agree. In hearings in Washington State, the Credit Union League testified in favor of a bill but the Bankers Association testified against it.

Also, compared to data breach notification laws, PCI DSS laws have less of a clear benefit to consumers (i.e., voters). These laws are aimed at reducing the burden on financial institutions, and usually don’t give consumers any explicit cause of action. Even if they did, consumer liability for fraudulent credit card purchases is already capped. The big win in PCI DSS laws is not for the consumer, it’s for financial institutions—many of whom are card issuers; thus their ambivalence.

Finally, as I mention in my note discussing Minnesota’s PCI law, it’s hard to draft good technology legislation. It has to be specific enough that it includes what it means to include (and should include), but not so specific that it has to be updated all the time.

A few states tried to avoid this problem by drafting bills that said credit card handlers had to “comply with payment card industry data security standards.” That approach would have been a major mistake, raising far too many questions. Are “payment card industry data security standards,” in lower case, the same as the Payment Card Industry Data Security Standards? Or is it supposed to be a more general phrase meaning whatever standards the payment card industry sets for data security? If it means the standard itself, that would give too much power to the body that drafts the standard. In theory, all members of the payment card brand associations have some say in how the security standards are built. Giving PCI DSS the force of statute would shift that balance, giving the PCI Standards Council virtual fiat power. And it would probably be an unconstitutional delegation of power, turning the Standards Council into a quasi-legislative, quasi-judicial body reporting to no one, but holding the power to set regulations and punish violators (through its determinations of compliance or non-compliance). Fortunately, two bills (in Washington State and Wisconsin) that started life this way were revised to remove that explicit reference, and the third (in Texas) died in committee.

With these problems, why did Minnesota’s bill become law? Maybe it zipped through before serious opposition could be mounted. Perhaps other states will fix the perceived flaws of these bills and start passing them. Alabama—one of the few remaining states without a data breach notification law—might be worth watching. Its PCI DSS “bill” was actually a provision in its data breach notification bill (which wasn’t enacted). It will be interesting to see if a PCI DSS provision, which hasn’t been able to stand on its own in any state other than Minnesota, can make it through as a part of a broader data breach notification law.

1 Technically, the law is based on a itty bitty part of PCI DSS, the requirement that prohibits storing full-track credit card data. A better name would be “anti-retention of payment card information bill,” but “PCI DSS” is a lot quicker to type and read.

Published in:  on June 8, 2008 at 5:49 pm Comments (1)