How do penetration tests work?
These are my own personal thoughts and options on how a penetration test (often referred to as “pentest”) should work. This post is written from the perspective of a penetration tester with years of experience and is aimed at management level personnel who want to better understand the process of a penetration test engagement.
Reasons to do a pentest
You have developed an application (in-house or outsourced), purchased an application (commercial off the shelf product), or purchased a software as a service (SaaS) and have concerns or compliance requirements regarding the security of the application or data stored. These concerns can be broadly categorised, in that an adversary or malicious user could:
- exploit the application to gain access to the hosting infrastructure;
- exploit the application to manipulate the business logic and perform malicious actions;
- exploit the application to exfiltrate sensitive data;
- exploit the application to compromise user accounts.
These concerns carry a risk to the business such as the compromise of the internal network, a direct financial loss or indirect financial loss through the loss of customers, the loss of intellectual property, reputational damage or legal and compliance issues.
How a pentest works
You will engage with a penetration testing service provider who will be doing the work. Depending on the provider, hopefully someone technical will be scoping the application to decide how long it will take. This is honestly the hardest part because the provider will need to understand exactly how complex the application is. The best thing you can do when getting the application scoped is to provide the consultant access to the application.
The penetration test will be performed against the application you specified. However, a number of secondary systems such as load balancers, caching systems, analytics systems, logging platforms, web application firewalls, email gateways, database systems, identity platforms and integration services will be impacted by proxy.
What is required
The pentester needs to access all functionality. Anything inaccessible will not be tested and could be left vulnerable.
The pentester should have access to the source code if available. This provides you with better value for money and a higher level of reassurance that the application is secure. I will admit there are risks involved and I understand that source code is often intellectual property. Please try to work around these issues with the pentester. Maybe let them access it via remote desktop services or have them come onsite.
The application should be in a development or testing environment. Penetration tests will involve sending the application large amounts of unexpected data which will result in unexpected behaviour. In my experience this is often a little overstated, and an experienced penetration testers will rarely cause issues that impact other users of the application. If you're confident about the security of the application and have backups then by all means test in production.
The pentester needs to use his/her own device. This is relevant for internal application tests in environments where you don't allow personal devices on the network. I recommend you make the exception as we often use very customized configurations, our tools will get detected by your antivirus and we will not have access to our notes, payloads lists and contacts. It just wastes time that could be used in testing the application.
The pentester needs at least 2 accounts at all privilege levels. Can a standard user perform admin functionality? Can a standard user access the information entered by another standard user?
The environment being penetration tested should have the web application firewall disabled. Web application firewalls serve the purpose of blocking anything that looks malicious. This makes testing the application for vulnerabilities difficult and we will just end up testing the effectiveness of the web application firewall.
What we do
A web application running in a web browser communicates with a server using various protocols that have strict specifications. The HyperText Transfer Protocol (HTTP) is the glue that defines the format used to transfer data between the client and server. Under normal usage the web browser follows the protocol specifications and the web application behaviors as intended.
A penetration tester will intercept the communications between the web browser and server. This allows the manipulation of the HTTP protocol specification, data transfer protocols that the application uses and the data itself.
The object is to manipulate the protocols and data to cause bugs that have security consequences. The security consequences could be disclosing sensitive data in the application, running code on the backend servers, injecting code that runs in the context of another user's browsers, bypassing authorization checks or manipulating data in a database. There are hundreds of methods that a penetration testers will use to uncover these issues.
What a good pentest should give you
A good penetration test should provide you with a verified list of findings that are actionable, have a business impact and improve the overall security of the application without adverse side effects. These findings should be detailed enough, preferably with a proof of concept so that the development team are able to reproduce if necessary and remediate.
I’m a little bit of a purist in that I dislike findings that are listed for the sake of having more findings. Projects and development teams have limited resources, so these types of findings just make unnecessary work and benefit noone. If you get a penetration test report with questionable findings, consult your development team (or someone technical) and challenge the pentester if you disagree. You are well within your right to call out false positives or misinformation and I encourage you to do so.
What a pentest is not
A penetration test is not a guarantee that the application is secure. However, it does provide a high level of reassurance that the application is secure against current publicly known methods and vulnerabilities.
Unfortunately, new methods and vulnerability are discovered all the time. These methods are often discovered by security researchers who dedicate months researching a given piece of software or solution consisting of multiple software packages. It is the penetration tester's job to be aware of the latest methods and vulnerabilities when performing penetration tests. There is however a limit as to about much research a penetration testers can do within the timeframe of an engagement.