Scoping a Network Assessment: What to Expect From Your First Pentest

Following on from our previous blog post on scoping a web application assessment, we’ll be taking a look at what to expect as part of the scoping process for network & infrastructure penetration testing.

If you like our transparent approach to scoping a pentest that’s tailored for your organisation, you can reach out or request a quote.

Getting started

It’s rare for a business to want a penetration test on a website or web application without also having an assessment of their external infrastructure. It usually goes hand-in-hand that any application testing will also involve some form of a configuration review or actual penetration testing of the hosting infrastructure.

What application testing usually doesn’t cover is the wider organisation’s infrastructure, and their assets that are publicly exposed.

Do I need network penetration testing?

There are very few reasons to require penetration testing of an internal or external network, with one example being for compliance purposes, like with PCI DSS. However, penetration testing is a highly recommended activity that all organisations should consider implementing into their security and risk assessment workflows.

It’s also a bit misunderstood that penetration testing is required for SOC2 and ISO 27001 compliance; both of these recommend penetration testing, but it isn’t an absolute requirement.

As to whether to choose between an internal and external penetration test; if this is your first foray into network security testing, then we’d recommend starting with an external assessment.

The key point for this is that most cyber attacks originate outside of your organisation (although that’s not to say that an insider threat isn’t a concern). This could be through a direct compromise of an external service, or a social engineering attack vector, such as phishing.

If your organisation has the ability to procure both internal and external network pentesting, then this will be the best way to get a start on understanding your attack surface from multiple layers:

• External testing to identify your perimeter attack surface and entry-points.
• Internal testing to discover what an attacker may be able to do once they’ve gained an initial foothold.

Scoping a Network Pentest

Keeping in theme with our previous post, let’s assume your organisation is looking to perform both internal and external pentesting, and you’re at the point of having a conversation with a provider. What are the next steps?

The first port of call is to discuss what type of testing you may need or what your organisation would benefit from. This also includes setting the approach to testing that would best suit your organisation’s security maturity and risk appetite; there are always inherent risks when performing penetration testing so it is good to plan in advance.

Just to note before reading on – the information here is generalised to scoping experiences within the industry and what we’ve observed in our careers. The estimates listed here are for example purposes, so if you’re looking for an exact quote for a scope of work please reach out.

See more about our services and how we operate.

Scoping an external network penetration test

First of all, your organisation should know what sort of systems and infrastructure are in place.

Larger organisations may have entire IP address ranges allocated to them (like a /24, a /22, or even bigger ranges like a /20). Smaller organisations may have individual IP addresses dotted around in environments such as a colocation or a VPS, which don’t form part of a cohesive address range.

Whatever it is that your organisation has, at this point the provider is aiming to understand what may be exposed to the internet, a rough idea as to the scale of your infrastructure, and then some additional information that can round out the edges.

Here are a few of the questions that you may be asked as part of the scoping process:

• What domain names would be in scope? If your organisation’s domains are in scope this opens the door to additional testing that can look for issues like shadow IT, weaknesses with DNS configuration, and many more potential vulnerabilities.
• How many IP addresses are in scope? Usually a rough estimate of the total number of IP addresses should be provided (e.g. 50-60). For instances where an organisation has a full allocated range (like a /24), this is usually sufficient but being able to narrow down the number within this can help reduce the potential cost (e.g. only 110 are actively assigned).
• How many endpoints are expected to be exposing services to the internet? You may not be asked this as part of the scoping exercise. But, like the questions around functionality and API endpoints within the web application scope, it can be used to narrow down the amount of time that might be needed for testing.
• Are there any sensitive or insecure services exposed that you’re aware of? Again, you’re unlikely to be asked this, but it is something to think about ahead of time internally. For example, publicly exposing FTP, RDP, or even web services that are intended to be non-customer facing.

To clarity, this isn’t an exhaustive list. There might be additional questions that are asked depending upon the answers to the first two questions.

For this type of assessment let’s break things down and look at two possible examples:

Example 1: Small asset scope

Let’s imagine that we have 10 IP addresses and 1 company domain name that is in scope.

From the pentest provider’s perspective, the limited number of targets that are in-scope essentially narrows down the likelihood of there being many publicly exposed services, and potentially not many weaknesses to identify.

This isn’t to say that “it isn’t worth doing” an assessment of this scale. If anything, your organisation has a much more focused assessment with the time that’s spent testing the scoped targets, leading to more confidence and assurance around your security controls.

Remember, the pentest provider doesn’t know whether your systems are secure or not until they test them. Because of this, a smaller target range still needs sufficient time allocated at the time of scoping to account for their being (let’s exaggerate) 20 services exposed per each of those 10 IP addresses that are targeted.

