Discovering vulnerabilities

This is a follow-up activity to implementing a vulnerability management process which will allow you to:

• stay ahead of potential attacks and reduce the probability of a successful incident
• provide the necessary information to teams responsible for fixing vulnerabilities
• provide regular reports on service security to senior decision makers

The process of discovering vulnerabilities should be performed continuously during every phase of the service lifecycle throughout design, development and deployment.

It can begin as soon as an outline of the system design has been developed, using documentation to identify potential vulnerabilities. As the system evolves, automated processes will help to make this an efficient part of delivery with the frequency of responding methods relative to the severity of the risks.

Completing this activity will help you to achieve the outcomes included in the Secure by Design principles to source secure technology products, build in detect and respond security and minimise the attack surface.

Who is involved

During the service design phase, your technical architects should work with security professionals to identify potential vulnerabilities in the design.

During the build phase and beyond, your development and DevOps teams should be responsible for following the appropriate methods for discovering and remediating vulnerabilities. This may involve seeking support from security professionals from the wider organisation or third-party suppliers to undertake vulnerability scans or penetration tests.

The project’s Senior Responsible Officer (SRO) and service owner should be kept informed of the vulnerability tests being conducted, with the outputs being fed into risk management decisions.

How to discover vulnerabilities

Your organisation may have existing processes or resources that can be utilised to discover vulnerabilities for your service. Discuss the available options with your organisation’s security team before starting your own process.

Step 1: Decide which methods you will use

A combination of tools and techniques can be used to effectively discover the vulnerabilities within your service. It is recommended to use multiple methods rather than relying on a single process to detect vulnerabilities.

Details of some commonly used methods are provided below but this is not a conclusive list. You should research options for discovering vulnerabilities that are most suitable for the technology within your system and the threats most likely to be faced by your organisation.

Threat modelling

As part of the Secure by Design approach you should be performing threat modelling. This is a crucial part of discovering vulnerabilities as it highlights the potential attack paths so you know where to start looking for weaknesses in your system.

Source code analysis

Tools such as Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) can identify vulnerabilities in your codebase by looking for out-of-date libraries and potentially insecure uses of functions or methods. Dependency management tools are also available which will help you to identify and alert you to vulnerabilities within your software supply chain for any open-source code or third-party software used. Read the secure development and deployment guidance from the National Cyber Security Centre (NCSC) for more information.

Peer reviews

Before code is deployed, processes should be put in place to ensure it has been checked by a suitably experienced member of the development team who was not involved in submitting the change. This ‘two-person rule’ is an effective way of ensuring updates to services do not result in unexpected consequences. Rules can be built into your platform to facilitate this with custom checklists providing details of specific things to look out for.

Review the Open Worldwide Application Security Project (OWASP) Top Ten

When developing web applications, you should refer to the OWASP Top Ten, which provides a compilation of the most common and critical security risks that developers should be aware of, including insecure design.

Vulnerability scanning

Various tools are available to monitor your system to look for evidence of known vulnerabilities. These provide a cost-effective and scalable way of detecting vulnerabilities that can be set up to run at the desired frequency. Different tools will look for different vulnerabilities and it’s possible to deploy multiple tools across your applications and infrastructure to ensure all your assets are monitored. NCSC provides guidance on vulnerability scanning. Scanning for vulnerabilities should not be a one-off event, but should take place at regular intervals during the development of a solution.

Penetration testing

There are several types of penetration tests that simulate an attack on your application, infrastructure or network. They are useful for identifying weak spots within a system and can be run by internal teams or external specialists. Each penetration test should begin with a goal, scope, and duration that reflects a real threat scenario.

Use open-source intelligence (OSINT)

You should use OSINT such as NCSC threat reports and CISP (Connect Inform Share Protect, a platform for UK-based cyber security professionals) to keep yourself up-to-date about information about new and existing vulnerabilities.

Team training

Both technical and operational teams should undergo regular cyber security training, including tests on their understanding of the topic. This will allow you to identify areas where the team is lacking in knowledge or skills which could lead to vulnerabilities.

Step 2: Set a schedule

To ensure vulnerabilities are not overlooked, the process for discovering them should align with procedures for handling changes within your service. Your chosen methods should be fed back into your vulnerability management process with details on what each activity entails, what the purpose is, what the output will be, and when it will be done.

The frequency of each type of vulnerability test should be relative to the type of threats and level of risk they are designed to guard against. Your schedule should include methods which are:

• Continual – daily or weekly scans which will typically be automated
• Periodic – tests which happen at set intervals which require more detailed planning and active involvement from the delivery team
• Triggered – ad-hoc tests that happen as a result of certain activities, such as code being deployed or new third-party software being integrated into your system

Step 3: Report on findings

The processes used to discover vulnerabilities rely on the communication of their outputs in order to be effective.

Automated processes (such as vulnerability scans) will usually have alert systems that can be configured based on the severity of what they discover. Configure your system so information is fed into your team’s preferred communication channel so it can be seen by those responsible for responding to identified vulnerabilities. Certain events may need to be escalated to those responsible for making security risk decisions.

Methods that are more manual (such as penetration tests) should have a clear set of deliverables that can be shared with teams involved in fixing vulnerabilities, as well as those responsible for developing vulnerability management processes and reviewing the operational effectiveness of security controls.