Too Many Network Pentest Restrictions Can Hurt Your Business
Recently, I had cervical spine surgery (ACDF) and was on restricted duty as a result. The surgery involved putting a metal plate on my spine in my neck with a new piece of bone in place of a disc that ruptured…and it’s my second surgery, plate, and bone. I’m a headbanger/metalhead. I love Slayer and Cannibal Corpse – is anyone surprised that I needed a second surgery?
I was under a lot of restrictions – wearing a collar, not lifting anything over 10 pounds, not moving my neck a whole lot, etc... I was only recently permitted to drive myself to the convenience store a couple miles away. These restrictions are in place to help me get better and ensure that the ACDF is fully successful. The bone graft has to sit in place for a couple months to a year (or longer) to make sure it will work. So, keeping my neck from moving and not lifting anything are good safeguards.
At Secure Ideas, we’re in the business of helping people and organizations understand how to secure their infrastructure and applications. Securing infrastructure and applications requires creating and enforcing restrictions. We understand restrictions. Some of us have even helped write the standards that help others understand what restrictions are necessary for securing systems. This post is specifically focused on network penetration testing restrictions, with the definition of restriction from the Cambridge Dictionary – an official limit or control on what people or companies are allowed to do, or on what can happen.
So, let’s define the objectives of the network pentest before getting into the restrictions that inevitably surround the exercise.
Defining the Pentest
Before we can talk about the restrictions, we need to talk about the type of pentest we’re talking about. There are several types of penetration tests that can be performed, and several subtypes within those types. The most common types of pentests are network, web application (webapp), and cloud tests. These encompass the majority of the tests that Secure Ideas (and other firms) perform. The subtypes are where things start to get more interesting. Network tests consist of external and internal network tests, and these can be broken down even further into specific tests built around compliance (PCI Tests can get fairly specific) or built around a type of infrastructure (I’m looking at you, ICS and SCADA networks).
The tests that we’re covering in this blog post are centered around full bore network tests. Internal and external network, almost all IPs in scope. A test which will give our clients the most efficient use of their resources – time and money. The issue we’re discussing surrounds when this is how the test is initially presented, then your pentest team is told that the scope is going to be pared down, sometimes by a LOT.
Defining the Pentest Objectives
One of the objectives of a pentest is identifying vulnerabilities present in a system or network and simulating an attack on those vulnerabilities. A side effect of this is that the security controls in place on the scoped network are also tested to assess how they will function during an attack. As a security consultancy, our objective is to help our clients mitigate risk through conducting an attack simulation and testing these controls.
But the objectives run a little deeper than that. When we scope a pentest, we ask the client questions like:
- What do they want and/or need from the test?
- What do they see as their primary objective of the test?
- What do they consider their biggest risk?
- What are they concerned about getting attacked?
I’ve personally asked my clients what scares you about your network and what keeps you up at night? The questions may seem a bit redundant, but they’re important because they help us understand the client’s needs, and tailor the testing efforts and scope for that purpose.
Defining Scope
Let’s talk about scope real quick – scope is defined as the parameters (systems, places, dates, times, etc.) against which the pentest can take place. Scope is, next to the contractual consent of both parties, the most important part of the pentest preparation. Scope defines what the tester can and cannot do – the pentest restrictions. They define what can be attacked, what cannot be attacked, when to attack, and in some cases, how to attack. Simply put, the restrictions (scope) are set to protect the business and the testers. So, why and how can restrictions hurt you?
The Dangers of Narrowing Scope
As a pentester, I’ve often thought about how attackers, real attackers, not simulated ones, have “no scope” to attack. There is some truth to this. For example, criminal attackers don’t have a timeframe that they can and cannot perform their attacks. While they will absolutely take certain things into account such as when and how to attack (they don’t want to get caught, right?), they don’t play by the same rules as a pentester. In a real attack, there is some malevolent intent behind the attack, such as intentionally stealing data and/or causing some form of chaos or destruction.
This is not the objective of a network pentest.
As pentesters, our job is not to destroy a network, but quite the opposite – we’re here to help make it more resilient against attack. We’re here to meet a core objective of the pentest – finding and exploiting flaws and misconfigurations in the scoped environment, including all security controls in place. But when the scope is so restricted that testers are not able to produce meaningful results, then a lot of time and money ends up wasted. Constraining the testing environment so much that the tester cannot perform the test to the best of their ability – that is, to manipulate the environment as a criminal attacker would – can actually do more harm than good.
Here’s an example: there is a corporate network with 25,000 systems on it, including workstations, servers (database, fileservers, development, etc.), and other network devices on it. When we scope these types of tests at Secure Ideas, we typically ask the client to give us as much of the network to test as we can get. Yes, that’s a LOT of systems to inspect and gather information on, but in the long run, it helps us to get the clearest picture of what a network’s security and controls look like. However, there may be systems on the network that “will fall over if they’re looked at sideways”. But should they be removed from scope?
Honestly, most of the time, the answer is no. This goes back to what an actual criminal attacker considers as “scope,” which is roughly anything that they can get their hands on. When attackers see something vulnerable, they’re going to exploit it. Now, there are exceptions to this rule, most often when something has been exploited before and it’s now a known issue. We absolutely agree that these types of systems may need to be removed from scope. But our experience has shown that often the evidence has been anecdotal – someone on the team heard that the system could fall over if it was attacked – it has not actually happened before.
We get it, there’s almost always some legacy systems on a network that can cause problems. As testers, we can and will treat them with kid gloves. But to remove them from scope altogether can set up your pentest for failure. Pentests are all about trying to help an organization determine where their weaknesses are from a security standpoint. Removing certain systems, or entire subnets, from a pentesting scope will not give the client the expected results.
How Can We Fix This?
So let’s define what a well-scoped network pentest should look like – one with almost all systems and subnets in scope. Proper scoping with your consultant team can help your organization understand where their assets are and help them understand how their controls are functioning (or malfunctioning) to prevent attacks on their network. The testing team will ask questions about what the organization’s objectives are, and help them to better understand how the test can help meet those objectives. The testing team will also help the organization to understand what the best outcome will look like, and how to achieve it. The end result is a test with clearly defined rules of engagement, scope and objectives, and a report that reflects all of the above.
And here’s the best part – it allows the pentest team to find the vulnerabilities in the dark part of the networks that might be overlooked, or even completely forgotten about.
Shameless Plug
If you’re reading this and wanting to know more about what a well-scoped, well-executed pentest looks like, then get in touch with us at Secure Ideas. We have years of experience and several satisfied and repeat customers that know what we’re capable of. It’s time to find out how your organization’s controls are protecting your organization, and where they might be failing to do so.
