Pen testing, short for ‘penetration testing’, is a method for testing the security of a system by using the same tools a hacker might use in order to see if it can be breached.
A social example of this might be a phone call trying to elicit secure information from an employee to test personnel processes, or intentional email phishing. In the development of software and IT, this article’s focus, pen testing is used to test the security of the design, system and code, for example protecting against malware and virus attacks, and unauthorised system access.
In an increasingly digital world where cyber attacks are on the rise, at least 30,000 websites are hacked every day and 93% of company networks are thought to be penetrable by cyber criminals, pen testing has become a fundamental part of the development of many products and platforms, offering organisations an extra layer of security and peace of mind.
Pen testing is only one of several methods we use at Calvium to ensure software security for our clients – including those projects we’ve developed for the security-focused defence sector. However, it feels particularly timely to write about the subject now, following our recently-approved application to have our Place Experience Platform (PEP) on the government’s public sector digital marketplace, G Cloud. We’re especially excited about this as it means we can now offer our services to the public sector market.
As part of our application, we had to demonstrate that our system had been pen tested, so we created a process to run internal penetration tests for the PEP’s content management system.
Fresh in our minds, this article will give an overview of pen testing, what’s involved in the process and share some key learnings from our own pen testing experiences – both as developers internally testing our own software, and working with accredited external testers.
Types of pen testing
There are a range of different tests you can do to test the security of a system. These are usually split into three levels: blackbox, whitebox and greybox.
Blackbox testing is the most realistic simulation of a cyberattack. This is when you approach a system with no knowledge about how it works on the inside; you’re simply trying to do something you’re not supposed to do and seeing if it allows you to hack the target system.
While the most realistic of the three, this kind of testing is usually more time-consuming and can leave some vulnerabilities unidentified given the pack of information provided.
Whitebox testing is when a tester has all the information about the target system; they know how it works on the inside and have some knowledge about how it could potentially be broken.
The purpose of whitebox testing is to identify potential weaknesses in areas such as logical vulnerabilities, security exposures and misconfigurations, and poorly written code. It is generally a more comprehensive kind of test, quicker to carry out and less likely to miss a vulnerability.
As you can probably guess, greybox testing is a mix of both of the above, where only limited information is shared. For this reason, it is usually more efficient than blackbox testing and useful to understand the level of access a privileged user could gain.
Pen testing process
Pen testing is most often, but not always, carried out by accredited third parties that are external to the client and developer. Accreditation is given through a scheme called CHECK, which is run by the National Cyber Security Centre, the official government body.
Although to some extent pen testing can be done in-house by a developer, in our experience certified external testers are hired by the client. We as the developers work with the testers, granting them appropriate access to systems and delivering any supporting documents required, in line with the client’s brief. Being externally reviewed in this way ensures the test results are as robust as possible – peace of mind for the clients, and the end users.
Pen testing usually happens towards the end of a project, or when substantially new feature sets are implemented, or when adding integration with new services and systems.
The actual testing lasts a few days. Our last project took three days to complete the test, which included the production of the report. In the majority of cases, the report generated goes to the client first, and is then shared with developers with a view to making any improvements.
In our most recently tested client project, we were the ones hosting and so we had a few calls with the third-party testers to run through the system and give them access to it. One further level of preparation required was in documenting the APIs we were using so that the external testers could quote for what they would need to test. These documents detailed the design and structure of the product, meaning the testers had information on the APIs prior to testing.
In addition to the external testing, we test internally between dev teams before a product is shown to any client. The next pen testing we will encounter will be when we add payment functionality to a product, which could potentially open up new vulnerabilities.
Before testing gets under way, we’ll sit down with stakeholders to identify what needs testing and then look to get permission from whomever runs what is being tested. We’ve got many things on cloud service providers like Amazon Web Services and Azure, for example, so we certainly wouldn’t want to start trying to randomly hack them without permission from Amazon and Microsoft first.
The scope of what a tester does varies greatly – from looking through code for mistakes, to searching for flaws in the backend, to attacking the frontend as a random internet user.
One benefit of using cloud-based or platform-as-a-service systems, such as the above, means we can take advantage of all the security measures Amazon, Microsoft and Google have developed. Another advantage is that risk can be ‘containerised’, given there are barriers set to seal off any risk.
In our experience, if pen testing is required as part of the project scope from the outset, it is possible to make decisions in the architecture which make it easier to test. For example, being able to easily deploy a new environment with the same configurations for safe testing away from live data.
Findings and post-report action
The report generated is known as a ‘findings report’, which highlights any vulnerabilities and adds reasons. It will include tables of findings with associated risk levels, ranging from critical to low or ‘For Information’, which guides the client to the implications of extra remedial work.
While testers are responsible for spotting potential issues and assigning a risk, they do not make any recommendations. It is up to the client to decide what action to take. Depending on the associated risk levels provided, they must weigh up the risk with the broader design and functionality restrictions and requirements.
When going through the report with the security representative from the client – usually a chief security officer – we then put forward our design and development recommendations to reevaluate the risk value in context. This is important because something may get reported as a risk but it might have been discussed at the outset as a factor in the design, which everyone understood from the initial phase.
Although we’ve never had anything alarming come up in the findings report, we have been made aware of occasional niche and interesting things, which gives us an opportunity to learn and improve. With our clients to-date, medium and below-rated issues can usually be addressed or discussed later depending on the context, impact, resource required and stage of the project.
As you would probably expect, remediating any issues that arise depends on the issue and implications. Sometimes testers will give a preview report so you can start working on issues before they finish, which helps to keep projects moving.