For customers that are new to crowdsourced cybersecurity, the differences between these two options may not be obvious. This blog will help you better understand which program to use when.    

The Rise of VDPs and MBBs

VDPs have been around for some time, but have really started gaining momentum the past few years as companies increasingly digitize their infrastructure. Last month, Google and Salesforce announced the Minimum Viable Security Product (MSVP), a vendor-neutral security checklist designed to help organizations ensure the minimally viable security posture of a product. The first of its recommendations is the creation of a Vulnerability Disclosure Program. In 2020, the Cybersecurity and Infrastructure Security Agency (CISA) also released a binding directive that makes VDPs a requirement and requires federal civilian agencies to remediate vulnerabilities (catalog of known vulnerabilities) within specific timeframes

Things are also heating up on the managed bug bounty side. Google has kicked off a three-month Bug Bounty Program—with triple researcher rewards—focused on identifying  flaws in the Linux kernel.

The Difference between VDPs and MBBs

VDPs and MBBs are now critical tools to have in your security toolbox, but which tool should you use for which job? Let’s compare:

• VDP: A VDP is a secure, publicly available channel for anyone to submit security vulnerabilities to organizations, helping them mitigate risk by enabling the disclosure and remediation of vulnerabilities before they are exploited by bad actors. In contrast to bug bounties, submissions are not incentivized by cash rewards. Publishing a vulnerability report after it has been fixed is another common attribute of VDPs, and gives researchers the opportunity to share knowledge and enhance their own reputation in the process.
• Public MBB: A public MBB allows anyone to participate in the bug bounty program. It’s similar to a VDP but with the addition of cash and other rewards to incentivize proactive testing. Another trait of MBBs is that testing efforts are directed by the organization themselves to specific areas where security is deemed most critical.
• Private MBB: Private MBBs are often narrower in scope than their public counterparts (e.g., more tightly focused on specific targets). Researchers are incentivized by cash bounties (aka “pay-for-results”). Private MBBs limit participation to handpicked researchers, which allows for targeted skills matching, along with background checks, geographic selection, and so on.

Understanding Use Cases for VDPs vs MBBs

The easy answer to the question of which to use is, “it depends.” But I’m going to put a stake in the ground—a vulnerability disclosure program should be a baseline security standard for everyone, as common as a firewall. All code contains vulnerabilities, even when much has been done to prevent them. According to Coralogic, the data logging analytics company, on average, a developer creates 70 bugs per 1000 lines of code.  A VDP establishes  a “see something, say something” mindset within your organization that carves out a global channel for vulnerability reports and publically demonstrates that your company is doing everything possible to protect its customers, partners, and suppliers.

Even if your company begins its crowdsourced cybersecurity journey with something other than a VDP—like a MBB or pen test—a VDP remains a foundational element.

Alternatively, organizations can start with a private MBB program too. This was the path that Motorola took when it launched a private MBB with Bugcrowd. After the success of its private bug bounty program, Motorola wanted to open a channel to showcase security maturity and interact with the wider researcher community. This drove it to launch a “neighborhood watch” in the form of a VDP.  Motorola did what made sense for its business by going with a managed bug bounty program before rolling out a vulnerability disclosure program. The end result was the same—happier customers and safer products!  

Private MBB is also often used as a similar crawl-walk-and-run rampway toward a public bug bounty program. Public MBB works well for organizations who can fix discovered security flaws in a short period of time, through team resourcing and software development lifecycle (SDLC) integration.

How VDPs and MBBs Address Security Challenges

All these options help organizations deal with the chronic difficulties they have in attracting and retaining the right security skills (aka overcoming the skills gap). Those obstacles are exacerbated by the constant need to move faster, to deploy more infrastructure and applications—demands which in turn create more and more attack surface to defend. And of course, the relentless creativity and ambition of attackers is an ever-present challenge. All of these impediments are greatly lessened with crowdsourced cybersecurity as delivered by VDP and MBB programs.

Of all the options, public MBB has garnered the lion’s share of attention. It’s often the thing people immediately think of when they hear the term “bug bounty”. If your organization is mature enough to want to attract the broadest possible range of talent, and make an even stronger statement about its commitment to security to the public, a public MBB shines.

Now that you have an understanding of VDP and MBB, where do you go from here?

Bugcrowd Can Help 

Combining VDPs with MBBs is a very common approach among Bugcrowd customers. For both types of programs, we provide everything you need to ensure efficiency, return on investment (ROI), and maximum impact.

Bugcrowd’s crowd-powered SaaS platform is built for multiple security use cases. Bugcrowd facilitates hundreds of managed VDPs, escalating high-priority issues within hours and averaging triage completion within one business day. Moving from a program (VDP) to another program (e.g., a managed public bug bounty) can be done via the platform as well. 

Start your VDP journey on the Bugcrowd Platform with an easy self-service option. Per month pricing and the ability to use a credit card are available here. Get started today and let the Bugcrowd Platform start finding vulnerabilities.    

The post Vulnerability Disclosure Program or Managed Bug Bounty: How to Determine which Program is Best for You appeared first on Bugcrowd.

At Bugcrowd, we strongly believe that:

