Project Milestone 1: Requirements:

Part II: Security Requirements

Part II of your Requirements Document should contain the following information.

Threat Analysis

Identify the threats of concern to your system, including their motivation, resources, and capabilities.

Security Goals

Note: lecture notes are available on this material.

Identify the assets and stakeholders involved with your system. This step should be easy, because you already identified assets 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." 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." Tag each goal as being a confidentiality, integrity, or availability property. 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 us your asset analysis, harm analysis, feasibility analysis, and security goals.

Security Requirements

Actually, you do not need to produce security requirements as part of this milestone. Instead, you will produce them throughout the remaining milestones as you implement your functional requirements.

Essential Security Elements

The project overview identified several essential security elements: authorization, authentication, audit, confidentiality, and integrity. Recall that to be acceptable as a course project, your system must involve each of these elements in a way that is essential to the system's purpose. Here, you should document why each element is essential to your system. If you can't construct a persuasive argument for an element E, you need to revisit your system purpose and invent new features that will cause E to be essential.

Evaluation

We will evaluate Part II of your Requirements Document 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 threats of concern and their characteristics are described clearly.
• Whether you have thoroughly 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 arguments for the essential security elements are persuasive.