Our guide to penetration testing is written by our expert penetration testers and will give you a detailed overview of penetration testing. You can use the table of contents in the right-hand sidebar to navigate to different sections.
An Introduction to Penetration Testing
Penetration testing is a common way for companies to gain assurance and information about the security of their IT infrastructure and to identify any security vulnerabilities. But for many, it’s seen as a dark art, carried out by hoody-wearing geeks with confusing terminology and (excuse the pun) impenetrable reports that can be hard to interpret, let alone act on.
In truth, while pen testing can be a complex and highly technical field to work in, a good testing partner will guide you through the process and provide usable reports to help quickly improve a company’s security posture. When carried out over a period of time, pen testing provides valuable input into tracking the maturity of your security programme.
In this guide to pen testing, we’re going to break down the many different aspects of penetration testing and dispel the myths surrounding it.
Why Should You Carry Out Penetration Testing?
Without getting too philosophical, computer systems are an inherently human construction. We design them, build them, and operate them. They’re also ferociously complex, requiring years of training and experience to work with. No single person, however intelligent, understands every aspect of computers or their security.
As such, they are as flawed as their creators. Even the best IT architects, developers, and administrators work within their constraints, with misconfigurations, workarounds, changing requirements and differing feature sets making every IT system unique. Despite our best efforts, computer systems are hard to secure and constantly changing, and some people are out to take advantage of that fact.
Penetration testing is a form of ethical hacking, but ethical hacking is a broader concept, meaning there are differences. Our post on the difference between ethical hacking and penetration testing should help you gain a better understanding. Pen testing is the most widely recognised approach to carrying out in-depth reviews of computer systems and encompasses many different techniques and methods to assess their security risks. Pen tests can focus on individual applications and tools or look holistically at a wider system to identify security issues that present a risk to the business. This gives us the opportunity to fix those problems before a bad guy gets there first.
Vulnerability Assessment or Penetration Test?
A common place to start gathering information about the security of a computer system is with a vulnerability assessment. Commercial, off-the-shelf tools are used to scan the network and gather information about common vulnerabilities, misconfigurations, and missing updates on servers, computers and other devices on the network, all of which are collated into a report.
After identifying vulnerabilities, activities can then be targeted to fix them and make sure systems are updated and properly configured. This is a valuable exercise and one which should be carried out regularly, probably once a month for most companies.
Vulnerability Assessments are also a component of penetration testing and commonly form one aspect of the final report. However, penetration testing services go a step further by focusing on those high-value vulnerabilities and misconfigurations that could be exploited by a criminal hacker and validating whether an attack could be successfully mounted against them.
Using real-world exploit techniques and bespoke tooling, a pen test uses benign payloads to validate whether an exploit will work and demonstrate the end result of such an attack. The subsequent report shows how an attack on one system or component can be turned into part of a larger, more complex attack, adding significant detail to a basic vulnerability assessment. To learn more, our blog “The difference between a penetration test and a vulnerability scan” gives more insight into the topic.
Grey box, white box and black box penetration testing: what’s the difference?
When you schedule a penetration test, part of the process will involve defining the scope of the engagement. There are different terms to describe whether the tester will be given access to your systems or given no prior information, known as white box, black box and grey box testing.
In a white box test, you give the penetration tester explicit and extensive information about your IT infrastructure and/or target applications. This can include network architecture, information about servers and applications, endpoints, security controls, access permissions and so forth. This degree of information enables an in-depth and highly targeted test. The tester will identify and exploit as many vulnerabilities and threat vectors as possible without spending too much time on discovery and enumeration.
While this makes for a valuable and comprehensive assurance exercise, one potential downside of white box testing is that the amount of information given to the tester might cause them to approach the exercise differently than a would-be, less-informed attacker, meaning that the focus may not be placed on the highest real-risk areas. However, white box testing is extremely valuable for testing during the development phase of new applications and infrastructure as part of a ‘security by design’ approach.
Black box penetration testing
Black box penetration testing is a method of testing where the penetration tester is given no prior knowledge of the target environment. They are tasked with discovering and exploiting vulnerabilities from a completely outside perspective, simulating an external attack as an uninformed attacker.
While black-box testing could be called the most ‘authentic’ form of a simulated attack, it has drawbacks. Namely, attackers have unlimited time to devote to analysis and exploitation, while penetration testers are given a specific engagement period.
This is why black-box testing is generally used for specific scenarios, and white box and grey box testing more broadly for penetration testing. The latter two enable testers to use their time more efficiently and focus on testing and exploiting systems, rather than discovering and analysing them.
Grey box pen testing
This type of test is a hybrid of black and white box testing. In a grey box test, the tester is given some knowledge of the system’s internal structure but not as much information as in a white box test.
As an illustration, the information provided could include login credentials for each level of account, a network diagram and a list of administrative users.
The availability of this information allows the tester to use their time efficiently, improving their ability to detect and exploit vulnerabilities in a shorter amount of time and providing more granular recommendations.
Advantages and disadvantages of the different testing methodologies
White box, black box and grey box testing approaches have their own merits and are suitable for different exercises. It’s not a case that one method is better than the other. Instead, one methodology is better for a particular type of test.
Broadly speaking, we can think of differences between the three in terms of speed, efficiency and accuracy.
Black box testing tends to be the most realistic engagement type as the tester has less information and access, making for closer to real-world, but potentially slightly longer, process. This lack of knowledge and no provided access also heightens the likelihood that some vulnerabilities may be missed – especially those within obscure areas of the estate. This, in turn, undermines the assurance exercise.
Grey box testing may be slightly quicker than a black-box test, but the additional information enables a more efficient test. The information provided to the tester also helps them better direct their testing efforts to discover valid and valuable weaknesses.
White box testing may be the longest, and the most comprehensive. However, this depends on the focus of the test. While the amount of information may increase the length of the test as the tester may engage in activities such as code reviews, the high levels of access also mean that testers will be able to find an increased number of both internal and external vulnerabilities for remediation.
What method is best for my business?
The methodology you go for will depend on the goals of your exercise. Generally, we advise most customers to conduct a white or grey box assessment if they are looking to gain assurance about the security of their systems.
These tests tend to be more efficient and cost-effective for discovering security weaknesses than black-box tests. Grey box testing, in particular, is valuable for discerning the level of access a user could gain and exploit. Many companies will not go beyond white or grey box testing, content that their systems are well run and provide a generally good level of security.
However, as noted, these tests don’t accurately reflect a real-world attack, whereby an attacker could come from any angle at any time and exploit security weaknesses in unexpected ways. It doesn’t test how people, processes and technologies work under stress and in the face of the unknown.
For a more accurate test of real-world resilience, we call on the Red Team – a testing scenario that relies on a black-box methodology. The Red Team is a pen tester – or multiple pen testers – that simulates a real-world attack on your systems. They will typically have a loose goal, such as to gain access to an HR system or to extract a website’s underlying database but will be given free rein to do so however they can.
The Red Team will start with very little information beyond knowing the given target, hence why this is a “Black Box” test. This forces the Red Team to act the same way as an attacker would, gathering information about the systems they’re targeting and identifying the weaknesses they can exploit, simulating a real-world attack.
As a general rule, red teaming should be reserved for organisations that consider themselves to have a mature cyber security posture or a much larger attack surface that a capable adversary could exploit. If the organisation’s cyber security defences are weak, starting with a red team test makes little sense. Instead, the organisation should begin with white box and grey box assessments.
Read our post for a deeper dive into Pen Testing methodologies.
Most companies still take a traditional “walled garden” approach to secure their networks. The important servers, desktops and underlying IT infrastructure are placed behind a firewall protecting them from the wilds of the Internet, using security controls to allow only necessary information to flow in and out of the network.
This Trusted vs Untrusted model presents a challenge to attackers, and means they have to be inventive in their attempts to access the company’s crown jewels: an attacker starting with nothing needs to discover ways to get into the network.
Penetration testing of the external parts of a company’s network helps to identify those systems and servers that are presented to the Internet, whether they be email servers, websites, application servers, file transfer tools or other publicly accessible resources, and discover the ways in which an attacker may try to subvert them. Take a deeper dive and learn about internal vs external infrastructure penetration testing.
Conversely, if an attacker successfully breaches the outer wall and gains a foothold inside the network, internal testing gives a view of what they might find once they’re there. A vulnerability assessment typically isn’t aware of every application bug, system, device or default password, and has no awareness of how they interact with one another. Internal testing helps to create that bigger picture and use an attacker’s mindset to focus on the weak links.
This approach holds true for cloud-based assets as well. In order to use cloud-hosted systems, access must be provided for corporate users to build and configure them, and for customers and partners to use the resources once published. Assessing these systems is equally as important as for traditional networks, and ensures data is not exposed or left unprotected.
Web Application Testing
Earlier we touched on the public-facing resources a company may have earlier, and Web Applications make up a large proportion of those systems. These might include web-based email systems such as Outlook Web App, HR platforms, collaboration via SharePoint or an FTP tool, or other bespoke systems used by the company.
Increasingly these applications are moving into SaaS platforms – Software as a Service – where the software maker hosts it online on your behalf. However, it’s still common for these systems to be built and hosted on company-managed infrastructure, with access to them made available via a web server accessible over the internet.
Regardless of the approach, these systems can hold highly sensitive information about the business or the people who work for it, making them valuable targets for hackers and are not immune to vulnerabilities or misconfigurations.
Web application testing is an aspect of penetration testing that focuses on these applications, testing the application itself for flaws that an attacker could use to compromise the app and the data it processes. But there are two types of web app test to consider. An authenticated web app test assumes the tester has a valid login to the application and is focused on what the attacker can do when they have a foot on the inside. By contrast, in an unauthenticated web app test, the tester mimics the actions of a threat actor who is looking at the web application from an outside perspective without login details.
SaaS tools don’t get off lightly either, as a good web app test includes assessing apps and services hosted by third parties.
Mobile Application Testing
In a similar vein to web app testing, mobile app testing looks at applications designed and built to run on mobile devices, such as phones and tablets.
Modern mobile devices offer many security features for apps, such as Apple’s Secure Enclave, sandboxing, app signing, encryption, data isolation, authentication and privacy features, and secure communications. However, these features are entirely optional, and a poorly designed app may fail to properly incorporate secure functionality.
Mobile app testing is a way to ensure the apps your company designs and uses work in a secure manner and protect the data they process and store. App testing, whether it be for mobile or traditional desktop applications, is commonly done throughout the development lifecycle. However, it’s equally common to leave the security testing until the end of the development programme. For the highest levels of assurance, security testing should be done.
Other Testing Types
We’ve looked at the main test process elements of a penetration test, where the testers emulate the methods and tactics of a criminal hacker, but from a wider assurance perspective, there are many additional testing and assessment activities that can form part of a larger engagement.
Sticking with the more combative activities, simulated phishing can provide a valuable assessment of staff security awareness and identify weaknesses in processes or training. This can be expanded into related social engineering techniques such “vishing” (voice phishing) or physical pen tests – bypassing physical security measures to gain access to buildings or restricted areas. For a deeper dive into social engineering, visit our page dedicated to Cyber Security Month 2023.
Configuration assessment reviews can also provide assurance that underlying technical systems are configured to appropriate standards, including:
- Firewall configuration and rule sets
- Network segmentation and configuration
- Wireless network security
- Operating System configuration
- Virtualisation and data storage platforms
- Virtual desktop infrastructure
- Cloud and cloud app security
- API assessments
- Static code review
Red Team Testing
So far we’ve focussed on well-defined, carefully planned activities where the testers are working to assess a particular system, app, tool or platform. This is often referred to as White Box testing, where the Pen Testers are working closely with internal technical teams to carry out controlled tests in a non-destructive manner. Learn more about red team testing vs penetration testing here.
This approach is excellent for providing a high level of all-round assurance that systems are well configured and tested to a particular standard or baseline. Many companies will stop there, content that their systems are well run and provide a generally good level of security.
However, this approach doesn’t accurately reflect the real world, where an attacker could come from any angle at any time and exploit security weaknesses in unexpected ways. It doesn’t test how people, processes and technologies work under stress and in the face of the unknown.
For a more accurate test of real-world resilience, we call on the Red Team.
The Red Team is still working for you – they’re not out to deliberately cause damage to your systems – but they’re not working with you. The Red Team acts like a bad guy and will typically have a loose goal, such as to gain access to a HR system or to extract a website’s underlying database, but will be given free rein to do so however they can.
To make life harder for them, the Red Team will often start with very little information beyond knowing the given target, making this a “Black Box” test. This forces the Red Team to act in the same way an attacker would, gathering information about the systems they’re targeting and identifying the weaknesses they can exploit, simulating a real-world attack.
They have the remit to try and achieve this goal using all the tools, techniques and tactics at their disposal. You won’t know when the simulated attack will start, which systems they will target, or what methods they will use to achieve their goal.
A Red Team test is designed not only to prove how easy or difficult it might be for the attacker but also to assess the defensive response to the attack. The defenders, or Blue Team, are typically made up of your IT team, security team, and maybe an MSP or MSSP, plus all their security tools and controls. The Blue Team’s ability to detect and thwart the Red Team is an equally valuable outcome of the activity.
A Red Team test is an excellent way to assess the effectiveness of defences and the capabilities of detection tools such as SIEM, Antimalware, firewalls, IPS/IDS/FIM etc. More importantly, it helps to identify if the necessary systems and processes are in place and fully working to enable the company to successfully prevent a targeted cyber-attack.
When Should You Get A Pen Test?
Pen testing covers such a range of activities that it can be used as an assurance tool in many ways and at different times.
Alternatively, a programme of testing activities could be spread throughout the year, focussing on different systems each time, coinciding with the release of new apps or testing substantial system changes. Similarly, these activities could vary in approach from a static code analysis one month, to a Red Team activity the next or testing app security against one of the many methodologies such as OWASP or OSSTM. For a more detailed look at when to pen test, our blog “What is a pen test and when do you need one?” explains all.
The most common penetration testing tools
A penetration tester relies on a wide range of tools, as well as specialist knowledge.
These tools typically come in the form of software applications that can assist the tester in finding and exploiting vulnerabilities. The tools the tester deploys will depend on their personal preference, company guidance, and penetration test type. Some tools are commercial and need to be licensed and paid for, others are open source and can be used without cost. One noteworthy platform is Kali Linux, a Linux-based Operating System that amalgamates various penetration testing tools into one cohesive platform. This operating system helps pen testers to streamline their workflows, enabling them to make use of one central interface to perform an array of testing exercises. Many of the tools we mention below can be found in Kali Linux.
As well as this, testers often create their own in-house tools, such as scripts for specific tasks. Given this, testers will use a wide range of tools depending on the use case, but the main types of tools used can be categorised, as set out below.
Once the tester and client have defined the scope of the test, the test begins with the reconnaissance phase. Here, the tester collates as much open-source intelligence as possible about their target. They often turn to public search engines and social media to do this. However, penetration testers don’t simply comb through Google or Facebook as you or I would. Instead, they use OSINT services that speed up the data mining process.
One of the most well-known tools for this is Spyse – a specialist cyber security search engine designed to assist security professionals in discovering technical information about different internet entities and businesses. Many penetration testers also use Shodan, a tool that searches for devices connected to the internet. Unlike search engines, which identify websites, Shodan discovers data about laptops, servers and other connected devices. This information includes metadata, like the software used by each device.
Another well-known reconnaissance tool is Maltego, which excels at information gathering and data mining. The tool uses graphical analysis to create patterns and multiple order connections from the information it finds. Lastly, theHarvester works to mine email accounts, subdomain names, open ports and more corporate information from public sources.
Ports are virtual locations within an operating system that facilitate network communications. Every computer has two kinds of network ports: TCP and UDP. Each port has a unique port number, which is also associated with the host’s Internal Protocol (“IP”) address. These numbers enable the network to know where to send data packets.
Internet-connected devices rely on ports to function and communicate. However, open ports can become a gateway for malicious actors if the service that listens on the port is misconfigured or unpatched. Therefore, port scanning is an essential part of penetration testing.
Port scanners automatically and rapidly discover open ports within a system. This, in turn, helps the penetration tester to understand how the network works and what applications run on it. From there, they can assess for potential infiltration points, diagnose network issues and discover application misconfigurations. Typically, penetration testers use port scans early in the penetration testing process – during the reconnaissance and discovery phases. Perhaps the best-known port scanning tool is Nmap but vulnerability scanning tools like Nessus can also be used for port scanning.
In addition to, and sometimes as part of, a port scanner – but with different objectives – is an SSL scanner. As context, SSL is an acronym for Secure Sockets Layer. This is a security protocol used to encrypt the connection between a web server and web browser. SSL certificates are necessary to secure data, including customer credit or debit card data, during online transactions. However, SSL is not immune to misconfigurations or vulnerabilities.
In order to achieve assurance that SSL has been implemented effectively and in line with best practices, penetration testers can use SSL scanners. These are automated tools used to discover common vulnerabilities or misconfigurations relating to SSL, such as the POODLE or beast vulnerabilities, or the use of outdated ciphers or inappropriate certificates. One of the most popular tools is Testssl, which scans ports for TLS/SSL ciphers, protocols and cryptographic flaws.
A vulnerability scan is an automated process that proactively identifies security vulnerabilities within a network or individual system. Most organisations regularly perform vulnerability scans as part of their vulnerability management programmes, but they are also an essential tool for penetration testing.
Because vulnerability scans do not involve human intervention, they are quick and fast. Once complete, the scanner creates a prioritised list of security flaws for the pen-tester to review, typically prioritised on the CVSS 3.1 vulnerability scoring methodology. The pen-tester uses these results to identify potential vulnerabilities for manual testing. Standard tools for vulnerability scanning include OpenVAS, Rapid7 and Qualys. For web application vulnerability scanning, a go-to tool is Nikto. Please read our blog on the differences between vulnerability scanning and penetration testing for a detailed overview of vulnerability scanning.
For web application pen testing, another well-known tool is dirsearch – a command-line tool that penetration testers can use to discover hidden files within the directories and sub-directories of the targeted web server.
Network protocol analyser
A network protocol analyser – colloquially known as a network sniffer – monitors and captures data packets as they pass through the network. Testers use it to passively collect information about the contents and sources of data packets. These can include sensitive information relating to email traffic, chat sessions, web traffic and even exposed credentials and passwords.
With this data, the tester can determine where information is going, the devices it came from, and the systems, applications, services and protocols it uses. The pen tester can discover vulnerable packets and broader network vulnerabilities by capturing granular details about these data packets. Common weaknesses found using these tools include parameter pollution, SQL injections, insufficient input validation, and buffer overflows. The most well-known network protocol analyser is Wireshark.
A web proxy is an essential tool for web application penetration testing. These tools act as a middleman between the browser and the web application, capturing users’ actions as they navigate through an application. Using these details, the proxy builds a virtual map of the application and how it is used. It will then flag any vulnerabilities discovered as requests and responses are sent to each page – such as a hidden form field or weak HTML features. Standard web proxy tools include Burpsuite and OWASP’s ZAP.
When a user enters their password onto a device or into an application, the hashed version is compared with a stored hash of the user’s authentic password. If the two matches, then the user is authenticated and allowed to use the device or application. However, even hashed passwords are vulnerable to threats.
Password crackers are tools that penetration testers use to discover weak passwords, putting the organisation at risk of exploitation. There are several methods of password cracking. Firstly, as noted above, testers can use network protocol analysers to intercept passwords as they are transmitted over the network. If this data is transmitted in clear text, the pen tester can quickly log in to the impacted account.
Another means of exploiting weak passwords is known as a dictionary attack. This involves using an automated tool that attempts to log in to an account using a pre-defined set of words. This can be the dictionary or a database of combinations put together by the pen-tester. This type of tool is only effective for cracking weak and common passwords. Moreover, in cases where multi-factor authentication or lock-out mechanisms are enabled, these tools have their limitations. The most well-known password cracking tools are John the Ripper and Hashcat.
As well as these types of tools, penetration testers will also utilise reporting and note-taking tools, such as Scratchpad, OneNote and Circacode. The testers use these tools to record their findings accurately and deliver valuable recommendations at the end of the test. There are advantages to both methods, but you can learn more in our blog about manual penetration testing vs automated tools.
What should a good penetration testing report include?
Penetration testing report structure
It is paramount that you find the penetration testing report useful and insightful. This is because the purpose of the report is to support you in improving your security posture by identifying vulnerabilities and their associated remediations.
A plain list of all the vulnerabilities found during the exercise is unhelpful. Instead, the report should take on a clear and concise structure, providing a narrative of what was tested, how it was tested, and the consequent results and actions – in order of urgency.
Commonly, reports take the following structure:
Executive Summary & Test Information
- Overview of findings
- Overview of recommendations
- Scope of work
- Test objectives
- Assumptions and constraints
- Test methodology followed
- Summary of findings and risk levels
- Summary of recommendations
- Prioritised recommendations
- Supporting information, including on how risks levels are set
Technical Report/Detailed Findings
- Vulnerabilities identified
- Risk ratings
- References / links to further resources / reading
- Remediation recommendations
- Tools used
- Detailed methodology information
The reason for having multiple sections is due to the different audiences that will review the report findings. The executive summary is aimed at senior management and business leaders, while the methodology and detailed findings are intended for IT and information security personnel.
Executive Summary & Test Information
All penetration testing reports should begin with an executive or management summary and key information about the test.
The executive/management summary should be written in plain English, for the benefit of risk owners and management at the client’s organisation. It should focus on business risk as opposed to technical details, highlight the most pressing issues that arose from testing and a brief overview of the remedial actions that need to be taken.
Test information should include details about the scope of the test, the client’s objectives, and assumptions that were relied upon or constraints that were applied, which the client should take into account when considering the overall assessment of business risk. Information about the testing methodology applied should also be included.
The test findings section will include more information on each of the vulnerabilities identified, the risk level associated with each one and a summary of the specific remediation guidance for each of the listed vulnerabilities.
It will include a risk rating methodology used to calculate the severity of discovered vulnerabilities. Assigning a severity score to vulnerabilities is essential for prioritising remediation.
Usually, risk ratings are informed by industry-standard scores such as CVSS, but can also be influenced by other factors to provide a more accurate rating that is more applicable to the specific environment the vulnerable system exists in, resulting in a low, medium, high or critical rating, escalating in severity and criticality.
Technical Report / Detailed Findings
This report section provides granular details on the vulnerabilities that the penetration testers discovered during the exercise. You should look for reports that present these findings in a clear and structured way so that they are easy to understand.
Each finding should include a clear description of the source of the vulnerability, details of the affected hosts, a concurrent vulnerability rating, an analysis of the potential impact should a threat actor be able to exploit the weakness and recommendations for remediating the issue. Evidence, such as a screenshot image, should ideally be provided for each issue identified as well.
The technical report should also include references from industry sources that provide further reading on the vulnerability and remediation steps. These are usually publicly available resources, which are accessible online from a hyperlink provided by the tester.
Ancillary information which may be helpful to the client, but which is not central to the report or its recommendations, should be provided in the appendices. Such information often includes details on the tools used during the test and more detailed information on the testing techniques and tactics followed.
Wash Up Meeting
Once you have received the report, a good penetration testing partner will offer to have a ‘wash-up’ call with your team to talk through the test findings and answer any questions about risks or remediation advice.
The report should be clear, easy to read and provide enough information to enable the client to take actionable steps, but questions commonly arise. The wash-up session enables you to query unexpected findings, understand the implications of the risks identified and discuss remediation options.
How much should you expect to pay for a penetration test?
In our recent blog on penetration testing costs, we explain why making sure that the quality of the service and accreditations of testers should be a priority over the budget option for organisations when choosing a pen testing vendor. We also discuss the average cost you can expect to pay for penetration testing services in the UK. However, in order to get the best service for your money, it’s imperative to ensure you know how to scope a penetration test effectively.
Benefits of Penetration Testing
Most business decisions are ultimately based on the management of risk, whether it be threats from cyber attackers or the opportunities presented by new products or services. Pen Testing provides the technical foundation for assessing risk across IT systems and gives assurance to customers, investors and partners across the supply chain. So what are the benefits of penetration testing?
There are many good reasons to carry out penetration testing, including:
Identifying and fixing security problems – if your systems or applications have vulnerabilities, you want to know what they are, what is affected and how to fix them. You also want to know the risk – does it need fixing today, or can it wait a little longer, especially if the fix means system downtime?
Ensuring compliance – this is increasingly important with the introduction of legislation such as NIS and GDPR which set specific security obligations. GDPR, for example, requires “a process for regularly testing, assessing and evaluating the effectiveness of technical […] measures for ensuring the security of the processing”. Likewise, if you are subject to PCI DSS it’s mandatory to pen test your cardholder data environment at least annually.
Supply chain and contractual obligations – buying organisations are starting to set minimum security standards in contracts with their supply chain. These commonly mandate specific controls or compliance with standards such as NIST 800-53, which defines pen testing as a core technical control, and ISO 27001 which focusses on regular vulnerability assessment and evaluating exposure, usually achieved by pen testing.
Secure development – even with security testing being carried out earlier during development as part of a DevSecOps culture, there is still a need to test code regularly and ideally before major releases of internet-facing applications to ensure that vulnerabilities, such as the OWASP Top 10, are not present. Pen testing, therefore, forms a key part of your secure software development life cycle.
Assurance – ultimately you want peace of mind by knowing that your security posture is strong, that there are no obvious gaps in your IT systems or application that an attacker could exploit, and your data is protected. No organisation wants to suffer a data breach and has to deal with the reputational and financial fall-out that follows. Pen testing doesn’t guarantee you won’t be hacked, but it will help ensure your systems are resilient to an attack.
Building a programme of testing in a repeatable cycle develops security practices and helps to baseline improvements over time.
Valuable reporting is a crucial part of penetration testing. The report findings should help you to identify, understand and remediate discovered security weaknesses – with the overarching aim of improving your cyber resilience.
You should look for a partner that produces easy-to-understand, insightful, and structured reports. We recommend asking to see one or more sample reports before committing to working with any testing partner so that you can ascertain whether their reporting format and style are compatible with your requirements and employees’ levels of technical experience.
Moreover, to ensure report requirements are precise, we advise that you include expectations relating to the format of the report and its delivery date in the scope of work.
We have written a detailed blog on how to choose a good penetration testing partner to assist with this. If your organisation needs help running a penetration test on an application or infrastructure, we’re here to help. We can assess your environment and run a full penetration test. We can also advise you on any follow-up actions, remediations and vulnerability management from our findings. Most importantly, we are CREST accredited for penetration testing and vulnerability assessments, ensuring you are in reliable and experienced hands.
Download the PDF version of the guide to penetration testing:
Read more articles and insights on our blog page.