• Appropriately rewarding hackers (see our rewards recommendations below) is an absolute requirement for all-around success in bug bounty, and
  
• The economic benefits of fair, market-rate payouts far outweigh their cost.

Let me explain why.

Case Study: MOVEit Transfer Vuln

The infamous MOVEit Transfer Critical Vulnerability (CVE-2023-35708) is a good example of how a relatively modest bug bounty reward would have paid for itself many, many times over. 

As the Russian-speaking cyber syndicate Clop orchestrated a wave of extortion against numerous companies last season, the narrative was dominated by the scope of the incursion: numerous compromised organizations, personal data of millions siphoned, and copious volumes of sensitive information leaking into the dark web.

Central to this attack was the deployment of a zero-day exploit. Whether this vulnerability was a product of Clop’s own cyber reconnaissance – or, what seems more probable, procured from a dark web forum – it provided a digital crowbar to pry open defenses. Sifting through dark net forum posts reveals indicators that threat actors were actively paying large amounts of money for high-impact vulnerabilities:

Now let’s take a look into the known impact of the MOVEit Transfer vuln on organizations and individuals, to date:

Impacted organizations: 2,561
Impacted individuals: 67,174,909

In cybersecurity economics, quantifying the financial fallout of security incidents is napkin math. But it is very feasible to sketch an illustrative financial portrait by drawing from statistics reported in IBM’s Cost of a Data Breach Report 2023. If we apply the average toll of a data breach for each compromised record (US$165) to the tally of confirmed individuals affected by the incident, the estimated financial impact is a staggering US$11.08 billion. That figure speaks for itself!

Thinking ahead

When we speak with CISOs, it is common to hear the concern that implementing a robust bug bounty program will require a financial investment that can strain limited budgets. However, short-term thinking often leads to long-term problems.

For the sake of argument, let’s assume that a program commits to paying on the higher end of our suggested reward ranges with a payout of US$20,000, not US$5,000, for each critical vulnerability (and this assumes only one is found). The long-term impact would include:

• Long-term cost savings: Investing in a comprehensive bug bounty program can lead to substantial long-term cost savings because the cost of addressing a security breach far exceeds the cost of a $20,000 bounty payout: Per the Cost of a Data Breach Report 2023, the average total cost of a data breach is well over $4 million.
• Protection of brand reputation: The impact of a cyber attack on a company’s reputation can be devastating and long-lasting. Customers lose trust in brands that fail to protect their data, leading to churn and lost revenue. Customer trust is an invaluable asset that, once lost, is costly to regain–far more costly than $20,000.
• Competitive advantage: A strong security posture can be a competitive differentiator. Companies that demonstrate a commitment to security attract more customers and partnerships. A well-funded bug bounty program signals to the market that a company is serious about security, potentially giving it an edge over competitors. You could never buy that reputation with a paltry $20,000 marketing campaign.
• Avoidance of potential fines, legal fees, and insurance premiums: As we described in a previous post, a significant breach can lead to millions in downstream costs–making that $20,000 look like a really good investment.
• Access to expertise on-demand: Bug bounty programs on the Bugcrowd Platform crowdsource the expertise of the global security community, offering access to a diverse range of skills and perspectives that internal teams may lack. This access to a broader knowledge pool can augment, extend, and enhance a company’s security team far more effectively than relying solely on internal resources. Without it, do you have the ability or the funds to employ experts for every skill and asset 365 days a year?

Hackers agree: Per Bugcrowd’s 2023 Inside the Mind of a Hacker report, 84% of them believe that most organizations do not understand the true risks of a breach.

New recommended reward ranges

For the reasons above, there is no downside to scaling your program toward even the upper range of market-rate payouts over time. (Also keep in mind that your program is competing with others for hacker attention, and money talks.) In support of that point and to reflect the current marketplace, we recently updated our recommended reward ranges for bounty programs – informed by benchmarking the most successful programs on our platform after mapping hundreds of thousands of data points about vulnerability types, severity levels, and payouts:

Respecting these recommendations is not only a proven method for enhancing impact, but it’s also the right thing to do for hackers who invest a lot of time in uncovering weaknesses that you want to hear about before potential threat actors do.

As market rates adjust over time, we continue to gather data about what makes successful programs work, and new categories (such as AI) emerge, we’ll make adjustments to these recommendations, as well. 

The post Why Bug Bounty Payouts Are Worth Far More Than Their Cost appeared first on Bugcrowd.

ExpressVPN takes the privacy and security of its users seriously. Since it operates in the privacy and security space, a security breach is a serious potential issue which could result in the loss of trust from its users. ExpressVPN was concerned about attackers obtaining access to its VPN infrastructure and compromising users through the use of its apps. As part of its in-depth security strategy, ExpressVPN decided to select a managed bug bounty provider as a way to continuously review its products and services and provide the most secure user experience possible.

