Published on JD Supra on February 15, 2018
In October 2016, Uber discovered that the personal contact information of some 57 million Uber customers and drivers, as well as the driver’s license numbers of over 600,000 United States Uber drivers had been hacked. Uber, like many companies, leveraged a vulnerability disclosure or “bug bounty” program that invited hackers to test Uber’s systems for certain vulnerabilities, and offered financial rewards for qualifying vulnerabilities. In fact, Uber has paid out over $1,000,000 pursuant to its program, which is administered through HackerOne, a third-party vendor. Uber initially identified the breach as an authorized vulnerability disclosure, paid the hackers $100,000, and the hackers deleted the records. Yet, Uber has faced lawsuits, governmental inquiry and much public criticism in connection with this payment.
What did Uber do wrong and how can organizations ensure that their programs are not subject to the same risks? To answer this question, one must first understand why and how companies create bug bounty programs.
Many companies feel it is far better to pay money upfront to identify vulnerabilities before those vulnerabilities turn into public relations and regulatory nightmares that not only drain manpower and financial resources, but also may result in litigation and increased governmental oversight. In addition, advance knowledge of a vulnerability allows a company to develop the right solution for the problem, rather than reacting hastily in the pressure-filled post-breach environment. A properly structured bug bounty program also can be a great way to test the viability of a new concept, product or platform. It should be noted that the payments made pursuant to bug bounty programs are rewards and NOT ransoms. The difference is the collaboration and structure of permission-based interactions.
Hackers may be motivated for a number of reasons, including financial gain, intellectual challenge and the personal prestige to be gained from discoveries. Most of all, by participating in a sanctioned bug bounty program, hackers are able to do what they love without fear of legal repercussion. The Computer Fraud and Abuse Act prohibits the unauthorized entry into a “protected computer” for purposes of obtaining information from it. Put simply, any individual who hacks a system could be criminally prosecuted. However, when a company sanctions and even invites the activity, as is the case with a bug bounty program, a hacker can be reasonably certain that it will not be prosecuted, provided that it complies with the program’s requirements.
Having made the decision to launch a bug bounty program, a company must then decide whether to create an ad hoc program, or to engage a third-party service provider to run the program. Going it alone requires a dedicated team of employees that not only understand the bug bounty program and the technology or functionality being tested, but also are qualified to evaluate any discovered vulnerabilities and issue resulting compensation. Alternatively, outsourcing can provide some comfort, not to mention the expertise of a vendor who can scale the program as needed. Essentially, the vendor acts as an intermediary to help the client formulate goals for its use of the program, communicate with hackers, evaluate the identified vulnerabilities and administer payment of the bounties. Bug bounty vendors offer a measure of safety to all parties, not just in terms of bug bounty program reliability, but also in ensuring increased accuracy and quality of the hackers.
In June 2017, the Department of Justice’s Criminal Division Cybersecurity Unit (the “CU”) provided written guidance for companies seeking to implement a vulnerability disclosure program. Presented as more of a list of considerations, as opposed to a list of requirements, the CU specifically recognizes that each company’s program must be driven by its unique business purposes and needs. Nevertheless, the CU suggests that a good program will be:
Once a bug bounty program is created and publicized, a company must hold itself to as strict a compliance standard as it applies to its hacker participants. What challenged Uber was that it paid a drastically larger amount (ten times the highest advertised reward amount pursuant to the program) for just one breach, thereby circumventing its own publicized and authorized program. Not only did the amount exceed the limits of its stated program, but Uber negotiated with the hacker, which appeared as extortion-like behavior. In addition, officials at Uber were aware that this situation unfolded differently than the typical bug bounty interaction. Rather than notify Uber of the potential vulnerability, the hacker downloaded the sensitive information, then contacted Uber to request payment. At that point, Uber should have notified law enforcement. Not only did Uber fail to contact authorities, it waited more than a year to notify the public or authorities about the breach.
Whether a company runs its own program or enlists the aid of a service such as HackerOne, it would be well-advised to ensure compliance with the terms of the program. Furthermore, it must make certain that all relevant business and legal leaders at the organization are aware of the identified vulnerability, particularly if it is a significant one or involves sensitive information. Only by involving all stakeholders in the discussion can the organization ensure that its program does not run afoul of relevant legal and other guidelines and requirements.