CS5430 Project: Spring 2013

CS5430 students are expected to participate in a group project to build a system that has non-trivial security functionality. Here is the schedule.

Forming a Group

Groups of 2 - 4 students are allowed, but groups of size 3 seem to work best. Smaller groups almost always produce lower-quality projects and, consequently, get lower grades; groups larger than 3 have difficulty coordinating---for example, finding times that all members can meet.

Beyond these pragmatics, working in groups offers other benefits:

MEng Project Option

MEng students may use their CS5430 project as the basis for the required MEng project. If this is your intention, then your group members must all be MEng students who are all electing to use the project in this manner. Your group will then not only be expected to satisfy the project requirements outlined below but will also be expected to:
  1. Implement some additional functionality, as agreed upon between your group and the course staff.

  2. Provide a written "project report" for the entire project. This report should document the problem solved, design alternatives, a rationale for design selected, the implementation, the testing strategy employed, and give instructions for both installation and use.
You may start working on these additional MEng-project tasks at any point during the semester. They need not be completed before the end of the semester, but the project without that additional functionality must be completed and submitted according to the above schedule for phases I through V.

Project Choices

You have considerable flexibility in choosing a system to build. The course project is intended to provide an opportunity for you to use the material we cover in lectures, however, so projects much involve the following elements.

Any interesting system will also involve other security functionality, too. Most systems, for example, will need to provide infrastructure for audit or other means of establishing accountability for actions. Many systems will need to implement authorization. The list above defines only a subset of the security functionality your project must implement. What is the rest of that functionality? Answering that question is one of the tasks in Phases 1 and 2.

Here are sketches for a few example systems. Each sketch has important elements missing from its description, as befits a sketch. So you'll need to identify and describe those elements if you elect to build a system that is inspired the sketch. But feel free to invent your own project idea if none of the sketches is appealing.

Choice of Tools

Select a programming environment, programming language, and target platforms that make sense for your project. Our evaluation of what you build will be based, in part, on your choice of tools (and our ability to understand your source code, so don't pick anything too obscure). Java and C# are safe choices.

If you elect to program in C or C++ then we will be interested in how you ensure that buffer overflows and other vulnerabilities that frequent C programs have been eliminated. There are tools for analyzing C and C++ source code for vulnerabilities, but running these tools (if you can get access to them) is a non-trivial undertaking.

When building a system in industry, it is generally a good idea to extend existing components rather than build your own. For example, there are many 3rd-party systems and tools available for building web services (including web servers) and for implementing databases. But using these tools in CS5430 would preclude parts of the learning-experience the project is supposed to promote. This is because, when you use a 3rd-party tool, you must: (i) accept somebody else's choices about what is useful security functionality and (ii) accept somebody else's assurance argument. We therefore impose the following ground rules about using code or systems written by others: