First, a little bit about me. I’m Elle Green, Team Lead of the TCSM team at Bugcrowd. In this blog, I’ll be giving you a sneak peek behind the scenes of the TCSM team, so you can see for yourself why so many Bugcrowd customers cite “Customer Success” as one of our key differentiators compared to other solutions. 

What does the TCSM team do?

The success of a program is a collaborative endeavor between TCSM and Program Owners (customers). Our responsibility encompasses program launch, understanding customer needs, and charting a path for growth and success. Given the diverse nature of programs, we assess individual requirements to guide customers towards achieving their goals.

Technical Customer Success plays a pivotal role in the customer lifecycle. We assist clients in understanding the platform, ensuring brief accuracy and readability for hackers, align reward ranges with expected hacker caliber, identifying areas of improvement, and proposing effective solutions. Above all, our focus is on client satisfaction, consistently exceeding their expectations.

When a customer decides to partner with Bugcrowd, they’ll be connected with their Technical Customer Success Manager. From there, the teams will come together for a launch call, where we’ll discuss client expectations, program scope, brief details, and the launch date. 

The TCSM team’s role actively maintains the ongoing health of programs, monitoring their activity closely. It falls upon us to identify and communicate any declines in activity, offering our proposed solutions to address such situations. Following the launch of programs, it becomes our duty to ensure their sustained success, delivering the anticipated value to our customers. Throughout this process, our team is dedicated to assisting and supporting our customers at every stage.

At Bugcrowd, our top priority is long-term customer satisfaction and success, and the TCSM team is a key part of that. It’s my job (along with my team) to help you launch, manage, grow, and get value from your programs. 

In the role of a TCSM, it’s crucial to recognize that clients possess varying levels of expertise. Some clients have experience in the security field, while others, newer to the domain, may be uncertain about their specific needs. Our duty is to ensure that every client is well-informed about the features of our platform and that we offer diverse solutions tailored to their requirements. We are responsible for providing thorough training to each client, ensuring they understand their expectations on our platform. Above all, it is our responsibility to convey to each client that they are not just a statistic; their significance is paramount to us. During the onboarding process, we meticulously gather details to formulate the best solutions that will drive their program(s) to success. 

With over a decade of experience in various engagements, Bugcrowd possesses a profound understanding of the strategic levers that propel customers to derive optimal benefits from their crowdsourced security programs.

Communicating with the TCSM team

Regular syncs that are held weekly, bi-weekly, or monthly, ensure that we remain aligned with our customers’ objectives. Maintaining close communication with each client is imperative to keep them on track and facilitating their growth on both a corporate and platform level.

Tips to maximize your investment in crowdsourced security with the TCSM team

I’ve been on the TCSM team here at Bugcrowd for almost three years, so I’ve seen the magic that happens when a customer works closely with their TCSM. Here are a few tips to maximizing your investment in Bugcrowd by partnering with your TCSM:

1. Regular communication—Lean on your TCSM’s advice and join regular syncs to identify quick-wins and areas for growth potential. 
2. Establish clear expectations—We are here to support you. However, you know your needs better than we do. It is important to discuss expectations because it would allow us to align with your needs and begin working towards a goal.
3. Ask questions—If you require additional clarity on something, ASK. Our job is to ensure you and your team are comfortable on the platform. Our goal is to build a strong partnership to maximize your value on our platform. 
4. Provide feedback—If you’re unhappy with your program’s results so far, let us know. If you’re happy with your results, also let us know. We will work with you to understand your concerns and goals and will develop a path that aligns with your definition of success. If your program is doing well, we will ensure we do everything possible to make it even better. 
5. Trust—The end goal for each of us is to ensure you are getting the value that you wish to receive on your program. We rely not only on your feedback, but that of internal teams who may identify additional areas of improvement. 

The post Partnering with Technical Customer Success Managers at Bugcrowd 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.

• Collaborate with the community to collect feedback and expertise to drive improvement
• Maintain a taxonomy that reflects  the latest changes in our ecosystem
• Enable vulnerability category-based workflows through ease of mapping

Driving further categorization within Automotive

With the vulnerability categorization being central to many security teams’ reporting, it’s essential to get the insight and visibility needed to make decisions. That’s why we partnered with Stellantis to add twenty automotive specific vulnerabilities across CAN, ABS, RSU, and infotainment systems. This builds upon the efforts in 2019 to support v1.7 in creating the initial `Automotive Security Misconfiguration` category, and we look forward to the community’s ideas on how to further improve.  

Reducing impact of Flash with end of life

As Adobe announced Adobe Flash’s end of life on December 31, 2020, all major browsers have coordinated to disable Flash from running. Due to strong mitigation plans upstream at the browser to disable end-users interaction with Flash, we’ve downgraded all Flash-based entries to P5.

Train to reduce repeat vulnerabilities

