Hey My name is Rami (not Rami Malek). I was hired from the crowd and now work to improve the crowdsource security experience, often working behind the scenes. I’ve always had a laser focus on community and continuous improvement from my experience as a professional photographer, pentester, hacker success manager, and everything in between. My unique perspective and determination from my various career paths led me to understand various needs and communicate them to the right people in the right way. Now a part of the Customer Success team, I hope this blog post helps you find the highest value engagement(s) for your organization’s needs. 

Factors to consider before deciding on your engagement type

• Scope: First, you must determine the size and complexity of your digital assets and their potential vulnerabilities. This assessment will help you identify which engagement aligns best with your requirements.
• Budget: Different engagements come with varying costs. Consider your organization’s financial capabilities and evaluate the potential return on investment in terms of enhanced security.
• In-house vs. outsourced: Determine whether you have the internal expertise to handle the chosen engagement or if you need to collaborate with external cybersecurity experts.
• Regulatory compliance: Ensure that the chosen engagement complies with any industry-specific or legal requirements your organization must adhere to.
• Risk tolerance: Assess your organization’s risk tolerance and how much you are willing to invest in proactive cybersecurity measures.

1. Managed bug bounty engagements (MBB):

Managed Bug Bounty engagements incentivize independent hackers to discover and report security vulnerabilities in an organization’s digital assets. Customers then set a tiered reward structure based on the severity and impact of the vulnerability identified in accordance with the Bugcrowd Vulnerability Rating Taxonomy. Once a vulnerability has been submitted by a hacker the Bugcrowd Security Operations team will triage, reproduce and assess the vulnerability. This process eliminates the signal to noise ratio ensuring you’re notified of new and unique findings. Bugcrowd offers MBBs in multiple flavors to meet your specific needs: 

• Time-based:
  • Ongoing engagements
  • On-Demand engagements
• Visibility:
  • Public engagements
  • Private engagements

Ongoing vs on-demand bug bounty engagements

Ongoing MBBs allow hackers to engage with the customer environment over an extended period of time. Ongoing MBBs allow hackers to deliver high impact vulnerabilities over time, which may otherwise not be found through traditional testing methods such as penetration testing Ongoing MBBs provide time and space for hackers and customers to build rapport and establish a level of trust. It’s not uncommon for hackers with strong rapport to exclusively hack on a single engagement/customer as a result of this. I like to call them ‘anchor hackers.’ Some anchor hackers have even been offered full-time jobs!

The benefits of running an ongoing MBB include:

• Impactful and ongoing testing
• Integrates into your long-term security posture
• Provides an ongoing level of assurance external from your security team
• Introduces new hackers over time

On-demand engagements offer two primary differentiators from ongoing programs. Their timeboxed nature provides a highly competitive and rewarding environment for hackers. They may be used to compliment ongoing engagements or to differentiate from them.

The benefits of running an on-demand MBB include:

• Time bound approach: On-demand engagements offer 2 or 4 week timeboxes, providing hackers with a highly competitive environment with increased rewards and unique scope.
• Set reward pool: Using a fixed reward pool ensures customers don’t go over-budget while ensuring hackers are appropriately compensated for their expertise. Customers typically use on-demand engagements as a first step towards the crowdsourced security space, or where they may have flexible spending that may not allow for an ongoing engagement just yet.
• Targeted scope: The highly competitive nature of on-demand engagements allow smaller groups of hackers to target areas with great concern. Successful on-demand engagements are often used to test new features, business-critical systems, and used as a warm up prior to releasing the assets to an existing on-going program.
• Pen testing use cases: They are increasingly used in pen testing use cases as well; in fact, we have customers who have completely replaced traditional pen tests with them.

Public vs private bug bounty engagements

There are two visibility options for MBB engagements, public and private.

Public bug bounty engagements are open to everyone. They’re often a best fit for large organizations with a security team equipped or even dedicated to hosting a bug bounty engagement. Your organization is most likely already quite secure and braced for attacks.

Benefits of public engagements:

• Largest form of exposure 
• Largest talent pool available
• Community engagement
• Showcases strong security posture

Considerations before launching a public engagement:

• Requires skilled team to manage
• Significant exposure 
• Increased noise

