How to Order a Penetration Test – A Quick Guide

Although people working in the IT security industry may consider this question to be as trivial as "How to order a phone charger", for many, writing a purchase order for a penetration test can be like designing a nuclear power plant.

• What do all those weird names and abbreviations mean?
• Is the pen test the same as an audit?
• What will actually be tested and what does it involve?
• I hope they don't ask me any questions...

These are probably the first questions that occur to merchants or procurement workers in a wave of stress. And that is the reason why we have decided to help you answer these questions whilst also relieving you from the stress of writing such a project description. We are going to simply show you how to choose and order a penetration test like a professional.

Pen Test or Audit

As with all explanations, there are many different definitions in this case, too. That is why we will try to describe them in the way we see it, as the hackers.

Audit – as the name itself suggests, it can be accurately compared with tax control (which is optional in this case). You invite a team of experts to your company or server and provide them with access, all available documentation, and collaborate with them to the maximum possible extent. On the basis of these documents and accesses, they will develop a report on the security of your server, solutions, and company, then they will describe the steps you should take to improve them. Alternatively, they will advise you to comply with some regulation.

Pen test – an abbreviation for the "penetration test", is a controlled real hacking attack. Imagine publishing an online challenge such as "Hack me!" The difference lies in the fact that white hats signed a contract with you, the terms and procedure of the testing process were agreed upon and you have also a signed non-disclosure agreement. For a set period of time, they will really try to hack your application, company, or network; however, shortly afterwards, they will demonstrate your vulnerabilities not only practically, but they will offer you a solution of how to fix them.

So what is better?

Like everything in life, both of these methods have their advantages and disadvantages. However, you are the one responsible for the choice, as you have to judge what is better for you and your needs. In all honesty, hackers prefer penetration tests, for the simple reason: "A practical example is worth a thousand words. You cannot argue against it." That is the reason why this blog is dedicated to penetration tests.

Choosing the type of pen test obviously depends on the subject to be tested, whether it is

• a web application
  

• a mobile application
  

• infrastructure
  

• an IoT device
  

• ...
  

It is very important to clarify this right from the start. If you are just preparing the project description and you are not the client itself, ask for an explanation of what the subject to be tested actually is. Subsequently, you can then proceed to select the type of pen test. The German Federal Office for Information Security has produced an excellent visual overview for choosing a concrete type of pen test:

It can be compared to the children's mazes that you can find on paper place-mats in buffets. You can simply find your way from the top to the bottom by answering the questions in lines.

Information Base

It includes the information that the "attackers", i.e. the penetration testers, use to perform the test. Black Box – simply said, without prior knowledge of the application. Testing is performed without knowledge of how the application is programmed and in which program, or without data on the network scheme or the way in which it works. The only information that the penetration testers possess is how the subject to be tested is used by its regular users. Black box is the most common form of testing. White box – as you may have already guessed, this is the opposite situation, if you decide to provide all the available information and/or collaborate during the testing.

Aggressiveness

The question of how "violent" a penetration tester should be while testing, in the range between "watch but do not touch" to "do what you know", is usually appropriate to ask only in specific cases if really sensitive targets are being tested, such as industrial networks. If a web or mobile application is about to be tested, you definitely want to let the penetration testers try out all the possible ways to hack you. Because then the attackers will take their gloves off.

Scope of Testing

Correctly defining the scope of testing, or, vice versa, what should not be tested, is a key point that needs to be made clear from the start. Prior to performing the test, the penetration testers will ask you again about the scope of testing in order to avoid any misunderstandings. It is important to remember that if the black-box test is performed (without knowledge), penetration testers depend on the project description provided by you. They cannot easily tell if any of the servers with which the application communicates belongs to a third party and only uses your domain, or if there are any applications on the server which you do not want to test.

Approach

How to access the test? "Fast and furious", in other words, without fear of being revealed, or "inconspicuously like a ninja"? In most cases, the client chooses not to hide anything because he knows about the test and the date of its performance, and the goal is to monitor the application's behaviour. However, there is an exception when testing an IDS/IPS system or the safety department's response to the hacking attack. However, it should be borne in mind that in the "ninja" version, the penetration testers will need a lot more time.

Technique

The choice of "testing" technique depends of course on the subject to be tested. In most cases, it is testing over a network, whether via the Internet or your local network. The only exceptions include cases where physical devices (for example, PLCs), people or social engineering techniques need to be manipulated.

Starting point

Finally, this is an organizational question which answers whether it is possible to perform the test directly from our comfortable office via the Internet (or VPN connection), or whether the testing will take place at the client's premises. For example, if remote access is not possible for any reason. Of course, we prefer the first option.

But how will be the testing carried out? What will be tested and how? What vulnerabilities can be detected? We will try to answer this in the following lines.

Methods

