CS1660 (formerly called CS166) is a course on computer systems security through a balanced mixture of theory and practice.

We’ll start out with building the foundations of security through an exploration of cryptography. From there, we’ll move to more complex, multi-faceted systems such as web applications, operating systems, and networks. Along the way, we’ll explore complementary topics such as authentication, physical security, social engineering, privacy, anonymity, usability, and the security of emergent systems such as blockchains and machine learning.

By learning about security through these multiple domains, you’ll concretely learn how various classes of attacks appear in a vast variety of scenarios and how they work in practice. You’ll also learn how to evaluate systems adversarially, from writing precise security analyses about subtle issues in protocols to discovering and exploiting vulnerabilities in concrete technical systems for yourself.

Through all of these activities, you’ll ultimately work to develop a specific kind of intuition—a “security mindset”—that will give you the knowledge, vocabulary, and confidence to critically analyze and effectively defend the software and systems you approach as a computer scientist even after the course.

We encourage you to take additional half-credit “lab”, called CS1620 (for undergraduates) or CS2660 (for master’s and graduate students). Senior undergraduates may use the lab portion to count for their capstone requirement.
Students taking the lab have the opportunity to work on advanced challenges that will provide you with a greater appreciation of systems security and the “security mindset” as a whole:

CS1620/CS2660 provides students with a deeper understanding of the material by doing advanced versions of the CS1660’s projects and advanced questions on the written assignments. These advanced versions focus on real-world skills: performing attacks that are more difficult and rely on less serious vulnerabilities, performing attacks against systems with more real-world constraints, and creating attacks that achieve a higher standard of quality than a mere proof of concept.