Invite only (or private) engagements are highly sought after due to their scarce nature. Hackers often look for large scope, high rewards, and low competition in private invites. The scarce nature leads to highly motivated hackers with more potential opportunity to identify vulnerabilities and gain rewards. Participation requires an invitation by Bugcrowd or your organization. The scope, rules, and rewards are shared with the invited hackers, but not with the general public.

Benefits of private engagements:

• Controlled testing
• Increased confidentiality
• Competitive activity
• Tailored to your needs as an organization
• Segregates different stakeholders and entities
• Introduces crowdsource security in a safer manner in your organization.

Considerations before launching a private engagement:

• Increased crowd management 
• Additional effort to manage compared to public programs 

Overall, managed bug bounty engagements are a great fit for small and large organizations across the globe. If one of the following applies to your organization, managed bug bounty engagements may be right for you:

• You have a large-scale attack surface
• You want to tap into the collective power of a global security community to find diverse and hidden vulnerabilities
• Your organization is able to offer financial rewards to ethical hackers for their discoveries

2. Vulnerability Disclosure Program (VDP):

Vulnerability Disclosure Programs (VDPs) are a “see something, say something” model, offering a public space to safely submit and disclose vulnerabilities to an organization. 

Unlike MBBs, they focus on encouraging responsible individuals to disclose security vulnerabilities directly to the organization with Safe Harbor. While most organizations welcome this information and behavior, the lack of a defined channel or process can carry risk, often disincentivizing people to report vulnerabilities. VDPs offer a comprehensive range of submission channels, triage, integration, and reporting capabilities.

When to choose a VDP:

• Your organization is ready to take their first step towards crowdsourced security
• You value transparency and open communication with hackers
• Regulatory/government mandates may require you to have one
• You want to promote responsible disclosure within the security community
• Your organization is ready to acknowledge and address security issues promptly

3. Penetration testing:

Penetration testing is a controlled and simulated cyberattack on a system, network, or application to identify weaknesses that could be exploited by malicious actors. Unlike bug bounty engagements, our crowd powered Pen Testing as a Service (PTaaS) is carried out by a large vetted pool of skilled hackers from the crowd. They simulate real-world attacks to assess vulnerabilities and provide a detailed report of their findings offering expertise unmatched by traditional pentesting services. According to your testing requirements, our specialized team and our agile processing can yield results in a matter of days. Throughout the testing phase, you will use the Bugcrowd Platform to gain access to real-time, prioritized findings, facilitating prompt remediation actions.

It’s common to see organizations pair their pentests with a bug bounty engagement to maximize risk reduction. 

When to choose penetration testing:

• Pay-for-effort in a time bound approach
• Leverage hackers with specialist skillsets and experience.
• Governance risk and compliance requirements
• Risk posture requires testing to be performed in a specific manner

4. Attack surface management

Bugcrowd’s Attack Surface Management (ASM) goes beyond traditional vulnerability assessments. Most hackers will tell you reconnaissance (recon) is arguably the most important step in the hacking process. Sw33tlie emphasizes recon over time in this blog post. Levering the power of the crowd, ASM combines technology, data, and hacker ingenuity to discover all digital assets (even the hidden ones) within an organization’s ecosystem. By identifying rogue assets, it helps your organization evaluate risk, inventory known assets, and prioritize remediation efforts. It offers a comprehensive approach to managing an organization’s attack surface continuously.

When to choose attack surface management:

• You want a holistic view of your organization’s cybersecurity posture, including forgotten, rogue, or unknown assets.
• You want to discover assets, not exploit them.
• You have a rapidly evolving organization with a complex attack surface to manage.
• You need a solution to help you continuously discover, prioritize, and mitigate risks associated with your assets.

The world of crowdsourced security can be confusing, but by carefully evaluating the options and understanding your organization’s specific needs and priorities, you can make an informed decision that aligns perfectly with your cybersecurity goals.

Thanks for taking the time to read my blog post. If you’re still hungry for more, you can learn about the role of our TCSM team in continuing your success with crowdsourced security, written by my good friend Elle. 

You can find me on Twitter, and LinkedIn. I’d love to hear from you!

The post Demystifying crowdsourced security: How to choose the right engagement for your organization appeared first on Bugcrowd.

