[538P] Topic in Computer Systems: Systems Security (2022-2023)

UNDER CONSTRUCTION

Course Description

The goal of this course is to expose students to a variety of topics in Systems Security. Security inherently touches on all areas of computer science. Therefore, this course was designed as a breadth course, addressed to all students in the department. The core idea underlying the course is to bring together a diversity of viewpoints to generate interesting discussions. On the other hand, we could also easily design a depth course focused on any of the topics we will discuss. The project component is the opportunity for students to explore one of those topics in more depth. Students are free (and encouraged) to apply their expertise (ML, PL, HCI, architecture etc.) to solve a specific Security problem. Some of the papers have been selected explicitly to highlight the interdisciplinary nature of Systems Security and to showcase how diverse perspectives are welcomed and appreciated.

Course Requirements

There is no specific pre-requisite for this course outside of an undergraduate degree in Computer Science or closely related topics.

Course Objectives

  • reason about security problems;
  • learn to read, critique, and write security papers;
  • better understand the review process;
  • implement and evaluate a security prototype.

Class format

This is a seminar-type class. Every class we will discuss a different paper. I have selected a mix of recent and older papers. There will be two presenters during each class. Each presenter will play a different role: the role of the Advocate and the role of the Critic. The Advocate should play a role similar to that of the original authors and try to sell the work to the audience. On the other hand, the Critic while remaining objective should towards the end of the presentation highlight the flaw of the paper and convince the audience that the paper is not good. The Advocate presentation will last 20-25 minutes, you should motivate the work, summarize the paper, and present the results. The Critic presentation will last 10 minutes, you do not need to cover motivation or summarization, instead you should focus on the shortcomings of the paper. While shorter, the critical presentation is probably harder to prepare.

In order to do well during your presentation, you should remember to stick to your role (Advocate or Critic). Further, you do not need to spend too much time explaining the basics of the paper, everyone in the class will have already read it. What add value to the presentation is your opinion and the insights you can extract from the paper! This is what you should focus on.

You should expect to present at least 2 or 3 times during the term depending on the number of students registered. After the presentation, we will take a 10 minutes break and discuss the paper. You should come prepared for those discussions and be ready to engage.

Paper reports

For each assigned paper you must write a report. You are to use the USENIX latex template for formatting. In your report, please, follow this structure:

Paper Summary (no more than 250 words)

Provide a brief summary of the paper (3-5 sentences is usually enough). The aim is to demonstrate that you’ve read (and understood) the paper, so try to paraphrase and extract the essentials. At this stage you should aim to be objective; later sections allow for your own opinion.

Answer the following (no more than 750 words in total)

The Problem

What is the problem? Why is it important? What is previous work insufficient (or Why has the problem not been solved before, e.g. it’s a new problem the authors have identified). This is your take on what the authors say in the paper (so again should be fairly objective). If the paper doesn’t seem to tackle a particular problem, then focus on the primary motivation for the work. 1-2 sentences for each of the three questions is probably sufficient.

The Solution (or Approach)

What is their approach/solution? How does it solve the problem? How is the solution unique and/or innovative (if it is)? What are the details? Once more you should use the paper itself as the source to help you answer these questions– but, as in previous parts, please do not just copy sections from the paper. Instead, you should focus on paraphrasing/synopsizing, and extracting the essential details. Depending on the paper, you’ll probably need 5-10 sentences here.

Evaluation

How do they evaluate their solution? What questions do they set out to answer? What does the evaluation say about the strengths and weaknesses of their system? What are the strengths and weaknesses of the evaluation itself do you think? A total of 3-4 sentences should suffice here – we’re looking for highlights, not a point-by-point reproduction of the evaluation section(s). In the rare case that there is no evaluation section, skip this part of the report.

Questions for the Authors

Imagine you’re attending a talk about this paper given by one of the authors. List at least 2 questions that you would like to ask. These should ideally be specific to the paper/research.

You should submit 23 paper reports (subject to change). Each report done properly is equivalent to 1% of your final grade for a total of 20%. In practice, this means you have a few “jokers”.

Project

The project must address a non-trivial problem relevant to systems security. The project can resolve the problem by building a system, collecting data/carrying out experiments, developing algorithms and proving them correct, etc. I strongly prefer that you do your project in a team of 2-4 people. You are encouraged to apply techniques from your main area of expertise to the topic of security (e.g., perform intrusion detection using ML techniques).

You should plan to schedule some time to chat about your project idea with me. Please, do not hesitate to send me an e-mail as soon as you want to discuss it.

