This blog is provided by Software Secured, an Eden Data penetration testing partner.

This is Part 2 of 2 in this series, view Part 1: Differentiating a Bug Bounty vs. a Penetration Test

Growing SaaS firms are experiencing an increased demand for Responsible Ethical Disclosure policies and practices to meet compliance requirements and manage their security posture. In 2019, 45% of North American SaaS companies with revenue between 1 - 100M were SOC 2 compliant. Having a policy outlining its commitment to data security aligns these firms with SOC 2 criteria (CC2.2 and CC5.3); however putting the practice into reality is a challenge, especially for startups and scaleups, with limited internal security resources.

What is Responsible Ethical Disclosure

Responsible Ethical Disclosure policies drive Bug Bounty programs; allowing ethical security researchers to responsibly disclose vulnerabilities found within the company's application or environment, for a predetermined price per vulnerability. Compliance frameworks such as SOC 2 don’t require a company to have a Bug Bounty program, but any company under the framework does require a Responsible Ethical Disclosure policy. Companies without a Bug Bounty program, aligned with compliance frameworks like SOC 2 will still have a Responsible Ethical Disclosure Policy and a process that includes these steps:

1. The security researcher must notify the security team via the email or other contact information on the Bug Bounty / Responsible Ethical Disclosure policy web page
2. All known information on the found vulnerability must be provided, in a legible report 
3. Screenshots, steps to reproduce, impact, and other information about the vulnerability type should be included
4. The security researcher must responsibly disclose the vulnerabilities found (without harming the company’s systems, reputation or client data) in order to receive payment. 

‍

Why Responsible Ethical Disclosures have become so important

Threat of irresponsible disclosure

Irresponsible disclosure involves the security researcher disclosing vulnerabilities to the public before the company directly. Hacking that involves irresponsible disclosure, exploiting the vulnerability, or attempting to monetize the vulnerability outside of a Bug Bounty program is not considered ethical. Such actions demonstrate varying degrees of malicious intent and are not aligned with the best practices of Bug Bounty programs or Responsible Ethical Disclosure practices. They could also require a company to engage in legal action against the security researcher.

Value of Bug Bounty markets

The average payout for bug bounties increased from $6,443 in 2021 to $26,728 in 2022. With the increasing importance of mature cybersecurity for growing SaaS firms, it is no surprise that the increase in Bug Bounty program rewards have incentivized ethical and unethical security researchers. Highly regulated industries such as healthcare, fintech and security are exceptionally vulnerable, as the information within their applications/environment often lead to a bigger payout, due to the larger repercussions of a data breach for companies within these industries. But, as the number of ethical security researchers and Bug Bounty programs continues to grow, there is also an increase in the number of unethical security researchers conducting security testing without the company's permission.

This leaves companies without a Bug Bounty program in a vulnerable position, as many still find themselves being contacted about vulnerabilities found within their application or environment. Any organization that does not have a way of continuously and actively finding vulnerabilities can consider various options, such as creating a Bug Bounty program or penetration testing. Penetration testing is a great alternative to bug bounties, as you are working together with the penetration testing vendor, instead of being in the dark until a vulnerability is found in Bug Bounty programs. 

So, what are the next steps for a company without a Bug Bounty program, that has received an email regarding vulnerabilities found within their application or environment?

Steps to respond to Responsible Ethical Disclosures

Verify the sender

Once you have received an email from the security researcher, there are a few ways to verify the credibility of the source. 

• Is this person a real security researcher? 
• Does the email being used contain their name, a company, or any information that can help identify their credentials?
• Have they conducted bug bounties in the past, how credible are they and their reports? 
• Is their past work searchable?

Verify the vulnerability

There are various aspects of the vulnerability to examine to determine if the severity is valid and if the vulnerability is applicable.

• Can they provide more details about the vulnerability? 
• What system or application is affected?
• What is the potential impact of this vulnerability if it were exploited?
• Can they provide step-by-step instructions to reproduce the issue?
• Have they successfully exploited this vulnerability?
• Have they disclosed this vulnerability to any other party?
• Are there any specific configurations or conditions that need to be met in order to exploit this vulnerability?
• Can they provide any evidence or documentation to support their claims?
• Are there any known instances of this vulnerability being exploited in the wild?
  

Verify with a third party

Now that you have determined the credibility of the vulnerability and the sender, it is worthwhile getting another opinion from a trusted security professional. This can be internally with your security team, or by a third-party security professional team that specializes in penetration testing or scaling security programs. 

