How to make a successful Bug Bounty program & measure its effectiveness?

We're not going to beat the hackers - we have to live with them. While we live with them we also need to ensure that we are one step ahead. We have witnessed that Hackers are exploiting the Web & Mobile Application of the organization at great extent. Due to adoption of Digitalization and more number of application in the origination many organizations struggles to put appropriate Security controls over the applications which are in production giving a opportunity to threat actors to exploit it.

Over the period of time many organizations have started using Bug Bounty program to overcome on this challenge, but the million dollar question is How to make a successful Bug Bounty program & measure its effectiveness?

What is A Bug Bounty Program & what’s the Good start?

A bug bounty program is a deal offered by many websites, organizations and software developers by which individuals can receive recognition and compensation for reporting bugs, especially those pertaining to security exploits and vulnerabilities.

These programs allow the organizations/developers to discover and resolve bugs before the general public is aware of them, preventing incidents of widespread abuse. Bug bounty programs have been implemented by a large number of organizations and have gain popularity over the period of time due to its effectiveness and participation.

STEP 1. LAUNCH A VULNERABILITY DISCLOSURE PROGRAM WITHOUT MONETARY BENEFITS:

A vulnerability disclosure program is a well-defined mechanism outsiders can use to safely report security findings to the security team. Setting one up without payouts attracts fewer participants and can be used to launch the program at a smaller scale. It allows security teams to get the feel of receiving input from people outside of the fold.

This preliminary step is important because it will provide you a glimpse into how many complex issues would be present in a full-fledged bug bounty program. These issues include how to respond to the disclosures, the escalation process, and challenges with remediation.

STEP 2. CAREFULLY CRAFT AND COMMUNICATE THE SCOPE AND PRICING OF YOUR PROGRAM:

The rules for a bug bounty program must be clearly defined for all participants. Clear communications help ensure that the organization gets what it wants out of the program and that the participants are satisfied because they will have accurate expectations of the process and payment. Rule violators should not be allowed to participate. The most important aspects to define are:

Program scope:?What kinds of bugs are you looking for? Are there parts of the infrastructure (application or network) that are off-limits? Any attack that may affect availability that you may not want to incentivize.

Pricing:?The price paid for vulnerabilities has to balance two factors. First, it must match or exceed their value on the black market—after all, you want your researchers reporting their findings to you, not to criminals. Second, the program must be affordable to run, providing a return on investment. The best strategy is to measure rewards based on the potential impact of the vulnerability discovered and by matching different levels of impact to reward values.

STEP 3. DECIDE ON A PUBLIC OR PRIVATE PROGRAM:

The more people looking for bugs in your system, the more submissions you are going to get. That sounds like a good thing, but it comes with challenges. More submissions mean you have to provide more responses, evaluate more discoveries, validate more findings, quickly remediate more valid vulnerabilities, and manage payments to more individuals. Also, with more activity on the network and endpoints, you have to keep a keen eye to determine whether it is legitimate bounty hunters or malicious actors. In short, a public program where anyone in the world can participate takes many more resources to conduct than one with a limited pool of participants that have been carefully vetted and selected through a private program.

STEP 4. SET UP A TESTING ENVIRONMENT DEDICATED TO THE PROGRAM:

Establish an isolated, segregated, and well-segmented test environment for the bug bounty program. This bug bounty test environment (BBTE) should not have any links to the organization’s Dev/QA/Prod environments to avoid any impact to business. Additionally, the dedicated testing environment would also reduce the chances of commingling production data with test data. No residual artifacts such as accounts or data from the Dev/QA/Prod environments should be in the testing environment to mitigate the risk of them being used for malicious purposes. You do not want to turn your bug bounty program into a reconnaissance activity for attackers.

STEP 5. PLAN FOR BLACKOUT DATES AND QUIET PERIODS:

The program may need blackout dates when you do not want outsiders testing your code and quiet periods following bug discovery to ensure resolution before the bug is publicized. Changes/updates may also require time for internal due diligence activities before being made available for public testing.

If you do not have a solid BBTE, consider additional blackout dates including weekly change management windows, annual change-freeze windows, and product release lifecycles. These will help minimize the impact to the neighboring environments and allow stakeholders to dedicate more time to key business changes.

STEP 6. GAIN SUPPORT FROM THE C-SUITE, LEGAL TEAM, COMMUNICATIONS DEPARTMENT, DEVELOPERS, SECURITY MONITORING TEAM, AND OTHERS:

A bug bounty program involves many company departments. It needs the executive team to provide financial support for administrative costs and bounties; it needs human resources to oversee employment and tax-related tasks such as sending 1099 forms; it needs communications and marketing assistance to publicize the program; it needs legal assistance for writing contracts, such as those that define the program and the company’s relationship with bounty hunters; it needs developers willing to incorporate bug fixes into new software versions; and it needs the security monitoring team to build additional detection capabilities for the production environment, while the relevant team rolls out a patch. Given that cyber risk is an enterprise-wide risk, a bug bounty program involves many of the cost-centers of a business.

STEP 7. START WITH A SMALL-SCALE TEST:

Before launching the bug bounty program, test it with a limited pool of bug bounty hunters, a limited scope of the environment, and a limited budget. This way, adjustments can be made to the program before widespread roll-out.

STEP 8. HIRE SUFFICIENT STAFF:

For a bug bounty program to be effective, an organization needs enough technology and administrative staff to support it. The IT team or Information Security team may not have availability to support a full time bug-bounty program in addition to their business-as-usual responsibilities.

STEP 9. MARKET THE PROGRAM:

If the bug bounty program is public, it must be marketed like any other product, service, or job opening to attract the right talent. Identify websites, schools, and other venues where security researchers congregate and communicate to them in a way that attracts their curiosity and problem-solving skills.

STEP 10. BE READY TO ACT ON THE DISCLOSURES:

This may be the most important step. When you learn of a critical bug, this knowledge can quickly turn into a liability if the issue is not rapidly resolved. Without remediation readiness, your risk management program could flip and actually introduce risk.

Bug bounty programs are positioned to become another must-have element of many enterprises’ security programs. As it has been the case with so many other new types of cybersecurity protections, adoption starts with the highest risk entities, as it already has, and it will trickle down to more types of businesses, ultimately becoming something most organizations are expected to have in order to demonstrate that they have done everything possible to protect against cyber-attacks.

How to measure its effectiveness of bug bounty program:

?Amit Ghodekar

[email protected]

Credits: multiple sources?