• Home
• Assignments
• Project
• Schedule
• Syllabus
• Moodle

• Use computer systems in a secure manner.
• Recognize common vulnerabilities in protocols, designs, and programs.
• Eliminate or minimize the impact of these vulnerabilities.
• Apply the principal security standards in use today to design and build secure applications.
• Apply principles, concepts, and tools from security to your own research.

Prerequisites:
The official prerequisite for this course is an undergraduate-level course in operating systems: in the Minnesota undergraduate program, CSci 4061. We don't recommend trying to take 4061 during the same semester as 5271, because the most important connection is an application to the first half of 5271 of material that is not usually taught until near the end of 4061. An undergraduate course in networking, such as Minnesota's CSci 4211, is also helpful as background for the section of the course on network security. The portions of the course that deal with low-level attacks and defenses on software (buffer overflows, etc.), depend on some familiarity with assembly language and how C programs are compiled. These are covered in CSci 2021, which is transitively a prerequisite for 4061, but students sometimes find themselves a bit rusty when the topics return in 5271.

As in any graduate-level course, we also expect students to have a broad familiarity with standard topics in a computer science as you would get from an undergraduate CS major. You should be resourceful: if a topic comes up in lecture that you aren't familiar with, you should have enough of an orientation to know where to look for more information on your own (from a textbook, from a manual, from Wikipedia, etc.).

You also need to be comfortable writing and debugging medium-sized programs independently. The largest portion of the programming will be system-level programming in C for Unix-style systems (mostly Linux), which is another reason 4061 is an important prerequisite. You should also be able to write shell scripts and use a Unix-compatible scripting language such as Perl, Python, or Ruby. You don't have to already be an expert with all of these tools, but you need to be prepared to fill in gaps in your knowledge as you go.

Reading Schedule:
The course web site will have a schedule of the topics that will be covered in each lecture, along with readings for each topic. You will get the most out of the lecture by reading the materials before coming to class. The material in the readings and the materials in lectures will not match exactly: while the most important material will appear in both, some points may appear only in the reading or only in the lecture, and they're all fair game to appear on exams. We'll post the slides from lectures on the web site after class, but reviewing the slides is intended to supplement, not replace, attending lecture.

Textbooks:
Because the area of computer security is changing quickly, it is hard to produce a good textbook; there's no single book that covers all the material in our class.

The book we'll be making the most extensive use of is Ross Anderson's Security Engineering, Second Edition (John Wiley & Sons, 2008). This is a great book for understanding the adversarial perspective in security; it covers many of the course's main topics at a high level, as well as drawing on examples of security thinking outside strictly computer applications. It's also a lot more fun to read than the average CS textbook. However it doesn't go into as much technical detail as we will in many areas. It should be available to buy in the campus bookstore, or various places online. But if you don't want a physical book, all the chapters are also available online from the author's home page. Also, the campus libraries have acquired ebook access to an HTML edition of the book through Books24x7. You can find a link through the library's course reserves portal, or here. Note however that one reason to buy a paper copy of the textbook is that you can bring a paper copy to exams, but you're not allowed to use electronics during exams. The first edition is significantly different and the chapter numbering is different, so be careful about which edition you get.

Including chapters from Anderson's textbook as discussed in the previous paragraph, all the class readings are available to download and/or read online. Many are public downloads; a few, such as some academic papers, are licensed to the University via the libraries so you can access them directly if you're coming from a campus IP address, or from off campus you can use the library's proxy service and bookmarklet. Some other online resources will be mentioned in lecture notes, assignments, or on the class forum, and of course there's lots of information, some of it good, available online that you can find yourself.

If you're looking for more specific textbook-style information about security, here are some additional recommendations primarly from past years' course staff:

• For software security, 24 Deadly Sins of Software Security (Bookfinder) is the updated edition of 19 Deadly Sins of Software Security. The sins that are most important for us are among the 19. This provides more explanation and background on low-level code and web security practices, and how to code defensively to avoid them.
• For network security, we'll be reading chapters from Firewalls and Internet Security, second edition (2003) (Bookfinder), so if you find them useful you might consider the rest of the book. Even the second edition is starting to get a bit old, though, so don't look to this for all the latest topics. (The first edition is even older, but it does have the advantage of being completely available online.)
• A good reference for cryptography at the application level we'll consider it is Cryptography Engineering by Ferguson, Schneier, and Kohno (Wiley, 2010) (Bookfinder). (The previous edition, still not too out-of-date for our purposes, was Practical Cryptography by Schneier and Ferguson (Wiley, 2003) (Bookfinder).) If you're interested in more about cryptography you should look into taking 5471, which is a course-length treatment that goes more into the design of cryptographic primitives, the theory behind them, and more advanced constructions. Good references for that greater level of detail include Manezes, Van Oorschot, and Vanstone's Handbook of Applied Cryptography, this set of lecture notes by Goldwasser and Bellare, or Katz and Lindell's textbook Introduction to Modern Cryptography.

