Intro
As early as the 1980s, movies like WarGames first popularized a now commonplace idea: poking around networked computer systems without permission, even with the best of intentions, is not a game. It is a crime! Matthew Broderick famously connects to a server that asks: “Shall we play a game?” He soon discovers that he’s interacting with a military supercomputer used for war games, and the FBI detains him when he almost starts a war. This perception of hackers as criminals, even the most innocent and naive of them, has prevailed.
Ironically, Hunter & Ready started perhaps the first documented bug bounty, for the VRTX (Versatile Real Time Executive) operating system, at the same time. Their offer of a VW Bug as a bounty (“Get a bug if you find a bug”), while compelling, did not have the same cultural impact as WarGames. Their invitation to ethical hackers to find a bug in the new VRTX OS, and, instead of exploiting it, bring it to the attention of the product developers, kicked off a new, crowdsourced approach to security management. Even if it took decades for security research to overcome the stereotype of the criminalized hacker in a hoodie, bug identification is now a big, legitimate industry. Recognizing this shift, many industry practitioners insist on welcoming security researchers, not benching them.
The federal government is now following suit, especially after the success of industry engagement with the U.S. military in Hack the Pentagon in 2016. The government’s new and improved cybersecurity agency, CISA, published its first binding directive of 2020, BOD-20-01, mandating federal agencies to establish a core prerequisite for security researchers to collaborate with hackers: a vulnerability disclosure policy (VDP). For most, that is a radical shift in how they approach security and who they trust. How does a federal agency get started? Let’s look at some winning techniques for your game.
Get buy-in from stakeholders and your legal team
This step is the most important, the most taxing, and will likely take the longest. For conventional stakeholders in an agency of any size, a public disclosure program means accepting substantial risk. The good news is that, with this directive in hand, it is far easier for a federal agency to justify that risk. It is vital agency management work with their legal team to understand the policy, vet it, and endorse it while you address the varied perspectives and needs of your stakeholders. Advocacy is key here, but you can arm yourself with examples of success. You can cite published bug bounty findings (more on that later) for other agencies and their impact, and highlight the bottom line: if you do not establish a VDP despite the mandate, you will never know about these vulnerabilities first-hand. There will always be surprises and you will struggle to catch up.
Use templates and existing VDPs
Every agency will have unique context, requirements, and stakeholders, but BOD-20-01 provides a reference policy template and other supporting materials. You need a winning game plan, and CISA gave your agency a strong head start. Additionally, many agencies have established their policies: use them as a source of inspiration. Some policies predate this work, and GSA’s TTS, for example, has their site’s content in version control: you can see how it has changed over time. Stakeholder and legal team buy-in will take time. Make sure drafting the policy is quick and only customize specific parts for your agency as needed.
Inventory, inventory, inventory
For your agency’s information security program, that key criteria is inventory. You cannot manage what you cannot measure, and you specifically cannot defend your information systems if you don’t know which are public in near real-time. Your long-term goal is to expand this program as efficiently as possible, but you can’t progressively scale up unless you know exactly what security researchers will and will not be able to access publicly.
And let’s be clear: no system is an island! Your staff will need to continue, or start, continuously mapping how your agency’s systems connect to one another. Do your systems connect to resources external to your agency (is there an approved content delivery network from which your web applications load CSS and Javascript libraries)? Can researchers use your public system to pivot and access another system that is on your internal network? The VDP might bring surprise answers, but you also want to limit surprises as best you can. Know your system boundaries and their connections, know what data they store and exchange with one another, and express that in your inventory.
Scope small and scale up
With your inventory up to date, you need to define the systems researchers can target. As for BOD-20-01, the minimum requirement is one system accessible on the public-facing internet. A VDP will require agency personnel and additional resources, so scaling gradually is definitely best. If your agency has public-facing systems with consistent, prior security assessments and penetration tests, increasing scope is definitely possible, but do not cast too wide a net at first. You will need to define a process that works for the different stakeholders in your agency, and one in which your teams can effectively triage new reports if the volume of disclosure grows.
Design a process for disclosures
To be most effective, the disclosure process must diverge as little as possible from established agency processes and workflows you use every day to track work. This objective is crucial, but these disclosures can be sensitive in nature and, unlike almost all other project artifacts, will be from those outside your agency, from people without access to agency credentials or tools. BOD-20-01 requires you receive disclosures with old and new methods: you will need to maintain a security email address registered for your agency’s .gov domain (BOD-20-01 required this address be set up by November 2020), and also, and preferably, a secure web form with a known URL.
In the past, security researchers often used PGP keys to encrypt information in emails, and for many agencies this tooling and PGP key management will be a hassle. To receive submissions over the web, as BOD-20-01 recommends, your agency needs to think about how to submit reports, not just publish guidance text. Regardless your agency likely has its own project management and issue-tracking tools, and it is most important your team finds ways to connect these gateway tools to your overall management policy.
As part of the policy, you will need to set timelines to acknowledge the report and target timelines for remediation. For triage and ongoing measurement, it is important to put thought into welcoming any report, responding sincerely to express review by an official (and not with an automated response as BOD-20-01 rightfully calls out), and finding a best-fit approach with current workflow and automation tooling.
Triage it fast, triage it right
Once you design a process and set up tooling to get the report into the right tracking system, you need capable staff to triage these reports. Your agency will want multiple people and, if possible, those that understand the technical components of your system. Developers and system engineers are a precious resource, and the staff triaging these reports will do their best work if they have the tools and skills to ensure reports are valid before escalating them to engineering teams. Some reports might repeat the same risks and findings that your agency has accepted, so your first line of defense will understand both risk-accepted or out-of-scope reports and reject them on the spot. Additionally, many reports will not get resolved on the first pass, and tenacious reporters will let you know that you did not fix the whole issue. Maybe some edge cases were missed! If your agency can get a technically minded triage team, you will triage it fast and triage it right.
Keep it measurable and manageable
BOD-20-01 emphasizes sincere interaction and specific attempts to communicate estimates of timeline and effort with whoever discloses a report. It is imperative, therefore, to be measuring the processes in developing and maintaining your systems. Outside of your future VDP reports, do you know how your agency tracks defects, and security or functional bugs, from reporter to issue tracker and maybe into the source code repository your developers and system engineers use daily to fix these things? Do they do so at a high level of consistency? For bugs that cross multiple components or interconnected systems, can you easily cross-reference them to know all changes were coordinated to fix a single reported bug? Do system owners and management have known methods and tools to aggregate analytics about these bug reports over time? These questions might not have simple answers, but consistency in processes and supporting tools will make or break the ongoing effectiveness of a public disclosure process. VDP disclosures need to be part of a comprehensive, holistic tracking system, not novel or separate. If not, triaging will become a daunting effort.
What about the “bounty” in bug bounty?
The private sector is much more likely to pay a bounty for identification of a security flaw. It’s much less common in the government, but not unheard of. It’s worth considering whether you want to offer a bounty, and if so, what it might look like. Regardless of compensation, for some people public acknowledgement is enough reward. Having stated policies for public disclosure and/or acknowledgment sets expectations for participants and may allow for a coordinated announcement upon disclosure or resolution.
Do I need a bug bounty? Do I want a bug bounty?
If VDP is a new kind of game, bug bounties are a championship trophy. BOD-20-01 has solid guidance in their Frequently Asked Questions on establishing a VDP and offering bounties. Creating a successful VDP is a lot of work, but it’s worth remembering a VDP can be a valuable way of discovering and remediating vulnerabilities. Your agency should prepare for offering bounties of some type after your VDP matures and disclosures are consistently accepted and remediated. Invite others to play your game — just be ready to make sure it is a win for all of you.
