Vulnerability management

Vulnerability assessments will highlight any security, configuration or update management issues to be aware of. To manage your attack surface, you should carry out vulnerability assessments across the entire estate at least every month. If your organisation has never run an organisation-wide vulnerability scan, the first report will probably contain hundreds or even thousands of vulnerabilities. It’s also crucial to understand your attack surface – your external exposure versus your internal exposure.

More mature organisations should consider even more regular assessments, particularly for services that are externally reachable. If you are using the equivalent tools built into your cloud environment, you should follow the cadence the provider recommends.

Although vendors often have a published cadence for releasing updates, they can be released at any time (known as out-of-band updates). This may happen if a critical vulnerability is discovered. Where this could impact your organisation, it’s important to have a process in place that allows you to carry out assessments at any time for a vulnerability of concern.

A regular scanning regime is essential to make you aware of the risks your organisation may face. It doesn’t need to be run by an external partner, and staff shouldn’t require any special training. The NCSC has guidance on how to choose, implement and use automated vulnerability scanning tools.

Vulnerability and configuration scans may also highlight issues that can’t be addressed through software updates, or where an automatic update mechanism hasn’t worked properly, meaning that manual remediation is required. These vulnerabilities should be triaged using the process outlined in Principle 4. A vulnerability scan is also particularly useful to highlight when updates aren’t being installed.

If you develop software or run systems, you should also consider setting up a process to allow security researchers to report to you any vulnerabilities they have found. The NCSC Vulnerability Disclosure Toolkit is designed to make setting up a disclosure process easy.

Sometimes installing the latest version of the affected software might not fix the reported vulnerability or misconfiguration, or there may not even be an update to address the issue. There are also cases where it might be appropriate not to update: for example, if the system is being decommissioned shortly and the vulnerability is hard to reach and hard to exploit. With sensible controls, such as making sure that decommissioning continues, it's perfectly rational to not update.

More commonly though, an organisation feels unable to fix the issue because of constraints such as staff time, or concerns with compatibility of the updated software. It’s important to fully understand the potential impact here on your organisation.

While the vulnerability assessment software or vendor advisory may provide a severity rating for the finding (such as the Common Vulnerability Scoring System or CVSS), it's essential that you consider business impact and risk for your organisation.

Sometimes an organisation may assess that the risks of automatically updating are too high. Where this is the case, the system should be added to an ‘exception list’ where updates go through any safety testing your organisation requires. As additional testing can take a significant amount of time, it should be limited to systems where availability is critical and there is no mechanism for safe recovery to a known good state.

The triage process

Where no update is available whatever the reason, you will need a process to triage and prioritise fixes.

You should consolidate all the issues and apply the same triage and prioritisation process so that system owners have full visibility to manage issues accordingly.

Your triage process should first group all similar findings together, or findings that require the same mitigation: for example, all SSL issues become one issue. Alternatively, you could group them by category, such as externally exposed vulnerabilities.

Once grouped, they should then be divided into three categories: issues to fix, acknowledge, or investigate.

• ‘Fix’ applies to issues where you will ensure a system is updated by default, or where you will put in place a reconfiguration or mitigation. You should prioritise vulnerabilities:

•  in services or applications that are internet facing

•  that would have the largest negative impact if successfully exploited (such as those present in critical shared infrastructure)

When prioritising and writing the list, you should record the date when the issue will be fixed. This might be the date the vendor has said they will issue a fix, or it could be an estimate of when the configuration change can be implemented. If the fix is a temporary vendor workaround or mitigation, it should be time-bounded and actively tracked so it can be removed as soon as the full vendor remediation is available and applied.

• ‘Acknowledge’ issues where, for whatever reason, you decide not to resolve at present. There are valid reasons for not immediately resolving a vulnerability, and they should be recorded, along with a planned review date. If the level of risk they present is sufficiently high, record the issue in a risk register. The rationale for acknowledging an issue – and not fixing it – should be sufficient to justify the decision made if the vulnerability is exploited in future. You should also consider putting additional monitoring in place to alert if there is exploitation of the known vulnerabilities.
• ‘Investigate’ issues where the triage can’t categorise it as ‘fix' or ‘acknowledge'. Investigate should only be used as a temporary status. This may be because the cost of resolving the issue isn’t known, or there are a number of possible resolutions and more work is needed to identify which one works best. Vulnerability assessment software isn’t infallible and false positives can occur. Where this is suspected, you should investigate before you remove it as issue. Timescales for issues in this category will depend on the severity of the issue.