As noted in Section 2.1.3, according to DHS, software assurance provides
“a basis for justified confidence” in a required property of software (or of a software-intensive system). This basis for justified confidence may take the form of an assurance case. T. Scott Ankrum and Charles Howell [111] define an assurance case as—
A documented body of evidence that provides a convincing and valid argument that a specified set of critical claims regarding a system’s properties are adequately justified for a given application in a given environment.
An assurance case documents assurance arguments and assurance claims about a software component, product, or system, and provides the necessary evidence of the validity of those arguments and claims sufficient to reduce uncertainty to an acceptable level, thus providing the grounds for justified confidence that the software exhibits all of its required properties. For this document, the required property of interest is security.
The assurance case should be developed alongside the software component or system itself. The information added to the assurance case at each life cycle phase will vary based on the level of assurance that is sought.
There is an increasing emphasis, in the software assurance community, on defining standards for the content and evaluation of security assurance cases
Software Security Assurance State-of-the-Art Report (SOAR) 101
Section 5 SDLC Processes and Methods and the Security of Software
for software. The only claim that can be realistically made for software security assurance cases at this point is that they will provide a useful mechanism for communicating information about software risk. To date, there has been little if any empirical evidence that assurance cases can or will improve the security of software or increase the level of trust between users and software suppliers.
The most mature of the emerging software security assurance case standards, SafSec (see Section 5.1.4.2.1), has only been tested in two case studies. As of April 2007, the next stage of SafSec evaluation, which involves applying the methodology on a system under development, was still underway.
It would seem that so far, assurance case proponents have based their
expectation of the effectiveness of security assurance cases on an extrapolation from the success of safety cases (see Section 5.1.4.1) and to a lesser extent from CC STs (discussed in Section 4.8).
For Further Reading Assurance Cases.
Available from: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance.html Elisabeth A. Strunk and John C. Knight, “The Essential Synthesis of Problem Frames and Assurance Cases”, in Proceedings of the Second International Workshop on Applications and Advances in Problem Frames, May 23 2006.
CMU SEI, Assurance Case and Plan Preparation.
Available from: http://www.sei.cmu.edu/pcs/acprep.html
J. McDermott, “Abuse Case-Based Assurance Arguments”, in Proceedings of the 17th Annual Computer Security Applications Conference, December 2001: 366-374.
Available from: http://www.acsa-admin.org/2001/abstracts/thu-1530-b-mcdermott.html
5.1.4.1 Safety Cases as a Basis for Security Assurance Cases
The concept of an assurance case originated with the safety case. In response to several significant catastrophes that were traced to the failure of certain physical systems (e.g., space shuttles, off-shore petroleum drilling facilities), multiple safety standards and regulations emerged in the 1990s [e.g.,
Radio Technical Commission for Aeronautics (RTCA) DO-178B Software Considerations in Airborne Systems and Equipment Certification, ISO 14971 Application of Risk Management to Medical Devices, MIL-STD-882D DoD Standard Practice for System Safety, UK Defence Standard 00-56 Safety
Management Requirements for Defence Systems] specifying requirements for the verification of reliability and fault-tolerance in safety-critical systems.
Safety-critical systems constitute physical systems or devices (e.g., airplanes, nuclear power stations, medical devices), including their software-based monitoring and control components. These software
components are either embedded within or networked to the physical system they monitor or control. [An example of the former is an electric flight control system; an example of the latter is software in an air traffic control system or the
Software Security Assurance State-of-the-Art Report (SOAR)
102
Section 5 SDLC Processes and Methods and the Security of Software
Supervisory Control and Data Acquisition (SCADA, see Appendix C) software for climate monitoring and control in nuclear power plants].
To satisfy the mandates of the new safety standards and regulations, safety cases were conceived [112] to provide a formal documentary basis that regulators, auditors, etc., needed to verify with high levels of justified confidence the reliability and fault-tolerance of safety-critical systems. A new term was coined for systems and software that required the exhibition of critical properties (such as reliability, safety, and survivability) [113] to be verified with a high level of confidence: high confidence (as in High Confidence Software and Systems).
In addition to regulatory, standards, or policy compliance, safety cases can be a prerequisite of third-party certification, approvals to operate, licensing, and other situations in which a compelling case needs to be made that the system satisfies its critical properties for use in specific contexts, such as healthcare or avionics.
There is a growing academic trend in Europe whereby software safety research is being extended to include software security. Consistent with this trend, most research by into software security assurance case methodologies and tools is being done at European institutions that have long been engaged in software safety research. (Appendix H lists specific examples of such research)
Just as many other practices from the software safety and information assurance communities have proven adaptable for purposes of assuring security (e.g., formal methods, fault injection), so the notion of assurance cases for establishing confidence in the security of software has emerged.
Most currently defined software security assurance cases include—
u One or more claims about the required security attributes of the software
u A body of evidence supporting those claims
u Arguments that clearly link the evidence to the claims.
Depending on the nature of its evidence and the persuasiveness of its arguments, an assurance case can reduce uncertainty and lead to justified confidence in the software’s security, or it may provide grounds for a rational lack of confidence.
The body of evidence that supports each part of the assurance case can come in many forms. This evidence may reflect either direct analysis of the software (e.g., test results, code review results, mathematical proofs from formal methods) or review of indirect indicators that the claims are likely to be true, such as the nature of the development process used, the reputation of the development organization, and the trustworthiness and expertise of the individual developers.
5.1.4.2 Software Assurance Case Standards
Some significant efforts are underway in the research community to develop such tools, or to extend, adapt, and refine safety case tools to also accommodate the particular requirements of security assurance cases. Efforts are also underway to standardize the software assurance process and its relationship to the software and
Software Security Assurance State-of-the-Art Report (SOAR) 103 Intended Audience.
Section 5 SDLC Processes and Methods and the Security of Software
system development processes, as well as the required content and structure of assurance case artifacts. The most significant of these efforts are described below.
5.1.4.2.1 UK Ministry of Defence SafSec
SafSec [114] is an assurance methodology developed by Praxis High Integrity Systems in response to the requests of its sponsors in the UK Ministry of Defence (MOD) for a program that would “reduce the cost and effort of safety certification and security accreditation for future military Avionics systems.”
Praxis’ response was to develop the SafSec standard and guidance documents, which define a standard structure for producing and evaluating a combined assurance case for software safety/reliability and security. In this way, SafSec provides an integrated view of assurance: not only do safety, reliability, and security converge in the C&A domain, they converge in the development domain, as illustrated in Figure 5-3.
Figure 5-3. SafSec Convergence of Safety, Reliability, and Security Assurance
The SafSec standard seeks to overcome the following problems associated with other software assurance processes:
u It ensures completeness.
u It minimizes overlap and duplication of evidence, and thus reduces the evaluation effort and the associated costs. Evidence that supports both safety/reliability and security assurance claims needs to be generated only once.
5NIFIED 2ISK0ROCESS
!RCHITECTURAL -ODEL 3AFETY (AZARDS
/PERATIONAL 2EQUIREMENTS
2ELIABILITY 2EQUIREMENTS 3ECURITY
4HREATS
2ISK
2ISK
$IRECTED 0ROCESS
/PERATIONAL
!CCEPTANCE 3AFETY
#ERTIFICATION 3ECURITY
#ERTIFICATION
Software Security Assurance State-of-the-Art Report (SOAR)
104 Scope.
Section 5 SDLC Processes and Methods and the Security of Software
u It provides a single methodology and framework that supports both safety and security certification and accreditation of both products and systems, including highly modular systems.
The SafSec assurance case can be said to be an integrated dependability case in which safety and security are handled in parallel. The inclusion of reliability and maintainability concerns in the assurance argument and evidence ensures that all aspects of dependability are addressed. SafSec emphasizes the need to concentrate on the product rather than the processes. Justification of the means or processes by which the product was produced is less important than ensuring that the system itself is assured. For this reason, SafSec uses the assurance case as a structure for evidence about the product alone.
SafSec’s implementation process incorporates three phases:
1. Unified Risk Management—The risk model is developed, taking into