Project Milestone 4: Beta

Declare: Monday, April 25, 10:00 pm by email.
Due: Wednesday, April 27, 10:00 pm through CMS.
Presentation: Friday, April 29.

Complete another project sprint and ship the latest increment of your system to the course staff. Your beta milestone should exhibit significant completed security functionality. System and code quality is an important concern for this deliverable. Recall that you don't have to have everything finished for the beta deliverable—you still have another two weeks after it to complete your system.

As discussed in class, I debated making this deliverable optional. After the alpha presentations, it became clear that no group was close to finishing the implementation of all security functionality. Everyone would benefit from another round of evaluation, but I also want to help you manage your workload. So this deliverable is strongly suggested but not required. If your group chooses not to deliver it, your grade(s) for the beta deliverable will be set to whatever grade(s) you receive on your final deliverable. Your group must declare your decision to deliver, or not, to Dr. Clarkson by April 25; that decision is binding. If you decide not to deliver, I regret that I will be unable to provide you with evaluation "for free."

Assurance Document

Prepare an Assurance Document that discusses assurance in the security of your system. Think of the audience for this document as being students from other groups in the class: your readers are familiar with security in general, but not your project in particular. (You might event want to have a member of another group review your document for you before you submit it.)

This document should outline the design for the security of your system, including discussion of the Essential Security Elements—authorization, authentication, audit, confidentiality, and integrity. Note that this discussion should be more detailed and implementation-oriented than what currently exists in your Requirement Document. For example, you could:

• Describe the kind of security policies (DAC, MAC, RBAC, Clark–Wilson, etc.) your system employs, and how they are customized for your use or your users' use.
• Give protocol specifications for the cryptographic protocols your system uses (where the specification details the sequences of messages exchanged, using the kind of notation we've used in class), including citations for any protocols you borrow from the literature. If you've invented your own protocols (something that is always discouraged in security), you should argue why those protocols are secure.
• Justify your choices of cryptographic algorithms, key lengths, nonce lengths, etc.
• Give an architectural description of all important program components related to security. For example, where are authorization and authentication decisions made?

Devote more space to what you think are the tricky parts, explaining what the pitfalls are and how your system addresses them. Write at a level of detail that is suitable to convince the reader that your security design is sensible.

Your Assurance Document should also outline how you have tested your system. No specific testing tools are required, per the revised workload for the course. But you have the opportunity to impress the course staff by discussing/providing some or all of the following: description of how you constructed your test suite, fuzz testing, JUnit tests, code coverage statistics from EclEmma, a FindBugs report, penetration testing.

Some groups have already submitted some of this information as part of their Requirements Document or test plans. You should now refactor that information into your Assurance Document.

Four to eight pages would be a reasonable length for this document. Your QA lead has primary responsibility for assembling it, but all members of your group should contribute. Also, note that an updated version of this document will be part of your final deliverable.

Submission

Submit a PDF containing your updated Requirements Document. The document should continue to contain your personnel, system purpose, threat analysis, security goals, essential security elements, and system backlog (both completed and uncompleted items).

Also submit a PDF containing your Assurance Document.

Finally, submit a zip file containing the source of your system. Include a plain text file named "README" in root of your source detailing how to compile and execute your system on our own machines.

Presentation

The presentation and demo will proceed essentially as in Milestone 3.

Assurance: As part of your talk, discuss the security assurance of your system. Plan to spend an extra 10 minutes or so on this topic.

Code Reviews: We had no time for these in the alpha presentations, regrettably. I really hope to spend time on this during the beta presentations.

You should submit your sprint report (through CMS) on the same day as your presentation.