Case study for COIT20265 and COIT13236
Case study for COIT20265 and COIT13236
The Global University
Case study for COIT20265 and COIT13236 Units
Objective
You are to design and build a secure, responsive, reliable, scalable, and resilient distributed system to support the online learning operations of a large university.
Background
The Global University (TGU) is one of the world’s largest online learning universities with more than 250,000 students undertaking undergraduate and postgraduate studies worldwide. At TGU, all education services, courses, programs and units of study are internally authored and delivered online both synchronously and asynchronously using TGU’s proprietary network infrastructure. TGU’s headquarters is in France, where it houses around 2,000 academics and about 4,000 administrative, operational and student support staff. In France, TGU also has a world class learning and teaching research centre (LTRC) with about 1,000 research staff. Since its inception, TGU has structured its academic operations into faculties; but just recently, TGU decided to consolidate its operations into seven schools, namely, 1. Arts and Social Sciences, 2. Business and Economics, 3.
Education and Language Studies, 3. Engineering and Maths, 4. Health Sciences, 5. Learning Technologies and 6. Science.
TGU network infrastructure interconnects its operations with the global research and education network community across multiple 100 gigabit per second (Gbps) dense wavelengths division multiplexing (DWDM) leased links over multiprotocol label switching (MPLS). TGU has four (4) strategically located private cloud data centres (CDCs) in Japan, Argentina, India, and South Africa respectively. Each CDC is typically equipped with application servers, virtual machines, physical machines, load balancers, bare machines, storage and Internet access.
At each CDC there is also a proprietary remote access laboratory, the university uses to support laboratory experiences for students enrolled in STEM units (Science, Technology, Engineering and Maths). A remote lab is a set of network-connected physical devices that can be observed and controlled at distance. Lately, these laboratories are becoming an issue for TGU because of their age, lack of interoperability, and high running costs. TGU decided to upgrade these remote labs by a state-of-the-art massive open online laboratory system (MOOL) offered as services (Lab as a Service or LaaS). The LaaS, conceptualised in Figure 1, features a modern service architecture typical of cloud computing [1]. From Figure 1, there is a lab service provider and a lab service consumer. Stakeholders can be teachers, students, learning designers, and lab owners.
Networks and Information Security Case study - Copyright 2020 © Edilson Arenas – CQUniversity
Similarly, TGU uses a customised proprietary Learning Management System (LMS) to support the management of learning, teaching and research. The LMS server (located in the headquarters) is nearly at the end of its lifetime, and like the old remote labs, TGU has decided to replace it for a more contemporary GNU General Public Licence. After an extensive research, TGU opted for Moodle [2] as the LMS to support its learning, teaching and research operations. There are hundreds of plugins for Moodle, extending the features of Moodle's core functionality. Table 1 lists some examples of plugins TGU aims to use:
Plug-in |
Aim |
Video-on-Demand (VoD) |
To stream video lectures |
Electronic Portfolio |
To enable students to keep their journals and learning experiences |
Web Conferencing |
To support web conferencing including real-time online classes, online meetings, chat, and mobile collaboration |
LaaS via Moodle |
To support the learning experiences of students enrolled in STEM units (Science, Technology, Engineering and Maths) |
SCORM Content Authoring |
To create reusable SCORM content |
Academic Integrity |
To promote academic integrity, streamline grading and feedback, deter plagiarism, and improve student outcomes |
Learning and Academic Analytics |
To track students’ learning experiences, personalise the learning environments, and improve the academic practices in general. |
TGU goal is to become the world’s largest online learning university by providing learning environments tailored to the learning needs of contemporary students. To that end, the following is the list of requirements to consider.
General Requirements
- The new system should scale to support a student base growth of 10% yearly for the next three years.
- The new Moodle LMS should leverage four-tier application architectures.
- The new system should operate 24/7, except for some scheduled downtime maintenance windows.
- The mean availability of the new system should fall within industry standard systems, typically between 99.5 per cent and 99.9 per cent uptime.
- All network tasks and services concerning the new system should be automated to improve business efficiency and effectiveness.
- The services running in the new system should be accessible from any device including desktops (Windows and MacOS), laptops (Windows and MacOS), tablets, and smart phones (Android and iOS).
- The services running in the new system should be compatible with all major browsers including Chrome, Firefox, Safari, Internet explorer, and Opera.
- The new infrastructure should provide support for the on-demand storing and streaming of HDTV videos (1080p 1920×1080 progressive scan) produced for each of the units of study.
- The new infrastructure should support the real-time streaming of online classes, online meetings, chat, and mobile collaboration.
- The new system should leverage micro-services technology. It is estimated that around 1,000 micro-services will be available to control all the components of the new network service.
- The new system should leverage the deployment of the latest 5G digital cellular network services.
- The new system should leverage the Internet of Things (sensors located at each LaaS); and devices like students’ Apple Watch and augmented / mix reality gear employed by TGU to gather data on the habits and patterns of its students.
- The new system should support the implementation of learning and academic analytics.
Security Requirements
- The security of the Moodle system and remote labs (LaaS) should be as solid as possible to defend against both physical and malware attacks specifically designed to compromise the lab equipment, application stack, web services, micro-services, and the cloud infrastructure in general.
- For remote lab access via a Moodle activity, the authentication should be done at the Moodle LMS and the authorisation at a third-party authorisation server that checks the validity of the Moodle LMS as a consumer for the lab.
- The implementation and configuration of LaaS (at the four CDCs) should leverage load balancers, proxy servers, reverse proxy server, and NAT (Network Address Translation).
- The LaaS and the Moodle LMS internal range of private IPv4 addresses should be 172.16.0.0/12
- Any security event at LaaS or Moodle LMS should be resolved within three hours of being logged (from event detection to ticket generation, and final resolution). The optimal goal would be the resolution of such events in real-time using automation as much as possible.
Statement of Works
TGU is concerned that changing its infrastructure from proprietary to commercial-of-the-shelf solutions (COTS) (LaaS and Moodle) will likely cause a big impact on the security of its operations. On these grounds, TGU has contracted YOU to conduct a preliminary assessment of the situation and recommend the senior management on the feasibility of the project. This should include:
- A business analysis and recommendation to TGU of the most appropriate infrastructure to host the Moodle LMS and LaaS integration. You need to recommend from a mix of on-premises private and third-party; or fully public cloud services; or hybrid (private clouds running on rented datacentres spaces). Your business analysis should be based on five factors, namely, compliance, performance, privacy, cost, and control. In your final recommendation, you should justify your selection in terms of technical issues concerning the security, responsiveness, reliability, scalability, and resiliency of the system. This is not a copy and paste activity. You should contextualise your analysis and recommendation in accordance with TGU requirements and goals.
- Using both the general and security requirements; and the background outlined in the introduction of the case study, conduct a thorough analysis and design of the new network infrastructure (Moodle and LaaS integration). As part of this, and based on your recommendation on point 1 above, provide a logical network diagram before and after the change of the infrastructure. Make sure to use the recommended internal range of private IPv4 addresses. You may use Packet Tracer or any other network diagram tool to draw your diagram.
- For the new network and system infrastructure, use the NIST Special Publication800-30 Guide for Conducting Risk Assessments [3] to recommend a cyber security risk mitigation strategy to TGU.
- Using the NIST Contingency Planning Guide 800-34, provide a tailored Disaster Recovery Plan (DRP) and a Business Continuity Plan (BCP) [4] that meets TGU business goals.
- Based on your cyber security risk management approach in point 3 above, provide a proof of concept (PoC) to demonstrate the security of the Moodle LMS as implemented in a four-tier architecture (see Figure 2).
Figure 2 Implementation Outline
About the PoC
The Moodle security PoC is not expected to be a full-fledged production system but a proof of concept. To that end, you need to decide on your infrastructure, i.e. network hardware, load balancers, servers, virtual machines, firewalls, and storage to host and secure the system. There are many alternatives. For example, you could set up a small home Internet network using three or four computers connected to a home router. You could also use a hypervisor like VirtualBox or VMware to create three or four instances of virtualised machines in your personal computer. However, given the popularity of cloud computing services, you are encouraged to develop a small virtual private cloud using the free options of educational cloud computing services from OpenStack Public Cloud, Microsoft Azure, Google Cloud or Amazon Web Services (AWS). In this case, you need to carefully select the computing platform to host your system including operating systems, data, utilities, application engines, and databases.
The PoC consists of three sub-tasks: 1. Moodle installation and configuration, 2. Moodle Hardening, and 3. Vulnerability / Penetration Test, described next.
1. Moodle installation and configuration
Download and install the Moodle package along with its associated software in the platform you chose to demonstrate the PoC. Then, configure the application according to the recommendations given by the Moodle site. The Moodle site contains many community resources and tutorials showing you how to do that.
Using Figure 2 as a reference, provide a physical network diagram of your PoC labelling the technical components of your infrastructure including the interfaces, type of connections, operating systems, databases, servers, firewalls, etc.
2. Moodle Hardening
The Moodle hardening process should be a holistic approach consistent with your cyber security risk management approach recommended in point 3 above. It should encompass ten (10) system administration good practices aimed to make the Moodle system more solid and secure. These practices might include, but not limited to, data encryption, the use of secure protocols (HTTPs, SMTPs, etc), closing of unnecessary service ports, use of twofactor authentication, enforcement of strong password policies, automation of password recovery and password change, change of SSH TCP port from the default 22 to a nonstandard TCP port, data backup and recovery automation, use of host-based IDSs and network-based IDSs, configuration of firewalls and NATs, DHCP hardening, use of whitelisting, and organisation of users into groups.
In hardening the Moodle system, you are required to explain how your Moodle security implementation protects against each of the security risks listed and compiled by OWASPtop 10 (Ten Most Critical Web Application Security Risks).
3. Vulnerability / Penetration Test
Based on your security risk management approach recommended in point 3 above, use free tools, for example Kali tools [5], to perform both vulnerability and penetration tests in your system. You should perform 10 tests. For each test provide the following:
- a screen shot of the test,
- a short description of the test (what was the test about),
- the test activity (how the test was conducted),
- the desired outcome (expected result), and
- the observed outcome (what you found)
You MUST use the accompanying MS WORD template found in the unit website to submit your final assignment. DO NOT CHANGE the format of the MS WORD template. The template is a specially formatted document that contains useful tips and important guidelines to address the project requirements.
For the latest information and supporting resources on this project, please refer to the unit website.
References
- Tawfik et al., “Laboratory as a Service (LaaS): A Novel Paradigm for Developing and Implementing Modular Remote Laboratories,” International Journal of Online Engineering (iJOE), vol. 10, no. 4, pp. 13–21, Jun. 2014.
- ‘Moodle - Open-source learning platform | Moodle.org’. [Online]. Available:
https://moodle.org/ [Accessed: 10-Feb-2020].
- ‘Guide for Conducting Risk Assessments | NIST’. [Online]. Available: https://www.nist.gov/publications/guide-conducting-risk-assessments?pub_id=912091.
[Accessed: 10-Feb-2020].
- ‘SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems | CSRC’. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final. [Accessed: 10-Feb-2020].
- ‘Penetration Testing Tools - Kali Linux’. [Online]. Available: https://tools.kali.org/. [Accessed: 10-Feb-2020].