Quality Review

1         Overview

1.1        Which group did you review?

Group 8 and School Network Design.

1.2        Which artefacts did you review?

• Project Plan
• Draft Presentation
• Technical artefact 1: Logical Network Design
• Technical artefact 2: School Network Design

1.3        Project Summary

The project is to create a network design for the new state special school Coomera that is secure, reliable, robust and scalable. This project will include a proof of concept in the cloud along with logical and physical network design diagrams for the on-premises with risk assessment and security polices for both cloud and on-premises. The stakeholders of the project are the teachers, students, Queensland government, school staff, and other users such as parents, visitors. The scope of the project is limited to cover only the prototype and not the entire network.

Group 8 uses the AWS cloud environment to hire resources such as server EC2 instance with Ubuntu OS, a MySQL database. The plan is to install and integrate a Forma Learning Management System and EMBY Media Server for the implementation of Proof of Concept (PoC). In addition, the project involves integrating a video conferencing functionality within the LMS to ensure it is suitable for schools in the Covid19 period.

The project includes roles such as cloud infrastructure specialist, risk assessment specialist, network operations specialist, vulnerability and penetration tester, security policy developer, team leader, and project manager.

2         Technical Artefact 1 Review[SG2] 

2.1        Technical Artefact Title

Logical Network Design

2.2        Technical Artefact Summary

The logical network design diagram includes the physical design of the school architecture with the following rooms: –

• Principal cabin
• Staff room
• Admin room
• Student lab
• Conference room
• School server room

All the assets such as workstation, laptop, VOIP phones are connected to the main router via layer 2 and 3 switches. The layer 2 switches have the connection to the wireless router. The assets in the staff room, admin room, student labs, conference room are connected via a layer 3 switch. The server room is directly connected to a secondary router. Both the routers are separated from the ISP services through a firewall. There are 2 ISP providers shown in the diagram.

2.3        Strengths

• The purpose of the artifact is clear, it is clear that it fits into the concept of the project.
• The artifact is specific to the project as it has physical rooms allocation based on the school assumptions.
• It appears professional as not an overcrowded design

2.4        Weaknesses

• There are technical errors in the design such as unnecessary links in the network design. Such as the usage of a layer 2 and 3 switch.
• More technical error as servers in the on-premises are connected to the internet directly and there is no connection with the intranet of the organization.
• The document is missing IP addressing at level 3 switch layer and physical naming convention for each asset in the diagram.
• This work does not have sufficient technical depth and could have been easily completed in few hours.
• Certain rooms like reception room are missing in the design.
• No network segmentation
• No subnets, names or labels
• No routing protocols

2.5        Recommendations[SG3] 

• Level 3 switches can be used directly without any level 2 switches as level 3 switches provide IP addressing routing table as an addon. It has more port density and high throughput with VLAN tagging for network segmentation. It also provides support for inter-VLAN communication. This also provides support for static routing and dynamic routing. VLAN routing is configurable and adds additional security.
• The server room should be connected to the main router that is linked to the other parts of the network. It should not be exposed only to the internet. In the design, we are losing the fast-paced access that is available in the intranet of the organisation.
• Every asset needs to be labelled with a naming convention in the diagram an example is provided. The naming convention based on the format X-YY-ZZZZZZ-NNNN where the X = Location – Y = Function – Z = VLAN – A= Device Number. An example of a desktop workstation in the Rockhampton’s site will be R-PC-VLAN10-0001.  This is an important step as all these assets will be registered using this name in the on-premises domain controller.
• IP subnetting is required for the logical network design. An example to do it will be the following way. WAN IP addressing is required to connect the various sites of the school. Since this school has only one site, we can use a allocation like 10.1.0.0/8 IP subnet with a /24 default gateway subnet. The LAN will be segregated in security zones using VLANs to ensure network using LAN IP Addressing Table.  An example is shown below.

LAN IP Addressing Table
Asset	VLAN	IP/Subnet	VLAN Gateway	Host IP Range
Asset1	VLAN 1	10.1.10.0/16	10.1.10.1/24	10.1.10.100/24 – 10.1.10.254/24

The LAN should be using private IP addressing with the /16 CIDR Prefix to allow for multiple VLANS. This will ensure future proofing for both LAN and WAN IP addressing.

• Routing protocol should be mentioned with regards to the connection between the on premises to the cloud applications. Does the solution require VPN tunnelling access should be checked? There are many options to connect to the cloud. Refer to MLPS connection. This makes sure as if the cloud components are a part of the on-prem itself through its secure and fast connection that will support multiple protocols.
• Wi-Fi broadcasting devices should be directly connected to the level 3 switches as we require IP routing tables in that scenario as well.

3         Technical Artefact 2 Review

3.1        Technical Artefact Title

School Network Design

3.2        Technical Artefact Summary

This artifact provides the following details: –

• Password policy
• Risk assessment
• Proof of concept implementation

The password policy includes details such as how the acceptable password can be formed and what are its guidelines for users. Some of the guidelines include: –

• Blocking simple words like 123456
• No direct personal information that can be guessed from their social media profiles like date of birth.
• It has to be a combination of letter, numbers, special characters.
• Cannot be a previously used password.

The risk assessment part starts with the asset identification where assets such as on-premises infrastructural components like computers, printers have been identified. In addition to the infrastructure components, informational and users have been identified. All the asset data has been classified based on data classification and its impact to profitability. The overall risk rating has been ranked.

