4. Network & Data Security

4.1 Facility security

All ELD primary servers are located in OVH data centres in London. These data centres are physically staffed 24/7, secured using a restrictive perimeter system and video surveillance, with access controlled and regulated through an identity/authorisation badge system.

OVH is certified ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, ISO/IEC 27701 and CSA STAR for providing and operating dedicated cloud computing infrastructures based on the ISO 27002 and ISO 27005 security management and risk assessment standards and associated processes. All physical hardware is PCI DSS compliant and bears the BSI Kitemark.

All ELD secondary servers are located in OVH data centres in Frankfurt, with the same security measures and certifications/compliances as those in London. These data centres are designated for DR and BCP purposes unless otherwise requested by a client.

All server backups are stored with AWS in Ireland. AWS is certified for compliance with ISO 9001, ISO 27001, ISO 27017 and ISO 27018.

4.2 System security

All servers are built to ELD specifications, designed specifically for hosting the Moodle/IOMAD application using the Ubuntu Server Operating System. Each server has its own individual firewall, Intrusion Detection Software (IDS), Intrusion Prevention Software (IPS), and DDoS Protection Software.

The OVH infrastructure is anti-DDoS/IPS-enabled by default, with infrastructure-specific IDS automatically performing quarantine actions triggered by suspect network traffic.

• Industry-standard encryption algorithms and technologies are used to protect data in transit and at rest.
• TLS certifications managed by ELD are automatically renewed using LetsEncrypt/Certbot.
• All ELD servers are backed up to an encrypted off-site location nightly. Backups are kept for 30 days.

4.3 Monitoring, patching & vulnerability scanning

ELD monitors all servers using Nagios and Munin to provide 24/7 alerts on emerging or critical issues such as filesystems filling up, high server load, or issues with web connections. Any emergencies are handled 24/7, with normal support available during office hours.

• Network infrastructure scanning/patch application is controlled and managed by OVH.
• Application vulnerability mitigation/patch release is controlled by Moodle Pty Ltd, and patch application is managed by ELD (within 48 hours of release).
• Operating system (OS) scanning/patch applications are controlled and managed by ELD as part of server standard builds (security patches are applied within 24 hours of release).

4.4 Redundancy provisioning

ELD servers are built upon VMWare ESX Clusters, which have redundant physical servers backed by redundant SAN-based disks. The ESX clusters are located in state-of-the-art data centres, which also feature redundant power and Internet connections. This infrastructure is designed to continue to run in the event of any physical hardware failure in a server, disk or network.

4.5 Access control

All ELD systems are configured to only allow authorised and authenticated users, utilising Identity and Access Management (IAM) systems where possible, in line with Role-Based Access Management (RBAC) protocols.

• All access rights require explicit authorisation/approval by ELD’s Head of IT before being granted.
• Privileged access rights are grouped by role function, and all systems are segregated by access control lists to ensure ELD staff only have access to the information they require to fulfil their specific role.
• All systems that support Multi-Factor Authentication (MFA) have been appropriately configured; if MFA is not possible, password complexity rules are increased accordingly.
• All password policies are documented, including creation complexity rules and change protocols in the event of exposure, breach, or suspected breach.
• All device-specific user accounts (e.g. laptops, tablets, mobile phones) are unique, as are user accounts on any system which permits the use of primary and secondary account types or separate accounts within the same application.
• Where there is no capability to have child or linked accounts/separate users, logins are shared; password vault access for shared services is strictly managed and controlled in line with RBAC protocols.
• System/OS and Moodle/application passwords are never stored in clear text.

A unique ELD Admin account is required for all installations for support purposes; clients are responsible for the management and implementation of all other access control policies for their own Moodle installation.

5. Incident Handling Measures

5.1 Incident definition

An incident in the context of this policy is an event or action (both confirmed and suspected) which may compromise the confidentiality, integrity or availability of systems or data, either accidentally or deliberately.

An incident includes, but is not restricted to, the following:

• system failure;
• unauthorised use of, access to or modification of data or information systems;
• attempts (failed or successful) to gain unauthorised access to information or IT system(s);
• unauthorised disclosure of sensitive/confidential data;
• hacking attack;
• password compromise;
• human error; or
• ‘blagging’ offences, where information is obtained by deceiving the organisation that holds it.

5.2 Incident reporting

• Confirmed and suspected security incidents will be reported internally by ELD staff, following documented procedures and protocols.
• Confirmed and suspected security incidents should be reported by clients via email to security@e-learndesign.co.uk, by calling 0845 474 4512, or through the helpdesk reporting web page.

5.3 Incident containment

