4.2 The Security Artifacts
5.1.1 Creating the SSRT Structure
The elements of the SSRT are used to create a tree structure based on the constraints/as- sumptions. The tree connects general requirements directly to constraints/assumptions, which then have associated software security requirements. Therefore, the SSRT provides a direct relationship between general requirements and software security requirements. The structure of the SSRT is created using an algorithm, so that general software requirements are correctly linked to needed software security requirements.
Figure 5.2 shows the SSRT creation algorithm, which operates on each constraint/as-
sumption, and decomposes them intousage conditions. The decomposition into usage condi-
tions is located on line 3 of the creation algorithm, and is the critical step at linking general requirements to software security requirements. The usage conditions specify when the con- straint/assumption can be violated, which is the only time the associated software security requirements are necessary in a project. An example constraint/assumption decomposition is shown in figure 5.3(a). The example starts with a constraint involving data confidentiality, which is evaluated to determine all scenarios, or usage conditions, where the data confiden- tiality constraint can be violated. In this example, there are five usage conditions that may result in the constraint being violated.
2: foreach constraintAssumption from list.constraintAssumptions do
3: list.conditions ⇐ constraintAssumption.usageConditions
4: for each condition from list.conditions do
5: queue.components ⇐ condition.componentQueueStartingWithMostBroad 6: currentNode⇐ root 7: currentComponentText⇐ string.empty 8: currentComponent ⇐queue.components.begin 9: while queue.components.notEmptydo 10: queue.components.removeFirst
11: if currentNode.list.branches.component contains componentthen
12: currentNode⇐ branch.childNode
13: else
14: Create newNode
15: Create newBranch
16: newBranch.childNode ⇐ newNode
17: currentComponentText ⇐currentComponentText + ’.’ + currentComponent
18: newBranch.descriptor⇐ currentComponentText
19: Add to currentNode.list.branches ⇐newBranch
20: currentNode⇐ newNode
21: end if
22: currentComponent ⇐ queue.components.next
23: end while
24: add constraintAssumption to currentNode.list.constraintAssumptions
25: end for
26: end for
Figure 5.2: The SSRT Creation Algorithm
The SSRT creation algorithm then continues on line 5, to decompose usage conditions
intocomponents, which are ordered in a queue from most broad to most specific. One usage
condition in the provided example is decomposed into components, as shown in 5.3(b). The logic in the example is that output to a network requiring confidentiality is only possible with output to a network, which is only possible with any form of output.
(a) Constraint decomposed into usage conditions
(b) Usage condition decomposed into components
Figure 5.3: Example of Critical Steps in SSRT Creation Algorithm
The remaining portion of the SSRT creation algorithm uses the component queue to determine a location in the tree. The constraint/assumption that led to the component queue is then added to that location in the tree, and parts of the component queue are
attached to the branches as a descriptor along the path. Figure 5.4(a) depicts this process
by taking the component queue shown in 5.3(b), and placing it into a tree as if it were the only component queue used so far. The tree is initialized with one node, the root node, and when a constraint/assumption has no usage conditions, it will be added to that node.
(a) Components from 5.3(b) inserted into tree using the creation algorithm
(b) Tree structure from (a) has usage description and software security requirement lists filled in
Figure 5.4: Example of Critical Steps in SSRT Creation Algorithm
After completing the creation algorithm on all constraints/assumptions, a tree structure is produced. Each node in the tree may have constraints/assumptions associated with it, and may have children nodes connected through branches. Each branch must have a usage description, but the creation algorithm has produced descriptors instead. The next step is converting those descriptors into a positive usage description, that provide details as to when this branch is used. The next step is converting the constraints/assumptions in a
node to lists of software security requirements associated to those constraints/assumptions. The conversion steps of the continuing example are shown in figure 5.4(b), which is the same as figure 5.4(a) except with usage descriptions and a software security requirement list. The final step is considering whether the usage description utilizes any potential information security requirements. If it does, an additional statement must be added to the branch usage description to specify that the branch must be used in all cases of the information security requirement absence. Currently, this is only occurs with sensitive data. If a project does not define sensitive data, then all data must be considered sensitive. Once all the components and constraints/assumption have been converted to usage descriptions and software security requirement lists, the tree structure is ready for use, and can be used to gather software security requirements as described in 5.1.2.
Figure 5.5: The Structure of the SSRT
The tree structure that resulted from the SSRT creation algorithm is the SSRT, shown in figure 5.5. The letters in the figure correspond to a branch usage description, while the num- bers correspond to software security requirement lists. Both the branch usage descriptions, and the lists of software security requirements are presented in greater detail in appendix C.