Complex systems, whether based on software, hardware or networks, are famously difficult to secure against malicious attack. Well-known security vulnerabilities are often discovered and re-discovered in newly deployed systems, even when countermeasures and methodologies exist to detect and avoid them. Consider, for example, the prevalence of software buffer overflows, poor default configurations, and static passwords found at the root of many recent security failures. Many of these vulnerabilities were originally discovered years ago, yet in practice software developers and system designers seem to be unable to guard against repeating them in new systems.
This seminar will focus on evaluating systems from the perspective of the attacker. Participants will apply expertise from their areas of specialization (programming languages, operating systems, networking, theory, hardware, etc) to find security weaknesses in real systems. We will study papers from the computing research and underground literature with the aim of developing methodologies for discovering hidden vulnerabilities. Projects will involve developing and applying an evaluation methodology against a security system (software, hardware or network), with the aim of either discovering a previously unknown exploitable flaw or increasing our confidence that no such flaws exist.
Graduate-level background in computer science and permission of instructor.
This course will be run as a research seminar, with much of the details of its content selected and presented by the participants. The main goal is for each participant to produce or make significant progress toward a publishable research result that will increase our understanding of how to identify (and avoid) security vulnerabilities. (A side effect of organizing the course this way is that the workload and time commitment here will probably be on the "high" side compared with typical graduate courses).
Your grade will be based on your project, your literature presentations and critiques, class participation, and a homework assignment.
Most of our meeting time will be spent discussing papers from the research and underground literature and presenting and evaluating student projects. We will also have occasional guest lectures and special topic presentations and discussions.
There will be one homework assignment, due at midnight on January 25th. It asks you to exploit and document one of the most common (and easily avoided) vulnerabilities found in deployed software. For details, see http://www.crypto.com/courses/spring04/cis700-03/homework.html.
Participants will select, present and critique papers, articles, and books from the computer science and underground/nontraditional literature. We will focus on material that describes an attack, countermeasure or case study from one of the topics listed below, but papers from other relevant areas are also possible. We will think about security broadly here, and will not limit our study to the computer security literature per se.
Each student selects and presents to the group two to four (depending on the number of participants) papers on attacks, countermeasures, or case studies. At least one of these should be a paper from the traditional computer science literature (defined here as research conferences and journals), and at least one should be from outside the traditional literature (underground publications, 'zines, books, etc). I will help with pointers, references and suggestions for appropriate papers.
Paper presentations will be scheduled throughout the semester based on the topic order listed below. The presenter will give a 15-20 minute lecture on the main contribution / result and then lead a group discussion of how the work might be applied or expanded in the context of attacks and countermeasures. In addition, for each paper, another participant will prepare a one page (two to four paragraph) summary and critique based on the paper and our class discussion, to be distributed before the the next meeting via the course mailing list.
(The exact number of papers each student will present and critique depends on the number of participants, but will be at least two and no more than four presentations, plus the same number of critiques).
To ensure good coverage of topic areas throughout the semester, you'll need to negotiate with me about your paper selections. We'll do this in two phases. Papers will be assigned FCFS, so it is to your advantage to act early.
January 19th (or sooner): Send me your first, second, and third choice papers from the computer science literature. (This means that you need to get to work quickly on surveying the literature).
January 26th (or sooner): Send me your first, second and third choice papers/books/articles from the underground/nontraditional literature.
Joint projects by small groups are permitted. Projects relying on collaboration with researchers not in the course may be possible, but must be discussed with me first and must identify clearly your individual contribution.
February 9th: Submit a draft project proposal that describes your methodology, the kinds of vulnerabilities it addresses, and a bibliography of other research on which it builds.
February 24th: Submit your final project proposal, including a test plan for evaluating the methodology and complete bibliography. Also at that time, be prepared to defend your proposal with a ten minute group presentation, followed by discussion and questions.
April 13th and 20th: Final project presentations will be held April 13 and 20, with a presentation and group discussion.
April 29th: Final project reports will be due April 29. This report should be in the form of a publishable conference or journal submission.
While you are encouraged to think broadly about security vulnerabilities, there is an ethical (and legal) difference between learning how to exploit weaknesses and actually exploiting them without authorization. All participants are expected to know, and respect, the letter and spirit of the law and to hold themselves to the highest standard of ethical behavior in this course. Needless to say, enrolling in this course does not constitute a license to violate the security of any systems, inside or outside the University, without authorization.
In particular, some security experiments, especially those involving self-propagating attacks (such as viruses and worms), can be difficult to contain within a laboratory environment. If there is any chance at all that your experimental work could interact with or disrupt "live" networks or systems, contact me in advance. The legal system has no sense of humor about "accidents" with security implications, however well intentioned.
These topics are approximate and depend on the interests of the participants. Other topics may be added as well. Paper presentations will occur in roughly the order below.
Home page: http://www.crypto.com
9 January 2004; revised 10 January 2004