Advanced Security

Description

This course explores advanced and emerging topics in computer security. We will study recent research across a range of areas, with an emphasis on technically deep work and important new security problems. Rather than treating papers as isolated results, we will focus on their core technical ideas, assumptions, limitations, and the research questions they open up.

The course is discussion-oriented. Students are expected to read the assigned papers carefully and come to class prepared to explain, criticize, and reason about them. There is no assigned textbook.

Prerequisite

Security I or equivalent background is recommended. Please contact the instructor if you are unsure about preparation.

Class format

A typical 110-minute class will have four parts:

1. Instructor introduction (about 10 minutes): framing the topic, connecting the readings, and highlighting the main questions for discussion.
2. Two student presentations (about 60 minutes total): two focused 30-minute presentations, normally covering one assigned reading each.
3. Break (about 10 minutes).
4. Q&A and discussion (about 30 minutes): questions for the presenters, comparison across the readings, criticism, and open research problems.

Exception: the first class will be instructor-led and will not have student presentations.

Attendance

Attendance is mandatory. This is a discussion- and presentation-based course, so a significant part of the learning happens through in-class presentations, questions, and discussion and cannot be reproduced by simply reading the assigned papers afterward.

If you expect to miss a class, please notify the instructor as early as possible. Absences for medical reasons or other documented emergencies are excused. Other unavoidable absences should also be communicated in advance whenever possible; unexplained or repeatedly uncommunicated absences will affect the participation grade.

Student presentations

Each student presentation is approximately 30 minutes. Presentations should be concise and analytical. A useful structure is:

As a guideline, each 30-minute presentation should use roughly 25–30 substantive slides. Presenters are expected to go into technical depth rather than skim the paper, and must be able to answer questions about any claim on their slides.

Reading and participation

There are no weekly paper summaries. Everyone is expected to read the required paper before class and participate in discussion. Students may occasionally be called on to explain a paper's key assumption, strongest result, limitation, or an aspect they found unclear.

For selected classes, students may be asked to submit a single sentence before class—for example, the weakest assumption in the paper or one experiment they would add. These responses are intended as preparation for discussion rather than as miniature essays.

Quizzes

There will be two short in-class quizzes during the semester. Their purpose is to encourage students to keep up with the readings, lectures, and class attendance throughout the semester. The date of each quiz will be announced approximately one week in advance.

• Each quiz will be short and designed to be straightforward to grade.
• Questions will focus on important concepts, assumptions, threat models, and basic technical ideas—not obscure details.
• Questions will primarily be multiple choice, true/false with a brief justification, or one-phrase/one-sentence answers.
• No lengthy derivations.
• Quizzes are individual and completed without AI tools or other electronic assistance.

Use of AI tools

Students may use LLMs and other AI tools for reading assistance, brainstorming, presentation preparation, coding, and project work unless explicitly stated otherwise. The course will not attempt to distinguish AI-assisted prose from unaided prose.

However, students are responsible for everything they submit or present. In presentations and discussions, you must be able to explain and defend your claims, technical arguments, and proposed ideas. Material that a student cannot explain should be treated as material the student does not understand.

Project

The project should investigate a focused research question related to the course. A project may reproduce, break, extend, or reinterpret an idea from a paper; build a small system; perform a careful empirical study; or develop a formal or conceptual result. Suggested LLM-focused project themes and example directions are available on the Project Ideas page.

The project is intentionally lightweight in structure. There are four milestones:

1. One-page proposal: problem, motivation, and intended approach. Due September 29 at 11:59 PM.
2. Detailed project plan (3 pages, due October 20 at 11:59 PM): extends your one-page proposal into a concrete plan that someone else could carry out. Be specific: name the exact models, datasets, tools, numbers and dates. Sentences like “we will use LLMs to analyze vulnerabilities” or “we will evaluate performance” get no credit. The report must contain:
   1. Research question and hypothesis. The question in one sentence and a hypothesis that could turn out false (e.g., “Adding fuzzer feedback raises patch correctness from X% to at least Y% on benchmark Z”). Say what changed since your proposal and why.
   2. Related work. 3–5 papers. For each, one or two sentences on what it did and exactly how your project differs.
   3. Setup. Exact models (name and version), datasets or benchmarks (source, size, and which subset you will use), tools and libraries (with links), and your compute or API budget in dollars or GPU-hours.
   4. Method, step by step. A numbered pipeline. For each step, state its input, what it does, and its output. Say what you will build yourself and what you will reuse (link the repos).
   5. Evaluation. Define each metric precisely, name at least one baseline, and say what result counts as success and what counts as failure. Include a table of the results you expect, filled in with your predicted numbers.
   6. Preliminary result. Show something you have already run, even if small; for example, run the baseline on 10 examples and report the output.
   7. Weekly timeline through December 1. A concrete deliverable for each week, and what you will show at the midpoint presentation.
   8. Risks and fallback. The two things most likely to go wrong and your plan B for each.
   References do not count toward the 3 pages. Vague plans will be returned for revision.
3. Short midpoint presentation (October 27 or November 10): what you tried, what happened, and what remains. Sign up for a slot using the sign-up sheet (Columbia login required) by October 20 at 11:59 PM. There are at most three presenters per day, first come, first served; students who have not signed up by then will be assigned a slot.
4. Final report and presentation/demo: a concise account of the question, approach, evidence, and conclusions.

Negative results are acceptable. Projects are evaluated primarily on the quality of the question, technical understanding, methodology, and what was learned—not on whether a new system beats a baseline.

Grading

Each quiz is worth 10% of the final grade. Presentation grades emphasize technical understanding, judgment, criticism, and the ability to answer questions rather than slide polish.

Schedule

The detailed schedule and readings will be posted here before the semester.