Know your estate (8.1.1 - 8.4.3)

IT estates come in all shapes and sizes and are as diverse as the many organisations in the health and care system. They range from large centrally supported single sites, to sites spread across a geographic area with local management, to a one building estate with a single PC in the back office.

Even in the smallest of estates, it can be a challenge to know all the applications installed on all the devices across that estate. The National Data Guardian report discussed using a survey tool can help automate that task.

You should use a survey tool to take an inventory of your hardware assets and the software that resides upon them. You should then be able to reference the versions of software installed. For each piece of software, there will be a known supported version(s) and when which version(s) are end of life.

Generally, the survey tool will harvest hardware and software assets to populate and update an asset database. The asset database can also have manually added/updated assets for those not detected.

Supported versions of software are those that the manufacturer supports with patching and upgrades. They are not necessarily the latest version of the software. 

End of life software is not updated or patched and therefore can be vulnerable to exploits with no cure.

Even with a small IT estate, it can be laborious to document software manually and keep track of it.

For the more common pieces of software, the software tool should report back whether it requires a patch or upgrade and it could be used to implement it. 

Beware of the limitations of your chosen tool(s), for example, survey tools may not be able to track installed software.

Understand the boundaries of your IT digital estate and do not overstep them. Know where your network begins and ends, which devices are yours (or you support) and those that are not. Like any good neighbour, liaise with your neighbouring organisations if you are unsure.

Boundaries can occur at many levels, such as multiple network tenancy in a building, between your local network and HSCN, and between wide area networks on the same estate.

Ultimately, you should know where your responsibilities end and another organisation’s begin. Consequently, you shouldn’t scan or try to update assets that are beyond your boundary. 

Under no circumstances should you scan over HSCN without consulting NHS England prior to doing so. Some vulnerability scanners (depending on how aggressively or passively they are being used) can cause a false positive by being indistinguishable from a cyber-attack, with the same tools being used by hackers. 

Software cannot exist on its own

Software is installed and used on devices. The devices of interest are end user devices. So that’s PCs laptops, tablets and phones. There should be a list of the end user devices used within your organisation (such as a hardware asset database). This can use the same technology as your software assets, as it makes sense to know what software is on what end user device.

You also need to know what removable media assets (such as USB sticks) your organisation has, though it is recognised these can be more difficult to track and control.

For most estates, this should be the largest yet the easiest to survey and upgrade, with a standard build, in known and fixed locations, and with desktop PCs managed by the organisation.

However, this can be complicated by:

• no standard build
• no enforced builds 
• too wider variety of builds
• staff having local administrator rights

As well as knowing where your software is you should ensure that you have enough licenses to cover its use. Generally, installed software is licensed per seat or concurrent/pooled licenses.

With a concurrent/pooled license model it is far easier to centrally enforce your license limits. Per seat license can be far more complex with either use of a single shared license/key or unique license per seat. 

A shared single license/key, especially one based on trust, can if uncontrolled, easily lead to an organisation exceeding its license threshold. There should be a regular triangulation between your licensing limits and your inventory of software installed on devices.

In keeping to your licensing model means that you should receive security patches (in the active and limited phases) for your software. Those security updates / patches need to be applied in a timely fashion. 

You may not be able to upgrade some of the software on devices yourself, such as specialist clinical software. 

Alternatively, software may depend upon certain legacy versions of operating systems or standard software being installed. 

Examples include an unsupported version of windows or a legacy version of Java. It's important that you engage with the supplier of the software and understand the dependencies and any roadmap to compliance.

Where there is no resolution with the supplier, or a fix cannot be applied (due to financial, license or technical reasons), the system should be risk assessed and if appropriate treated as unmanaged and untrusted. 

It may be possible to negotiate an extension to a cut-off date, at least in the short term. 

There will be systems where updates are no longer available (such as supplier liquidation).

Care should be taken when surveying and treating clinical applications and devices however they are not exempt or immune to vulnerabilities.

A clinical device such as an ambulatory device or patient monitoring device may look very different from computers or a phone, but at their core they can have pieces of software just as vulnerable as that of other devices.

Find out more about protecting medical devices.

Where your organisation has remote locations, it will generally fall into one of these categories:

1. your organisation manages the whole remote site infrastructure including desktops and networking
2. another organisation (such as the main organisation at the remote site) manages the network infrastructure however you still manage the desktops
3. another organisation (such as the main organisation at the remote site) manages the network infrastructure and manages the desktops

For scenario a) and b), the results of those remote systems should be included in your survey tool results.

For scenario b) and c), you will require cooperation with the other organisation. For c), if the other organisation completes the data security and protection toolkit, the survey results can be completed in their submission which means you can just reference it.

The devices and software should either be uninstalled or treated as unmanaged or untrusted (this is discussed later in this guide).

Your coverage goal is a minimum 95% of your server estate and 98% of your desktop estate on supported versions of operating systems. This can be determined by Advanced Threat Protection (ATP) or equivalent.

Where your organisation’s complete IT infrastructure is managed by another party, you will require a degree of cooperation with your supplier. Generally, it will be expected that your supplier runs the survey tool on your behalf (and undertakes any necessary remediation with your approval). They provide you with a copy of the results and come back with any issues for your determination.