Fixing a vulnerability is good, but training a team to reduce the chance of it happening again is better. That’s why we’ve partnered with Secure Code Warrior to link each of our categories to their applicable training. Leveraging mappings to VRT is a breeze thanks to our Ruby client that does all the hard-lifting of mapping and deprecating classification so you can easily find the CWE, CVSS, Remediation Advice and soon, the Secure Code Warrior mapping for any classification.

Platform Launch

V1.10 will be available throughout the platform the week of April 12th. This is included but not limited to all program’s submissions forms, reporting, filtering and our Ruby client.

Celebrating our tenth version

Over the past four years we’ve seen over a hundred issues opened up to the community, ultimately driving updates to improve categorization, impact, and remediation understanding across all users who leverage the Vulnerability Rating Taxonomy. Thank you to all who have provided feedback! 

Check out the latest version and stay attuned to what’s next by subscribing to future discussions.

The post VRT v1.10 Released: Flash downgrades and extended automotive categorization appeared first on Bugcrowd.

While Bugcrowd offers full program management for all of our products and services, we also appreciate the value of flexibility and control. Sometimes this means making changes to program scope, rewards, bonuses, or even messaging, as and when it makes sense for your business. To help facilitate this, Bugcrowd has launched Self-Serve Program Announcements. Rather than request a change through Bugcrowd, customers can publish changes directly themselves. To encourage higher levels of engagement and activation, researchers subscribed to a given program are then pushed email notifications alerting them of changes.

What’s changed: 

Previously, all announcements (known as program updates) were routed through a Bugcrowd customer success manager. While this workflow will still be available, customers may now choose to directly edit and publish briefs themselves. We also wanted to be sure to provide you with insight from our experience of sending over two thousand announcements over the past 2.5 years, so we provided a variety of templates based on the reason selected for the announcement. These templates render markdown to provide table breakdowns of new scope, links directly to the target, along with a reply-to and link to email Bugcrowd Support for any further help.

Features and Advantages:

• Ability to update on your own time as you see fit
• Templates that make updates quick and easy, and ensure structural continuity between program owners
• More direct engagement with the researcher community.

Announcement Options:

Customers can also communicate directly with the researchers on their program to alert them of updates related to new features or releases, language or scope changes to the program brief, reward structure changes, or announce bonus reward periods. 

Announcement details:

While researchers will see the update within the email notification and link from the bounty brief, the customer can see a full list of announcements with the number of recipients emailed within their announcement page. In addition to seeing historical published announcements, one can manage drafts for upcoming announcements through this page.

In addition to email notifications, published announcements appear on the program page as well.

Interested in learning more about this update? Read more on Bugcrowd’s Researcher Docs page.

The post Bugcrowd Introduces Self-Serve Program Announcements appeared first on Bugcrowd.

The problem

In their formative stages, many organizations have a limited attack surface — often only one web app or a few subdomains. But as they grow and expand their publicly facing footprint, most fail to grow their security testing programs in step. In crowdsourced security, this opens a gap in coverage and creates grey area for security researchers who identify issues in assets that fall out of scope for the bug bounty program.

The solution

At Bugcrowd, we’ve seen an uptick in such situations, and have two solutions that will greatly alleviate stressors to both parties. 

1. Have an expansive bounty program that includes all assets owned by the organization — providing an inlet for researchers to report and get rewarded for any and all security concerns.
2. Run a Vulnerability Disclosure Program (VDP) in conjunction with one’s bug bounty — providing an inlet for researchers to report any and all security concerns they find in the wild. VDPs are open scope by default, allowing researchers to report any security issues identified across the entirety of your attack surface.

Both of these options allow researchers to easily report any/all security vulnerabilities to the organization, which is what our most successful customers agree is necessary to ensure the entire attack surface is being secured. We believe the ideal solution is to offer bounties for all findings in order to encourage more active bug hunting (option 1). Where that’s not tenable, then the following example strongly underscores the imminent need for a VDP (option 2).

Why change now?

Consider for a moment the position of a researcher who identifies a vulnerability in an asset that’s not technically in-scope for a bug bounty program, but still presents a security risk for the organization as a whole. Since the asset is out-of-scope for the bounty program, the researcher will then need to try to find a place to report the issue — but where do they report it to?

Perhaps they look on the website for a disclosure page — but if that doesn’t exist, what are their other options? Some try reaching out via LinkedIn or Twitter — but what happens when those are similarly unresponsive? Security researchers are driven to affect change, and in lieu of getting an actionable response across the board, the only remaining alternative may be attempting social channels in hopes of drawing proper attention to the issue. These situations rarely end well for anyone involved, and could usually be avoided entirely if there had been a proper disclosure program offered by the organization.

Next steps

Where possible, adding a VDP and expanding the scope of your bug bounty program will reduce submission ambiguity and improve researcher relations. However, if you’re unable to do one or both of these, there are steps you can take today that also help. 

