Suggested audience: School digital champions, ICT Co-ordinators, Network Managers, local authority technical teams.
This document describes the controls available across the range of digital tools in the Hwb Platform and how these tools can be used to enable organisations to maintain the security of the information they use.
Government Security Classifications
The Government Security Classifications cover three levels: OFFICIAL, SECRET and TOP SECRET.
The levels are defined as follows:
The majority of information that is created or processed by the public sector. This includes routine business operations and services, some of which could have damaging consequences if lost, stolen or published in the media, but are not subject to a heightened profile.
Very sensitive information that justifies heightened protective measures to defend against determined and capable threat actors. For example, where compromise could seriously damage military capabilities, international relations or the investigation of serious organised crime.
HMG’s most sensitive information requiring the highest levels of protection from the most serious threats. For example, where compromise could cause widespread loss of life or else threaten the security or economic wellbeing of the country or friendly nations.
Information processed within the school environment will be at the OFFICIAL level.
For OFFICIAL data, information security controls should:
- Protect against deliberate compromise by automated or opportunistic attack
- Aim to detect actual or attempted compromise and respond
Full details are available in the associated Cabinet Office documentation.
For Hwb, security controls are referred to as standard and enhanced, only some aspects of Hwb have enhanced controls available.
Standard controls are intended to be suitable for the majority of Hwb users and to provide appropriate protection for low sensitivity personal data and OFFICIAL information.
For personal data the decision about what controls to use lies with the data controller (in schools this will normally be the headteacher).
In addition to the proposed approach for Hwb, formal advice is available on the ICO website to assist data controllers to decide what level of control is necessary.
The following table illustrates typical usage scenarios, however there are likely to be legitimate reasons to deviate from this model depending on a organisation’s specific circumstances; any such deviation is a local risk management decision.
Please refer to the control selection flowcharts applicable to each aspect of Hwb for further clarification.
Hwb Standard Controls Suitable?
Hwb Enhanced Controls Suitable?
General school information including attainment data from the MIS (e.g. SIMS, Teacher Centre), which does not include sensitive information.
Pupil information from the MIS, for example for use on school trips.
SEN data can often include sensitive information; a local decision should be made based on the context and content of the data to determine whether enhanced controls are justified.
Yes - recommended
Child safety investigations tend to be sensitive in nature and require confidentiality; this will normally necessitate enhanced controls.
Yes - essential
E-mail is not secure by default, in theory anyone with access to an e-mail as it travels across the Internet can view the contents. The content of an insecure e-mail is similar to a postcard while it is going through the postal delivery system.
The diagram below illustrates a simple e-mail journey without encryption, it is unlikely that someone with access to the route taken by the e-mail across the Internet will be able to read it, but it is possible.
Encryption can be used to reduce the risk of e-mails being viewed during transmission between e-mail systems.
Encryption of e-mail is recommended for any e-mail containing personal data, doing so will ensure that no matter how lucky or clever a hacker is they will not be able to read the contents of the e-mail while it is travelling across the Internet.
There are many different options for encrypting e-mail, some of which are easier to use than others, though the choice of which encryption method to use should be primarily based on the sensitivity of the e-mail.
There are three e-mail encryption options available in Hwb:
- Enforced TLS
- Office 365 Message Encryption
The following table summarises potential usage scenarios and considerations for use for each of the options available in Hwb.
Recommended as the minimum for any e-mails containing personal data
No user action necessary.
Configured by the Hwb Team
BUT, it only works for partner organisations that support it (add link).
Office 365 Message Encryption
For sharing sensitive information with controlled circulation.
Suitable for e-mails that can’t be protected using other options, for example e-mails to parents.
Different restrictions possible for different levels of sensitivity.
Can help to reduce the risk associated with the use of personal devices.
External recipients that do not have a Microsoft account will need to have HTML enabled in their e-mail client.
Suitable for the highest sensitivity information and where strong assurance is required that only intended recipients will have access to the contents.
Both sender and recipient(s) need a S/MIME certificate.
Hwb is not currently configured to support the use of S/MIME with Outlook on the web. This can only be used with the Outlook desktop client.
Not well suited to large distribution groups.
Encryption based on TLS (this is the same encryption that is used for secure access to websites, for e-mail it is often referred to as STARTTLS) is optional for e-mail servers exchanging e-mail across the Internet.
The diagram below illustrates the scope of TLS effectiveness when used for communication between e-mail servers.
It should be noted that after e-mail has been delivered to the recipient’s e-mail server, subsequent encryption of e-mails is dependent on any onward routing of e-mail and also the recipient’s e-mail app configuration.
Most e-mail services, such as Office 365 and Gmail, can use TLS, but it is not universally supported, therefore it cannot be configured as a requirement for all e-mail to and from Hwb, doing so would prevent some e-mail systems from being able to send to or receive e-mails from Hwb.
However, with Office 365 it is possible to enforce TLS selectively, the Hwb e-mail service has been configured to provide the widest practical use of enforced TLS.
Hwb has been configured to enforce TLS for all e-mails sent and received:
- Between Hwb users
- Between Hwb and partner organisations
There is no user action necessary, encryption is applied transparently according to pre-defined rules.
The configuration for enforced TLS on Hwb includes:
- A manual check of the destination domain’s DNS MX record
- Confirmation that the mail server supports STARTTLS
- Creation of an Exchange Online mail flow rule that requires TLS for all e-mail is based on:
This tells Office 365 which e-mails the rule is applicable to.
Configuration example: hwbcymru.net
- Mail server address (from MX record)
This helps to prevent malicious changes to DNS resulting in e-mail being routed to systems controlled by hackers.
Configuration example: protection.outlook.com
- Requirement for a CA issued TLS certificate
This helps to ensure that the mail server is reliably ‘authenticated’ before e-mail is sent
The configuration is ‘fail safe’, the implication of which is that if encryption fails for any reason, the e-mail will not be sent.
Office 365 Message Encryption (OME) is a Microsoft service specific to Office 365, which has been licensed for all Hwb users.
OME uses a combination of encryption and rights management to enable protection that stays with an e-mail after it has been sent, this provides additional assurance that information will only be accessible by people it has been shared with.
Hwb Message Encryption has been configured to work automatically if a user includes the key words ‘secure mail’ or ‘post diogel’ in the subject line of an e-mail.
S/MIME should be considered for use with higher sensitivity information, especially where other controls, such as MFA, are not practical.
S/MIME works by using certificates, one is public and one is a private. The public certificate is shared with other people and can be used to encrypt messages. You will need someone’s public certificate if you want to send them S/MIME encrypted e-mails.
The private certificate is used to unlock e-mails, this certificate needs to be kept secret. After installation it is protected by the computer’s software. Any backup copies of the private certificate need to be stored securely.
It is this use of certificates that leads to the main benefit of S/MIME, a hacker would have to gain access to your device and the private certificate to be able to view S/MIME encrypted e-mails.
If a hacker guesses your password and is able to login to Hwb, but without access to your device, they will be able to access all your e-mails, but any S/MIME encrypted e-mails will remain encrypted and inaccessible to the hacker.
S/MIME is an option that is available to any Hwb user. It requires a user to have a locally provisioned certificate, which can be configured locally and does not require the Hwb admin team to make any changes to Hwb.
An e-mail protected using S/MIME will only be accessible on devices configured with the corresponding certificates, if a mailbox is compromised from a different device S/MIME e-mails will not be accessible.
- Sender and recipient both need their own certificate
- Users with S/MIME setup must choose to encrypt e-mails in Outlook (otherwise the e-mail will be sent normally)
Phishing is the term generally used for e-mails that try to persuade people into giving up sensitive information, primarily passwords.
Phishing e-mails normally pretend to be from a trusted source using one or more of the following tricks:
- Faking the sender’s e-mail address
- Copying images and styles from genuine e-mails
- Using urgent or ‘panic’ inducing messages
Phishing e-mails used to be easy to identify because they had spelling mistakes or grammatical errors, however, they are becoming increasingly sophisticated.
Phishing e-mails will almost certainly include an attachment or link that you are encouraged to access. An emerging strategy is to create a copy of the Office 365 login so that an attacker can capture the username and password of unwary users.
Only access Hwb from your favourites or by typing the Hwb URL into the browser address bar.
If you receive an e-mail that is encouraging you to access a link or open attachment, pause and consider whether you are expecting the e-mail and whether there are any tell-tale signs that it might not be genuine.
Hwb Anti-Phishing Measures
Hwb has applied a number of measures to try and make it easier to spot phishing e-mails, as well as reducing the number that get through. The following summarises the measures.
E-mails related to Hwb will never include links, if there is something urgent that requires your attention the e-mail will notify you about it, but any links will be published on Hwb.
Hwb will not send e-mails to any other e-mail accounts you have. If you receive an e-mail at home, which looks like it is from Hwb, it will be a phishing e-mail. It would be helpful if you could forward any such e-mails to the Hwb Service Desk – email@example.com.
Hwb e-mail has been configured with a number of technical controls to minimise the number of phishing e-mails delivered to Hwb users, they include:
- Office 365’s anti-phishing service, which uses machine learning and detection algorithms to detect phishing e-mails
- DMARC, which is a way of organisations that send e-mail let other e-mail systems know what to do with e-mail that does not come from authorised senders for Hwb
- Office 365 Safe Links, which provides filtering to block access to known malicious websites. It should be noted that this may not be effective against all sites and therefore does not remove the need for individual vigilance!
Authentication is the term used to describe the process of checking someone is who they claim to be.
Most people are familiar with username and password for authentication. For a long time relying on passwords in isolation was adequate for preventing hackers gaining access to someone’s account.
There are additional ways of checking someone is who they claim to be, for example using a finger print.
The different ways of authenticating someone are based on three properties or factors:
- Something you know
- Something you have
- Something you are
Something you know is the most common property used for authentication and usually takes the form of a password or PIN.
An example of something you have is a physical ‘thing’ of some description, often it will involve submitting a code so that it is possible to confirm that you currently have item.
Something you are relies on biometrics, while they are becoming more widely adopted, for example finger print readers on phones, they are not currently well suited to cloud services authentication.
In isolation each factor is susceptible to attack, but when combined they can be difficult to defeat. A combination of more than one type of factor is often referred to as multi-factor authentication or simply MFA.
For online systems such as Hwb, the use of an additional factor is a very effective way to ensure that a leaked password does not provide full access to someone’s account and all the information it contains.
Having multiple combinations of one factor, for example two or more passwords, is not multi-factor authentication.
The use of MFA is strongly encouraged due to the benefit it has for preventing unauthorised access to information, particularly if it protects personal data of a sensitive nature.
Hwb MFA (Enhanced Control)
MFA on Hwb is a configurable option in Office 365 that requires both a password and submission of a time-limited code during the logon process.
The code is generated by the Microsoft Azure Authenticator app, which needs to be installed on a smartphone. The app does not need an always on Internet connection after installation, so it will still work in places with weak or no network coverage.
Note: The Azure Authenticator app is a code generator. After the Azure Authenticator app has been installed the app will generate a code which changes every 30 seconds. The code is entered during logon to Hwb. Your Hwb account can only be linked with one instance of Azure Authenticator i.e. it can only be used on one phone. More information about the app is available on the Microsoft website.
The use of MFA is required for higher risk logon scenarios, which are mostly applicable to administrative staff.
For Hwb users the mandated use of MFA is currently only applicable to Digital Champions when accessing the User Management Portal from outside schools’ networks.
The rules for MFA can be configured by Hwb to allow flexibility so that MFA is only selectively required, for example:
- People with access to sensitive information
- Logon from unknown locations, for example when not on the school network
- Access to specific applications (that process sensitive information)
For MFA to be effective there is an assumption that staff with access to sensitive data will not share their phone with others or leave it unattended and unlocked.
Hwb has defined recommended combinations of controls applicable to collaboration areas.
The standard controls are anticipated to be the most suitable configuration for most of the collaborative working undertaken by Hwb users.
Azure Multi-Factor Authentication (MFA) and Azure Rights Management (RMS), described in more detail below, are Enhanced controls, they are recommended wherever there is a need to work collaboratively with sensitive data.
Local risk decisions and guidelines should be followed whenever working with personal data, however the anticipated usage scenarios for the different levels are:
- Enhanced- Suitable for sensitive information
- Level 1 – recommended to ensure that documents remain secure by having controls that ‘travel’ with the document.
- This control level may also be suitable where there is an identified need to collaborate with large numbers of external users and confidentiality of low sensitivity information is important.
- Level 2 – recommended only for small groups of users; there is a reliance on users’ awareness and vigilance with respect to information security.
- Level 1 – recommended to ensure that documents remain secure by having controls that ‘travel’ with the document.
- Standard– Suitable for every day working and collaboration, which may include identifiable data, but will normally be unsuitable for more sensitive information
It is recommended that external sharing is constrained to small groups of users due to the lack of knowledge of how third parties manage information security.
Expected Number of Users
Enhanced level 1
Enhanced level 2
Files stored on G Suite for Education are protected by encryption during upload / download and when stored on G Suite for Education servers, but there is no option for explicitly encrypting files directly i.e. if a file is downloaded from G Suite for Education it will not be encrypted on the destination device.
G Suite for Education is appropriate for processing personal data, but where sharing of files containing personal data is required the controls available in Office 365 should be utilised.
Team Drive File Restrictions
G Suite for Education Team Drives can be configured to restrict how users can interact with files. The following setting can be configured:
Prevent commenters and viewers from downloading, copying, and printing files in this Team Drive
This configuration option will prevent uncontrolled copies of files being downloaded by any people with the commenter or viewer role. Depending on the collaboration scenario this may be an appropriate level of control for sharing content with external users.
Any users with edit access (contributors, content managers and managers) will be able to download copies of any files.
Rights Management – Enhanced Control
Azure Rights Management (RMS) is a form of digital rights management that provides additional control for file access, that ‘travels’ with the file.
In Hwb the use of RMS is currently constrained to supplementing the existing network access controls for SharePoint libraries containing sensitive data. Microsoft Office files stored in these secured libraries will automatically have RMS applied and will only be accessible by the users with access to the library.
A file that has had RMS applied will require a user to provide credentials for access to the file, even when they are accessing it outside the online environment. Encryption is used to prevent anyone without permission from accessing the contents of the file.
Applying RMS to a document will help ensure that irrespective of who has access to the file only pre-authorised people can view its contents.
Please contact your local SharePoint administrator for more information.
Multi-Factor Authentication (MFA) – Enhanced Control
Personal cloud storage drives can benefit from MFA being applied to a user’s personal account, in the same way as other services.
File level Password Protection - Enhanced Control
Microsoft Office’s native password protection can be used to protect files containing sensitive data, though this does introduce some restrictions on the access methods for the document (summarised below).
The Google G Suite for Education online applications for files do not directly support password protection.
Is password protection available?
Can you save to online Drive?
Can you view protected file contents online?
Can you edit protected file contents online?
G Suite for Education
Office 365 online
Office 365 desktop