Project Peer Review is given to other Project Sample 2021 CQU

<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-4462760071454301"
     crossorigin="anonymous"></script>

Quality Review

Project Title

Group Number:       Group–100

Unit:                       <COIT20265>

Student 1:               Students

Student 2:               Student2

Project Mentor:      Mentor

Date:                      today date

CQUniversity Australia

1         Overview

1.1         Which group did you review?

Group 1 and Cyber Security Solution for Health Provider

1.2         Which artefacts did you review?

  • Project Plan
  • Draft Presentation
  • QHC Technical Security Controls
  • Health Centre Network Design

1.3         Project Summary

Group1’s project is to design a cyber security solution for a medium-sized healthcare provider called Queensland health clinic [QHC]. Some of the assumptions of the project are as follows

  • 5 primary locations across Queensland including Rockhampton (Head Office), Gladstone, Bundaberg, Townsville and Cairns
  • Each site has 20 staff.
  • Staff can increase in numbers in the future
  • QHC has a small branch in Gracemere to assist in the covid19 testing.
  • QHC provides consultations for patients first-level medical concerns.

The aim of this project is to develop a solution in the cyber security space to mitigate threats and assist QHC in its expansion over the next 5 to 10 years. In this project, Group1 will represent itself as CQ Security Solutions (CSS).

To complete the requirements of the project the CSS team will design a network diagram and identify the building layout and perform an asset register. They will also write security policies in cyberspace to maintain confidentiality, integrity, and availability of the system. In addition to the above, they will create training plans for their users and write testing policies with tools to conduct vulnerability and penetration testing.

In addition, the CSS team will run a proof of concept by creating a sample website and hosting it in the Azure cloud in a VM server. They will implement a point-to-site VPN system with security controls such as endpoint protection and place it behind a firewall.

The plan of the team is to mimic a remote desktop VPN access model to access their QHC internal websites as well.

2         Technical Artefact 1 Review

2.1         Technical Artefact Title

QHC Technical Security Controls

2.2         Technical Artefact Summary

The purpose of this technical artifact is to provide security controls that should be in place for the QHC network to achieve its cyber security visions. In this document, solutions have been reviewed and compared before selecting the required solutions for QHC. This document does not consider 3rd party involvement.

CSS has identified that the following solution is required at a preliminary level. They are as follows

  • Endpoint protection to reduce vulnerability and increase visibility of users accessing the network. This is also to ensure that attacks such as ransomware do not happen.
  • Email filter to prevent data leaks, ransomware, Phishing and Scam attacks
  • Web proxy to separate the access from internal and external networks. This will also ensure that unauthorised access is denied.
  • Patching tools to update vulnerable operating systems and software to reduce security breaches.
  • Vulnerability scanners to identify and prevent exposures
  • Virtual desktop infrastructure [VDI] to reduce risks of unauthorized access
  • VPN to reduce possibility if attack and enforce two factor authentication
  • Firewall to effectively enforce security policies
  • Intruder detection and prevention systems to enhance the monitoring of network traffic and to identify outliers and
  • Anti-malware software to provide another layer of security
  • Harden the system with a standard OS image with standard configurations
  • New deployment requirements to change default passwords.
  • Tracking of software versions used
  • Naming every device uniquely to identify threat origin
  • Backup setup to ensure business continuity and disaster recovery
  • Network segmentation to overcome migration of error or security issue from one segment to another.
  • Access control to provide proper access to specific to the user.

The security control recommendations are as follows

  • To use a Citrix workspace to action on the VDI setup.
  • Use a SCCM tool to conduct patching operations
  • Use a M365 endpoint defender to provide endpoint protection
  • Use M365 cloud app security to reduce risks, use only secure and approved apps, protect data
  • Use M365 enterprise online protection for handling email security and filtering
  • Microsoft defender for identity details in AD
  • Cisco firewall in the on premises to ensure access control enforcement, create virtual firewalls, have traffic visibility
  • Zscaler Secure Web Gateway to implement a web proxy that considers zero trust architecture, SAML based SSO, application peering and log collection.
  • Tenable.io as a vulnerability scanner with the capability such as container security, asset tracking, etc.

