18732 Secure Software Systems

Instructor	Dawn Song
Course Home	http://www.ece.cmu.edu/~dawnsong/teaching/f05
Location	PH 125C
Meeting Times	Monday & Wednesday, 1:00-2:20PM (Note that class starts on Sep 12)

Instructor	TA
Dawn Song CIC 2122 http://www.ece.cmu.edu/~dawnsong	David Brumley James Newsome

Email address	Purpose
18732-f05-general@lists.andrew.cmu.edu	Questions about subject matter, course policy, grading, etc. (Also see the class discussion board, on blackboard).
18732-f05-summaries@lists.andrew.cmu.edu	Submit reading summaries here.
18732-f05-scribenotes@lists.andrew.cmu.edu	Submit scribe notes here.
18732-f05-project@lists.andrew.cmu.edu	Submit project proposals, milestones, and papers here.

Prerequisites:

The prerequisites of this class include 18730 (Introduction to Computer Security), an undergraduate Operating System class, proficient programming in C and Java, and familarity with assembly language.

Topics Covered in Class:

Software vulnerabilities: study the causes and manifestations of different forms of vulnerabilities, including language dependent vulnerabilities (buffer overrun, format string vulnerabilities, etc.), language independent vulnerabilities (race conditions, concurrency vulnerabilities, privilege control, etc.), and viruses, etc.

Software analysis, testing, and verification: study the general methodology and specific techniques for analyzing software for vulnerabilities, testing programs for bugs, and verifying correctness of code. Techniques covered include static analysis, high-coverage testing, fault injection, model checking, and theorem proving. We'll survey a set of existing tools as well as the underlying techniques.

Software transformation: study various software tranformation techniques for different purposes, including worm/virus morphing and software watermarking.

Secure software engineering practices and system evaluation: study security issues in software lifecycle including design, implementation, evaluation, patching, etc.

Secure operating systems & platforms: study foundations of secure OS, attacks & defenses, fault isolation, sandboxing and confinement, Virtual machine monitors, runtime monitoring, NGSCB, TCG, SE Linux, .net

Other topics: web security, Java security, mobile code securtiy, storage systems and database security, DRM

Class Format:

Each class will involve lecturing and some discussions on related topics. 1 to 3 research papers will be assigned as reading requirements for each class. Reading assignments will be posted to the class web site several days before the class. Students must read the assigned papers before each class and write a short summary to be turned in electronically before class. The summaries should be sent to 18732-f05-summaries@lists.andrew.cmu.edu in plain text format (no attachment). Each summary should contain a description of the technical approach in the paper, three technical points that you learned from the paper, and three most significant flaws that you discovered in the paper.

Grading:

50%	Final project	Each group needs to implement and demonstrate a tool that can assist in improving software system security. Each group needs to write a project report and give an in-class presentation.
15%	Midterm	There will be a midterm exam.
10%	Paper summaries and class participation	This portion is for paper summaries and class participation. Students must write a short summary for every paper assigned to the class. Summaries will be chosen randomly to be graded. All students should participate in class discussions.
25%	Homework/Lab	There will be several homeworks/lab assignments.

Format Requirements for Project Report

The project report should be written in LaTex.

Template for the project report
You should write your contents in a separate file and include it in project.tex using the "\input{your-flie-name}" line. The bibliography should be included in the .bib tex file. If you are not familiar with LaTex, you may also use Lyx at http://www.lyx.org.

Requirements for Scribe Notes

The scribe notes should be written in LaTex, using the template provided on blackboard. You should write your contents in a separate file (name it by the date) and include it in scribe.tex using the "\input{your-file-name}" line. For example, the scribe for lecture on Sep 14 should be named 0914.tex. The new bibtex entries should be included in a new .bib file; e.g., 0914.bib in the above example. The new figures should be named using the date as prefix as well; e.g., 0914-1.eps in the above example.

Submission guidlines:

The first draft of the scribe notes should be submitted one week after the lecture in class; the submission should be two hard copies in class as well as an electronic submission of the .pdf file to the scribenotes mailing list.
Students will receive feedback on their first draft of the scribe notes. After receiving feedback on the scribe notes, the scribes should incorporate the feedback and revise the scribe notes. The final draft should be submitted no later than 2 weeks after the initial lecture for the scribe notes. The submission should be two hard copies in class as well as an electronic submission. The electronic submission should include a tarball of the new .tex file and .bib file and any other new files for figures.

Resources:

Information about the class will be available at http://www.ece.cmu.edu/~dawnsong/teaching/f05. Course information, announcements, and reading assignments will be posted to this site. We will also be using the CMU Blackboard site for this course. To access the site, go to http://www.cmu.edu/blackboard and log in. If you are enrolled in the course, it will appear under my courses.

If you have a question about the course, including course logistics or material we have covered, please post it to the Discussion Board. It's on the course blackboard site, under Communications. You may also send mail to 18732-f05-general@lists.andew.cmu.edu.

Warning

We may discuss vulnerabilities in widely-deployed computer systems in class. This is not intended as an invitation to go exploit those vulnerabilities. CMU's policy (and my policy) on this should be clear: you may not break into machines that are not your own; you may not attempt to attack or subvert system security. Breaking into other people's systems is inappropriate, and the existence of a security hole is no excuse.