Verification with the Security Artifacts

Each software security requirement used in a project must be verified at the end of the design, and implementation phases using the security artifacts given in the previous section. If a security artifact is not verified, then whether the corresponding software security requirement is used correctly is unknown. The verification process differs slightly depending on the phase of development, but each only uses the security artifacts designated for the particular phase. The verification processes are as follows:

Design phase verification compares the design artifacts of every software security re-

quirement included in the project with the design documentation. The design ar- tifacts are a collection of decisions, and if a comparable decision cannot be found in the design documentation, then the design documentation cannot be considered complete. Once all the security artifacts found in design have been verified in the design documentation, the implementation phase can begin.

Implementation phase verification differs slightly the design phase verification, because each code artifact must be critically analyzed to determine all possible locations in code the artifact will be present. Each place in code is then compared against the code artifact. If the code does not match the code artifact, it is re-written until it can be verified. The code artifact has finished verification when all expected places in code contain the artifact. The entire implementation phase is considered complete when all security artifacts found in code have been verified.

Once the software security requirements have been verified in the design and imple- mentation, a level of assurance is provided for correct translation of the software security requirements. However, verification does not guarantee correct inclusion of the requirements nor does it guarantee bug-free software, so the remaining full VV&T strategies presented in 4.1.1 must be used along with verification.

4.3 Summary

This chapter presents how to use VV&T with the software security requirements to ensure their proper translation into the design and implementation of a project. Only full VV&T is supported by this research, because it is the only VV&T strategy where security concerns start during requirements engineering. Validation and testing strategies provided by full VV&T are easily used with the software security requirements because the requirements were designed to be testable. Verification in VV&T is supported by the security artifacts which were generated from each software security requirement. The security artifacts support developers with limited security knowledge, by providing examples of what is expected in design and code. Lastly, a verification process that uses the security artifacts is provided for the design and implementation phases, to clearly explain how verification must occur.

Support for Software Security Requirements Selection

The list of software security requirements is long, and many projects will not have the need for all the requirements since a project may only face a subset of vulnerabilities that the requirements are designed to prevent. This creates a problem for developers; unnecessary requirements increase the workload in the design and implementation as verification and validation strategies are conducted on requirements that are never used. Unfortunately, the software security requirements are targeted at developers without security knowledge, who may not have the capability of removing the unnecessary requirements correctly.

5.1 Software Security Requirements Tree

The Software Security Requirements Tree (SSRT) associates software security require- ments with general software requirements. This places a condition on the use of the SSRT - a development team cannot select the necessary software security requirements until the more general, non-security related, software requirements have been generated. Once all the general software requirements have been written, they can be used to select which software security requirements are needed.

Figure 5.1: Elements of the SSRT

The SSRT contains four basic elements: nodes, branches, usage descriptions, and soft- ware security requirement lists. Figure 5.1 shows a portion of the SSRT with the elements labeled in italicized text. The software security requirement list in the top node is blank because the node contains no software security requirements.

Nodes represent the general requirements of a project. A node can connect to another

node through a branch, where a parent/child relationship is created between the connected nodes. In the given figure, the node with the arrow pointing to it is the child, while the node connected at the other end is the parent. The child node represents a subset of the general requirements contained in the parent node. In this example, the parent node is input, while the child node is a subset of input, more specifically, input from an environment variable. A node can have multiple children nodes, but only one parent node.

Branches connect nodes in the SSRT. A single branch is connected to two nodes, one

of which is a child, and the other a parent. When using the SSRT, the branches must be traversed from the parent node, to the child node. In figure 5.1, the child node has an arrow pointing to it, while the node connected on the other end is the parent.

Usage descriptions are associated with a branch and the branch’s child node, which is

shown in the provided example with dashed arrows. The usage description clearly states in positive terms what general requirements the child node represents. The simultaneous association with the branch and child node may seem unnecessary since a branch can only be connected to one child node, but the distinction was made for the different scenarios the structure faces. When creating or navigating the SSRT, logically it makes sense to associate the usage description with the branch. However, when using the prototype SSRT tool, described in 5.1.3, it is more logical to associate the usage description with the child node.

sents general requirements contained in a project, the software security requirements in the associated list must be used by the project in development.