CSE P590 (Winter 2007)

Computer Security


Security Reviews: Overview

In addition to learning technical aspects about computer security (like facts about access control or network security protocols), one of the most important things to learn from this course is the security mindset --- or how to think about security. As we will discuss in class, thinking about security issues is different from thinking about other issues like functionality or performance. Intuitively, since issues like functionality and performance are directly visible to developers and users, it is comparatively "easy" to think about these aspects of a system. But security? Unfortunately, the lack of security can easily be invisible to developers and users and anyone without the appropriate training.

This course is designed to teach you how to spot security issues. One way to develop the security mindset is to actively practice thinking about and discussing security issues. Therefore, in this course you will get the opportunity to analyze real products and to discuss your findings with your classmates. By the end of this course, when you see the announcement for a new product, you should be able to immediately start thinking about potential security issues. And, more importantly, when developing a new system of your own, you should be able to quickly spot potential security issues in the system's requirements or design, and know to pro-actively address those issues before the system is built. You will also understand how subtle security issues can be, and will realize that it may take a lot of work to uncover "all" of the major security issues affecting a system or proposed system.

Why is learning this mindset so important? We believe that the first step towards improving the security of a system is to know that there might be problems. Even if you eventually forget some of the technical aspects of this course (like the details of certain encryption modes), as long as you remember how to think about security at a high level and are aware of some low-level details, you can (and in fact probably should) still work with others to iron out the low-level details.

Structure

Over the course of the quarter you will: For each of the three reviews, you will: For the weeks that you do not present a review, you will: Before the first class, we will assign you to a group. (If you do not receive an email with your group assignment, please send us an email since we may not have your email address.) You group name will be either "Group A.n," "Group B.n," or "Group C.n," where n is a number. Your presentation days will be as follows: The reason for the ".n" in the group names is that sometimes in class we will ask you to form larger groups. For example, we may ask all the people in Groups A.1, B.3, and C.2 to meet together in class and discuss.

Finding Products to Review

When finding a product to review: One way to find candidate review subjects is by glancing at the new technologies discussed on Slashdot, Wired, Digg, etc. You might also find good review subjects by looking at the ads in the Sunday newspaper. We'll give you some example subjects during the first class session. After that, we'll occasionally post potential subjects to the class Wiki, and we encourage all of you to do the same.

What to Produce

Each written review should begin with a summary of the product that you are analyzing.

You should then discuss the potential security issues for the product. What should the security goals be? How might the product fail to meet those goals?

You should then include the results of your analysis. You may analyze the product at a high-level, and without specific knowledge of how the product operates. It is fine to speculate in your review. You should think of your product review as the first stage of a complete security evaluation, where your goal is to identify the issues that you would like to explore further. Of course, we will not be disappointed if you do actually find a real, exploitable security vulnerability -- but finding such an exploitable vulnerability is not a requirement.

Your in-class presentation should reflect your written report, with a brief summary of the product and then the results of your high-level analysis.


yoshi@cs.washington.edu