Making the most out of your penetration test
The purpose of this article is to give you the information you need to have an easy, thorough penetration test that provides value to your company, is fair on your staff members and ensures that you get the most value you can out of your penetration test.
Penetration Testers: Foe or Friend
A penetration test can be a stressful time for companies, with pressure often being put on developers and system administrators by management to ‘pass’ the assessment. The test is seen as an assessment of their work and ability to create secure systems or write secure code. The reality is that we are all human and creating these systems is a complex task that often relies on multiple people working together. This approach creates an environment where the engagement is a battle between penetration tester and systems administrator/developer and it will ultimately result in the company not getting the most out of the penetration test.
A penetration tester should be viewed as a friend, someone who is there to help find any issues before a malicious threat actor exploits them and it becomes a potentially fatal problem for your company.
Taking a management approach, whereby relevant staff members are judged on how well they are able to respond, categorize and ultimately mitigate vulnerabilities, as opposed to how many vulnerabilities were discovered, will give you the best chances of making the most out of your penetration test, creating a scenario where the penetration tester and relevant staff member are working together to achieve the completion of a project.
Leave plenty of time
Sometimes it is unavoidable to have to perform a last minute penetration test; however, one should consider the level of stress this puts on your staff members. Typically, a penetration test requires your company to create a suitable environment for the consultants; this can be quite time consuming. Creating these environments in a rush may result in the environment not perfectly reflecting that of the live system with the report containing vulnerabilities that are not present in the live system. As it is likely the most common example of this happening, let’s take the following case study:
Company A have been told, on a Monday at 9am, that a prospective client requires a penetration test of Company A’s flagship product before they sign a large revenue deal. Management and sales want to push the deal through as quickly as possible due to it being high revenue. They assure the client that everything will be completed for them in three weeks. They speak to the head of engineering or relevant position and give them a three week deadline to complete the penetration test and move forward with the deal.
Company A contact TrustFoundry on Tuesday and ask them to perform a penetration test, leading to a scoping call with one of the consultants. Company A have all of the relevant information about the web application and Trustfoundry are able to complete the scoping and send a proposal within the same day. The proposal is for a total of 5 days of testing, including reporting.
On Wednesday, the proposal is sent to finance who are not able to get all of the relevant sign off until Friday afternoon. On the following Monday, dates are confirmed by TrustFoundry to start testing on the following Monday, with the ability to get the report to the company on the final day of their deadline. This allows as much time as possible for company A to get the environment sorted.
The developer of the web application needs to create an exact replica environment, create dummy data and create accounts. As this test was booked last minute, the developer has a few calls and other meetings booked in through this week which makes the completing everything in time for the assessment hugely stressful. Due to this, an exact copy of the environment is not possible and the environment is made to mimic live as closely it can.
The penetration test is performed smoothly and the report is delivered on time; however, there are two critical and three high risk vulnerabilities that the client will not accept, nor do management want them to see the issues in the report. There are also multiple medium risk vulnerabilities relating to TLS and underlying server configurations in the report that are not representative of the live system.
The prospective client contacts Company A the following Monday and asks if everything has been completed within the time they asked. The developers have to mitigate 5 issues and also investigate which issues are not relevant to the live environment. Once the issues have been mitigated, re-testing needs to be booked in and performed. The developers estimate it will take a minimum of two weeks to complete the required work.
If a more realistic, eight week time-frame was given to the head of development, the developer would have been given enough time to complete the environment so that it was an exact replica of live, preventing the TLS and underlying server vulnerabilities from being reported in the first place. There would have been sufficient time for the developers to fix the vulnerabilities and have them re-tested. The company would not be in an awkward position with the prospective client where they have missed a deadline before signing them as a client.
Remove third-party defenses
The purpose of a penetration test is to assess the underlying code of an application or the configuration of network services. There are often third-party defenses that can be put in place as an additional layer of security such as a Web Application Firewall (WAF), Intrusion Prevention System (IPS), Intrusion Detection System (IDS), etc.
If these defenses are left on during a penetration test there can be no guarantee that the report will reflect the vulnerabilities that are present in the underlying code or system. If they are removed for testing purposes, the underlying code or system can be properly assessed for vulnerabilities and then the third-party defenses can be re-enabled for an extra layer of security. A web application firewall doesn’t make your web application secure, writing secure code does. Let’s take a look at the following common scenario:
Company A book a web application penetration test and make the decision that they would like to keep their WAF enabled.
An assessment is performed against the application and no injection related vulnerabilities were identified but it was noted that a WAF was in place that blocked common injection payloads. Company A are happy and continue business as usual.
Three weeks later they have a major security breach and all of their database has been stolen. Upon investigating the issue, they found that two days before the breach, a new WAF bypass payload was released for SQL injection, relating to the WAF they are using. The WAF is now considered useless against this type of payload and it is up to the underlying codebase of the application to be secure against any attacks. The malicious threat actors exploited the SQL injection vulnerability and managed to compromise and exfiltrate the entire database. Company A are now in serious trouble.
If the WAF was disabled for the assessment, it is likely that the SQL injection vulnerability would have been picked up and mitigated prior to it being exploited by the malicious threat actor. WAF bypasses are common; a Google search for your ‘<your WAF name> bypasses’ will likely bring up many payloads that have worked at some point in time. This does not mean they currently work.
If you do remove third-party defenses for your assessment and any critical or high risk issues are found, ask the consultant to re-test the issues with the defenses enabled. It can be reflected in your report that the issues are present in the underlying code base but at the time of exploitation, the defense would have stopped it from being successful.
Assign a technical contact for the duration of the test
A technical contact that has a good understanding of the system that is being tested should be assigned, with a purposely light workload during the assessment. This is to ensure that the contact can respond to and help with any queries or questions. It also ensures that if a critical or high risk finding is discovered (of which we will contact you in advance of the final report delivery), it can be analysed and potentially fixed before the end of the assessment and we can reflect that this in the report.
Understand your objectives
Understanding your own requirements for a penetration test ensures that the assessment can be tailored directly to your needs. For example, if you have any specific concerns about pieces of functionality within the application, we can ensure that these are highlighted in the report. We can also test specific parts of an application, if the requirement does not need the entirety of the application assessed. Understanding your objectives will allow you to get the most out of your assessment and it could even save you money.
Encourage a post-test call
Encourage your team to take part in a post-test call with the consultant. During this call, the consultant will run through the report, explaining the findings. This gives a great opportunity for your team to ask questions and give internal intelligence that could result in vulnerability ratings being lowered. If your team is not able to implement a fix for a vulnerability, we may be able to give you another solution. The more you speak to us, the more we can help.
