conflicts in the resulting requirements specification. This research is discussed in Section 5.2
5.1 Whole Life Cycle Security Concerns
5.1.2 Using Formal Methods to Achieve Secure Software
Formal methods are an adaptation to software development of certain aspects of mathematics developed in 19th and 20th century mathematics. A formal system consists of four elements:
1. A set of symbols.
2. Rules for constructing well-formed formulas in the language.
3. Axioms for formulae postulated to be true.
4. Inference rules, expressed in a metalanguage. Each inference rule states that a formula, called a consequent, can be inferred from other formulae, called premises.
Formal methods are not just disciplined methods, but rather the incorporation of mathematically based techniques for the specification, development, and verification of software. Inasmuch as vulnerabilities can result from functionally incorrect implementations, formal methods, in general, improve software security (at a cost).
An example of a successful implementation of formal methods to further software security is type checking. An integral feature of modern programming languages like Java, C#, and Ada95, type checking is a particularly successful and familiar implementation of formal methods. Type checking increases the detection rate of many types of faults and weaknesses at compile time and runtime.
The “specification” contains the type information programmers provide when declaring variables. The “verification” of the specification is achieved through use of algorithms (such as Robin Milner [101]) to infer types elsewhere in the code, and to ensure that overall typing is internally consistent. The outcome of the verification is
“assurance” (contingent on an absence of extrinsic interventions) of—
u The integrity of how raw bits are interpreted in software as abstract values.
u The integrity of the access pathways to those values. Type checking affects all software engineering practices using modern languages.
It remains a research challenge to develop formal methods for the
specification and verification of non-trace security properties in software, such as non-subvertability of processes and predictability of software behavior under unexpectedly changing environment conditions associated with malicious input, malicious code insertions, or intentional faults.
Software Security Assurance State-of-the-Art Report (SOAR)
92
Section 5 SDLC Processes and Methods and the Security of Software
At a high level, the main uses for formal methods in the SDLC include—
u Writing the software’s formal specification
u Proving properties about the software’s formal specification
u Constructing the software program through mathematical manipulation of its formal specification
u Using mathematical arguments and proofs to verify the properties of a program.
Note: The majority of formal methods focus either on formal construction or on after-the-fact verification, but not both.
Formal methods have applications throughout the SDLC. Figure 5-1 maps possible uses of formal methods to each phase of the SDLC. Because formal methods can be used for correctness, independently of security concerns, the life cycle phases are not labeled in terms of security concerns.
Figure 5-1. Formal Methods in the SDLC
Table 5-1 describes each of the formal methods activities in the diagram, indicating the SDLC phases to which each activity pertains.
#ODING
Software Security Assurance State-of-the-Art Report (SOAR) 93 Intended Audience.
Section 5 SDLC Processes and Methods and the Security of Software
Table 5-1. Formal Methods Activities and SDLC Phases
Formal Method Activity Description SDLC Phases in Which Undertaken Formal models of user behavior:
often describe sequences in which users invoke the functionality of a system. For example, decision tables, finite state machines, Markov models, or Petri nets can characterize user actions.
u system analysis
u system requirements allocation
u software requirements also useful in generating test cases during:
• system integration and testing
• subsystem integration and testing
• product integration and testing
Formal specifications:
rigorously describe the functionality of a system or system component. Languages used, such as in the Vienna Development Method (VDM) and Z, often involve extensions of a mixture of predicate logic and set theory.
u system analysis
u system requirements allocation
u software requirements
u architecture design
Consistency proofs:
examine the components of a system in a formal specification developed at a single level of abstraction. They are useful at every phase in which a formal model is developed.
u system analysis
u system requirements allocation
u software requirements
u software architecture design
u software detailed design
u coding Proofs of properties:
prove that some proposition regarding states or combinations of states in the system is always maintained as true. For example, a formal method for safety might include the proof that some state never arises in a system.
u system analysis
u system requirements allocation
u software requirements
u software architecture design
u software detailed design
u coding Model checking:
a practical technique for automated formal verification. Model checking tools use symbolic expressions in propositional logic to explore a large state space. Model checking can be used in the same phases in which formal verification is used. With some analysis, it is possible to determine whether a model checking result is trustworthy enough to form the basis for positive assurance; however, such a determination is not intrinsic to the technique.
u software requirements
u software architecture design
u software detailed design
u coding
Prototyping:
not necessarily a formal method. However some formal method tools can be used to generate a prototype, particularly if an operational semantics is used. (Prototyping can be accomplished without as high a degree of automation and formality.)
u system analysis
u system requirements allocation
u software requirements
u software architecture design
u software detailed design
Software Security Assurance State-of-the-Art Report (SOAR)
94 Scope.
Section 5 SDLC Processes and Methods and the Security of Software
Table 5-1. Formal Methods Activities and SDLC Phases - continued
Formal Method Activity Description SDLC Phases in Which Undertaken Model-driven architecture (MDA):
automatic generation of an architecture from a Unified Modeling Language (UML) specification of a system.
u software architecture design
Model-driven development (MDD):
supports the construction of a system or system component by transforming a formal or semi-formal model into an implementation.
u software detailed design
u coding
Black box testing:
entails the development of test cases based on specifications of the system or system component being tested, as opposed to the development of test cases based on knowledge of internal implementation of the system or component. Because the specification is formal, formal techniques can be used in generating black box test cases.
u system integration and testing
u subsystem integration and testing
u product integration and test
Model-based testing:
the automatic generation of efficient test cases from models of requirements and functionality, given a formal model of the user developed in the corresponding requirements phase.
u system integration and testing
u subsystem integration and testing
u product integration and test
For Further Reading
Constance Heitmeyer (NRL), Applying Practical Formal Methods to the Specification and Analysis of Security Properties, (May, 2001).
Available from: http://chacs.nrl.navy.mil/publications/CHACS/2001/2001heitmeyer-MMM-ACNS.pdf Jeannette M. Wing (CMU SEI), A Symbiotic Relationship Between Formal Methods and Security, CMU-CS-98-188, (December, 1998).
Available from: http://reports-archive.adm.cs.cmu.edu/anon/1998/abstracts/98-188.html D. Richard Kuhn, Ramaswamy Chandramouli, and Ricky W. Butler (NIST, NASA Langley Research Center), “Cost Effective Use of Formal Methods in Verification and Validation”, in Proceedings of the Foundations 02 Workshop on Verification and Validation, (October, 2002).
Available from: http://csrc.nist.gov/staff/kuhn/kuhn-chandramouli-butler-02.pdf Formal Methods Virtual Library.
Available from: http://vl.fmnet.info
Michael Huth and Mark Ryan, Logic in Computer Science: Modelling and Reasoning About Systems, 2nd ed, (Cambridge University Press, 2004).
Available from: http://www.cambridge.org/us/catalogue/catalogue.asp?isbn=052154310x
Jonathan P. Bowen and Michael G. Hinchey, “The Use of Industrial-Strength Formal Methods,” in:
Proceedings of the 21st International Computer Software and Applications Conference (COMPSAC 97).
1997. Available from: http://www.jpbowen.com/pub/compsac97.pdf
Robert L. Vienneau, (Data and Analysis Center for Software), A Review of Formal Methods, (May 26 1993).
Available from: http://www.dacs.dtic.mil/techs/fmreview/title.html
Software Security Assurance State-of-the-Art Report (SOAR) 95 Assumptions and Constraints.
Section 5 SDLC Processes and Methods and the Security of Software
5.1.2.1 Limitations of Formal Methods for Assuring Software Security
Formal methods have limitations of scale, training, and applicability in principle. To compensate for the limitations of scale, formal methods have been applied to selected parts or properties of a software project, in contrast to applying them to the entire system. As for training limitations, it may be difficult to find developers with the needed expertise in formal logic, the range of appropriate formal methods for an application, or appropriate automated software development tools for implementing formal methods. Finally, not all formal methods are equally applicable on all systems. Formal languages without modularization capabilities and scope-delimiting rules are difficult to use on large systems at any but the highest level of abstraction.
Formal methods also have limitations in principle. A formal verification can prove that an abstract description of an implementation satisfies a formal specification or that some formal property is satisfied in the implementation.
However a formal method cannot prove that a formal specification captures a user’s intuitive understanding of a system and furthermore cannot prove that an implementation runs correctly on every physical machine. As restated by Barry W. Boehm, [102] formal methods are sometimes useful for verifying a system, but they cannot be used in validating a system. Validation shows that a system will satisfy its operational mission. Verification shows that each step in the development satisfies the requirements imposed by previous steps.
DHS’ Security in the Software Life Cycle observes that because software security properties are often expressed in negative terms (i.e., what the software must not do) it is particularly difficult to specify requirements for those
properties (formally or informally), and then to mathematically prove that those requirements have been correctly satisfied in the implemented software.
The same is true of both security and safety properties, which are both a form of universal statement that “nothing bad will happen.”
Formal methods for design have been mandated for software that must meet high assurance levels, for example, at CC EAL 7 and above. Formal methods have also proven successful in specifying and checking small, well structured systems such as embedded systems, cryptographic algorithms, operating system reference models, and security protocols.