Public Comment from Casey Ellis, Bugcrowd re DRAFT BOD 20-01

Originally posted: https://github.com/cisagov/cyber.dhs.gov/issues/139

January 23, 2020

Mr. Christopher C. Krebs
Director
Cybersecurity and Infrastructure Security Agency
Department of Homeland Security Stop 0380
245 Murray Lane
Washington, D.C. 20528

Dear Director Krebs and CISA/DHS team,

Thank you for the opportunity to comment on this Binding Operational Directive.

To start out: The Bugcrowd team, the security researcher community, and I personally applaud this effort.

The information systems that run the US Government are the output of human creativity and human effort. Humans, while unmatched in our creativity and ability to pursue potential, are also fallible, which gives rise to vulnerabilities and risks. This is merely a byproduct of being human. This truism begs the question of how to identify these risks, fix them, and reduce their likelihood in the future, before the adversary finds and exploits them.

Those who have both the skills and altruistic interest to identify cyber risk and improve the safety and security of the Internet have been waiting patiently for the better part of 30 years, and our efforts to help have been met with varying responses. Up until 5 or 6 years years ago many of them were fearful, hostile, and negative. The evolution of the information attack surface and the capabilities of our adversaries have caused a huge shift: The Internet realised that all “hackers” aren’t burglars, many of them are actually locksmiths.

Put simply, there is a crowd of people building software and systems, and a crowd of people working to find new ways to attack our software and systems, and this BOD proposes what we believe to be a logical response: Engaging the crowd of good-faith hackers and concerned Netizens to help the government defend it’s information systems.

For context: I founded the company Bugcrowd, the first organization to operationalize and intermediate the relationship between the hacker community and organizations wanting their input, in 2012.

Collectively, we have been a participant in the “helpful hacker” community, an advocate for healthy security feedback loops between system owners and their users, and a leader and moderator in vulnerability disclosure policy conversations for thousands of organisations, ranging from

small startups to massive technology platforms,
government agencies both in the USA and abroad (including the US Department of Defense), though to
traditional and safety critical organizations like automotive manufacturers, medical manufacturers, and financial exchanges.
The recommendations below come from our experience across this diverse variety of organizations, which we believe reflects the diversity of different agencies who would be participants to BOD 20-01.

In general we find the recommendations to be thoughtful and well laid out, and are greatly encouraged by the apparent groundswell of support from the researcher and information security community.

Consumer understanding of cybersecurity threats is a relatively new phenomenon, and has resulted in increased desire for transparency of the measures being taken to protect consumer data and the digital workflows that impact – at this point – almost every conceivable aspect of life.

This BOD addresses Government systems, not all of which interact with “consumer” information directly. The now ubiquitous awareness of the risk of cyberattack by the average citizen makes it a socio-political issue, as it directly impacts the confidence of the constituent in their government.

The transparency and conceptual simplicity of “Neighbourhood watch for the Internet” is a natural fit to the overlaid issue of constituent confidence, but our experience sharply reinforces that the journey to maturity in a vulnerability disclosure program is not one-size-fits-all. A measured approach is important to ensure smooth implementation and successful outcomes.

As such, our recommendations carry a focus on maximizing whole-of-program success with consideration to individual agency needs in the implementation of BOD 20-01.

Recommendations:

Prioritize the enablement of per-agency roadmap development.

• While accountability through milestone completion is essential, the “crawl, walk, run” implementation will vary dramatically across the different agencies.
• Contributing factors include operating constraints, risk and threat models, asset distributions (geographically, age and supportability, and technology-wise), and capacities for timely remediation.
• Clearly acknowledging these variations and their impact on implementation for different agencies will help drive collaboration and serve the overall mission of the BOD.

Set a clear expectation that restrictive scope is unlikely to be followed by Finders, and that scope control isn’t the purpose of an organizational Vulnerability Disclosure Program.

• In practice, Vulnerability Disclosure Programs attract and receive input for the organization running the program, as opposed to the specific targets which might be in a scope.
• Instead of focusing on what is in-scope, ensure agencies are considering the things that should be expressly considered to be Out-of-scope.

The typical approach taken to ensure readiness is either:

