Published by The Lawfare Institute
in Cooperation With
Lawfare and others have spent an enormous amount of time discussing the intricacies of the Vulnerabilities Equities Process (VEP). Many policy conferences have been dedicated to the matter, and an even greater number of Twitter debates. The topic, in its own way, serves as a proxy for what one thinks of broader issues in information security and signals intelligence.
Today’s so-called WannaCry ransomware attack reveals the stakes, but more importantly the limits, of that debate.
Our bottom line up front is that, VEP or no VEP, today’s ransomware attack highlights the risks of relying on software that is no longer supported by its developer (like Windows XP) and of not applying patches that the developer makes available (like MS17-010). Even a perfectly functioning VEP would not make much difference unless the developer addressed the vulnerability, and businesses and institutions applied the relevant patch. These are the two issues—more than a government process that feeds them—that make or break organizations in the wake of today’s attack.
The Existing Debate
The VEP is the mechanism through which the United States government decides which of the software vulnerabilities it discovers it will turn over to vendors for patching, and which it will use in its own hacking efforts to gather signals intelligence. In its post-Snowden review, the newly commissioned Review Group on Intelligence and Communications Technologies expressed concern about the number and quality of exploits the United States was retaining for its hacking operations, which appears to have led to the reinvigoration of the then-dormant VEP. The process attracted a great deal of attention after the 2014 revelation of the Heartbleed vulnerability, which affected a large number of servers running critical encryption software. In that instance, the United States government denied that it knew of and was exploiting the vulnerability and laid out some criteria for how it made its decisions through the VEP.
How Today’s Attack Must Shift This Debate
Today’s ransomware attack, which so far has affected tens of thousands computers in 70+ countries, shows the stakes of the software exploit issue. The worm, known as WannaCry, appears to spread through a vulnerability in a network protocol called Server Message Block in Microsoft Windows. The ransomware part of the malicious code encrypts the targets’ files, locking out users from accessing these files until a ransom is paid. The infections have been worldwide, but the most notable effects have been felt by the UK’s National Health Service, whose critical services have been disrupted.
The key to today’s attack was the malware’s propagation through SMB, not the sophistication of the initial infection or the ransomware itself. Nicole Perlroth of the New York Times has a good write-up of the sequence of events of how this vulnerability became public. In April, a shadowy group known as the Shadow Brokers released what it alleged was a series of hacking tools stolen from the NSA, including this SMB vulnerability, known as EternalBlue. This release of very sensitive tools caused a great deal of consternation and worry, until it was discovered that Microsoft had patched the vulnerabilities that these tools exploited the previous month. Included in that March security update was a patch to protect against the propagation of today’s WannaCry ransomware.
Today’s attacks thus serve as critical proof of the stakes and the limits of the VEP. The rampant infections, including in critical systems, shows just how dangerous exploits can be, not just to computer systems but also to human life. Those are the stakes. Let’s assume for a minute that after the NSA suffered its breach, the U.S. government tipped off Microsoft about the potential risks of these vulnerabilities becoming public. The subsequent issuance of the MS17-010 patch would then serve as a testament to the value of the VEP, or something like it (though some advocates would argue that the vulnerability should have been disclosed and never used by the NSA). That is, the government became aware of a serious danger—an adversarial actor in possession of unpatched exploits—and so it warned the relevant vendor, who issued a patch. The problem is that so many operators failed to apply that patch—possibly for reasons out of their control—and found themselves in the line of fire. Those are the limits of the VEP. If patches are not developed and deployed, the VEP becomes toothless.
Will the Trump Cyber Executive Order Help in the Future?
It is worth noting that yesterday (May 11), the Trump Administration released its long-awaited cybersecurity executive order. Here’s the question: will the implementation of that EO keep us safe from incidents like this in the future? Our answer: maybe. The EO covers federal government systems, critical infrastructure, and so forth. The federal government has the most control over its own systems—it doesn’t need an EO to upgrade legacy systems still using Windows XP or to ensure rapid patch application. What it does need is money. Just a few weeks ago Congressman William Hurd (R-Tex.) re-introduced legislation that would make the federal government a lot better off in this regard.
But it’s in the area of critical infrastructure or systems directly affecting lives where we should be most concerned. Similar to the machines in UK hospitals affected by today’s attack, the risk is that the computers that run so many services on which we all depend are vulnerable—either because they are running unsupported software, or the supported software has not yet been patched. The question for the Trump Administration, and specifically for DHS’s Industrial Control System team, should be just how much can they do to help private companies that operate critical infrastructure to mitigate these specific risks.
What does today’s attack mean for the VEP debate? To some extent that debate should continue. There are legitimate equities in play that need to be balanced. But we should suffer no illusion. After all, we live in a world in which 42 of the 48 National Health Service trusts that responded to a 2016 Freedom of Information request are still running unsupported Windows XP. Debate alone will not help. If fundamental security tasks like patching do not get done, nothing else matters.