error_outlineWEBSITE HACKED ? sos@getsecureworld.com

How to define your scope for the penetration test?

blog Z. Oualid today

Background
share close

If you have already performed a penetration test on your website or your network infrastructure, then you should have heard about the scope of the penetration test.

Defining the scope for a penetration test is performed by following the next 10 steps:

  1. Defining the tested assets
  2. Defining the criteria of success
  3. Defining the pentest duration
  4. Choosing the right pentest approach
  5. Defining the tests time frames
  6. Defining the prohibited techniques
  7. Listing the types of vulnerabilities

If you want more details and examples of how to perform each of the previous steps, just continue reading …

Defining the tested assets

This step may look obvious, but trust me this can save you a lot of time and money if it is well done. Before even thinking about performing a penetration test against your website or your network infrastructure, you should answer the following three questions and write them down:

  1. What are the critical apps or systems that should not be out of the server under any circumstances?
  2. What are the apps, systems, or networks that you want to pentest?
  3. What are the apps, systems, or networks that should not be tested?

Let me explain why you should answer those questions now.

When a service provider is performing a penetration test against your app or any system, it is simulating a real hacker attack against you. Therefore, many bad or wrong things could happen to your app, especially if the penetration tester is not an expert. Things like data modification or a deny of service or even just system disruption.

So, knowing what are your critical systems and apps between your assets will help you identify the risk and defining the allowed techniques to be used in this pentest mission, to avoid all these problems.

Identifying those critical systems will also help you answer the second and third question. It means you will be able to know exactly which ones that you may accept the risk of performing a penetration test against them, and which ones you don’t. Therefore, you will be able to better orient the penetration tests to save more of the penetration test time. Which means also, saving money.

Defining the criteria of success

Defining the criteria of success is one of the most important things, you should do before asking for a penetration test. Knowing exactly what is the output that you are waiting for from a penetration test is a critical aspect that should not be left to the end. The criteria of success are simply the condition at which the penetration test should stop. Let me give you some examples to better understand this.

Let’s say you are trying to perform a penetration test against your local network infrastructure. The criteria of success in this situation could be :

  • Gaining the network Active directory administrator privileges
  • Gaining access to some critical servers
  • Gaining access to some critical network

For example if you are trying to perform a penetration test against your website then here is some examples of what a criteria of success may looks like:

  • Finding as many vulnerabilities as possible
  • Gaining Application Administrator access
  • Performing a privilege escalation in the app
  • Controlling the server that hosts the app
  • Gaining access to the database

You may start now by asking yourself what is the best option for me. Well, I really don’t like the general answer to “it depends”, so I am going to tell you what is the best in my point of view and why. However, at the end of the day, you know better than me what your objectives are.

Now, in the case of a network penetration test, I suggest that you focus on two things as criteria of success:

  • Knowing as much vulnerabilities as possible of your network
  • Gaining Active directory Administrator privileges

If the penetration tester gains admin privileges on the AD, then he will have access to the whole network. Therefore, there is no longer necessary to continue the pentest. However, if this condition is not met, then the pentester should continue the mission to get, as much information about the vulnerabilities as possible, and the mission will stop only at the end of the mission duration.

For a website or a web application penetration test, the best success criteria that I found, is finding as many vulnerabilities as possible. The idea of a penetration test in an application is really very different than the network. In most cases gaining administrator privileges in a vulnerable app is very easy once the vulnerability was detected if the app is on production. However, in general, the penetration tests are performed in a test environment where in most cases no one is logged in. Therefore, the exploitation of vulnerabilities to gain administrator privileges become time-consuming.

Most of the time when performing a penetration test you may choose to do a gray box pentest, and in this job mode, you will have to give admin and other simple user credentials to the service provider to perform the pentest. Therefore, having the admin account hack as success criteria has no sense.

Defining the pentest duration

In most cases, a penetration test for a medium-sized website could take between 3 days to 1 week, a more complex app could take between 2 to 4 weeks to be done.

Defining the penetration test duration is really a very difficult task that is performed by your service provider, all you can do in this step is negotiate. When I say negotiation, it means if you have for example some delivery deadlines you should meet, regarding your internal superiors or something like this.

However, I really encourage you to not negotiate this part with your service provider if you don’t have any time limitations to perform this pentest.

Negotiating the duration of a penetration test simply means, reducing the time to perform the pentest. Therefore, reducing in most cases the effectiveness of the penetration test mission. The penetration test is not an exact science and sometimes, depending on the complexity of the app, this could take much more time than the expected one. So giving your service provider the freedom to suggest the best duration for him, is the best thing you can do in this step.

Choosing the right pentest approach

A penetration test has three approaches that you can choose between them when you decide to perform a penetration test. I have already written an article about this subject, where I have explained in detail which approach is the best and why. However, I am going to give you just an idea about those modes so that you can understand the concepts.