For that reason, data science and infrastructure have always been, and will always be, a major area for R&D investments. One such investment is in knowledge graph technology, as a foundation for the rich data models that power the AI in our platform.

So, we thought it would be helpful to provide some details about how this all works.

What is a “knowledge graph?”

In data science, knowledge graphs represent relationships between data entities (e.g., people, places, and things) that often turn out to be insightful and unexpected. A knowledge graph comprises nodes, edges, and labels, with material or abstract things (e.g., people, places, or concepts) serving as nodes, edges connecting those nodes, and labels defining the relationships that create those connections. These data structures are stored and managed in specialized data stores called graph databases.

Here’s a visualization of a typical knowledge graph:

How do Bugcrowd Platform users benefit from knowledge graphs?

Knowledge graphs are a powerful tool for representing data entities and expressing relationships. For Bugcrowd—which has collected millions of data points over the past decade about vulnerabilities, attack surface/assets, remediation, and hacker skills and performance—they are ideal for understanding relationships between vulnerabilities and assets, vulnerabilities and skills, skills and hacker profiles, and every other permutation you can imagine. We call the data models that collectively reflect our platform’s entire historical dataset the Bugcrowd Security Knowledge Graph.

The Security Knowledge Graph powers data-driven outcomes that create long-term success for hackers and customers alike—including crowd matching, engineered triage, rich reporting and analytics, and recommendations. As the graph grows, the value delivered from those outcomes grows along with it. 

How does CrowdMatch utilize the Security Knowledge Graph?

For example, CrowdMatch AI, the technology in the platform that matches hackers and pentesters to customer engagements, is a key application of our Security Knowledge Graph. The “hacker matching” AI algorithm inside CrowdMatch evaluates the entire portfolio of a hacker’s performance and experiences on the Bugcrowd Platform, including: 

• Points and rewards earned
• Skills
• Report volume
• Report and communication quality
• Testing accuracy
• Depth of testing
• Aggregate report impact 

This algorithm also continually updates its assessments based on new information. The algorithm then intelligently curates and optimizes a hacker team to an engagement’s specific needs across 100s of dimensions.

For more details about how this all works, take this 5-minute, interactive tour:

We hope you’ve learned something new about knowledge graphs, their value for crowdsourced cybersecurity, and their key role in long-term hacker and customer success on our platform!

The post Get to know the Bugcrowd Security Knowledge Graph appeared first on Bugcrowd.

These sightings have me thinking about a phrase we’ve said here at Bugcrowd for almost a decade now—”the unlikely romance between hackers and security teams.” We’ve been talking about this surprising dynamic for years, and as the CISO at Bugcrowd, I’d like to share my thoughts specifically on the relationship between hackers and CISOs/security leaders. 

What exactly does an “unlikely romance” mean? 

To truly understand this “unlikely romance,” you first need to understand what I mean when I say “hacker.” Defining a hacker is harder than one might think. Most people probably consider a hacker and a cybercriminal to be one in the same. Merriam-Webster defines a hacker as “an expert at programming and solving problems with a computer.” That doesn’t sound like a cybercriminal, does it? 

“Hacker” is the dominant self-descriptor used by the cybersecurity community to refer to “the good guys.” Other terms you may have heard include ethical hackers, white hat hackers, and security researchers. The confusing part is threat actors, aka “the bad guys,” also call themselves hackers. For my purposes in this blog (and the rule of thumb at Bugcrowd), when I say “hackers,” I’m talking about the good guys. 

There is so much misinformation out there about the hacking community. Long-standing stereotypes of faceless criminals in hoodies come from pop-culture depictions. These stereotypes lead to assumptions that CISOs are actively fighting against hackers. This is where the concept of an “unlikely romance” really comes into play. People expect CISOs and hackers to be working against each other, not together for the greater good. 

Hackers + CISOs = ? 

Some of the challenges security leaders are facing may feel like old news, but that doesn’t make them any less relevant to our strategic initiatives. For example, the cybersecurity skills gap has been the subject of many articles, yet it is still a major struggle for security teams around the world. ISC2’s recent study found that the cybersecurity skills gap grew 12.6% last year, even though the cybersecurity workforce grew by 8.7%. 

