“Can I have a penetration test please” is about in line with saying “Can I have a car please?”. Why am I writing a blog about this? Well, where do I start, so I have been working on the technology world basically all my career and over the last 20 odd years one area of digital security management that I think a lot of organisations and people struggle with is understanding just what a penetration test is, how it should be used, how long they can take and what is involved.
Now there is loads of materials available if you are an intrepid reader you can read content from CREST, there is a 62-page penetration testing programme guidance document. If you are not content with that you can read the PTES documentation (which when I go to print it says 179 pages of A4). Then on top of that there are some awesome bits of documentation from NCSC, OWASP and MITRE etc. All in all, there is a plethora of information available on the subject and countless sales brochures and PDFs explaining approaches etc.
So, with all this material out there why I am writing more? Well mainly because in my experience the majority of people out there do not understand what a penetration test is, how it is scoped, what is involved, and they do not have the time or inclination to read hundreds to thousands of pages. So, the aim here is to give people a thousand-foot view and focus on some key areas to help people get a bit more insight without the hundreds of pages.
What is a penetration test?
According to the folks at the NCSC a penetration test can be described as “A method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might.”. Seems pretty reasonable to me. They also follow this up with a good dose of reality checks and recognition that a penetration test is not a magic bullet and is a part of a security management process.
How does this fit into a security programme?
Ideally there are a range of security management activities, from planning, design, design reviews, control assessments, supplier and solution assurance, vulnerability reviews, configuration audits, risk assessment and also well penetration testing (amongst other things). So, if you are at this point and you do not know what I am talking about in the other areas do not worry you are not alone (it is more common than you think). The real answer is penetration testing is a tool/method/practise/activity that is conducted to test a system and it is controls to see if they are robust and resilient against likely threats.
Scoping a Penetration Test
Understand what you are testing?
Is it an infrastructure/networking service, an application, an API, a PC device, a mobile device, embedded device, wireless network, or physical control? The variety of targets is large.
Determine Test Objectives
Determine Threat Actor Position and Scenario
We need to understand where the attacker will be positioned from a network or physical perspective and we need to understand the scenario (think of that as the story) that they are in. E.g., they are in the UK and they are using a single internet connection, they are attacking service X and they have (or do not have) information (such as credentials, system knowledge etc.)
This could be a range of perspectives such as:
- Country specific, Internet Facing.
- Physical at a location with adjacent network access.
- An insider threat (malicious staff member)
- A supplier
Now we have determined who, what and where next we want to think about objectives.
Now we know where the attacker is, how they are going to access our system and if they have key information. We need to think about what they might be trying to achieve. This could include areas such as:
- Gain unauthorised access to sensitive data such as hashed credentials
- Gain unauthorised access to the underlying system components e.g., Database Services or Operating System Components
- Elevate to a high privileged position and exfiltrate data
- Deny access to the service for other users
That is not a prescriptive list, you will likely know your system better than the testers at this point, so the idea here is to help steer the thinking so that the testers focus on key areas.
Describe the Scope
Now here is an important part, a penetration test is not hiring a criminal organisation. It is hiring a professional to complete a project. They need to have clearly defined boundaries, targets, and thresholds. Penetration testing is not a two second job nor is it all about smashing and grabbing so recognise that paperwork is important, as well as ensuring everyone is clear on the rules of engagement and boundaries (as well as escalation paths, contact details and when a test should pause, seek further authorisation, or simply conclude).
Understanding the service, architecture, and test approach
So, we have determined why we want to test, where we are testing from, who we are going to emulate but we also need to know something about the system and environment. Now we have got different styles of test (black box, grey box, white box) which determines the level of information we have access to (black is very limited, grey is some (this may also include being authenticated etc.) and white we have full access to the systems, docs, and team (or a hybrid of this).
So, to give some examples of information that is going to be needed I am going to show two example, one infrastructure scenario and one web application scenario (these are the most common types of scenario):
The services are public facing and consistent of 16 public facing IP addresses. The services include remote access services via Remote Desktop Services, web applications, database services, virtual private networking services and perimeter firewalls.
Now we need to have a view on when the testing will need to be performed. This should be fairly obvious, but preparations are required, and an indication of timescales is a normality in project management. What we also need is an indication of the duration/effort involved. Putting this all together we have the who, what, how and when, we need to now look at the how long. This will vary based on the specifics but generally speaking the average penetration testing duration is weeks not hours. There is clearly a requirement to test to a reasonable standard and duration, you are not generally going to run a penetration test for months (unless you are using an internal team or a large-scale managed service). You can run penetration testing in an iterative fashion (we wrote a blog about that the other week) however the traditional model is a more aligned to a waterfall project approach. Penetration testing needs organising, it needs logistics sorting, it needs the testing to be conducted and the report created quality assured and there needs to be a post-test debrief. If you think that you can do all of this in a day you really are not being realistic with your expectations.
The Penetration Testing Process
High Level View
- Plan & Prepare
- Report & Debrief
Each of these phases has a range of activities, we are not going to go into every single step in this post, but we have hopefully given a good view on some of the important parts of the plan and prepare phase.
Getting the most out of a penetration test
The more you put into something usually the more you get out. I do not mean that just in terms of time, but this is around the whole security posture of a service. A penetration test is not the be all and end all, it is part of the picture. It is important to get the right scope, the penetration testing scope is one of the most important elements. It will not matter how good the testers are if they have a poor scope. It is not the sexiest part, but it is the part that makes or breaks a test!
PTES – http://www.pentest-standard.org/index.php/Main_Page
CREST Guidance – https://www.crest-approved.org/wp-content/uploads/CREST-Penetration-Testing-Guide.pdf
NCSC Guidance – https://www.ncsc.gov.uk/guidance/penetration-testing