The proof-of-concept set-up includes the EC2 instance creation, database creation, security policies using security groups, installation and starting of Apache web server, connecting to the database using the connection strings and installation of the forma LMS. In addition, the configuration of the forma LMS is included. Moreover, they have mentioned about brining the server behind a load balancer.

Finally, they have installed a Emby media server for sharing of files with a demo image of how it will look.

3.3        Strengths

• The artifact details are relevant to the project
• Best practices such as using a load balancer to divert traffic has been mentioned in the artifact
• There is good technical depth in the implementation part with relevant screenshots.it clearly shows they have spent more time on the PoC design and development.
• There are not many grammatical and spelling mistakes.
• The formatting followed is consistent.
• Has taken the data from the server into the database in a multitier architecture. Forma LMS instances does not persist any data.

3.4        Weaknesses

• The purpose of the artifact is not clear, there is no goal and scope. The document doesn’t appear professional due to this.
• There is no clear structuring in the document. 2.1 asset management concludes the entire risk assessment.
• There are some technical errors such as unnecessary details in password policy.
• There are no justifications provided as to why certain risk ratings were provided in the document
• The artifact contained too many things in the same document. They should have been in different artifacts.
• Asset register provided is very general and not specific to the project.
• No backup configured

3.5        Recommendations

• Asking users to not write password in computers and not share with other users should be a different policy. The policies can be split into password construction guidelines and not sharing details can be a part of acceptable use policy. Having both under password policy is confusing and ambiguous.
• The artifact should be split into 8 different artifacts. Namely
  • Password policy
  • Acceptable use policy
  • EC2 deployment and configuration
  • Forma LMS installation and configuration
  • Database design, deployment, and configuration
  • Emby installation and configuration
  • Load balancer deployment and configuration
  • Risk assessment

Having all of this information grouped together is very ambiguous and doesn’t help the reader. Knowledge documents will have to be very specific to the task it is intended to accomplish.

• Risk assessment is incomplete. You need to perform the following steps on top of asset management and risk ranking. Risk ranking also requires reasoning.
  • Identify and rank assets
  • Identify threats
  • Identify vulnerabilities
  • Analyse the existing controls
  • Determine likelihood
  • Assess the impact
  • Recommend new controls
  • Document the results

Without all the details in this process it will be insufficient information to base any security or organisational policies and mitigation strategies. See the attached table template with an example to assist you.

Threat	Vulnerability	Asset	Impact	Likelihood	Control recommendations
System/ server failure – overheating	Old hardware devices poorly allocated	Servers on-prem	Business suspended and can lead to fire	H	Regular monthly check-ups of hardware and installation of certain assessment software’s to keep track of hardware health.

• In asset register, please make a note of all the applications you will use as well. Example forma LMS. Reason, it’s a web application hosted in the cloud. That means, it has vulnerabilities as identifies by OWASP top 10. You can write vulnerability tests to overcome them in different part of your project based on this.
• A suggestion would be create the identities of the user in a windows active directory and use those details to enforce single sign on capabilities to both the forma LMS server and Emby server. That will make it more consistent. Emby server will also need redundancy and data in the Emby server can be taken out to a storage account to ensure that it doesn’t persist any data as well.
• You can configure daily or weekly backups in the EC2 instance settings. This will help in case of disaster recovery. In addition, since the servers are not persisting any data, a template of the server can be saved in the EC2 container registry in amazon to immediately deploy a new instance. while the usage of 2 instances to show reliability and load balancing is good for the PoC, the solution must have auto scalable features. Refer to the image below.

Figure 1: source – amazon documentation

4         Project Review

4.1        Evaluation

	Much better than our group	Slightly better than our group	About same as our group	Worse than our group
Quality				x
Depth and details				x
Presentation				x

4.2        Reflection: How do you recommend your group improves?[SG4] 

Not Applicable

---

 [SG1]This template contains sample or explanation text inside <angle brackets>. You should fill in with the correct information or delete the explanation text when not relevant. For example, you would replace <Project Title> with the title of your project (and delete the <angle brackets>). This is NOT the title of the project under review.

This template also includes examples. You must delete the examples before submitting your report.  When tables are used, add/delete any rows where necessary.

 [SG2]The length of your review depends partly on the length of the technical artefact. Most technical artefact reviews will be about 1 or 2 pages of text. If a technical artefact is short (e.g. a 2 page policy) then the review may be short (about 1 page). If a technical artefact is long (e.g. a 30 page design document) then the review may be long (about 2 or 3 pages). Reviews will be longer if you include diagrams or screenshots.

 [SG3]The number and depth of recommendations will be dependant on the quality of the technical artefact.

In all cases, some recommendations are expected.

In cases when you have identified a lot of strengths (but not many weaknesses), i.e. you think it is a great technical artefact, then there may not be many recommendations. But there should be many project reflections at the end of the review.

In cases when you have identified a lot of weaknesses (but not many strengths), i.e. you think it is not a good technical artefact, then there should be many recommendations and they should have depth. However, there may not be so many project reflections at the end of the review.

 [SG4]See the comment about Recommendations.

In summary, if you evaluate the group to be better than yours, then we expect detailed reflections of how you can improve. But if you evaluate the group worse than yours, then we expected detailed recommendation on how that group can improve.