Pair this with the fact that the attack surface is always evolving, it really creates a perfect storm. There is always the next “big threat” looming—for example, right now, it’s AI threats. CISOs simply don’t have the time or resources to constantly adapt to prepare for what’s next while still dealing with the pressure that comes from an under-staffed team. 

I’m speaking with a lot of fellow CISOs at the moment who are looking to counter this challenge and the cybersecurity skills gap and help their security teams scale by broadly adopting the crowdsourcing of human intelligence via the hacker community. Partnering with hackers helps continuously weed out unique or previously unidentified vulnerabilities that their internal offensive security teams cannot—not just from a technical point of view, but also from time to scale-up or go deep in “breaking” new technology perspectives. 

CISOs should be partnering with hackers to extend the reach of their security teams and proactively secure their attack surface or find that hidden “golden nugget” of a bug. This partnership can be achieved at scale through a trusted crowdsourced security vendor. 

One statistic from Inside the Mind of a Hacker that really shatters hacker stereotypes is the fact that 77% of hackers report working in IT or cybersecurity full time. That’s right—over three quarters of hackers work in traditional IT or cybersecurity roles. Chances are, you probably have someone on your security team right now who hacks on the side on the Bugcrowd Platform. 

In my personal view, partnering with hackers does not increase operational risk; instead, it only decreases risk, as it enables the earlier identification of vulnerabilities harvested by experts in the security community before attackers can discover and exploit them.

Building a relationship that can go the distance

We’ve established the need to work with hackers via crowdsourced security models, but how do CISOs:

1. Find the right hackers to work with
2. Develop long-lasting, mutually beneficial relationships with hackers

To extend the Valentine’s Day/unlikely romance theme, they say there are a lot of fish in the sea, but most people aren’t looking for all of the fish…they’re looking for the right fish. 

It’s the same with hackers. Some crowdsourced security companies throw bodies at the problem, thinking a higher quantity brings better results. That’s not exactly true. You want to look for quality in the hackers you partner with, not quantity. 

To do this, leverage a company like Bugcrowd that expertly pairs organizations with hackers based on skill sets, target types, and precisely the right experience. For example, Inside the Mind of a Hacker found that 70% of hackers identify web applications as their area of hacking specialization. By nature of that fact, three quarters of hackers other vendors pair your organization with would have that specialty…but what if you’re looking for network pen testing or recon/asset discovery? Blindly throwing bodies at a problem is just going to create noise and not give you the best solution. You need the right hackers with the right skill sets for your specific situation. 

By the way, if you’re still on the fence about working with hackers, you can always take a crawl, walk, run approach. By leveraging a select number of curated hackers with small-scope proof of value (POV), CISOs can safely and effectively mitigate the perceived risk of crowdsourced security. Running this POV gives a CISO’s team familiarity with the platform, triage services, and customer success capabilities. As CISOs become more accustomed to the crowdsourced model, they are likely to go wider and deeper— sometimes straight to a public program to glean the ultimate benefits from a bigger, more diverse community of hackers.

Going back to my second point, it isn’t just about finding the right hackers, it’s also about nurturing good relationships with them. By investing in your organization’s relationship with the hacker community, you’ll foster goodwill, more continuous testing, and attract more hackers to your programs. 

Ways to foster these relationships include responding to hacker submissions quickly, investing in a crowdsourced security platform with excellent triage capabilities, and offering program rewards within market ranges. 

How Bugcrowd can help

Crowdsourced security platforms like Bugcrowd make the unlikely romance between hackers and CISOs possible. By leveraging penetration testing as a service, vulnerability disclosure programs, and managed bug bounty programs, CISOs can expand their team’s reach, partnering with the hacker community as an extension of their team. 

The post The Unlikely Romance Between Hackers and CISOs appeared first on Bugcrowd.

Over time, the attack surface and submissions associated with the VRT evolve, as do the needs of hackers and customers – so the VRT needs to grow and change, too. In that spirit, we are pleased to announce the latest release, VRT version 1.11, will be rolling out on the Bugcrowd Platform and reflected in our submission form shortly.

Overview of changes

This release includes several updates. As you can see below, they reflect changes to the threat environment, and how hackers, customers, and the Bugcrowd triage team view certain vuln classes and their relative impacts differently than before. 