Grading:
Grading for this course will be based on the following components:

• Exercises: Corresponding roughly to 5 topic areas in the semester there will 5 sets of "exercises", written assignments that you should be able to complete without much programming (they're also similar to the longer-answer questions on the exams). The questions and their due dates will be posted on the course web site. Students may work individually or in groups of 2 or 3 on the exercises. Be aware that even if you work in a group, you are still also individually responsible what the group turns in: it's not an excuse that someone else in the group "was supposed to turn in the assignment" and didn't, or "didn't finish part c". Type up your exercise solutions and submit them electronically, in either plain-text or PDF format, via the Moodle.

  Late submissions: exercises turned in between 1 second late and 23 hours, 59 minutes and 59 seconds late are worth up to 75% of their original value. Continuing with that pattern, 24:00:00 to 47:59:59 late is worth 50%, 48:00:00 to 71:59:59 is worth 25%, and 72 hours or more late receive no credit.

• Hands-on Assignments: Corresponding to the two major topic divisions (software and system security; and network and web security) there will be two large hands-on implementation assignments. Like the exercises these will be posted with due dates on the web site, and turned in via the Moodle. You may also work in groups of up to 3 students on the hands-on assignments, and the same warning about collective responsibility applies. However we encourage you more strongly to work in groups on the hands-on assignments: they can be a lot of work especially for a student working individually. The hands-on assignments will particularly call on your skills in C programming and the Unix shell environment.

  Late submissions: hands-on assignments turned in between 1 second late and 23 hours, 59 minutes and 59 seconds late are worth up to 75% of their original value. Continuing with that pattern, 24:00:00 to 47:59:59 late is worth 50%, 48:00:00 to 71:59:59 is worth 25%, and 72 hours or more late receive no credit.

• Exams: There will be an open-book, open-notes midterm exam held during class on Monday, October 16th, and an open-book, open-notes final exam held on Monday, December 18th from 8am to 10am. Both exams will have a similar format, mixing multiple-choice (or matching, true-false, etc.) questions with written-answer questions much like the exercises.
• Course Project: Students will work in groups of 3-6 over the course of the semester to complete an original research project related to computer security; most projects will be extend or attack the results of another recently-published paper. The project grade will be given primarily (70%) based on a final written report of 8-12 pages in conference paper format; one student from each group must also present the work in class (10%), and group members must attend a series of three mandatory progress meetings with the instructor over the semester. A full description of the requirements and grading of the project is on a separate page labeled "Project"; those details are just as important as the rest of the syllabus and students are equally responsible for understanding and complying with them.

Final scores will be computed as a weighted average of the exercises score (10%), hands-on assignments score (15%), midterm score (20%), final exam score (25%), and project score (30%). Letter grades will be assigned using the following scale:

Collaboration and External Sources:

Discussing the course content with other students can be a very useful part of your learning experience: that is part of why we encourage/require you to collaborate on the exercises, homeworks, and course project. However it is up to you to structure that collaboration for the best results and to maximize everyone's learning. For instance when working on an exercise set, if you split up the questions between the group members, you would still be advised to get together at the end and discuss your answers before turning them in. Of course this will help you in the situation where one group member didn't do their part, but you'll also want to understand the idea behind each answer in case, say, something similar were to show up on an exam. Hard questions, and in particular some parts of the homeworks that require creative attacks, will also benefit from closer collaborations and discussions.

On the other hand, we ask that you be more circumspect in discussing exercises and homeworks with students outside your group, so that every group has the chance to grapple with the challenges on their own. The class isn't graded on a curve, so you aren't competing with other groups: their failure will not improve your grade, and we'd like to maintain a generally friendly atmosphere. For instance it's okay to discuss ideas from the course at a general level that might apply to a homework (e.g., the concept of a buffer-overflow attack), or to help another group with a technical problem unrelated to the project itself ("I can't get my VM to boot"). But you should avoid giving specific suggestions that another group could use in place of figuring something out on their own ("you can overflow buffer foo by passing a 200-byte string to function bar"). And sharing code or prose that would be given as an answer to an assignment question is of course never okay.

Many assignments in the class will allow or even encourage the use of resources beyond the course readings and lecture notes, such as you might find in the library or on the Internet. However it is an important academic value, which we enforce rigorously in this class, that it is never acceptable to use another's work without properly acknowledging it. In exercises and homeworks, you should acknowledge any external sources of inspiration or code directly in your answer; in the course project report, you should acknowledge resources and related work in the same was as you would in an academic paper. Failure to do so constitutes plagiarism.

Academic Integrity Policies: By the nature of this class, we will often discuss techniques that could be used to compromise the security of certain computer systems. However, IT IS VERY IMPORTANT THAT YOU NEVER APPLY THESE TECHNIQUES TO A COMPUTER WITHOUT THE PERMISSION OF THE COMPUTER'S OWNER. In particular you should never attempt to attack the security of computers that belong to CSE Labs, the department, the University, or an unsuspecting classmate. If we learn that a student has unethically exploited a vulnerability discussed in class, THAT STUDENT WILL FAIL. This is in addition to any University-level, department-level or legal penalties such an action may be subject to.

More generally, you are expected to do your own academic work and cite sources as appropriate. Failing to do so is scholastic dishonesty. Scholastic dishonesty includes, but is not limited to: plagiarizing; cheating on assignments or examinations; engaging in unauthorized collaboration on academic work; taking, acquiring, or using test materials without faculty permission; submitting false or incomplete records of academic achievement; acting alone or in cooperation with another to falsify records or to obtain dishonestly grades, honors, awards, or professional endorsement; altering, forging, or misusing a University academic record; or fabricating or falsifying data, research procedures, or data analysis. A student found responsible for scholastic dishonesty will at a minimum receive a grade of 0 for the assignment in question and be reported to the campus-wide Office for Community Standards (OCS). More serious offenses will receive a grade of F (or N) for the course and be subject to additional sanctions from the University. You should also read this page about academic conduct in computer science.

Other Applicable Policies: There are a number of other University-wide policies that apply to this course which you should be familiar with. This list is an abridged summary of longer policies which you can find linked from a University-wide page:

• Students are required to abide by the Student Conduct Code, which among other things prohibits disruptive classroom conduct.
• Personal electronic devices should be used with caution in the classroom lest they interfere with your or other students' learning.
• Students will not be penalized for absence during the semester due to unavoidable or legitimate circumstances. Such circumstances include verified illness, participation in intercollegiate athletic events, subpoenas, jury duty, military service, bereavement, and religious observances. The requirement of verification for absences due to illness is waived for a single episode absence that did not require professional treatment, and did not lead to missing an important in-class event such as an exam.
• The University considers that accepting compensation for taking and distributing classroom notes violates shared norms and standards of the academic community.
• Sexual harassment is not acceptable in the University setting.
• The University provides equal access to and opportunity in its programs and facilities, without regard to race, color, creed, religion, national origin, gender, age, marital status, disability, public assistance status, veteran status, sexual orientation, gender identity, or gender expression.
• The University of Minnesota is committed to providing equitable access to learning opportunities for all students, including making reasonable accommodations. If you have, or think you may have, a disability that might affect your participation in class please contact the Disability Resources Center. If you are registered with the DRC and have a current letter requesting reasonable accommodations, please contact your instructor as early in the semester as possible to discuss how the accommodations will be applied in the course.
• As a student you may experience a range of mental health concerns or stressful events which may interfere with learning. You can learn more about the broad range of confidential mental health services available on campus via the Student Mental Health website.
• Within the scope and content of the course as defined by the instructor, academic freedom includes the freedom to discuss relevant matters in the classroom and conduct relevant research. Students are free to take reasoned exception to the views offered in any course of study and to reserve judgment about matters of opinion, but they are responsible for learning the content of any course of study for which they are enrolled. (Adapted from The AAUP Joint Statement on Rights and Freedoms of Students.)

(This syllabus is based in part on documents used in previous editions of 5271 and written by Prof. Nick Hopper.)