2.3         Strengths

  • The purpose of the artifact is very clear. It summarizes the concepts and attempts to compare the various solutions before fixing on the policies.
  • Most of the contents of the artifact are specific to the project and are in very good depth. The controls assigned to each subsection of the considered areas are extensive.
  • The artifact uses existing and proven technologies such as M365, Cisco firewall, Citrix workspace and doesn’t reinvent the wheel.
  • There is sufficient technical depth to see the target goals envisioned through these tactics that are employed in the artifact.
  • The artifact is very professional considering multiple areas of concern such as comparisons, establishing the required keywords, and formatting.
  • The structuring of the artifact is very clear with suitable sections and sub-sections.
  • There very minimal spelling mistakes in the document and sentence formation and grammar are appropriately used.
  • The formatting in the document is very accurate and consistent.

2.4         Weaknesses

  • There are many technologies mentioned in the artifact, but their integration issues have not been considered.
  • Many technologies and their benefits are mentioned that is not relevant to the project scope. Example – Container security is not required in this scenario as the goal is VDI setup and not microservices. While it can be re-purposed for OS images, it is not a feasible solution.
  • Antivirus solutions such as windows defender is not the correct security for identity protection in the AD.  There is some inconsistency in the chosen technology for the tasks. Multiple technology performs similar activities and having too much overhead will decrease the performance of the solution.
  • 3rd party applications and their impact is not considered from a security perspective. This will be a problem as there is no infrastructure that doesn’t consider the usage of 3rd party apps and tools.
  • Some statements such as 2FA in VPN is not explained as to how it can be integrated. While it is possible to do so, VPN tunnelling by itself provides good security layer but not MFA. The gap here is not covered in detail and causes confusion to the readers.
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-4462760071454301"
     crossorigin="anonymous"></script>

