A Bug in the System

Last week, a group of 75 security researchers, user-rights advocates, and software vendors, united in the goal of creating a more secure Internet, gathered at Berkeley Law School to kick off a new multi-stakeholder collaborative process that aims to bring together disparate points of view and try to reach consensus on difficult policy questions. The process explores the often tension-filled ways in which these groups interact today and how they can best work together. The group was convened by the Department of Commerce’s National Telecommunications and Information Administration (NTIA) as a part of a larger effort to convene multi-stakeholder processes to solve thorny policy questions in the cybersecurity and vulnerability space. I was there representing the Open Technology Institute.  

There is no question that these groups have some thorny issues to work through. Security researchers make their living finding and publicizing bugs in vendors’ software, often causing public relations issues and, some argue, harming users by publicizing vulnerabilities before companies have the chance to fix them. Vendors, on the other hand, are often seen as intransigent and overly litigious, preferring to sue researchers that come to them trying to help, and refusing to fix bugs (sometimes because of the cost of doing so, and sometimes simply because they would prefer to spend the time developing new features instead) that have serious security implications. Users are left with software that may or may not function, or possibly exposed to vulnerabilities that puts their entire system at risk. The reality in all of these cases is probably somewhere in between.

This disconnect is a problem, because the Internet needs researchers and vendors to work together - and do it so much better than they do now. Vendors have to understand that bugs happen and that not reacting to them can have serious consequences for the security of their users. Involving legal teams or even the Department of Justice when a researcher finds a vulnerability is not just counterproductive to achieving security for users, but in many cases causes permanent harm to the public’s perception of the company and their product. Vendors should look on most researchers as any other outside consultant with value to bring to the table, and focus on fixing bugs rather than resorting to lawsuits.

As one security researcher at the event noted, researchers have to bear in mind their own responsibilities too. In most cases, releasing information about a vulnerability to the public immediately does not give a vendor acting in good faith the time to develop and distribute a fix. That’s not a hard and fast rule – there may be situations where immediate disclosure is necessary – but it is a good guideline.

From here, the future of the process is a bit uncertain. While plenty of productive conversation happened last week, there is still a lot of work to be done to give the process some scope. While there was general sentiment that everyone could stand to work together better, there were definitely some present who were wary of the full group coming to any kind of consensus conclusion, for fear that it would be used against researchers. A number of break out groups will convene soon to chart out recommended directions and the full group will meet again within the next couple months. Stay tuned for more details!