For DoD Partners

A Bug Bounty is an event where ethical hackers are awarded monetary compensations for successfully discovering and reporting a vulnerability through the appropriate channels.

Bug Bounties have been around for several years and are used by some of the biggest companies in the world such as Apple, CISCO, Facebook, Google and Twitter.

A Bug Bounty program is a cost-effective way for an organization to identify security risks and vulnerabilities. The program allows organizations to have experienced ethical hackers from diverse backgrounds proactively identifying weaknesses so they can be remediated.

Bug Bounties allow the DoD to find and address vulnerabilities in a rapid, cost-effective way - before the adversary does.

A public Bug Bounty permits anyone to participate in the program and receive compensation. It may be posted on a platform for the general public where anyone can sign up. The benefits are that a large amount of researchers & ethical hackers can participate and increase the amount of possible bugs reported.

A private Bug Bounty is when a smaller pool of researchers & ethical hackers may focus on more specific targets and receive compensation. Researchers complete a more extensive background screening and the program is by invitation only. The benefit is a higher level of expertise and additional control with the bounty.

A Bug Bounty program gives ethical hackers permission to test an organization’s applications for certain types of vulnerabilities resulting in monetary payment. In comparison a Vulnerability Disclosure Program (VDP) relies on hackers to “see something, say something” where anyone can submit security vulnerabilities to help mitigate risks and is not paid.

For more information on the VDP, visit: www.dc3.mil

Most bounties are unclassified, however if vulnerabilities are encountered with a higher risk, they will be escalated appropriately.

Currently, we work with a small collection of 3rd Party vendors who source the researchers from their extensive databases. Additionally, they manage the platforms for communication, validating submissions and payment to the researchers.

The researchers for our Bug Bounties are vetted with an extensive background screening from our approved vendors. They do not have a preset schedule and can access an active program based on predetermined scope from the system owners. We pride ourselves on user researchers from a broad background so in addition to U.S. Nationals, they can be from NATO and FVEY nations.

DDS Bug Bounties follow a 4 week x 4 week x 4 week model that starts after the Task Order is approved by Procurement Officers.

Bounty prep will include defining the scope and ensure backend connection to systems.

Bounty launch will include kick off, training on the vendor’s  portals, monitoring of the vulnerabilities and payments from the vendor directly to the researches.

Bounty wrap up will include review of metrics, out-briefs and final remediation.

Scoping for a bug bounty effort is a critical step in hosting an effective bounty program. Tuning your scope to fit the security needs of your organization can make a significant difference in researcher engagement, meeting your program goals, and creating a lasting positive effect on your cyber security.

Mapping Scope to Goals:
‍One of the most effective ways to scope an engagement is to begin by defining the goals or outcomes you wish to see from a bounty program. If you aim to see code development improvement then scoping in source code, deployment pipelines, and production applications may make for an effective choice. If you are hoping to identify weaknesses in your deployed application then scoping in the application and any supporting services (cloud hosting, web application firewall, load balancing) may be preferable.

‍Incentivize Worst Case Scenarios:
‍Another way to best identify scope is to table top worst case scenarios. If an attacker got in, what actions or systems would be the worst possible outcomes of a breach? Using these “nightmare” scenarios as a basis, it is possible to add incentives to vulnerabilities that would lead directly (or chain indirectly) to these outcomes. If a specific database holds sensitive information such as Personally Identifiable Information (PII) or Protected Healthcare Information (PHI), incentivizing vulnerabilities against these specific assets would be prudent.

‍Test/Staging vs. Production Environments:
‍Many organizations implement a testing environment which may be referred to as staging, test, development, user acceptance testing, or pre-production environments. Organizations may be inclined to offer these environments for scope to avoid negative impacts to production. The standing recommendation for scoping is to test the production environment if at all possible. While many test environments claim to be exact copies of production, in all prior experience nuances between these environments leads system owners to pay for vulnerabilities that do not exist in the production instance. Additionally, vulnerabilities may exist in production environments that do not exist in any pre-production instances. Asset owners sometimes profess concern about the risk of researchers accessing production environments. In our experience, the detailed rules of engagement put in place for bug bounties, combined with detailed logging of researcher actions and researchers' need to maintain their professional reputations, provide more than sufficient risk mitigation.

