Introduction to Penetration Testing
More and more UK businesses are considering engaging a third party company to perform a penetration test but there is still a lot of confusion over what a penetration test actually is.
If you’re anything like me, it’s hard to hear the phrase penetration test without a thought something along the lines of…
Joking aside, we define a penetration test as:
A legally authorised, exploitative attack against a computer system designed to simulate as closely as possible the techniques used by a threat to that system.
In simple terms, it seems to boil down to hack it to see if it can be hacked and, while to some extent that is true it doesn’t really explore the full intent of a penetration test.
What is a Penetration Test for?
Assurance. The same as any testing, you are trying to work out if things work they way they are supposed to. If you have implemented layers of security defence in your systems or applications, how well do they stand up to an attack? A penetration test should be able to tell you that.
There’s a couple of key points I want to pull out of our definition above.
Legality
Firstly, a penetration test should be legal. In the UK performing any kind of typical security testing activity against a system without authorisation is an offence under the Computer Misuse Act 1998. No reputable penetration testing company is going to proceed without making sure the test is legal.
Exploitative
Next up, a penetration test is an exploitative process. Typically a penetration test may include a vulnerability scan as part of the enumeration phase but that is not the end of it. A vulnerability scan is an automated check of the target systems for any known vulnerabilities, typically caused by a lack of software security patching.
There is plenty of value in an automated security scan of your systems, network or web application but this is not a penetration test. Vulnerabilities will be exploited in a penetration test, meaning we will actually try to gain access to the system or data, as defined by the scope of the engagement (more on that later).
Techniques
Finally, I want to touch upon the part of our definition that says “..simulate as closely as possible the techniques used by a threat…”. In order to achieve this we need to understand the threats you are concerned with. Now, for many clients who have not perhaps had a penetration test performed before, they may need some help identifying threats to their business but for most organisations there’s a concern about an external entity gaining unauthorised access either without any authentication whatsoever or, as is the case with many web applications, having some form of user account that can be leveraged to perform an attack.
Breaking it down even further, the type of external entity can be very important. Are you concerned with a targeted attack or more about opportunistic ones where someone might “meddle”? These two will potentially take very different approaches and this should be factored in as well.
If you don’t understand your attacker to at least a basic level you are not going to get the most value out of a penetration test. To make an analogy;
If you prepare yourself to defend against hand-to-hand combat but your enemy turns up with a shotgun, you may have been wasting your time.
Goal-based
Understanding your threats allows you to make penetration testing a goal-based activity. Hacking a web application is great but it’s not the hack that creates the impact, it’s the repercussions. An obvious example would be an app that processes credit cards. The goal of the penetration test may be to obtain credit card data.
By giving the test a focus it allows your penetration testing company and your security team (if you have one) to do more accurate threat modelling which, in turn, means closer alignment to real world techniques which == a better test.
Scoping
I’m not going to cover too much about scoping here, there’s a whole other post to cover that but don’t be too exclusive. Don’t rule out social engineering attacks, for example, if you feel this is a realistic threat for you. I struggle to think of many businesses where it isn’t.
Do I need a penetration test?
It depends.
I know, that’s not very helpful but it really does depend. If you have any kind of compliance requirement, PCI DSS for example, or CHECK or ISO27001, there’s probably an external factor that will force you to have one. But what if you don’t have to have one to meet a compliance objective?
We’ll assume your business has something worth taking. So many businesses, mainly smaller ones, assume they have nothing of value to an attacker but that is a massive over-simplification. At the end of the day, there are so many types of attacker and they all want different things but if your business is making any kind of money then it has value. If it has value, criminals tend to sit up and take note.
So we’ll assume you have threats. If you want to understand how vulnerable you are to those threats then maybe a penetration test will be useful. However, I’m going to use my favourite analogy now - and the reason we have a picture of a man being punched on our home page.
If you were going to have a fight with a heavyweight boxer, you wouldn’t just get in the ring. You can predict the outcome without enduring the pain of the inevitable knockout. You would do some training first.
Let’s say you’ve written a web application but, thus far, you have not specifically considered security at any point in the software development lifecycle. There’s a very high possibility that a penetration test is going to uncover quite a large number of issues. Is this good use of time and budget?
We’ve had great success with a number of clients where we just talked to them beforehand. We talked to their developers and asked them questions about common vulnerabilities, like “do you know what SQL Injection is and how do you defend against it in your application?”. Based on the responses we receive we can make a fairly educated guess about the likely resilience of the application to attack.
Does that mean we shouldn’t pentest it? Not necessarily, a lot of clients still like to know “how bad it is” and penetration testing can help to make it real and get it on the agenda. I get that, this isn’t a utopia where boards just *get* the need to spend money on theoretical issues.
Penetration Test Options
But there are options. We did some work with a start-up software-based business recently which we broke into two phases. The first was a short, time-limited penetration test of their web application. Essentially an OWASP Top Ten tyre-kicker focused on breadth rather than depth. The second phase was a review of their processes, understanding of security, software development lifecycle, system configuration and so on.
This was great for these guys. To assess the app fully was probably five days work. We did a two day test, found a few critical issues and then talked to them about what we’d found and sought to understand how these issues had occurred. Our report was then focused on short, medium and long term goals to improve their overall security approach rather than a massive list of individual issues to wade through. Although they did of course remediate the issues identified as well, but from a root cause perspective.
Consider all your options. Talk to your penetration testing company, talk to us! Make sure you are getting the right solution for your business.
In summary
So, to sum up, a penetration test simulates a real attack against your systems.
What defines a real attack will depend on your organisation but certainly there is commonality, particularly across industry sectors.
A penetration test should probably form part of your overall assurance programme but isn’t necessarily the best place to start.
