UW Computer Security Research and Course Blog

Every week you must submit one high-quality, thoughtful, and well-formulated story or comment to this blog. You should also read this blog regularly. We may discuss aspects of this blog in class or pull from this blog for the midterm or final exams.

The primary goal of this blog is to have you constantly think about security when you read the news or hear about new products. I.e., the goal of this blog is to help you develop the security mindset and become mature security thinkers. This blog will also give you an opportunity to exercise your writing and critical thinking skills in a cooperative learning environment. Through this blog we will also discuss some of the “bigger picture” issues surrounding computer security — issues ranging from ethics to politics to accessibility.

You may contribute several types of stories (articles) for CSE 484 (in addition to comments on existing blog entries), including: current event articles and security reviews. You should submit one article or thoughtful comment for each week of the 10-week lecture period of the course (where a week is defined as Monday through Sunday). Within the first five weeks of the course you must submit at least one current events article and one security review. You must also submit at least one current events article and one security review within the last five weeks of this course.

Current event articles. Current events articles should be short, concise, very thoughtful, and well-written. Please remember that your fellow students, as well as the general public, will be able to read your article. Your goal should be to write an article that will help your fellow students and other readers learn about and understand the computer security field.

Your article should: (1) summarize the current event; (2) discuss why the current event arose; (3) reflect on what could have been done different prior to the event arising (to perhaps prevent, deter, or change the consequences of the event ); (4) describe the broader issues surrounding the current event (e.g., ethical issues, societal issues); (5) propose possible reactions to the current event (e.g., how the public, policy makers, corporations, the media, or others should respond).

You should tag your current events articles under “Current Events” category. If you don’t do this, you may not get credit for your contribution. You should also select any other relevant categories.

Security reviews. Your goal with the security review articles is to evaluate the potential security and privacy issues with new technologies, evaluate the severity of those issues, and discuss how those technologies might address those security and privacy issues. These articles must be tagged under the “security review” category. These articles should reflect deeply on the technology that you’re discussing, and should therefore be significantly longer than your current events articles.

It’s OK if two students review the same technology, say the Miracle Foo. But if you’re the second reviewer of the Miracle Foo, you need to: (1) explicitly reference the earlier articles; (2) provide new technical contribution; (3) don’t waste space repeating what the previous review said. (3) is important since you are all required read this blog, and it’s not fair to ask your fellow students to spend time re-reading previously-posted material. For (2), new technical contributions might include: a new perspective on the risks; a new potential attack vector; or a new defensive mechanism.

Each security review should contain:

• Summary of the technology that you’re evaluating. You may choose to evaluate a specific product (like the Miracle Foo) or a class of products with some common goal (like the set of all implantable medical devices). This summary should be at a high level, around one or two paragraphs in length. State the aspects of the technology that are relevant to your observations below. If you need to make assumptions about a product, then it is extremely important that you state what those assumptions are. To elaborate on the latter, if you end up making assumptions about a product like the Miracle Foo, then you are not studying the Miracle Foo but “something like the Miracle Foo,” and you need to make that extremely clear in your review.
• State at least two assets and security goals. Please explain why the security goal is important. This should be around one or two sentences per asset/goal.
• State at least two potential adversaries and threats. You should have around one or two sentences per adversary/threat.
• State at least two potential weaknesses. Again, justify your answer using one or two sentences per weakness.
• State potential defenses. Describe potential defenses that the system could use or might already be using to address your potential weaknesses above.
• Evaluate the risks associated with the assets, threats, and potential weaknesses that you describe. Also discuss relevant “bigger picture” issues (ethics, likelihood that the technology will evolve, and so on).  (Update on Jan 10, 2008:  Being qualitative is fine; you don’t need to be “formal” in you risk analysis.)
• Conclusions. Give some conclusions based on your discussions above. In your conclusions you should reflect thoughtfully on your results above.

Comments. You may also comment on the articles of others. Your comments should be thoughtful reflections on the original article and earlier comments. One- or two-liners are not sufficient. You might draw in other examples to support the original article’s thesis, and then explain why these are good examples. Or you might give several concrete counter examples, and explain why they are counter examples. You might also raise an issue that the original article didn’t fully address.

Anything else. You are, of course, welcome to submit other types of articles. As always, your articles must be thoughtful and well-written. If you’re trying to make an argument, make sure that your argument is clear and convincing.

Breaking up long articles. If your article is particularly long, then please use the “more” button at the top of the visual editor to break long posts into a short abstract by the full details of your article. Make sure your abstract summarizes all the key points. (E.g., for a security review, your abstract should briefly describe the technology, the risks, whether there exist natural mitigation mechanisms, and how likely it would be to get those mitigation mechanisms adopted).

Modifications by course staff. The course staff reserves the right to modify postings, but we will try to do so rarely and will always make it clear that the post is modified. For example, if we notice an entry describing a zero-day exploit, then we may remove the discussion of that exploit first and then work with the article’s author to revise the post.