Why Pen Testing (alone) isn’t Good Enough 

One common challenge that comes up when I speak to clients relates to pen testing. I don’t think at this point anyone is struggling with whether they should or shouldn’t complete pen testing on their systems periodically (although there is ongoing debate of the definition of ‘periodically’).

The challenge that clients usually articulate is more along the lines of ‘am I testing the right things?’. This is much more difficult to answer and is probably an area where many organisations could benefit from applying a slightly different lens to their services and technology stack to ensure they are a) ‘testing the right things’ and b) getting maximum value from their pen test spend.

Historically organisations have taken a very binary view to how they scope and commission their pen testing activity, some of the common themes I’m sure you’ve come across are;

1. Internal/External - This testing approach silos systems based on where they are accessible from, immediately assuming that controls in place to restrict access to internal systems are effective.

2. Physical/Digital - This testing approach assumes that any attack or compromise will follow either a physical or digital route. In reality a blended approach of attack techniques is more likely.

3. Customer/Colleague - This testing approach groups systems by who accesses them, it largely ignores the fact that there is likely interactivity between systems and common technologies that cut across both customer and colleague facing systems.

Whilst these are valid ways of classifying systems, data, networks and locations to focus testing, this approach fails to consider risks / impacts to an end-to-end service or product.

For example a web application pen test against a customer facing web app that processes customer data may show no findings. That’s great – It’s indicative of good secure development practices, hardened underlying infrastructure and robust authentication and authorisation mechanisms.

However if the internal team that access the system use an outdated back end application, supported by a shared legacy database, in an office space that isn’t physically as secure as it could be, then isn’t the clean bill of health for the web application actually masking the underlying risk to your customers data?

What’s the opportunity?

As more and more organisations move towards using agile concepts and a product focused DevOps approach, isn’t it time we started using the same principles when identifying and managing information security risk?

One pen test shouldn’t be the seal of approval that indicates to management that something is secure. There’s an opportunity to take a more holistic approach to security assurance which helps both us, as security professionals, in identifying risk, and also in allowing management to make informed decisions to more effectively manage ALL the risks to the data, services, or products for which they are responsible.

How can you get started? 

The first step in developing a holistic approach to security assurance is truly understanding your products and services.

Identifying the people, processes and technologies involved in delivering services to your customers (be they internal or external) will allow you to identify all the component parts which could present information security weaknesses.

Once you’ve got an understanding of the people, processes and technologies required to deliver your service then you can start to identify threats that exist across the end to end service rather than just testing some elements in isolation which may mask risks or provide false assurance.

Now that you’ve got a holistic view of the threats that exist you can develop an assurance approach that will really add value and could tease out previously unidentified risks.

That assurance approach will likely include some traditional pen testing, however complementing the traditional approach with some additional testing / assurance activity will allow you to present an end to end view of information security risk exposure to your stakeholders.

Some of your broader security assurance activity could include:

1. Process Breakdown / Bypass - Does the business logic behind your processes stack up? Can processes be manipulated to allow an individual access to information they are not authorised to see?

2. People Compromise - How trained are your people? Can a tester present a scenario whereby they grant access or provide information inappropriately?

3. Physical Perimeter - Can the operating locations / underlying data storage hardware be accessed inappropriately?

4. Network Traversal - Are individuals who are either granted or gain access to your network able to manipulate their permissions and traverse the network to gain access to the data or systems that underpin your service?

5. Testing your Response - How would you know if a service was under attack or compromised? Have you tested your logging and monitoring solutions to check if any investigation would be triggered by indicators of compromise?

When you’re armed with this view it’s much easier to prioritise risk management activity and ensure that you are expending effort in the areas that will most significantly reduce your risk exposure.

if you want to understand more about your security assurance options and how we can help you get more value out of your security testing, please get in touch.