Formal specification Software Engineering 9th ed (intro txt) I. Sommerville (Pearson, 2011)

334 Chapter 12 ■ Dependability and security specification The starting point for all formal development processes is a formal system model, which serves as a system specification. To create this model, you translate the sys- tem’s user requirements, which are expressed in natural language, diagrams, and tables, into a mathematical language which has formally defined semantics. The for- mal specification is an unambiguous description of what the system should do. Using manual or tool-supported methods, you can check that a program’s behavior is consistent with the specification. Formal specifications are not just essential for a verification of the design and implementation of software. They are the most precise way of specifying systems, and so reduce the scope for misunderstanding. Furthermore, constructing a formal specification forces a detailed analysis of the requirements and this is an effective way of discovering requirements problems. In a natural language specification, errors can be concealed by the imprecision of the language. This is not the case if the system is formally specified. Formal specifications are usually developed as part of a plan-based software process, where the system is completely specified before development. The system requirements and design are defined in detail and are carefully analyzed and checked before implementation begins. If a formal specification of the software is developed, this usually comes after the system requirements have been specified but before the detailed system design. There is a tight feedback loop between the detailed require- ments specification and the formal specification. Figure 12.12 shows the stages of software specification and its interface with soft- ware design in a plan-based software process. As it is expensive to develop formal specifications, you may decide to limit the use of this approach to those components that are critical to the system’s operation. You identify these in the architectural design of the system. Over the past few years, automated support for analyzing a formal specification has been developed. Model checkers Clarke et al., 2000 are software tools that take a state-based formal specification a system model as an input, along with the specifica- tion of some formally expressed desirable property, such as ‘there are no unreachable states.’ The model checking program exhaustively analyzes the specification and either reports that the system property is satisfied by the model or presents an example that shows it is not satisfied. Model checking is closely related to the notion of static analysis and I discuss these general approaches to system verification in Chapter 15. Formal specification techniques Formal system specifications may be expressed using two fundamental approaches, either as models of the system interfaces algebraic specifications or as models of the system state. You can download an extra web chapter on this topic, where I show examples of both of these approaches. The chapter includes a formal specification of part of the insulin pump system. http:www.SoftwareEngineering-9.comWebExtraChapsFormalSpec.pdf 12.5 ■ Formal specification 335 The advantages of developing a formal specification and using this in a formal development process are: 1. As you develop a formal specification in detail, you develop a deep and detailed understanding of the system requirements. Even if you do not use the specifica- tion in a formal development process, requirements error detection is a potent argument for developing a formal specification Hall, 1990. Requirements problems that are discovered early are usually much cheaper to correct than if they are found at later stages in the development process. 2. As the specification is expressed in a language with formally defined semantics, you can analyze it automatically to discover inconsistencies and incompleteness. 3. If you use a method such as the B method, you can transform the formal speci- fication into a program through a sequence of correctness-preserving transfor- mations. The resulting program is therefore guaranteed to meet its specification. 4. Program testing costs may be reduced because you have verified the program against its specification. In spite of these advantages, formal methods have had limited impact on practical software development, even for critical systems. Consequently, there is very little experience in the community of developing and using formal system specifica- tions. The arguments that are put forward against developing a formal system specification are: 1. Problem owners and domain experts cannot understand a formal specification so they cannot check that it accurately represents their requirements. Software engineers, who understand the formal specification, may not understand the application domain so they too cannot be sure that the formal specification is an accurate reflection of the system requirements. 2. It is fairly easy to quantify the costs of creating a formal specification, but more difficult to estimate the possible cost savings that will result from its use. As a result, managers are unwilling to take the risk of adopting this approach. Increasing Contractor Involvement Decreasing Client Involvement Specification Design User Requirements Definition System Requirements Specification Architectural Design Formal Specification High-Level Design Figure 12.12 Formal specification in a plan-based software process 336 Chapter 12 ■ Dependability and security specification Formal specification costs Developing a formal specification is an expensive process as quite a lot of time is needed to translate the requirements into a formal language and check the specification. Experience has shown that savings can be made in system testing and verification and it seems that specifying a system formally does not significantly increase the overall development costs. However, the balance of costs changes, with more costs incurred early in the development process. http:www.SoftwareEngineering-9.comWebFormalSpecCosts 3. Most software engineers have not been trained to use formal specification lan- guages. Hence, they are reluctant to propose their use in development processes. 4. It is difficult to scale current approaches to formal specification up to very large systems. When formal specification is used, it is mostly for specifying critical kernel software rather than complete systems. 5. Formal specification is not compatible with agile methods of development. Nevertheless, at the time of writing, formal methods have been used in the devel- opment of a number of safety- and security-critical applications. They may also be used cost effectively in the development and validation of critical parts of a larger, more complex software system Badeau and Amelot, 2005; Hall, 1996; Hall and Chapman, 2002; Miller et al., 2005; Wordworth, 1996. They are the basis of tools used in static verification such as the driver verification system used by Microsoft Ball et al., 2004; Ball et al., 2006 and the SPARKAda language Barnes, 2003 for critical systems engineering. K E Y P O I N T S ■ Risk analysis is an important activity in the specification of security and dependability requirements. It involves identifying risks that can result in accidents or incidents. System requirements are then generated to ensure that these risks do not occur and, if they do, that they do not lead to an incident or accident. ■ A hazard-driven approach may be used to understand the safety requirements for a system. You identify potential hazards and decompose these using methods such as fault tree analysis to discover their root causes. You then specify requirements to avoid or recover from these problems. ■ Reliability requirements can be defined quantitatively in the system requirements specification. Reliability metrics include probability of failure on demand POFOD, rate of occurrence of failure ROCOF, and availability AVAIL. Chapter 12 ■ Exercises 337 ■ It is important not to overspecify the required system reliability as this leads to unnecessary additional costs in the development and validation processes. ■ Security requirements are more difficult to identify than safety requirements because a system attacker can use knowledge of system vulnerabilities to plan a system attack, and can learn about vulnerabilities from unsuccessful attacks. ■ To specify security requirements, you should identify the assets that are to be protected and define how security techniques and technology should be used to protect these assets. ■ Formal methods of software development rely on a system specification that is expressed as a mathematical model. Developing a formal specification has the key benefit of stimulating a detailed examination and analysis of the system requirements. F U R T H E R R E A D I N G Safeware: System Safety and Computers. This is a thorough discussion of all aspects of safety- critical systems. It is particularly strong in its description of hazard analysis and the derivation of requirements from this. N. Leveson, Addison-Wesley, 1995. ‘Security Use Cases.’ A good article, available on the Web, that focuses on how use cases can be used in security specification. The author also has a number of good articles on security specification that are referenced in this article. D. G. Firesmith, Journal of Object Technology, 2 3, May–June 2003. http:www.jot.fmissuesissue_2003_05column6. ‘Ten Commandments of Formal Methods . . .Ten Years Later.’ This is a set of guidelines for the use of formal methods that was first proposed in 1996 and which are revisited in this paper. It is a good summary of the practical issues around the use of formal methods. J. P. Bowen and M. G. Hinchey, IEEE Computer, 39 1, January 2006. http:dx.doi.org10.1109MC.2006.35. ‘Security Requirements for the Rest of Us: A Survey.’ A good starting point for reading about security requirements specification. The authors focus on lightweight rather than formal approaches. I. A. Tøndel, M. G. Jaatun, and P. H. Meland, IEEE Software, 25 1, JanuaryFebruary 2008. http:dx.doi.org10.1109MS.2008.19. E X E R C I S E S 12.1. Explain why the boundaries in the risk triangle shown in Figure 12.12 are liable to change with time and changing social attitudes. 12.2. Explain why the risk-based approach is interpreted in different ways when specifying safety and security. 338 Chapter 12 ■ Dependability and security specification 12.3. In the insulin pump system, the user has to change the needle and insulin supply at regular intervals and may also change the maximum single dose and the maximum daily dose that may be administered. Suggest three user errors that might occur and propose safety requirements that would avoid these errors resulting in an accident. 12.4. A safety-critical software system for treating cancer patients has two principal components: ■ A radiation therapy machine that delivers controlled doses of radiation to tumor sites. This machine is controlled by an embedded software system. ■ A treatment database that includes details of the treatment given to each patient. Treatment requirements are entered in this database and are automatically downloaded to the radiation therapy machine. Identify three hazards that may arise in this system. For each hazard, suggest a defensive requirement that will reduce the probability that these hazards will result in an accident. Explain why your suggested defense is likely to reduce the risk associated with the hazard. 12.5. Suggest appropriate reliability metrics for the classes of software systems below. Give reasons for your choice of metric. Predict the usage of these systems and suggest appropriate values for the reliability metrics. ■ a system that monitors patients in a hospital intensive care unit ■ a word processor ■ an automated vending machine control system ■ a system to control braking in a car ■ a system to control a refrigeration unit ■ a management report generator 12.6. A train protection system automatically applies the brakes of a train if the speed limit for a segment of track is exceeded, or if the train enters a track segment that is currently signaled with a red light i.e., the segment should not be entered. Giving reasons for your answer, choose a reliability metric that might be used to specify the required reliability for such a system. 12.7. There are two essential safety requirements for the train protection system: ■ The train shall not enter a segment of track that is signaled with a red light. ■ The train shall not exceed the specified speed limit for a section of track. Assuming that the signal status and the speed limit for the track segment are transmitted to onboard software on the train before it enters the track segment, propose five possible functional system requirements for the onboard software that may be generated from the system safety requirements. 338 Chapter 12 ■ Dependability and security specification Chapter 12 ■ References 339

