Capstone Project Final Report

CQUNIVERSITY
Capstone Project Final Report
COIT20265
COIT13236
Design of a Distributed System to Support the Online Learning Operations of a Large University

EXECUTIVE SUMMARY

This should be a brief section, not larger than a page, that summarises the key facts relating to the project; purpose and goals; scope and deliverables; issues encountered; lessons learned; and other facts that you might think are important to highlight. Do not include in this executive summary any background information or introductions.

1. INTRODUCTION

The introduction should be a clear and concise description of your project in terms of TGU’s needs and requirements. Make sure to include a background to the case study (i.e. characterisation and importance of large distributed systems), description of TGU, TGU business domain, requirements, and statement of works. The last paragraph of the introduction should be an outline of the structure of this report.

2. BUSINESS ANALYSIS AND RECOMMENDATION

2.1 Large Distributed Systems Literature Review

This section should discuss Large Distributed Systems. Use it as the theoretical background to frame your recommended infrastructure. What is a distributed system? How does it differ from traditional centralized computer architectures? Security, configuration, performance, scalability, and resiliency issues of distributed systems? Distributed Systems vs Cloud Systems? Are they the same? Cloud Computing Platforms: IaaS, PaaS, SaaS?

2.2 Infrastructure Recommendation and Justification

This section should discuss the cloud infrastructure options available to TGU. First, you should provide a background of what constitutes: a) private; b) private and third-party; and, c) fully public cloud services. Secondly, highlight the advantages and disadvantages of all options in terms of the following five factors:

1. Compliance (this might include, for example, government conformance, regulations, etc.).
2. Performance (for instance, speed, reliability, etc.).
3. Privacy (for example, security risks, law enforcement, etc.).
4. Cost (for instance, total cost of ownership, ROI, running costs, etc.).
5. Control (for example, flexibility, specifications, automation, etc.).

2.2.1 Recommended Infrastructure

In this section, using the five factors outlined in section 2.2, choose your option: a) private; b) private and third-party; or, c) fully public cloud services. Then, justify your recommendation to TGU based on its business and technical needs. Make sure to elaborate on the security, configuration, performance, scalability, and resiliency of the recommended system.

This is meant to be a holistic recommendation. To that end, frame your justification around facts that add value to your recommendation. You may consider, for example, the nature of the business organization (i.e. TGU), its organisational culture, mission statement, size, widespread geographical locations (France, Japan, Argentina, India, and South Africa), coverage, quality of service, competition, interoperability, ROI (return on investment), TCO (total cost of ownership), vertical or horizontal integration, level of automation, operations, and service level agreements amongst others.

If you use figures and tables to support your argument, remember you should label, number, explain, and reference them appropriately. I expect that all tables and figures in the report are designed and produced by you. Copying and pasting original tables and figures is unacceptable. You should redraw and reference them accordingly.

3. ONLINE NETWORK INFRASTRUCTURE ANALYSIS AND DESIGN (Moodle and LaaS integration)

3.1 Network Analysis

The online network infrastructure analysis should address all requirements articulated in the case study. I suggest classifying the requirements in two groups: business requirements and technical requirements. Then proceed to abstract and analyse them using a LAN / WAN network design methodology that best matches TGU needs. The analysis should be conducive to deliver a logical network design (LANs / WANs). Ultimately, this design needs to be consistent with your recommendation in section 2 above.

Business Requirements

1. Reduce Costs
1. The running cost of the new LaaS and Moodle LMS will be lower than the present remote labs and proprietary LMS respectively.
2. All network tasks and services concerning the new system should be automated to improve business efficiency and effectiveness.
3. The new infrastructure should support the real-time streaming of online classes, online meetings, chat, and mobile collaboration.
4. The new system should support the implementation of learning and academic analytics.

Technical Requirements

1. Scalability
   • The upgraded system will be capable of supporting 10% more students every year for the next three years.
2. The new Moodle LMS should leverage four-tier application architectures.
3. Availability
   • 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.
   • DRP
4. Security
   • 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.
5. Adaptability
   • 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 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.

When performing the analysis, you may take into account the following questions:

• What does it mean to be a global organization with multiple geographical locations and operations? How does this impact your network design?

Being an International University, TGU has established its branches in different parts of the world having its headquarter in France. Despite, most of the important tasks and decisions are made in France, all other offices in Japan, Argentina, South Africa and India have Cloud Data Centers having application servers, virtual machines, physical machines, load balancers, bare machines, storage and internet access. It seems these CDCs are separate businesses on itself but they are all controlled by the head office.

• Which are the pros and cons of four-tier application architectures? Why do you think TGU opted for this type of application architecture?

• TGU creates, produces, and delivers its own content and microservices. What and how does this affect your network design?

• What is the role of Public Internet Service Providers (like, for example in Australia, Telstra and Optus) in your network design? What would be the optimum backbone network to interconnect TGU datacenters and operations?

• Providing Internet
• Uptime
• Internet failure information
• Redundant
• Hardware with built-in-fail-safe features

• Routing internet traffic
• Resolving domain names/ Domain name registration
• Maintain network infrastructure that makes internet access possible
• Web hosting
• Email services

• What measures do you need to put in place in your design to achieve a network availability larger than 99.5%?

• Use network design and device monitoring software (Server Monitoring, Configuration change monitoring, Application performance monitoring, Synthetic testing, Alerting)
• Implement a change control programme
• Use automated incident response solutions
• Use the cloud
• Have a rehearsed plan