ExpressVPN has been using the Bugcrowd Platform for managed bug bounty since 2020. Brian Schirmacher, Offensive Security Manager at ExpressVPN, has worked in lockstep with Bugcrowd to ensure the products ExpressVPN delivers to users are as safe as possible. “Bugcrowd allows us to become aware of vulnerabilities in areas we don’t have oversight on, such as vendors making changes to third party integrations without notifying us,” Schirmacher said. The ExpressVPN public program has uncovered nearly 100 valid vulnerabilities to date, and continues to see results as skilled hackers join the program. 

Before Bugcrowd, ExpressVPN was running a self-managed bug bounty program. One key benefit of using the Bugcrowd Platform has been its focus on engineered triage for rapid validation and prioritization of vulnerabilities, which lets ExpressVPN’s engineers focus on remediation instead of filtering noise. Bugcrowd has also streamlined reporting and the reward and disclosure processes. 

ExpressVPN has also found value in Bugcrowd’s CrowdMatch technology, matching the right hackers with the right skill sets to its needs—resulting in both a higher number of hackers reviewing its products and a more specialized group of hackers relevant to its scope. 

ExpressVPN values the straightforward nature of the Bugcrowd Platform. “Bugcrowd offers reasonable terms without some of the admin/overhead/transaction fees that other players in this space have begun to add on. They’ve focused on their core service offering and ensured their primary product continues to meet customer needs,” Schirmacher said. 

Another key differentiating factor for ExpressVPN is the heavy focus that Bugcrowd takes on acting as an independent mediator between companies and hackers. This helps maintain trust, and is a huge priority for Bugcrowd. 

Learn more about ExpressVPN’s Bug Bounty program here. 

The post ExpressVPN Uses Crowdsourced Security to Continuously Improve its Security Posture appeared first on Bugcrowd.

A duplicate (in the bug bounty world), is a report for an issue that was previously known or identified. However, when determining whether or not a given finding is truly a duplicate, the solution isn’t always cut and dried. Many situations require a non-trivial amount of nuance and context. To help with duplicate evaluation in these cases, we’ve put together a guide for a few common duplicate scenarios, where we explain how Bugcrowd looks at these situations, and how we recommend clients approach them as well. As we go through these scenarios, there are three key principles to keep in mind:

• Touch the code (or make a change), pay the bug

1. 1. • If a finding causes you to make a change—and is in scope + is a vuln that’s rewarded as part of the program brief—it should be rewarded.

• Similar != same

1. 1. • If a finding is similar to another finding, but requires a separate change, it is a unique issue that needs to be rewarded independently.

• Many != systemic

1. • Just because there are many of a particular vulnerability type, that doesn’t mean they’re all part of the same root issue.

The importance of context and nuance in duplicate evaluation

As a quick note, when triaging findings, Bugcrowd’s engineered triage takes all of the above into account (to the best of our abilities—as there are extenuating circumstances in some cases that we don’t have visibility into). We leverage our ML-powered de-duplicate detection, contextual intelligence from over a decade’s worth of data on vulnerabilities, and human validation to perform a thorough review of any and all findings that come into the platform to ensure (1) duplicates are properly identified; and (2) all unique issues are elevated for review by the client. 

Scenario #1: Multiple SQLi Vulnerabilities

• A researcher has identified ten SQLi vulnerabilities across your application for a number of different queries and resources. Since they are all SQLi, you decide to pay for one finding and mark the others as duplicates.

This approach is misguided because multiple vulnerabilities of the same vulnerability class does not equal them all being the same vulnerability. Seeing a large amount of the same vulnerability class reported on a single asset is fairly common—when there are one or two of a vulnerability type, there are usually a lot more. This may be due to the same developers making the same mistake(s) in different places across the attack surface. Like birds, vulns of a feather commonly flock together. 

Assessing Vulnerability Clusters and Determining True Duplicates

In situations like this, it’s important to realize that even though there are many of the same type of vulnerability, they’re sprinkled across the application in different contexts. This means that it’s highly unlikely that they’re all one fix. 

Some of them might be true duplicates. If fixing one removes the need to fix another, refer back to principle #1 from above, “touch the code / make a change, pay the bug.” If, as a result of fixing a vulnerability, one no longer needs to touch the code or make a change to fix another finding, then the latter is truly a duplicate of the former. 

Ensuring Fair Recognition and Reward for Unique Findings

However, it’s imperative that we only mark something a duplicate if it’s truly a duplicate (e.g. fixing the parent finding removes the need to fix the duplicate finding). In the case of having ten SQLi scattered across the application, if we try to reward only one finding and dupe the rest, that’s tantamount to saying that only one change to one area of the codebase was made as a result of those issues. If we look at the situation honestly, had the researcher only reported one of the ten SQLi issues, and that issue got fixed, there would likely still be at least nine other vulnerabilities floating around even after the first one was remediated—because each requires a unique fix. It may be tempting to assert that they’re all one-in-the-same, but that is very rarely the case.

THINGS TO KEEP IN MIND

