Safety, Security, and Portability

Transcription

1 NCC Group Whitepaper Safety, Security, and Portability November 22, 2017 Version 1.0 Prepared by Robert C. Seacord Technical Director Abstract Safety, security, and portability are all quality attributes of software systems, but it is unclear what their relationship is. This question is becoming increasingly important as software developers struggle to develop systems which are both safe and secure. This white paper attempts to define these concepts in sufficiently precise terms to define a collection of rules for developing software with these quality attributes in the C programming language. This paper identifies and characterizes the existing and emerging markets for safe and secure software and explains the relationship between safety, security, and portability in sufficient detail to allow the creation of coding rules for C language programming.

2 Table of Contents 1 Introduction Existing and Emerging Markets Market Characterizations Portability Summary References Safety, Security, and Portability NCC Group

3 1 Introduction Safety, security, and portability are all quality attributes [Kazman 1998] of software systems, but it is unclear what their relationship is. Is security a strict subset of safety? Is portability necessary for safety or security? While these may seem like largely academic questions, they are critical to the work of the Safety and Security Rules Study Group within ISO/IEC JTC1/SC22/WG14, the international standardization working group for the programming language C. The purpose of this group is to study the problem of adding rules for safetycritical and safety/security-critical to ISO/IEC TS 17961:2013/Corrigendum 1:2016 Secure Coding Rules [ISO/IEC TS ]. An International Standard (IS) based on ISO/IEC TS needs to address the requirements for safety-critical systems, security-related systems, and safety- and security-critical systems. ISO/IEC TS establishes a baseline set of requirements to diagnose insecure code beyond the requirements of the language standard for analyzers including static analysis tools and C language compilers. The term analyzer is used in this paper to include both analysis tools and compilers. These rules must be enforceable by static analysis and analyzers that implement these rules, and they must be able to effectively discover secure coding errors without generating excessive false positives. The initial direction of the study group is to define coding rules systems that need to be safe, systems that need to be secure, and systems that need to be both safe and secure. To complete its work, the study group must define precise criteria for the inclusion of a rule in each of these categories. To define these criteria, it is necessary to analyze the markets an International Standard (IS) would service and to agree philosophically on the purpose of these rule sets. ISO/IEC/IEEE provide definitions for safety, security, and portability as follows: safety the expectation that a system does not, under defined conditions, lead to a state in which human life, health, property, or the environment is endangered [ISO/IEC ]. safety-critical-software software that falls into one or more of the following categories: a) software whose inadvertent response to stimuli, failure to respond when required, response out-of-sequence, or response in combination with other responses can result in an accident b) software that is intended to mitigate the result of an accident c) software that is intended to recover from the result of an accident. [IEEE Std ]. security portability NOTE: In some domains, a distinction is made between safety-related (can lead to any harm) and safety-critical (life threatening). 1. the protection of system items from accidental or malicious access, use, modification, destruction, or disclosure [ISO/IEC ] 2. protection of information and data so that unauthorized persons or systems cannot read or modify them and authorized persons or systems are not denied access to them [ISO/IEC ]. all aspects related to defining, achieving, and maintaining confidentiality, integrity, availability, non-repudiation, accountability, authenticity, and reliability of a system [ISO/IEC ]. 1. the ease with which a system or component can be transferred from one hardware or software environment to another. 2. the capability of a program to be executed on various types of data processing systems without converting the program to a different language and with little or no modification [ISO/IEC Safety, Security, and Portability NCC Group

4 1993] Synonym: transportability In terms of the C Language Standard [ISO/IEC ], portability issues are enumerated in the informative Annex J, Portability issues. Portability issues include: undefined behavior, unspecified behavior, implementation-defined behavior, locale-specific behavior, and common extensions. There are various references to safe and unsafe throughout the C Standard, but it is unlikely WG14 intended these as direction on what constitutes safety in C language programming. Annex K, Boundschecking interfaces mentions both safety and security in a cursory manner in the background and scope sections, but otherwise provides little guidance. 4 Safety, Security, and Portability NCC Group

