20s-2550: Introduction to Cybersecurity
Welcome to my section of 2550 for S'20.
We meet TR 9.50–11.30 in Cargil 097.
We have 9 TAs for this class (and its other section).
- Lead TA: Martin Petrauskas
- TAs: Simon Bruklich, Kathrine Driscoll, Samir Elhelw, Matthew Kline, Byron Kress, Fiona McCrae, Donald Sea, and Rahul Toppur
Mondays: 9–11 ISEC 605 (Martin, Samir, Rahul)
Tuesdays: 6–7:30 ISEC 605 (Kate, Rahul)
Wednesdays: 10–11 ISEC 605 (Simon, Donald)
Thursdays: 9–10:30 ISEC 605 (Martin, Samir, Matt); 3–4 ISEC 505 (Simon, Donald, Fiona); 4–5 ISEC 505 (Fiona, Byron)
Fridays: 12–1 ISEC 505 (Fiona, Byron); 3:30–5 ISEC 605 (Kate, Matt)
abhi: 9–10 Mon, Wed ISEC 621
You have a few actions items before class:
This is a introductory (first-year) course that presents an overview of basic cybersecurity principles and concepts. The high-level goal is to introduce main topics in security, introduce adversarial thinking mindset, threat modelling, and design of defense mechanisms.
In my own interpretation, a large part of the field is understanding different classes of failures for critical systems. I think of four rough classes of failures:
- Failure in operation:
- Human model of usage
- Mistake, checking in keys to github
- Failures of implementation:
- improperly handling untrusted input
- time of use and time of check
- error handling leaks implementation
- linux scheduling
- Failures of design:
- SHA1 hash function
- wifi pwd protocol
- Failures of abstraction: when the assumed abstraction does not hold, which leads to catastropic flaws in security. (These are sometimes the most interesting cases to study.)
- side-channels: power, acoustical, spectre, meltdown
- adversary is stronger than expected
- Unintended consequenses: privacy loss
As we study these failures, and hopefully understand how to design better systems, the field also considers practical defenses against unforseen attacks and adversaries:
- Defense in depth
- point-to-point instead of perimeter security
The course will also introduce students to legal and ethical issues associated with cybersecurity. The course will quickly cover most of the required background, and so we encourage wide participation.
Concepts will be illustrated with practical tools, systems, and applications that exemplify them. Hands-on projects will introduce students to key security tools and libraries.
|Jan 7,10||Intro, Linux basics, threat modeling||L2|
|Jan 14,17||Crypto, example of adversary, private key encryption||L3 L4||P0 due 1/17|
|Jan 21,24||Crypto: PRG, Enc, MAC||L5 L6|
|Jan 28,31||Crypto: MAC, PRF, PKC||L7 L8||P1 due 1/31|
|Feb 4,7||Passwords||L9 L10|
|Feb 11,14||Passwords and Access control||L11 L12||P2 due 2/15|
|Feb 18,21||Review and Midterm||L13 –|
|Feb 25,28||Cyberlaw, ethics||L15 L16||P3 due 2/29|
|Mar 1–7||Spring Break!|
|Mar 10,13||Access Control, Social Engineering||L17 L18|
||System security and Exploits||— L19|
|Mar 24,27||System security, Exploits||L20 L21||P4 due 3/26|
|Mar 31,03||Program exploits, Network attacks||L22 L23||P5 due 4/4|
|Apr 7,10||Web application attacks, Wireless attacks||L24 L25|
|Apr 14||Botnets, DDOS, Cybercrime||L26||P6 due 4/14|
|Apr 17||Final Exam||3:30–5:30p|
You will learn about security techniques and tools that can potentially be used for offensive purposes; “hacking” in other words. It is imperative that students only use these tools and techniques on systems they own (your personal computers) or systems that are sanctioned by the instructor. NEVER perform attacks against public systems that you do not control. As we will discuss in class, it is ethically problematic to attack systems that you do not own, and may violate the law.
Your final grade is computed as a weighted sum of your 7 project scores, your quiz scores, the midterm and final exam.
- Projects (7): 4%, 6%, 10%, 10%, 10%, 10%, 10%
- Quizzes (5): 2% each
- Midterm and Final: 15% each
Each assignment will include a breakdown of how it will be graded. Some projects may include extra credit components that can boost your grade above the maximum score.
I usually assign final letter grades on a curve to be generous.
There will be seven projects throughout the semester. Assignments are due at 11:59:59pm on the specified date. For this section, you will need to submit your work through gitlab. Your last commit timestamp on your files will be used to determine lateness.
Most projects can be programmed in a language of your choice. The only universal requirement is that your projects must compile and run on an unmodified Khoury College Linux machine. Notice the stress on unmodified: if you’re relying on libraries or tools that are only available in your home directory, then we will not be able to run your code and you will fail the assignment. You are welcome to develop and test code on your home machines, but in the end everything needs to work on the Khoury College Linux machines. If you have any questions about the use of particular languages or libraries, post them to Piazza.
There will be one midterm and one final. All exams will be closed book, and computers are not allowed nor is any access to the Internet via any device. Students are allowed to bring a single 8.5x11 cheat sheet to exams, with material written or printed on the front and back. The exams will cover material from lectures, readings, and the projects. The final will be cumulative, so review everything!
Throughout the semester, there will be five in-class quizzes. These quizzes will be brief; they are designed to be completed in 15 minutes or less. They are not meant to cause students grief, and the questions will be straightforward. The goals of the quizzes are to incentivize attendance and encourage careful study of the lecture material. If you need to miss class for any reason, please let me know ahead of time, just in case there is a quiz. Makeups will be provided on a needs-driven basis. Participation
I do not require students to attend class and I won’t be taking attendance, although as stated above, there will be in-class quizzes. That said, I prefer an interactive classroom, and I encourage everyone to attend, ask questions, and participate!
Requests for Regrading
In this class, we will use the Coaches Challenge to handle requests for regrading. Each student is allotted two (2) challenges each semester. If you want a project or a test to be regraded, you must come to the professors office hours and make a formal challenge specifying (a) the problem or problems you want to be regraded, and (b) for each of these problems, why you think the problem was misgraded. If it turns out that there has been an error in grading, the grade will be corrected, and you get to keep your challenge. However, if the original grade was correct, then you permanently lose your challenge. Once your two challenges are exhausted, you will not be able to request regrades. You may not challenge the use of slip days, or any points lost due to lateness.
Note that, in the case of projects, all group members must have an available challenge in order to contest a grade. If the challenge is successful, then all group members get to keep their challenge. However, if the challenge is unsuccessful, then all group members permamently lose one challenge.
For programming projects, we will use flexible slip days. Each student is given four (4) slip days for the semester. You may use the slip days on any project during the semester in increments of one day. For example, you can hand in one project four days late, or one project two days late and two projects one day late. You do not need to ask permission before using slip days; simply turn in your assignment late and the grading scripts will automatically tabulate any slip days you have used.
Slip days will be deducted from each group member’s remaining slip days. Keep this stipulation in mind: if one member of a group has zero slip days remaining, then that means the whole group has zero slip days remaining.
After you have used up your slip days, any project handed in late will be marked off using the following formula:
Original_Grade * (1 - ceiling(Seconds_Late / 86400) * 0.2) = Late_Grade
In other words, every day late is 20% off your grade. Being 1 second late is exactly equivalent to being 23 hours and 59 minutes late. Since you will be turning-in your code on Gitlab, its clock is the benchmark time (so beware clock skew between your desktop and Gitlab if you’re thinking about turning-in work seconds before the deadline). My late policy is extremely generous, and therefore I will not be sympathic to excuses for lateness.
Collaborating with other students in the class on homework problems is encouraged, though we urge you to first attempt working out all of the problems by yourself. It’s ok to ask your peers about the concepts, algorithms, or approaches needed to do the assignments. We encourage you to do so; both giving and taking advice will help you to learn.
However, you must write up, prepare, submit your solutions, in your own words. Looking at or copying code or homework solutions from other people or the Web is strictly prohibited. In particular, looking at other solutions (e.g., from other groups or students who previously took the course) is a direct violation. Projects must be entirely the work of the students turning them in, i.e. you and your group members. If you have any questions about using a particular resource, ask the course staff or post a question to the class forum.
All students are subject to the Northeastern University’s Academic Integrity Policy. Per Khoury College policy, all cases of suspected plagiarism or other academic dishonesty must be referred to the Office of Student Conduct and Conflict Resolution (OSCCR). This may result is deferred suspension, suspension, or expulsion from the university.
You do not need a textbook for this course.