Building an effective security testing strategy is essential to any business. Cyber security needs can vary from business to business. And so creating your strategy around the required outputs of your company is super important. However, in this blog we’ve outlined some key elements to consider when putting your security testing strategy together. 

‍

Policies and criteria

‍

The best place to start is by laying out your policies and your criteria. 

‍

• What matters? 
• What are your expected outcomes? 
• What does success look like?
• What does not succeeding look like?

‍

Having a clear roadmap to what you are striving towards means that you can start confidently looking at how and where to implement the different tools, technology and processes that will make that happen.

‍

Measures of success

‍

Using this criteria in your security testing programme is vital when it comes to measuring success. Having the best tools and the smartest developers is great. However, a lack of clarity around your development processes and accomplishments (or lack thereof) won’t get the most out of your tools or investment.

‍

Understanding which metrics to track to get the most out of your security testing programme is the first step. Then you can understand which tools and systems you need to track and monitor this. 

‍

Key metrics to include:

‍

• MTTD (mean time to detection)
• MTTR (mean to time response)
• Volume of vulnerabilities
• Vulnerability ratings

‍

The economic line between manual and automated testing

‍

Understanding the economic line between manual and automated testing is also a key element to an efficient security testing strategy. Here, it’s about understanding where a human is needed versus where a technology can accomplish the same result in a more effective way.

‍

For example, for low risk development changes, such as adding a new comment functionality, it’s easy to run a DAST scan using Zap. We can likely predict the potential vulnerabilities caused by the change (cross-site scripting / cross-site request forgery etc) and so running this change through an automatic test is appropriate and effective. 

‍

On the other hand, for changes like an introduction to a new user role, we likely need to test for vulnerabilities such as function-level access control issues and horizontal privilege escalation. For this, automated tools can’t quite cut it and manual testing is advised.

‍

So a deep understanding of the type of testing needed for different development changes is what will help determine the line between manual and automated testing. And in return, you can make your security testing as effective and efficient as possible, without sacrificing quality. 

‍

Security posture management

‍

Security posture management is a fairly new phrase in cybersecurity, although it’s not a new concept. Fundamentally, security posture management is about recognising that inevitably there will always be vulnerabilities and improvements to be made. When putting your testing strategy together, it’s valuable to keep this in mind to keep your plan attainable and to guide your areas of focus. 

‍

Systems won’t necessarily always meet your requirements. But, as long as you are measuring vulnerability location, volume and significance, you have a baseline for improvement over time. 

‍

Shifting left

‍

Shifting left is the phrase used to describe performing security testing earlier in the development process. The objective is to move security testing as far inside the SDLC (software development lifecycle) as possible. To some organisations, shifting left simply involves performing the security testing in a dev / UAT (user acceptance testing) environment before deploying into production. For others, it involves deploying SAST/DAST tools as part of a CI/CD pipeline.

‍

The benefits behind shifting left is that testing for vulnerabilities earlier on in the development lifecycle means vulnerabilities are less likely to make their way to production, minimising security risks. It also reduces the gap between detection and remediation, so often it’s easier and quicker for developers to fix. 

‍

Spotting the signs

‍

Evaluating the timing behind your testing is crucial when creating your strategy as it can form the backbone behind your whole programme. If you’re facing the following challenges within your vulnerability management programme, it may be a sign to reconsider when you test:

‍

• Frequent vulnerability backlogs
• Slow MTTD rate
• Slow MTTR rate

‍

Infrastructure

‍

Prioritising security testing around live development changes can be easier to implement than you think. Continuous Testing Orchestration platforms like Cytix automates the whole process for you. By automatically turning live development changes into sequenced testing actions, it connects with the testing tools and services needed to check for vulnerabilities at the time of development. So shifting left doesn’t need to be a fractured and difficult change to implement across your business. 

‍

Vulnerability history

‍

There is massive value in being able to understand the history behind a vulnerability in your code. Whether you're a CISO or an Information Security Manager, seeing the progression of a vulnerability from code, to staging, to production is vital in understanding its route cause and preventing future repetitions.

‍

Vulnerability history is also important for developers to be able to treat vulnerabilities quickly. Without it, it’s the equivalent of going to see a doctor to treat a broken bone, but without telling them which bone is broken. So treatment is slow and unnecessarily difficult.

‍

So If MTTR is a metric of focus in your strategy, implementing an infrastructure and process that highlights vulnerability context is crucial.

‍