1. If you currently run a bug bounty program and VDP program separately, make sure to explicitly call out the presence of the VDP on the bug bounty program so researchers know where to submit otherwise out-of-scope findings.
2. If you don’t currently run a VDP in conjunction with your bug bounty program, set up a rudimentary VDP at a bare minimum. The most common variant for this is adding a security@ email address and/or a short form on your organization’s main webpage. This way, researchers at least have a place to report any security issues they identify in the wild that affect your organization.

Through all of this, despite the ever-changing landscape, the end goal remains the same — making your organization (and the internet) a safer place for everyone. We’ll always continue to learn and iterate as we feel it benefits the community and the organizations we support. Good luck and happy hunting! 

The post The Problem with Limited Scope appeared first on Bugcrowd.

As we’ve touched on earlier in this blog series, core to creating a successful program is the idea of having a clear and coherent program brief. As a quick reminder, the program brief is a single page document that outlines the scope, expectations, rewards, prioritization, and any other information that hackers need to be successful. Given that it’s the central and key artifact when it comes to your program, it’s of paramount importance that the brief contains not just the information so that your program can be understood, but also that it cannot possibly be misunderstood – creating what amounts to a contract between you and the hackers.

In today’s blog, we’ll take a high-level overview of all the components in a program brief, and provide some guidance in regards to putting yours together. As a note, for any program managed by Bugcrowd, our Solutions Architect team will provide guidance to all customers looking to launch a crowdsourced program; however, in lieu of having that hands-on guidance, this guide is intended to start you off on the right foot.

Scope

As the central and single most important piece to any program, a well-defined scope clearly tells researchers what they can and cannot test within the boundaries of the engagement. It’s thereby absolutely critical to ensure that as we’re defining our scope, there’s no room for misinterpretation. This in mind, the scope for any given program is entirely contingent on what your goals and objectives are with the program.

That said, in terms of guidance when setting up your scope, there are a few things we want to call out as potential points for consideration:  

1. Too narrow of scope may result in coverage and testing gaps (creating a false sense of security), or may signal to hackers that it’s not worth their time
   1. For instance, if we have an API with five total endpoints, and no credentials for researchers to test with, a good number of testers are going to look at the extremely narrow scope, and decide it’s not worth their time to look at something so small. Generally speaking, less attack surface = less opportunities for findings – and bug bounties are all about maximizing the time one spends testing to the vulnerabilities found (and thereby rewards).
   2. If there are a low number of meaningful findings against a narrow scope, you may begin to think that you’re reasonably secure. However, this is usually far from the case. There’s no shortage of examples where programs seemed to have no findings until they opened their scope up, receiving hundreds of submissions almost instantaneously. Wherever and whenever possible, we strongly advise you to open up your scope to include their entire digital footprint – allowing hackers to better mirror how attackers would function in the wild.
2. Try to expose as much of your footprint as possible. If you have certain assets you value more than others, our recommendation is to simply tier those out, where your primary assets have the highest rewards, and secondary assets are rewarded at a slightly lower rate – and so on.
3. Always evaluate your scope from the mindset of a hacker. Ask yourself “how could I misread or misinterpret this information?” A vague or incomplete scope may lead to lost cycles while hackers ask a question around verification, or worse, they move onto another program.
4. Think about how you want to handle submissions that are valid, but out of scope. For instance, if there are two sides to your business, and only one side is in-scope, what happens if a hacker inadvertently stumbles on an issue that affects the other side of the business? How can they report that finding, and what is your policy? Clearly outlining these contingencies are extremely helpful in both setting expectations for hackers, as well as knowing what to do when such findings do come in.
5. Finally, if your goal is to target a very specific app/target, as much as we prefer the scope to be open, it may behoove you in some situations to limit the program scope to just what you want tested. Again, this is only advised if you absolutely need hackers to focus on just the one thing. An overly broad scope may ultimately distract resources and time constrained hackers from focusing on what you need them to focus on.

Focus Areas / Target Information

After you inform hackers what you’re looking to have tested (e.g. what’s in scope), it’s important to now talk about where you’d like them to focus their attention and effort. For instance, if there’s a new feature or attack vector you’re want to ensure is covered, it’s worth calling those areas out explicitly. Additionally, many program owners also find it effective to add point-in-time or long-term bonuses around focus areas.

Of note, focus areas should not include generic vulnerability classes (e.g. XSS, SQLi), as hackers typically look for those types of findings by default. Calling out very specific situations is much more effective – such as advising hackers that you’ve got a premonition that there might be input validation issues on a few specific endpoints or parameters, etc.