• Once notified internally of a confirmed or suspected security incident, ELD will take the appropriate steps for containment and mitigation of potential data loss.
• Once notified by a client of a confirmed or suspected security incident, ELD will take the appropriate steps to assist them in containment and, where possible, recovery of any lost data through backups.
• Should a confirmed or suspected data breach or security incident be due to a client password compromise, clients should update their passwords as soon as possible.

5.4 Incident investigation and impact assessment

• Immediately following any incident, a full investigation (including root-cause analysis and impact assessment) will be undertaken to identify any actions necessary to prevent recurrence.
• If appropriate, a report recommending client-specific changes to systems, policies and procedures will be provided for consideration.
• If required, any actions necessary to prevent recurrence will be undertaken by ELD.

5.5 Post-incident reporting

• Immediately after investigation, ELD will send reports to impacted clients with details of what the incident was, the root cause, and the steps taken and/or planned to prevent recurrence.
• If deemed necessary, an official report will be made to the appropriate authority by ELD.

All incidents will be documented, even if an official report is not deemed necessary.

6. Disaster Recovery & Business Continuity

6.1 Standby provisioning

ELD provides all hosting clients with a Warm Standby VM solution as standard, where a prepared server is kept available as a destination to recover client data from off-site backups. This secondary location will not be within the UK (if UK primary hosting) or EU (if EU primary hosting) and will only be used in the case of a severe outage in the primary location.

ELD offers an optional Hot Standby VM solution to dedicated server clients where the live server is mirrored to a redundant VM in a separate data centre location in real-time using Zerto. This secondary location will not be within the UK (if UK primary hosting) or EU (if EU primary hosting) and will only be used in the case of a severe outage in the primary location.

In the event of a disaster, all network traffic will be internal to ELD’s data centre private networks (with respective UK or EU endpoints), so all locations will still be considered to be in the UK or EU for the purposes of cross-border data transfer laws.

6.2 Disaster Recovery (DR) triggers

• all connectivity to the primary location data centre is lost;
• the primary location ESX Cluster suffers a catastrophic failure;
• corruption of a client server’s underlying disks;
• hostile takeover of the server OS (e.g. for ransomware purposes); and
• other catastrophic failure of the server OS, which requires a point-in-time recovery.

6.3 Disaster Recovery (DR) protocols

In the case of a catastrophic event, steps specific to a Client Standby VM solution will be taken.

Warm Standby VM

Recovery Time Objective (RTO): Service restoration within 24 hours of disaster declaration, excluding DNS propagation delays.
Recovery Point Objective (RPO): Up to 24 hours filesystem data loss, depending on time of last backup.

Step 1: Server available for client site recovery.
Step 2: Copy-back of the last filesystem backup to the new server. The copy-back timescale will depend on data size.
Step 3: Client’s staff informed of any changes they need to make to the DNS entries to ensure that their staff and students are connecting to the correct server.
Step 4: All backups and monitoring subsequently updated to point to the new server.
Step 5: Rollback to the original data centre coordinated once it becomes available.

Hot Standby VM

Recovery Time Objective (RTO): Service restoration within sixty minutes of disaster declaration, excluding DNS propagation delays.
Recovery Point Objective (RPO): Maximum data loss of five minutes under normal operating conditions.

Step 1: Hot Standby server VM brought online, removing the synchronisation from the original live server VM.
Step 2: Where possible, the original server will be switched off to ensure that there is no erroneous access to this system.
Step 3: Client’s staff informed of any changes they need to make to the DNS entries to ensure that their staff and students are connecting to the correct server.
Step 4: All backups and monitoring subsequently updated to point to the new server.
Step 5: Synchronisation set back to the original data centre once it becomes available.

6.4 Business Continuity Plans (BCP)

There are multiple redundant systems built into the servers for a Client and the data centres housing them. If these systems are no longer available, ELD will enact the DR procedures to bring the systems online within a different data centre.

Server backups are held in discrete off-site locations. These form the last resort methods for DR and allow a Client’s servers to be rebuilt using any other compute resource providers, such as Amazon, Rackspace, Azure, etc.

All of the ELD internal systems use infrastructure to allow ELD staff to work from anywhere. For example, a cloud-based helpdesk system, a distributed and cloud-based solution for documentation, and VoIP and/or mobile phones for telephony. As long as there is either an internet or 5G connection, ELD staff can work as usual:

• ELD use email, social media and telephony to relay information to clients. Should there be an issue with one of these, the remaining would be used for backup.
• ELD uses several cloud-based online meeting solutions, so multiple alternatives are available should the preferred option be offline.
• Access to ELD’s helpdesk and support is available through email or a web portal. The helpdesk uses a separate email solution from ELD internal provisioning.

ELD will ensure that clients are made aware of the best channels for support in the case of contingency.

6.6 Testing and review

DR testing is performed on a rolling basis for all ELD servers every 6 months; BCP protocols are reviewed every 12 months.