The penetration test mission could be performed in three possible approaches:

  • Black box
  • Gray box
  • White box

The black box penetration test simply means that no information will be given to the pentester. All that the service provider will get are the addresses or IPs that are already available to the public. Then he will start acting like a real hacker that tries to infiltrate your system by collecting as much information as possible about your app. This approach is the most realistic, but also the most time-wasting and the less efficient.

Therefore, what I personally recommend to my clients, is the gray box approach. Following this approach has two main benefits:

  1. You will be able to reduce the needed time to perform the test as the penetration tester will not lose too much time looking for information.
  2. You will not have to give critical and sensitive information about your app or your system (like source code)

The white box penetration test is the most efficient approach in terms of a number of discovered vulnerabilities. However, in most cases, the Whitebox penetration test may take longer than the other ones. In addition, following this approach required giving your source code to your service provider, which may be a confidentiality problem to some companies.

To do the right choice regarding this step, I highly recommend that you take a look at the article I have written, you will have all the details with examples to better understand those approaches.

Defining the tests time frames

Now that you know what you want to test and which approach you are going to use for it, you are able to define the test time frames. Let me explain first what I mean by tests time frame.

The test time frame is simply the periods where your service provider can perform his tests without disturbing your production environment or your network bandwidth. In case, the penetration test is performed against a test environment (which is what I always recommend), then there is no problem at all you can choose what you want. However, if you are performing it against your production environment then, doing it when the traffic is low, is the best idea.

according to statistics the best time to perform the penetration tests is when the traffic is at its lowest levels for a website or in the case of a network, after the job.

Let’s say for example that your website gets low traffic between 9:00 am and 11:00 am, then this is your best time to perform a penetration test. Some people may ask to perform this penetration test in an active environment where there are multiple login and logout. This is understandable because to be able to effectively exploit some vulnerabilities and gain admin privileges, you will need this like in an XSS vulnerability exploitation.

However, in my point of view, and as I said in the definition of criteria of success, the idea here is to find as many vulnerabilities as possible. Therefore, if you can just get a proof of concept of the existence of the vulnerability then it is enough.

If you are performing a penetration test against a local network, then things change a little bit. In the network penetration tests, the main criteria of success are to gain Active directory administrator privileges. Therefore, to perform what we call lateral movement in the network to get to this objective, the penetration tester needs an active network.

Defining the prohibited techniques

Here we get to a very important aspect that you should define in your scope. Unfortunately, this step is a little hard to put in place, as it needs some knowledge of the cybersecurity vocabulary. In this step, you will have to define and limit the use of some hacking techniques that can disturb your website or work environment.

Unfortunately, I will not be able to talk about all the used techniques in this article, but I will give you some of the most aggressive ones that may cause you some troubles.

Brutforcing

The first technique that I am going to talk about is the brute-forcing technique. Bruteforcing is a technique that helps the attacker guess some information by testing as many letters and number combinations as possible. In fact, this technique could be used in two situations in most cases.

The first and obvious use of this technique consists of attacking the login interface of the website with multiples usernames and password combinations. This attack then helps the penetration tester to discover valid credentials to get into the app. Sometimes, if the admin username is discovered earlier, the penetration tester could use this technique to find the admin password.

The second most popular use of this technique consists of brute-forcing the website path to find some configuration files or backup files that can contain some critical information.

Performing such a technique against your website or your local network could put down your environment and stop the production. So, you should think of discussing the possibility to not perform such attacks. However, if the service provider will perform those attacks on a test environment, then it is better to leave him free to perform whatever is possible.

Phishing

If you ask me what is the most efficient way to penetration a network or a website, I would say it is phishing. Phishing is a technique that can be performed by the attacker to gain user credentials by exploiting human weaknesses. This technique is based on social engineering.

This technique is really useless for you as a client that wants to perform a penetration test. Actually, as discussed in the previous paragraphs, the success criteria is to find the technical vulnerabilities. Therefore, using this technique in a penetration test is not beneficial for you. However, performing a separated sensitization campaign after that will be.

Listing the types of vulnerabilities

This step is not necessary for the network penetration test, as the vulnerabilities are very diverse. However, in a website penetration test, this could be defined to your service provider. Actually, in some cases and when the application security reaches a certain level of maturity, it is better to define the list of vulnerabilities that you are looking for in your source code.

Let’s say that for you, finding a missing header flag in your source code, is not that critical. Then, not looking for such vulnerability from the beginning would save some time to focus on the others.

Or, another example, if you want to just look for business logic vulnerabilities in your website. Therefore, specifying this in your agreement would be very important.

I know that this step is not easy to do, as it needs a certain level of knowledge in the existing types of vulnerabilities, but if it is done, it will save you a lot of money and time.

Written by: Z. Oualid

Rate it

About the author
Avatar

Z. Oualid

I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).


Previous post

Post comments (0)

Leave a reply

Your email address will not be published. Required fields are marked *