New Top-Level Category: Cryptographic Weaknesses
A new category has been added to cover all common flaws in the cryptography area. This approach will help guide hackers when submitting a report about a specific weakness – such as insufficient entropy, predictable PRNG or IV, missing cryptography steps, timing attacks, or insufficient key stretching, to name just a few.

Multiple Category Updates: Insecure Direct Object Reference (IDOR)
This category has been a bit of a thorn in the side of hackers for a while now as a single IDOR category with the priority of ‘Varies’ can be frustrating especially when the finding has proven demonstrated impact. Additionally, with a lack of default priority, it could mean a program owner is more exposed than they should be, compared to if it were a P1.

Therefore, we’ve added several specific variants to the category:

• P1 – Read Personal Data (PII) – Iterable Object Identifiers
• P2 – Modify/Delete Sensitive Data – Iterable Object Identifiers
• P2 – Read Personal Data (PII) – GUID/Complex Object Identifiers
• P3 – Modify/Delete Sensitive Data – GUID/Complex Object Identifiers
• P4 – Read Sensitive Data – GUID/Complex Object Identifiers
• P5 – Read Non-Sensitive Information

This change should cover most common IDOR cases. However, hackers who find something that isn’t in these specific variants can always select the top-level category and appropriate adjustments will be made by our triage team.

New Variant: HTML Injection
The existing P4 ‘Email HTML Injection’ variant receives a lot of false-positive submissions from hackers submitting HTML injection in a web application. We did a lot of research on this category, reviewing the outcomes from the P4 false positives and how many led to accepted submissions and resulted in fixes. The answer was: not very many. As a result, the new category for these is considered P5, and you’ll find it under the existing ‘Content Spoofing’ specific vulnerability name. We’ll update existing submissions under the old P4 variant to the new P5 one, accordingly.

Update To Existing Category: Server-Side Request Forgery (SSRF) – External
We reviewed a number of SSRF findings across the existing P4 variant ‘External – Low Impact’. Most of these submissions are not accepted by customers, as they typically arise from intended functionality such as a webhook or image download. As a result, we have moved this category to the P5 level. 

New Specific Vulnerability: HTTP Request Smuggling
Thanks to amazing work by James Kettle at PortSwigger, this category has been revitalized across the internet. We see this vulnerability reported on a daily basis, but more often than not, it has low impact – so, we’re introducing it at the ‘Varies’ priority level in the ‘Server Security Misconfiguration’ category. The triage team will adjust affected submissions as needed.

New Specific Vulnerability: LDAP Injection
While certainly not the most reported vulnerability we see, LDAP Injection was a conspicuous omission in previous versions of VRT. We’ve remedied that by adding it to the ‘Server Side Injection’ category. 

Modified Specific Vulnerability: PII Leakage
The existing ‘PII Leakage’ category is commonly misused, with many hackers simply searching for ‘PII’ in the VRT selection box and selecting this category regardless of whether the specific vulnerability is related to automotive security. As a result, the existing category under ‘Automotive Security Misconfiguration – Infotainment’ has been changed from ‘PII Leakage’ to ‘Sensitive Data Leakage/Exposure’, retaining its usability for automotive submissions specifically.

A new vulnerability called ‘PII Leakage/Exposure’ with the default priority of ‘Varies’ has also been added to the category ‘Sensitive Data Exposure’. We believe that a ‘Varies’ priority is important here because not all instances of PII – a single email address in an AEM response, for example – are a P1 by default. However, the triage team will adjust submissions to a P1 as needed.

Deprecated Specific Vulnerabilities and Variants
‘Existing P4 Cross-Site Scripting IE-Only / IE11’ has been removed and the existing P5 category ‘Cross-Site Scripting – IE Only < IE11’ modified to cover all versions of IE. These changes have been pending for some time due to Microsoft retiring Internet Explorer version 11 in 2022.

New Specific Vulnerability: On Permission Change
This vuln is documented by OWASP and other sources, but is also very use case specific. To support these customer use cases, we’ve added it to the ‘Failure to Invalidate Session’ variant of ‘Broken Authentication and Session Management.’

This is a healthy, albeit not major, update to the VRT with contributions from hackers in the Bugcrowd community, our triage team, and our customers. There is still more work to be done, so you’ll soon be hearing from us again very soon about additional changes that reflect the evolving environment.