If an external pentest scope was limited to half a day of testing, but it was discovered that there are excessive services exposed after a port scan, and there was only time to manually probe and target 10% of them, would you feel that you’d had sufficient coverage?

What a pentester will do during a smaller engagement will be to run a port scan to identify the ports that are exposed to the internet (and will probably fingerprint what services are associated at the same time), and then focus on the high-value (i.e. most sensitive) services first. As an example, if SMB is exposed across 7 IP addresses this might take precedence over HTTPS.

Quick note here to say that a lot of this testing is usually done in parallel. A tester can still be enumerating other services whilst manually probing or scanning a specific port.

As an example, let’s assume that this is an already established business that’s been operating for a fair number of years and their systems have been operational for just as long.

In this case, the number of days allocated to this assessment might edge closer to 1 day of testing, but could be 2 days worth of time to include any assessment reporting. Providers will usually assimilate the “reporting time” into “testing time” when there is unlikely to be many issues or findings to report on, and instead dedicate more of that time to active testing.

Example 2: Larger asset scope

When an organisation has a much larger scope, for example they have a x.x.x.x/22 network, there’s clearly a greater number of assets and potential services that could require manual testing.

Scaling the time allocation for larger IP ranges is not a trivial task for a pentest provider, and this is where some external pentest scopes are over or under quoted.

In our experience, quite often the larger the scope the lower the ratio of assets exposed to the internet. For example an organisation with 1000 IP addresses may only expose services on 10% of them, whilst a smaller organisation with 50 IP addresses could be exposing services on 40% of them. This isn’t to say that larger organisations expose fewer services to the internet!

We could assume that a timescale for testing would scale linearly based upon the number of targets in scope. If that’s the case, then would pentesting 100 IP addresses take 5x as long as 20 IP addresses? In an idea world, yes! It would be great to be able to spend equal amounts of time testing every resource fairly.

In reality, providers will typically scale the time effort in a non-linear way. Essentially, they will bundle together the number of days they estimate that a test would take based on how many assets in an IP range will be exposed.

Let’s use another example and assume that an organisation has a x.x.x.x/22 network. That’s over 1000 IP addresses! If we have our baseline at 1 day of testing for up to 10 IP addresses, then clearly, no-one would expect to spend 100 days for pentesting an external network. For that type of cost you may as well start red-teaming or using pentest-as-a-service.

What you might see (not exactly what we do at Exploitr):

• 1-10 IP addresses: 1-2 days of testing
• 11-50 IP addresses: 2-3 days
• 51-250 IP addresses: 4-5 days
• 251-500 IP addresses: 5-7 days
• 501+ IP addresses: 8+ days

That’s a very rudimentary breakdown of how providers may consolidate testing of a larger scope.

Reducing the scope

This is where it is important for organisations to have asked themselves the question “How many assets are exposing services?” that was mentioned earlier.

By providing an estimated number of active assets, your pentest provider may look to reduce the overall scale of the scope, but still perform sufficient enumeration through port scans to confirm during the assessment.

For example, if your organisation has 300 assets that are on the perimeter network, but you’re only actually serving 25 systems that expose services to the internet, then a pentest scope should include all 300 systems for the enumeration phases and quote for active testing of the lower amount.

Lowering the expectations with how many active systems there might be shouldn’t lower the quality of testing, but it can save your organisation from receiving an over-scoped quotation for external penetration testing.

From the individual pentester’s point of view there’s no joy in having to spend 8 days performing an external pentest when there’s only 3 HTTPS ports exposed and they all lead to Apache services that have nothing on them!

Scoping an internal network penetration test

So, we’ve got the external network testing scope covered off. What about the internal network? There are some key differences here that change the context of how your organisation and a pentest provider could approach planning an assessment.

First of all, it’s going to be expected that there will be a considerably higher number of targets to assess. Whether you have a small network in a local business office, or a much larger multi-location network with different subnets, VLANs, and possibly even cloud infrastructure – the main aim is to understand the scale and finer details of what would be targeted.

To start to get an idea of what the “internal” infrastructure looks like, you may be asked these sorts of questions:

