Case Study Project

Overview

The purpose of the case study project is to get you acquainted with the security challenges of a real, complex, messy software product. In class, you learn about security ideals, common mistakes, and best practices. In the case study, you will see how those ideals are applied (or not applied!) to actual problems.

This case study is designed to help you in two key ways: investigation and co-authorship. The investigative part of this project is to help you to learn about software projects from the outside in. This means reading bug reports, documentation, mailing lists, commit logs, and anything else you can get your hands on to understand what's going on. The co-authorship part of this project is to help you learn what it's like to describe complex arguments (i.e. specific security risks) to a technical, yet non-security-minded audience. The "co-" part is to help you learn how to write much like how you've learned how to code... communicating, coordinating, know when to work alone, know when to work collaboratively, giving good feedback, and reacting to feedback.

The main component of this project is a paper that will be written much like we write code - iteratively. Every few weeks we will have another chapter of the paper due, along with the revisions from the previous chapter. A significant grading emphasis will be based on how well you react to the instructor's feedback, and how well you give feedback to others.

In terms of writing style, here's what the instructor likes to see:

For formal, technical writing, brevity and clarity are key. I would far rather see one clear, thoughtful sentence than three repetitive sentences. You might notice that we have no word minimums or maximums here - only questions that must be answered.

Furthermore, the paper must have a cohesive writing style. Like coding, this is not something you want to be slapping together from a few paragraphs people wrote separately. The varying sections need to be all part of a single narrative. Thus, please do NOT repeat the questions below in your paper - it should read smoothly on its own. Also, using bullet points as a structure is not a cohesive style - this is not a PowerPoint presentation, it is prose.

Submissions and Deadlines

Example Paper

This is an example paper on Chromium that was considered excellent work (PDF). This might give you an idea for the depth of research and quality of writing we consider to be great.

Formatting

Please use following formatting throughout your paper.

Plagiarism

Stealing someone else's writing is a despicable act that will not be tolerated. Do not copy text from other sources. For example, do not simply copy the project website's description into your description

Case Study Proposal

You must find your own team for the project. (3-4 members per team). As a team, choose a case study project. Choosing a project may take some effort, as not every project out there makes a good candidate. Here are the minimum requirements for a good case study:

Your proposal must be written in paragraph form and it must provide a convincing narrative about how you will be able study your project empirically. In your proposal, include the following in any organization you like:

For this proposal, create a document called "X Case Study Proposal" where X is the name of your case study project.

Grading scheme (10pts)

Chapter 1: Domain and Historical Analysis

The purpose of this chapter is to provide an overall assessment of the security risks posed by the domain of your case study. Your chapter must include:

Remember: you're now a software archeologist. This is a research project as much as it is a writing project. Plan on taking a lot of time tracking down source control commits, release histories, bug reports, mailing lists, or whatever software development artifacts you need to track down. Feel free to also share your sleuthing strategies with your team and your class - there are many clever ways of mining software repositories for this information.

A few notes:

Grading scheme (50pts)

Peer Review of Chapter 1

After your chapter is due, you will be assigned another group in the class to review. You will be given one week to review the chapter, and submit comments. You will graded on the quality of comments you provide, so please put thought into them.

Each member of your team will be individually responsible for submitting feedback. Place your comments in appropriate places in Google Docs, using your own login so that the comment can be attributed to you. Be available with clarifications on your comments if needed.

See the syllabus for exact due dates, but this will generally be due one week after the chapter 1 due date.

Your comments should fall into the following categories:

A high-quality comment is insightful, actionable, and constructive. We do not place a number on how many comments you are to give - only on how helpful and insightful they are.

Grading scheme per individual: (15 pts)

Chapter 2: Design Analysis

The purpose of this chapter is to assess the high-level design of the system. Your chapter must include:

A few notes:

Reaction to prior comments: Also due with this chapter is revision to your writing based on all prior comments from the TA, professor, or peer group. We are looking for reasonable revisions. Hit "resolve" on the comments when they are fixed.

Grading Scheme (60 pts)

Peer Review of Chapter 2

Same instructions as Chapter 1. Grading scheme (per individual)

Presentation

Prepare a lightning talk of your case study. You do not need to cover every chapter of your paper. Instead, choose the most interesting part of your case study. Each team will have a total of 13 minutes—keep your presentations strictly 10 minutes or less, leaving 3 minutes for questions. You Powerpoint is not required, but is recommended. You may have one person present, or multiple people. Outside of extenuating circumstances, all team members must be present to receive credit for the presentation. Concrete examples are strongly encouraged.

Total Points: (35 pts)