Why contribute to the VRT?

As we said in the introduction, an open-source governance model helps the VRT evolve at a pace and in concert with the changing environment – but that only happens if hackers and customers actively participate in the process. Contributions to the repository are reviewed by the VRT Council, which meets regularly to discuss new vulnerabilities, edge cases for existing vulnerabilities, priority-level adjustments, and general validation experiences. When the team comes to a consensus regarding a proposed change, it is committed to the master.

If you would like to contribute to the VRT, Issues and Pull Requests are most welcome!

The post Announcing Our Latest Vulnerability Rating Taxonomy Update appeared first on Bugcrowd.

As a new milestone in that effort, we are thrilled to introduce a groundbreaking, industry-first platform feature: Request a Response. This new feature offers an additional channel for hackers to engage with Bugcrowd triagers and customers, with a response ensured within 48-96 hours depending on the type of request. 

As a result, hackers will enjoy improved communication, increased transparency, and most importantly, more time dedicated to hacking–and to earning rewards. For Bugcrowd customers, Request a Response enables faster access to insights from hackers, when decisions about payments or other submission details would benefit from their feedback.

The Old Standard is Out

Unread comments are frustrating, to say the least. In the crowdsourcing space, it’s common for hackers post comments or questions that need to be addressed on their submissions, but for various reasons, the comment will not receive a response for an unacceptably long period of time–or get no response at all, in some cases. 

So, the industry standard has long been: submit a bug, wait for a response, leave a comment while awaiting response, comment goes seemingly unread, reach out to support, and eventually, reach a resolution only after much missed or absent communication. 

This cycle of miscommunication leads to confusion and frustration for everyone involved. Hackers are left wondering about the state of a particular submission and when they can expect movement–and their time, resources, and energy take a hit. 

Request a Response is Here to Deliver, and Here’s How

To solve this problem, Request a Response will help standardize communication between hackers, customers, and Bugcrowd staff. It allows hackers to directly request additional information, or ask a question to Bugcrowd employees and customers. A request triggers specific workflows, notifications, and alert actions to Bugcrowd and customers, who will then address the request within 48-96 hours. For status updates, hackers receive in-platform and email notifications as their request is addressed. 

Communication gaps have been the norm for far too long, and we’re determined to close them. With Request a Response, communication between hackers, Bugcrowd, and customers is streamlined and smooth.

Here’s what our beta testers had to say:

What You Can Expect

Our goal is to make this process as simple and predictable as possible. That leads to clear, reliable communication pathways and timelines. 

With this new standard set by Bugcrowd, hackers can request a response from Bugcrowd across seven different categories:

• Issue is Reproducible
• Scope
• Duplicate State
• Reward
• Priority
• Requesting Update
• Other

For responses from customers, two types of requests are available: Requesting Update and Other.

Additionally, hackers can provide details about their request to help Bugcrowd staff and customers properly triage and respond to them.

Plus, hackers can use this feature for these different submission substates:

• Triage
• Unresolved
• Resolved
• Out of Scope
• Not Reproducible
• Not Applicable (Bugcrowd only)

This feature is available to the Crowd across our engagements, so hackers and customers can submit a request and receive a quick response, saving time and stress.

The New Standard is Here

Ask questions, get a response: It’s as simple as that. Historically, succinct and predictable communication between hackers, platforms, and customers has been poor, messy, and frustrating. With Request a Response, you can expect clear communication timelines and guaranteed responses. 

For more information on Request a Response or any other Bugcrowd feature, please refer to our Researcher Documentation. Follow along as we continue to expand our platform features by following us on Twitter and Instagram, and don’t forget to join us on Discord and the Bugcrowd Forum. Sign up for a researcher account today to start your hacking journey!

The post Introducing Request a Response: A new standard for hacker and customer response time appeared first on Bugcrowd.

Now, we’re taking our PTaaS vision one step further: Starting immediately, you can buy, configure, launch, and see real-time results from a human-driven Bugcrowd Standard Pen Test–with a pentester team matched to your precise needs–via a few clicks. No more sales calls, scoping calls, and other backs-and-forths that delay your pen test launch. Instead, thanks to new capabilities in our platform, you’ll cut setup time from days to hours, start seeing prioritized findings in a rich Pen Test Dashboard fast, and get a final report within days of test completion. That’s how pen testing should work!