A list from your survey tool (or other method) should be compiled. It is very likely (unless you have a small IT estate with standard software only) that the survey tool will not capture every piece of software on every device.

The survey tool (or other method) may be limited by:

• specialist or bespoke applications may not be detected and may require to be manually added
• the survey tool might not be able to detect devices that are on a segmented network

In both cases, manual intervention may be required to add software or devices to your list.

Any form of assessment of potential untrusted software should ask the following questions:

1. Is the system built upon components that themselves are subject to vulnerabilities as detailed in cyber alert notifications (formerly CareCERT advisories) that cannot be upgraded or patched? 
   Such as requiring an end of life operating system, e.g. an end of life version of Microsoft Server, or built and delivered on a Microsoft SQL Server version that is end of life.
    
2. Do any of the systems require interaction with components that themselves are subject to vulnerabilities as detailed in cyber alert notifications (formerly CareCERT advisories) that cannot be upgraded or patched? 
   Such as a desktop operating system that is end of life or the client requires a legacy version application software.

If the answer to any of the questions is yes, the system should be treated as an untrusted one and the SIRO should be informed together with mitigation options.

Devices or software that cannot be upgraded

Dealing with software or devices that cannot be upgraded or patched will be difficult where they are still required and cannot be replaced. In these circumstances, they should be treated as an obsolete system that is unmanaged or untrusted (see Useful resources).

Treat obsolete systems as unmanaged or untrusted.

One of the traditional treatments for obsolete systems is to treat them as standalone. In todays connected world, it is difficult to see how a completely standalone system is possible.

The types of terms used are:

• 'It is on a standalone network, it doesn’t need to communicate with anything else.'
• 'It’s a standalone PC, it’s only connected to the internet, not your network.'
• 'It’s that old a piece of software, nobody would ever hack it.'

However, in practice, standalone networks and systems can find themselves directly or indirectly linked to an organisation network.

Direct linking can occur when a device or the network itself is connected temporarily such as to support a data export or installation of new software. This can have the effect of making the entire standalone network vulnerable. 

A form of indirect connection can occur with the use of portable drives between the main network and the standalone one which can also make the entire network vulnerable.

A moving target

Much like any product with a defined life, if you are replacing products towards the end of their support window with the next newest product, this product may be midlife itself and be approaching its own retirement. This scenario is true with products such as Windows, where there are currently three versions within their support lifecycle.

Consequently, it's important to treat discovery and treatment as a continuous cycle.

The SIRO should have an active role in the process. They need to be informed when systems cannot be upgraded and they should personally confirm what the risks of using unsupported systems are and that these risks are being treated or tolerated.

The SIRO should also be informed where high risk vulnerability patches have not been applied within 14 days, with reasons why. They should also sign off where appropriate on unsupported devices and software.

Find out more about SIROs.

You should have an effective plan or strategy for implementing patches on a consistent and regular basis. You should decide where to use automatic patching (such as the main desktop estate) or where manual patching is more appropriate (such as server farms) and the frequency of that.

It's important with automated patching that you follow up on any issues (such as where a patch cannot be applied to a specific desktop). It is also good practice to verify your results, either through another product such as vulnerability scanner or a dip sample manual check.

You need to decide on how you manage updates to remote end points (Home working PCs or mobile workers). These are devices not on your core network but consume services from the core and which could have a negative effect on the main infrastructure if infected.

Your patching approach should incorporate a fast track approach for applying critical or high risk vulnerabilities within 14 days of release, though it is recognised that this can be a challenge.

Where a decision has been made not to apply a critical or high-risk vulnerability there should be a robust reason for not doing so paired with a technical remediation and risk management.

This applies to any device (managed internally or by a third party) that has the ability to connect to the Internet including application servers, desktop computers, laptop computers, tablets and mobile devices running windows desktop operating systems. Example routes to the Internet include (but are not limited to) HSCN, N3/Transition network, VPNs, or cloud computing services.

You should be in a position to know if this a temporary fix such as with a virtual patch on server you intend to patch during the next downtime window or more long term. 

The NCSC Early Warning service helps organisations investigate cyber attacks on their network by notifying them of malicious activity that has been detected in information feeds. 

Your organisation should have sufficient number of individuals signed up to the service to cover eventualities, such as absences.

Secure by design and configuration (8.4.1 - 8.4.2)

Your infrastructure, ideally when implemented (or retro fitted), should be protected following secure by design principles whether that is network topology or server hardening. This includes ongoing patching and configuration changes. 

Secure by design covers having appropriate skill sets, segregation of networks into security zones, simple data flow between components, recoverability and content inspection.

Secure configuration covers knowing your configurable items, utilising baseline and last known good builds managing change, validation, white listing software and managing automated decisions.

Your infrastructure’s operating systems and software is patched regularly, the minimum being to the level still supported by the vendor (for security updates).

You should manage your infrastructure so you understand its exposure to publicly known vulnerabilities such as NHS Cyber alerts notifications (formerly CareCert) and bodies of knowledge such as Common Vulnerabilities and Exposures cve.mitre.org).

You should prioritise announced vulnerabilities which could be in addition to NHS Cyber alerts notifications (formerly CareCert alerts). 

You should test your infrastructure (through 3rd party testing) to verify your understanding.

You should maximise the use of supported software, firmware and networking (for example, in the active phase).