2.5         Recommendations

  • Intruder detection and prevention systems have been provided as a requirement but there can be other details that can be added. Such as what type of requirement it is, because IDS/IPS by itself is such a huge space. If the requirement is not payload inspection, then using azure firewall by itself with a threat intelligence enabled will satisfy the requirement. There is no need for an external IDS/IPS system in this use case. But if payload inspection is required, the team needs to select a specific 3rd party product from the marketplace and perform compatibility and comparisons and select the suitable solution. [https://docs.microsoft.com/en-us/security/benchmark/azure/security-control-network-security]
  • While it may not be feasible in the given timeframe to consider 3rd party workflows in this artifact, points of failure happen in the real-world organisational network through integrations that are not secure. This policy should provide a integration checklist for the 3rd party integrations and how known issues can be mitigated with certain security controls. Example of these could be vendor risk management, integration, and testing in a sandbox environment.
  • 2FA in VPN as a requirement is wrong. MFA needs to be implemented as a separate security layer. It’s not a reason to implement VPN tunnels. VPN tunnels are implemented to encrypt the data at transport and hiding the IP address of the source and client by bouncing their details through a secure server chain.

3         Technical Artefact 2 Review

3.1         Technical Artefact Title

Health Centre Network Design

3.2         Technical Artefact Summary

The goal of this technical artifact is to provide a network design for the QHC to support its growth in the next 5 to 10 years. The scope of this artifact is to provide a high/low fidelity network design and show the various standards that will be used and how the devices will be labeled along with their recommendations.

As the assumption of the project includes 5 sites, the Ip addressing will have 5 IP subnets with each IP subnet using its x.x.x.1 IP for the default subnet. For each area, the design has been selected to use 10. x.y.z where x will be the region number. The artifact represents /8 subnets for the region itself while using a /24 subnet for the default gateway.

The on-premises IP addressing has been split into various VNET to segment the network and avoid threat or error migrations. A total of 6 assets are identified and provided with their /16 IP subnets and the host IP range. As the number of users identified per region is 20 at this point, the artifact represents the IP range from x.y.z.100/24 to x.y.z.254/24. Its future-proofed.

The high-level network design represents the various segments of the network using the VLANs and their associated end-user computing devices connected together by switches and wireless devices. This also includes the connections between the main router and the firewall protecting them from threats from the internet. The VPN network design diagram expands the high levels design based on the various locations in the building with edge switches and specific rooms and their requirements. The diagram includes the assigned Ip addresses and the name of the devices that will be stored in the active directory of the network. The cloud design of the network includes a gateway subnet and firewall subnet with servers and a network security rules group tied together by a network interface.

The artifact proposes the use of Cat6A cables in the on-premises with Telstra NBN and Optus 4G as the ISP providers. Cat6a has been selected to mitigate cross-talk and multiple ISP has been selected for business continuity purposes. The artifact provides device recommendations for each of the identified assets such as Cisco IP Phone 7861 for VOIP phone, etc.

The artifact provides 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 Rockhampton’s site will be R-PC-VLAN10-0001.        

3.3         Strengths

  • The purpose of the artefact is clear. The scope is well defined.
  • The artifact is very specific to the project as it considers the naming convention, IP addressing, device recommendations as per the case study and their assumptions.
  • Some best practices such as dual ISP providers to ensure business continuity has been used in this artifact.
  • Justifications for the design are very clear and explained well in the high-fidelity design and other sections and brought well together in the low fidelity design.
  • The network diagram is very clear, and the network segmentation is excellent.
  • The artifact is very professional
  • The structuring of the artifact is very clear with suitable sections and sub-sections.
  • There very minimal spelling mistakes in the document and sentence formation and grammar are appropriately used.
  • The formatting in the document is very accurate and consistent.

3.4         Weaknesses

  • Physical AP diagram is missing, and low-fidelity diagram is drawn without the same. That section can be mentioned through textual message as assumptions as the details are already integrated in the low-fidelity design.
  • There is enough technical depth to the parts explained in the design, but missing sections such as standards and policies in the artifact make the readers miss out on information. Many hardware devices have been selected but their reason for selecting them could be explained with assumptions.
  • The cloud side network design is not very clear and needs explanations.
  • Protocols, standards, client settings missing.

3.5         Recommendations

  • How does the cloud side and on-premises connect with each other is missing. Does it use site to site connection od MPLS connection? Try to explore express route connections as it’s the best way to customize security levels with multiple protocols and will only require a customer gateway in the on-premises to connect with the cloud network. Site to site connections is possible in this method securely.
  • Where the identity stored is missing? You need to have a domain controller in the on-premises to store the identity. This should be migrated to the azure cloud AD for back up using a azure active directory connect server. Each site should have a domain controller and should sync with each other using a forest. This will make sure that every identity and computer devices in the network are documented correctly. Naming details are stored in the active directory and if using only a cloud only AD it should be mentioned. 

4         Project Review

Consider all the technical artefacts reviewed, as well as the Project Plan and Draft Presentation. Compare what this group has done so far compared to what your group has done so far.

4.1         Evaluation

Give a rating for each item by placing a X in the appropriate box.

 Much better than our groupSlightly better than our groupAbout same as our groupWorse than our group
Quality X  
Depth and detailsX   
Presentation  X 

4.2         Reflection: How do you recommend your group improves?

Based on what you have seen from another group, explain what you can do differently in your project to improve.

  • We can improve our security policies document to consider a variety of areas. We have only considered DDOS protection and OWASP top 10 vulnerabilities. We can improve this document by including endpoint protection systems. Alongside these, we can also write critical settings that can be enabled or scripted to improve the documentation. Example we suggested Azure DDOS protection for the cloud security component, but we haven’t written about on-premises security except for firewall, data transport between on-prem and the cloud. We will have to improve the security concepts from OS patch updates to 3rd party integrations.
  • In our documents we did not explain the reasons for various tools and design decisions. We can improve on this aspect of the documentation. In our network design document, we have recommended many selections for on-premises devices, but we can improve them by adding statements like this. MS390-48 Cisco Meraki as a switch is recommended because it provides a web-based dashboard that can be used to create secure, scalable, and easy to deploy networks. It also has a mobile app that can be used to do the same. A technician doesn’t need to be in the office to troubleshoot and configure the product during periods such as covid19. It is by considering these aspects that we have selected Cisco Meraki product for the switch. In addition to this, we can also compare our selection with other competitor brands to explain the choice.

 [Note]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.

 The length of your review depends partly on the length of the technical artifact. Most technical artifact reviews will be about 1 or 2 pages of text. If a technical artifact is short (e.g. a 2-page policy) then the review may be short (about 1 page). If a technical artifact 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.

 [Note]The number and depth of recommendations will be dependent on the quality of the technical artifact.

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 artifact, 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 artifact, 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.

 [Note]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 recommendations on how that group can improve.