12.8. Explain why there is a need for both preliminary security risk assessment and life-cycle

security risk assessment during the development of a system.

12.9. Extend the table in Figure 12.11 to identify two further threats to the MHC-PMS, along with

associated controls. Use these as a basis for generating further software security requirements that implement the proposed controls.

12.10. Should software engineers working on the specification and development of safety-related

systems be professionally certified in some way? Explain your reasoning. R E F E R E N C E S Badeau, F. and Amelot, A. 2005. ‘Using B as a High Level Programming Language in an Industrial Project: Roissy VAL’. Proc. ZB 2005: Formal Specification and Development in Z and B, Guildford, UK: Springer. Ball, T., Bounimova, E., Cook, B., Levin, V., Lichtenberg, J., McGarvey, C., Ondrusek, B., Rajamani, S. K. and Ustuner, A. 2006. ‘Thorough Static Analysis of Device Drivers’. Proc. EuroSys 2006, Leuven, Belgium. Ball, T., Cook, B., Levin, V. and Rajamani, S. K. 2004. ‘SLAM and Static Driver Verifier: Technology Transfer of Formal Methods Inside Microsoft’. Proc. Integrated Formal Methods 2004, Canterbury, UK: Springer. Barnes, J. P. 2003. High-integrity Software: The SPARK Approach to Safety and Security. Harlow, UK: Addison-Wesley. Bishop, M. 2005. Introduction to Computer Security. Boston: Addison-Wesley. Brazendale, J. and Bell, R. 1994. ‘Safety-related control and protection systems: standards update’. IEE Computing and Control Engineering J., 5 1, 6–12. Clarke, E. M., Grumberg, O. and Peled, D. A. 2000. Model Checking. Cambridge, Mass.: MIT Press. Firesmith, D. G. 2003. ‘Engineering Security Requirements’. Journal of Object Technology, 2 1, 53–68. Hall, A. 1990. ‘Seven Myths of Formal Methods’. IEEE Software, 7 5, 11–20. Hall, A. 1996. ‘Using Formal methods to Develop an ATC Information System’. IEEE Software, 13 2, 66–76. Hall, A. and Chapman, R. 2002. ‘Correctness by Construction: Developing a Commercially Secure System’. IEEE Software, 19 1, 18–25. Jahanian, F. and Mok, A. K. 1986. ‘Safety analysis of timing properties in real-time systems’. IEEE Trans.on Software Engineering., SE-12 9, 890–904. 340 Chapter 12 ■ Dependability and security specification Leveson, N. and Stolzy, J. 1987. ‘Safety analysis using Petri nets’. IEEE Transactions on Software Engineering, 13 3, 386–397. Leveson, N. G. 1995. Safeware: System Safety and Computers. Reading, Mass.: Addison-Wesley. Miller, S. P., Anderson, E. A., Wagner, L. G., Whalen, M. W. and Heimdahl, M. P. E. 2005. ‘Formal Verification of Flight Control Software’. Proc. AIAA Guidance, Navigation and Control Conference, San Francisco. Peterson, J. L. 1981. Petri Net Theory and the Modeling of Systems. New York: McGraw-Hill. Schneier, B. 1999. ‘Attack Trees’. Dr Dobbs Journal, 24 12, 1–9. Storey, N. 1996. Safety-Critical Computer Systems. Harlow, UK: Addison-Wesley. Wordsworth, J. 1996. Software Engineering with B. Wokingham: Addison-Wesley. 340 Chapter 12 ■ Dependability and security specification