Practical IT: how to manage cost-effective penetration testing

Penetration testing is a valuable tool but can quickly get expensive. Focusing on testing the right things in the right manner is key to getting the best bang for your buck.

Deciding what and when to test can be the hardest step. A periodic test of your entire perimeter–that is internet-facing services and infrastructure–is where most companies start (and, more often than not, end).

Frequency is somewhat dependent on the rate of change in your infrastructure. For a stable environment, once a year may be sufficient. A more dynamic organisation may require more frequent checks. And automated vulnerability scans can also help plug the gaps here.

Although this approach still has merits, there is a growing issue for many companies: assets are increasingly becoming more detached from a specific IP range.

A risk-based, asset-focused approach is a great way to handle a diversely delivered infrastructure.

It can be a challenging process to bake-in to your project framework, but running a provisional security assessment early on makes all the difference.

It will help your project manager schedule the testing (oh, and don’t forget to include some time for remediation) and the costs can be included in the project budget instead of your security budget.

A balance between asset/project focused testing and a wider perimeter test is a good tactic for most organisations. Larger projects will benefit from some dedicated testing. Periodic perimeter tests can pick up problems with any “under-the-radar” projects or changes.

Vendor selection probably comes next. There is a good chance your pentester will get their hands on some sensitive information, so a reputable firm and an NDA are a must.

You will also want the testers to have some accreditation: CREST and CHEG CHECK are good ones to look for.

You may have some skills in-house. This can be a real benefit for quick tests of low-risk systems and to help assess test results. But I would advise bringing in a third party for other penetration test, as it can lend vital weight to findings.

Imagine having to tell senior business leaders that a project should be delayed due to a critical vulnerability. During negotiations, a professional-looking report from an objective third party can be a very useful asset.

Forging a good relationship with a firm or two will pay in the long-term. If your pentesting partners understand your organisation and its infrastructure, they can also work directly with key individuals. Project managers and pentesters liaising directly to manage the vulnerability remediation process can be a great time saver.

Pentest partners are also in a much better position to help you with the scoping, which can prove to be a challenge.

Even the smallest of systems could be tested for years and still not be forced to reveal all their bugs. This is important: pentesting offers assurances, but even an A* on the report card simply means no critical bugs vulnerabilities were found, not that they don’t exist.

Unfortunately, your attackers likely have much more time than you can afford to pay your pentesters. By giving your pentesters a comprehensive overview of the application and access to architecture diagrams, configuration and even source code, you can give them a head-start and counter this asymmetry.

A good understanding of the application will also give the tester some context in which to assess any problems, resulting in a more relevant and readable report.

Finding the correct focus does indeed depend on many factors.

Exposure is an obvious consideration: the globally accessible login page to a web app could be attacked by anyone with an internet connection, whereas the back-end management services on the web host are most likely well firewalled.

If it is an important system, you will probably want to take a strong defence-in-depth stance and test the host too, but with limited resources, perspective is important.

Checking what parts of a system have already been tested in another way can be very helpful. For example, a pragmatic way to handle host and infrastructure testing is to periodically check you standard server builds.

If you are confident the hosts delivering a new application match your standard server builds, then you can focus available effort on the application itself. Likewise, if you’re hosting an off-the-shelf application, then maybe you can assume that it has already been tested.

You will likely still want to do your own testing, but sharing the vendor’s test results with your own testers could allow them to quickly verify them before moving onto areas specific to your implementation: any custom configurations, integrations or features are very good candidates for new bugs that won’t get picked up elsewhere.

A similar approach is sensible for SaaS vendors (for a wider discussion in this area see my articles on due diligence for the cloud).

The core application & infrastructure should (and don’t assume – do check!) be the vendor’s responsibility, so you’ll get most value from looking at functionality and configuration specific to your implementation.

Lastly, make sure the test agreement includes help with the remediation phase. Vulnerabilities can be tricky to spot without the correct tools so a tester who rechecks the results and verifies the fixes will save you a lot of time.

_{Security keyboard image courtesy of Shutterstock
Files locked image courtesy of Shutterstock
Identity theft image courtesy of Shutterstock
Test results image courtesy of Shutterstock
Money clock image courtesy of Shutterstock}