For CSE 484 this year, we have switched from the blog format to the forum format. The course website is online at http://www.cs.washington.edu/education/courses/484/10wi/. This year’s forum is online at https://catalysttools.washington.edu/gopost/board/kohno/14597/. We switched from the blog format to the forum format because forums seem to provide a better opportunity for interactive discussions within the course.
EDIT: It appears that I goofed with the “more” tag when I first posted this, so I’ve included the rest of the article below.
Since the days of waking up at 5am to watch the Tour de France live with my dad at eight years old, I’ve been a big fan of bikes. I’ve since grown to love riding them, and spent several years as an avid road racer. While I’m somewhat of an anomaly, many of you also rely on cycling for transportation to class, to work, and elsewhere. Unlike cars, which are just slightly harder to steal, bikes are the candy-from-a-baby in the world of theft. One magazine article I read several years ago had a “professional bike thief” (probably a security professional who learned methods of theft in his research) attempt to steal a bike secured by one each of every available bike lock on the market at the time. In public. The result? All but a single lock could be circumvented so quickly that nobody in the area even noticed that it was not unlocked by normal means.
I have to say, I am particularly bitter about bike security. A few years ago I was living in Stevens Court with a few friends. A past summer job at Gregg’s Greenlake Cycles had yielded an absurdly cheap employee purchase of a Lemond Tourmalet, a very nice road bike. I wasn’t using it to commute to school (who locks up a bike like that around the Ave?), but I did have it in our apartment so I could go riding. One day I came home and it had been stolen from my living room. My roommates had left the front windows wide open and the door unlocked. Go go speed racer, go.
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:
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.
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.
University of Washington CSE PhD student Dan Halperin et al.‘s paper on the security and privacy for pacemakers and implantable defibrillators just received the Best Paper Award at the annual IEEE Symposium on Security and Privacy (a.k.a. the “Oakland” conference).
Dan and the rest of the team from UW, UMass Amherst, and Harvard Medical School found that an implantable cardioverter defibrillator can leak private information and can allow unauthorized parties to modify settings that control, among other things, shock therapies.
You can read Dan’s full paper and the FAQ, as well as his earlier work on the topic of medical device security. You can also read summaries of Dan’s work in The New York Times, the Wall Street Journal, Reuters, and the Associated Press. Bruce Schneier also provides excellent commentary.
Congratulations Dan!
Have a great spring break everyone!
To readers of this blog: Please expect low activity for a while. The University of Washington is on the quarter system, and our quarter just ended. Everyone in the class is, of course, encouraged to still contribute articles to this blog. And we’ll continue using this blog (or more sophisticated forum environments) in future courses. Stay tuned for more information 🙂 .
Hey everyone. I found a website where you can try to use various ways to hack through levels of password. I think this is a fun way to get in touch with our security mindsets and see how far you can go. I wish everyone good luck 🙂
http://hackerskills.com/
On Thursday, Apple happily unveiled its plan for third party support of native iPhone applications. The plan involves an application development and distribution pipeline including an iPhone SDK, a suite of IDE tools, and a sales and distribution plan through the new iPhone “App Store”. Apple is restricting the distribution of 3rd party applications through their app store by requiring an iPhone developer account. There will be no other supported way to get 3rd party iPhone applications onto the iPhone. Apple has also made the claim that no malicious, pornographic, or software with security vulnerabilities will be distributed through their store.
(Read on …)
Michael Levine provided this example CSE 490K Security Review.
John Kurkowski provided this example CSE 490K Security Review.
Here’s another example CSE 490K Security Review.