The recently released Department for Education Cyber Security standards for schools and colleges cover twelve topics and in some cases are quite detailed in what they expect organisations to have in place.
In Part One of our detailed look we are going to take the first two standards and look at some of the implications:
- Protect all devices on every network with a properly configured boundary or software firewall
- Network devices should be known and recorded with their security features enabled, correctly configured and kept up-to-date
I’ve grouped these two together not just because they are the first two on the list but more importantly because they are standards that are categorised as items that should already be in place and the standards should already be met.
While the technology aspects of these may be in place, there are some process and recording elements that may need more attention in some organisations.
Of course if for any reason your organisation isn’t meeting these standards than remedying that should be a top priority. To understand how your organisation stands with respect to the standards, a quick audit of current practice against the standards would be highly recommended.
Throughout the standards the term IT Service Provider is used and can mean either internal staff or external service provider or a combination of the two. What is important though is that anyone you use for these purposes has the skills and experience, and ongoing development, to ensure they can provide the security needed to protect your digital assets.
Perhaps the most critical thing to understand about IT security is that it isn’t something that a one-off project can “fix”. While it may be possible to run a project to bring things up to the standards as they are today, to ensure that the networks and data remain as secure as possible there needs to be ongoing monitoring and remediation as the threats are constantly evolving.
Firewall(s)
A firewall is a technology that sits between the outside world and your internal network or device. The reason for the plural in the title is that there are options for firewalls at both the network and the device level that should be considered to create a layered security plan.
The firewall on the network is the first line of defence and if correctly designed, configured, and maintained can prevent many attacks. At a network level, to achieve the performance needed, firewalls are usually hardware devices that sit between the internet connection and the main internal network.
Firewalls will usually work by applying rules to inbound and/or outbound traffic. Some firewalls can also act as filtering and monitoring for outbound traffic to enforce rules relating to blocking access to certain content or preventing users accessing sites, either intentionally or unintentionally, that host malware or viruses.
There are also services that move the firewall off premise with the protection being at the other end of a point-to-point leased line for example and managed firewall services, either on or off premise, are one way for organisations without the internal skills to be assured that they are protected.
The technical requirements of the standard are as follows:
- protect every device with a correctly configured boundary, or software firewall, or a device that performs the same function
- change the default administrator password, or disable remote access on each firewall
- protect access to the firewall’s administrative interface with multi-factor authentication (MFA), or a small specified IP-allow list combined with a managed password, or prevent access from the internet entirely
- keep firewall firmware up to date
- check monitoring logs for suspicious activity
- block inbound unauthenticated connections by default
- document reasons why particular inbound traffic has been permitted through the firewall
- review reasons why particular inbound traffic has been permitted through the firewall, change the rules when access is no longer needed
- enable a software firewall for devices used on untrusted networks, like public wi-fi
As the list demonstrates, putting a firewall in place is the start of the process not the end. The device needs to be monitored and maintained to ensure that it remains fit for purpose and up to date with the latest information.
It is important that someone is actively looking at the firewall log files which will record all activity and traffic going in and out. This will indicate early on if there is suspicious activity that may need further attention. Increasingly firewall vendors are building easier to use tools into the devices to allow this process to be much more friendly than scanning a pile of text and in some cases now even have built in systems to automatically flag suspicious activity.
When selecting a firewall these additional elements are worth exploring to ensure the device will be useful longer term.
Where the device also acts as a content blocker there will be additional updates both automated and manual entering of exceptions. Any manual change should come via a process that delivers challenge (why is the change necessary) and documentation to provide future reviewers with information to support the change.
Firewalls can be changed to allow inbound traffic that matches a given rule. For example, there may be a service that runs on an internal server that needs to be accessed remotely. However, any changes to the inbound rules must be made only after in-depth analysis of the impact on the overall security that making the change will have. Any change must be documented and ideally have a limited time applied to remove the rule as soon as possible.
In some organisations, decisions have been made for expediency that have resulted in dozens of rules being applied to allow access to internal systems. Instead of thinking about inbound traffic rules, shorten it to holes. That is in effect what we are talking about. Each rule adds another hole in the defensive wall that could interest an external attacker. Each service or server utilising the hole is now at increased risk of attack.
Ideally, as part of the review against these standards there would also be a review of existing rules. If there are any inbound rules (holes) the question should be why and can we provide the same service a different way that protects the main network. This may require bigger change than just removing the rule.
One of the other key decisions in respect of the firewall is do those authorised to administer the system need to do so from outside the internal network. The safest way may be to disable this feature all together but that does mean that faults that happen out of hours or when the site is inaccessible can’t be remedied.
Where remote access is deemed worthwhile it is critical that access to that part of the firewall is protected by the most layers of protection as possible and this includes MFA for those users.
Finally, although much of the standard relates to the main network firewall, it is worth noting that Windows and OS X (and other operating systems) have built-in software firewalls which are usually turned on by default. However it is worth checking your standard setup process to include a step to ensure that these are enabled.
Adding a software firewall, particularly to laptops that may be used off site and especially those that may access the internet via a public wi-fi system is another crucial step to add further layers of security.
One thing not in this part of the standard relates to testing of the defences. Although there is a cost associated with it I would strongly recommend that external penetration testing is undertaken by a qualified 3rd-party organisation. This should be done at least once a year and should also be considered after any major changes to the firewall to double-check that there are no clear dangers present in the system.
Any test programme should include as part of the output a narrative, risk-based report that will allow less technically adept readers to determine what, if any, actions need to follow the test to ensure any findings are correctly graded in terms of risk and priority for resolution.
Securing Network Devices
Within the standards set out in Meeting digital and technology standards in schools and colleges there are recommendations for both wired and wireless network developments that include security measures. This standard takes that a step further by noting that security features should actually be used!
There are several reasons why security features are not used. The simplest reason is that they are not turned on by default and nobody gets round to flicking the switch. Sometimes they are not turned on because of a fear that doing so may break something else on the network or that turning them on requires detailed planning to ensure the service works effectively and the time to do that work (or perhaps the skills) are not available.
There are even times when security measures enabled by default are turned off because leaving them on requires users to take additional steps or creates a training need.
The standard makes it very clear that this is not acceptable and that utilising all the security tools at an organisations disposal should be part of the wider cyber security plan.
This can be a challenge in terms of transformation as it often does require users to modify their behaviour and this can be met with resistance. Although covered elsewhere, MFA is a clear case where there are many benefits to using the technology but the users often report that it has made things more complex. Even though users may use such technologies to access services in their personal lives, banking apps for example, they may still see imposition of these security measures as a waste of time. Communication is as always key.
The standard also pulls to the forefront another key element which is knowing what equipment you have in your organisation. This may seem obvious but I have been involved in several projects where the first stumbling block is a lack of detailed information about what is already in use. For mature network environments that have grown organically over a number of years this can be particularly relevant.
As with the firewall example earlier, a lot of sites will have pieces of network architecture born out of expediency rather than a long-term plan. Often temporary pieces of work become permanent without being added to the documentation or consideration of security implications. The need for flexibility often comes at the expense of structured process which can be a future headache for cyber security.
The standard itself has the following requirements:
- keep a register, list or diagram of all the network devices
- avoid leaving network devices in unlocked or unattended locations
- remove or disable unused user accounts, including guest and unused administrator accounts
- change default network passwords
- require authentication for users to access sensitive school data or network data
- remove or disable all unnecessary software according to your organisational need
- disable auto-run features that allow file execution
- set up filtering and monitoring services to work with the network’s security features enabled
- immediately change passwords which have been compromised or suspected of compromise
- protect against brute-force attacks on all passwords by allowing no more than 10 guesses in 5 minutes, or locking devices after no more than 10 unsuccessful attempts
- physical access to switch management and boot-up features should be protected by a password or PIN of at least 6 characters
- All other devices must be protected with an enforced password strength of
- where a deny list is used for automatic blocking of weak passwords, 8 characters
- where a deny list is not used at least 12 characters
There is quite a lot to unpick in that list and it ranges over a whole set of different areas and subjects.
The first item we’ve already touched on. It is really important that there is documentation of the kit you have deployed on your network. I’d personally recommend a diagram to show the topology of the network showing a schematic representation of the network including the device type and numbers of ports, links between different pieces of equipment etc to give a simple visual representation of the network which give quick information for either fault finding or planning for growth or rolling out of features. Behind that should sit a detailed list of all the equipment with technical details and elements such as version of software etc.
Thankfully, many of the systems that allow a network-wide view which is a requirement under the network part of meeting digital and technology standards will automate the production of this documentation and maintain it by reading the devices directly saving time and effort.
Unless you are purely working out of new buildings, and sometimes not even then, the chances are the second item is one to look at. Ideally all network equipment would be locked away in rooms that could only be accessed by technical and estates staff to protect it from tampering.
In reality though, many schools and colleges will have grown the network organically and this will have led to network cabinets being installed in classrooms or other open locations. While not ideal there are still some simple steps to help with these such as installing them at a high level rather than floor standing. Anything to make access to them more challenging and more likely to be noticed. Also something as simple as keeping the cabinet locked can add a little deterrent from tampering – again I seen many a network cabinet in an open space, door wide open.
Physical security is a key part to cyber security. Anyone with direct physical access to your network equipment will have a better chance to attack it.
The next two items represent established best practice when deploying new devices. Network devices will usually ship with a number of predefined user accounts, sometimes with passwords, sometimes unprotected, to allow engineers to log into the system to apply configuration. These accounts if left represent a massive security risk as databases of devices and those default account and password combinations are available on the internet. Even respected forums may include this information as a help to other administrators who inherit kit with no documentation when they need to apply new configurations.
It is therefore critical that those standard accounts are removed, renamed and if they remain are assigned a unique and strong password that only authorised personal can use. One challenge with using strong passwords can be recording them and elsewhere the standard recommends password management software be used. For system administrators I would always strongly recommend that they use one of the paid for password management tools to act as the main repository for all administrative level passwords. This adds a level of protection and doesn’t require individual administrators to remember device passwords.
When implementing a network wide monitoring and configuration tool as recommended in the wider standards documents you may well find that there are tools to automate the deployment of new switches that incorporates this element of best practice.
For now though it is worth an audit of existing hardware to check whether default accounts are disabled and passwords are set.
One policy that should exist within schools and colleges will outline the rules for gaining access to the network and other systems and this should tackle the next item on the list. Nobody should be able to access the network without authenticating to it. Although the standard specifies sensitive data this should apply to all access.
When talking about cyber security there is a concept of a threat surface. This relates to how many targets there are to potentially attack and how big each of those targets is. One of the challenges across the board is patching systems in a timely manner when security issues are found, or indeed just keeping things up-to-date with the latest versions.
Often processes will cover big items such as servers and network equipment but it is also important to remember that any software on any device that connects to the network could be a potential weak spot and keeping those applications up to date is also vital. There have been a number of exploits in recent years that have targeted common software installed on ordinary computers such as Adobe Acrobat or Flash, Java and other libraries that may be used by multiple pieces of software. While there are other ways of reducing the risk the easiest by far is to not have any software on the machine that isn’t needed.
Unfortunately, by default Windows in particularly comes with a whole pile of applications that will for most users never even be opened. It is therefore important that you create a base build that removes any unneeded software and use this to prepare any new devices. That way you can be sure that you aren’t forgetting to upgrade or patch software that isn’t required.
Next on the list is to disable auto-run. This is a feature that may apply to optical drives such as DVD or USB drives and is set to make life easier, rather than having to navigate the drive and run something when inserted a drive will look for an auto-run file and run whatever is in it. While this may be convenient it is obviously something that can be exploited by would be hackers.
Elsewhere in the standards we look at creating accounts with least privileges, that is only giving user account the minimum access to a system that it needs to operate. This will partially mitigate against users installing software without permission but it is worth noting that auto-run can be used with software that can bypass standard installer permission so could still be used to establish a foothold. If using Active Directory with Windows devices, preventing auto-run is a simple policy update.
As mentioned at the top of this piece, the standard sets out to ensure that people actually use security features available to them. The list now reiterates that in relation to filtering and monitoring services in that existing services should be configured to work with network security features; not as is sometimes the case security features being disabled or weakened to make existing systems work.
The final section of the list covers a range of elements relating to passwords. Having an agreed password policy and publicising this alongside user education activities is a really important part of cyber security.
Passwords are not good in terms of security in that computers can crack them much more easily than people can remember them. The more complex the password the harder it is for a human to remember it.
What may interest people in these standards is what isn’t included. There is nothing about forcing a password change at given intervals. Nor is there anything about using upper and lower case letters and number substitutions. In the case of the former, remembering passwords is hard, especially given the other piece of password advice to use different passwords with different systems, so forcing users to remember new ones every few months is self-defeating as they will simply either write them down or try and cheat the system by using their existing password with a 1 on the end.
Using upper and lower case and other combinations has little real impact on the ability to crack passwords as the power of computers is ever increasing they find such things trivial to overcome.
Using a deny list, and there are many freely available examples, prevents users choosing passwords that are known to be weak or that have been previously seen in breaches. This, alongside an education campaign dealing with choosing a strong password can have a marked improvement in password safety.
The National Cyber Security Centre recommend two things in relation to passwords. The first is to use a password that consists of three random words. For example twelve angry giraffes. When combined with minimum length restrictions it means that it will generally lead to longer but more memorable passwords than using random characters.
The second recommendation is one we raised earlier – the use of password manager software. Not only do these applications store passwords they also generate them and because there is no attempt to make them memorable they can be longer and use a range of characters that may not otherwise be used.
While there can be challenges deploying password managers in multi-user settings, as a minimum it is worth considering for situations where users have a dedicated device, for example if all staff have their own laptop. This is particularly useful where specific business systems have additional username and password layers as the rules on password strength, complexity and reuse also apply to these systems so a password manager can ensure that each system has a high quality password.
Finally, although not in the standard it is worth a quick comment on some common advice I’ve seen given with regards to not saving passwords in browsers. Given that users should have their own accounts and not be using browsers where others will be able to access the passwords it would seem that the benefits of being able to store complex passwords, individual to each site outweighs the risks posed from saving them in the browser. The obvious exception to this would be in shared user environments such as home equipment that hasn’t been set up with different accounts for different family members.
With that we draw to a close the review of the first two standards. As noted at the start, everything here is supposed to be in place already and yet there is quite a lot of ground covered. If you are unsure how your current infrastructure matches up to these standards, or just want added assurance that the best practices that you think apply actually do, an audit against the standards would be a good place to start.
We’d be happy to help guide any school or college through this process so please get in touch if that would be useful.
In the next article in the series we will move onto two parts of the standard covering user accounts and how they should be created and secured.
