IT Security Basics: Misunderstanding the Purpose of Penetration Testing

“I’ve had a penetration test done, so the service is secure!”

(Firstly, no jokes please…)

Too often, in my travels visiting a variety of customers, I see some fundamental misconceptions as to what the purpose of a penetration test is, which leads to a value-enablement gulf. In this blog, I explore some of the common behaviors I’ve seen that lead to (in my opinion) a lack of business value from penetration testing plus, unfortunately, increased business risks.

As an IT service management (ITSM) pro, you might not usually read security-based blogs but – if you can pardon my bad pun – not only is security everyone’s responsibility, better information security is better job security. (Too much?).

Understanding the Cyber Kill Chain

It’s important to recognize the steps that a threat actor will go to attack your business/service. The term cyber kill chain has been adopted to express this.

“The term ‘kill chain’ is a term used originally by the military to define the steps the enemy uses to attack a target.  In 2011 Lockheed Martin released a paper defining a ‘Cyber Kill Chain.’  Similar in concept to the military, this paper defines the steps used by cyber attackers in today’s cyber-based attacks.  The theory is that by understanding each of these stages, defenders can better identify and stop attacks at each of the stages.”

Below is a high-level description of a typical cyber kill chain (the phased method of attacking a target):

1. Recon – Your entire attack surface will be probed for vulnerabilities, open source intelligence gathering will be conducted, and potential attack vectors enumerated. This may be from a range of vectors using both targeted and untargeted methods.
2. Weaponization – “Payloads” will be created or re-used which will be used to compromise your environment.
3. Delivery – Unless remote code execution is leveraged, or credential theft has already occurred, the attacker is likely going to need to get content in front of your operators, e.g. a phishing link may be sent.
4. Exploit – Malicious code will be executed to gain a foothold on the target environment. Often in the form of a remote shell.
5. Installation – Following the initial foothold, additional malware will be deployed to a target enabling persistence, lateral movement, and aggressive capabilities, e.g. ransomware.
6. Command and control – Attacks will likely create a persistent back door which enables remove access and “command and control” of the compromised assets. This is often in the form of a reverse shell; however, it can be as complex as hiding commands in plain text such as Twitter accounts.
7. Action on – The attacker may start hunting for additional systems on your network to compromise. Using lateral movement, they may spread to other systems hunting for their targets.
8. Exfiltration – Attackers may clean up the evidence, wipe down their digital footprints, and attempt to remain undetected.

You have to remember that the attackers have a large (potentially unlimited) amount of time and free range at attack vectors, nothing is off limits! They’ll not always come/go in using a single method and the avenues for attack will cover every possible path between your data and the attacker’s position (including servers/services and endpoints that don’t belong to your company). The attacks may be continuous and will likely not revolve around your organization’s working hours.

Compare This to Penetration Testing

Now think about the phases of a penetration test, these (while they may seem somewhat similar) are often quite different:

1. Supplier selection – Companies select a supplier from the marketplace, often focusing on ticking the certification badges and cost needs rather than the testing approach.
2. Scope – A scoping call is conducted within which the client and supplier will discuss the requirements and the supplier will craft a proposal. Here a fairly specific scope will be selected which will include and exclude scenarios and tests.
3. Scheduling – Once contracts are agreed, the test will be scheduled, prerequisites will be enabled, and timings agreed.
4. Testing – Testing will be conducted (often over a few days) based on the provider’s testing method. This may be an automated scan using a product such as Nessus or ideally it will be a combination of tool-based and manual testing covering the full spectrum of the service being tested (although often it’s a limited set of testing).
5. Reporting – A report is provided to the customer which provides a traffic light style arrangement outlining critical, high, medium, low, and informational findings and remedial recommendations.
6. Post report – Following the penetration testing report submission, the customer should review this report with relevant stakeholders and then adjust security controls accordingly. This is likely to require a collaborative effort between a number of functions, departments, teams, and capabilities. The key element here should be enabling teams to not only reduce the risk of the specific service, but also play into the continual improvement of the software/service lifecycle development process to improve security posture and robustness throughout the lifecycle.

Common Pre-Testing Issues

The six penetration testing phases I outline above might seem reasonably straightforward but things can go wrong and they often do. The following four points are scenarios I sadly see time and time again which, even before the testing has begun, help to create a value gulf. This list isn’t exhaustive, so feel free to comment below to expand on this (I’m sure you’ve seen your fair share!).

• Penetration testing is only conducted with a limited scope, e.g. black box testing, from a specific IP address against a specific target, in a limited manner
• The penetration testing provider is selected based solely on cost
• The scope of the testing doesn’t represent sufficient vectors relative to what a threat actor will leverage in a real-world scenario
• Testing is limited to “test” systems only as there’s fear that the service/business may be impacted if a test creates a “destructive” outcome

Common Post-Testing Issues

In addition to the above:

• The penetration test results are kept super-secret (yes, they’re sensitive but the bad guys are already probing you and likely already know the same things)
• The results are not used to help the relevant teams (Blue team, IT Ops, developers, service desk, and architects) learn how to not only mitigate the specific attacks but also improve their practices to reduce the number of vulnerabilities created.

So What?

If you’re reading this and think that none of this occurs in your organization, then you’ve made me a very happy puppet (but for the wrong reasons). However, I suspect that many of you will, as I did, nod your head and wince a little as the memories of the limited-value activities that have occurred in the past return.

It’s key, when designing and operating services, that security assurance and testing activities are conducted in a continual cycle that both improves security posture and also enables business value. Shelf-ware reports, or simply ticking compliance check boxes and conducing point-in-time tests, do little to add value or reduce business risk.

Finding and fixing security vulnerabilities is a lot less stressful, and expensive, if tackled during the early-lifecycle stages, and knowing the tools and methods you should deploy before conducting a pen test will save you a lot of sleepless nights if you start early and continually assess.

Penetration tests absolutely have a part to play to secure and assure services, however please remember that they’re just a component and not the entire solution. Other activities that are important include:

• Secure design
• Asset management
• Threat modelling
• Risk assessments
• Code reviews
• Service audits and reviews
• Vulnerability assessments
• Code analysis (static and dynamic)
• Security hardening
• Patch management
• Secure operation
• Adversary simulation

And many more!

Hopefully this article has made you think about the purpose of a pen test – how this should be to improve security learning and posture, and play into the wider picture of planning, designing, building, and operating secure services, which not only reduce business risk but also deliver customer value!