If updating to the latest version of the affected software does not fix the reported vulnerability or misconfiguration, or if there is no update to address the issue, you will need a process to triage and prioritize.
The vulnerability assessment will highlight any security, configuration, or update management issues that require attention. To manage your attack surface, you should conduct a vulnerability assessment of your entire asset at least monthly. If your organization has never run an org-wide vulnerability scan, the first report may contain hundreds or even thousands of vulnerabilities. It's also important to understand your attack surface (external vs. internal).
More mature organizations should consider more regular assessments, especially for externally accessible services. If you're using equivalent tools built into your cloud environment, you should follow the cadence recommended by your provider.
Although vendors typically have a cadence for releasing updates, they can be released at any time (known as out-of-band updates). This can happen if a critical vulnerability is found. If this is likely to affect your organization, then it's important to have a process in place that allows you to assess the vulnerabilities of concern at any time.
It is important to distinguish between vulnerability assessment systems, which are designed to identify vulnerabilities, and software asset management, which is used to determine software versions. In some cases, a single tool can perform both functions, but this is not always the case. For more information, see our guide to vulnerability scanning tools and services.
A regular scanning regime is essential to give you an idea of the risks your organization may face. It does not need to be operated by an external partner, and the staff does not require any special training. The NCSC provides guidance on how to select, implement, and use automated vulnerability scanning tools.
Vulnerability and configuration scans can also highlight issues that can't be resolved with software updates, or where the automatic update mechanism isn't working properly, meaning manual fixes are required. These vulnerabilities should be classified using the process outlined in Principle 4. Vulnerability scanning is also particularly useful for highlighting situations where updates are not installed.
If you develop software or run systems, you should also consider establishing a process that allows security researchers to report to you any vulnerabilities they find. The NCSC Vulnerability Disclosure Toolkit is designed to simplify the setup of the disclosure process.
Sometimes, installing the latest version of the affected software may not fix the reported vulnerability or misconfiguration, or there may not even be an update to resolve the issue. In some cases, it may be appropriate not to update: for example, if the system is about to be decommissioned, and vulnerabilities are difficult to find and difficult to exploit. With reasonable controls, such as ensuring that decommissioning continues, it is perfectly reasonable not to renew.
But more often, organizations feel like they can't solve the problem due to constraints such as employee time constraints or concerns about updating software compatibility. It's important to fully understand the potential impact this has on your organization.
While vulnerability assessment software or vendor consulting may provide a severity rating for issues found (such as the Common Vulnerability Scoring System or CVSS), you must consider your organization's business impact and risk.
Sometimes, organizations may assess that the risk of automatic updates is too high. In this case, the system should be added to the Exception List, and the update will pass any security testing required by your organization. Because 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 safely reverting to a known good state.
If there are no updates available for whatever reason, you'll need a process to triage and prioritize fixes.
You should consolidate all issues and apply the same triage and prioritization process so that system owners have full visibility to manage issues accordingly.
Your triage process should start by grouping together all similar findings or findings that require the same mitigation: for example, all SSL issues become one issue. Alternatively, you can group them by category, such as externally exposed vulnerabilities.
Once grouped, they should be divided into three categories: problems to solve, problems to confirm, or problems to investigate.
Fix "Applies to issues where you will ensure that the system is updated by default, or for which you will implement reconfigurations or mitigations." You should prioritize vulnerabilities: Internet-facing services or applications.
If successfully utilized, it will have the greatest negative impact, such as those present in critical shared infrastructure
When prioritizing and compiling a list, you should record the date the issue was resolved. This could be the date when the vendor said it would release a fix, or it could be an estimate of when the configuration change could be implemented. If the fix is a temporary vendor workaround or mitigation, it should be time-bound and actively tracked so that it can be removed once a full vendor fix is available and applied.
Acknowledging "whatever the reason you decide not to address at this time." There are valid reasons for not addressing vulnerabilities immediately, and those reasons should be documented, along with the planned review date. If the level of risk they present is high enough, record the problem in the risk register. If the vulnerability is exploited in the future, the justification for acknowledging the problem (rather than solving the problem) should be sufficient to justify the decision made. You should also consider implementing additional monitoring to alert you when vulnerabilities are known to have been exploited. The Investigation classification can't classify it as a Fix or Confirm issue. Surveys can only be used as a temporary status. This may be because the cost of fixing the problem is unknown, or there are multiple possible solutions, and more work needs to be done to determine which one is most effective. Vulnerability assessment software is not infallible and false positives can occur. If you suspect this issue, you should investigate it before removing it as an issue. The timeline for such issues will depend on the severity of the problem.