When starting with bug bounty, ensuring you have a good testing scope is key. This includes the assets you would like your researcher crowd to test and report vulnerabilities on. Defining your out of scope is also just as important. These are things you do not want researchers to test and submit vulnerabilities on.
‘In-Scope’
In this part of your program build we will assist you with defining exactly what you would like to be test. These can be publicly facing assets, internal assets, domains, APIs, Web/Mobile applications, network infrastructure etc. depending on your focus and objectives. To refine your descriptions and explain to the researchers, we have a library of templates that you may use as a whole or parts of, to best describe what you are looking to get tested.
The ‘In-Scope’ is crucial for setting the boundaries of the program, ensuring that researchers know which parts of the organisation's digital infrastructure they can legally test without violating terms of service or engaging in unauthorised activity.
‘Out-Of-Scope’
The ‘Out Of Scope’ is just as important, if not more as this is where we define what is outside of those boundaries. This is key as this prevents misunderstanding in what they are allowed to test and provides them with areas of focus. In this section we can include internally known issues, accepted risk vulnerabilities, third party services, specific components/functionalities of your assets or organisation that you do not want researchers to investigate or test.
As all researchers accept the Terms and Conditions of your program, they are legally confirming that they will remain within the scope and accepting that they will report outside of this as doing so can lead to negative impacts on the asset/organisation or program.
The exclusion of certain targets from the scope is decided by the you as a client and for various reasons, which may include privacy concerns, legal restrictions, or because those targets may not be relevant to the organisation's current security objectives.
What makes a good bug bounty scope?
- Organisational Impact and value
- Assets that are critical to your organisation’s operations, data security and reputation. These include public-facing web applications, APIs, internal systems with potential external access points, and infrastructure critical to the organisation's services. Good practice is to also include products/solutions that you are offering which have continuous development.
- Example: Online platforms are crucial to a business if they are offering a via a cloud hosted platform. This may have multiple roles i.e. Admin, User, Guest; which can be exploited via a series of attack methodologies which our researchers can test for you within a controlled setting.
- Security Sensitivity
- Areas or components of your organisation that store sensitive data such as; PII, PCI and business IP, are also key as this enables continuous testing and patching over time. These are most likely to be prime targets for an malicious actor. As part of this it may also be a good idea to think critical infrastructure components such as authentication servers/services, encryption services and access control.
- Example: Data entry points can often be used for collecting sensitive/personal data which can also be a prime target for malicious actors, especially if payments are involved. Payment gateways are another exploitable target for researchers to test whether this is via a dashboard page, API or 3rd integration. Areas of risk in these assets are the PII and PCI data, as well as the workflow which triggers a ‘successful payment’.
- Asset Complexity
- Within your solution or organisation which have the most complex technologies would be a good asset for bug bounty as these are most prone to security oversights. Researchers enjoy testing these assets, as it gives them an opportunity to uncover vulnerabilities that may have been missed internally or by automated scanners.
- Example: Assets with multiple versions and integrations developers have the mammoth task of ensuring full functionality of the applications, therefore security may not be number 1 priority. Implementing concepts such as ShiftLeft and Secure By Design can certainly help to increase security maturity from the early stages however more complex vulnerabilities can still be over looked. This would make a great scope for our crowd whether it be in an Bug Bounty Program or in a Hybrid Pen Test as code review.
- Availability
- Ensuring that the assets can be tested without risking significant disruption to business operations or user experience is ideal. This means having staging or test environments that can be access externally, for this we can support a VPN communication between the environment and your researchers.
- Example: Different environments for bug bounty testing are vital because they safeguard the live, production environment, ensuring the stability and user experience is not compromised. These separate testing areas allow for aggressive and thorough security testing without risking user data or system functionality. Moreover, they facilitate an organised approach to enhancing software security efficiently without affecting daily operations or compromising data privacy.
- Exposure
- Publicly facing assets make prime targets for malicious threat actors, which is why these also make good targets for our researchers. In two ways; firstly for them to access easily and test freely with the available resources; secondly, to give you, as a client, a extremely ‘real world’ approach to testing.
- Compliance
- As bug bounty is continuous testing, we can help satisfy various controls which are part of compliance frameworks such as ISO27001 and SOC2. Therefore any assets or components that fall under compliance, we support you in maintaining compliance.
Overall, these are all key factors to consider when defining your scope. It is also good practice to ensure that you keep in mind the continuous nature of bug bounty, meaning that you can prioritise the assets /components that require testing in the short term vs longer term.