In some cases, some might assert that implementing a WAF (or WAF rule) could count as a single “fix.” For instance, one could implement a WAF rule that blocks any injection of double quotes that were otherwise required for the SQLi vulnerability. In doing so, all the SQLi issues are no longer exploited, and are thereby “remediated.” However, from Bugcrowd’s view, findings need to be rewarded from the perspective of how they would be remediated in the underlying codebase, and not at the WAF layer. Adding a WAF rule or similar blocking mechanism is a half-measure that will invariably have a hole of its own at some point in the future that will leave the still-vulnerable application underneath exposed. There’s no shortage of WAF bypasses or other creative mechanisms that researchers have found to get around these controls, and as such, (1) any remediation should always start at the application layer; and (2) rewards should be administered based on fixes to the codebase, and not the WAF.

Scenario #2: Reflected XSS Vulnerabilities with Common Parameters

• A researcher identifies 15 reflected cross site scripting (XSS) vulnerabilities across a number of pages on your application—however, they usually end in one of three parameters “page=”, “id=”, and “utm=”. Since they are all on unique pages (e.g. /view, /news, etc), and we previously talked about how it’s important to pay for all unique issues, you decide to pay for each finding independently.

This is partially correct, and partially incorrect. It is correct in that we want and need to reward for all the unique findings, given that these issues appear to be originating from three unique parameters. The most common outcome here is that there would be three unique findings (one for each vulnerable parameter), and the rest would be marked as duplicates of the initial issue for each parameter. 

Understanding Duplicates in Multi-Parameter Vulnerability Scenarios

But this is not always the case. Sometimes the same parameter name may be handled differently by different pages—this can be evaluated by looking at where the injection is reflected back on the page, and if it’s the same place for each parameter on each page. If that’s the case, they’re likely the same issue / underlying function applied on the different pages—despite appearing on unique urls. In cases like this, fixing the underlying function will remediate the issue on every page where that function is called, and so Bugcrowd will automatically mark each initial finding as unique per parameter, and then mark all subsequent ones for those parameters as duplicates. 

THINGS TO KEEP IN MIND

It’s worth noting that in a good number of cases, even multiple parameters will be duplicates of the other parameters across the same or multiple pages if they’re fundamentally part of the same issue. A good example of this is when the page url is printed in the page content. In such cases, the url could have 30 parameters, or even a fake parameter added to it would all be reflected back in the page via the same function on the backend—which again would only take a single fix to remediate, and thereby only be eligible for a single reward across all the parameters and pages that have this issue.

In doing so, we’re adhering to the principles outlined earlier: paying for all the places where the code is being changed (once per underlying function that will be fixed per parameter), and also keeping in mind that “similar != same.”

Scenario #3: CSRF Findings on Multiple Pages/Endpoints

• A researcher submits 50 cross site request forgery (CSRF / XSRF) findings against the application for every available page/endpoint, since there is no anti-CSRF token present anywhere on the app. Since they’ve identified 50 points where there’s an issue, should they be paid out for 50 findings? 

This is where our third principle of duplicates comes into play: many != systemic. As we saw in the first and second example, many issues of a vulnerability class doesn’t mean that it’s automatically systemic, or that it should be condensed to a single finding. With certain bug classes though, it is possible to have systemic issues—CSRF being a notable example.

Clarifying Systemic Vulnerabilities and Their Influence on Payouts

If the application had anti-CSRF protections in 45 of the 50 places, and was just missing it in five of them, then each instance of missing CSRF protection would be a unique finding. This is because the protection exists, it just didn’t on those specific endpoints. However, since in our example there was no anti-CSRF anywhere on the application, it’s possible that once they turn it on (especially in modern frameworks), it’ll automatically apply itself to all of the pages/endpoints for the application, and resolve the many with a single code change. Now, this isn’t always the case, but very commonly is (specifically with CSRF). In such situations, we’ll label the issue as “systemic,” reward the first report, and mark all subsequent reports as duplicates. 

THINGS TO KEEP IN MIND

After the mitigation is applied, if there are places where the systemic fix doesn’t cover all the bases, then those would be net-new unique vulnerabilities that should be rewarded independently.

Other examples of systemic issues include subdomains that are load balanced or resolve to the same host. This is where reporting an issue on one will make it immediately applicable to all other subdomains that share the same codebase or host, etc. This isn’t an exhaustive list—just a couple examples of how/where vulnerabilities can be systemic.

Navigating Duplicates with Confidence

Hopefully this guide provides some context around how, when, and why duplicates are duplicates. It’s important to remember that in all cases relating to duplicates, it’s critical to interrogate and evaluate the situation, as context matters significantly. Many times it requires reviewing the codebase to see how many fixes a given bug will take to remediate. So, remember the three principles mentioned earlier:

1. Touch the code (or make a change), pay the bug
2. Similar != same
3. Many != systemic

As long as you’re taking these principles to heart in each situation, it’s unlikely that you’ll get it wrong. If you have any questions, the Bugcrowd team is always here to help and provide advice. 

Finally, if nothing else, always remember, whether it’s updating documentation or the codebase—“touch the code or make a change, pay the bug”. 

Good luck and happy hunting!

The post The Three Principles of Bug Bounty Duplicates appeared first on Bugcrowd.