5 2 Existing and Emerging Markets There are two well-established markets for safety-critical systems and security-related systems developed in the C language. A third market is emerging for safety- and security-critical systems that include systems such as connected cars [igate Research 2016]. The existence of these established and emerging markets highly influences the practical nature of security and safety, beyond their definitions. The automotive and aerospace industries are major consumers of coding standards for safety-critical systems. Many organizations develop safety-critical code in C [Gerard 2006]. With C s long history there is an extensive tool support for this language, including strong source code analyzers, logic model extractors, metrics tools, debuggers, test support tools, and a choice of mature, stable compilers. The safety community traditionally constrains development to a subset of the C language that is considered less prone to error and amenable to analysis. These language subsets are influenced by the IEC series of international standards for electrical, electronic, and programmable electronic safety related systems [Gerard 2006]. These standards support the assessment of risks to minimize these failures in all Electrical/Electronic/Programmable Electronic safety-related systems, irrespective of where and how they are used. ISO [ISO/DIS ] is an adaptation of IEC for automotive electric/electronic systems that has been widely adopted by the major automotive manufacturers. The security community serves a broader market. Outside of government high-assurance systems, there is a significant focus on security in private/public sectors including financial (banks, trading firms), health (hospitals, medical equipment), and so forth. Still, security is more often considered an attribute of applications and systems whose primary purpose is to deliver functionality and for which security is typically one of several system qualities that may be traded-off against other qualities, such as performance and usability. These applications frequently make use of the whole language, including dynamic memory, which makes subsetting the language too costly to consider. Safety engineering traditionally excludes malevolent behavior, but recent attacks on automobiles [Checkoway 2011, Miller 2015] have demonstrated how remote attackers can control the cyber-physical systems in automobiles and have raised concerns that vulnerabilities in automotive systems [McCarthy 2014] can be exploited to jeopardize system safety. Consequently, automotive manufacturers are increasingly motivated to adopt coding standards that address both safety and security concerns. Several evolving standards aim at addressing these concerns. For example, SAE J3061 [SAE J ] defines a cybersecurity process framework and provides guidance to help organizations identify and assess cybersecurity threats and design cybersecurity into cyber-physical vehicle systems throughout the entire development lifecycle process. The safety-critical systems market is primarily served by The Motor Industry Software Reliability Association (MISRA), a UK-based collaboration between manufacturers, component suppliers, and engineering consultancies. The MISRA C Guidelines define a subset of the C language that reduces the opportunities for mistakes. The first edition of MISRA C, Guidelines for the use of the C language in vehicle based software [MISRA 1998] was published in 1998 to provide a restricted subset of C to meet the requirements of IEC Safety Integrity Level (SIL) 2 and above. Since that time, MISRA C has been adopted by a wide variety of industries and applications including the rail, aerospace, military, and medical sectors. The second edition, known as MISRA C:2004 [MISRA 2004] is titled Guidelines for the use of the C language in critical systems. The first two editions of MISRA were based on C90 [ISO/IEC ]. MISRA C:2012 [MISRA 2012] extends support for C99 [ISO/IEC ] while maintaining guidelines for C90. The security market is primarily served by The CERT C Coding Standard [Seacord 2008, Seacord 2014] published by Addison-Wesley. The CERT C Secure Coding Standard was developed at the request of, and in concert with, the C Standards Committee [Seacord 2016]. The first edition, also known as CERT C:2008 [Seacord 2008], was published on Oct 14, CERT C:2008 provided guidance to programmers in the 5 Safety, Security, and Portability NCC Group

6 secure use of the C language and specifically supported C99 [ISO/IEC ]. After the publication of CERT C:2008, the C Standards Committee established a study group to produce analyzable secure coding guidelines for the C language. The study group first met on October 27, 2009 and in 2013 published ISO/IEC TS Information Technology Programming Languages, Their Environments and System Software Interfaces C Secure Coding Rules [ISO/IEC TS ]. The second edition of The CERT C Coding Standard was updated to support C11 [ISO/IEC ] and to align with ISO/IEC TS Published in 2014, it also known as CERT C:2014 [Seacord 2014]. SAE J3061 recommends both MISRA C and CERT C for guidance on avoiding vulnerabilities and unpredictable behavior in software. 6 Safety, Security, and Portability NCC Group