‍Legal Protections for Vulnerability Disclosure:
‍Organizations routinely fear perceived legal and policy consequences for vulnerabilities found during a bug bounty or a vulnerability disclosure program. Federal policy has been updated to provide protection to security researchers operating in good faith. M-20-32 provides the latest guidance on vulnerability research performed during bug bounties and vulnerability disclosure programs. It is clearly stated in that memo that, “Good-Faith Security Research is Not an Incident or Breach”. However, in the process of assessing and responding to the reported vulnerability, it is possible to discover that an incident or breach occurred prior to the vulnerability report. Any discovered incident or breach must be handled according to the OMB Memo M-17-12. Both Memo's are available near the top of this page.

Scoping for a bug bounty effort is a critical step in hosting an effective bounty program. Tuning your scope to fit the security needs of your organization can make a significant difference in researcher engagement, meeting your program goals, and creating a lasting positive effect on your cyber security.

Mapping Scope to Goals:
‍One of the most effective ways to scope an engagement is to begin by defining the goals or outcomes you wish to see from a bounty program. If you aim to see code development improvement then scoping in source code, deployment pipelines, and production applications may make for an effective choice. If you are hoping to identify weaknesses in your deployed application then scoping in the application and any supporting services (cloud hosting, web application firewall, load balancing) may be preferable.

‍Incentivize Worst Case Scenarios:
‍Another way to best identify scope is to table top worst case scenarios. If an attacker got in, what actions or systems would be the worst possible outcomes of a breach? Using these “nightmare” scenarios as a basis, it is possible to add incentives to vulnerabilities that would lead directly (or chain indirectly) to these outcomes. If a specific database holds sensitive information such as Personally Identifiable Information (PII) or Protected Healthcare Information (PHI), incentivizing vulnerabilities against these specific assets would be prudent.

‍Test/Staging vs. Production Environments:
‍Many organizations implement a testing environment which may be referred to as staging, test, development, user acceptance testing, or pre-production environments. Organizations may be inclined to offer these environments for scope to avoid negative impacts to production. The standing recommendation for scoping is to test the production environment if at all possible. While many test environments claim to be exact copies of production, in all prior experience nuances between these environments leads system owners to pay for vulnerabilities that do not exist in the production instance. Additionally, vulnerabilities may exist in production environments that do not exist in any pre-production instances. Asset owners sometimes profess concern about the risk of researchers accessing production environments. In our experience, the detailed rules of engagement put in place for bug bounties, combined with detailed logging of researcher actions and researchers' need to maintain their professional reputations, provide more than sufficient risk mitigation.

‍Legal Protections for Vulnerability Disclosure:
‍Organizations routinely fear perceived legal and policy consequences for vulnerabilities found during a bug bounty or a vulnerability disclosure program. Federal policy has been updated to provide protection to security researchers operating in good faith. M-20-32 provides the latest guidance on vulnerability research performed during bug bounties and vulnerability disclosure programs. It is clearly stated in that memo that, “Good-Faith Security Research is Not an Incident or Breach”. However, in the process of assessing and responding to the reported vulnerability, it is possible to discover that an incident or breach occurred prior to the vulnerability report. Any discovered incident or breach must be handled according to the OMB Memo M-17-12. Both Memo's are available near the top of this page.

When you begin the process of a Bug Bounty, you and the vendor set the price and scope of the bounty in advance, which means you have control over the process. If researchers submit duplicates or vulnerabilities that are not valid, they will not be paid.

However, it's important that you do not exploit this rule because if your reputation as a system owner is equally important in the community, you want to prevent gaining the reputation that you do not pay then it becomes difficult to attract top researchers to future bounties.

In general system owners can expect to pay $250K—800K per bounty, with most of the money going to researchers.

Since we can only support so many bounties per year, it’s important to prioritize our efforts on systems that are of significance to DoD or our partners' mission.

Goes without saying: it is critical that we have a champion for the bounty both at the leadership/decision-maker level, but also a reliable champion at the technical & program management levels to ensure a smooth effort.

To reap the most benefit from a Bug Bounty, the DoD partner should have a technical shop, enough to (a) quickly & effectively support the technical aspects of a bounty, like allowing researcher aspect to the network and (b) effectively remediate the discovered vulnerabilities and learn from trends after the bounty completes.

An ideal HTP partner program is one with leaders and folks who understand the value of security assessment, including bounties, and don’t suffer from the mindset of ‘this will be bad because it will show my superiors how vulnerable my product is’.

Ideally the DoD ‘customer’ will fully fund the bounty. For Army & Air Force groups that can’t fund the bounty, reach out to us since DDS receives funding from Army/AF that we may be able to direct towards a bounty. Worst case, we can petition DDS leadership to direct some DDS funds towards the bounty.