COMP 435 Final Project: Security Investigation

Goal

The final project should go beyond summarizing a security incident.

You will investigate a security question by analyzing, measuring, reproducing, comparing, or building something.

You may work in teams of 2–3 students.

Core Requirement

Every project must include some original analysis, experiment, comparison, implementation, or evaluation.

A project that only summarizes an incident, paper, or tool is not sufficient.

Project Tracks

1. Analyze a Real System or Incident

Choose a real security incident, vulnerability, or system and analyze it in depth.

Possible components include:

• identify the protected assets
• define the adversary and their capabilities
• identify trust assumptions and trust boundaries
• build a threat model or attack tree
• explain the technical root cause
• connect the incident to course concepts
• compare 2–3 possible mitigations
• create one concrete artifact, such as:
  • an attack-flow diagram
  • a timeline
  • a policy analysis
  • a small experiment
  • a comparison of defenses

Example question:

How did one compromised endpoint in the LastPass breach lead to exposure of customer vault data?

2. Reproduce or Extend a Security Result

Choose a security paper, attack, or result and reproduce one central observation, experiment, or mechanism at an appropriate scale.

You are not expected to reproduce an entire research paper.

Possible projects include:

• reproduce a cache timing difference
• compare two password-hashing approaches
• measure timing differences with and without a mitigation
• reproduce a toy Spectre or side-channel result using provided code
• compare ASLR behavior across repeated executions
• demonstrate a TOCTTOU race in a controlled toy program
• measure how rate limiting changes password-guessing throughput
• compare a vulnerable and fixed web example

Your project should clearly explain:

• what result you are trying to reproduce
• what assumptions you are making
• what you measured
• whether your result matched your expectations
• limitations of your experiment

3. Build and Evaluate a Small Security Artifact

Build a small security tool, demo, or simulator and evaluate what it does.

The goal is not simply to “make an app.” Your project should answer a security question.

Possible ideas include:

• password guessability visualizer
• password-hash benchmarking tool
• access-control policy checker
• toy sandbox or permission simulator
• cache side-channel visualizer
• race-condition demonstrator
• attack-tree builder
• secure-vs-insecure login demo
• file-integrity monitor
• static checker for dangerous API use
• toy anomaly or log-analysis tool

Your project should answer:

What security property is this tool trying to enforce, detect, measure, or explain?

4. Comparative Security Study

Compare two or more defenses, mechanisms, implementations, or policies under the same threat model.

Possible examples include:

• compare two password-hashing approaches
• compare multiple rate-limiting strategies
• compare two memory-safety mitigations
• compare two access-control models
• compare two side-channel mitigations
• compare secure and insecure implementations of the same functionality

Your comparison should use a clear set of criteria and include some measured, observed, or systematically analyzed result.

Common Deliverables

1. Project Proposal (10%). Due 10/21

Approximately 1 page.

Include:

• project title
• project question
• chosen project track
• system, attack, or artifact being studied
• threat model
• what you plan to analyze, measure, reproduce, compare, or build
• expected final artifact
• any tools, datasets, starter code, or papers you expect to use

2. Checkpoint. Due 11/16 (15%)

Submit a short progress update including:

• a preliminary result, experiment, or working prototype
• what you have completed
• your biggest unresolved question or challenge
• any change in scope

3. Final Artifact. Due 12/2 (25%)

Depending on your project, this might be:

• code
• a working demo
• an experiment
• a replication
• a comparative evaluation
• a detailed incident/system analysis
• a visualization or simulator

Artifacts should be reproducible or inspectable when possible.

4. Final Report. Due 12/2 (35%)

Approximately 4–6 pages.

Suggested sections:

1. Question / Motivation
2. Background
3. Threat Model and Trust Assumptions
4. Method
5. Results
6. Security Implications
7. Limitations
8. Mitigations / Next Steps

Your report must also answer:

What did you learn from this project that you could not have learned just by reading about the topic?

5. Final Presentation or Demo. Due 12/2 (15%)

Approximately 5 minutes.

Examples:

• a live demo
• a concise technical walkthrough
• a result-focused presentation

Avoid making this only a narrated summary video of things you’ve already turned in.

Example Project Questions

• How much does rate limiting slow a password-guessing attack?
• What does salting change for an offline attacker?
• Can we observe cache timing differences reliably on our machines?
• How much does ASLR vary addresses across repeated executions?
• Can a TOCTTOU bug be triggered reliably, and what changes when it is fixed?
• How do two password-hashing schemes compare in cost per guess?
• Can we build a toy access-control system that violates complete mediation, then fix it?
• How does input validation change exploitability in a small web application?
• Can we reproduce one figure or result from a security paper using provided starter code?
• How do different mitigations affect a toy side channel or memory-safety bug?
• How does one real security incident map onto assets, trust assumptions, attack paths, and mitigations?

Project Philosophy

The project should feel like a small security investigation, not a polished summary of something that already happened.

You do not need to perform advanced security research. However, stronger projects may involve a paper replication, coding project, experiment, or deeper technical evaluation.

Different project tracks are intended to support different strengths:

• analysis-heavy
• research / experimental
• programming / building
• comparative evaluation

The important common requirement is that your project produces some new evidence, observation, artifact, or analysis of your own.