The choice of method that determines the procedure and scope of the testing depends on the subject to be tested. There are extensive articles and discussions available about the individual methods, and their advantages and disadvantages. For simplicity, we will list only those most appropriate for the majority of people within the given category.

Web applications

OWASP Testing Guide (v4) – Sometimes referred to as OTGv4. If you would like to test your web application, this is the best choice for you.

Mobile applications

OWASP Mobile Security Testing Guide – OWASP MSTG – This is a comprehensive testing method for the Android and iOS platforms, the tests of which comply with the OWASP MASVS standard (if you use it).

Infrastructure

Open Source Security Testing Methodology Manual – OSSTMM – You can find this abbreviation in almost all of the orders for infrastructure penetration tests. However, this is a formal method, not a test guide. You cannot mess up something by simply mentioning it in the Methods column.

Industry/ICS/SCADA

Securea
– There is no comprehensive testing method for these systems as of yet. We are currently working on it.

Please fill in the Methods column with the full name of the method or its abbreviation. If you write only OWASP, it is like if you wish to get LEGO for Christmas. The OWASP abbreviation refers to a non-profit organization that covers the publishing of a number of those methods. There are only two of them within this section.

What to think about prior to the penetration test

Pricing – If you want to prepare a price offer or you are launching a selection procedure, the first thing the pen tester will request is an application preview (eventually its user guide) or other description of its functionality (best with images). In order to be able to determine the workload and scope of the subject to be tested, we need to know the type of the application and its functionality. On the basis of these pieces of information, it is possible to set a very precise time (and thus financial) estimate as well as to verify the terms of the project description. So, if someone immediately responds to your offer/tender without even being interested in the type of the application or test ordered, the quality of the result of this offer should be questioned.

Do not perform a test in the production environment – It is really not a good idea. Although we try to avoid "destructive" activities, sometimes the application can be disabled or the data of other users are inadvertently modified (deleted). Therefore, we perform tests in another environment (e.g. in a sand box), but this should be identical to the production environment (and contain test data). It is also not desirable to deploy new versions into the environment during testing, as this affects the test results. There are other reasons described in the following points.

Make a backup – A backup should be made prior to the penetration test, ideally a snapshot of both the operating system and the database. During testing, an enormous mess is made in the application, therefore it is easier to restore the entire environment. The same applies for the testing of mobile applications with a web backup.

We will want the environment for ourselves – If possible, we will want to keep the testing environment for ourselves. This is especially true for web applications. The reason behind this is the facilitation of testing and the minimization of complications. In this case, we know that all conditions that occur during testing are caused by us and not by someone else. Moreover, we do not have to worry that we will inadvertently affect somebody else's testing.

Date of realization – When planning the implementation date, it should be foreseen that the pen test is usually carried out by two pen testers and therefore reserve a sufficient time period for them. Not all tasks can be performed simultaneously. Five times more people do not test one thing five times faster.

What we require from you

Contact persons

We will need two contact persons available during the period of the pen test's implementation. Technical contact – a person we can contact if the application stops working or if we require a technical consultation. Escalation contact – a person who can be urgently contacted in case of occurrence of any serious vulnerabilities that could jeopardize the production environment. In that case, we recommend you make a correction immediately and not to wait for a report from us.

Access

Pen testers will need access to networks, applications, VPN and so on. Therefore, especially in large organizations where complicated processes are implemented, it is good to consider this fact ahead of time in order to ensure enough time for providing access.

Web services

If web services are the subject to be tested, you will also need to prepare functional sample requests in addition to the calling description (e.g. WSDL), or the test projects (SoapUI) directly.

Mobile application

If the mobile application is the subject to be tested and it is not yet published, we will need an application package or its source code (if needed).

Example

Never order a penetration test in the following way:

Dear Ladies and Gentlemen,

I would like to ask you for an offer for the security testing of our intranet site.

It consists of two servers: Apache and Mysql.

A possible date of testing is from next Monday to Wednesday.

Kind regards,

Customer

Selection procedure for a web penetration test of the module LOL, application QWERTY within the IMHOLOL project

Description: This is a FUN application of the PWND department to manage HEH clients using HAHA

Range: 42 forms

Used technologies: Apache, Linux, HTML

Test Requirements: OWASP, OSSTMM, CWE, NIST, CVE, CISSP

Realization Date: 1st-5th November 2017

Additional questions are not possible.

Company E

And, finally, just a preview of the type of order we'd like to get from you:

Dear Ladies and Gentlemen,

I would like to ask you to draw up an offer for the penetration testing of the AWESOMEAPP web application.

You can try the demo application at https://demo.awesomeapp.sk , login demo: demo

We require a black-box penetration test in compliance with the OWASP Testing Guide.

The test should be performed in a special test environment available online during November.

For additional questions do not hesitate to contact me,

Kind regards,

Super Customer

We look forward to your orders ;)