When I was sixteen, the rule was that I could not drive a car until I knew how to change a tire. My dad always reminded me that it is dangerous just to drive, but not knowing how you plan to fix a flat could cause you a lot of unnecessary stress. Uber Technologies, the popular transportation app, is currently learning that while driving on the information super highway, companies should likewise know how they plan to address a data breach.
Uber disclosed on Friday, February 27, 2015 that it suffered a data breach nine months earlier on May 13, 2014 affecting approximately 50,000 of its current and former drivers. Many are criticizing Uber because although it discovered the breach on September 17, 2014, Uber waited 163 days to inform drivers whose identities and personal information are at risk. In other words, over five months passed before any of these drivers learned that their names and drivers licenses may be available to identity thieves.
Uber published a press release admitting that late last year it identified a “one time access” of its database by an unknown third party. “Immediately upon discovery we changed the access protocols for the database, removing the possibility of unauthorized access,” said Uber’s managing counsel of data privacy, Katherine Tassi. Uber explained that it has a plan to resolve this breach: Uber “filed what is referred to as a ‘John Doe’ lawsuit so that [it is] able to gather information that may lead to confirmation of the identity of the third party.” The press release added “we are notifying impacted drivers, but we have not received any reports of actual misuse of information as a result of this incident.”
But Uber’s press release and notification leave open two very curious questions: how did Uber discover the breach, and why did it wait so long to notify those affected? Sasha Antman, an Uber driver in Portland, Oregon, filed a class action suit in federal court, claiming that Uber did not do enough to prevent the 2014 breach, and waited too long to disclose it. The complaint alleges that the security key used by the hacker to perpetrate the data breach was actually publicly available on the internet via one or more GitHub webpages (GitHub, an app designed for sharing code among app developers, has been criticized in the past because some users are lax in securing the data and information stored on the website). The lawsuit alleges that “the private information was maintained in unencrypted form, and that the Hacker was able to access it freely with a basic password.” To put it simply: Uber “not only permitted all of the compromised private information to be accessible via a single password, but allowed that password to be publicly accessible via the Internet.” The complaint also alleges that the delay in notification made drivers more susceptible to identity theft.
The Uber data breach offers all of us an opportunity to review some basic rules of the road for anticipating and responding to a data breach.
1. Plan for WHEN a Data Breach Occurs, Not IF a Data Breach Occurs.
2. Anticipate Potential Information Security Deficiencies.
The data security process never ends; instead, the process evolves constantly to meet emerging threats as hackers grow more sophisticated. With adequate planning you can aim to prevent many threats and mitigate the harm from others. Take a look at GitHub. Code sharing services like GitHub are popular because they enable software developers to efficiently collaborate on large projects, make changes to coding, and maintain a history of all modifications made to coding over the life of a given project. Unfortunately, developers using these services are not always careful about the information they store on the Internet. An attacker familiar with the site may be able to find files containing private security keys, login credentials, and other data stored on the Internet along with the source code. Attackers armed with this information can access enterprise systems and data, which seems to be the case with Uber. Hindsight is always 20/20, but taking the time to do your homework on the methods by which data is stored and used can save you from a major privacy headache down the road. Make a point to be vigilant about the possible deficiencies in your data storage processes and explore ways to make those processes even more secure. Since Uber has not disclosed any details on the breach, we do not know the extent to which Uber’s information on GitHub could be responsible. But at the very least, Uber’s use of GitHub has alarmed many data privacy advocates, making Uber the target of much public criticism.
3. Have a Plan in Place for How to Disclose a Data Breach.
Although there is no national data breach notification law, many state laws require organizations to notify data breach victims “in the most expedient time possible and without unreasonable delay” after discovering a breach. Companies should recognize that this vague timeframe is not a license to drag your feet on disclosure. At the same time, companies do not want to jump the gun and disclose immediately before taking the time to educate itself on all the facts concerning the breach, the kind of information accessed, and the plan to remedy the effects of the breach. No two data breaches are the same, and appropriate actions to disclose the breach will vary. Companies should keep an eye on the calendar and recognize that the longer it takes to notify, the more criticism they might receive. Have a plan in place on how you will study the origins of the breach, the effects of the breach, and the best way to remedy those effects. Consult with counsel on how to best comply with state law, and consider the consequences of disclosing too early or too late: the public will best remember your first response to a breach, so put yourself in a position to be authoritative, responsible, and accurate.
Data breaches can happen to anyone. But with appropriate planning and anticipation, you can avoid many of the headaches that are currently ailing Uber. Just like my dad would not let me drive without knowing how to change a tire, companies should not allow themselves to handle data without knowing how they will respond to a breach.