| Instructors | Daniel Votipka, Kelsey Fulton, Mike Hicks, and Michelle Mazurek |
| Time | M/W/F 12:00-1:30pm |
| Location | IRB 1207 |
| Office Hours | Available on request, IRB 5112 |
This will mostly be a hands-on course centered on the design, implementation, and refinement of a single medium-sized system of programs throughout the semester. The course will be structured into two phases. In the first part of the course, you will spend most of your time in class designing and building your secure system. Then, in the second part, you will attempt to break your classmates' programs and respond to exploits by classmates (by fixing your code).
Throughout, we plan to cover a subset of the secure software development material typically covered in 414 (e.g., network security, cryptography, memory corruption attacks, etc.). However, most of the class time will be spent working on the project in teams. Our hope with this flipped classroom approach is that we'll be able to provide tailored, in-depth feedback as we go through to help everyone get a solid, practical understanding of software security by the end of the course.
Additionally, data generated throughout the course of the class will be used in ongoing secure development learning research. This includes recordings and observations of team discussions and any submitted artifacts (code changes, design documents, etc.). All data collected will be anonymized prior to reporting and raw data will be maintained in a secure location only accessible to the instructors and research team. You will not be required to perform any tasks beyond what would be required for an equivalent course; we will simply maintain and report on the anonymized data you produce.
The bulk of your grade will come from the course secure programming competition. Your grade for the competition will be divided into two parts: per-round criterion (40%) and competition score (20%).
Every day of the course, students will submit a status report. This is intended to help the instructors know where you are in the project and any issues you are facing.
Any time a commit is made to your project codebase, it should be accompanied by a description of the change. This description should answer a set of questions specific to the round. Specific requirements for each round are given on the resources page.
Throughout the course, you will complete a series of surveys where you will be asked to gauge your secure development experience and describe strategies and methods used when writing your code.
In your system design documents, you will answer three main questions: how system is organized to meet required and optional functions, how an attacker can affect the system, and mitigations in place against potential attacks.
You will be asked to submit a design document three times during the course: At the start of development (6 Jan), after the Build round (13 Jan), and at the end of the competition (22 Jan).