In addition to including distinct and clear focus areas, it’s also important that we include some high-level information and all relevant documentation around the in-scope assets. For an API target, that means making sure to include API docs so that researchers are able to test effectively. For a credentialed application of any sort, it’s important to call out how researchers can register, or how they can gain access to any relevant authenticated scope. For a complex, multi-tenanted financial webapp, this means providing high-level guidance around what certain roles are supposed to have access to, etc. For complex or unintuitive targets, this means writing out detailed, step-by-step instructions for getting started, links to resources, and so on.

When building out the target information section, it’s helpful to keep perspective on what you’re providing to researchers. Understand that everyone seeing this is unlikely to see things with the clarity, insight, or understanding that you have – so, be sure to take a moment to really dive in and give as much information as you feel is needed to help researchers be effective against your assets. Remember, contrary to how it may feel, we want researchers to find vulnerabilities on our program, and providing the information they need to be successful is an integral part of doing so.

Out of Scope

The inevitable corollary to setting up a program’s scope is to simultaneously call out what is out-of-scope. Anything not explicitly in scope is presumptively out-of-scope; however, sometimes there may also be sub-components of the in-scope assets that you prefer hackers not test. For instance, you may not want people sending in support tickets that will clog up internal team queues, or you may want to exclude 3rd party hosts that run on infrastructure other than your own (blogs, forums, etc). Keep in mind that hackers are penalized for making out of scope submissions, so it’s important to be sure that we set proper expectations around what should/shouldn’t be submitted to the program.

Exclusions / Ratings

Very similar to, but slightly different from the out-of-scope section, is the inclusion of program exclusions. Program exclusions are typically any vulnerabilities or vuln classes you don’t want hackers submitting to the program. Historically, this has been a very long list of finding types that most program owners don’t like seeing (e.g. clickjacking, missing security headers, etc). If you look at a number of bounty programs on the web, you’re likely to see some variant of this – “non-qualifying submissions”, or something to that extent. However, this list very quickly gets long, obtuse, and hard to follow for hackers.

In an effort to help standardize this information and expectations, Bugcrowd has developed the Vulnerability Rating Taxonomy (VRT) that lists out all commonly submitted vulnerability types, and ranks them by their technical severity P1-5 – where P1 is a critical issue, and P5 is an informational, unrewarded finding type (thereby de-incentivizing P5s as non-qualifying issues at default). By having this definitive and documented list, it sets clear expectations for hackers around what they should and shouldn’t be submitting and removes the need for program owners to draft and update a lengthy and unwieldy list of findings they’re not interested in seeing. For this reason, it’s highly recommended that all programs follow the Bugcrowd VRT, which has the double-sided benefit of being advantageous for both program owners and researchers, while also simultaneously reducing clutter from the program brief.

Rewards

On our last post in this series, we spent a fair amount of time talking about rewards and the prioritization of findings. While we do recommend referring to that page for more detail, we’ll very quickly also cover some high-level information around rewards as a refresher.

1. We encourage all clients to offer cash rewards, as that’s the single best motivator for driving activity to your program. However, in offering rewards, it’s also imperative that those rewards match or exceed market value, so as to incentivize researchers to participate on your program.
2. All rewards should be linked to a clearly specified priority level on the program brief – where vulnerabilities that fall into a specific category are easily understood as being worth between X and Y dollars. This is made easy and simple by utilizing the VRT and setting designated reward ranges for each priority level.
3. Rewards will need to grow over time. It can be tempting to set-and-forget rewards on your program – but as time goes on and the low hanging fruit is knocked out, it’s important that we constantly re-evaluate and adjust the rewards to grow in line with your security maturity.

Disclosure + Rules

Finally, in building our program brief, it’s also important to ensure we include and clearly outline our policy on disclosure, as well as any supplemental rules/guidelines for participation. And while Bugcrowd believes public disclosure to be an important part of the vulnerability reporting ecosystem, and encourage our clients to work with hackers to disclose issues once a fix is released, we also understand, recognize, and support our customers’ customized/individual disclosure policies.

By default, on public vulnerability disclosure programs and bug bounty programs, the standard policy is coordinated vulnerability disclosure with the option to select non-disclosure. If you’d prefer a policy of non-disclosure on a public program, we’ll work with you to achieve your needs. For private bug bounty programs, private pre-launch VDPs, and for Next-Gen Pen programs, the default policy is non-disclosure with the option to select coordinated disclosure, if desired. In the absence of a clearly articulated disclosure policy, or if there’s ambiguity, we, as a platform, default to “ask first” for both the hacker submitting the vulnerability, as well as the program owner.

That said, coordinated disclosure has a number of marked benefits – namely: a) it allows other hackers to see and learn from the interesting and published work of other testers; b) it shows that your organization welcomes the reporting and submission of security issues, and works effectively with the security community to identify and remediate these findings; c) it shows a very proactive and advanced security posture for your organization – where you’re actually able to gain publicity for the quick, timely, and effective remediation of an issue that a researcher reported to your organization.

