Secure Programming Project

Project Objectives

In this project, you will work either in a team or individually to build a software system that has non-trivial security functionality.

Required Elements

The following security elements must be included in each project:

Authorization - The system must enforce some non-trivial authorization policy to control some subset of its operation. Some systems will require DAC; others will require MAC. Implement an access control mechanism that is appropriate and natural for your system's functionality and expected scale.

Authentication - The system must authenticate its clients or allow its clients to authenticate the system. Clients may include human users as well as programs executing on machines. You must implement reasonable means of authentication, which may include passwords, user registration, generation of secrets, distribution of keys, etc.

Audit - The system must provide infrastructure for audit or other means of establishing accountability for actions.

Confidentiality and Integrity - The system must involve information that resides in long-term storage or that is transmitted over a network. The system's mission must require that information to be kept secret and be protected from un-authorized modification.

In addition to these security elements, note that all code in the system must be your own, so that you can evaluate its security properties and provide assurance to its behavior. That following exceptions to this general rule are permitted:

• Features provided by your language's standard library (excluding web service frameworks)
• Cryptography library
• GUI builder
• Database
• Other exceptions after prior discussion with instructor

Two elements are not required in this project:

• Availability - Many techniques for achieving availability are properly studied as part of other courses, such as ECPE 276, Cloud Computing.
• Graphical User Interface - Fancy graphical user interfaces (or, indeed, any GUI) are not required for this project. If you choose to build a GUI, ensure that its construction does not take away time from the security elements, which are the high priority in this course. Usability is more important than aesthetics.

Project Topics

The required security elements listed above can manifest themselves in a variety of different systems. Choose a system from the list of examples below to implement, or propose your own system.

• Chat program - Allow users to send private messages (text, images/videos?) with other users. (Example: Signal)
• Social network - Allow users to form links in a social network and share information with other users.
• Distributed storage - Allow users to share and synchronize their files across multiple computing devices. Ensuring data integrity and privacy is of utmost importance.
  • In lieu of files, similar designs could be implemented in the form of a password manager or bitcoin e-wallet, synchronizing data across multiple computing devices.
• Electronic voting - Allow citizens to vote, and then collect and tally their votes. Ensuring ballot secrecy and resisting tampering is of utmost importance.
• Bank internal software - Allow clients to operate a multi-branch banking system distributed across a geographic region. Ensuring that accounts are altered only by authorized parties is of utmost importance.
• Medical records software - Allow clients (doctors) in a multi-site health care organization to store and update patient medical records.
• Or other system of your own design...

Part 1 - Charter

Your project charter defines the members of your team (if any) and proposes the software system you intend to build. Your charter should include the following information:

Charter Overview:

• A working name for your system.
• The implementation language you are proposing to use, along with a brief description of your prior experience in that language.
• A link to the version control repository that you will use for software development. (Bitbucket, GitHub, etc...)
• (If Applicable) The members of your team (if any) and their contact information.
• (If Applicable) Your plan for a group weekly status meeting. It is strongly suggested that you meet, as a team, at least once a week out of class to discuss the status of your project.

Proposal:

• Provide a very short (1 paragraph) statement of the core vision or key idea for your system.
• Provide a short (no more than six items) bulleted list of the key features of the system.
• Provide a bulleted list of the essential security elements, and a one sentence description of how your system will incorporate each element.
• Provide a narrative description (3-4 paragraphs) of the system you intend to build.

Submission: Upload a PDF document to Canvas.

Grading: The Charter document will be evaluated against the following criteria:

• Whether your document is easy to understand, well organized, and clearly written. Correct English style and usage counts here, just as it does in the real world.
• Whether the key features listed cover the full scope of desired features (not the details)
• Whether the narrative description is sufficiently clear and comprehensive to allow a different group to start working on your project and achieve your vision.

Part 2 - Requirements Document

Your requirements document provides a full proposal for the system that your team will build. It should contain the following five sections:

(1) System Purpose. In 3-4 paragraphs, explain the purpose of your system. The basis for this explanation should be the one-page system summary you wrote in Part 1. Update that summary as necessary, based on the functional requirements and security goals you develop in this document.

(2) Functional Requirements. Invent a list of functional requirements for the system you are building. For the purposes of this project, a functional requirement comprises the following data:

