The requirement to perform a penetration (pen) test, be that on infrastructure, applications, employees, cloud environments, etc., may derive from a range of sources. Compliance to standards such as the Payment Card Industry Data Security Standard (PCI DSS), requests from clients and needing to conform to security policies are some of the main drivers for undertaking a technical security assessment.
With these external drivers to conduct penetration tests, they can often be seen as box-ticking and costly exercises, with little flexibility for tailoring. However, such a view can prevent organisations from extracting the maximum value from penetration testing.
In this blog, URM will provide some hints and tips on what steps your organisation can take to prepare for a penetration test in order to maximise the value obtained from the assessment whilst minimising any costs.
Understand the Requirements for Your Pen Test
The first thing we recommend is to understand why you need to undertake a pen test. This will help you identify what assets need to be tested and define the best testing approach to satisfy the requirements. As a consequence, this will ensure that all assets which need to be tested are included, unnecessary assets are excluded, the right amount of budget is allocated and the most effective approach to satisfy the requirements is selected.
What to test
When the source requirement comes from the need to comply with an industry standard, the standard usually defines what needs to be in scope for the penetration test. However, it may not be as easy to determine what to test in other scenarios.
As an example, if you’re offering a business solution for your clients in the form of a web application hosted on AWS and you need to provide assurance to your clients that your solution is secure, you may consider testing the web application from an application layer, but also the underlying infrastructure exposed to the Internet. You may also consider performing a configuration review of your AWS environment to provide assurance that different attack vectors are covered. Conversely, performing an internal infrastructure penetration test of your corporate network may not be relevant for this requirement if your AWS environment is completely segregated from your corporate network.
Testing the appropriate assets will provide you with the greatest reassurance that your requirements are satisfied. Conversely, selecting the wrong assets or not including important assets in the scope of the test may have unbudgeted cost implications or leave you vulnerable to attacks. If unsure, speaking with an experienced pen test provider can help you identify those assets you should consider including in the pen test scope.
The following are some examples of assets that can be tested:
- Web applications
- External infrastructure
- Internal infrastructure
- Segmentation between networks
- Wireless networks
- Cloud environments
- Remote access solutions
- Mobile applications
- Employees resilience against phishing attacks
- Physical security of buildings
- Docker images
- Servers/workstations configurations.
Define the approach
As opposed to deciding what assets to test, when it comes to the approach to adopt when performing a pen test, there is not a lot of guidance – even from the standards. For example, the PCI DSS doesn’t specify if an internal penetration test needs to be performed from an unauthenticated user perspective, or if it needs to be performed from a compromised user or server perspective. External requirements, including standards, may not always specify if the test needs to be performed using a black, white or grey box approach or if a time-boxed pen test is acceptable.
This lack of guidance may leave you asking questions such as:
- When testing an internal network, should testing be performed from the perspective of an unauthenticated user to simulate an external third party who has plugged in a device to the network?
- Or, should it be performed from a low privilege domain user to simulate a user account compromised through a phishing attack?
- If you’re on a limited budget, does performing a time-boxed assessment make most sentence?
Whilst it is tricky selecting the optimum approach, getting it right allows you to both satisfy the requirements for the pen test whilst minimising the cost involved. Conversely, adopting an inappropriate approach may not only fail to satisfy the testing requirements, but could also lead to unnecessary high costs. As with deciding what assets to test, if unsure, speaking with an experienced pen test provider can help you identify the best approach to adopt to satisfy your requirements.
Different types of approach to consider include:
- Black Box
- White Box
- Grey Box
- Time boxed
- Standard
- Focused (specific new web app functionality, authenticated review of a few critical servers / services, phishing against a specific department, etc.)
Set Specific Objectives for Your Pen Test
Here, URM advises you not to set very generic objectives such as ensuring:
- A pen test of the internal network is performed to check its security posture or
- An authenticated web application pen test is performed to assess the overall security of the application.
In order to maximise the benefit of a pen test, it is essential the test is tailored to your specific risks. As such, assessing the particular threats to your organisation and to the in-scope environment is a key prerequisite in ensuring your pen tests are tailored to your risks and controls.
For example, in most cases, performing an unauthenticated internal pen test on a private virtual network in Azure will not provide much value. For most organisations, the risk of an unauthorised third party being able to connect a physical device to their cloud-hosted internal network or deploy a VM without any credentials is very low.
In the same way, if your budget is limited, testing a web application from the perspective of a super admin user when the only two super admin users are trusted internal users may not be a priority if the application is normally used by several client organisations in a multi-tenanted environment.
Taking the example of a web application penetration test, we suggest a set of more specific and valuable objectives would be to gain assurance that:
- Projects/health/personal/financial data cannot be accessed by unauthorised users
- Low privilege users of clients cannot horizontally or vertically escalate privileges to access other low privilege users’ data or administrative functionalities
- Users from one client (including client admin users) cannot access data belonging to other clients of the application
- Client admin users cannot vertically escalate privileges and gain super admin privileges which should only be accessible to a limited number of trusted internal users
- Controls in place at the infrastructure level do not allow threat actors to compromise the hosting server.
Setting more specific objectives requires a certain understanding of the assets to be tested, both from a business and technical perspective. If you are unsure how to define your objectives, your pen test provider should be able to guide you through the process during the pen test scoping phase.
Having specific objectives and sharing them with the pen test provider will ensure that these will be tested and provide the level of assurance required.
Attach Importance to the Scoping Phase
The scoping phase is a critical part of the process, as this is where pen test providers can understand your requirements and objectives and provide a proposal that aims to satisfy these requirements in the best way possible.
Ideally, you should be looking to describe to your pen test provider why you need a pen test, what assets need to be tested and which specific objectives you would like to achieve. You may also have ideas on the approach to be taken. However, if unsure on any aspect, the scoping phase is a perfect opportunity to ask your pen test provider to help you in this process.
In this phase, it is important to share as much information as possible with the provider such as:
- Network diagrams
- Attack vectors you have identified
- Where do you see the biggest risks in respect of your assets
- Your business-critical assets
- A demo of the application to be tested
- Application programming interface (API) documentation.
It is important to understand that your pen test provider is your partner in security. The sooner they understand your systems or applications and learn what you know about the systems, the more effectively they will be able to find vulnerabilities.
Select the Most Appropriate Provider for You
Selecting the right provider can greatly increase the value you gain from your pen test. Here are some practical tips for selecting the right provider for you:
- Ensure the provider is qualified and experienced
- Ensure the actual penetration testers are involved in any scoping calls
- Select a provider who listens and responds to your requirements and not one which ‘pushes’ a standard service offering
- Request a sample report and examine whether findings are clearly explained, if the report provides steps to replicate the issues and whether remediation actions are clear and logical
- Explore whether the provider’s methodology fully meets your requirements, in particular where there is a requirement to test more unusual systems and assets such as mainframes, bespoke hardware or uncommon network protocols
- Ensure that the provider offers a debrief meeting and provides the opportunity for you to ask questions on findings from the test
- Investigate whether the provider offers a retest policy and what it comprises, as you will need reassurance that any remediation has been successful.
Preparing for Your Pen Test
It is not uncommon to find vulnerabilities that are easy to identify with automated tools during penetration tests. Identifying and reporting on these low hanging fruits will increase the time that pen testers will be able to allocate to discovering more complex vulnerabilities. There are a number of activities that you can conduct prior to a pen test being performed that will maximise the value which can be obtained from the test, such as:
- Ensuring you have an up-to-date inventory of all your assets
- Conducting regular vulnerability assessments to identify and remediate vulnerabilities that can be identified by automated tools
- Using authenticated vulnerability scans to identify hardening opportunities
- Implementing an effective and efficient patch management process that identifies and applies security patches as soon as possible
- Having a vulnerability management programme in place
- Changing default passwords
- Setting passwords – including your printers!
- Enabling multi-factor authentication (MFA) wherever possible
- Using anti-virus software
- For applications, using static application security testing (SAST), software component analysis (SCA) and dynamic application security testing (DAST) tools throughout the software development life cycle (SDLC).
Closing Thoughts
The pre-test period is critical in ensuring there is a clear understanding of the requirements for the pen test, it is correctly scoped, the objectives are clearly defined and the right provider is selected, all of which are essential building blocks for an effective and productive penetration test. By following the advice outlined in this blog and ensuring you have comprehensively prepared and collaborated with your pen tester prior to the test, you will be ideally placed to extract the maximum benefit from your penetration test when it is performed.
How URM can Help?
As a CREST-accredited penetration testing provider, URM can offer a wide range of penetration testing services to help your organisation proactively identify the vulnerabilities affecting its assets before they can be maliciously exploited by a threat actor, and subsequently improve its security posture.
For example, URM can provide infrastructure and network penetration testing services against all IP addresses associated with your organisation, location or service. This can be performed from either an internal or external perspective, with our external penetration testing providing you with insight into what harm a malicious actor could inflict relying only publicly available assets and information about your organisation. Meanwhile, our authenticated, internal pen testing services will allow you to establish how a compromised low-access user account could impact your network and infrastructure.
Depending on your requirements and objectives, URM can also offer website and mobile application penetration testing, cloud penetration testing, and business-led penetration testing, in which the scope of the penetration test is determined by the issues and concerns your organisation faces.
URM prides itself on the comprehensive and integrated CREST penetration testing services it delivers, supporting organisations through the whole penetration testing process, including during the post-test remediation period. The ultimate goal of any cyber security penetration testing is to amend the vulnerabilities which pose the greatest threat to your organisation’s assets and, as such, we will provide a free retest within 30 days of the original assessment of any high or critical risk vulnerabilities we have identified.
URM is pleased to provide a FREE 30 minute consultation on penetration testing for any UK-based organisation.
If you are unsure, URM can perform CREST-accredited internal and external penetration testing against all IP addresses associated with your organisation, location, or service.
Designed to assess the architecture, design and configuration of web applications, our web application pen tests use industry standard methodologies to identify vulnerabilities.
Are you getting the best value out of your penetration testing? URM’s blog discusses alternative approaches to penetration testing.
URM’s blog discusses the security risks associated with the software supply chain & how both software developers and their clients can mitigate these risks.
The consequences of unauthorised access are varied. Apart from financial losses, there is a loss of customer confidence. Can penetration testing prevent this?