top of page

Getting the most from your penetration test: paying less, testing more

Writer's picture: Coldsurge teamColdsurge team

For many organisations, penetration tests are the primary means by which they validate their cyber security posture. However, whilst penetration testing plays a critical role in assurance, costs can sometimes spiral unnecessarily. Organisations often overspend due to avoidable mistakes, leading to oversized testing scopes, delays, or wasted testing time.


At Coldsurge, one of our first priorities when preparing penetration tests is ensuring that organisations are getting the maximum test coverage they can in the time available, so in this post we have listed some of the ways to get the most out of your engagement.


Ethernet switch

1. Ensure scopes are accurate

Penetration tests are priced, almost exclusively, on the testing time required to provide a specific level of security assurance. This means it's really important that your scope is accurate and targeted to your testing objectives, and the more information you can provide during scoping, the more accurately your test will be scoped, which in turn reduces the estimated test time.


The best way to ensure a good scope is to make sure you have accurate information about the systems you would like to test. This will depend on the type of test you are requesting, but typically includes information such as:

  • Number of servers or workstations for infrastructure tests

  • Number of static and dynamic webpages, for web application tests

  • Total API endpoints, and methods, for API tests

  • How many authentication levels you would like to test

  • How many network positions you would like to test


Getting this right from the beginning will prevent test estimates from being larger than they need to be and prevent testing problems later on down the line.


2. Avoid setup and access delays

One of the most common causes for testing time being wasted is delays in access or connectivity for penetration testers. Making sure that everything is set up in advance of your test date prevents wasted hours, where testers are unable to do anything because they don't have what they need to start. This includes ensuring the correct setup for things such as:

  • Testing accounts and credentials

  • Networking, for example IP reservations and firewall rules

  • Provisioning of environments needed for testing

  • Security exceptions and policies


This also applies for any hardware or security tokens are needed, without which the test might not be able to begin. Of course, there may be unexpected issues or delays that arise even with the best planning, but getting the basics sorted in good time can prevent needless delays.


3. Use EDR, firewalls and security exceptions

If you're preparing a penetration test for your organisation, it can be a surprise if penetration testers ask for their testing tools be exempted from antivirus and other security solutions. After all, if they are simulating adversaries, shouldn't they be able to bypass security controls?


In reality, unless the reason for your test is to explicitly test your EDR, antivirus or firewall, you are probably most interested in the vulnerabilities and weaknesses in your assets themselves, rather than the security controls around them.


Antivirus alert
Testing EDR is rarely the most effective use of time on penetration tests.

Penetration testers also face a constraint that real adversaries do not: time. Whilst ten years ago the bar for bypassing antivirus solutions was often surprisingly low, the rise of enterprise EDR solutions has meant that it takes much longer to obtain reliable bypasses. On a one- or two-week penetration test, this could cost days of testing time on your actual targets, meaning testers may not have time to fully test everything in the scope, or may need to request additional time.


Ultimately, testers are on your side, and unless you are testing security controls specifically, the less friction they face to validate their attacks, the less days they will need and the more time they can spend on the objective.


4. Don't use black box testing if you don't need it

"Black box" refers to a type of test, whereby testers don't have access to the source code, internal workings or configuration of a target service or application. It's typically used when the source code is unavailable, or when it's desirable to see what an attacker could find with no assistance.


Whilst black box testing definitely has its place, at Coldsurge we typically recommend white box testing approaches for most penetration tests, where possible. White box testing is the opposite of black box and means that the testers have access to source code and configuration for targets in scope.


Like EDR and firewall exceptions, white box testing means that testers aren't spending their limited time on time-intensive activities associated with black box testing, such as fuzzing, which can take days for large projects. With white-box testing, it's quicker for testers to validate suspected vulnerabilities and attack paths as they can utilise the source code, resulting in broader test coverage.


5. Deduplicate assets where possible

As mentioned before, typically the more targets in the scope, the more time your tester will need for the assessment. One area where test scopes can be optimised is duplicate targets. This refers to scenarios where multiple targets are duplicates of each other, or of a base instance and have no meaningful differences that relate to security.


Examples of this include static HTML pages generated from a CMS, where there is no possibility to include dynamic content, or multiple instances of containers, all running with the same configuration and no way for users to change that configuration after launch.


The primary criteria here, of course, is that the duplicates cannot be changed into a different security state afterwards. So, this would rule out endpoints based on a golden image, for example, because users are able to change their systems after provisioning in a way that could affect security.


But when duplicate scenarios are identified, scopes can be significantly reduced either by testing a base instance or configuration or testing a representative sample.


Conclusion

As we've mentioned in this post, penetration test scopes boil down to time: time to get set up, time to get access and time to test your assets. Small things such as drawing up accurate asset lists and ensuring testing accounts are provisioned in advance can both save money and increase your test coverage - a win on both counts.




bottom of page