Understanding Penetration Testing Scope

Your organization will likely need penetration testing at some point, whether for regulatory compliance or as part of a cybersecurity risk assessment. It would’ve been great to be able to test all internet-facing systems and resources that connect to your internal infrastructure, but the reality is that you simply can’t test everything. 

Time and budget constraints are among the top reasons for this, along with the ownership of the infrastructure you’re using. For instance, you can’t pentest IP addresses belonging to AWS (or other cloud providers), even though you host your infrastructure there. That’s outside of your control, may harm other AWS customers, and may violate the terms and conditions. 

So, whether you’re conducting the test in-house or engaging a third party, you need to define the penetration testing scope.

What Is Penetration Testing Scope?

The penetration testing scope is an upfront agreement between the organization and the tester that defines the boundaries and targets of the test. It outlines what will be examined, what the testers will do, and how long each process will take. It also includes the systems that will be excluded from the test.

The scope is determined by the organization, sometimes with the help of the testers.

What Does Penetration Testing Scope Consist Of?

You want to provide the tester with a document that details everything. So, what exactly goes into the penetration test scope document? Here are some key elements to keep in mind:

• Assets in scope: This is your “yes” list. We’re talking about all the systems, applications, networks, and infrastructure components that are fair game for the testers. 

• Assets out of scope: Just as important as what’s in, is what’s out. This clearly defines anything that the testers should not touch. Maybe it’s a critical production system that can’t handle any disruption, a third-party service you don’t own (like AWS’s underlying infrastructure, as mentioned before), or even specific customer-facing elements. Explicitly stating these helps prevent accidental damage and keeps everyone on the right side of the agreement.

• Vulnerabilities in scope: This section specifies the kinds of vulnerabilities the test will focus on. For instance, are you primarily concerned with SQL injection, cross-site scripting (XSS), or misconfigurations? Defining this helps the testers hone their efforts.

• Vulnerabilities out of scope: Conversely, there might be certain vulnerability types that aren’t a priority for this particular test, or perhaps they’re already being addressed through other means. Listing these clarifies expectations.

• Testing method: The method of testing decides how much intelligence you will be giving to the tester. In a black-box approach, testers will start with zero knowledge about your infrastructure, just like a real threat actor would. Gray-box testers get limited information, such as user credentials or network diagrams, mimicking an insider threat or an attacker who has gained initial access. White-box testers have full access, including the source code, allowing them to conduct the deepest and most comprehensive tests.

• Allowed techniques and tools: Regardless of the testing approach, you also need to agree on the techniques and tools testers are allowed to use to avoid unexpected disruptions or activities that go against organizational policies. 

• Timing and duration: This sets clear expectations for the timeline and helps both parties allocate resources efficiently. You don’t want a test running indefinitely or at a time when your systems are already under heavy load.

• Rules of engagement: Any specific limitations that help ensure that the test is done ethically and safely, such as not impacting production systems, avoiding denial-of-service attacks unless specifically agreed upon, or any sensitive data handling requirements.

Penetration Testing Scope vs. Test Plan

The penetration testing scope is different from a test plan. The scope is an overarching agreement that outlines everything the tester is allowed to check and the type of tests they can do. On the other hand, a test plan is more granular. It is a detailed list of specific assets and the testing procedures that will be followed to execute the agreed-upon scope. 

The test scope is what the first stage of the pentest (planning) begins with. The plan is the output of that stage.

Why is it Important to Define the Penetration Testing Scope

The scope is very important both for the organization and the testers. If you approach a third party about pentesting, the first thing they would ask you would be “what’s the scope?”

Why Is the Pentest Scope Important for the Organization?

1. To estimate the cost. How many web apps and how big the web apps are will define the cost of the test – whether it’s a sum of money you’re paying to a third party or just the time and headcount dedicated to the test.
2. To ensure compliance. Different compliance standards specify what needs to be tested. To ensure compliance, you’ll need to ensure everything that the standard required you to test was tested.
3. To ensure business continuity. The pentest scope serves as a safety net that minimizes risks during the test. It sets clear boundaries for testers, preventing them from accidentally (or intentionally, if there’s miscommunication) affecting critical systems and sensitive data that should not have been touched, or violating vendor contracts.
4. Getting the most value out of the test. If the scope isn’t defined correctly, some critical assets may end up not being tested properly (or at all). That may give you a false sense of security.

Why Is the Pentest Scope Important for the Testers?

1. The resources needed. Pentests take a while and are mostly done manually, so the bigger the scope, the longer it will take — or will require more people.
2. The depth of the test. For example, if a web app has multiple roles with different permissions, pentesters would need to authenticate and test each one of those roles. They need to know it before they start testing.