• Crawl, walk, run – Where private crowdsourced testing of the risk posture and remediation capability of the organization is tested ahead of a public policy and intake channel being opened up; and or
• Quiet, louder, loudest – Where the public policy and intake channels are introduced without promotion or prominence, and are progressively exposed to the public over time.

Extend the timeline to a fully public vulnerability disclosure program.

• 180 days for the publication of a disclosure policy for every agency is fairly aggressive.

The timelines and pathway to a fully functioning, easy to find and engage program will vary between
Departments, but the pathway could look like the following:

• Enabling the [email protected] intake pathway and adding a security.txt policy, alongside a private crowdsourced program to proactively assess the risk posture and remediation capacity of the organization; followed by
• Adding a web intake form with the VDP policy on an agency.gov/security page; then optionally
• Partnering with a disclosure coordination provider to actively promote the program to the community.
• The current 180 days would be sufficient to engage risk and remediation maturity assessment, and to have either published a public policy or to respond to the DHS with an alternate rollout plan to be completed within the following 180 days.

Treat CERT/CC or other centralized points of intake as the exception process, not the primary process.

• It’s our belief that the global announcement of a centralized point of intake for every government agency within 180 days is infeasible.
• This recommendation avoids premature overload of remediation pipelines within agencies from the influx of vulnerability reports triggered by announcing an “all of government” disclosure program, and the resulting misalignment of expectations on remediation and disclosure timelines/protocols between the agency, CISA, and the hacker community.
• Similarly, this recommendation avoids overload on the intermediary agency or service. CERT/CC, MITRE, and other CERTs around the world have all experienced a sharp increase in processing load since the popularization of VDP and bug bounty, and this load is best addressed on a distributed basis.

Double down on the encouragement of “good-faith authorization” (aka Safe Harbor).

• The existing anti-hacking laws, at both Federal and State levels, have traditionally operated on a presumption of malicious intent if unauthorized access is attempted or gained.
• While actual prosecution against good-faith security research has declined, deliberate efforts to align the intent of programs like BOD 20-01 within and throughout the participant organizations, as well as deliberate signalling of this intent to the security community, continue to be of critical importance.
• The “Authorization” language in https://cyber.dhs.gov/bod/20-01/vdp-template/ accurately reflects this precondition. Efforts to standardize, simplify, and promote both the importance and acceptance authorization and Safe Harbor language can be found at https://disclose.io if additional language to address DMCA, State laws, Terms of Service, or other considerations are required.

Continue to clearly disambiguate “vulnerability disclosure” from “bug bounty” and “private crowdsourced security”.

• The language of the draft distinguishing between vulnerability disclosure programs and bug bounties is important and will need to be repeated early and often.
• The popularity of bug bounty programs and resultant market confusion around terminology
• This disambiguation is critical, as it avoids the view of VDP as a non-starter by agencies that conflate the concept with bug bounty programs, as well as hasty adoption by those who’ve conflated the concept with private crowdsourced security.
• This also clarifies that a chief goal of a VDP is communication, transparency, and confidence.

Disambiguate researcher, contractor, etc to “Finder” where possible.

• In a recent well publicised vulnerability, a 16 year-old gamer accidentally stumbled upon a privacy vulnerability in a phone system, which was then reported to the vendor by his mother who self-identified as “non-technical”.
• The existing market nomenclature for a “finder” is diverse and confusing, and each variant of the term carries a different loading and invokes a different emotion.
• Removing the persona of the finder from the directive and focusing attention on the conversation, the information, and the resulting actions will disambiguate the mission goals and the steps needed to get there.

We’d like to reiterate on behalf of the security community our appreciation and commendation of this effort from CISA. This effort legitimizes the security researcher community, encourages transparency and pragmatism around vulnerability management within government agencies, and will ultimately result in more secure US Government information systems.

We stand ready to provide additional input and help as required to support this initiative.

Kind regards,

Casey Ellis – Founder, Chairman, and CTO, Bugcrowd

With input from…
Judy Dorner – Special Projects Office, Bugcrowd
Michael Skelton – Global Head of Security Operations, Bugcrowd
Randy Young – Principal Product Manager, Bugcrowd