Penetration testing has become well-established as part of the cyber defence armoury – and indeed it’s a mandatory requirement in some industries such as Financial Services and Defence.
But is the traditional model of penetration testing on an annual or bi-annual basis sufficient? With an annual penetration test, a weakness might be uncovered that developed months previously – and it could be several months more before it’s fixed. Meanwhile, new cyber threats and attack methods are constantly emerging and attackers don’t put activity on hold while companies address the vulnerabilities exposed in their annual attack simulation.
Continuous software development changes the game
An even more topical reason why the method of how penetration testing is consumed needs to move on, at least for some organisations and in some sectors, is that the software development lifecycle has changed. ‘Agile’ is everywhere, with increasing numbers of businesses adopting a continuous integration and continuous development (CI/CD) approach to achieve faster release cycles, increase productivity and improve software quality.
The speed of development through CI/CD introduces new risks. In a traditional software development lifecycle, there are several stages including planning, design, coding, testing and deployment. Each stage is separated from the others, and there is time between them for review and analysis. With the CI/CD approach, the stages are compressed, and the time between them is reduced or eliminated entirely.
There are significant commercial benefits to be gained through the greater speed of production – but the danger is that code may be deployed without proper testing or analysis, which in turn can lead to critical vulnerabilities and security issues. There is also a risk of errors and bugs in the automation scripts used in CI/CD, while the open-source libraries and frameworks that are often accessed to develop applications quickly may contain vulnerabilities or backdoors that can be exploited by attackers. The use of open-source software also makes it difficult to track and monitor all dependencies, making it challenging to ensure that all software components are up to date and secure.
Continuous testing in sync with the development cycle
For all these reasons, I believe that business needs to move towards a continuous penetration testing approach for software, web and cloud applications – part of the ‘DevSecOps’ approach that emphasises the importance of security in every stage of the development lifecycle.
So what is continuous penetration testing? In simple terms, rather than one big penetration test every six months or year, continuous testing sees frequent ‘bite-size’ tests performed in sync with the progress of the development cycle. It places the emphasis on frequent and regular testing to ensure any newly discovered vulnerabilities are addressed immediately. Security teams perform testing on specific pieces of code or applications on a daily, weekly, or monthly basis, depending on the complexity of the environment and the pipeline of continuous development and integration. The goal is to keep the organisation's infrastructure and software applications secure by identifying and addressing potential vulnerabilities as soon as they are disc
Multiple benefits to be gained
Continuous testing not only minimises the risk to the organisation but also saves valuable time and costs that would have been incurred if the vulnerabilities were discovered at a later stage of the development process, such as the annual penetration test.
There are numerous benefits that can be unlocked through the continuous approach, including potentially:
- Earlier detection of vulnerabilities and breaches
- Better incident response capabilities
- Improved security posture as a result
- Better compliance with industry regulations such as DORA, PCI DSS, HIPAA, and UK SOX
- Cost reductions in fixing development issues
- A competitive edge over less secure peers
Planning the shift
There’s no doubt that continuous testing marks quite a shift and it’s something that organisations will need time to get ready for. Recently, a senior executive in a major bank explained to me that he believed it may be 12-18 months of preparation before they would be ready to engage in any continuous testing – but they recognised the need to do it.
A successful approach requires a strong partnership between the company's DevSecOps team and the supplier to ensure the testing is effective and efficient. It is key to define the scope of the testing, which includes identifying the systems and applications that will be tested, as well as the types of tests that will be conducted. The DevSecOps team will need to work closely with the supplier to ensure that the testing is comprehensive and covers all potential vulnerabilities. This means involving all relevant stakeholders in the process, including the IT team, security team, and business leaders, to ensure that all requirements are captured.
Once the scope of the testing has been defined, testing protocols need to be established. This includes determining how often the testing will be conducted, as well as the specific tests that will be run. After testing has commenced, it’s critical to review the results in detail, implementing changes and fixes, and continuously monitoring the testing itself to evaluate its effectiveness.
This is something we’re seeing more demand for at KPMG, where we have an extensive and proven penetration testing capability.
Is it time for you to consider a move towards continuous testing for some aspects of your business? Forward-thinking organisations are starting to look at this in earnest and I have no doubt that it will gradually but steadily become more widespread.