When evaluating the value of crowdsourced security, many people focus on the number of researchers who will be focused on your targets. While this is a logical approach, it’s just as important to consider the diversity of perspectives that a “crowd” can provide. For example, in a traditional penetration test, the findings usually reflect the perspective of a single “type” of tester (more on that below) –and that produces results aligned with that, albeit ones that conform to a methodology. In contrast, a genuinely crowdsourced pen test (not a “crowd-washed” one) inherits value from the full range of thoughts, approaches, and styles that only a crowd can provide–and that enables more comprehensive, intense testing to find more diverse types of bugs. Furthermore, it’s a strong signal that “pay for effort” (typical of an industry-standard pen test) and “pay for impact” (typical of a bug bounty) testing models are highly complementary.

At Bugcrowd, we think of hackers/pentesters as belonging to one of five distinct roles: Beginners, Recon Hackers, Deep Divers, Generalists, and Specialists. (It’s also important to keep in mind that over time, hackers/pentesters can and will journey from one role to another.) Each type has an important role to play in a given program, and those roles are relevant to how the Bugcrowd Platform’s CrowdMatch^TM technology matches the right crowd to a customer’s needs, at the right time, across 100s of dimensions.

Next, let’s take a look at each type of role in more detail.

The Beginner

Beginners on the Bugcrowd Platform refer to those who are new to the concept of crowdsourced security in general, rather than just being new to the platform specifically. When assessing a hacker’s level of experience on the platform, we may consider factors such as their participation on other platforms or their published research and tools. However, if such information is not available, we may assume that the hacker is a beginner in the ecosystem, at least initially (although this may not always be the case).

It’s important to note that being a Beginner does not necessarily mean that an individual is unskilled, even if they’re only submitting P3/P4 issues. For example, they may be working through a course to broaden their skill set, or they may have limited public presence but already work as a pentester and want to further develop their skills. Typically, this type of hacker covers vulnerability classes that others may not focus on as much, including P4 issues related to authentication and authorization, as well as simpler infrastructure issues (such as DMARC). 

Beginners add value in terms of coverage and consistency. Their participation in a program ensures, for example, vulnerabilities that would typically be found in a penetration test are also identified in a bug bounty program. The last thing we want is for a customer to follow a pentest with an overlapping bug bounty, and only then learn about a bunch of lower-priority items!

The Recon Hacker

Recon Hackers focus on identifying issues across the largest scope possible, so these individuals often discover P2/P3 issues that would not typically be found in a penetration test. 
Over the past few years, Recon Hackers have dominated every provider’s leaderboard due to the proliferation of subdomain takeovers, particularly in ROUTE53 and EC2 takeovers. While these takeovers are now largely patched, the leaderboards are now askew, and thus the highest-rated hackers may not always bring the maximum level of impact.

It’s important to note that many recon-based hackers are highly skilled. However, many of those who take a recon-first approach have found a lucrative niche, and thus tend to focus on refining their toolkit to further exploit only that niche.

The Deep Diver

Deep Divers are the most valuable hackers for Bugcrowd to identify, engage, retain, and uplift. These are hackers who tend to focus on a particular program, learn as much as they can about it, and provide unique and distinct value. A Deep Diver can uncover vulns that nobody else can due to their persistence and long-term knowledge of how a program operates.

Identifying these hackers is best done by analyzing the content of their submissions–rather than just looking at the spread of vulnerabilities on a program–due to the unique nature of these findings. 

The Generalist

Generalists take a multifaceted approach: They have a solid foundation in reconnaissance and utilize it to cover attack surfaces thoroughly, without relying solely on large-scale monitoring and tooling. Generalists also apply a deep-diving approach to evaluating assets, similar to the Deep Divers. While they may not spend as much time on a particular program as deep divers do, they invest considerable amounts of time across a variety of programs. Due to their dual proficiency in recon and deep diving, Generalists gain a reputation on the Bugcrowd Platform quickly and are highly valued. 

The Specialist

Specialists are a rare breed who require specific sourcing for an engagement. They possess unique and rare skill sets, and typically have years of experience in a particular technology (e.g., APIs, AI, IoT, web3) or a specific Bugcrowd VRT category.

As you read in the introduction, one of the Bugcrowd Platform’s greatest strengths is its ability to source and activate specialists to meet a program’s specific skill-set needs. Due to their specialized knowledge, Specialists can uncover issues that other hackers may miss, and they often provide invaluable, unique solutions to a problem. 

An Engineered Approach

To maximize the contributions of each hacker role, Bugcrowd is strategic in its approach to sourcing and engaging with them. For example, adding Beginners to a program that has been running for three months may lead to frustration and a high number of duplicates, while adding Generalists too early dilutes the ability for Beginners to up-level themselves through their findings. Therefore, program maturity is an important input for our platform’s CrowdMatch^TM technology when it sources the appropriate roles.

To summarize, different hacker roles contribute to crowdsourced security programs in different ways, and it’s important to deeply understand the program’s needs to make the most of those contributions. To respect that process, unlike other providers that rely on leaderboards or coarse-grained methods, Bugcrowd’s engineered approach intelligently sources and activates the right role types and skills for your programs, at the right time.

The post How Different Hacker Roles Contribute to Crowdsourced Security appeared first on Bugcrowd.

