For part three of our in-depth look at the standards, we are going to tackle three more elements:
- You should use anti-malware software to protect all devices in the network, including cloud-based networks
- An administrator should check the security of all applications downloaded onto a network
- All online devices and software must be licensed for use and should be patched with the latest security updates
Anti-Malware
The first thing to say about this standard is that it seems to be a missed opportunity in a couple of areas.
There is no mention specifically of protection from phishing which is probably the single most likely way you will trigger a breach to your cyber security. Phishing is a technique whereby would-be attackers send emails purporting to be from reputable organisations but containing links to either sites containing malware or sites that seek to trick users into entering their personal data, including usernames and passwords.
Some phishing emails are very badly put together and easy to spot. Users will fall for these in some cases even though they are obvious. Some are really well crafted and very hard for users, even those who have had training, to spot until it is too late. Commonly these will do things such as send a user to a very well-put-together copy of the Microsoft 365 login page and ask them to enter their details. These can then be used to target those accounts. This is another reason why MFA is a good thing.
There are a range of anti-phishing systems and technologies available and in my view every organisation should be considering implementing one if they possibly can. It is hard to overstate just how much this method is used to target people.
Which takes us to the second and slightly odd omission. The title of the standard directly references cloud-based networks; the text of the standard then fails to mention that aspect again. The reason this springs to mind in relation to anti-phishing is that for a service such as Microsoft 365, when using the cloud version of the Exchange email service there will be a level of protection built in. However, this is a bare minimum and consideration should be given to whether this is sufficient or whether the more advanced protection, or indeed a 3rd-party alternative, would be beneficial. As always I’d recommend a risk-management based approach looking at the potential impacts versus the likely costs/complexity.
The cloud-based protections may also act as a stimulus for transitioning away from on-premise technology to a cloud offering. For example, Microsoft 365 and Google Cloud offerings both offer protections against malware, including ransomware, that will increase the resilience of your security.
Now to look at the things that the standard does talk about.
The first subtle piece of language to consider is the use of the term anti-malware rather than anti-virus. This is very important in maximising your protection. Traditional anti-virus products seek to prevent damage from traditional viruses but have sometimes not tackled other forms of malware.
Over recent years we have seen most vendors move to a broader coverage of threats but sometimes these come as additional modules which must be licensed to become operational so it is crucial that when looking at the software that you ensure that you are protecting against a wide range of threats including viruses but extending to other malware such as ransomware.
It is important that you select a product that will cover the devices you have in operation and is supported across the operating system versions in use. It is also important to understand where there is limited value in adding such a product (for example an iPad or Chromebook) and the NCSC have a short advice page on this topic.
When selecting a product you must ensure that as a minimum it:
- is set to scan files upon access, when downloaded, opened or accessed from a network folder
- scans web pages as they are accessed
- prevents access to potentially malicious websites
- prevents the running of applications identified as malware
It is also imperative that any system is regularly updated, preferably automatically and personally I would want there to be a central point that would identify any issues with updates (or installation of the software) so that they can be quickly remedied.
There are occasions where access to websites that contain malware may be justified, for example as part of teaching the topic. Where this is required there needs to be a process for risk-assessment, authorisation and documentation for such access. In reality, the layers of security that are in place will probably require such activities to take place in dedicated labs set up to bypass normal restrictions and separate to the main infrastructure, however it is still important to have the risk-assessment and authorisation in place.
Security Checks
The aim of this standard is to prevent applications downloaded from the internet from inserting malware into the network. It seems a simple and straightforward aim but there is a level of complexity beneath the surface.
At its simplest, the easiest way to achieve this aim would be to prevent users from downloading applications and the actions from an earlier section on least privilege user accounts should prevent the running of applications if they are downloaded (although this isn’t foolproof).
However, this can put a burden on the technical teams if users demand access to a range of applications that are not part of the standard install. This means that to meet this standard it is more about policy and process than technology.
Having a well-understood mechanism for requesting new applications, whether traditional paid-for apps or downloaded free apps, will allow the software to be checked by the technical team. Such a mechanism should have clear expectations of time-frames and ideally, there should be a set of actions that need to be undertaken by the team to determine whether the application should be authorised or not.
Checks can include simple ones such as reputation checks, for example, if the software is from a well-known company it should be safe. Where the software is downloaded there are checks to be made on digital signatures to make sure that it is actually from the company that produces the software.
There is of course a balance to be struck to ensure that the process doesn’t become time-consuming and onerous on the technical team. This should entail, as part of the process, a stage where the requirement is justified by the requestor. This also allows for alternatives to be suggested where software in use elsewhere fulfils the same requirement.
Although we will look at licensing issues later, this process would also allow for the licence to be checked. There are many cases where users have started using “free” software not realising that the licence is for personal use only and when used for teaching there is a payment required.
In some secondary schools and colleges, there is an added complication when they are teaching coding and software development. By definition, this will result in code that hasn’t been checked and there have been cases where code has triggered the anti-malware software when it is activated.
To overcome this, consideration should be given to the environment used for software development and whether this needs to be separate from the standard network or whether the use of sandbox technologies to insulate the code from the wider network can be used. As always there is a balance between usability and protection.
Licensing and Patching
Although it may seem that licensing and patching are different topics, they are in modern software linked. Often, only licensed software will be able to download the latest updates and this can extend to security patches.
Licensing is of course also a legal requirement. Running unlicensed software can result in both financial and criminal action so it is vital that an organisation understands what software it is using and the status of the licensing.
This can be a complex area, some software has perpetual licences, that is you buy it once and own it forever. However, this will generally apply to only one version and when a newer version comes along you can’t simply download and run the upgrade, you will instead need to re-licence.
Other software will have an annual subscription that grants full access to new versions, however, failure to renew the subscription will probably render the software unlicensed and require you to remove it. Even if the software continues to function, using it is a breach of the law.
It is vital therefore that you have a mechanism in place to record any and all software that is used across your organisation. As discussed above, having a clear process for the provision of new software will help with this. It is also advised to audit your devices to ensure that no additional software has been installed that hasn’t been through the correct process.
When looking at new systems and applications, one of the considerations would be whether it can be procured as software as a service (SaaS) – often billed as “cloud-based”. This will be a subscription service but will automate the process of updating and patching the software and will of course always be licensed while the subscription is maintained.
Patching of software is possibly one of the biggest challenges in meeting cyber security requirements. This is particularly true for larger estates and where there are a large number of applications in use. In the earlier standards, we talked about removing unused or unnecessary software and part of the reason for this is to reduce the number of things that need to be kept up to date.
Where possible automatic updates should be enabled. There are some exceptions here though, particularly if the organisation is reliant on in-house developed applications. It would be unhelpful for a server or database to automatically update only to crash the in-house app. Any organisation that develops substantial amounts of software should have a testing environment where the patches can be applied and tested before being applied to the live environment.
Perhaps the single most challenging requirement of the standard is taken directly from the Cyber Essentials framework which is that you must complete manual updates to hardware or software, including configuration changes, within 14 days of the release of the patch where the vulnerability is:
- described as high risk or worse
- has a Common Vulnerability Scoring System (CVSSv3) score of 7 or above
This is challenging for a number of reasons:
- although only applying to non-automatically updating items this does cover all hardware and software so can potentially be a large number of devices (cross reference the standards for networks requirement for auto-updates and central management technology)
- it requires someone to monitor for security announcements for all software and hardware deployed across the network
- it requires someone to test the update to ensure that it doesn’t cause further issues
There are many professionals, especially in larger colleges and universities who think that the blanket 14-day rule lacks nuance and there should be a risk-based approach that takes into account the individual circumstances of the organisation, however, the rule has remained in place.
Whatever the challenge, the standard clearly sets the exception that patching will be something an organisation takes seriously. There should be a clear policy setting out the objectives, not just for the 14-day vulnerabilities but more widely in terms of patching lower-scoring ones.
Consideration should also be given as to how you would demonstrate that your patching regime is effective and that whether automated or manual, the patches are being applied. One way to do this would be to undertake an automated vulnerability scan of the network which would identify any vulnerabilities and recommend priorities for remediation. This is available as a paid-for service although larger organisations with strong internal IT might want to consider buying the audit software and training the team as the costs are roughly the same due to great education discounts from several vendors.
Finally on this topic, there is a, thankfully very rare, exception where the Department for Education can issue a notification requiring patches be applied within 3 days. For this to be issued the vulnerability is not only severe but also judged to put institutions at immediate risk, often when attacks utilising the vulnerability have been seen against schools or colleges.
That brings this part to a conclusion. Next time we will be looking at backups and business continuity planning.
If you need any help or guidance with any of the issues raised in this post, please get in touch, we’d be happy to help.