To give you a flavor of how easy this is, we’ve captured a couple steps in the brief demo below:

The Need for Standards

Why have we taken up this mission? Because everyone in the industry knows that the penetration testing experience for buyers and pentesters alike needs an upgrade. Traditional penetration testing has roots in consulting, so buying, scoping, sourcing pentesters, and report delivery depend on numerous manual, ad hoc interactions that delay what everyone wants: results. Too often, other PTaaS providers rely on automated, low-impact testing to streamline this process, while leaving the procurement and setup process largely manual–giving buyers the worst of both worlds.

Instead, we believe the solution to this problem is to standardize how human-driven, high-impact pen testing is delivered for common asset types, just like the construction industry adopted standards to make it faster and easier to build things at scale. That standardization is what makes it possible for us to orchestrate the setup process in software, for customers to buy Bugcrowd Standard pen tests in three sizes for external web apps or networks (with access to exactly the right pentester skills), and to easily organize and manage multiple pen tests in groups. Our platform’s unique ability to crowd-source the right pentesters for the job (CrowdMatch^TM) based on data, and rotate them on demand, is special value in the bargain.

Clear Choices

So what does this development mean for the pen testing industry? The way we see it, the choices are clearer than ever:

With this announcement, we’ve transformed the pen test experience from procurement through report delivery, but we won’t stop there. In the future, we’ll expand the types of pen tests that can be purchased and set up online and make it even easier to clone, organize, and manage pen tests and other programs on our platform.

In the meantime, buy and set up a Bugcrowd Standard Pen Test that’s “just right” for your external web app or network with just a few clicks! And if you’re attending RSA Conference in San Francisco next week (April 24-27), visit us at Booth #2438 or schedule a 1:1 to learn more. Read more about our Pen Testing as a Service announcement here. 

The post Standard Pen Tests Are Now Just A Few Clicks Away appeared first on Bugcrowd.

The Bugcrowd Platform also provides out of the box capabilities for the most popular workflows and use cases. Some of these include inbound integrations with SDLC tooling such as Atlassian Jira or IBM SOAR. To address outbound needs, Bugcrowd offers notifications on important events via email or on the web. As these use cases grow in sophistication, we’ve enhanced Bugcrowd Platform Notifications with two additional settings.

First, you can now be notified on submissions assigned any severity. For example, “Notify me when a P1 is submitted” is one of the most popular features requested by customers. With this setting, customers are notified of the issue immediately, even before triage. This allows you to take action on the finding immediately if the submission is in fact a true positive. Of course, you will still be notified once the submission is triaged by the Bugcrowd team. 

Second, you can now set up notifications for multiple submission states where you’ll be notified for all submissions that reach the specified state in the Bugcrowd Platform. As an example, you can be notified any time a submission reaches the “Triaged” state, and when it reaches the “Unresolved” state (accepted by a team member).

Both of these settings are now generally available in the Bugcrowd Platform. For more details, see the docs here.

The post Configuring Notifications for P1 Response in the Bugcrowd Platform appeared first on Bugcrowd.

In 2022, Bugcrowd Security Knowledge Platform introduced a new platform feature, the Industry Versus Organization Comparison Report, to allow customers to benchmark the performance of their program against industry peers for augmenting or improving the overall performance of their program. Today, we’re announcing additional security benchmarking capabilities in the report: giving customers the ability to benchmark the performance of their program against different industry peers, and adding new performance metrics, as well.

We understand that customers have dynamic, complex businesses and need to benchmark against different industries to fully understand the performance of their program. So, we’re giving customers the ability to select up to three industries to compare against at a time.

We have also added four additional charts for Payout comparison for P1 through P4 submissions to help our customers understand how they compare in payouts versus their peers in different industries. Having that data should help them become more competitive for researcher attention and attract more researchers to their program.

The post Announcing Enhancements to Industry Comparison Reports in the Bugcrowd Platform appeared first on Bugcrowd.

As the use of GPT-based chatbots, such as OpenAI’s GPT-3 and GPT-2, becomes more widespread, there is an increasing risk that malicious hackers may use these powerful language models for their own nefarious purposes.