Media companies like TX Group remain firmly in the bullseye for cyberattackers. Media companies must be extra-vigilant in order to protect themselves. And this is a considerable challenge for TX Group which, among its 3,700 staff and across all its individual companies, employs 500 developers at 50 locations worldwide. TX Group manages over 500 developers in 50+ locations and is constantly launching new digital products and services. 

In November 2020, the company was subjected to a daily barrage of DDoS attacks. TX Group went public and confirmed that other media companies had been attacked as well. This open collaboration resulted in shared information about how to better deal with such an attack and ramp-up DDoS protection. 

TX Group brought the same open-minded approach to vulnerability discovery through the adoption of bug bounty programs on the Bugcrowd Security Knowledge Platform^TM as a core strategy. The company now runs two public programs that have superseded annual audits at the group’s digital companies, vulnerability scanning of on-premises legacy solutions, and a managed SOC. 

Why Bugcrowd?

TX Group chose Bugcrowd after considering proposals from several major bug bounty solution providers, including Bugcrowd, HackerOne, YesWeHack, and Synack. Proposals were evaluated based on a cost-benefit analysis (price), availability of a managed platform, availability of pre-built integrations (e.g. Slack, Jira etc.) and — most important — the ability to provide the SecDevOps team with a customized solution.

Outstanding Results

TX Group’s managed bug bounty program has delivered outstanding results. Even with the company conducting initial audits before commencing programs, up to 20 times more vulnerabilities were discovered in some cases, and a significant number of vulnerabilities were designated as critical. 

Not only are TX Group assets now more secure, but its investments in security can now be more directly tied to results because bounties are paid only for validated vulnerabilities. In contrast, a classic audit always incurs costs, whether valid vulnerabilities are found or not.

Learn More

To learn more, read the TX Group Case Study here.

The post Bugcrowd Uncovers Up to 20x More Vulnerabilities for TX Group appeared first on Bugcrowd.

The importance of these questions can’t be overstated. As the famous saying goes, you can’t manage what you can’t measure. By defining the objectives and metrics for your bug bounty program as a first step, you’ll get a critical tool to help you understand if your program is on track and healthy, as well as when it’s time to make adjustments.

Here are some common success metrics for a managed bug bounty program on the Bugcrowd Security Knowledge Platform^TM. Note that while these measurements are expressed in months, they can just as easily be applied on a yearly/quarterly/weekly basis–but on average, a monthly metric is the ideal tool for measuring efficacy. Rich analytics and reporting in the Bugcrowd Platform, along with your Customer Success team, help you track all of them, as needed:

X submissions per month

This metric is something you should track if your goal for the program is raw activity– providing insight into if researchers on your program (aka the “crowd”) are testing in-scope assets and reporting issues. Regardless of the validity of the submissions, this number tells you whether your crowd is at least making an effort to find them. This metric is useful for targets that have been thoroughly tested and are unlikely to yield a high number of unique findings per month.

X valid submissions per month

This is a more stringent version of the above that indicates whether your crowd is identifying valid issues. (As a general rule, roughly 30% of all findings are duplicates, 30% are invalid, and 30% are unique, valid issues.) Depending on the number of in-scope assets involved, this could be one valid finding per review period, or it could be 50–it all depends on your program’s scope and maturity.

X valid P1/P2 findings per month

This is an even more stringent variant of submission measurement focusing on critical vulnerabilities. For most programs, critical/high findings may be few and far between, so this number may be relatively low–but if finding critical vulns is your goal, it’s the right one to track. (Note that you can track multiple metrics concurrently–for example, you could track this and track total submissions overall; it’s not one or the other, so much as it can be an “and/or” situation, depending on goals.)

X dollars awarded per month

This metric is a reasonable reflection of value from most programs. For instance, if your program awards $500 versus $5,000 over a given period of time, it’s a safe bet that paying the latter amount will have derived more value from findings than the former. This goal will vary depending on budget, departmental objectives, and so on. One novel, self-sustaining approach is to allocate a certain amount of reward spend per month (say $5,000), and whatever isn’t rewarded that month is then stacked on top of the subsequent month (resulting in a respective increase in the amount of earnable pool). This allows for predictable budgeting, while organically increasing bounty payouts as findings become more sparse.

X targets added per month

If your goal is to expand coverage as a way to reduce risk across your attack surface, this is the ideal measurement because it indicates whether more assets are moving into scope.

Existence of the program

For some organizations, especially as they move to more mature programs, the goal for the program is often simply that it exists. At some point, rewards may reach a peak where it’s no longer tenable to continue to increase them, or submission volume may not be particularly high due to earlier findings being remediated and better coding practices being adopted. At this point, the program serves as something of an “insurance policy” that proactively incentivizes people to report issues, but doesn’t have a high volume of issues reported otherwise. The fullest expression of this goal is taking the program public–by allowing anyone on the internet to participate in your program, you create the most mature, realistic sample size.

X number of testers performing verified coverage per month

Finally, some organizations may want or need assurances that researchers are testing, but in the absence of findings, the question becomes “How do we know if people are doing testing as deeply as we need them to?” To answer this question, we recommend running a penetration test that pays researchers a flat rate to follow a testing methodology against your in-scope assets. Whether testing the login form, implementation issues, or other functionality, the crowd can provide the visible coverage that you and your organization need.

