Industry Perspectives on Practical Problems in Computer Security
· For people interested in auditing, please read the auditor policy.
· We require a soft copy of your project proposal. If you have not submitted your project proposal, please e-mail to the course instructors. Any proposals submitted later than 11:59PM January 31st, 2009 will have marks deducted.
Instructors: Richard Reiner & David Lie
E-mail: ECE1724instructors@eecg.toronto.edu
Time: Mondays, 9-11
Location: BA2135
This course will survey some important practical problems in computer security that are not considered by end-users to be adequately addressed by currently available technologies. For each problem considered, we will review the variety of practical solutions currently available in the marketplace and the shortcomings of each, as well as considerations for improvement. Problems to be considered include:
· Phishing -- fraudulent acquisition of sensitive information and access through impersonation of a trusted entity, by means of email, instant messaging, and related communications channels. Current solutions to be discussed include: the use of SSL site certificates, user alerting based on site blacklisting, login personalization, takedown services, and others.
· SPAM -- unsolicited commercial email and instant messaging. Current solutions to be discussed include: SMTP blackhole lists, heuristic filters, grey listing, community-based filtering, spam traps, Bayesian filters, SPF/DomainKeys, sender-pay systems, receiver-reputation systems, and others.
· Web application protection -- injection attacks, XSS, XSRF, and related forms of attack upon browser-based applications. Current solutions to be discussed include: session state protection, user input to server output locking, application-model based filtering, and others.
· Spyware and malware -- protection of non-professionally-managed end-user computers against hostile executables distributed through exploitation of browser flaws as well as through intentional downloads. Current solutions to be discussed include file-signature based desktop agents, traffic-signature based network agents, browser sandboxing, and others
Auditor Policy: Auditors are permitted in this class but they must fulfill the following requirements:
· Auditors are responsible for reading all papers every week and participating in class discussions.
· Auditors are responsible for presenting papers from two weeks.
· Auditors are not responsible for a project.
This course will primarily be a seminar course. Each week students are expected to read the assigned readings and discuss them. Every week, general lecture style notes will be posted, and there will be an opportunity for students to ask questions, but no lectures will be given. There will also be a course project due at the end of the semester.
Students are expected to read the papers assigned each week and come to class prepared to discuss the papers. Each week a group of 2students will present their views of the papers. For each paper, one of the students will present pro’s for the paper, and the other will present con’s for the paper, and each student should be pro for at least one paper and con for at least one paper. A good paper should present a new and practical solution/technique so solve an important problem. It should also contain a critical evaluation of the merits of the idea, and clearly point out any flaws or shortcomings that could be solved in future work (of if they can be solved at all). Finally, the paper should clearly indicate past work in the area, and indicate how their solution improves on the existing solutions. For advice on giving presentations, refer here.
Each paper presentation should last approximately 20 minutes (for both presenters) and be in this general format:
1. Summary of the paper (~10 minutes): You will summarize the objective of the paper, the proposed technique and the results/contributions the authors have presented. If there is background required to understand the contents of the paper, the presenter should touch upon this as well. Either the pro or con presenter can handle this part.
2. The Pro presenter will explain what he/she thought was good about the paper, and argue for why the paper should have been accepted.
3. The Con presenter will then argue for why the paper should not have been accepted.
The presenters should meet before hand and discuss their views of the paper. During the presentation some good questions to answer (this list is neither exhaustive nor are they applicable in all cases):
· Are the authors working on a real problem?
· Did the authors miss any critical limitations in their paper? Was the way they presented their evaluation honest and fair?
· Did the evaluation test the right aspects of the solution? For example, did the presenters pick the right benchmark?
· Is the solution really novel? Did the authors identify all related work or did they miss work that is very similar to theirs. You should spend time doing an extended literature search for all papers (Google is your friend).
· Did the authors clearly differentiate between fundamental aspects of their design as opposed to artifacts of their implementation (that might not exist on another implementation of their design)?
· In your opinion, will the solution work as the authors indicated? Is it applicable in the general case or is it very specific to the cases they used in their evaluation?
· What questions does the paper leave unanswered? Is there future work or is the problem essentially solved by their solution? What improvements or additional information might you expect from the authors? Remember that researchers frequently construct prototypes, not products, so improvements should answer important questions, not be requests for functionality that is incomplete, but would be straightforward to add.
Students should work in groups of two or individually to do a research oriented course project. The project will either propose a solution to a security problem, or explore some aspect of computer security. The project will have three deliverables:
1.
Project Proposal
Students will hand in a project proposal in the second class. The proposal should be no more than 2 pages long. Students have a choice of two types of projects they may do:
Option
1: Research Project
Students selecting this option will hand in a research paper describing their project. The paper will be no longer than 12 pages. The most important goal of any research paper is to confer knowledge that the author learned by doing the research onto the reader. Thus, when writing the project research paper, students should focus on things they learned in the course of the project, that was not obvious to them before they embarked on the work. A good research paper should:
· Introduce and motivate the problem the paper attempts to solve.
· Provide a description of the proposed solution, as well as any interesting implementation details of the prototype (if one was built)
· Give a critical analysis of the strengths, weaknesses and limitations of their system, making sure to differentiate fundamental limitations of the solution from limitations specific to the prototype implementation
· Conclude with no more than 3 points describing the enlightening things that were learned from doing the research.
For more guidance, refer to information on writing research papers in the Course Resources Section.
Option 2: Industry-oriented Business Plan
As a more challenging (but optional) alternative for the final project, students may prepare a basic business plan for a technology startup venture based on the original technical innovation developed during the course, rather than a conventional research paper. A good business plan will be no more than 15 pages long, and will include, at a minimum, the following essential elements:
· Introduce and motivate the business problem the company will solve. This should be expressed in terms of the needs or problems faced by the company's future customers, rather than in purely technical terms -- i.e. it is necessary to demonstrate not only a new solution, but one that customers will want.
· Clearly define the target market (i.e. the potential customers): for example, banks and insurance companies, or small businesses, or consumers, etc.
· Provide a description of the proposed solution, as well as any interesting implementation details of the prototype (if one was built).
· Give a critical analysis of the strengths, weaknesses and limitations of the system, making sure to differentiate fundamental limitations of the solution from limitations specific to the prototype implementation
· Compare and contrast the strengths and weaknesses proposed system with all major commercially available alternatives, clearly demonstrating its advantages and why customers will prefer it
· Describe the business model to be used in taking the solution to market (e.g. a hosted solution (SaaS) sold by annual subscription, or onsite enterprise software with a conventional direct sales model and perpetual licensing, or open source software with paid support, etc.)
· Please refer to these links for more information on how to construct a successful business plan.
For either option, the 2-page project proposal turned in at the second class should:
· Introduce and motivate the problem they are going to attempt to solve or what previously unanswered question they are going to try and answer.
· Give an outline of the proposed solution.
· Provide a list of related work and an explanation of how the advantage they believe their proposal will have over existing solutions
The instructors will meet with students as necessary to discuss their proposals. The proposals will then be made available to other students the class via this webpage.
2.
Project Midterm Update and Presentation
Approximately midway through the course, students will also provide a written report no longer than 3 pages to the instructor summarizing their progress so far. A class will be set aside for groups to make an oral presentations to the class explaining their project and progress made up to that point. They will highlight interesting problems they have had and outline their plans for the remainder of the semester. The class should comment on the project and try to give advice. For advice on giving presentations, refer here
3.
Project Research Paper and Presentation
At the last class session, students will hand in their final project papers (research paper or business plan), and will present their work to the class.
Note that a few of the links for readings below require user registration (free) before downloading.
|
Date |
Topic |
Readings |
Presenters |
Project Deadlines |
|
Jan
12 |
|
|
|
|
|
Jan
19 |
|
|
|
|
|
Jan
26 |
Web Application Security |
1. Adam
Barth, Collin Jackson, and John C. Mitchell. Securing
Frame Communication in Browsers 2. Ofer Maor. SQL
Injection Signatures Evasion. 3. Kevin Fu, Emil Sit,
Kendra Smith, Nick Feamster. Dos and Don'ts of
Client Authentication on the Web |
Ekin
Akkus Tony
Chau |
Project Proposal |
|
Feb
2 |
Host
Administration and Configuration Issues |
1. Helen J. Wang, John Platt, Yu Chen, Ruyun Zhang, and
Yi-Min Wang. Automatic
Misconfiguration Troubleshooting with PeerPressure 2.
Brian Guild, Heather DalleTezze and Mounil Patel. Automating
Security Configuration Management: Calculating a Real ROI |
Ekin Akkus Lyndon Carvalho |
|
|
Feb
9 |
User Authentication |
1a. OpenID
Foundation. OpenID
Authentication 2.0 Specification 1b. Stefan
Brand. The
Problem(s) with OpenID. If not working here is an alternate link. 2. Blake Ross, Collin Jackson, Nicholas
Miyake, Dan Boneh and John C. Mitchell. Stronger Password
Authentication Using Browser Extensions. |
Pouya
Alagheband Amin
Tootoonchian |
|
|
Feb
16 |
Reading
Week: No Class |
|||
|
Feb
23 |
Malware, Viruses and Rootkits |
1.
Carey Nachenberg. Computer
Virus-Antivirus Coevolution. 2.
Carsten Willems, Thorsten Holz, and Felix Freiling, Toward
Automated Dynamic Malware Analysis Using CWSandbox. |
Sergio
Valle Zoe
Chow |
|
|
Mar
2 |
Student
Midterm Presentations |
|
|
Project
Midterm Evaluation |
|
Mar
9 |
E-mail and Messaging Security, Key management and
Cryptography |
1. Alma Whitten & J.D. Tygar . Why Johnny can't encrypt: a
usability evaluation of PGP 5.0. 2a. Voltage
Security. The
Identity-Based Encryption Advantage 2b. Voltage
Security. Email
Security - The IBE Architectural Advantage 2c. Section
"PKI vs. non-standards based solutions" on page 20 of Lance Hooper.
Email
Data Loss - A Key Information Security Risk |
Amin Tootoonchian Myrto Papadopoulou |
|
|
Mar
16 |
Intrusion
Detection/Prevention Systems and Firewalls |
1a. Palo Alto Networks. Next Generation Firewalls: Restoring
Effectiveness Through Application Visibility and Control 1b. Palo Alto Networks. The
Application Usage and Risk Report: An Analysis of End User Application Trends
in the Enterprise 1c. Palo Alto Networks, Reducing
Costs With Next Generation Firewalls 2. Sumeet Singh, Cristian Estan, George Varghese and Stefan Savage. Automated
Worm Fingerprinting. |
Maxim Siniavine Tony Chau Myrto
Papadopoulou |
|
|
Mar
23 |
Spam Detection and Filtering |
1. Meng Weng Wong
and Wayne Schlitt. SPF protocol
specification 2. Loder, Van
Alstyne, & Wash. Information
Asymmetry and Thwarting Spam 3. M.
Sahami, S. Dumais, D. Heckerman, E. Horvitz (1998). A
Bayesian approach to filtering junk e-mail |
Sergio
Valle Pouya
Alagheband
|
|
|
Mar
30 |
Phishing |
1a. Gervase Markham. Phishing -
Browser-based Defences 1b. Garrett Casto, Oliver Fisher, Raphaël Moll, Marria Nazif, and Dan
Born. Google
Safe Browsing Protocolv2Spec 2. Finn and Jakobsson.
Designing
and Conducting Phishing Experiments. |
Zoe Chow Maxim Siniavine |
|
|
Apr
6 |
Guest Lecturer from Industry |
|
|
|
|
Apr
13 |
Student
Final Presentations |
|
|
Project
Final Presentations |
·
How
(and How Not) to Write a Good Systems Paper
·
Eurosys 2006 Authoring Workshop
· Writing Systems and Networking Articles
· A good starting point: Brad Feld's Business Plan series
· A good outline of issues to consider in the business plan: Sequoia Capital
· A useful worksheet for developing content for the business plan project proposal: UCF Venture Lab
· A business plan template that can optionally be used (note that this contains several sections than are not required for this course assignment): UCF Venture Lab