System engineering and system assurance are intimately related. To assure a system means to demonstrate that system engineering principles were correctly followed to meet the security goals. However, “good” system engineering as it is commonly understood does not guarantee that the resulting system will have the necessary level of system assurance. The need for providing additional guidance for system assurance is based on the rapid evolution of threats and changes in the operating environments of systems. The assurance of systems has usually been relegated to various processes as part of a broader systems engineering strategy. For example, discussion and validation of requirements is performed to ensure a consistent program definition and architecture. Testing and evaluation are done to ensure that the developed system meets its specifications and the requirements behind them. Various organizational audits and assessments track the use of systems engineering principles throughout the program's life cycle, to ensure that organizational performance is a function of good practice. Because of the complexity and nature of the evolving threats, however, it is important to plan and coordinate these practices and processes, to keep the threat in mind across the system's life cycle. System assurance cannot be executed as an isolated business process at a specific time in the program's schedule, but must be executed continuously from the very earliest conceptualization of the system to its fielding and eventual disposal.

Today, the risk management process often does not consider assurance issues in an integrated way, resulting in project stakeholders unknowingly accepting risks that can have unintended and severe financial, legal, and national security implications. Addressing assurance issues late in the process or in a nonintegrated manner may result in the system not being used as intended, or in excessive costs or delays in system certification or accreditation. Although assurance does not provide any additional security services or safeguards, it rather refers to the security of the product or service and that the product or service fulfills the requirements of the situation, and satisfies the Security Requirements. This may appear to be a less than important aspect at first sight, particularly when the cost of providing or obtaining assurance is factored in. However, it should never be forgotten that, while assurance does not provide additional security services or safeguards, it does serve to reduce the uncertainty associated with vulnerabilities, and thus, often eliminates the need for additional security services or safeguards. Risk management must consider the broader consequences of a failure (e.g., to the mission, people's lives, property, business services, or reputation), not just the failure of the system to operate as intended. In many cases, layered defenses (e.g., defense-in-depth or engineering-in-depth) may be necessary to provide acceptable risk mitigation.

The System Security Engineering Capability Maturity Model (SSE-CMM) developed by ISSEA [SSE-CMM 2003], considers risk assessment, engineering, and assurance as key components of the process that delivers security and, although these components are related, it is possible and useful to examine them separately. The risk assessment process identifies and prioritizes threats to the developing product or system, the security engineering process works with other engineering disciplines to determine and implement security solutions, and the assurance process establishes confidence in the security solutions and conveys this confidence to stakeholders (see Figure 5).

The Risk Assessment – A major goal of security engineering is the reduction of risk. Risk assessment is the process of identifying problems that have not yet occurred. Risks are assessed by examining the likelihood of the threat and vulnerability and by considering the potential impact of an unwanted incident. Associated with that likelihood is a factor of uncertainty, which will vary dependent upon a particular situation. This means that the likelihood can only be predicted within certain limits. In addition, impact assessed for a particular risk also has associated uncertainty, as the unwanted incident may not turn out as expected. Because the factors may have a large amount of uncertainty as to the accuracy of the predictions associated with them, planning and the justification of security can be very difficult. One way to partially deal with this problem is to implement techniques to detect the occurrence of an unwanted incident.

An unwanted incident is made up of three components: threat, vulnerability, and impact. Vulnerabilities are properties of the asset that may be exploited by a threat and include weaknesses. If either the threat or the vulnerability is not present, there can be no unwanted incident and thus no risk. Risk management is the process of assessing and quantifying risk, and establishing an acceptable level of risk for the organization (see Figure 6). Managing risk is an important part of the management of security.

Risks are mitigated by the implementation of safeguards, which may address the threat, the vulnerability, the impact, or the risk itself. However, it is not feasible to mitigate all risks or completely mitigate all of any particular risk. This is in large part due to the cost of risk mitigation and to the associated uncertainties. Thus, some residual risk must always be accepted. In the presence of high uncertainty, risk acceptance becomes very problematic due to its inexact nature. One of the few areas under the risk taker's control is the uncertainty associated with the system.

The Engineering – Security engineering is a process that proceeds through concept, design, implementation, test, deployment, operation, maintenance, and decommission. Throughout this process, security engineers must work closely with the other system engineering teams. This helps to ensure that security is an integral part of the larger process, and not a separate and distinct activity. Using the information from the risk process described above, and other information about system requirements, relevant laws, and policies, security engineers work with the stakeholders to identify security needs. Once needs are identified, security engineers identify and track specific requirements (seeFigure 7).

The process of creating solutions to security problems generally involves identifying possible alternatives and then evaluating the alternatives to determine which is the most promising. The difficulty in integrating this activity with the rest of the engineering process is that the solutions cannot be selected on security considerations alone. Rather, a wide variety of other considerations, including cost, performance, technical risk, and ease of use must be addressed. Typically, these decisions should be captured to minimize the need to revisit issues. The analyses produced also form a significant basis for assurance efforts.

Later in the life cycle, the security engineer is called on to ensure that products and systems are properly configured in relation to the perceived risks, ensuring that new threats do not make the system unsafe to operate.

The Assurance – Assurance provides a very important element when performing a security risk assessment and during the risk management phase of determining if additional safeguards are required and if so, whether they are implemented correctly by engineering. Although assurance does not live in isolation, we can distinctly talk about assurance life cycle, assurance requirements, assurance infrastructure, assurance stakeholders, assurance management, and assurance specialized expertise (see Figure 8). For this reason, there is a need to treat assurance as a stand-alone discipline and as such, it is explored in detail throughout the book.

The umbrella component in system assurance is “assurance case,” which is defined as a reasoned, auditable argument created to support the contention that a defined system will satisfy particular requirements, along with supporting evidence. This structured approach allows for the documentation of all relevant information that can be analyzed to validate if the application is meeting the set objectives, which lends itself to a repeatable process that allows you to go back and review the information to justify any decisions made based on the results of the assessment. It also aids the collection of supporting evidence at different points over time, providing the ability to analyze trends in both risk and trustworthiness [[Toulmin 1984] and [Toulmin 2003]], [Kelly 1998], [NDIA 2008], [ISO 15026].

The purpose of assurance case is to convince stakeholders, such as system owner, regulators, or acquirers, about certain properties of the system that are not obvious from system descriptions. Thus, a security assurance case is about confidentiality, integrity, and availability of information and services provided by the systems in cyberspace. In other words, assurance case is the documented assurance (i.e., argument and supporting evidence) of the achievement and maintenance of a system's security. It is primarily the means by which those who are accountable for the mission, system, or service provision, assure themselves that those services are delivering, and will continue to deliver, an acceptable level of security.

Assurance case was developed by the safety community, primarily in the UK where it has been mandated by a number of legislations as the means to argue about safety of systems [Kelly 1998], [Wilson 1997]. Assurance case is necessary for regulators, as the main objective of regulation of certain activity is to ensure that those who are accountable for the security discharge their responsibility properly followed by an adequate means of obtaining regulatory approval for the service or project concerned.

The development of an assurance case is not an alternative to carrying out security assessment; rather, it is a means of structuring and documenting a summary of the results of such an assessment and other activities (e.g., simulations, surveys, etc.), in a way that a reader can readily follow the logical reasoning as to why a change or ongoing service can be considered safe and secure.

Procurers of critical computer-based systems have to assess the suitability of implementations provided by external contractors. What an assessor requires is a clear, comprehensible, and defensible argument, with supporting evidence that a system will behave acceptably.

The designers of a system will obviously take security requirements into account, but the satisfactory design and implementation of such requirements does not manifest itself clearly in the models and artifacts of the development process; for example, one cannot look at a development process and assume a system's reliability and security.

A contractor may provide the assessor with a large amount of diverse material on which to make their assessment. They may provide a formal specification of the system and a design by refinement. They may produce hundreds of pages of carefully crafted fault tree analysis. They may place great emphasis on the coverage and success of the system testing strategy. Each of these sources may provide a useful line of argument or a key piece of evidence, but individually they are insufficient grounds for an assessor to believe that a system is acceptably secure.

Also, individual analyses models are likely to be based on a number of underlying assumptions, which are not easily captured in the model itself. There will always be issues that cannot be captured in any specific analysis model; principal amongst these is the justification of the model itself.

What an assessor requires is an overall argument bringing together the various strands of reasoning and diverse sources of evidence in the form of an assurance case, which makes clear the underlying assumptions and rationale. An effective assurance case needs to be a clear, comprehensive, and defensible argument that a system will behave acceptably throughout its operations and decommissioning.

There is a need for analysis models and artifacts to derive measures of security, reliability, etc., to make the properties manifest and controllable.

A structured account of these analyses models is usually presented to the appropriate regulatory authority as an assurance case.

An assurance case consists of four principal elements: objectives, argument, evidence, and context. Security case will emphasize security objectives, namely confidentiality, integrity, and availability. To assure security, the systems owner has to demonstrate that security objectives are addressed. The security argument communicates the relationship between the evidence and objectives and shows that evidence indicates that objectives have been achieved. Context identifies the basis of the argument. Argument without evidence is unjustified and therefore, unconvincing. Evidence without argument is unexplained—it can be unclear that (or how) security objectives have been satisfied. [Eurocontrol 2006]

Requirements are supported by claims. Claims are supported by other (sub) claims. Leaf sub-claims are supported by evidence. The structured tree of sub-claims defines context for argument.

System assurance provides coordinated guidance for multidisciplinary, cross-domain activities that generate facts about the system, and use these facts as evidence to communicate the discovered knowledge and transform it into confidence. The aim of the end result is to achieve the acceptable measures of system assurance and manage the risk of exploitable vulnerabilities.

The confidence produced using this formal approach can be viewed as product due to the following characteristics:

Today, most of assessment activities that make up assurance processes are informal, subjective, and manual due to lack of comprehensive tooling and agreed-upon assurance content in machine-readable form, which makes assessment approaches resist automation. Less automation means a laborious, unpredictable, lengthy, and costly assurance process.

The good example would be the Common Criteria (CC) Evaluation Assurance Process [ISO 15408], [Merkow 2005]—IT system certification process of commercial products that will be deployed in the government environment. CC Evaluation Assurance Levels (EAL1 through EAL7 numerical rating) of an IT system reflect at what level the system was tested to verify if it meets all of its security requirements. The intent of the higher levels is to provide higher confidence that the system's principal security features are reliably implemented, focusing on covering development of product with a given level of strictness, and only higher EALs involve evaluation of formal system artifacts (EAL 5 – to EAL 7), leading to a costly and laborious evaluation process.

In 2006, the US Government Accountability Office (GAO) published a report on common criteria evaluations that summarized a range of costs and schedules reported for evaluations performed at levels EAL2 through EAL4 [GAO-06-392 2006] that is summarized in Figure 11.

While certification cost for EAL1 through EAL4 is measured in hundreds of thousands of dollars, EAL5 through EAL7 is measured in millions of dollars. For example, EAL 7 of OS Separation Kernel can cost up to $5M and last up to 2.5 years—not so practical to be applied across all systems.

Automation in security assurance would be game changing.