• How many networks/subnets do you have? What the provider is looking for here is to get an idea as to how mature the network is, and the scale and distribution of the network topography. You may also be asked what the subnets are for (at a high level), or an estimate and breakdown of the number of workstations, servers, and other network devices present.
• What sort of devices do you have on your network/which operating systems? The aim of this question is to understand whether you are a macOS-first, Windows-only, or hybrid deployment. The same question applies for servers (e.g. Unix / Windows Server).
• What do you consider as the key focus for the assessment? This may be phrased differently depending upon how the conversation is going, but essentially what is being asked is for you to describe what your “crown jewels” are with data or information. For example, if the company is a retail or e-commerce platform, you may consider anything within the card-data environment (CDE) as the key focus. Other organisations may simply consider the compromise of their internal domain (i.e. Active Directory) the endgame.
• Will administrative credentials be provided? A question that somewhat goes against the methodology of a traditional penetration test, but the purpose of this is to understand whether you will be upfront with providing access to allow authenticated vulnerability scanning of your wider environment. Many different compliance regulations can require a sample-based approach to vulnerability scanning, for example to identify missing or outdated software and operating system patches.
• Where would we (the pentester) be positioned on the internal network? What might be an odd question at first is just a way of asking where the “simulated attack” would originate from. For example, your organisation may be more concerned about an attack vector that originates from the position of a compromised external web server, and so the test might start from this position with basic access from the “www-data” user account.
• Can testing be performed remotely? In the olden days most ‘internal’ penetration testing was performed on-site, where a pentester would arrive at one of your office locations and set themselves up at a desk for a week. Whilst this is still very much a standard practice, the modern approach is to provide remote access in some way, which can save a lot of time, money, and effort for both parties. Look out for more on this in an upcoming blog.

These, again, aren’t an exhaustive list of questions, but should give a small insight into how the scoping discussion may go. As mentioned earlier, the key result from this conversation is to understand what is to be tested, and how testing will/should be performed.

Internal network scoping example

Let’s take an example of a small-medium sized enterprise.

They have a couple of office locations, one which serves as the “HQ” and hosts the central infrastructure on-site. At the bare minimum there may be 3 subnets of a /24 size: one for the HQ user network, one for the remote office network, and one for the server subnet. For this example, we’ll say that the organisation is entirely Windows-based for both workstations and servers.

This is a little bit of an exaggeration, and there may be additional subnets or VLANs for VoIP infrastructure, a separate subnet for the remote office’s local servers, and so forth.

With our example, we’ll also assume that the answer to “what is the key focus?” is that the organisation is just generally concerned about their security and wants to improve it. In this scenario, testing will usually be at the discretion of the actual pentester in charge of delivering the assessment, and will depend upon where they’re positioned in the network (e.g. at a desk connected to the user subnet, or wherever a drop-box or remote access is situated).

So, we know the rough scale of the network, that they use Windows throughout, that there’s up to about 700-800 systems (but likely fewer). The testers will need to be onsite, so there’s potentially expense costs to consider here too (they might either be post-dated or included upfront).

For a test of this scale, you might expect about 3-4 days worth of testing to be performed onsite, followed by 1-2 days worth of reporting activities off-site. The time allocated for this is slightly arbitrary and is difficult to plan ahead of time without having prior experience in the same network (like a repeat test) or extensive planning during scoping.

If the organisation was aiming for more of a realistic assumed-breach scenario, the time allocation requirement may increase. For example, if the organisation’s goal is to identify a route to compromise through any means, this indicates that they take security very seriously, which likely means they’ve implemented significant hardening throughout their network.

Personally, the quickest that I’ve ever compromised an entire network was within about 8 minutes of connecting an ethernet cable to my laptop. Gaining Domain Admin privileges, in this instance, provided me with access to each and every system on the network, and direct access to user data.

What did I do for the remaining days allocated to testing? Well, after immediately disclosing the details to how this was performed to my contact, I spent the time looking for other routes to compromise. 

Scoping a Penetration Test – Summary

To summarise everything as more of a quick-reference:

Know what your business concerns are before arranging a scoping call.

This will be crucial for you to understand whether your pentest provider will acknowledge your requirements and translate them to an appropriate testing scope.

Have a good idea of how many assets you have that are actually active and expose services.

Sharing a bit more detail with the pentest provider brings a bit of transparency that can mean less overall testing time and costs.

Be explicit with anything that is considered out-of-scope.

It’s important to note anything that should be excluded from network testing. These could be individual IP addresses, entire IP ranges, specific hostnames/subdomains, or even individual ports and services.

Be specific up-front to ensure that the resulting rules of engagement define what is, and (optionally) what is not to be targeted during testing.

What we haven’t covered

Internal network assessments are usually doubled up with additional ‘internally’ related testing, such as a Wi-Fi security assessment, workstation or server build reviews, firewall ruleset reviews, and so on.

Part of this is due to the pentester already usually being on-site for most of these engagements. Because of this, there’s a bit of cost and time saving involved when considering things like expenses for travel, approval for testing, and planning ahead of any compliance submissions. However, there would be additional time required to perform the various types of testing that’s needed.

As these sections relate to what to expect during your test, rather than your scope, we’ll include this on an upcoming blog, so watch this space!