Determine scope, SLAs and parameters 

If compliance such as SOC 2 or ISO27001 is driving your Responsible Ethical Disclosure policy and how you handle bug bounties, then the scope must include the apps and network in scope for your audit. Freemium applications and the corporate website are concerns from a reputational and financial point of view as well as a security risk, whether or not they are hosted in the same environment as the apps in scope for compliance. Many organizations begin with the applications in scope for their audit and gradually improve their security posture over time by  extending their Responsible Ethical Disclosure policy to their entire attack surface.

Service level agreements (SLAs) should be custom to your organization, and reflect the amount of sensitive data that could be exposed in a cyber attack. In some organizations, the SLAs are purely driven by clients contracts or compliance mandates, therefore SLAs for Bug Bounty follow those requirements. A 5 day window to respond to the security researcher is a good place to start and 15 days for a critical, 30 days for a high, 90 days for a medium and 180 days for a low severity vulnerability to patch it before the security researcher can go live with a report about the successful find. If your team is still working out which SLAs make sense for your Vulnerability Management Policy, check out a best practice outlined by CVSS that our partner Software Secured uses in penetration testing, or speak to a security consulting company such as Eden Data. 

Return to step Verify the Vulnerability for specific parameters you can set for ethical security researchers. 

Respond to the security researcher (Bonus: sample templated response)

Now that the sender and vulnerability have been verified, it’s time to put your Responsible Ethical Disclosure Policy into practice. 

A sample templated response if you do not have a Bug Bounty Program:

Hi (ethical security researcher’s name), 
Thanks for this. (Company name) is committed to working with the broader community of security professionals to continue improving our security posture.
We conduct regular penetration testing on all applications and infrastructure in scope for our Responsible Ethical Disclosure Program with a trusted vendor.
At this time we do not run a Bug Bounty program and therefore are not in a position to provide financial compensation. 
Thanks for your understanding.

(Name)

A sample templated response if you are building a Bug Bounty Program:

Hi (ethical security researcher’s name), 
Thanks for this. (Company name) is committed to working with the broader community of security professionals to continue improving our security posture.
Given the severity of this vulnerability and the data we protect, we are able to provide a financial reward of x. I’ve cc’d our financial team to discuss next steps for payment.  
Thanks for your assistance.

(Name)

Payout per vulnerability

After remediation efforts have been completed, the next step is to determine possible payouts for the vulnerabilities. If an organization hasn’t publicized a price on finding vulnerabilities because they do not have a Bug Bounty program, you can consult companies like Eden Data to help navigate this decision. Ranges of pay for vulnerabilities are dependent on the severity, and the sensitivity of the data being exposed. For example, if a company is in a highly regulated industry such as healthcare, security or financial services they can offer up to 100% more for a Bug Bounty than companies who do not; anywhere from $500 - $5,000 per vulnerability depending on the severity and impact level. 

Companies who do not work with sensitive data, are less regulated and in an earlier stage of growth can pay anywhere from $250 - $2,500 depending on severity and impact level. This range can vary significantly, and it is best to consult a cybersecurity expert to confirm standard payout per vulnerability for your organization.

Payouts per vulnerability, and the general landscape of bug bounties are always changing. The Bug Bounty industry has seen substantial growth in recent years, with a 21% increase in software vulnerabilities found and a three-fold increase in payouts from Bug Bounty programs. The Bug Bounty market was valued at $223.1 million in 2020, which is expected to grow to $5,465.5 million in 2027. The rise of AI, compliance frameworks and data security regulations impacting SaaS industry growth and the mainstreaming of cybersecurity will continue to shape the Bug Bounty industry, as well as the increasing importance of transparency in vulnerability disclosures. 

Conclusion

Responsible Ethical Disclosure policies are an integral part of an organization’s overall security strategy, and outlines the organization's commitment to data security. However, putting the practice into reality is a challenge, especially for startups and scaleups, with limited internal security resources. Responsible Ethical Disclosures are unique for every situation, and it is important to consult security professionals as you continue to grow your security program and navigate vulnerabilities. Reach out to Eden Data for more information on Bug Bounty programs, and our partner Software Secured for penetration testing services. 

Disclaimer: This blog is an example of what a company can do in the case of a Responsible Ethical Disclosure for a security vulnerability. Our partner Software Secured is unable to provide recommendations on specific environments or applications without engaging directly with clients and prospects to fully understand the attack surface.