• User type - The type of user involved in this requirement.
• Assets - The critical information involved in this requirement.
• Importance - The importance of this requirement to your system's purpose. Use the MoSCoW method scale to rank importance:
  • M. Must have.
  • S. Should have, if at all possible.
  • C. Could have, but not necessary.
  • W. Won't have now, but would like to add later.
• User story - A brief description of a single kind of interaction a user can have with your system. User stories describe what your system will do, but not how. You should follow this template for a user story: "As a user, I can action, so that purpose." The purpose clause of a story might be obvious enough to omit that clause. Note that stories shouldn't be about developers or attackers, that will come later.

You might find it helpful to organize your requirements in a spreadsheet, so that you can sort them in various ways.

Here are four example functional requirements for a hypothetical grade management system for academic courses:

User type	Assets	Importance	User story
professor	assignment	M	As a professor, I can create a new assignment by specifying its name, number of possible points, and due date.
student	submission	S	As a student, I can submit a file as a solution to an assignment.
grader	grade	M	As a grader, I can assign a number of points as a grade to a student for an assignment.
student	grade	S	As a student, I can view my grades for all assignments.

Good user stories satisfy the INVEST criteria for agile software development:

• Independent - Stories shouldn't overlap, and ideally you should be able to implement them in any order, although some orders might make more sense than others.
• Negotiable - Stories might need to change as your project evolves.
• Valuable - Stories add value to your system for users. The general template above ensures that you think in terms of that value.
• Estimable - Stories' importance can be estimated, hence ranked. And stories' implementation time can be estimated. If you can't estimate, you probably don't understand the story. Consider adding more detail or breaking it into smaller stories.
• Small - Stories should be succinct, probably no more than one to four sentences.
• Testable - Stories represent testable goals. If you can't decide whether you've met a goal—that is, if you can't write a test that a skilled outsider could follow to determine whether your system fulfills a story—then your story isn't clear enough.

The above user story examples satisfy the INVEST criteria reasonably well. But here's an example that doesn't satisfy the criteria:

User type	Assets	Importance	User story
professor	survey	C	As a professor, I can conduct online surveys of students, so that I don't have to print and collect paper surveys.

This user story doesn't specify what a survey is, how students will take it, how results will be tabulated and presented, etc. It should be broken down into smaller stories. And this is likely how you will proceed with inventing user stories: write stories that are too "big" at first, then refine them.

(3) Threat Analysis - Identify threats of concern to your system. Concentrate primarily on malicious, human threats. What kinds of attackers will your system defend against? What are their motivations, resources, and capabilities? Don't just list vague, generic threats. Make them specific to your system and its functionality. If there are any non-threats, you should identify them, too. For example, you may wish to assume that some system components execute on hardware that is located in a physically secured machine room reachable only by trustworthy system operators.

(4) Security Goals - Identify the assets and stakeholders involved with your system. This step should be easy, because you already identified assets and users for each functional requirement. For each asset, identify what its value is to stakeholders.

Perform a harm analysis on assets. Use the template "performing action on/to/with asset could cause harm." (Although you are encouraged to rewrite statements made with that template into more natural English.) Be as thorough and creative here as possible; this is the step at which you're most likely to overlook something that's important and relevant to security.

Transform the harms you've identified into security goals, using the template "the system shall prevent action on/to/with asset." Label each goal as being exactly one of confidentiality, integrity, or availability. Examine the feasibility of each goal in light of your threat analysis. If necessary, relax goals so that it is feasible to achieve them.

You must document all of these steps, showing your assets and stakeholders, harm analysis, feasibility analysis, and resulting security goals.

Submission: Upload a PDF document to Canvas.

Grading: The Requirements document will be evaluated against the following criteria:

• Whether your document is easy to understand, well organized, and clearly written. Correct English style and usage counts here, just as it does in the real world.
• Whether the system purpose gives a clear summary of the system you are building.
• Whether the functional requirements seem sensible given the purpose of the system.
• Whether the functional requirements are clear and seem complete.
• Whether the functional requirements adhere to the INVEST criteria.
• Whether the threats of concern and their characteristics are described clearly.
• Whether you have documented all the steps you went through in crafting your security goals, including your harm and feasibility analyses.
• Whether you have correctly identified each security goal as being related to confidentiality, integrity, or availability.
• Whether the security goals you identify are sensible for the system purpose, planned functionality, and threats of concern.
• Whether your have successfully argued that a majority of security elements are involved in your system.

