Having conducted thousands of penetration tests over the years, we can confidently say that a pen test is only as effective as the planning and preparation behind it. Simply commissioning a test without it can lead to wasted resources and limited insights.
As Benjamin Franklin famously said, “By failing to prepare, you are preparing to fail“.
Those who conduct regular testing should know all about planning and preparation, however, if you’re new to testing, or you only perform testing periodically, what do you need to have in place to ensure your test runs as effectively as possible, providing you with the best possible results that deliver real value for money?
That’s exactly what this insight sets out to explain.
But before we do, let’s start with some assumptions:
- A discussion between the client, the dedicated Account Manager and the Consultant has already been conducted. This call outlines why you are testing, and what your concerns are and allows for a demonstration of the environment. These steps are important as they will enable the consultant to ask questions about the asset undergoing assessment and allow them to accurately estimate the time required to cover the scope.
- An agreement has been signed for the work to be carried out.
- The scheduling team has allocated a resource to the assessment for a date when the test will be carried out.
General Prerequisites
Before starting the testing phase, several general prerequisites must be in place. These requirements have been refined and documented over the years to prevent any delays during testing.
Your Account Manager will clearly outline this list of necessary prerequisites ahead of time, as well as include it in your test proposal. This will provide ample time to ensure that all requirements are in place before testing begins.
The following elements will be included in this list and contain essential information:
- Authorisation Form – A form sent by the Account Manager to the point of contact. Ahead of testing, before any testing can occur it needs to be completed accurately, signed and returned. This document needs to contain a list of all targets undergoing assessment.
- Third-Party Authorisation – Pentest ask that if your environment is not self-hosted, authorisation from the third-party supplier is obtained. Pentest will not ask to see this and will trust that you have completed the process if the Authorisation Form is signed and returned.
- Change Requests – Ensure that any change requests have been agreed to ensure that testing can be carried out on the desired date.
- Point of Contact – An email address and contact number for the person who the consultant would reach out to if there were any questions or problems encountered.
- IP Address Ranges – To allow organisations to know where our traffic will be coming from and to allow us through defences. Why do we ask to be allowed past defences? We ask for this so we can assess the quality of the target opposed to the effectiveness of the defences.
Once these general requirements have been outlined, test specific requirements will be the next discussion.
Test Specific Requirements
Each test has its own unique set of requirements, and the success or failure of the assessment often depends on the willingness to provide accurate and up-to-date information.
When such information is unavailable or inaccurate, it can hinder the assessment, leaving it in a state of limbo until a response is received. Although this situation occurs infrequently, these delays can gradually encroach upon the assessment window, which is crucial for analysing the security posture for significant misconfigurations.
Common stumbling blocks include but are not limited to:
- Inaccurate information within the consent form.
- Absence of Postman or Swagger files for assessing APIs; additionally, no test data is supplied.
- Absence of complete collection of API endpoints; this would result in undocumented endpoints not being assessed.
- Encrypted mobile applications.
- Mobile applications with defensive mechanisms, such as jailbreak/root detection or enforced SSL pinning.
- No testing accounts created for the assessment.
- Absence of testing data on the application.
Most of these issues can be addressed by having a thorough understanding of the asset being assessed and by reviewing the documents provided by the Account Managers.
As mentioned earlier, each test has its own unique requirements. If these requirements are met, along with the general prerequisites, the assessment can typically proceed without problems 99% of the time.
The remaining 1% pertains to unique configurations that may require some form of interaction from the organisation’s side. For example, if there are no trunking ports available for internal assessments, certain network areas may become inaccessible. In such cases, the consultant would need to request a change in the VLAN to continue their assessment. This is why it is important to have a contact person outlined and available during the testing window, as resolving these issues can be time-consuming if they are not present.
Below are some examples of popular engagements and a brief overview of their specific test requirements:
Web Application & API
- All URLs to be provided, including any supporting APIs – Without this information the consultant may not be able to touch pivotal parts of the functionality leading to it not undergoing assessment.
- Creation of testing accounts – Typically two roles per user level undergoing assessment, this allows the consultant to test for horizontal, and vertical privilege escalation.
- Two tenants – If the application supports tenancy, accounts created in multiple tenants to enable for cross tenancy checks to be carried out.
- Testing Data – Provisioning of testing data within the environment to ensure the tester can accurately understand what is required and to assist with assessment of functionality.
- API Documentation – Provide details of all API endpoints, this can be achieved in the form of a Swagger, or Postman, document. In addition to this, if test data for parameters cannot be easily obtained, example data.
- Emails – If the environment sends email, and requires some form of allow listing, the testers email addresses to be added so they can assess the functionality thoroughly.
- Source Code – Access to the applications source-code to assist with an intelligence driven assessment. The code will never be built out, rather only used to provide the consultant with knowledge of where critical flaws may exist that otherwise may have gone undiscovered.
Mobile Application
- Shielded & Unshielded Applications – Shielding refers to the implementation of protective, or defensive measures. These include encryption of the application, Root or Jailbreak detection, SSL Pinning or VM Detection. As the assessment is time limited, we require a version with (shielded) and a version without (Unshielded) of the application. The consultant will still try to bypass these protections, if implemented, however, if they were unable to, they could pivot to the application without and not have to wait.
- APK & IPA files – Access to the APK or IPA files directly so they can be installed on the tester’s emulator or physical device. Due to version issues, access to TestFlight for iOS may not be possible so ideally, we would prefer these to be sent directly to us.
- API Information – If part of the assessment was to understand the security posture of the supporting API, all information to assist with this would need to be provided such as API documentation, or target URL.
External Infrastructure
- Targets List – To allow the consultant to understand what needs to be assessed.
Internal Infrastructure and Network Segregation Testing
- Provisioning of the Drone – Internal assessments can be carried out remotely via drones. Drones come in the form of a physical laptop delivered to you and need to be connected into the network via an ethernet cable. Alternatively, if your network supports virtualisation, a VM can be created connected to the relevant networks. Once created, or connected, Pentest will supply a script that could be executed on the VM, that communicates back and will allow remote connection.
- On-site – If the assessment cannot be delivered remotely via the means mentioned above this will require a consultant to come on site. If this were the case the requirements would be to:
- Provision a desk and chair in an area whereby network connection would be possible along with a power point to allow the consultant to connect their laptop.
- Allocate a point of contact to ask for on the day.
- The address of where the assessment was to be carried out.
Further information about these requirements will be provided when the test has been agreed, and the preparation phase is being carried out. Throughout this phase, if you have any questions, reach out, your Account Manager would be happy to assist or find a technical resource that can answer your queries.
Conclusion
Preparing for your test is crucial to ensure a smooth testing experience and maximize the value delivered. When considering penetration testing, it’s important to understand that it represents a specific point in time and is limited in duration. So, by preparing before the testing window, you give your tester the necessary information to perform effectively from the start.
While some of the preparation requirements outlined may seem excessive, it’s essential to remember that threat actors have all the time they need to target assets. Rigorous preparation and meeting pre-test requirements will therefore equip both you and the tester for success within the allocated timeframe.
We often find that clients who fulfil all pre-test requirements emerge from assessments with more high-value vulnerabilities. This can happen when the assessment focuses on the application rather than the defences themselves, indicating that resilience against attacks was not a priority but rather adopted to enhance the overall security posture. It also highlights the potential consequences if a threat actor successfully bypasses defences.
Another scenario could involve the consultant having access to the code, allowing them to use code scanning tools to identify concerning issues more effectively.
If you are considering a penetration test, why not get in contact? We would be happy to discuss your concerns, review your assets, and talk about what you would like to analyse or explore the possibility of working together in the future.
