Bishop Fox named “Leader” in 2024 GigaOm Radar for Attack Surface Management. Read the Report ›

Prepare for Scoping: The Technical Side

Periscope peering out from a body of water


As we discussed in our prior post, scoping is an important precursor to a successful security test. We walked through several high-level questions to ask as you prepare for scoping. Now, let’s explore the more technical considerations you should make as you prepare for a network pen test.

Before we start though, let’s take a quick primer on network configuration, how it has changed over the years, and how it’s impacted pen testing.


The “typical” model of network configuration has changed significantly over the years and will continue to evolve with new technology and business operation models. It’s most important to partner with a pen testing firm that stays on top of the latest technology trends. Scoping conversations offer an early opportunity to make sure you’re working with a partner that isn’t stuck in the past.

For the sake of brevity, we’ve split network configuration into two broad models:

Traditional model: Back in the early 2000’s, a company would buy a bunch of servers from Sun Microsystems (RIP) or Dell, install and configure applications individually on each server, and give each of these servers a public IP address if they were publicly accessible. If it were a medium to large company, they would have their own registered allocation of IP addresses from the American Registry for Internet Numbers (ARIN) or another appropriate internet registry. They might have an IP allocation larger than the number of live servers, but a very quick port scan can help estimate the number of live hosts and give a decent starting point for scoping a network pen test. Testing effort per live host would scale linearly because each host was relatively similar.

Modern model: Due to the complexity inherent to more modern network configurations, this model is hard to name. Cloud-native, abstract, hybrid could all work but do leave gaps – so we’ll just call it “modern” to cover our bases.

The combination of flexible cloud infrastructure, software-defined networking, convergence on HTTP and HTTPS as the overwhelmingly dominant protocols on the internet, the adoption of server name indication (SNI), carrier grade network address translation (CGNAT), and the depletion of available IPv4 addresses mean that it is possible, if not necessary, to put hundreds or thousands of different applications and (virtual) servers behind a single IP address. Scoping based on IP addresses alone lacks a lot of important context for modern networks.

Advancements in cloud services, infrastructure automation, DevOps methodology, virtualization, and containerization also make it possible (if not imperative) for companies attempting to deliver new platforms at scale to build, deploy, and maintain infrastructure at scale. This means that the externally exposed infrastructure and attack surface for a new cloud-native system might be very uniform and minimal because there are 1000 identical application servers/containers running behind a few IP addresses. This is helpful information to know for scoping, so the testers can focus their efforts, rather than having to explore each individual container, instance, or other discrete unit.


As we outlined in the prior post, the more information you share during the scoping process, the more precise our team can be in determining the best test for your needs. That all starts with knowing your goals and discussing them honestly with the scoping team. Be specific! Everyone “cares about security,” but what has made you decide to pursue testing now?

Beyond your goals, here are some technical questions to address with your engineering or infrastructure teams.

  • What is the purpose of the environment?

    • Cloud environments are very flexible, which is great, because it enables many teams to build out environments specifically fit to purpose.

      • A streaming platform for live events will likely have a large, dynamic number of identical web servers used to host content (and/or offload some of this to a content delivery network) but the attack surface may be limited compared to the handful of servers used to capture and transcode the video stream.

      • A digital marketing software startup might have a traditional web application, but also host a data science platform that allows users to write and run code.

    • Understanding the purpose of an environment makes it easier to identify services and architecture patterns relevant for testing.

  • There are some common technical components you might take for granted, but what we need to know about includes:

    • Are you a Windows or Linux shop? Do you deploy Kubernetes?

    • Is there inconsistency across divisions or business units? Did you acquire a company and take on their unique configurations?

    • Does your network have any specialty environments or use cases like research and development?

    • Does the environment have unique access requirements? Does it contain PII or other protected information?

  • Is anything about to change?

    • If you’re about to rip and replace part of your environment, you may not want to waste time testing it. Testing could also support, refine, or adjust your change plans.

    • Should certain areas be deprioritized because they’re about to be replaced.

  • How is infrastructure deployed and managed?

    • Are there/What are the outliers from this standard operating procedure?

  • Technical details of the environment

    • Legacy network footprint: numbers of IP addresses and IP ranges are helpful sizing metrics.

    • If we’re looking at cloud native infrastructure, we’re trying to identify the level of uniqueness in the environment:

      • the number of Kubernetes clusters (if applicable),

      • the number of unique virtual machine images,

      • the number of applications hosted in the environment,

      • the number of load balancers, and/or

      • the number of subdomains depending on how their infrastructure is configured.


Regardless of where you go, here are some questions you can ask during scoping to ensure you’re getting a good test. You can also find other advice to prepare for a pen test here.

  • How have you updated your testing and scoping methodologies to address new networking models and technology?

    • Ensure you’re not scoping only based on IP or you’ll likely miss important context. Instead, to get the most out of your pen test, take an approach to scoping that considers all the modern nuances to network configuration we listed above.

  • Be sure you’re working with a firm that’s staying up to date with the latest paradigms of computing:

    • How do you test cloud environments?

    • How do you try and get into externally exposed systems beyond exploiting published vulnerabilities?

Once you have these internal discussions with the relevant and appropriate teams, grill your pen testing firms during the evaluation phase. Ask for sample reports, case studies, a list of access requirements they recommend, etc. to ensure you're working with strong partners who have a testing philosophy that aligns with your goals.

Subscribe to Bishop Fox's Security Blog

Be first to learn about latest tools, advisories, and findings.


About the author, Claire Tills

Content Marketing Manager

Claire Tills is a Bishop Fox alumna. She has several years' experience with marketing, communication, and research in cybersecurity. Claire enjoys tabletop gaming and gets emotional about space on a semi-regular basis. She has her Master of Arts in Communication from the University of Maryland.
More by Claire

This site uses cookies to provide you with a great user experience. By continuing to use our website, you consent to the use of cookies. To find out more about the cookies we use, please see our Privacy Policy.