Penetration testing can be used in many different ways to meet different goals, and there are several different types of penetration test. We’re always trying to understand our customer’s goals so that we can make sure we’re applying the right methodology to your penetration test to achieve the outcomes you want.
Traditionally, penetration testing has been used to describe the process of taking a whole system, network or application and conducting a thorough assessment of the system to identify all of the technical vulnerabilities, weaknesses and exposures within that system. Most of the time, when compliance programmes require a penetration test, this is the type of penetration test that is being referred to.
This type of traditional penetration testing may also be referred to as "full coverage" penetration testing, or "linear" penetration testing. If you’re developing a new system or application, or have a compliance requirement to meet by conducting a penetration test, this traditional methodology is likely to give you what you need. It’s a good way of identifying vulnerabilities or weaknesses within the bounds of the scope that you provide and can provide a comprehensive picture of individual issues that need to be addressed.
The traditional type of penetration testing methodology is less well-suited, however, to answering important security questions about your systems or applications which are directly relevant to actual attacks, and that’s where more innovative approaches and methodologies come in handy. There are three closely-related approaches that are also worth considering: objective-led penetration testing, scenario-based penetration testing and intelligence-led penetration testing. All three have much in common with Red Teaming, and they often overlap.
Most real-world attacks occur when an adversary follows an attack path which involves some form of initial compromise, followed by a path of movement which takes them from the point of their initial compromise towards an ultimate goal. For example, an adversary who wants to compromise a critical internal customer database is unlikely to target that database directly. Instead, they might target an employee with a phishing attack to gain access to that employee’s workstation. Then they might search for vulnerabilities in the internal network as that employee, and exploit an unpatched server. Using that unpatched server, they might escalate their privileges to take over the internal Active Directory domain, and using their escalated privileges, they might then impersonate a database administrator in the domain in order to access the data in the critical customer database.
A traditional linear penetration test of the critical customer database would likely not highlight any weaknesses related to that example attack path; a database administrator would typically be a permitted user case for accessing the database and therefore there is no self-contained weakness to explore or report on. Traditional penetration testing methodologies aren’t always suited to taking a holistic approach to attack pathways or aggregate risks.
We could, however, have used an objective-based methodology to highlight this risk. Taking an objective-led approach means giving the testing team an objective to complete – in this case, it would have been accessing the critical customer database. Using this approach, the testing team would map back attack paths from their objective (the database) to identify ways that database could be accessed (database administrator account compromise, application account compromise, etc.) and explore these parts of the potential attack pathway.
Had we used the scenario "what if a database administrator account is compromised?", we would also have been able to explore this risk and the attack pathways present. Scenario-based testing is really useful to understand the impact of "what if?" What if an employee downloads some malware? What if we have a malicious insider? What if our key supplier is compromised? When we think in scenarios, we can explore the impact that factors outside the immediate technical scope can have on the security of the assets we’re trying to protect.
Intelligence-led approaches are also helpful. When adopting an intelligence-led approach, it's because we have information about a specific threat or a specific threat actor and we want to explore how they might be able to achieve their aims. Perhaps we know that a particular criminal group has been targeting our sector. Armed with this information, we can look at systems and applications from a viewpoint of understanding how the threat actor operates and how susceptible we are to their techniques.
When we’re scoping penetration testing, we like to explore our customers’ principal security concerns, and key worries. We ask about specific threats or intelligence. We explore what hypothetical scenarios are most worrying, and what objectives an attacker might have. We combine all of this information together so that when we conduct a penetration test, we’re combining the best of these different penetration testing approaches together to achieve the most holistic picture of security we can during the testing we conduct. This is how we provide our customers with the best value for money, and the best security outcomes.