Lastly, once all the above points are complete and drafted, it’s worth a final/quick perusal of the brief we’ve created to consider your business’ unique use cases and any useful stipulations or considerations you want/need researchers to be aware of. The goal is to make sure researchers stay in line with your expectations as they’re testing. To help with this, it’s important to make sure to call out these points, so that all parties are on the same page going forward.

With all of the above having been covered, you should now have a pretty solid start for your program brief! Your Bugcrowd SA may have some additional suggestions prior to launch, but so long as you’ve got the above points covered, you have a  healthy start and a solid base to work off.

The post The Do’s and Don’ts of Writing Your Program Brief appeared first on Bugcrowd.

At Bugcrowd, we hear these questions time and time again – and want you to know that if you’re asking these same questions while setting up your crowdsourced security program, you’re certainly not alone. All of these points are natural and important considerations when getting started with crowdsourced security: what exactly is the going rate for vulnerabilities against certain target types? How much should a given vulnerability class be rewarded? And how much can one expect to spend on bounty rewards over the course of a year? In this blog, we’ll be looking to cover these very questions, and provide some best-practice guidance around rewards and ranges as they relate to running a crowdsourced security program.

Bugcrowd’s VRT

The good news is that it’s pretty easy to answer the question of how much a specific vulnerability class should be rewarded within the context of an existing reward range. Bugcrowd has made the segmentation of classes/priority remarkably simple and straightforward via our Vulnerability Rating Taxonomy (https://bugcrowd.com/vulnerability-rating-taxonomy), which has been developed (and continues to be expanded upon) over the course of running hundreds of programs. Through managing these programs, we’ve classified all the most common vulnerability types, and then rated them P1 through P5 – where P1s are critical issues (RCE, SQLi, etc), and P5s are informational (and commonly non-rewarded) findings. This being established by setting a reward range per P-level, we then can easily bucket any given finding into the applicable reward range for that vuln type.

By adhering to the VRT standard, it makes life easy for both you and the hackers – both groups have a standardized set of expectations for the rating of a given finding and subsequently rewarded. For instance, a researcher who finds a SQLi vulnerability can expect that it’ll get paid out in accordance to whatever the P1 schedule is – and the program owner also knows exactly what they’re expected to pay. Now the only question is how much those reward ranges should be…

Market Rate for Vulnerabilities

At the low end, the market-rate recommended range is $125-$2000 (we’ll cover other ranges later). In the example above, the guidance is that this P1 SQLi should be rewarded between $1750 and $2000. It’s important to note that the reason for using a range, and not a static value, is that often the value of a given finding (even at the same priority level), can vary substantially depending on the impact… e.g. what data is compromised? It’s also worth keeping in mind that this is simply a base level – and program owners are encouraged to both enumerate and reward bonuses for particularly valuable outcomes (e.g. became able to view credit card or PII info, etc).

This blog would be incomplete if we didn’t note that at this point, many first-time program owners tend to pause and feel a sense of aversion toward paying $2000 for a vulnerability. To be clear, $2000 is a lot of money, but if we take a moment to put things in perspective, this $2000 very quickly goes from feeling expensive, to one of the best deals on the planet. To get there, imagine you get publicly breached tomorrow by a P1 vulnerability (SQLi, RCE, etc), leaking a substantial amount of client and/or internal information on the web. Considering a world where this sort of debacle is instantly all over the news, does $2000 still seem like too much to pay for the ability of knowing about (and be able to patch) the critical issue before it happens? And it doesn’t even have to be a vulnerability on a critical piece of infrastructure – even moderate priority (e.g. P3) issues can cause brand or reputational damage when sensationalized in the media; making the relative cost via a bug seem like a remarkable deal – because it is.

This same exercise extends to more advanced/expensive reward ranges as well – in almost every case, the relative price of a bounty amount typically pales in comparison to the number of cycles and effort that public disclosures and incidents tend to incur. Furthermore, one incredible, yet often forgotten component of crowdsourced security, is that you only pay for valid findings – this means that regardless of what your rewards are, you’re only ever paying bounties for results. The only time you’ll ever be paying P1 prices is when you’re actually getting valid P1s, and if you’re getting P1s, then (as counter-intuitive as it sounds) that’s great – because you’re now more secure today than you were yesterday!

What About Reward Ranges?

Now that we’ve established what rewards should be given for what types/classes of vulnerabilities, the final question to cover is what reward ranges you should use for your specific program. The short answer is that it varies depending on your budget, types of targets, number of targets, the relative hardiness of said targets, and so on. While non-exhaustive, the following list details our recommended starting reward ranges and corresponding example target types:

$150-2,500 – Best for: untested web apps with simple credentialed access and no researcher restrictions — for any target with restrictions in place (e.g. you must own X product, or live in Y location), rewards should default to one range higher.

$200-4,500 – Best for: moderately tested web apps, untested APIs, untested mobile apps.

$250-6,500 – Best for: well-tested web apps, moderately tested APIs or mobile apps, presumed-to-be-vulnerable thick clients/binaries and/or embedded devices.

$300-10,000 – Best for: hardened web apps (e.g. banking, etc), well tested APIs or mobile apps, moderately secure thick clients/binaries and/or embedded devices.

$500-20,000+ – Best for: extremely well hardened and sensitive web apps, APIs, and mobile apps – as well as moderate-to-highly secured thick clients/binaries and/or hardened embedded devices.

Keeping in mind that while you may, when you first start your program, fall into the ‘untested’ bucket, it’s expected that after a few months (or in some cases longer), your program and targets will likely graduate to being a more heavily tested scope – meaning that along with your relative maturity, your rewards should advance as well (so as to match the increasing level of difficulty involved in finding a valid, unique issue).

It’s also further worth noting that many programs with large scopes tend to have multiple reward ranges that vary based on the target – e.g. targets XYZ are rewarded at one level (due to their hardiness and/or level of importance), while targets ABC are rewarded at a lower or higher level, and so on.

Finally, to put all of the above together – we come back to the question of how much one can expect to spend (and should thereby budget) for the first year of running a crowdsourced security program? The answer is that it varies. However, in an effort to provide some constructive advice, assuming a moderate attack surface and some degree of past security testing, $20k is a solid starting point for your program reward pool – keeping in mind that you may need to top that up before the year is over (if the scope is massive, you’ll likely need substantially more). If/when you need to top up your rewards, keep in mind that having to do so is a good thing – it means you’re getting findings, and valuable ones at that (at the base reward range, it’d take 160 P4s to exhaust your reward pool, so rest assured that if you’re spending that much, it’s highly unlikely it’s all on low priority findings).

All said, the rewards for a given program are completely dependent on your specific business needs and security maturity. But it’s critical to keep in mind that the key to a successful program remains the same: we want and need hackers to test and find vulnerabilities against our targets – and in order for that to happen, we have to attract the right hackers with the right incentives – making our program something they want (and choose) to test on.

For more information on reward ranges and budgeting for your crowdsourced security program, download Bugcrowd’s Defensive Vulnerability Pricing Model: https://www.bugcrowd.com/resource/bugcrowds-defensive-vulnerability-pricing-model/

The post Setting Up Your Program Reward Ranges appeared first on Bugcrowd.

Once the valid findings have been triaged by Bugcrowd, it’s now ready for you to do a final review and reward these reports as quickly as possible. The reason it’s important to be expedient is that the timely and meaningful acceptance and rewarding of findings is the single best way to show researchers exactly what they can expect from your program.

As a researcher, there’s no shortage of potential programs to participate in, and we want them to test on your program. But without having already made a submission and gone through the experience of interacting with the program owner, it’s not immediately clear to a researcher: a) how quickly will the program owner reward findings; b) if the rewards will be fair and consistent with what’s on the program brief; and c) if the program owner is truly invested and engaged in their program. These things in mind, it can be an apprehensive and unsure experience when first interacting with a new program – what if the program owner takes a month to reward or reply, pays poorly, and is overall not worth working with? Without being able to know this information up front, it’s entirely possible that one could invest hours or even days of work into a program, only to be greeted with a less than ideal experience. We want to make sure they very quickly know that won’t be the case with our program.

