Project information
Overview
This course will require each student to complete a project,
through a series of iterations, in which you will be asked to
perform a security evaluation of a software system, and produce a
report documenting the results of this evaluation. The final
report should generally be 10-12 pages in length, and consist of
three sections, plus a separate code submission:
- System Design. Describe the software system in enough
detail that someone who has not seen the code can understand the
basics of its architecture and function, including detailed DFDs
for the system (or the portion evaluated so far) and generally
take about 2-3 pages. You will want to follow the DFD
“visual syntax” described by Shostack in Chapter 2.
- Threat Model. Develop a basic threat model
(e.g. using STRIDE) that outlines what you consider to be the
types of threats that you evaluated the system against (not only
the types of threats you eventually found), and justifications
for the threats you considered. A good rule of thumb is that
your threat model will give a high-level overview of what
security properties the system should provide, followed
by a STRIDE-per-element overview that spells out why each
category of STRIDE threat is or is not pertinent to each element
in the DFD (for example, if a flow is by function call or an
OS-provided communication channel, it may not be subject to
tampering even though in general STRIDE-per-element would
dictate that this is a possible threat; or perhaps spoofing or
elevation of privilege are more or less relevant for some
processes than others.) This section should use perhaps 3 pages
of the final report.
- Summary of Findings. The system we'll give you is
deliberately buggy, so we expect you to eventually be able to
document at least 6 vulnerabilities in the complete system
(covering at least three different STRIDE categories). For each
vulnerability you describe, the summary of findings should
include a separate section describing the vulnerability in
enough detail for another programmer to verify, explain why this
is a problem, and suggest methods to mitigate the
vulnerability. At least two of these vulnerabilities should
be a code execution / elevation of privilege vulnerability. A
good vulnerability report should illustrate what portions of the
code enable the attack, how inputs or actions of an attacker can
reach this point, document confirmation that the attack is
feasible, and document the effects of the attack. This section
will generally be at least 4-5 pages long. Note: No BS.
Claiming that an attacker can exploit a coding issue without
confirming this is possible is academically and
professionally dishonest. You must not make unsubstantiated
claims of vulnerability in your report. If you think that there
is a risk of a vulnerability but you do not know for sure, your
writing needs to reflect that uncertainty. Making
unsubstantiated claims is worse than saying nothing at all. You
won't just not get any credit for the false claim: doing this in
your report would be grounds for a grade of zero on the entire
assignment.
- Proof of concept exploits: For each of the
vulnerabilities in your summary of findings, you should be able
to give a “proof of concept” script or input that
triggers the claimed behavior (for example: exploits an
elevation of privilege vulnerability to obtain a shell, or
exploits an information disclosure vulnerability to obtain
confidential information). These programs, along with a
README.md file explaining how to replicate your finding
using them, will be submitted along with your report. Note:
the README is an important requirement. Without a README
file explaining what each PoC script does, how it does it, how
to run the script, and what result to expect, we will not be
able to grade this portion of the report.
In each project submission, you will focus on an additional
component of the software, while also revising your previous
report according to the feedback you received at submission time.
Your second and third submissions will include an addendum that
explains how the report was updated in response to the feedback
you received on the previous submission(s).
Group Writing
You are encouraged to work in groups of up to 3 students each,
and each group should submit one report and supporting
artifacts. We expect all students in a group to contribute to
all phases of the work. In particular, because all students
must write in this class, each student in a group should
individually be the primary author, over the course of the
semester, of 2 vulnerability subsections, and one design section
or revision, and one threat model section or revision. Each group
report must include a separate addendum that explains which
student was the primary author of each section. To demonstrate the
separate efforts of each group member, you will need to
individually submit drafts of a section you have been working on
before each full group submission.
Grading Criteria
There will be a more detailed checklist for each submission,
but your group's score for project assignments will be derived
from the following components:
- Completeness (20%): do you report and code submission
include all the required contents?
- Writing quality and process (30%): 2/3rds, 20% of the
total, will be for the quality of the writing in the project
submission, according to a rubric we will go over in more detail
before the first submission. The remaining third, 10% of the
total, will be based on your participation in the processes
around your writing, including making changes in response to our
feedback and fairly dividing effort among group members and
reporting how you did so.
- Correctness (50%): Do we agree that each of your
vulnerabilities are present and properly described? Do the
proofs of concept execute as described? Your README.md
must be clearly organized and easy to follow.
- Extra credit Up to 4% (4 points out of 100) are
available for additional vulnerabilities and/or proofs of
concept. A well-described and distinct vulnerability included in
the report earns 1 point of extra credit. A corresponding
working and well-documented proof of concept will also earn 1
point of extra credit.
Timeline
- Iteration 1:
- Iteration 2:
- Release date: Tuesday, March 18th
- Due date: Tuesday, April 15th, by 11:59pm
- Iteration 2:
- Release date: Tuesday, April 8th
- Due date: Tuesday, May 5th, by 11:59pm (no extension)
This project description is based in large part on a
description by Prof. Nick Hopper, and is licensed under Creative
Commons Attribution-ShareAlike 4.0.