A focused pentest gives you clarity on the vulnerabilities that truly threaten your most important assets and how you stand against them. Essentially, this helps you understand your overall security posture. 

The Risks of Not Defining the Penetration Testing Scope

What happens when you gloss over the scoping phase? You’re most likely going to miss vulnerabilities because the test is incomplete. If the penetration testing scope isn’t clearly defined, testers might focus on generic areas they’re familiar with, overlooking critical systems and assets that are actually vulnerable. This leaves you with a false sense of security while paying for hours and resources that don’t contribute to your security posture.

And, without clear boundaries, a pentest can accidentally bring down vital production systems. Imagine an e-commerce site going offline during a peak sales period because a tester unknowingly overloaded a server. If testers inadvertently access data they shouldn’t, disrupt services for customers, or breach third-party agreements, you could face serious legal repercussions, fines, and compliance violations.

How To Determine the Scope of Penetration Testing

Penetration testers use worksheets like the one provided by SANS to get an idea of the test’s scope. While every organization’s needs will differ, there are some common considerations that can guide you. 

• Types of systems to be tested: Each type of system comes with its own unique attack vectors and testing methodologies. Consider the hostnames, IP ranges, application URLs, and any relevant versions when determining the scope.

• Existing defenses and security controls: Knowing your current security tool stack, including firewalls, intrusion detection/prevention systems (IDS/IPS), web application firewalls (WAFs), endpoint detection and response (EDR) solutions, and security information and event management (SIEM) systems helps testers understand what they’ll be up against.

• Configurations: Consider if you want the testers to specifically look for default credentials, open ports, insecure protocols, or improper access controls within your systems.

• Tolerance levels: How much disruption can your critical systems tolerate? Some tests, by their nature, can be disruptive (e.g., certain denial-of-service simulations). You need to clearly define what’s acceptable and what’s absolutely off-limits.

• Attack sophistication level: What kind of attacker are you preparing for? Are you worried about opportunistic, low-skill attackers, or are you concerned about advanced persistent threats (APTs) with nation-state backing? Defining the desired sophistication level helps testers mimic realistic attack scenarios.

• The entire attack surface: While you can’t test everything, you need to understand your entire attack surface (including dependencies and interconnections between assets) to make informed decisions about what to include. 

• Budget: Your finances will inevitably influence the breadth and depth of your penetration test. It’s important to be realistic about what you can achieve within your budget while still focusing on the highest-priority areas.

Using EASM Tools for Pentest Scoping

Ideally, each organization needs to prepare for pentests – and this preparation process will also help with scoping it. Attack surface mapping is a great exercise to prepare for a pentest, which means that an EASM tool could be very useful here. Here’s why:

Get an asset inventory

When you use tools that support external attack surface management (EASM), they discover and map your assets to each other. That allows you to understand which assets you have so that you can decide which of them should be tested and not miss anything critical.

Eliminate shadow IT 

While cataloging your assets, you will likely run into shadow IT assets that were not on your radar. These need to be inventoried, patched, and handed over to the IT department before the test starts so that you are sure you have plucked the low-hanging fruit for pentesters and haven’t left any easy entryways into your network.   

Understand which IPs actually belong to you

Some security platforms like Attaxion can tell you which IP addresses belong to your infrastructure and which ones belong to public clouds so that you don’t accidentally include public cloud IP addresses in the pentest scope and face legal implications for that.

Patch the critical issues prior to the test

EASM platforms also help you detect vulnerabilities in the discovered assets, which helps you get the most value out of the pentest if you immediately patch those that are easy to exploit. Tools like Attaxion provide insight into a vulnerability’s exploitability as it integrates Exploit Prediction Scoring System (EPSS) scores and CISA Known Exploited Vulnerabilities (KEV) data for vulnerabilities, helping you identify those that need to be prioritized when preparing for the pentest.

Conclusion

Penetration testing can be expensive, take a long time, and break things in the process. You can avoid breaking the bank, accidentally taking down business-critical services, and waiting for months to get results by properly defining the pentest scope. 

Cybersecurity platforms with EASM capabilities, like Attaxion, are useful while scoping the test, as they give you a complete inventory of all your assets and essentially make you ready for the actual pentest. These tools also complement penetration testing through continuous monitoring of your attack surface, compensating for the scheduled penetration testing, which is only based on a point-in-time snapshot. 

Witness firsthand how Attaxion can help you with your asset inventory. Sign up for Attaxion’s free 30-day trial now.