By responding and actioning findings quickly, fairly, and with empathy/understanding, we immediately set ourselves up as a program they can trust – and in doing so, become a program they’re far more likely to continue testing and investing effort on/into.

It’s critical to remember that there’s a person on the other end of the keyboard, who is just like you and me. They have a life, family, job, and enjoy feeling appreciated and respected. As long as you treat them with humanity, they’ll usually do so in return. Work WITH the researchers, and they’ll work with you – together, improving the security of your scope, as well as the internet as a whole.

To this end, we’ve created the acronym FRUIT, as a way to remember some of the core characteristics of an effective and engaged program owner. An effective and engaged program owner is:

Fair – Executing on the expectations set on the program brief, and rewarding researchers equitably for their effort. Remember that your bounty brief is essentially a contract between your organization and the security researchers – and it is ultimately your responsibility to ensure that the content accurately reflects the information and expectations you want to be conveyed to researchers.

Responsive – Rewarding findings in a timely fashion (ideally, never more than seven days), and quickly responding to any questions from Bugcrowd or the participating researchers. Lengthy response times jeopardize researcher goodwill and interest in continued participation. To help prevent any inadvertent delays, as noted in prior blogs as part of this same series, it’s helpful to make sure each person within your org knows and understands their expected role as part of the program, as well as having a secondary program owner to help ensure continuity if/when the primary is out.