Next steps

After you’ve defined goals and metrics, the next step is to implement them in your program and then put yourself in a position to iterate meaningfully–whether by increasing incentives, growing your crowd, adding scope, or in any combination as needed. To provide a roadmap for that journey, we’ve published a new customer guide that explains everything you need to know about creating, tracking, and responding to bug bounty metrics appropriately based on simple examples. (Or, watch an on-demand webinar on this topic.) If you have any questions or need further help, we’re always here for you!

The post Metrics for Growing and Improving Your Bug Bounty Program appeared first on Bugcrowd.

In this post, which is based on past experiences with Web3 customers and researchers on the Bugcrowd Security Knowledge Platform, we’ll offer a few simple rules along those lines for building a top-notch Web3 bug bounty program on the platform.

Offer appropriate, impact-based rewards

First, and most important, rewards have to be appropriate in size. It’s important to keep in mind that researchers often treat bug bounties as a full-time job (especially the extremely good talent, which are exactly who we want and need to attract here). It’s highly unlikely that such researchers will spend hours auditing an asset for a potential payout of only hundreds or a few thousand dollars, so if rewards are too low, don’t be surprised when all you get are shallow results from a scanner. Instead, offering appropriately sized monetary rewards ensures that researchers will have a clear, motivating incentive to spend quality time on your targets to find high-impact vulns, and that they won’t spend their valuable time on competing programs. (As an extreme example, in April 2022, Aurora awarded a $6 million bounty to a researcher for responsibly disclosing an inflation vulnerability!)

Rewards should also be impact-based. In other words, if your program’s main goal is to prevent theft on any tested platform, then regardless of how that goal is achieved (whether via a web request or by breaking the underlying cryptography), findings should be treated and rewarded the same way. 

Read “Setting Up Your Program Reward Ranges” for more information about designing appropriate incentives.

Open the scope

In situations as broad and as nuanced as finance (whether via fiat or crypto currency), it’s important that the entire organization be in scope as part of the bug bounty program. Securing one’s front door with 12 deadbolts is little protection for the open window out back, and the same holds true when securing financial assets. Whether attack vectors include leaked information on GitHub, credentials found on pastebin, a SQLi vulnerability, or an old server that someone forgot to take down, they all need to be in scope–because that’s how attackers in the wild will approach your organization as a target.  

As another example, unless your Ethereum fork is completely different than the original blockchain, it doesn’t make much sense to limit scope to your own fork without putting all your other assets in scope. In such scenarios, it’s much more likely that there are security deficiencies in assets other than in the blockchain code itself–which is already thoroughly audited by thousands of pairs of eyes.

Read “Scopes: Where Bigger is Better” for more background on the benefits of open scope, generally.

Be public, not private

We usually recommend that programs with Web3 targets should be run in public. Why? Because similar to the guideline above open scope, it’s important to maximize not only the attack surface that the good actors see, but also the number of eyeballs that see it–giving you the best and most effective route to identifying security risks before the bad actors do. Furthermore, having a healthy, public bug bounty program sends a clear message to your investors, customers, and potential users that you take security seriously and protect your customers over anything else.

Make it easy to get started

Onerous setup requirements guarantee that most researchers will avoid your program in favor of one where they can start testing immediately, without having to spend their own money and time deploying multiple services. (Even if you remove those requirements later, most researchers won’t bother giving you a second chance.) So, it’s critical to make it as easy as possible to get started.

For example, one of the best ways to do that is to provide a testnet deployment that researchers can quickly and safely test against.

Use familiar currencies for payments

Always offer the option to pay your bounties in USD, Bitcoin, or Ethereum; don’t make the overhead of safely converting niche currencies to mainstream ones a barrier for researcher participation. Again, you want it to be easy and appealing for researchers to participate in the program, removing any reason to take their skills somewhere else. 

Always provide detailed, transparent explanations

Sometimes you’ll need to change a submission’s priority or reward an unexpected bounty amount due to attack-scenario limitations only your team knows about. In these cases, the best thing to do is to put yourself in the researcher’s shoes and understand that a detailed, transparent explanation goes a long way toward establishing mutual trust. For researchers, there are few worse experiences than getting negative feedback about your hard work because of some hidden agenda.

The more detailed the explanation, the easier it will be for everyone to be on the same page about goals and rewards. This could also lead to researchers identifying additional attack vectors that circumvent your systems, and may even allow them to escalate their findings.

Let researchers publicly disclose findings after remediation

As we said previously, transparency helps build mutual trust between program owners and researchers, and that applies to disclosure policies, as well. For that reason, we strongly recommend a “coordinated disclosure” approach in which program owners allow researchers to publish mutually agreed vulnerability information after fixes are complete. Having that level of transparency about disclosure attracts positive attention from other researchers, and it’s good for your “security brand” (“Here’s how we quickly identified, remediated, and disclosed a risk for our users”), as well. 

Read our docs for more information about coordinated disclosure.

Happy Web3 hunting!