CS1620 vs. CS2660: Due to credit-counting logistics, the lab portion of the course has two different course numbers: CS1620 and CS2660. Undergraduate students wishing to do the half-credit lab should sign up for CS1620 in addition to CS1660. CS2660 combines both CS1660 and CS1620 in one, 2000-level course. If you are a graduate student (or an ScB student who has applied for the concurrent CS master's program), and wish to earn 2000-level credit for this course, you should sign up for CS2660 only. What’s the difference? Both CS1620 and CS2660 share the same extra course content, but only CS2660 counts for 2000-level credit. In course materials, we will refer to the lab portion simply as CS1620–this includes both CS1620 and CS2660 students.

How much work is the lab?: In previous years, students taking the lab report spending approximately 8–20 extra hours on each project throughout the semester, though they also note that the additional components are more front-loaded so the second half of the semester is much more flexible. (We anticipate that this will be the same this year.) You do not need any additional experience beyond the base prerequsites of the course to succeed with the lab-—anyone who feels comfortable taking CS1660 should also feel comfortable taking CS1620/CS2660, so long as you are comfortable with the extra time requirement. Note that students taking CS2660 are committed to completing the requirements for both the lab and main portion of the course–after the add/drop period ends, it is not possible for a CS2660 student to drop the lab portion and still get credit for CS1660 in the same semester.

How do I sign up?: If you are interested in the lab portion, undergraduates should register for CS1660 and CS1620 on CAB. Senior undergraduates are eligible to capstone with CS1620—-email the HTA list if you intend to have the lab count for your capstone credit. If you intend to take CS2660, please fill out this form and request an override code on CAB.

The waitlist closes at Friday, January 27, 2023 at 11:59pm EST.

Interested in taking the course? The course commonly fills up during pre-registration, but to have the best chances of getting a spot in the course, you should do the following:

• Register for the waitlist by filling out this form. We actually do read and evaluate the responses that are submitted, so if you have any particular reasons you want to take the course, do let us know!

• Add the course to your shopping cart. This will grant you access to EdStem and Gradescope.

• Read about the lab component of the course, and consider if you want to take it. If you’re interested in taking the lab, make sure to note that in the waitlist form! (If you already submitted the form, don’t worry, you can visit the link again to edit your response!)

• If possible, attend (in person or via Zoom) the first lecture on Thursday, January 26 or watch the recording as soon as is feasible.

Every day during shopping period, we will admit students from the waitlist, prioritizing those who were unable to register previously due to CAB issues, and students with strict program requirements or who are otherwise unable to take the course at another time. If you fall into one of these categories, please briefly state it on the form (please avoid email–it will take longer!). If you already responded and need to edit your response, you can do so by clicking the form link again.

While we cannot guarantee that all students on the waitlist will be able to take the course, all students who were registered for the waitlist in Spring 2018 were given an override code by the last day of shopping period; in Spring 2019, all students on the waitlist were given an override code by the 10th day of shopping period; in Spring 2020, all students on the waitlist were given an override by the 9th day of shopping period.

You should have an intro-sequence’s worth of programming experience (0160, 0180, or 0190) and have a good understanding of systems programming (0300, 0330, 1310, or 1330). This concretely means that:

• You should be comfortable writing programs and scripts in the language of your choice (such as Python, Ruby, Bash, Go, C++, etc.), be comfortable in a Unix command-line environment (running binaries, filesystem navigation, etc.) and using SSH with the Brown CS filesystem, have a basic understanding of systems programming concepts such as memory management and networking.
• You also should have heard of the terms “race condition”, “packet”, “TCP”, “UDP”, “buffer overflows”, and “DNS”. (If you forget what these are, don’t worry—we’ll describe them again when they come up in the latter half of the course.)
• You should also be at least somewhat comfortable (and very willing) to learn new programming languages and reading code in languages and programs that you’ve never used before. (You’ll get lots of practice with this in this course!)

If you don’t meet the official prerequisites but still want to take the course, please feel free to ask the instructors–we are happy to discuss your individual situation to determine if the course is right for you!

Your willingness to challenge yourself is perhaps the most important prerequsite for the course. Security can be frustrating at times, but the rewards are great. In exchange for engaging with some difficult intellectual challenges, you’ll have the opportunity to gain concrete insights about systems and security and become a better computer scientist along the way!

We will have live lecture on Tuesdays and Thursdays @ 1pm - 2:20pm ET in person at CIT 368 and on Zoom via this link. All lectures will be recorded and will be posted on Panopto following the lecture.
NOTE: We are encountering an issue with the recording for the first lecture. An update will be posted on Ed soon.

Attendance policy: Students are encouraged to attend lecture in-person or synchronously via Zoom, though this is not required. Attendance does not impact your course grade. Lecture may use TopHat questions to poll students during class–these are optional and are only used to gauge your understanding during class. TopHat responses have no impact on your course grade.

Asking Questions:: We encourage students to ask questions in class, either by raising your hand (either in person, or as a reaction or chat message in Zoom). If you are participating remotely, we will ask you to unmute and ask your question.

Recording Policy:: All lectures will be recorded. Recordings and any notes/slides from lecture will be made available within 24 hours of the lecture date in Panopto.
During shopping period, students who are not officially registered should have CSCI1660 in your primary cart on CAB in order to have access to Panopto.

The Collaboration Policy details the rules surrounding collaboration on all aspects of the course.

The most important points are as follows:

• Projects: Whenever you’re actively interacting with project systems, you must do so entirely independently. “Actively interacting” includes having the project systems (binary, website, etc.) within sight or interacting with them, exploring system source code, writing your deliverables (solutions, writeup, exploit code, video, etc.), and so on. You also may not share your deliverables with others, and you may not read others’ deliverables.

  That said, we allow discussion of projects with other students as long as no student in the discussion is actively interacting with the project systems. You should treat project-based discussions like going to TA hours—that is, focus on high-level hints, prodding questions, and occasional debugging help on narrowly scoped technical issues, but don’t give away full answers. Finally, when you talk to other students about projects, you must cite those students in your handin. See the Policy for more details.

• Homeworks: You’re permitted to (and encouraged to) discuss any aspect of the homework problems with other students currently in CS1660. In this course, the homework problems generally will require you to approach problems from different angles and are designed to encourage discussion amongst students.

  However, you must write your homework solutions entirely independently. You may not share your solutions with anyone (or read solutions written by others). You should not write your solutions while working with other students, and when you’re writing your solutions, you should ensure that you independently understand and can reproduce your answers without referring to notes from collaboration sessions and consulting with other students. (Homework Clinics are not exempt from this policy.) Finally, when you talk to other students about homeworks, you must cite those students in your handin. See the Policy for more details.

Even if you’ve read the above summary, please read the remainder of the Collaboration Policy, since it covers more policies on referencing external sources, how to cite other students in your submissions, etc. If you have any questions about the Policy, please ask on Edstem.