7 3 Market Characterizations Programmers have developed significant quantities of code that meet the requirements of each market and their associated coding standards. The safety-critical market, in particular, has long used a subset of the C language that it considers safe. As a result, significant existing legacy code bases are implemented using this safe subset of the language. The security requirements of code depend on its purpose rather than its environment. The UNIX finger daemon (fingerd) is an example of ordinary code, even though it may be deployed in a hostile environment. A user runs the client program, finger, which sends a user name to fingerd over the network, which then sends a reply indicating whether the user is logged in and a few other pieces of information. The function of fingerd has nothing to do with security. However, in 1988, Robert Morris found and exploited a vulnerability in fingerd by triggering a buffer overflow, allowing him to execute arbitrary code on the target machine. The Morris worm could have been prevented from using fingerd as an attack vector by preventing buffer overflows, regardless of whether fingerd contained other types of defects. By contrast, the function of /bin/login is purely related to security. A defect of any kind in /bin/login has the potential to allow access where it was not intended. This is security-critical code. Similarly, in safetycritical code, such as software that runs an X-ray machine, any defect at all could have serious consequences. In practice, security-critical and safety-critical code have similar coding requirements in that they must be free from any defects. Standards that address safety-critical code, because they must focus on preventing essentially all defects, are considered too strict by developers outside the safety-critical community. This lack of adoption leaves ordinary code like fingerd unprotected. Security requirements, unlike safety requirements, are frequently retrofitted to existing legacy code. A significant amount of existing legacy code, including code used in critical infrastructure, was implemented without regard to a coding standard of any kind. Consequently, coding standards for security-related software are typically written to support the full language, and not just a secure subset of the language. To be considered a security flaw, a software defect must be triggerable by the actions of a malicious user or attacker. An attacker may trigger a defect by providing malicious data or by providing inputs that execute a particular control path that in turn executes the security flaw. Implementers are encouraged to distinguish violations that operate on untrusted data from those that do not. Secure coding requirements go beyond the requirements of safety when it comes to confidentiality. Leaking patient information, for example, does not jeopardize the immediate safety of the individual and is frequently ignored in safety-critical systems. Consequently, rules that address hard-coding credentials or clearing sensitive information stored in reusable resources, for example, are often absent from coding standards that service the safety-critical systems market. The following terms, are based on the preceding exposition: security-related-software software that must provide security appropriate to its purpose, environment, and threats. security-critical-software software that must be secure in any environment against any threat. Applying these terms to our examples, /bin/login would be classified as security-critical software, while fingerd would be classified as security-related software. 7 Safety, Security, and Portability NCC Group

8 4 Portability Safety and security properties can (and generally should) be verified and validated for each implementation on which it will be deployed. Strictly conforming code is rarely a goal for any system. Portability is a concern when static analysis tools are unavailable for the target platform. For example, a programmer may develop software on an x64 machine but deploy to a headless MIPS device. In these cases, an analysis tool might validate the code for x64 even in cases where it is insecure or unsafe on the MIPS target. Code that must be safe, secure, or both across multiple targets, especially embedded ones, must be verified free from assumptions that hold for some of those targets but not others. This is especially important for static analyzers that, unlike compilers, do not need to be run for each target. Anecdotally, complete static analysis for large code bases can take up to a week to complete. Some static analyzers only care about the target and not the host platform because they operate based on the compilation commands from the build system. These static analyzers interpret the compile flags passed through the build system for a specific target and uses these settings to perform the analysis. Code portability can be divorced from safety and security concerns. This is certainly the case when software targets a single implementation. When multiple implementations are targeted, safety and security properties can be verified and validated for each implementation on which it will be deployed. Many analyzers and compilers target only a single implementation; these tools should be able to conform to the IS. Portability in ISO/IEC TS was addressed by the San Francisco rule that states that variations in quality of implementation permit an analyzer to produce diagnostics concerning portability issues. For example, the following code can produce a diagnostic, such as the mismatch between %d and long int, but is not required to: long i; printf("i = %d", i); ISO/IEC TS does not specify that a conforming analyzer be complete or sound when diagnosing rule violations. This mismatch might not be a problem for all target implementations, but it is a portability problem because not all implementations have the same representation for int and long. A similar approach may suffice for safety-critical systems as well. 8 Safety, Security, and Portability NCC Group

9 5 Summary Security is largely a subset of safety. In other words, safety requirements are generally stricter than security requirements. Secure code must be correct; while safe code must be demonstrably correct. This additional requirement necessitates that safety-critical code be restricted to an analyzable subset of the language. While rule sets for both safety-critical systems and security-related systems need to consider existing legacy code, these legacy code bases vary significantly. Safety-critical systems largely follow MISRA or related guidelines while security-related systems frequently follow no coding standards whatsoever. Consequently, rules for safety-critical systems can subset the C language, while rules for security-related systems need to support the entire language. Security-related systems have some requirements that are not traditionally addressed in safety-critical standards, such as rules to prevent information leakage (for example, to preserve confidentiality). Existing coding standards that address the security-related or safety-critical markets do not fully address the requirements of the emerging market for safety- and security-critical systems. The rule sets for safety- and security-critical systems need to satisfy the stricter requirements for safety-critical systems, but also need to include confidentiality rules, which are absent. Furthermore, the rule sets for safety- and security-critical systems must be reconciled to be consistent and noncontradictory. Portability is not a requirement for safety or security. Ideally, safety and security properties will be verified and validated for each implementation for which the code is deployed. Portability may be a requirement when code must be verified to be free from assumptions that hold for some of those targets but not others, particularly when suitable analysis is not available for the target implementation. If you are interested in participating in the C Safety and Security Rules Study Group, please contact the author of this white paper. 9 Safety, Security, and Portability NCC Group