Understanding – Recognizing that researchers are here to help – though it may not always feel like it, remember that they’re here to help you find vulnerabilities. Know that they’re well-intentioned, and treat them with the same respect that you would if they were an extension of your own team- because they are!

Invested – Doing what it takes to make a program successful – whether that means getting additional sets of credentials, increasing rewards, sharing changelogs, or increasing the program scope. Our most successful programs are led by deeply invested Program Owners. A further corollary to this point is to recognize and remember that we want researchers to find vulnerabilities! It’s easy to often feel like we should be restricting or limiting access/attack surface – when on the contrary, we should be creating an environment that is as conducive to testing as possible! Which often means being open to working with both researchers and your Account Team at Bugcrowd to gradually build out and work towards a comprehensive and all-encompassing scope.

Transparent – Being clear and honest with researchers. If you believe a finding should be downgraded, or simply something you don’t see as an issue, it’s important to offer a clear and detailed explanation to the researcher, so as to ensure that they’re aware of your point of view, so that they can either appropriately refocus their efforts, or allow for them to provide context that may not have been otherwise considered. This sort of open and transparent dialogue helps immensely in terms of building trust as well as genuine relationships that pay dividends over time. Befriending and establishing trust with a hacker who is finding great content on your program will often keep that researcher coming back well into the future – and in some cases, they may even someday come to work for you as well! Being transparent and honest with researchers is incredibly impactful, and when done right, is a boon to any program.

In short, if you can keep all of the above in mind when running your program, you’re well on the way to being an effective and engaged program owner – and of all the things that can impact program success, outside of access to the scope, your engagement is the single most powerful tool, and the single greatest indicator of as to the long term health and success of a program.

Armed with FRUIT, you’ll be a grape program owner!

The post Maintaining Program Success & Being an Effective Program Owner appeared first on Bugcrowd.

Scoping:

The absolute first thing to do when preparing to run a successful bounty program, is to make sure you have sufficient resources to allocate towards operating and maintaining the program, as well as getting internal buy-in from all the relevant stakeholders. This may not feel like it’s part of “scoping: in the technical sense, but it is a necessary and integral part of ensuring the long-term success of your program. Make sure you know, and everyone within your organization knows, who is responsible for which parts of the program (who validates, who remediates, who rewards, and so on).

Next, in terms of technical scoping, it’s important to get a full and accurate understanding of:

1. What your available attack surface is;
2. More specifically, your clearly defined scope for this engagement/program.

By understanding your scoped attack surface, you can more readily and thoroughly convey to researchers where to focus their efforts, as well as providing documentation that will enable them to be more successful. One of the great paradoxes to crowdsourced security is that we, somewhat counter-intuitively, want researchers to find and identify as many vulnerabilities as possible – and providing them with as many resources as we’re able is an important component to creating and driving that success.

Finally, as the last stop on the scoping path, we also need to ensure that we establish clear goals and objectives for the program and set expectations around what qualifies as a successful program. Once these parameters have been established, we’re ready to begin writing the program brief by documenting the targets, focus areas, salient information, and incentives.  

#ProTip: When writing your program brief, a good rule of thumb is to always review the document as if you were a researcher yourself. If you were offered this scope and these rewards, would you want to participate on this program? And does the program include all the relevant information you’d need to be successful? If the answer is ever anything less than an emphatic “yes”, then that’s a good indication that things could likely use some tweaking.

Implementing:

Once your program brief has been clearly and thoughtfully articulated (as well as having been stress tested), it’s important to spend some time on ensuring that once the program goes live, that things, as much as possible, go accordingly to plan. This includes setting up integrations (Jira, ServiceNow), building out workflows, creating templates, and so on. So that when a finding arrives there’s a process established for all involved parties.

Additionally, in terms of implementation, and something that is likely informed by the previously determined goals and objectives, it’s important to also determine how/where your program will live: will this be a public program that’s open to the world, or a private engagement that’s limited to a smaller subset of researchers? Is it intended to be a VDP, “if you see something, say something”, or is our goal to always have researchers consistently/actively testing the target? Depending on how we answer those questions, the format, content, and implementation of the program can vary fairly dramatically. But regardless of how and where, the most important thing to keep in mind here, is that everything works better when everyone is on the same page.

Identification of Findings:

Once our program is live, in almost every case, submissions will typically start rolling in almost immediately! Which, non-coincidentally, is why there’s so much emphasis on ensuring we’ve got a plan and process as early in the launch process as possible. Having established and formalized workflows allows us to act effectively and efficiently as soon as the program starts to see traction, which as noted above, can (and often does) happen very rapidly.

As with many things, how we start is of paramount importance, and no role is more critical in this phase of execution than that of the team (or individuals) who will be evaluating the findings as they arrive – performing, in the Bugcrowd vernacular, “triage and validation”. This first touch is core to building a sustained and meaningful relationship with researchers. At Bugcrowd, our ASE team performs this part of the equation – processing through all new submissions, and ensuring that anything triaged is valid, in-scope, not-a-duplicate, and has sufficient replication steps. However, it’s important to be aware that the work doesn’t stop here; there’s one additional step needed to accept a finding, and the most crucial one as far as researchers are concerned: rewarding the report at a level consistent with what was outlined on the program brief.

