代写CSC8208、Java/c++编程语言代做
- 首页 >> Java编程 CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
CSC8208: Module Handbook
March 1, 2024
1 Introduction
Welcome to CSC8208: Research Methods and Group Project in Security and Resilience! In this module, you
will work as a team to research, design, implement, and evaluate a software system within the context of a
security-related topic. This handbook aims to establish the expectations, module structure, assessment and
marking criteria, and the way in which teams will be chosen and monitored during the course of this module.
In this module, you will gain experience with reading and understanding research papers within the field of
cyber security. In the last 25 years, 3015 papers have been published in the top four security-research conferences. New security knowledge is often first published in scientific papers; the skill for reading, assimilating,
and communicating new knowledge is a crucial one in the long term.
You will work largely independently as a team using your own initiative with minimal supervision. This
is similar to the way in which your individual project (dissertation) supervisor will likely operate. Lectures
are delivered to support the development of your group projects, covering material on reading and writing
papers, evaluation methods, and more. On CSC8208, all course materials and discussions will be hosted and
conducted respectively on Canvas for later reference.
The following academic staff will deliver CSC8208 this academic year:
2 Module Calendar
During this module, you will go through a series of lectures to help you learn best practices in reading and
presenting research, and writing a report on your findings. You will be organised into groups of approximately
eight members per team. You will then briefly read all papers towards the Assessment 1: Literature Review,
Threat Model & Security Policy. Assessment 1 involves concisely summarising a subset of these research
papers, which should assist you in the final report.
The rest of the module is dedicated for the collaborative Group Project as outlined in Assessment 2: Project
Report. Your project must also be demonstrated. Students are expected to start working on a comprehensive
project that is meticulously executed and documented in a report.
2.1 Lectures
The lectures are scheduled to be delivered in the following order:
1. Module introduction. 10:30–11:30, Monday 12th February 2024.
2. Project briefing. 11:30–12:30, Thursday 15th February 2024.
3. Establishing a common vocabulary on security and resilience. 10:30–11:30, Monday 19th February 2024.
4. Implementation guidance. 11:30–12:30, Thursday 22nd February 2024.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 1
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
5. How to read a research paper. 10:30–11:30, Monday 26th February 2024.
6. Writing and presenting a project. 11:30–12:30, Thursday 29th February 2024.
7. How to evaluate a project (Part 1). 10:30–11:30, Monday 4th March 2024.
8. How to evaluate a project (Part 2). 11:30–12:30, Thursday 7th March 2024.
Location: FDC.G.06.
2.2 Tutorial Sessions
Several tutorial sessions are scheduled in your timetable. It is expected that one member per team, at an
absolute minimum, will attend in order to provide a update on the team’s progress at each session. Team
mechanics are described in greater detail in §4. These sessions take place on:
1. 26th February 2024.
2. 4th March 2024.
3. 11th March 2024 (For the formative assessment of teams 1–11).
4. 18th March 2024 (For the formative assessment of teams 12–22).
Location: USB 1.006 at 13:30–14:30.
2.3 Assessment Deadlines
The following assessments are set, along with their respective weightings:
1. Literature Review, Threat Model and Security Policy (30%): This assessment broken down into:
(a) 20%: Summarise three research papers from the repository provided on Canvas. These focus on
different research directions, such as system security, malware, and Internet of Things security. Each
summary should be ∼1,000 words.
(b) 5%: Submit a threat model that you will address specifically in your secure chat project. This includes a concise description of the attackers and attack methods with appropriate justification.
(c) 5%: Submit a security policy comprising a concise set of rules (bullet points) which can serve as the
security requirements that, if met, will successfully protect against the attackers in the threat model.
Your submission must have a maximum length of 5 pages in total using the IEEE Computer Society
double-column conference template. Markers will be under no obligation to mark beyond this: you
may miss out on marks if you exceed this limit.
• Due date: 4th March 2024.
• Submission type: PDF.
2. Presentation (Optional/Formative): A verbal presentation in an elevator pitch style of your developed
project. This should be delivered in person on 11th March 2024 (Teams 1–11) and 18th March 2024
(Teams 12–22). It should be 5 minutes in duration. There is no formal marking scheme.
3. Final Group Report (70%): Presents your developed solution to the project brief. Your report must be
max. 10 pages, again using the IEEE template. Markers will be under no obligation to mark beyond this.
You must also submit a video file that demonstrates a working project.
• Due date: 22nd March 2024.
• Submission type. a PDF (report) and ZIP file containing your software artefact AND a video
demonstration of your project (e.g. MPEG4).
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 2
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
All assessments are group-based. Marks are distributed to individuals using the formula described later in
§4.3. Within each assessment, we expect that students submit their contribution percentages within an
appendix chapter.
NESS must be used for submitting your assessments.
3 Project Brief: A Secure Chat System
Secure communication is a major concern for personal and professional use, with numerous solutions having
emerged over the years. The current wave of secure chat clients dates as far back as 2004 with the development
of the Off-the-record (OTR) messaging protocol [1], which supports secure instant messaging with message
encryption, authentication, and forward secrecy. Signal, Theema, Telegram, and WhatsApp represent some of
the most widely used secure messaging solutions in today’s marketplace.
In this project, you are tasked to design, implement, and evaluate a chat system that provides one-to-one
or group-based communication. Your system must allow at least two communicating entities to send and
transmit messages over a secure channel to each other. You have two overarching tasks to complete, which are
described in the following subsections.
3.1 Task 1: Literature Review, Threat Model, and Security Policy
You will begin with a literature survey by selecting and reviewing any three research papers from a predetermined list of scholarly articles provided by the staff. You should briefly read all papers before selecting
and reviewing three papers that you deem most interesting and appropriate from which to develop your final
project (Task 2). Be mindful of a literature review’s purpose: it is not a list of papers described uncritically.
This is the first part of the assessment.
In the second part of the assessment, a threat model and security policy will be devised, pertaining specifically
to your project. The definition of a “secure” chat system is left purposely vague for you to define. Therefore,
you are required to submit a threat model and a security policy aligned with your chosen theme and research
papers. The threat model will concisely state the potential threats and the attacker capabilities that your project
will address. This should be a brief (0.5 page) description. You must also present a basic security policy. This
will be presented as a concise set of rules, i.e. bullet points, which can serve as the security requirements that
if met, will successfully protect against attackers (1 page).
Your group-based paper reviews, threat model, and security policy attracts 30% of the overall module mark.
A breakdown of the marking criteria is given in §5.
3.2 Task 2: Build and Write-up Your System
The design, implementation, and evaluation of your own secure chat system is the main task in this module.
Your system is described in the final report, which must be written in the style of a scientific paper, attracting
70% of the module mark. Broadly, your report should include introducing the problem, providing a related
work section, discussing your design and implementation decisions, how you evaluated your system, and
conclusions with directions for future research. In the report, you will primarily be assessed with respect to
three dimensions: 1 security, 2 resilience, and 3 innovation. The strength of your project’s introduction,
evaluation, and presentation are also assessed.
3.2.1 Dimension 1: Security
This dimension assesses how your system addresses a reasonable threat model and security policy.1 The quality
of the mitigations is of paramount importance. Good projects are expected to use mitigations that follow
current best practices and use existing libraries (e.g. see “don’t roll your own crypto” in §6).
1Your threat model and security policy may be refined from the first assessment for your final project report.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 3
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
For the avoidance of ambiguity, we expect the following to be satisfied as minimum ‘must have’ requirements in
order to achieve a basic pass:
• Confidentiality: Ensure that any transmitted messages between clients cannot be trivially read over a
network medium.
• Integrity/authenticity: Ensure that trivial changes to any transmitted messages can be detected. For
example, if A sends “Let’s meet at 9am tomorrow” to B, then a third party, C, should not be able to change
this to “Let’s meet at 10pm tomorrow” without it being detected.
• User authentication: How will you ensure that only a given user can log into their account? For example,
through the implementation of secret-based methods, e.g. requiring passwords or biometrics to log in.
Beyond this, higher-scoring projects should convincingly provide additional features. As a general guideline, a merit-level project should implement one of the following; a distinction-level project would implement
more than one of:
1. Secure file transfer: In addition to simple messages (strings), can you enable the secure transmission of
files, e.g. PDFs and images, between clients in an efficient way?
2. Message self-destruction/deletion: Can you enable users to delete messages in a way that leaves no trace
of them on their device, server etc.? This could be time-based, e.g. similar to WhatsApp’s time-limited
messages, or on demand from the user.
3. Secure persistent message storage: How could you ensure that messages are stored securely at rest?
This could applied to the user’s device or the chat server.
4. Biometrics: To enhance usability, could you enable users to log in to their accounts using their fingerprint, or facial image etc.?
3.2.2 Dimension 2: Resilience
Implementing resilience into any chat system requires various considerations to ensure reliability and robustness. As a minimum requirement to achieve a pass in this dimension, your project should allow more than
one communication session at a time. Beyond this, it is expected that you explore a wider range of techniques
to protect against unintended faults. A good (merit-level and above) project should implement at least one of
the following aspects:
1. Redundancy and failover: Can you use multiple servers/instances to ensure that, if one server/instance
fails, another can take it over seamlessly?
2. Data backup, replication, and recovery: Does your project regularly backup data and have a recovery
plan in place? The goal would be to quickly restore your service in the event of a major system failure.
3. System monitoring. You may implement substantial alerting mechanisms, for example, to help identify
and remedy faults and other issues as they arise.
4. Scalability. How will your system handle large amounts of traffic, which may hinder the delivery of
legitimate messages (among other problems)? Design mechanisms that gracefully handle this increased
load.
To be clear, implementing a comprehensive range of resilience techniques, commensurate with a productiongrade system, is not necessary in this module. See the marking criteria in §5 for additional guidance.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 4
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
3.2.3 Dimension 3: Innovation
This final component assesses the innovation of your project; that is, how it provides new features, or addresses
new requirements, in a way that goes beyond existing secure chat systems.
Some ideas for novelty include:
1. Privacy-enhancing technologies: To what extent can differential privacy, private contact discovery, or
data obfuscation be applied in a novel way?
2. How could machine learning be integrated in your solution in a new way? For example, for detecting
fake/malicious clients or unauthorised users of devices in real-time (continuous user authentication)?
3. Information hiding: How can steganography be incorporated in a new way to covertly transmit secrets
in the presence of adversaries who may have access to messages?
4. Blockchain: To what extent could blockchain be used in a secure messaging system?
You may also express your innovation through the project’s engineering with clearly justified benefits. For
example, you may utilise a new network or system architecture (e.g. supporting decentralisation); using an
interesting network medium over which to communicate messages; using readily available hardware security
technologies to protect encryption keys; and more. This should be convincingly justified in your report.
3.3 Module Flowchart
To help your understanding of CSC8208’s structure, we illustrate the different stages and times in Figure 1.
4 Team Mechanics
To be successful in this module, it is critical to learn to work effectively within a team of people whom you
may not know. This is to replicate a real-world environment: just like the workplace, you may have never
worked with, or have even met, your teammates before this module. To this end, you will be stratified into
groups of approximately eight members each, comprising members from different M.Sc. programmes within
the School of Computing. Please note that the staff will allocate the teams; students will not be able to form
teams themselves. Changing teams is also prohibited unless there are exceptional circumstances with the
approval of the module leadership. This is to ensure diversity and consistency across teams.
4.1 Team Leader
Once you have been allocated to teams, it is imperative that you make contact as a collective as soon as possible.
Each team must nominate a leader whose responsibilities include:
• Arranging and leading group meetings. Includes physical/virtual meetings, setting agendas and delegation. It is important to re-emphasise that module staff are not responsible for arranging your team
meetings, nor can they expected to attend them.
• Submitting group assessments. To ensure consistency, each team leader shall submit assignments on
behalf of the group (literature review, presentation, and final group report).
• Planning the team’s activities. A concrete plan is an important component in ensuring that assessments
are submitted on time, with sufficient contingency measures, and that tasks will be delegated fairly
We expect each group to have nominated a leader and held their first meeting(s) by the end of the first teaching
week. A deputy leader is also required, who will assume the responsibilities of the team leader in a back-up
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 5
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
Lectures
Group Allocation
Reading Papers
Project Theme Selection
Three Paper Reviews
Threat Model
Security Policy
Assessment 1 Submission
High & Low Level Design
Coding & Implementation
Testing & Evaluation
Assessment 2 Submission
Weeks 1 to 4
Week 1
Weeks 2-3
Weeks 3-4
4th March
Weeks 4-6
22nd March
Weeks 1-4
Weeks 4-6
Figure 1: Indicative module flowchart.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 6
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
capacity. The names of team leaders and deputy leaders should be submitted in your Microsoft Teams channel
by Week 2.
Submit progress update each week covering minutes of the team meeting and any concerns.
4.2 Project Supervision
As mentioned in Section 1, teams are expected to work independently with minimal supervision, similar to
the way in which your individual project (dissertation) supervisor may operate. However, you are not alone:
problems sometimes arise that prevent teams from functioning as expected. There are several ways in which
such issues can and should be raised. Firstly, it is critical that you make the most of the aforementioned tutorial
sessions. Please do not hesitate in raising queries/issues with the module staff during the scheduled tutorial
sessions. Within the short duration of the module, unresolved issues can quickly spiral into ones that affect
your grades. The Canvas discussion board functionality also serves as an appropriate forum for raising issues.
Lastly, if all other avenues of communication have failed, the module staff can be contacted via email.
4.3 Individual Contribution Formula
It is important in team-based modules to ensure that each member’s contributions are fairly reflected in the
overall marks. This must be done in a way that incentivises teamwork and collaboration, avoiding situations
in which one or two people do all of the work. This module uses the following guidance, which has been used
in previous years on CSC8208 and its sister module, CSC8113: “Group contributions should be agreed among the
group, and should be fair and truthful. They should sum to 100% and must be included in the group report.”
In other words, if a group has eight members, then an ‘ideal’ allocation is 12.5% per person to indicate that
everyone has contributed equally. However, it need not be ideal due to the different levels of engagement
between team members. A possible distribution could be 15%, 15%, 15%, 15%, 15%, 10%, 5%, and 10%.
In your decision-making process, please consider the significance of individual contributions. If the final
project report carries a weight of 70% of the overall module marks, and a group mark is given as 80/100, then
the report will carry 56/70 (= 70 × 0.8) towards the group’s mark.
Given eight members in a group, there are (56 × 8) = 448 marks to be distributed. Let us also assume each
member is named as A, B, C etc. Given an example of A = 15%, B = 15%, C = 15%, D = 15%, E = 15%,
F = 10%, G = 5%, and H = 10%, then the following allocation will be made for individual grades:
• A, B, C, D, and E will receive 15% of 448 = 67.2/70 = 96%.
• F and H receive 10% of 448 = 44.8/70 = 64%.
• G receives 5% of 448 = 22.4/70 = 32%.
Therefore, G will receive a failing grade for this assessment.
Considering that 100% is the maximum that a student can achieve, this methodology has some significant
consequences. Let’s assume the same situation in which the group has received 56/70 for their final report:
• Assume that four members, A, B, C and D, do all of the work, and their contributions are 25% each with
all other team members having zero contribution. In this scenario, A . . . D will thus receive 0.25 × 448 =
112/70 = 160%, while E . . . H will receive 0%. Because the assessment is ‘capped’ at 100% per individual,
A . . . D will receive 100% in practice; the additional amounts over 100% are lost.
• Freeloading on others’ contributions is penalised. Assume A . . . G contribute 14% each, while H contributes 2%. H will receive a failing grade in their individual mark (0.02 × 448 = 8.96/70 = 12.8%) while
A . . . G receive 0.14 × 448 = 62.72/70 = 89.6%.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 7
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
5 Marking Criteria
5.1 Literature Review, Threat Model, and Security Policy
This assessment aims to develop critical analysis and understanding of key research papers within the realm
of security, specifically focusing on subject areas such as privacy, performance, networking and blockchain.
Students are tasked with reviewing any three research papers from a pre-determined list of scholarly articles
provided by the module staff.
Along with the research paper reviews, students are required to submit a threat model and a security policy aligned with their chosen theme and research papers. The security policy should encompass preventive
measures, detection strategies and measures to maintain the security properties outlined in the threat model.
The mark scheme for this assessment is given in Table 1 at the end of this document.
5.2 Final Project Report
The final project report attracts the biggest percentage of any assessment (70%). It should describe your solution in the style of a scientific paper (IEEE Computer Society double-column journal or conference style). This
should give you a feel for how ‘real’ papers in computer science are composed. The template can be found
online or on Canvas.
The precise section headings are left for you to decide. However, in general, we expect that a good report
would comprise the following:
• The project’s aim, rationale and objectives, and a brief background of the research problem(s) that you
are solving.
• A literature review in the form of a ‘Related Work’ section written specifically on secure chat systems.
• How your system design and implementation addresses each of the three aforementioned dimensions:
1 security, 2 resilience, and 3 research novelty, as described in §3.2.
• How you evaluated your project.
• Your conclusion(s) and any directions for future research.
To guide the development of your project, the final report will be marked using the criteria in Table 2 at the
end of this document. This should set out the expectations for receiving the different grades. Good luck!
6 Helpful Advice
Some common issues have arisen in the past that have limited the success of teams’ assessments in this module.
These issues are described below in order to help you avoid them:
• Structure and focus your team appropriately. It makes little sense for every team member to be on
programming duties with nobody, for example, working on security engineering or research novelty. It
is generally a sound strategy is to focus efforts evenly, structuring the team to meet all elements of the
marking criteria. For example, you may wish to assign a resilience ‘lead’ to to one team member, security
to another, and so on. This will help balance your team while leveraging the strengths of each member.
• ‘Don’t roll your own crypto’. During the design and implementation of your project, it is important to
use established, rigorously tested security algorithms. Implementing protocols, or worse, cryptographic
algorithms from first principles is not necessary to be successful in this module. Always opt for an
existing libraries and protocol implementations over ones you build yourselves.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 8
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
• Make use of communication and collaboration tools. Working effectively in a team is essential to succeeding in this module. It is strongly advised to arrange frequent in-person or virtual meetings to help
make key decisions, delegate tasks etc. You may also wish to use Microsoft Teams, Slack, Discord, or
another platform to help coordinate your activities online. Github and other Git implementations are
also useful in managing code bases that involve a number of contributors.
7 Supplemental Background Reading
This module accepts students from a wide range of backgrounds and programmes. Some team members may
have a limited understanding of security, while others, such as those on the M.Sc. Cyber Security programme,
may have a large degree of knowledge. However, other members will have skills in other important areas,
such as cloud computing, which lends itself to the resilience dimension. It is vital that teams work effectively
to maximise the benefits of each other’s skill sets.
It is often desirable for everyone to have a broad understanding of what they are implementing. The following
resources are suggested as a introductory reference material. Note: these should be considered independently to the
papers that you include in your literature review!
• On research methods in computer science: J. Zobel, “Writing for Computer Science.” Springer, 2009 [2].
• On threat modelling: A. Shostack, “Threat modeling: Designing for security.” John Wiley & Sons, 2014 [3].
Chapters 1–3 are worth consulting for modelling threats in a standard fashion.
• On security and cryptographic engineering: N. Ferguson, B. Schneier, and T. Kohno, “Cryptography
engineering: Design principles and practical applications.” John Wiley & Sons, 2011 [4]. Chapters 1–2 and
18–20 may be of interest.
• Building modern resilient systems: H. Adkins et al., “Building secure and reliable systems: Best practices for
designing, implementing, and maintaining systems.” O’Reilly Media, 2020 [5]. See chapters 1–2 and 8–10.
Acknowledgements
A ‘thank you’ is due to the previous staff, particularly Dr. Steve Riddle, who helped make CSC8208 a success
in previous years. Also, thanks to Dr. Essam Ghadafi for permission to use the CSC8209 marking criteria from
which the final report’s mark scheme is derived.
References
[1] N. Borisov, I. Goldberg, and E. Brewer, “Off-the-record communication, or, why not to use PGP,” in Proceedings of the ACM Workshop on Privacy in the Electronic Society, pp. 77–84, 2004.
[2] J. Zobel, Writing for computer science. Springer, 3 ed., 2014.
[3] A. Shostack, Threat modeling: Designing for security. John Wiley & Sons, 2014.
[4] N. Ferguson, B. Schneier, and T. Kohno, Cryptography engineering: design principles and practical applications.
John Wiley & Sons, 2011.
[5] H. Adkins, B. Beyer, P. Blankinship, P. Lewandowski, A. Oprea, and A. Stubblefield, Building secure and
reliable systems: best practices for designing, implementing, and maintaining systems. O’Reilly Media, 2020.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 9
CSC8208 MODULE
HANDBOOK
(
V1.2) ACADEMIC
YEAR: 2023/2024
Appendix
Assessment 1 Criteria
We maintain a broadly flexible marking scheme for assessment one (30% of the overall module grade). The first element of the report—the paper summaries—
will be marked with respect to the components in Table 1. This will attract 20% of the overall module grade; each paper summary will carry 1/3 of this grade.
Table 1: Assessment 1 – Marking criteria breakdown.
Aspect Contribution (%) Description
Investigation methodology 30 Does the paper aim to answer any questions? What are these? If not, what do you think these
questions are? Why are these questions interesting to the general reader (not just yourself) How
does the paper answer these questions?
Critical evaluation 50 Provide a critical commentary on the work itself, focusing on the strengths and weaknesses. In
particular, the strengths of the work should demonstrate your understanding on the paper itself
and its merits. You should not justify your commentary based on the print-quality or formatting
of the work.
Open challenges and discussion 20 Write a discussion note about the paper itself, by presenting a list of topics or questions about the
paper, for the reader to consider. These should not be questions the paper has already asked, or
those you have written previously.
The remaining 10% is divided as follows:
• Threat model (5%): Give a succinct description of the attackers and attack methods with suitable justification (1/2 page).2
• Security policy (5%): Give a concise set of rules (bullet points) which can serve as the security requirements that if met, will successfully protect against
attackers (1 page).
2For the utmost clarity, the threat model and security policy should be written specifically with respect to your secure chat project, not the paper summaries.
NEWCASTLE
UNIVERSITY Last modified: March 1, 2024 10
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024 Assessment 2 Criteria This assessment attracts 70% of the module. The mark scheme in Table 2 will be used. Table 2: Assessment 2 – Mark scheme. Component (%) Fail (0–39%) Borderline (40–49%) Pass (50–59%) Merit (60–69%) Distinction (70–100%) Introduction (10%) Irrelevant rationale, aims, objectives, or problems to be addressed. A present but unclear rationale; objectives are largely vague in scope. A clear aim and mostly realistic objectives; may be vague in places. Clear aim with specific, realistic, measurable ob- jectives; good rationale. Cogent, research-based aim and SMART objec- tives; excellent rationale. Background (15%) An absent or irrelevant consideration of related work; no connection to the aim and objectives. Limited coverage of es- sential literature; many relevant papers not in- cluded; vaguely relevant to the aim and objectives. Basic coverage of related literature; some relevant papers not included; a weak but clear link to the aim and objectives. Good coverage of related work, but largely de- scriptive or uncritically treated; a good link to aims and objectives State-of-the-art literature covered, understood, and critically reviewed; clear and compelling links to the aim and objectives. Security (15%) Solution mostly fails to meet any ‘must have’ se- curity requirement. Lim- ited awareness of relevant threats and mitigations. Vaguely addresses some ‘must have’ security re- quirement; largely flawed mitigations. Addresses the key secu- rity requirements; mitiga- tions may have shortcom- ings; sound threat model and security policy. Addresses the key secu- rity requirements; appro- priate and correctly im- plemented mitigations. Addresses key and 1+ other security require- ments; strong threat model, security policy; appropriate mitigations. Resilience (15%) Solution does not enable one-to-one communica- tion; not resilient under any scenario. Enables two-party com- munication at any one time; major issues under most realistic scenarios. Multiple simultaneous sessions; implements a stated resilience mecha- nism; may have issues under some scenarios. See ‘pass’ but with a compelling implementa- tion showing resilience under realistic scenarios. A compelling solution with multiple resilience mechanisms catering to realistic scenarios. Innovation (15%) No potential for innova- tion; badly executed ver- sion of a simple system. A working derivative of existing work; no mate- rial novelty. Some novelty, but minor or incremental in nature. Significant novelty; largely safe, conventional approach to a reasonable problem. Significant novelty; con- vincingly addresses a rea- sonable problem in an original, inventive way. Evaluation (15%) An irrelevant or missing evaluation. Limited justification of the project’s aims and objectives. No empirical evidence. Acceptable justification; empirical methods used to justify the project’s aims and objectives. Empirically-led eval- uation; may not meet real-world requirements. Convincing, empirically- led evaluation demon- strated under real-world requirements. Form (5%)
CSC8208: Module Handbook
March 1, 2024
1 Introduction
Welcome to CSC8208: Research Methods and Group Project in Security and Resilience! In this module, you
will work as a team to research, design, implement, and evaluate a software system within the context of a
security-related topic. This handbook aims to establish the expectations, module structure, assessment and
marking criteria, and the way in which teams will be chosen and monitored during the course of this module.
In this module, you will gain experience with reading and understanding research papers within the field of
cyber security. In the last 25 years, 3015 papers have been published in the top four security-research conferences. New security knowledge is often first published in scientific papers; the skill for reading, assimilating,
and communicating new knowledge is a crucial one in the long term.
You will work largely independently as a team using your own initiative with minimal supervision. This
is similar to the way in which your individual project (dissertation) supervisor will likely operate. Lectures
are delivered to support the development of your group projects, covering material on reading and writing
papers, evaluation methods, and more. On CSC8208, all course materials and discussions will be hosted and
conducted respectively on Canvas for later reference.
The following academic staff will deliver CSC8208 this academic year:
2 Module Calendar
During this module, you will go through a series of lectures to help you learn best practices in reading and
presenting research, and writing a report on your findings. You will be organised into groups of approximately
eight members per team. You will then briefly read all papers towards the Assessment 1: Literature Review,
Threat Model & Security Policy. Assessment 1 involves concisely summarising a subset of these research
papers, which should assist you in the final report.
The rest of the module is dedicated for the collaborative Group Project as outlined in Assessment 2: Project
Report. Your project must also be demonstrated. Students are expected to start working on a comprehensive
project that is meticulously executed and documented in a report.
2.1 Lectures
The lectures are scheduled to be delivered in the following order:
1. Module introduction. 10:30–11:30, Monday 12th February 2024.
2. Project briefing. 11:30–12:30, Thursday 15th February 2024.
3. Establishing a common vocabulary on security and resilience. 10:30–11:30, Monday 19th February 2024.
4. Implementation guidance. 11:30–12:30, Thursday 22nd February 2024.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 1
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
5. How to read a research paper. 10:30–11:30, Monday 26th February 2024.
6. Writing and presenting a project. 11:30–12:30, Thursday 29th February 2024.
7. How to evaluate a project (Part 1). 10:30–11:30, Monday 4th March 2024.
8. How to evaluate a project (Part 2). 11:30–12:30, Thursday 7th March 2024.
Location: FDC.G.06.
2.2 Tutorial Sessions
Several tutorial sessions are scheduled in your timetable. It is expected that one member per team, at an
absolute minimum, will attend in order to provide a update on the team’s progress at each session. Team
mechanics are described in greater detail in §4. These sessions take place on:
1. 26th February 2024.
2. 4th March 2024.
3. 11th March 2024 (For the formative assessment of teams 1–11).
4. 18th March 2024 (For the formative assessment of teams 12–22).
Location: USB 1.006 at 13:30–14:30.
2.3 Assessment Deadlines
The following assessments are set, along with their respective weightings:
1. Literature Review, Threat Model and Security Policy (30%): This assessment broken down into:
(a) 20%: Summarise three research papers from the repository provided on Canvas. These focus on
different research directions, such as system security, malware, and Internet of Things security. Each
summary should be ∼1,000 words.
(b) 5%: Submit a threat model that you will address specifically in your secure chat project. This includes a concise description of the attackers and attack methods with appropriate justification.
(c) 5%: Submit a security policy comprising a concise set of rules (bullet points) which can serve as the
security requirements that, if met, will successfully protect against the attackers in the threat model.
Your submission must have a maximum length of 5 pages in total using the IEEE Computer Society
double-column conference template. Markers will be under no obligation to mark beyond this: you
may miss out on marks if you exceed this limit.
• Due date: 4th March 2024.
• Submission type: PDF.
2. Presentation (Optional/Formative): A verbal presentation in an elevator pitch style of your developed
project. This should be delivered in person on 11th March 2024 (Teams 1–11) and 18th March 2024
(Teams 12–22). It should be 5 minutes in duration. There is no formal marking scheme.
3. Final Group Report (70%): Presents your developed solution to the project brief. Your report must be
max. 10 pages, again using the IEEE template. Markers will be under no obligation to mark beyond this.
You must also submit a video file that demonstrates a working project.
• Due date: 22nd March 2024.
• Submission type. a PDF (report) and ZIP file containing your software artefact AND a video
demonstration of your project (e.g. MPEG4).
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 2
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
All assessments are group-based. Marks are distributed to individuals using the formula described later in
§4.3. Within each assessment, we expect that students submit their contribution percentages within an
appendix chapter.
NESS must be used for submitting your assessments.
3 Project Brief: A Secure Chat System
Secure communication is a major concern for personal and professional use, with numerous solutions having
emerged over the years. The current wave of secure chat clients dates as far back as 2004 with the development
of the Off-the-record (OTR) messaging protocol [1], which supports secure instant messaging with message
encryption, authentication, and forward secrecy. Signal, Theema, Telegram, and WhatsApp represent some of
the most widely used secure messaging solutions in today’s marketplace.
In this project, you are tasked to design, implement, and evaluate a chat system that provides one-to-one
or group-based communication. Your system must allow at least two communicating entities to send and
transmit messages over a secure channel to each other. You have two overarching tasks to complete, which are
described in the following subsections.
3.1 Task 1: Literature Review, Threat Model, and Security Policy
You will begin with a literature survey by selecting and reviewing any three research papers from a predetermined list of scholarly articles provided by the staff. You should briefly read all papers before selecting
and reviewing three papers that you deem most interesting and appropriate from which to develop your final
project (Task 2). Be mindful of a literature review’s purpose: it is not a list of papers described uncritically.
This is the first part of the assessment.
In the second part of the assessment, a threat model and security policy will be devised, pertaining specifically
to your project. The definition of a “secure” chat system is left purposely vague for you to define. Therefore,
you are required to submit a threat model and a security policy aligned with your chosen theme and research
papers. The threat model will concisely state the potential threats and the attacker capabilities that your project
will address. This should be a brief (0.5 page) description. You must also present a basic security policy. This
will be presented as a concise set of rules, i.e. bullet points, which can serve as the security requirements that
if met, will successfully protect against attackers (1 page).
Your group-based paper reviews, threat model, and security policy attracts 30% of the overall module mark.
A breakdown of the marking criteria is given in §5.
3.2 Task 2: Build and Write-up Your System
The design, implementation, and evaluation of your own secure chat system is the main task in this module.
Your system is described in the final report, which must be written in the style of a scientific paper, attracting
70% of the module mark. Broadly, your report should include introducing the problem, providing a related
work section, discussing your design and implementation decisions, how you evaluated your system, and
conclusions with directions for future research. In the report, you will primarily be assessed with respect to
three dimensions: 1 security, 2 resilience, and 3 innovation. The strength of your project’s introduction,
evaluation, and presentation are also assessed.
3.2.1 Dimension 1: Security
This dimension assesses how your system addresses a reasonable threat model and security policy.1 The quality
of the mitigations is of paramount importance. Good projects are expected to use mitigations that follow
current best practices and use existing libraries (e.g. see “don’t roll your own crypto” in §6).
1Your threat model and security policy may be refined from the first assessment for your final project report.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 3
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
For the avoidance of ambiguity, we expect the following to be satisfied as minimum ‘must have’ requirements in
order to achieve a basic pass:
• Confidentiality: Ensure that any transmitted messages between clients cannot be trivially read over a
network medium.
• Integrity/authenticity: Ensure that trivial changes to any transmitted messages can be detected. For
example, if A sends “Let’s meet at 9am tomorrow” to B, then a third party, C, should not be able to change
this to “Let’s meet at 10pm tomorrow” without it being detected.
• User authentication: How will you ensure that only a given user can log into their account? For example,
through the implementation of secret-based methods, e.g. requiring passwords or biometrics to log in.
Beyond this, higher-scoring projects should convincingly provide additional features. As a general guideline, a merit-level project should implement one of the following; a distinction-level project would implement
more than one of:
1. Secure file transfer: In addition to simple messages (strings), can you enable the secure transmission of
files, e.g. PDFs and images, between clients in an efficient way?
2. Message self-destruction/deletion: Can you enable users to delete messages in a way that leaves no trace
of them on their device, server etc.? This could be time-based, e.g. similar to WhatsApp’s time-limited
messages, or on demand from the user.
3. Secure persistent message storage: How could you ensure that messages are stored securely at rest?
This could applied to the user’s device or the chat server.
4. Biometrics: To enhance usability, could you enable users to log in to their accounts using their fingerprint, or facial image etc.?
3.2.2 Dimension 2: Resilience
Implementing resilience into any chat system requires various considerations to ensure reliability and robustness. As a minimum requirement to achieve a pass in this dimension, your project should allow more than
one communication session at a time. Beyond this, it is expected that you explore a wider range of techniques
to protect against unintended faults. A good (merit-level and above) project should implement at least one of
the following aspects:
1. Redundancy and failover: Can you use multiple servers/instances to ensure that, if one server/instance
fails, another can take it over seamlessly?
2. Data backup, replication, and recovery: Does your project regularly backup data and have a recovery
plan in place? The goal would be to quickly restore your service in the event of a major system failure.
3. System monitoring. You may implement substantial alerting mechanisms, for example, to help identify
and remedy faults and other issues as they arise.
4. Scalability. How will your system handle large amounts of traffic, which may hinder the delivery of
legitimate messages (among other problems)? Design mechanisms that gracefully handle this increased
load.
To be clear, implementing a comprehensive range of resilience techniques, commensurate with a productiongrade system, is not necessary in this module. See the marking criteria in §5 for additional guidance.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 4
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
3.2.3 Dimension 3: Innovation
This final component assesses the innovation of your project; that is, how it provides new features, or addresses
new requirements, in a way that goes beyond existing secure chat systems.
Some ideas for novelty include:
1. Privacy-enhancing technologies: To what extent can differential privacy, private contact discovery, or
data obfuscation be applied in a novel way?
2. How could machine learning be integrated in your solution in a new way? For example, for detecting
fake/malicious clients or unauthorised users of devices in real-time (continuous user authentication)?
3. Information hiding: How can steganography be incorporated in a new way to covertly transmit secrets
in the presence of adversaries who may have access to messages?
4. Blockchain: To what extent could blockchain be used in a secure messaging system?
You may also express your innovation through the project’s engineering with clearly justified benefits. For
example, you may utilise a new network or system architecture (e.g. supporting decentralisation); using an
interesting network medium over which to communicate messages; using readily available hardware security
technologies to protect encryption keys; and more. This should be convincingly justified in your report.
3.3 Module Flowchart
To help your understanding of CSC8208’s structure, we illustrate the different stages and times in Figure 1.
4 Team Mechanics
To be successful in this module, it is critical to learn to work effectively within a team of people whom you
may not know. This is to replicate a real-world environment: just like the workplace, you may have never
worked with, or have even met, your teammates before this module. To this end, you will be stratified into
groups of approximately eight members each, comprising members from different M.Sc. programmes within
the School of Computing. Please note that the staff will allocate the teams; students will not be able to form
teams themselves. Changing teams is also prohibited unless there are exceptional circumstances with the
approval of the module leadership. This is to ensure diversity and consistency across teams.
4.1 Team Leader
Once you have been allocated to teams, it is imperative that you make contact as a collective as soon as possible.
Each team must nominate a leader whose responsibilities include:
• Arranging and leading group meetings. Includes physical/virtual meetings, setting agendas and delegation. It is important to re-emphasise that module staff are not responsible for arranging your team
meetings, nor can they expected to attend them.
• Submitting group assessments. To ensure consistency, each team leader shall submit assignments on
behalf of the group (literature review, presentation, and final group report).
• Planning the team’s activities. A concrete plan is an important component in ensuring that assessments
are submitted on time, with sufficient contingency measures, and that tasks will be delegated fairly
We expect each group to have nominated a leader and held their first meeting(s) by the end of the first teaching
week. A deputy leader is also required, who will assume the responsibilities of the team leader in a back-up
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 5
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
Lectures
Group Allocation
Reading Papers
Project Theme Selection
Three Paper Reviews
Threat Model
Security Policy
Assessment 1 Submission
High & Low Level Design
Coding & Implementation
Testing & Evaluation
Assessment 2 Submission
Weeks 1 to 4
Week 1
Weeks 2-3
Weeks 3-4
4th March
Weeks 4-6
22nd March
Weeks 1-4
Weeks 4-6
Figure 1: Indicative module flowchart.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 6
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
capacity. The names of team leaders and deputy leaders should be submitted in your Microsoft Teams channel
by Week 2.
Submit progress update each week covering minutes of the team meeting and any concerns.
4.2 Project Supervision
As mentioned in Section 1, teams are expected to work independently with minimal supervision, similar to
the way in which your individual project (dissertation) supervisor may operate. However, you are not alone:
problems sometimes arise that prevent teams from functioning as expected. There are several ways in which
such issues can and should be raised. Firstly, it is critical that you make the most of the aforementioned tutorial
sessions. Please do not hesitate in raising queries/issues with the module staff during the scheduled tutorial
sessions. Within the short duration of the module, unresolved issues can quickly spiral into ones that affect
your grades. The Canvas discussion board functionality also serves as an appropriate forum for raising issues.
Lastly, if all other avenues of communication have failed, the module staff can be contacted via email.
4.3 Individual Contribution Formula
It is important in team-based modules to ensure that each member’s contributions are fairly reflected in the
overall marks. This must be done in a way that incentivises teamwork and collaboration, avoiding situations
in which one or two people do all of the work. This module uses the following guidance, which has been used
in previous years on CSC8208 and its sister module, CSC8113: “Group contributions should be agreed among the
group, and should be fair and truthful. They should sum to 100% and must be included in the group report.”
In other words, if a group has eight members, then an ‘ideal’ allocation is 12.5% per person to indicate that
everyone has contributed equally. However, it need not be ideal due to the different levels of engagement
between team members. A possible distribution could be 15%, 15%, 15%, 15%, 15%, 10%, 5%, and 10%.
In your decision-making process, please consider the significance of individual contributions. If the final
project report carries a weight of 70% of the overall module marks, and a group mark is given as 80/100, then
the report will carry 56/70 (= 70 × 0.8) towards the group’s mark.
Given eight members in a group, there are (56 × 8) = 448 marks to be distributed. Let us also assume each
member is named as A, B, C etc. Given an example of A = 15%, B = 15%, C = 15%, D = 15%, E = 15%,
F = 10%, G = 5%, and H = 10%, then the following allocation will be made for individual grades:
• A, B, C, D, and E will receive 15% of 448 = 67.2/70 = 96%.
• F and H receive 10% of 448 = 44.8/70 = 64%.
• G receives 5% of 448 = 22.4/70 = 32%.
Therefore, G will receive a failing grade for this assessment.
Considering that 100% is the maximum that a student can achieve, this methodology has some significant
consequences. Let’s assume the same situation in which the group has received 56/70 for their final report:
• Assume that four members, A, B, C and D, do all of the work, and their contributions are 25% each with
all other team members having zero contribution. In this scenario, A . . . D will thus receive 0.25 × 448 =
112/70 = 160%, while E . . . H will receive 0%. Because the assessment is ‘capped’ at 100% per individual,
A . . . D will receive 100% in practice; the additional amounts over 100% are lost.
• Freeloading on others’ contributions is penalised. Assume A . . . G contribute 14% each, while H contributes 2%. H will receive a failing grade in their individual mark (0.02 × 448 = 8.96/70 = 12.8%) while
A . . . G receive 0.14 × 448 = 62.72/70 = 89.6%.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 7
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
5 Marking Criteria
5.1 Literature Review, Threat Model, and Security Policy
This assessment aims to develop critical analysis and understanding of key research papers within the realm
of security, specifically focusing on subject areas such as privacy, performance, networking and blockchain.
Students are tasked with reviewing any three research papers from a pre-determined list of scholarly articles
provided by the module staff.
Along with the research paper reviews, students are required to submit a threat model and a security policy aligned with their chosen theme and research papers. The security policy should encompass preventive
measures, detection strategies and measures to maintain the security properties outlined in the threat model.
The mark scheme for this assessment is given in Table 1 at the end of this document.
5.2 Final Project Report
The final project report attracts the biggest percentage of any assessment (70%). It should describe your solution in the style of a scientific paper (IEEE Computer Society double-column journal or conference style). This
should give you a feel for how ‘real’ papers in computer science are composed. The template can be found
online or on Canvas.
The precise section headings are left for you to decide. However, in general, we expect that a good report
would comprise the following:
• The project’s aim, rationale and objectives, and a brief background of the research problem(s) that you
are solving.
• A literature review in the form of a ‘Related Work’ section written specifically on secure chat systems.
• How your system design and implementation addresses each of the three aforementioned dimensions:
1 security, 2 resilience, and 3 research novelty, as described in §3.2.
• How you evaluated your project.
• Your conclusion(s) and any directions for future research.
To guide the development of your project, the final report will be marked using the criteria in Table 2 at the
end of this document. This should set out the expectations for receiving the different grades. Good luck!
6 Helpful Advice
Some common issues have arisen in the past that have limited the success of teams’ assessments in this module.
These issues are described below in order to help you avoid them:
• Structure and focus your team appropriately. It makes little sense for every team member to be on
programming duties with nobody, for example, working on security engineering or research novelty. It
is generally a sound strategy is to focus efforts evenly, structuring the team to meet all elements of the
marking criteria. For example, you may wish to assign a resilience ‘lead’ to to one team member, security
to another, and so on. This will help balance your team while leveraging the strengths of each member.
• ‘Don’t roll your own crypto’. During the design and implementation of your project, it is important to
use established, rigorously tested security algorithms. Implementing protocols, or worse, cryptographic
algorithms from first principles is not necessary to be successful in this module. Always opt for an
existing libraries and protocol implementations over ones you build yourselves.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 8
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024
• Make use of communication and collaboration tools. Working effectively in a team is essential to succeeding in this module. It is strongly advised to arrange frequent in-person or virtual meetings to help
make key decisions, delegate tasks etc. You may also wish to use Microsoft Teams, Slack, Discord, or
another platform to help coordinate your activities online. Github and other Git implementations are
also useful in managing code bases that involve a number of contributors.
7 Supplemental Background Reading
This module accepts students from a wide range of backgrounds and programmes. Some team members may
have a limited understanding of security, while others, such as those on the M.Sc. Cyber Security programme,
may have a large degree of knowledge. However, other members will have skills in other important areas,
such as cloud computing, which lends itself to the resilience dimension. It is vital that teams work effectively
to maximise the benefits of each other’s skill sets.
It is often desirable for everyone to have a broad understanding of what they are implementing. The following
resources are suggested as a introductory reference material. Note: these should be considered independently to the
papers that you include in your literature review!
• On research methods in computer science: J. Zobel, “Writing for Computer Science.” Springer, 2009 [2].
• On threat modelling: A. Shostack, “Threat modeling: Designing for security.” John Wiley & Sons, 2014 [3].
Chapters 1–3 are worth consulting for modelling threats in a standard fashion.
• On security and cryptographic engineering: N. Ferguson, B. Schneier, and T. Kohno, “Cryptography
engineering: Design principles and practical applications.” John Wiley & Sons, 2011 [4]. Chapters 1–2 and
18–20 may be of interest.
• Building modern resilient systems: H. Adkins et al., “Building secure and reliable systems: Best practices for
designing, implementing, and maintaining systems.” O’Reilly Media, 2020 [5]. See chapters 1–2 and 8–10.
Acknowledgements
A ‘thank you’ is due to the previous staff, particularly Dr. Steve Riddle, who helped make CSC8208 a success
in previous years. Also, thanks to Dr. Essam Ghadafi for permission to use the CSC8209 marking criteria from
which the final report’s mark scheme is derived.
References
[1] N. Borisov, I. Goldberg, and E. Brewer, “Off-the-record communication, or, why not to use PGP,” in Proceedings of the ACM Workshop on Privacy in the Electronic Society, pp. 77–84, 2004.
[2] J. Zobel, Writing for computer science. Springer, 3 ed., 2014.
[3] A. Shostack, Threat modeling: Designing for security. John Wiley & Sons, 2014.
[4] N. Ferguson, B. Schneier, and T. Kohno, Cryptography engineering: design principles and practical applications.
John Wiley & Sons, 2011.
[5] H. Adkins, B. Beyer, P. Blankinship, P. Lewandowski, A. Oprea, and A. Stubblefield, Building secure and
reliable systems: best practices for designing, implementing, and maintaining systems. O’Reilly Media, 2020.
NEWCASTLE UNIVERSITY Last modified: March 1, 2024 9
CSC8208 MODULE
HANDBOOK
(
V1.2) ACADEMIC
YEAR: 2023/2024
Appendix
Assessment 1 Criteria
We maintain a broadly flexible marking scheme for assessment one (30% of the overall module grade). The first element of the report—the paper summaries—
will be marked with respect to the components in Table 1. This will attract 20% of the overall module grade; each paper summary will carry 1/3 of this grade.
Table 1: Assessment 1 – Marking criteria breakdown.
Aspect Contribution (%) Description
Investigation methodology 30 Does the paper aim to answer any questions? What are these? If not, what do you think these
questions are? Why are these questions interesting to the general reader (not just yourself) How
does the paper answer these questions?
Critical evaluation 50 Provide a critical commentary on the work itself, focusing on the strengths and weaknesses. In
particular, the strengths of the work should demonstrate your understanding on the paper itself
and its merits. You should not justify your commentary based on the print-quality or formatting
of the work.
Open challenges and discussion 20 Write a discussion note about the paper itself, by presenting a list of topics or questions about the
paper, for the reader to consider. These should not be questions the paper has already asked, or
those you have written previously.
The remaining 10% is divided as follows:
• Threat model (5%): Give a succinct description of the attackers and attack methods with suitable justification (1/2 page).2
• Security policy (5%): Give a concise set of rules (bullet points) which can serve as the security requirements that if met, will successfully protect against
attackers (1 page).
2For the utmost clarity, the threat model and security policy should be written specifically with respect to your secure chat project, not the paper summaries.
NEWCASTLE
UNIVERSITY Last modified: March 1, 2024 10
CSC8208 MODULE HANDBOOK (V1.2) ACADEMIC YEAR: 2023/2024 Assessment 2 Criteria This assessment attracts 70% of the module. The mark scheme in Table 2 will be used. Table 2: Assessment 2 – Mark scheme. Component (%) Fail (0–39%) Borderline (40–49%) Pass (50–59%) Merit (60–69%) Distinction (70–100%) Introduction (10%) Irrelevant rationale, aims, objectives, or problems to be addressed. A present but unclear rationale; objectives are largely vague in scope. A clear aim and mostly realistic objectives; may be vague in places. Clear aim with specific, realistic, measurable ob- jectives; good rationale. Cogent, research-based aim and SMART objec- tives; excellent rationale. Background (15%) An absent or irrelevant consideration of related work; no connection to the aim and objectives. Limited coverage of es- sential literature; many relevant papers not in- cluded; vaguely relevant to the aim and objectives. Basic coverage of related literature; some relevant papers not included; a weak but clear link to the aim and objectives. Good coverage of related work, but largely de- scriptive or uncritically treated; a good link to aims and objectives State-of-the-art literature covered, understood, and critically reviewed; clear and compelling links to the aim and objectives. Security (15%) Solution mostly fails to meet any ‘must have’ se- curity requirement. Lim- ited awareness of relevant threats and mitigations. Vaguely addresses some ‘must have’ security re- quirement; largely flawed mitigations. Addresses the key secu- rity requirements; mitiga- tions may have shortcom- ings; sound threat model and security policy. Addresses the key secu- rity requirements; appro- priate and correctly im- plemented mitigations. Addresses key and 1+ other security require- ments; strong threat model, security policy; appropriate mitigations. Resilience (15%) Solution does not enable one-to-one communica- tion; not resilient under any scenario. Enables two-party com- munication at any one time; major issues under most realistic scenarios. Multiple simultaneous sessions; implements a stated resilience mecha- nism; may have issues under some scenarios. See ‘pass’ but with a compelling implementa- tion showing resilience under realistic scenarios. A compelling solution with multiple resilience mechanisms catering to realistic scenarios. Innovation (15%) No potential for innova- tion; badly executed ver- sion of a simple system. A working derivative of existing work; no mate- rial novelty. Some novelty, but minor or incremental in nature. Significant novelty; largely safe, conventional approach to a reasonable problem. Significant novelty; con- vincingly addresses a rea- sonable problem in an original, inventive way. Evaluation (15%) An irrelevant or missing evaluation. Limited justification of the project’s aims and objectives. No empirical evidence. Acceptable justification; empirical methods used to justify the project’s aims and objectives. Empirically-led eval- uation; may not meet real-world requirements. Convincing, empirically- led evaluation demon- strated under real-world requirements. Form (5%)