10 6 References [Checkoway 2011] Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., and Kohno, T. (2011). Comprehensive experimental analyses of automotive attack surfaces. In D. Wagner (Chair), SEC 11, Proceedings of the 20th USENIX Conference on Security, USENIX Association, August 8-12, San Francisco, CA. Available at [Gerard 2006] Gerard J. NASA/JPL Laboratory for Reliable Software The Power of 10: Rules for Developing Safety-Critical Code. Computer 39, 6 (June 2006), DOI= [IEC ] IEC 61508:2010. Functional safety of electrical/electronic/programmable electronic safetyrelated systems, International Electrotechnical Commission, in 7 parts published in [IEEE Std ] IEEE Std (R2002) IEEE Standard for Software Safety Plans. [igate Research 2016] igate Research. Global Connected Cars Market (by Connectivity Form Factor, Connectivity Technology, Product Categories and Geography) and Volume Forecast to 2022 ID: Report November [ISO/DIS ] ISO/DIS Road vehicles Functional safety. The standard consists of several parts, published in [ISO/IEC ] ISO/IEC. Programming Languages C (ISO/IEC 9899:1990). Geneva, Switzerland: ISO, [ISO/IEC ] ISO/IEC. Programming Languages C, 2nd ed (ISO/IEC 9899:1999). Geneva, Switzerland: ISO, [ISO/IEC TS ] ISO/IEC TS 17961:2013/Cor 1:2016. Information Technology Programming Languages, Their Environments and System Software Interfaces C Secure Coding Rules. Geneva, Switzerland: ISO, [ISO/IEC ] ISO/IEC. Programming Languages C, 3rd ed (ISO/IEC 9899:2011). Geneva, Switzerland: ISO, [ISO/IEC ] ISO/IEC 15026:1998, Information technology System and software integrity levels. [ISO/IEC ] ISO/IEC 15026:1998, Information technology System and software integrity levels. [ISO/IEC ] ISO/IEC 12207:2008 (IEEE Std ), Systems and software engineering Software life cycle processes. [ISO/IEC ] ISO/IEC 15288:2008 (IEEE Std ), Systems and software engineering System life cycle processes. [ISO/IEC ] ISO/IEC :1993, Information technology Vocabulary Part 1: Fundamental terms. [ISO/IEC TS ] ISO/IEC TS 17961:2013/Cor 1:2016. Information Technology Programming Languages, Their Environments and System Software Interfaces C Secure Coding Rules. Geneva, Switzerland: ISO, [Kazman 1998] Kazman, Rick., Klein, Mark., Barbacci, Mario., Longstaff, Thomas., Lipson, Howard., & Carriere, S.: The Architecture Tradeoff Analysis Method Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-98-TR-008, Safety, Security, and Portability NCC Group

11 [McCarthy 2014] McCarthy, C., Harnett, K., & Carter, A. (2014, October). Characterization of potential security threats in modern automobiles: A composite modelling approach. (Report No. DOT HS ). Washington, DC: National Highway Traffic Safety Administration. [Miller 2015] Miller, C., Valasek, C.: Remote Exploitation of an Unaltered Passenger Vehicle. August [MISRA 1998] MISRA (Motor Industry Software Reliability Association). Guidelines for the Use of the C Language in Vehicle Based Software, Nuneaton, UK: MIRA, 1998 (ISBN ). [MISRA 2004] MISRA (Motor Industry Software Reliability Association). MISRA C: 2004 Guidelines for the Use of the C Language in Critical Systems. Nuneaton, UK: MIRA, 2004 (ISBN X). [MISRA 2016] MISRA C WG14 Liaison Report WG14 Meeting, London 11th-14th April 2016 Andrew Banks, [SAE J ] SAE J3061 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems, January [Seacord 2008] Seacord, R.: The CERT C Secure Coding Standard (Addison-Wesley, 2008). [Seacord 2014] Seacord, R.: The CERT C Coding Standard, Second Edition: 98 Rules for Developing Safe, Reliable, and Secure Systems (Addison-Wesley, 2014) [Seacord 2016] Seacord, R.: C Secure Coding Rules: Past, Present, and Future, articles/article.aspx?p= , accessed 18 April Safety, Security, and Portability NCC Group