https://www.advancedcyber.co.uk/it-security-blog/5-foolproof-ways-to-improve-system-network-availability

• Load balancing
• Distributed system
• Multiple ISPs
  • What is your action plan to supporting a subscription growth 10% yearly for the next three years?

As we are using Distributed System, it is easy to scale the system growth easily. (https://keetmalin.wixsite.com/keetmalin/single-post/2017/09/24/An-Introduction-to-Distributed-Systems)

• Avoiding single point failure
• Scaling horizontally not vertically
• Pushing work as far away from the core as possible
• API first
• Cache everything, always
• Design for maintainance and automation
• Asynchronous rather than synchronous
• Be ready for failure

Hierarchical Design helps in scalability.

• What are major traffic sources and stores? How does this affect your estimation of bandwidth requirements, QoS, routing protocols, flow control, and network efficiency?

User Comunities:

Data Stores:

Traffic Flows:

3.2 Logical Network Infrastructure Design

You may consider the following design-related questions:

• What topology do you think is more appropriate to support TGU cloud operations?
• What is your IP addressing strategy? Device naming strategy?
• How do you design for resiliency? Strategies, MTBF, MTTR, capacity planning, redundancy, load sharing vs hot spares, fault management, hardware and software failure, and congestion control?
• How do you design for scalability? Strategies, traffic separation, the use of cache, load balancing, data segmentation, queueing, threading, content delivery networks (CDN). How does the TGU environment use a CDN?

4. VULNERABILITY ASSESSMENT AND RISK MITIGATION STRATEGY

Recall this section should be completed in accordance with the NIST Special Publication 800-30

4.1 Cloud infrastructure security challenges

Before you tackle section 4, you should conduct a brief research literature to understand the security challenges faced by online network infrastructures similar to TGU.

4.2 Risk Analysis

4.2.1 Asset Assessment

• What information assets can you identify? How important are they? Which ones do you need to protect?

4.2.2 Risk Assessment

• What is the level of sensitivity for each of those identified assets?
• What threats might compromise the integrity of your assets?

4.2.3 Recommended Controls

• What methods, controls, and measures should be implemented to counter those threats?

5. DISASTER RECOVERY AND BUSINESS CONTINUITY PLANS

Recall this section should be completed in accordance with NIST Contingency Planning Guide 800-34

5.1 Disaster Recovery Plan

This should be a systematic disaster recovery plan to inform TGU on how to get all IT infrastructure and operations back to normal work after an outage.

You might consider the following:

• Highlight the importance of a DRP in terms of distributed systems like TGU
• What practices should TGU adopt to reduce outages?
• What is your recommended incident response procedure?
• What would be the structure of TGU Incident response team (IRT)? Who is responsible and for what?
• What elements should be included in an incident action plan?
• Would you recommend drills to test your DRP? If so, how?

5.2 Business Continuity Plan

This should be a systematic business continuity plan to inform TGU on how to get all business processes back to full functionality after a crisis.

You might consider the following thoughts:

• In case of a disaster, what is your recommendation to return TGU’s whole business back to complete functionality?
• Business impact analysis?
• What would be the stages of business recovery?
• What systems do you think need to be recovered first?

6. Moodle Security PROOF OF CONCEPT

6.1 Description of the proof of concept

Based on the hardware and software you opted to use (either cloud computing, VirtualBox / VMware hypervisor, or small home Internet), give a brief description of the nature of the proof of concept and network infrastructure you want to demonstrate.

6.2 Moodle installation, configuration, physical network diagram

6.2.1 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 applications according to the recommendations given by the Moodle site. The Moodle site contains many community resources and tutorials showing you how to do that.

Give evidence of your installation and configuration by illustrating with screenshots and describing briefly the tasks conducted.

Note that this will be verified during the DEMO of your system in week 12.

6.2.2 PoC physical network diagram

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. You may use figure 2 in the case study as a reference to draw your diagram.

6.3 Moodle Hardening

6.3.1 Moodle hardening practices

You should demonstrate and give evidence of the ten (10) system administration good practices you implemented to make the Moodle system more solid and secure. This can be done by listing each practice, explaining how it was practically implemented in the system, and including a screenshot.

For example, let’s assume that one of the practices you decide to implement in Moodle is blacklisting. To that end, you build a domain blacklist by adding IP addresses that you wish to block. The outcome is that any IP address that is in the list is blocked. You may document this example as follows:

Good Practice # 1: Blacklisting

Description of the practice

This practice was implemented by building in the Moodle system a list of IP addresses to block. After logging in as admin, we navigated to Site administration>Security>IP blocker to access the settings. Then, following the instructions in the settings, we entered the list of IP addresses to block and saved the changes.

Screenshots

Note that this will be verified during the DEMO of your system in week 12.

6.3.2 Moodle hardening – OWASP

In hardening the Moodle system, you are also required to explain how your Moodle security implementation protects against each of the security risks listed and compiled by OWASP top 10 (Ten Most Critical Web Application Security Risks). Basically, provide a table witht the OWASP top 10 in a column, description of the security risk, and your mitigation strategy in another column. The following table illustrates an example (SQL injection) of how to document this section. You may use this table as a reference [do not forget to delete the example entry].

6.4 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:

• Test title
• Short description of the test (what was the test about)
• The test activity (how the test was conducted)
• The desired outcome (expected result)
• The observed outcome (what you found)
• A screen shot of the test

7. REFERENCES

List your references in accordance with CQUuniversity referencing guidelines.

Use this section to report any project-related supplementary materials.