Image via Wikipedia
In an interview with GovInfoSecurity, Sen. Thomas Carper said that the U.S. Senate is considering attaching cybersecurity legislation to a defense authorizations bill. Though clearly a ploy to be able to say "we did something about those evil hackers" before the elections, CAUCE applauds the attempt. There can be no doubt that the United States (and many other countries) sorely needs better laws to deal with these threats.
Further, Senate Majority Leader Harry Reid has asked that the cybersecurity bills currently in front of various committees be combined into one single, omnibus bill, which would presumably then be attached to the defense authorizations bill. Here's where we start to get worried.
Each of the bills we've seen (and we surely haven't seen them all yet) have some good points, and some…let's just call them unintended consequences. In every case it's obvious that the authors' intentions were good, but they needed some expert advice from people who understand the technical and legal realities of the internet today.
One such expert, a long-time CAUCE supporter who asked to remain anonymous, shares his review of one of those bills: S. 3742, the "Data Security and Breach Notification Act of 2010." You can read the original and check its current status here.
Please note that this is not legal advice. Our expert is not a lawyer, I'm not a lawyer, and CAUCE did not consult with any lawyers before publishing this article.
Our expert says it's going to be difficult to construct a single good omnibus cybersecurity bill. The bigger and more complicated it gets, the less likely it is that anyone will actually read the bill before voting on it — particularly when they're in a hurry to go home and win an election.
He highlights a few specific items which could be troublesome for just about anyone running a mail server, a web site, or other online services which collect or transit any information:
- Page 2, Section 2 (a)(2)(A): More or less everyone's going to need to have personally identifiable information (PII) security policies
- Page 3, Section 2 (a)(2)(B): … and an information security officer
- Page 3, Section 2 (a)(2)(C): … and a process for monitoring for PII breaches
- Page 3, Section 2 (a)(2)(D): … and a process for mitigating PII vulnerabilities
- Page 3, Section 2 (a)(2)(E): … and a process for securely deleting electronic records containing PII
- Page 4, Section 2 (a)(2)(F): … and a process for securely destroying paper and other non-electronic records containing PII
- Page 4, Section 2 (b): If you're an "information broker" (which would include nearly anyone who collects information and shares it with anyone else), you have additional obligations, including needing to submit policies to the FTC, needing to provide consumer access to information, tracking access to information maintained by the broker, etc.
- Page 13, Section 3 (a)(1): Requires notification solely to US citizens and residents in the event of a breach. Of course, that presumes you know the nationality/immigration status of those whose PII data you hold (hmm, I don't think *anyone* I know does, except for HR departments with regard to their own employees). If I were a covered entity, I'd be strongly inclined to begin soliciting that information from everyone I get PII data from, although of course that may trigger a whole different set of issues, particularly in areas where immigration related issues are a hot button topic.
- Page 14, Section 3 (b)(2): Notification by a service provider triggers reporting requirements. This is going to make LOTS of friends for service providers, given the affirmative notification and credit protection obligations that customers accrue after being notified.
- Page 19, Section 3 (d)(2)(A): Alternative notification is available for incidents involving LESS than 1,000 individuals. This is goofy.
Normally alternative notification is allowed as an option when the number of covered individuals is very LARGE not very small. For example, some state laws permit alternative notification in cases where costs of providing notice would exceed a quarter million dollars, the affected class of consumers to be notified exceeds 350,000, or the notifying party doesn't have sufficient contact information to provide notice.
There's language on page 22 of the draft bill that may allow regulatory additions to expand when substitute notification is permissible, but the basics for when substitute notification should be permissible should be part of the core statute, not an after-the-fact, maybe-yes, maybe-no regulatory add on by the agency. - Page 25, Section 3 (d)(2)(B): imposes compliance burdens on entities for a year before technical compliance guidance is available. Enforcement of the act should be held until the guidance envisioned by 3(d)(2)(B) is available, and realistically it will take probably an additional period after that for sites to deploy the recommended technology (new projects don't happen over night).
- Page 26, Section 3 (h): Potentially requires notification in polyglot languages. This can be a huge administrative PITA — consider the "simple" case of the EU, where there are "only" 23 official languages (Bulgarian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Irish, Italian, Latvian, Lithuanian, Maltese, Polish, Portugese, Romanian, Slovak, Slovene, Spanish and Swedish, plus (semi-official) Catalan, Galician, and Basque).
This section could be potentially exceptionally burdensome if the FCC suddenly mandates that sites provide notification in multiple foreign languages (I could see an argument for requiring Spanish as well as English, but there are some communities in the United States where other languages are also very common). - Page 28, Section 4 (b)(1): It seems unnecessarially combative to define all data security incidents as "unfair or deceptive acts or practices." Data security incidents are not typically something which a covered entity intentionally does, neither are such breaches typically "unfair" or "deceptive" in the same way that some TV or Internet huckster's "miracle" product or pyramid sales scheme might be.
The most persuasive argument in the other direction is probably that currently most states already have their own PII breach notification laws, and it can be a pain to try to stay in compliance with 46 different PII information security and breach notification statutes. So again, the intention is clearly good, but in practice…it needs some careful review.
So there are the results from one bill, examined by one expert. He's one of the best minds in the cybersecurity community, yet he may still have missed something. With legislation as important as this, smushing it all together and rushing to attach it to something unrelated is simply a bad idea. This is a topic which requires careful thought, from multiple people who really do know what they're doing — and who can explain it to the Congressional staffers who will write the resulting bill, and then to the Senators and Representatives who will collectively make the decision.
Once that education has occurred, it should quickly become evident that while some of these bills do overlap, others do not. Some will disagree. Some simply contain bad ideas. All of this has to be worked out. Then, finally, it might make sense to combine them — not now, and not just because they all have the prefix "cyber" in the title somewhere.