One potential way that hackers could use GPT-based chatbots is by using them to impersonate a trusted entity in order to gain access to sensitive information. For example, a hacker could train a GPT-based chatbot to impersonate a customer service representative from a bank or other financial institution, and use this chatbot to trick people into providing their personal information, such as their login credentials or credit card numbers.

Another way that hackers could use GPT-based chatbots is by using them to generate convincing phishing emails or text messages. These messages could be designed to trick people into clicking on a link that would then install malware on their devices, or to steal their personal information.

Additionally, GPT-based chatbots could be used to conduct “social engineering” attacks, by creating compelling and tailored messages to scam individuals or organizations, since chatbots can generate highly specific and convincing text.

It’s also possible for GPT-based chatbots to be used for spreading misinformation and propaganda at scale, by automating the process of creating fake news and misleading narratives on social media.

It is important to note that the technology behind GPT-based chatbots, like any other AI tool, is neutral and can be used for both good and bad purposes, but the potential malicious use cases outlined above are a reminder that as with any new technology, it’s important to be aware of the potential risks and take steps to mitigate them.

For individuals and organizations, it is important to be aware of these potential dangers and to take steps to protect themselves, such as being wary of unexpected messages or emails, and verifying the identity of any person or organization that requests personal or sensitive information. Additionally, developers should design and implement security measures to detect and prevent malicious use of GPT-based chatbots.

As GPT-based chatbots become more advanced and widely adopted, it will be important for the broader technology community to come together to address these risks and to ensure that this powerful technology is used for the betterment of society rather than for harm.

ChatGPT is the consummate example of how emerging threats continually challenge security tools and techniques that were never designed to handle them. Only the global security researcher/hacker community provides human ingenuity at scale to recognize and counter new attack vectors as they appear!

The post Will GPT-Based Chatbots Become A Thing For Malicious Hackers? appeared first on Bugcrowd.

Massive growth in mobile applications, web apps (cloud-based and on-premises), IoT devices, APIs, cloud infra, and other assets continues to complicate the attack surface, especially for smaller companies that historically have had less to worry about in this area than enterprises. Orgs of all sizes are exposed now: In 2021, nearly 80 percent of observed threat groups targeting mid-sized companies, and more than 40 percent of observed malware, had never been seen before.

Source: McKinsey & Co.

The regulatory environment is also driving the need for more solutions: Within the United States alone, there are currently hundreds of state bills or resolutions that seek to regulate cybersecurity and data privacy, and the US Securities and Exchange Commission (SEC) has proposed new federal-level rules about breach notifications. In Europe, the environment is arguably even tougher thanks to GDPR, and NIS2 looms in the distance after recent adoption by the European Parliament. Globally, compliance-driven customer requirements will only grow.

With these strong market forces, you’d probably predict that the gap between spend and opportunity is fairly minimal–but you’d be wrong. In reality, the gap between actual spend ($150 billion in 2021) and market opportunity ($2 trillion) is glaring. According to McKinsey, that gap is both a failure and an opportunity:

“Such a massive delta requires providers and investors to “unlock” more impact with customers by better meeting the needs of underserved segments, continuously improving technology, and reducing complexity—and the current buyer climate may pose a unique moment in time for innovation in the cybersecurity industry.”

In other words, the delta exists because the cybersecurity industry has produced too many solutions that fail to scale up or down, add anything interesting to the technology conversation, and/or reduce complexity or noise. Cybersecurity buyers are crying out for a better approach to reducing risk, and that dissatisfaction is reflected in shallow market penetration by vendors.

Those buyers are also trapped in a deep and seemingly permanent talent crisis, which makes solutions that can help them meet their security goals in spite of that trap extremely timely. 

The Platform Shows the Way

At Bugcrowd, that innovation referenced by MicKinsey takes the form of a Security Knowledge Platform that brings the power of the global security researcher community to penetration testing and other security workflows in a scalable, highly engineered way, removing noise and adding contextual intelligence derived from 1000s of other customer experiences. The result is a unique ability to continuously discover and remediate hidden vulnerabilities that put you at risk of being blind-sided by cyber attacks–while providing a foundation for future applications of crowdsourcing to security.

Contact us to learn more!

The post Are Cybersecurity Investments Recession-proof? appeared first on Bugcrowd.