CMSC 838G, Spring 2014

Software Security


Instructor Michael Hicks
CSI 2107 Tues/Thurs 2:00-3:15pm
Office Hours By appointment AVW 3417
Dates | Class notes | Syllabus | Readings

Important Dates

Class notes

Syllabus

OS-level and hardware protection cannot solve the security problem alone.  We need ways to establish the trustworthiness of software, to augment or even replace these mechanisms.  For example, OS-level mechanisms fail to protect against SQL injections, cross-site scripting, stack smashing, and other attacks.

In this class we consider vulnerabilities in software, and means to address them. Our focus will be on software-oriented techniques, rather than OS-level and hardware techniques (though these will not be ignored). In particular, we will consider novel programming languages, programming language analyses (both on the source code, and as instrumentation on the running program), and programming tools that can be used to identify and address security issues.

Most of the class will consist of reading and discussing papers in the research literature. The discussion site has the reading list and blog software. It's not completely filled out; here is a preliminary reading list (a prefix of which is on the discussion site) .

Prerequisite: There is no official pre-requisite for this class (beyond an undergraduate CS degree); we will attempt to make it largely self-contained. We will be reading some technical papers from the programming languages research literature, so having taken CMSC 631 (or taking it concurrently) will be helpful. That said, we will review programming languages concepts crucial for understanding particular papers prior to reading them. Contact the instructor if in doubt.

Grading: Graded work is as follows:

Paper reviews (comments) and class participation: Students will be required to submit an insightful comment or question about each paper by 9am the day of class. Insightful comments are not redundant with prior comments, so consider starting early, or if late, comment on comments. Good questions can point out things not made clear in the paper. Paper comments are generally given scores of 0, for missing or showing no evidence of having read the paper, 1, for minimal effort or a not-insightful summary, and 2, for actively insightful. There is a sweet spot of comment length that approximates a paragraph: one or two sentences is too short to develop an idea, three or four paragraphs is too long to describe a coherent idea well.

Here is some useful advice about how to read papers. Once you get in the groove, you should expect to spend 1-3 hours per paper (you do not need to understand every detail, especially for the longer papers).

Scribes: Each person will act as a scribe at several points during the semester, taking notes on the class discussion to be published on the course web site. The basic format for the notes should be the following:

In general, the summary should mention people by name, if possible, to give credit to those who made insightful comments.

Presentations: Students making presentations will be graded on the following criteria:

Remember that you will likely be able to explain more detail than you can hope to cover in a single lecture. This is one reason that it's hard work to prepare a good presentation: not only do you need to understand the paper, but you need to filter out the irrelevant details and amplify the key arguments. You'll probably have omit entire sections of the paper from your talk -- don't worry about it. Simply mimicking the structure of the paper ("regurgitating it") tends to produce a disconnected sequence of boring facts. A good talk should tell a story; every idea should be motivated, and all facts should fit together in a coherent picture. Telling such a story in a short time often requires creating your own explanations, motivation, and examples. I would recommend reading some advice by Simon Peyton Jones on giving good presentations.

Academic Dishonesty: The university policy on academic dishonesty is strictly followed. All graded materials (whether exams, summaries, presentations, or projects) must be strictly individual efforts. In the case of a group project or assignment, only collaborations within the group are permitted.