Posted on 2020-06-25 by Matt Strahan in Business Security
What is in scope for a penetration test will be tested and what isn’t in scope for a penetration test won’t be tested. Simple enough, right? The problem comes when the hackers don’t follow the same scope that the penetration testers follow.
The choices that are usually made when scoping a penetration test are often made around simple practicalities and the various requirements that pop up for the organisation. Security considerations are important, but can be a secondary factor to it all.
For smaller organisations it’s not uncommon to have a full annual test with the entire internal and external environment in scope. After all, it’s easier to do it in one lot and just get it over with.
For larger organisations a full annual test would be too much since there are too many moving parts. It’s more common to have the scope restricted to a single project, maybe the new web application, new SOE, or the new network environment.
For this project by project testing the idea is that you can potentially get comprehensive coverage over the entire environment by testing each project in isolation. Hopefully a group of secure systems ends up being a secure environment. In the end, though, hackers will end up not targeting the systems directly, but they’ll start manipulating how they integrate and interact together.
The gaps between systems
We looked at issues with scoping previously when looking at third party systems. That blog post highlighted how to include third party systems in penetration testing and outlined the risks of not including them.
For larger companies with this project by project testing, though, sometimes the “third party systems” aren’t the systems belonging to other organisations, but the systems that are simply outside the project that is being tested. These other projects have different project managers, are part of different business units, and the lines of authority and ownership are often completely separate.
This can often be even more complex than dealing with the “third party” organisations. The same giant engine with a whole load of moving parts can make it hard to test things in isolation since after all it’s part of a moving engine.
Testing in isolation can feel inadequate. How would you, for instance, test a clutch in isolation of the transmission, the gear box, or the engine? Would you feel confident driving a car when the clutch is “tested in isolation of the rest of the vehicle”?
This holds true for testing projects in isolation as well. The deep integration between systems required by modern organisations make it seem like a break in one system can lead to the entire thing falling apart. What’s more, the integration between the systems and the different handling of data can itself be attacked! Issues with data validation in one application can lead to command injection in another. The packaged transactions from the website could lead to processing issues in the backend settlement.
Managing project based testing
I’m not saying we should test everything every time though. There are practicalities we have to keep in mind as well. If we were to test all the potential security dependencies in every application rollout, then Active Directory would be tested every single day. That would be a huge waste of effort and resources. Meanwhile, the organisation of a full year test would be prohibitive and applications could remain vulnerable in the time between rollout and the annual test.
In the end, we have the practical requirement to test in isolation but we have the security risks of doing just that. How do we manage those risks?
There are a few sensible controls that can help limit the risks of testing in isolation:
- Threat modelling and risk assessment: Threat modelling and risk assessments should be standard for all major projects, and other systems should be considered when threat modelling a project. You may want to highlight key integrations to your testers and ensure they are tested.
- Easy or automatic approval for pentesting: There’s the old “it’s better to ask forgiveness than permission” adage. Sometimes this should be the case. Especially for business functions that do not have a 100% uptime requirement or can withstand or manage the availability risks of pentesting. You can mark these systems as not requiring permission to include it in another test.
- Standardisation: Most vulnerabilities in integration target not one system or the other, but the different ways that the two systems handle the data that flows between them. The more consistent your organisation is with the handling of data the harder it will be to attack the integrations between systems. This can be achieved by using public standards (you don’t need to reinvent the wheel) or documented internal standards. Public standards, in particular, will already have people looking at potential integration issues that might crop up.
- Compliance: The result of compliance standards could also provide consistency in data handling across different systems. For instance, ISO27001 encourages information classification that mandates sets of security controls for information across the entire environment.
- Loose coupling: Prevention is better than the cure. If you try to limit the security dependency between projects, there is less likely to be vulnerabilities in the integration between them. This is often done by using simple APIs rather than more complex system level integration.
- Don’t just rely on penetration testing: Other security controls such as architecture reviews and design reviews are also effective and are often more effective at picking out integration problems.
With a few sensible controls, you can heavily limit the risks of testing in isolation missing vulnerabilities, making sure that not just the projects themselves are secure, but the entire engine is resilient as well.
About the author
Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on Twitter and LinkedIn.
Photo by Josh Redd on Unsplash.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn