Welcome to 2009 and another rendition of CSE 484 / CSE M 584, the University of Washington undergraduate and 5-th year Masters computer security course. Please familiarize yourself with this post from last year; it explains why we have this blog. In short, the blog is designed to be a vehicle for you to proactively develop “The Security Mindset.” You will be posting blog entries analyzing the security of existing products and reflecting on current events, and you will be using the blog’s comment feature to engage in conversations with your fellow students.
They say that one of the best ways to learn a foreign language is to immerse yourself in it. If you want to learn French, move to France. This blog is designed to immerse you in the security culture and to force you to think about security on a regular basis, such as when you’re reading news articles, talking with friends about current events, or when you’re reading the description of a new product on Slashdot. Thinking about security will no longer be a chore relegated to the time you spend in lecture, on assigned readings, on textbook assignments, or on labs. You may even start thinking about security while you’re out walking your dog, in the shower, or at a movie. In short, you will be developing “The Security Mindset” and will start thinking like a seasoned security professional.
It is also extremely important for a computer security practitioner (and actually all computer scientists) to be aware of the broader contextual issues surrounding technology. Technologies don’t exist in isolation, rather they are but one small aspect of a larger ecosystem consisting of people, ethics, cultural differences, politics, law, and so on. This blog will give you an opportunity to discuss and explore these “bigger picture” issues as they relate to security. As an added bonus, this blog will also give you an opportunity to exercise your writing and critical thinking skills in a cooperative learning environment with your peers.
Course Blog Requirements. You should read this blog regularly. Within the first five weeks of the course you must submit at least one current events article and one security review (due Feb 6 at 11pm). You must also submit at least one current events article and one security review within the last five weeks of this course (due March 13 at 11pm). You must also post a blog comment for each week that you do not post a main current events or security review article (where each week “ends” on Fridays at 11pm). Hence, by the end of the class, you will have written at least 10 times in the blog (2 current events, 2 security reviews, and 6 comments). All your posts and comments should be high-quality, thoughtful, and well-formulated.
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 and how it fits into the broader context.
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 the “Current Events” category. You should also select any other relevant categories.
Your chosen current event should not be the same as a previous current event article on this blog.
There are some examples of past current event articles here. (You might have to scroll down a bit.)
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 articles 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).
- Conclusions. Give some conclusions based on your discussions above. In your conclusions you should reflect thoughtfully on your results above.
There are some excellent examples of past security reviews here. (The requirements for these past security reviews may, however, be different than the requirements for this version of the course. So please pay attention to the specific requirements for this version of the course.)
You should tag your current events articles under the “Security Reviews” category. You should also select any other relevant categories.
Blog comments. Your comment should be a thoughtful reflection 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.
Working with others. You may do your current event articles and security reviews in groups of up to two people.
Post early, post often. This year we are giving you significant flexibility in when you make your posts. But we encourage you to post early and post often.
You will receive extra credit for posting current events and security reviews early (but within the same 1/2 of the quarter). Each current event and each security review post is worth 12 points. If you submit your first security review in the 4th week of the quarter, it will get 1 extra credit point, if you submit it in the 3rd week of the quarter it will get 2 extra credit points, and so on. Your second security review must be submitted in the last 5 weeks of the course (this is what we meant by “within the same 1/2 of the quarter”); if you submit it in the 6th week, you will get 4 extra credit points, and so on. The same holds for the current event articles.
Of course, there’s another reason to post early: this course is quite demanding and we suspect you’ll only get busier as as the quarter progresses. Plus, remember that each current events article must discuss an event that was not previously discussed on the blog. This means that the earlier you post your current event article, the easier task you’ll have at finding an interesting event to discuss.
We will also give extra credit to those who actively use this blog to post extra articles or comments.
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).
How to submit. You should submit your current event articles and security reviews in two ways.
First, you should “publish” it on this blog.
Second, save a copy of your blog post in PDF form (e.g., print to PDF on a Mac) and upload the PDF to the course Catalyst submission system. If you work with someone else on your current events article or security review, then only one of you should upload the PDF to the course submission server. However, make sure everyone’s name is on the first page of the PDF. This process will facilitate our ability to grade the blog (e.g., batch printing of PDFs). You do not need to (and in fact should not) upload PDF copies of your blog comments to the Catalyst system, however.
Note that you should anticipate that it will take you a few minutes to generate the PDFs and that the blog post will only be considered on time for a week if the Catalyst PDF submission is on time. Please plan accordingly.
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.
Additional notes. We may discuss aspects of this blog in class or pull from this blog for the final exam or impromptu extra credit questions during the lectures.