CS 261N Internet/Network Security Projects
Your term project should address a research issue in
network security, interpreted broadly (it need not be a topic discussed
in class). The goal in terms of depth and quality is to develop the
effort to a degree that
would merit a workshop-caliber publication.
Most projects will fall into one of the following general
- Analyze. Undertake a substantive analysis/assessment of
security issues for a given network system. For example, to what degree
does Skype expose its users to remote compromise? Preserve their privacy?
Admit misuse of the system to aid in denial-of-service attacks?
Surreptitiously monitor their communications? Have
vulerabilities that enable fraud? What
is its trust model? What steps could be taken to strength Skype in
this regard? What can you say about the expected efficacy of those steps?
it needn't be an application nor involve end systems. You can consider
schemes relevant to other layers of the networking stack, or that
concern infrastructure/internal components.)
- Measure. Empirically explore and characterize a network
security issue. For example, under what circumstances and to what degree
do nodes in the Tor anonymizing network alter the content that passes
- Innovate. Devise and analyze (and possibly implement)
a new mechanism or technique. For example, this could be a new way to
protect servers from application-level denial-of-service attacks, or
a new detector for some type of malicious activity.
- Test. Take a result in the literature and undertake
a thoughtful and meaningful reproduction of it to assess to what degree
you obtain the same results, and why.
- Attack. Develop a new threat. Assess its efficacy,
countermeasures/defenses, and likely "arms race" evolution.
- Research. Conduct a deep, thoughtful literature survey
of a particular area in network security ("research" as a verb). Assess
the strengths and weaknesses of the published results in the area, delimit
the boundaries of the state of the art, identify themes and abstractions,
frame avenues for future work.
I encourage you to find a topic of interest to you; feel free to be creative
in selecting a project topic! You're welcome to pick a topic that is
connected to your current research, and in general I'm happy to discuss possible
topics with you in advance. (See the end of this writeup for a list of
past projects to get the flavor of what students have done. I can provide
more specifics about these if you'd like.)
Often you can pursue the same project jointly
for two different classes. If this would be the case, you need to discuss
it first both with me and with the other instructor(s).
In general, you should work in a team of two. One resource for
finding a partner is posting your interests/thoughts to Piazza.
may be doable but require prior discussion with the instructor.
If you want to work in a team larger than two, first talk with me about
why this is appropriate and how the work will be divided.
With coauthors, I've written some papers providing advice for researchers:
- Send me a short email summarizing your
initial thoughts regarding possible project(s) you are
considering. Briefly sketch the topic; what you would hope to achieve;
why the project interests you; who you might partner with (if known);
what concerns you have at this point.
The Initial Thoughts email is due the evening of
Friday Jan 30.
- Write a concise (approximately 1 page)
project proposal that clearly states the problem you will be tackling,
the key challenges for new research, and your plan of attack (including
milestones and dates). If there are any special resources you might need,
flag these. Mention any relevant papers of which you are already aware.
The project proposal is due the evening of Friday Feb 13.
Put together a related work writeup. This writeup should
reflect a solid grounding in the literature relevant for your project,
written in a style similar to the related work sections in
the papers we've been reading. For
each item of previous related work, briefly discuss the contributions
of the paper, its relevance to your undertaking, and (if appropriate)
in what ways it differs from your effort.
In general, you can tell if your related work framing is possibly
too narrow is by looking at the citations of those papers you currently
discuss. If you see that they cite tons more work that at least from their
titles sound like they could be germane, then it's your task as a researcher
to then track those down - ideally, all of the ones that sound like
they could be relevant - and assess which ones you indeed need to read and
absorb. Note, read-and-absorb here can run the range from reading in
detail, similar to how you read papers for the class, to just reading
sections or such, as you gauge relevance.
You then recurse on the citations in those papers, repeating
the process until you converge by not finding any new papers, and/or the
ones you find become only lightly related.
At this point, you've then mastered the full literature on the
area you're working in (and usually gotten a bunch of new ideas
about what to try or, often more importantly, not try).
When gathering these related papers, you may run across some that require
payment through portals such as those run by ACM or IEEE. Note that UCB
has site licenses for most of these libraries, so you should be able
to readily fetch them using a campus machine/address without needing to provide
The related work writeup is due the evening of Friday March 6.
- Write up a short status report explaining what work you have
completed, what remains, and any open issues (such as problems you haven't
figured out how to solve or additional resources you require). Begin
your report with a sketch of your project so I'm reminded of the context
while reading it.
The status report writeup is due the evening of Friday Apr 10.
- As part of turning in the status report writeup, include your
team's availability for a meeting, which I may ask for so we can further
discuss the progress of your project.
Prepare a class presentation.
These will be held at the end of the semester, extending into RRR
week due to the size of the class.
24+ hours prior to the class
in which you'll be presenting, post a brief (~2-3 paragraphs)
description of your project to Piazza.
There's an art to scoping a presentation to effectively make use of
the available time. You need to gauge what context your particular audience
(here, this means your classmates) already has regarding the problem space
your work addresses, and not spend time developing that broader context;
at most, just remind them. However, it will (better!) be the case that
your particular area has depth beyond what the average audience member
knows about. You do need to frame this additional context, both
in terms of what makes the problem interesting and significant, and how
the problem space has been previously viewed in terms of prior work and
the assumptions this work reflects.
Finally, your project report is due on Tuesday May 12, at 1PM.
No extensions will be granted.
The Final Report
You are expected to write a technical paper, in the style
of a conference submission, on the research you have done.
State the problem you're addressing, motivate why it is an
important or interesting problem, present your research
thoroughly and clearly, compare to any related work that
may exist, summarize your research contributions,
and draw whatever conclusions may be appropriate.
There is no page limit (either minimum or maximum),
but reports will be evaluated on
technical content and not on length.
If relevant, include a section where you describe how others (beyond your
team) contributed both to different parts of the work and to the text in
the writeup. My expectations are that the strong majority of both the
work you report on and the writeup text will be yours, but it's generally
okay if relatively minor subsets are from others, as long as these are
flagged as such.
Be sure to pay attention to these
writing technical papers.
Submit PDF via an email attachment.
I generally review papers from hardcopy, so it needs to print clearly and
with sufficiently large text and figures. If you use color figures, mention
that in your cover note so I can send it to an appropriate printer.
In addition, also submit your document source. It doesn't
need to build (e.g., okay to leave out LaTeX packages and figures; it can
be helpful to include your bib file, though).
Examples of past projects
To give you a flavor of possible projects, here are examples of what
students have done in the past (note that some of these could make sense
to redo or work on further):
- Securing Firefox's plug-in mechanism
- Measurements of nation-state attacks on a community vs. "routine" malware
- Correctness of a Web ad security safety model
- In what ways does the Internet have "bad neighborhoods?"
- Approaches for safely running other people's code on your trace data
- Assessing the feasibility of using a hypervisor to enforce always-use-Tor anonymity
- Dynamic firewalls for data centers
- Security analysis of AirBears
- Characterizing monitoring of P2P networks that aims to detect illicit file sharing
- Security evaluation of T-Mobile's "WiFi Calling" feature
- Distributed detection of spam sources
- Detecting "fast flux" DNS domains in real-time
- Security assessment of cloud-based file sharing
- Designing spontaneous mesh networks for use by citizenry to counter government-imposed Internet outages
- Literature survey of forensics
- Evaluating the security of Chrome extensions
- Survey of SCADA security issues
- Efficacy of heuristics for detecting phishing sites
- Analysis of security issues relating to location services
- Exploiting hypervisors to protect users from divulging credentials
- Measuring factors that influence the prevalence of security problems in open-source network services
- Assessment of security issues for cloud computing
- Visualization of security data
- Securing a distributed key/value store
- Privacy implications of Flash
- Security analysis of Near Field Communication
- Securely deploying filtering and other functionality in network elements
- Using fault localization to find bugs in network servers
- Measuring the behavior of "clickbots" of fraudulent pay-per-click
- Assessing abuse of a large online social network run by the student
- Determining how well a detector for web abuse previously published in the literature performs on traces to which the students obtained access
- Assessing the vulnerability of data-reporting protocols for sensor networks in the face of adversarial intermediary nodes
- Locating embedded web-based systems likely set up using default configurations/passwords based on similiarities in their home pages
- Detecting plagiarised/cloned Android apps from their distribution packaging
- Analyzing enterprise traffic to infer which services appear to have interdependencies
- Assessing to what degree we can detect spam on Twitter due to mismatches between the concepts described in a tweet versus the web page to which a URL in the tweet leads the user
- Reassessing data from the "Spamalytics" study to determine whether its findings regarding national differences in responses to spam arise due to variations in anti-spam filtering vs. cultural factors
- Comparing the effectiveness of input validation versus output escaping for reducing vulnerabilities in web applications.
- Evaluating potential vulnerabilities that arise from discrepancies between how Flash treats the Same Origin Policy versus how browsers do
A couple of possible projects
In case of interest, here are two projects that I'm currently looking to
put together (for which students would be working directly with me). I've
offered these in various forms to some of my advisees, so a given project
might no longer be available if they decide to pursue it, though still
could if they would find it beneficial to have someone else working with
them on it. If you're interested in one of these, mention that in your
Initial Thoughts note (and of course feel free to ask me questions
about what's involved), but you should also frame alternatives.
- Develop a detector to find with high confidence remote logins to
a site that likely reflect stolen credentials rather than legitimate
activity, based on deviations from the features of the logins from
historical norms. This would be working in collaboration with
staff security analysts at the Lawrence Berkeley National
Laboratory, significantly extending their existing framework for
- Study the phenomenon of attackers recruiting "mules" for laundering the
proceeds of cybercrime. This project would be a collaborative
effort with the bank fraud R&D division of a US bank that has
already worked extensively on analyzing forms of muling activity.
It would also be joint with researchers from CESR, the cybersecurity
center I co-direct.