There’s no such thing as a sure thing when it comes to bug bounties, but if you follow all these recommendations, your program will be as well positioned as it can be for success on the Bugcrowd Platform!

The post 7 Rules for Top-notch Web3 Bug Bounty Programs appeared first on Bugcrowd.

The good news is that bug bounty and crowdsourced security are tailor-made to help address the problem, and their adoption by hyperscalers for their cloud products and open source projects is proving it.

Hyperscalers Double Down

Microsoft is an enthusiastic adopter of bug bounty, and recently announced that it paid out $13.7 million in rewards through its 17 active bug bounty programs over the past 12 months. (Bugcrowd processes bounty payments for Microsoft’s programs.) The bounty table is impressive: The Platform Program for Microsoft Hyper-V offers up to $250,000 for findings in the area of critical remote code execution, information disclosure, and denial of services vulnerabilities, and a similar program for Microsoft Windows Insider Preview offers a bounty range of up to $100,000 for critical/important vulnerabilities. 

Possibly based on the rapidly expanding attack surface associated with cloud infrastructure (including the discovery of six critical Azure vulnerabilities in 2021), Microsoft expanded its bug bounty programs in the past year, adding “high-impact security research scenarios” to its Microsoft Azure Bounty Program. 

Although Amazon Web Services has a less systematic approach to crowdsourced cybersecurity than Microsoft to date, it does accept vulnerability submissions for its cloud products and open source projects, and provides public infrastructure for running private bug bashes (with a goal of squashing 1 million bugs, collectively).

Beyond cloud infrastructure itself, cloud applications are inherently at risk due to potential misconfigurations or data exposure, insecure APIs, lack of tenant isolation, and numerous other reasons. As Bugcrowd Founder/Chairman/CTO Casey Ellis has remarked, “A lot of people would just assume that [security] is all sorted when they go to use a cloud provider — and might be a bit surprised to find out it’s not.”

Google Brings Bug Bounty to Open Source

Meanwhile, in August 2022, Google rolled out a new self-managed bug bounty program focusing solely on Google’s open source projects. The new Open Source Software Vulnerability Rewards Program (OSS VRP) will offer vulnerability rewards that range from as low as $100 to slightly over $31,000, with possible bonus increments that range to $1,000 in the case of a “particularly clever or interesting” vulnerability.

Google was an early adopter of bug bounty through what is now called its Bug Hunters Community, with 12 years of experience and more than $38 million in payouts on record. In 2021, Google disbursed a total of $8.7 million in bug bounty rewards to nearly 700 security researchers across 60 countries. 

This new program is another proof point that the open source software supply chain has become nearly impossible to defend with traditional means due to complex dependencies, constant code churn, increased opportunities for malicious code injection, and other factors. In its announcement, Google cites a 650% year-over-year increase in open source ecosystem attacks, including the recent major incident involving Log4j. 

Next Steps

Now that cloud adoption and open source software are ubiquitous, more security leaders are learning the lesson that Microsoft and Google learned years ago: that status-quo, reactive approaches to cybersecurity alone fall short as scale grows–and nothing says “scale” like cloud and OSS. 

To learn more about crowdsourcing and cloud vulnerabilities in particular, grab a seat for our webinar on the subject with Enterprise Strategy Group cloud security analyst Melinda Marks.

The post Cloud and OSS risks have Bug Bounty adoption humming appeared first on Bugcrowd.

What is a scope? 

A scope is the defined set of targets that have been listed by an organization as assets that are to be tested as part of a particular engagement. Things that are listed as “in-scope” are eligible for testing, and things that are “out of scope” are to not to be tested. 

If you think of scope as a spectrum, there are three main categories that programs fall under. Where you fall could determine the effectiveness of your program reaching researchers and the overall success of your program. 

 Three main types of scopes:

1. Limited Scope: a limited scope on a bug bounty program only includes a single or specific target(s). 
2. Wide Scope: a wide scope bounty program is one that includes a wildcard to the in-scope targets.
3. Open Scope: an open scope bounty program is one that has no limitations on what researchers can or cannot test, so long as the target/asset belongs to your organization. 

For programs that currently fall under (1) or (2), considering a move toward open scope is almost always a good idea. If you’re feeling unsure, don’t worry: Most organizations and bounty programs take a systematic progression over time. It’s common to start with a basic or limited scope, move to a more expansive, limited scope, then to a wildcard, and finally, to an open scope.

Why is expanding your program’s scope important?

Threat actors aren’t asking for permission to use an open scope; they don’t have to play by any rules, and they aren’t going to limit themselves to entering through your “front door.” So, limiting what defenders can test only creates more disadvantages. For that reason, an open scope program is not only useful, but necessary: There are few actions that are more potentially effective in improving security posture than running an open-scope bug bounty program.

Ready to start moving your program toward an open scope?

The best place to start is by talking to your Bugcrowd Success Team – your TCSM will help provide guidance, recommendations, and support for whatever you need to get going. Bugcrowd is here to help you secure your organization, and we know that open scope is a critical part of your security journey. To learn more about Open Scope, check out this guide. 

The post Is An Open Scope Program Right For Me? appeared first on Bugcrowd.