The required project deliverables are listed below. Written submissions will be made through TBC and must be formatted using the USENIX latex template.

  • Project Proposal Draft:
  • Proposal Presentation:
  • Proposal Peer Review: each student will review proposals from other groups and give feedback. You should take this task seriously.
  • Project Proposal: you should incorporate feedback from the peer review process. I also strongly encourage you to schedule time to chat with me.
  • Project Report Draft:
  • Project Presentation: a presentation describing your project. I encourage you to demo your project during your talk. Each presentation will be followed by a QA period. Presentation timing details TBD.
  • Report Peer Review: as per the proposal stage, you will be asked to review the report from other teams.
  • Project Report: you should incorporate feedback from the peer review process. I also strongly encourage you to schedule time to chat with me.

Deadlines (TBC)

  • Project Proposal Draft: Friday, February 9th
  • Proposal Presentation: Wednesday, February 15th
  • Proposal Peer Review: Friday, February 17th
  • Project Proposal: Monday, February 27th
  • Project Report Draft: Friday, April 7th
  • Project Presentation: Wednesday, April 12th
  • Report Peer Review: Friday, April 14th
  • Project Report: Friday, April 28th

Grading

  • Peer Review 10%
  • Project (group) 55%
  • Paper reports 20%
  • Presentation(s) 10%
  • Participation (in-class discussion) 5%

Schedule & Reading List (subject to change)

Day Paper Presenters
Jan 9 Mon Introduction - Course Overview - Reading a Paper
Reading (no report): How to read a paper
Jan 11 Wed A Study on the Security Implications of Information Leakages in Container Clouds
Jan 16 Mon Houdini’s Escape: Breaking the Resource Rein of Linux Control Groups
Jan 18 Wed SCONE: Secure Linux Containers with Intel SGX
Jan 23 Mon Security Namespace: Making Linux Security Frameworks Available to Containers
Jan 25 Wed Demons in the Shared Kernel: Abstract Resource Attacks Against OS-level Virtualization
Jan 30 Mon Anomaly detection using call stack information
Feb 1 Wed A fast automaton-based method for detecting anomalous program behaviors
Jan 6 Mon Fast Memory-efficient Anomaly Detection in Streaming Heterogeneous Graphs
Feb 8 Wed DeepAID: Interpreting and Improving Deep Learning-based Anomaly Detection in Security Applications
Feb 13 Mon Automating mimicry attacks using static binary analysis
Feb 15 Wed Proposal Presentation
Feb 20 Mon Midterm
Feb 22 Wed Midterm
Feb 27 Mon Automated whitebox fuzz testing
Mar 1 Wed AFL++: Combining Incremental Steps of Fuzzing Research
Mar 6 Mon kAFL: Hardware-assisted feedback fuzzing for OS kernels
Mar 8 Wed IoTFuzzer: Discovering Memory Corruptions in IoT Through App-based Fuzzing
Mar 13 Mon Rethinking Access Control and Authentication for the Home Internet of Things (IoT)
Mar 15 Wed Information Exposure From Consumer IoT Devices: A Multidimensional, Network-Informed Measurement Approach
Mar 20 Mon Control-Flow Bending: On the Effectiveness of Control-Flow Integrity
Mar 22 Wed KCoFI: Complete control-flow integrity for commodity operating system kernels
Mar 27 Mon Software fault isolation with API integrity and multi-principal modules
Mar 29 Wed LXDs: Towards isolation of kernel subsystems
Apr 3 Mon RedLeaf: Isolation and Communication in a Safe Operating System
Apr 5 Wed EROS: a fast capability system
Apr 10 Mon Cheri: A hybrid capability-system architecture for scalable software compartmentalization
Apr 12 Wed Project Presentation

Late Policy

You will receive a 0 for late work unless you have an approved extension.

For individual assignments, the deadline for one assignment can be extended by 24 hours with no penalty to the mark. Extension requests must be made explicitly through e-mail. Extension requests must be made no later than 24 hours past the deadline.

For group tasks, you can request an extension of 24 hours as long as someone in your group has an unused extension. You cannot receive an extension of more than 24 hours for a group deliverable.

Academic honesty and collaboration guidelines

The department has a detailed policy regarding collaboration and plagiarism. You must familiarize yourself with this policy.

Paper reports: You should write your reports individually. You are free to discuss with others, but you must write the reports on your own. You should clearly reference any resources you have used.

Projects: you are free to use any code you find in your project. However, a non-trivial fraction of functionality in your prototype must be constructed by your team. You must cite and attribute sources of the code that you borrow/utilize in your project. When writing the project reports, you should follow the same citation standard as expected from conference papers.

Extra Reading Material

Thomas Pasquier
Thomas Pasquier
Assistant Professor

My research interests include provenance, operating systems, distributed systems and intrusion detection.