CSC 481/681 - Fall 2020 - Semester Project

All students in CSC 481 and CSC 681 will complete a project that involves independent exploration of practical aspects and tools related to concepts we discuss in class. This document describes the timeline, deliverables, and expectations for the project.

The basic idea is that all students (undergraduates and graduate students) will do a practice-driven exploration of some tool or technique that we touch on in this class. Some basic examples (which are expanded on below) include static analysis tools for vulnerability detection in software, security testing tools including fuzz testers, reverse engineering tools for malware analysis, network probing and assessment tools, tools and libraries for cryptography use in applications, and more. There is also an option for creating your own password-modeling tool (details below). You should explore the use of your selected tool on at least one real-world size problem, and write a report describing what you learned about the tool and how it worked when applied to your problem. The final report is due at the university-scheduled final exam time, and will not be accepted late.

Graduate students taking CSC 681, and undergraduate students taking this course for contract honors credit, will also select a topic from the research literature according to their interests, locate appropriate references, and write a thorough research summary and critique. Students are allowed and encouraged to do this in conjunction with the basic semester project. For example, rather than exploring a standard tool (e.g., a fuzz tester) for the project, you can experiment with a research-level tool and survey current research literature related to that tool or technique. More information on guidelines for this research component are available on the Research Related Activities page.

Note that there are various resources that are available in the department that could be useful for some projects. For example, there are some large-ish servers that can be used for computationally-intensive analysis or testing. If you could benefit from something like this, just ask!

Timeline

Topic Selection: Due Monday, October 26
Submit, in Canvas, a brief statement on your project topic selection. All that’s needed for the basic project is a few sentences describing the tool or technique you will explore, a reference to where the tool can be found online, and an indication of what problem you will apply the tool to. If you don’t have a specific application problem selected, you can describe (in a few sentences) how you will select a specific problem.

Progress Reports: Due Monday, November 16
By this date, you should have thoroughly explored and experimented with the tool you are using, have decided on a specific problem to apply it to, and have performed some initial experiments with the tool and your problem. Your progress report should be roughly 2-3 pages, and include what will become the “Introduction” section of your final report: describe the tool (its purpose, how it’s used, and what you can expect to discover from the tool), your applied problem (specific application, why you chose it and believe it is a good demonstration of the tool, and what you hope to discover), and your experimental design (your general approach to exploring your problem). You should also include information about challenges to your project (if any) – both things you have run across already, and issues you foresee coming up in the future.

The main purpose of the progress report is for me to get a very clear picture of what you are doing and where problems may arise. I will give feedback to you on whether you are headed in the right direction, and can give suggestions for overcoming challenges that you experience. You may submit the progress report as early as you’d like, and I’ll give you feedback promptly to help direct your work.

Final Project Reports: Due Friday, December 4, 3:30 (this is the university-scheduled final exam time for this class, and projects may not be submitted after this time)
Your final report should thoroughly report on the tool and results from applying it to your problem. While there is no required structure for the report, a good structure could be an Introduction section (described in progress report above), a section describing the problem you are applying this to, a section describing your experimental setup (what tool options you’re using and why), a section on raw findings, and a discussion section wrapping up what you learned about the tool, how effective it was, and interesting take-aways from applying it to your problem.

An appropriate final report length would be 8-12 pages, single spaced with reasonable margins and a 12 point font (this is the length of the writing – if you include screenshots or large diagrams, don’t count them in the 8-12 pages). If you have raw data or code to include, place them in an appendix following the main report. Make sure you include citations of any references (web sites, documentation, etc.) that you used.

Topic Selection Guidelines

Your project should be designed around a significant tool or technique for security work and/or development. The sample project topics below give a feel for the level of tool that is appropriate. While it’s impossible to give specific guidelines, you should be looking for high-quality, established tools that provide a variety of non-trivial options and configurations to explore. For example, a tool that simply looks for format string vulnerabilities is basically a glorified “grep”, and is not sufficient for this project. There is a huge selection and variety of open-source security tools that are freely available, but you aren’t restricted to just free tools. Some commercial tools have free evaluation periods that could enable a project – just make sure your evaluation period lasts long enough for you to complete your project! If you are really interested in commercial tools and are particularly ambitious, you can contact the vendor to see if you can arrange use of the tool for your project.

You also need an application problem to apply the tool to. For example, if you select a software analysis or security testing tool, you can apply this to some substantial piece of open-source software. Do not go overboard though – applying a tool to a web browser or the full Linux kernel would most likely be too complex a task to complete in any meaningful way for this project. There are many open-source projects that contain between 30,000 and 500,000 lines of code, and these could be good targets. For basic projects (although not necessarily graduate student research tools), it’s best to avoid the most popular open-source software packages – these have been analyzed and fuzzed extensively, so there’s not much chance that you’ll get interesting results from applying a well-established tool to such an application. If you can find a fringe or emerging project, then you might discover previously-unknown vulnerabilities that you can fix and provide a real-world impact for your class project!

Sample Project Topics

Note that there are many interesting projects dealing with finding vulnerabilities in programs, through either program analysis tools or testing tools. We have not covered most of these topics at this point in the class, but hopefully the descriptions below should be self-explanatory. If you have any questions, just ask! The list of sample tools/topics below is not exhaustive – if you know of some other tool or technique that you think would be appropriate for a project, talk to me (the earlier the better) and we’ll discuss the possibility.