Improving Vulnerability Disclosure Together (Officially)

Author: Bryan Ware, Assistant Director 

Imagine walking your neighborhood in the cool dawn and noticing a home at the end of the block engulfed in flames. You look around. No one else appears to have noticed yet. What do you do? You’ll likely call 911, share the address of the burning home, and stick around to help if needed. 

Now, imagine visiting a government web application – say, website.gov – on a balmy evening and noticing an open redirect on the site. You click around. Nothing on the site hints at how to report this. What do you do? If you’re into cybersecurity, you might send a short email to security@website.gov, pulse some contacts when it bounces, and tweet something spicy about website.gov. 

It doesn’t have to be this way. 

An open redirect – which can be used to give off-site malicious content the appearance of legitimacy – may not be on par with a fire, yet serious vulnerabilities in internet systems cause real-world, negative impacts every day. In many instances, a trained eye can spot critical deficiencies and yet have no one to report it to. It shouldn’t be hard to tell the government of potential cybersecurity issues — but it will be unless we’re intentional about making it easier. 

A Comment on Comments 

Last November, we asked for feedback on a draft binding operational directive, BOD 20-01, which would require most executive branch agencies to create a vulnerability disclosure policy, or VDP. A VDP tells those who find flaws in an agency’s digital infrastructure where to send a report, what types of testing are authorized for which systems, and what communication to expect in response. 

We’d never done a public comment round on a directive before, but since the subject matter was “coordination with the public,” this one merited it. And even though the comment round spanned every holiday from late November to early January, the quantity and quality of feedback was nothing less than stellar. We received over 200 recommendations from more than 40 unique sources: individual security researchers, academics, federal agencies, technology companies, civil society, and even members of Congress. Each one made the directive draft, its implementation guidance, and our VDP template better.

How so? 

• Severalsubmissions asked whether the mobile apps that agencies offer to the public would be in scope of agency VDPs. That was something we hadn’t considered before – and concur with. 
• A few comments suggested small ways of thinking about the problems that would remove ambiguity around scope (it includes vulnerabilities and misconfigurations), reporting requirements (they stop when everything’s in scope), and how to respond to anonymous vulnerability reports (you don’t; they’re anonymous).
• Anumberofcomments discussed our use of “target timelines,” concerned that the directive not mandate specific deadlines for remediation. Fixing a vulnerability is not always push-button, and requiring deadlines might create perverse incentives where a lower severity-but-older vulnerability takes organizational precedence over newer-but-more-critical bugs. Deadlines might also cause rushed fixes. The final directive makes clear that the goal of setting target timelines in vulnerability disclosure handling procedures is to help organizations set and track performance metrics; they are not mandatory remediation dates. (We say a lot more about this in our implementation guidance.)
• Many comments helped us vastly expand and enhance the implementation guidance, particularly the FAQs. We intend our guidance to be living, and we’ll update the FAQs as questions come. 

Even though not all suggestions led to a direct change, every comment helped us think more deeply about vulnerability coordination in the federal enterprise. Our sincere thanks. 

I’m proud to announce CISA is issuing the final version of BOD 20-01, which is issued in support of the Office of Management and Budget M-20-32, “Improving Vulnerability Identification, Management, and Remediation”. Here’s a comparison of everything that changed between the draft and final set of documents. 

Putting the Pieces Together 

VDPs are a good security practice and have quickly become industry-standard. Even ingovernment, others have harnessed the benefits of working with security researchers before. More recently, we released guidance to election administrators for setting up their own VDPs (something that community is starting to do). At CISA, we believe that better security of government computer systems can only be realized when the people are given the opportunity to help. 

BOD 20-01 is part of CISA’s renewed commitment to making vulnerability disclosure to the civilian executive branch as easy conceptually as dialing 911. That concept hinges on an understanding that 911 is distributed, and the center your call is routed to is dependent on physical geography. We’re aiming similarly: 

• Under BOD 20-01, agencies take action to make reaching them easy. This includes adding a security contact in the .gov registrar, posting their VDP publicly (which may include a web form to receive vulnerability reports), and adding security.txt to their primary .gov website (and others, as desired). Each of these actions is agency-centric, like their own local version of 911. 
• If reporting to agencies directly fails, CISA can help. We don’t manage agency systems or services (by law, they do), but we’ll be a backstop. (CISA does help security researchers coordinate previously unknown vulnerabilities in products – and if agencies receive these reports in the first instance, we can help there, too.) 

To centralize part of this effort, CISA will offer a vulnerability disclosure platform service next spring. We expect this will ease operations at agencies, diminish their reporting burden under this directive, and enhance discoverability for vulnerability reporters. 

We the People 

This directive is different from others we’ve issued, which have tended to be more technical – technological – in nature. At its core, BOD 20-01 is about people and how they work together. That might seem like odd fodder for a cybersecurity directive, but it’s not. Cybersecurity is really more about people than it is about computers, and understanding the human element is key.  

A final note to those people who find and report vulnerabilities: we see your work, we want to help, and we appreciate you. To others that would use these new ways to reach agencies, please: this is not a business development opportunity, and pitches to security@agency.gov aren’t going to be appreciated. Don’t @cisagov on your spicy tweets.