On the Bugcrowd platform, rewarding and accepting a finding is a fairly straightforward process and one that is made substantively less time consuming than it would be in the wild, largely thanks to the first-level work done by our ASE team to triage, etc. All that needs to be done is to review the priority of the finding, move it to an accepted state, and pay according to the rewards structure that was previously outlined in the scoping step. Once accepted and rewarded, the submission will follow your internal workflows to ensure it arrives at the desk of an engineer for remediation.

Remediation of Issues:

Once valid bugs are fed back into your development lifecycle and prioritized by criticality (and in relation to existing development workload), it is crucial to also work with the development team(s) to not only fix/remediate the bugs at hand, but also to ensure the same coding mistakes don’t happen in the future. To help here, Bugcrowd provides free remediation advice within the platform so you can work with your developers to understand, mitigate, and avoid introducing future security vulnerabilities into your product(s).

As a note, once the finding has been remediated, do be sure to advise the researcher of this, as many researchers will go back and re-test the finding, trying additional attack vectors, as well as helping to ensure there are no regressions, etc.

Learning + Iterating:

Because, as we mentioned at the start of this post, running a bounty program is continuous and ongoing process, it is further important that we consistently stay on top of our program to reassess results and outcomes as they apply to our goals and objectives, and then adjusting our program to meet these targets by increasing scope, advising researchers of changes and updates to the program as they happen, adding rewards, placing more researchers on the program, creating additional programs as needed, and so on.

Throughout this process with Bugcrowd, our Account Management and Program Operations teams will work collaboratively with you and your team, to provide experienced input and guidance along the way. Together, we’ll work to improve and grow both your program(s), as well as your overall security maturity as an organization – taking and applying the learnings from each step of the process, and then iterating onward and upward!

——

When launching a crowdsourced program, Bugcrowd helps you every step of the way.

The post Process For Launching Your Crowdsourced Security Program appeared first on Bugcrowd.

Security misconfiguration can stem from a very simple error, but at the same time can lead to devastating cyber attacks. The latest version of VRT for the first time includes specific security misconfiguration vulnerabilities for the automotive industry.

Today’s cars have all of the security issues of a modern data center, compounded by the rapid changes in the industry and the massive complexity of the technology infrastructure behind every car. For the automotive industry, we’ve seen nearly 10,000 vulnerability submissions over the past year, with an average priority of 2.58. Average payout for a P1 is $4,417. The automotive security misconfiguration updates to VRT 1.7 reflect the massive uptick in reported critical vulnerabilities and the importance the industry is placing on security.

Other Updates to VRT 1.7 include, but are not limited to:

• Added Sensitive Data Exposure > Weak Password Reset Implementation > Token Leakage via Host Header Poisoning as a new P2 variant, which is consistent with how this issue has been triaged by Bugcrowd’s Application Security Engineers so far.
• Two new P4s:
  • Insufficient Security Configurability > Weak 2FA Implementation > 2FA Secret Cannot be Rotated
  • Insufficient Security Configurability > Weak 2FA Implementation > 2FA Secret Remains Obtainable After 2FA is Enabled
• Updated Remediation Advice links to latest OWASP Documentation

We know that every company has different priorities and needs. Because of this, we work with our customers to help them define any potential deviations from our VRT as well as any other program brief customizations.

The VRT 1.7 update will be implemented into the Crowdcontrol platform the week of March 25th. Before then, if you are one of Bugcrowd’s customers, we suggest you review the VRT changes and your program brief to make any adjustment necessary.

What is the Vulnerability Rating Taxonomy (VRT)?

Created with consideration of common vulnerability standards such as the OWASP, the VRT is a living document that is constantly evolving to best provide a baseline priority rating system for vulnerabilities reported within our platform, Crowdcontrol. Our VRT Council consists of several members of the Bugcrowd team who meet each week to discuss vulnerability edge cases, improving vulnerability classification, and all external feedback from the official VRT GitHub repository. Open sourcing our VRT enables us to keep our ear to the ground, ensuring that the taxonomy aligns with the market.

At anytime, you can visit the changelog to keep up to date with a fully detailed list of changes made to the VRT. We also encourage you to follow our repository and contribute to it in any way you can.  

Managing the VRT as a living document has proven to be an effective strategy for us, as the security landscape is constantly evolving. We’d like to thank everyone involved in this project and are off to start work on even more improvements!

The post Bugcrowd Releases Vulnerability Rating Taxonomy 1.7 With New Automotive Security Misconfiguration appeared first on Bugcrowd.