Part 2
In the first article in this series, I explained the need for system security engineering and how it works. I also explored the first two SSE contexts: Problem and Solution. In this article, I address the core of the third and final Trustworthiness context: the assurance case. I provide a simple, practical approach and an example case.
Trustworthiness Context
The purpose of the Trustworthiness context is to demonstrate that the system is designed to safely operate within the target production environment while meeting all business operations and security governance expectations. This is done with a security assurance case.
A security assurance case tracks the security design of a system and includes detailed proof of how the security objectives and requirements were met. It includes assumptions, constraints, and inferences that impact the decision-making process.
When properly designed, assurance cases inform those responsible for governance that the system complies with internal policies and regulations. Cases also help the project team, the security team, and the governance team identify misses or gaps.
Assurance Case Overview
We construct assurance cases with structured notation methods. One of the popular methods is Goal Structuring Notation (GSN) developed at the University of York in the early 1990s. GSN is standardized, and I used it in this article. The standard is free and downloadable from the UK Safety-Critical Systems ClubOpens a new window .
Core Elements
The GSN includes a large number of symbols. Using all of them can increase the complexity of assurance cases. Complex assurance cases are not useful when trying to demonstrate system trustworthiness to those responsible for governance. Consequently, I restricted my example to the core GSN elements: goals, strategies, contexts, solutions, justifications, and assumptions.
Goals (Claims)
Goals are the foundation of an assurance case, and we represent them with a rectangle using the label “G.†They present an overall claim about the security of the system and sub-claims that support that top-level claim.
The claim is that the system is reasonably and appropriately secure. It is essential to use the right qualifiers to ensure that stakeholders understand what is being presented.
Each goal has an identifier. In this case, G1. Each of the core elements has an identifier format. These identifiers make it easy to refer to supporting documentation.
Figure 3 shows how we continue to break down the goals. Proving sub goals proves the parent goal. For example, proving goals G15 through G17 proves G12. Proving G10 through G14 proves G6, and so forth up to G1.
In this example, I used the five areas of concern detailed in the NIST Cybersecurity Framework as goals G5 through G9. We break these down as needed to provide as much detail as needed clearly to demonstrate the assurance case argument.
Each series of claims is an argument for assurance. For example, all elements following G1 compose the argument for G1. All claims under G12 in Figure 3 form the argument for G12.
The diamonds in Figure 3 are GSN notations for goals that have not yet been developed.
Strategies
A strategy element helps defines the nature of an argument. It helps us understand the reasoning behind the claims. Strategies are represented with trapezoids and the label “S.†They apply to the entire argument beneath them.
Contexts
Correctly interpreting a claim requires understanding the context in which we make it. This is the role of the context element. Figure 5 shows the rounded-corner rectangles, C2 and C3, that help understand the sub-claim G2. The contexts also apply to all other arguments under G2.
Solutions
We apply solutions to the final level of sub-claims. Figure 6 shows the solutions, Sn1 through Sn3 for the detection argument thread. Each solution requires a detailed document that describes:
- The objectives addressed
- The requirements satisfied
- How the implementation or configuration of relevant administrative, physical, and logical controls enabled relevant preventive, detective, and response efforts in support of confidentiality, integrity, and availability
Justifications and Assumptions
Although I did not include them in my example, justifications and assumptions are often necessary for clarification. A justification (J1 in Figure 7) provides the reasoning behind an element. A justification only applies to the element to which it is attached: not the entire following argument.
An assumption (A1 in Figure 7) is just that; it provides an unsubstantiated statement about a condition or other characteristic of a claim or strategy. The assumption must be valid for the claim or strategy to be true. An assumption applies to the entire argument that supports a claim.
Building Assurance Cases
Assurance cases should be started as early in the SDLC as possible. This allows addressing each claim, its contexts, and how it breaks down. It is much easier to do this than to wait and try to create the assurance case at the end of the design or development processes. The GSN standard consists of many more symbols in addition to those I used in this article. Use what you need to develop your assurance cases.
You do not have to start with a blank sheet every time you start a case. Instead, your first case becomes what is known as an assurance case pattern. The start of an assurance case in this article is an example of how you could build a pattern based on the NIST Cybersecurity Framework. Each pattern is adjusted as you work through specific system projects.
Avoid Common Assurance Case Errors
The GSN standard provides a clear description of what not to do when building a case.
- Do not try to describe too much in a claim. Claim only one thing. If more is needed, break it into multiple claims. The same applies to all other elements. Each element can be broken down if needed.
- Strategies should not include part of the claim argument. In other words, strategies are not functional statements. This is why we begin them with “Argument by appeal to…,†“Argument by…,†“Argument across…â€
- Do not try to summarize claims, contexts, or solutions in case elements. Use supporting documentation for all summaries and detailed analysis.
- Do not do anything that prevents the goal structure from clearly demonstrating the arguments. Ensure that goals only include claims and solutions refer to detailed documentation.
- Do not use contexts and solutions for anything other than references to documentation.
- Do not be ambiguous or vague in your element text.
- Avoid oversimplification. When necessary, break down goals as necessary to clearly show the elements of the case arguments. Apply context and strategy elements where necessary. Additional GSN elements like justification help with clarification.
- Do not confuse contexts with solutions. The standard provides the example in Figure 8 to help explain this. C4 is not a context. Instead, it is a solution.
- Do not make leaps of faith. Ensure that it is clear how you arrived at a sub-claim from a parent claim. This often requirements adding addition sub-claims between them.
- Do not add a solution too early. Make your claims detailed enough to demonstrate how your solution meets specific claim challenges.
Conclusion
Security assurance cases provide the means to provide a detailed analysis of steps taken to ensure a reasonably safe system, given business operational requirements and management’s appetite for risk. A case should start as early as possible in the SDLC, evolving as objectives and requirements are defined; and as we consider and finalize designs.
Keep case diagrams as simple as possible without losing clarity. Your details should remain in the documentation referred to in your case elements. A presentation of the case diagram should enable management fully to understand challenges and residual risk.
In the third and final installment in this series, I look at the processes that support assurance throughout the life of a system.