All modern software contains vulnerabilities; either software defects that require patches to remedy, or configuration issues that require administrative activity to resolve.
For this reason, organisations should have a vulnerability management process which enables them to know what vulnerabilities are present within their IT estate on a regular basis. Executive staff should ideally be as aware of the major vulnerabilities in their IT estate as they are of their financial status.
This guidance helps organisations to:
- assess and prioritise vulnerabilities
- identify which patches are most relevant
- ensure funds and resources can be deployed to best effect
About this guidance
This guidance focusses on the vulnerability management of widely available software and hardware, which consists in large part of deploying patches and looking for known weak configurations. The management of niche software issues consists of discovery of previously unknown issues, and is, for the most part, outside the scope of this document.
This guidance assumes that:
- your organisation uses technology which you are responsible for keeping secure
- you have sensitive data that needs to be protected from Internet-based attacks
Even if most of your data is not sensitive, vulnerability management will help you protect your staff details and your reputation. It will also lessen the likelihood of you being a source of onward infection. Penetration Testing should be used to validate the efficacy of the internal vulnerability management process and is not a replacement for it.
About vulnerabilities
Exploitation of known vulnerabilities in software remains the greatest cause of security incidents. Patching — the process of applying updates from software developers, hardware suppliers and vendors, to either enhance functionality or to improve security — is one of the most important things you can do to mitigate vulnerabilities.
Why do vulnerabilities go unfixed?
The safest possible practice would be to fix all vulnerabilities as soon as the relevant patch is released for affected systems. However, there are many real world limitations that explain why this is not possible. The main reasons include:
- cost — upgrading servers and workstations to a new platform is costly
- disruption — upgrades disrupt business and resources must be taken away from other IT projects
- compatibility — specialist applications may not operate reliably on newer operating systems (there is a two-fold cost incurred here; the application must be replaced in addition to the platform it runs on)
- operations — major software upgrades are inherently risky, and user tools may work differently
In addition, the prospect of a massive upgrade unnerves businesses, and the right mix of skills may not be available to plan and implement such work. Delays in upgrade work only increase the size of the task, making it more expensive and less appealing.
Plenty of tools and resources exist to assist in the prioritisation of upgrades and vulnerability management.
It is better to start small and make progress than feel overwhelmed by the task and do nothing.
1. Assess vulnerabilities
We recommend that organisations perform vulnerability assessment of their entire estate on a monthly basis. New vulnerabilities are reported all the time and many software vendors release updates on a monthly cycle (such as Microsoft’s monthly ‘Patch Tuesday’).
A regular assessment regime is essential to ensure that your organisation is aware of the risks that are present. It does not need to be run by an external partner, nor do staff require any special training.
Automated vulnerability assessment systems
While software patch status can be collected using software asset management suites, you should use an automated vulnerability assessment system (VAS) to identify vulnerabilities across your organisation’s IT estate. Software asset management suites do not always check for vulnerable software libraries in addition to installed software, and do not check for mis-configurations.
VASs perform actions against a target system (such as collecting a banner by connecting to a network service) and then assesses the returned data against signatures of known vulnerabilities (such as the version number reported by the network service that is known to have vulnerabilities).
When using a VAS you should:
- Assess your systems from an external perspective (eg from the Internet) and from an internal perspective — assuming that your system design differentiates between these two locations.
- Monitor the accounts used to run vulnerability assessment scans for any unusual activity. When an assessment is not being performed, consider disabling the account or changing credentials associated with it.
- Perform scans of your networks in addition to targeted scans of known systems, with the aim of discovering potentially unknown or unauthorised devices.
- Be aware that a VAS can cause unexpected outcomes, up to and including data corruption. Such outcomes are highly unlikely on relatively modern systems (those developed since 2010) but you may wish to test your VAS against non-production copies of critical systems before going live.
- Run the VAS with the credentials required to perform an on-host assessment, not simply an unauthenticated scan. Some VASs use an on-host agent while others use privileged credentials to authenticate and query the state of devices. The choice between these two options is a question of what is easier for your organisation to integrate into your systems. The privileged credentials used to perform vulnerability assessment are used to connect to large numbers of systems across the estate, and there is a risk of credentials being obtained by an attacker who has already compromised a system within the estate.
2. Triage vulnerabilities
We recommend you form a ‘vulnerability triage group’, consisting of staff with knowledge of cyber security risk, business risk and IT estate management. This group should meet once a vulnerability assessment has been performed in order to triage all vulnerabilities found.
Vulnerability assessment software will normally assign a severity rating to issues; this severity should be considered as part of the process, but since it does not take into account any business risks or mitigating circumstances, it should not be taken as a gold standard.
The triage group must take the time to assess issues based on all the available information. Note that the first time this is performed on a system, there may be very large numbers of issues to assess. Resist the temptation to ignore all issues which are not marked as ‘Critical’ or ‘High’.
The Common Vulnerability Scoring System (CVSS) assigns numeric scores to vulnerabilities and attempts to assist in the process of vulnerability triage. It can be a useful tool if used correctly, but the triage group must ensure that they:
- do not select an arbitrary score above which vulnerabilities must be fixed, ignoring all issues below that level
- do not take raw CVSS scores without taking into account organisation specific mitigations or priorities
Your triage process should divide all issues identified into three categories: Fix, Acknowledge and Investigate.
- Fix issues are those for which a patch, re-configuration or mitigation will be put in place. These fixes should be prioritised (see below), and given a date by which the fix will be put in place.
- Acknowledge issues are those which, 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 the reasoning for acknowledging it and a review date given. 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 should the vulnerability be exploited in future.
- Investigating issues should be used only as a temporary status where the triage group are unable to categorise it as ‘to fix‘ or ‘to acknowledge‘. This may be because the cost of resolving the issue is not known, or there are a number of possible resolutions and more work is required to identify which works best. Vulnerability assessment software is not infallible and false positives can occur. Where this is suspected then an investigation should be performed before removing the issue. Timescales for issues in this category will depend on the likely severity of the issue.
The decision to fix or leave an issue is, at root, a business decision and every organisation has their own risk appetite.
3. Prioritise vulnerability fixes
You should prioritise vulnerabilities by concentrating on issues that:
- are accessible to the largest number of potential attackers
- would have the largest impact if exploited
The number of potential attackers depends on the accessibility of the vulnerability (for example is it accessible from the Internet, or only from within a secured network?) and the complexity of the exploitation. If there are publicly available exploits, then the number of possible attackers is much larger than if a weakness is known about but attackers would have to develop their own exploit code.
The impact of exploitation consists of both the technical impact and the business impact. For example:
- technical impact — an issue which could allow a denial of service is generally considered as a lower impact than an issue which would give an attacker the ability to run their own software on the target system
- business impact — a vulnerability in a payment processing system is higher than one in a meeting room booking system
A sample set of guidelines for deciding on what issues should be fixed are given below.
Step 1: Decide what you need to fix
Priority 1: Fix Internet services and off-the-shelf web applications that can be exploited automatically across the Internet with no user (or attacker) interaction.
- Secure any service that is directly accessible from the Internet and for which there are known, exploitable, serious vulnerabilities. Vulnerability scanners can filter for those which have known exploits and are ‘High’ or ‘Critical’ (in terms of their potential negative impact).
- Include any off-the-shelf web applications; it they contain known vulnerabilities they are highly vulnerable to exploitation, including non-targeted automated exploitation.
Priority 2: Fix bespoke/niche web applications that can be exploited across the Internet with no user (or attacker) interaction.
- Secure bespoke web applications (that is, anything that runs code on a website that wasn’t purchased from a vendor or that didn’t come from a major open source project). Such web applications are increasingly subject to attack.
- In the first instance, prioritise any servers accessible from outside your environment.
Priority 3: Fix Issues that can be exploited across the Internet with minimal user interaction (workstation vulnerabilities, drive-by downloads, email based attacks).
- Secure user workstations against drive-by downloads and email based attacks. Securing web browsers and common user applications is crucial here.
- You don’t have to upgrade the operating system immediately, although older versions of Windows are not supported for newer applications. You will need to upgrade eventually.
Priority 4: Fix issues that can be exploited across the Internet with social engineering of users (malicious applications downloaded from the web or sent via email). These attacks require your users to play a part — for example by downloading an infected file or by clicking a link or an attachment in a phishing email — so you need to protect your systems accordingly.
- Put in place a simple application blacklist using Software Restriction Policy on Windows XP, or AppLocker on Vista and more recent Windows versions. This will stop users from easily being able to run programs that they have downloaded or been emailed (either on purpose or by mistake). See our End User Device guidance for more in-depth information.
- In Windows XP, block all applications being run by users from C:\Documents and Settings, and all the folders contained within them.
- For Windows Vista and later, block all applications being run by users from C:\Users, and all the folders contained within them.
Step 2: decide what you can afford to fix
You will probably find more problems that you can afford to fix. Deciding what you can afford to fix is a senior level decision. This is not an IT problem; this is a business risk.
Priority decision making will need to combine the following factors:
- priority list above
- direct cost
- cost in inconveniencing staff
- availability and cost of short term fix
- cost and availability of skilled resource
- cost of incident response and recovery (including any fines imposed)
- damage to reputation
Record the reasons for the decisions made. For any issues where a decision is made not to fix the issue but acknowledge it, a timeframe for reviewing this decision needs to be made. The decision for not fixing the issue should be made at a sufficiently senior level so that the person making the decision will be able to defend it if a vulnerability is exploited in the future.
Source: NCSC