Part 3 and Part 4 - Code Sprints!

Parts 3 and 4 for the project involve the same essential work. You will engage in a sprint, which is a fixed length of time during which you build a "shippable" increment of your system. Your sprints will last three weeks. At the end of each sprint, you will ship the latest increment of your system and provide a demo of it to your class. You have two sprint cycles — named alpha and beta — to implement your project.

Features - You are empowered to decide what features you will deliver as part of each sprint. But the Alpha sprint should demonstrate functionality related to Audit, while the Beta sprint focuses on Authentication and Authorization functionality.

Source Control - You are required to keep your project in a source control system. There are many free possibilities (GitHub, Bitbucket, ...) that provide code hosting, bug tracking, and wikis. Under no circumstances should you resort to emailing your entire source code between team members.

Assurance - You should prepare a document that explains how and what you have tested in the source code being submitted. Issues to discuss include:

• How you tested individual methods, classes, and units
• How you tested the integration of units, especially those written by different programmers
• How you tested the features you are delivering
• How you tested to ensure that security requirements are met
• Whether you did any pair programming or code reviews
• How much code coverage your test suite achieves
• How often you run regression tests.

Static Analysis Tool - You are required to use a static analysis tool to evaluate your code.

Demo - During class, you will demo your program on the day that it is due. Bring laptops that have your system installed and running. The instructor and the other project teams will use your system and report on how well it appears to be working and achieving its security goals. Demos typically involve some or all of the following events, though there is necessarily some flexibility involved:

• You demo a few user stories (functional requirements) that you've marked as completed. Any bugs seen during that demo would be especially unimpressive. The instructor or your classmates might try weird inputs, strange user behavior, etc., in an attempt to find such bugs.
• You exhibit source code for features you are delivering. Code quality matters.
• You discuss the design and implementation of any security functionality you are delivering.
• The instructor and classmates ask you questions. Questions about the security of your system could be directed to any specific member of the group. All members should be able to explain and defend the security-relevant choices your group made.

Submission - Upload the following to Canvas:

• An updated version of your requirements document, clearly showing which requirements have been implemented and which are still pending
• An assurance document describing your approach and tasks completed to date
• .zip or .gz file with a compiled executable
• PDF document with installation and execution instructions
• Link to your version control repository

Part 5 - Final Submission

Submit an updated version of your requirements document that serves as a final report. In this document, add discussion of how your design addresses these requirements:

• Authorization: What types of authorization policies are being used (DAC vs. MAC)? How are they implemented? How are changes to policies handled?
• Authentication: How are users and programs authenticated?
• Audit: How is accountability for user actions provided?
• Confidentiality: How is data confidentiality maintained?
• Integrity: How is data integrity maintained?
• How are secrets (e.g., passwords) chosen/generated, stored, updated, and erased? Probably you will have implemented some use of cryptography, so it would be appropriate to discuss issues such as how you generate and erase keys, how and where keys are stored, the exact cryptographic algorithms being used, sizes of keys and nonces, and assumptions about operating system functionality.
• Assurance: How and what have you tested in the source code being submitted? Issues to discuss include how you tested individual methods, classes, and units; how you tested the integration of units, especially those written by different programmers; how you tested the features you are delivering; how you tested to ensure that security requirements are met; whether you did any pair programming or code reviews; how much code coverage your test suite achieves; and how often you run regression tests.

Grading - The design and implementation of your system, including your code, will be evaluated on how well it exemplifies the various principles of security, the extent to which your system fulfills its purpose, realizes its security goals against threats of concern, and involves the essential security elements. Readability, simplicity, documentation, and testing will be included in this evaluation.

Grading

Your project grade will be calculated as follows:

• Part 1 - Charter Document: 5%
• Part 2 - Requirements Document: 20%
• Part 3 - Alpha Sprint (Code and Demo): 10%
• Part 4 - Beta Sprint (Code and Demo): 20%
• Final submission: 45%

Submission

Submit all files to the Canvas CMS site. Only one submission is needed for the group.

There will be separate Canvas assignments for:

• Part 1 - Project Charter (Upload as .pdf)
• Part 2 - Project Requirements Document (Upload as .pdf)
• Part 3 - Alpha Sprint
• Part 4 - Beta Sprint
• Project Final Code (submit link to version control repository and upload compiled binary)

With thanks to the original Practicum in System Security course, CS 5431, at Cornell