www.programmingresearch.com

SILVANO SOGUS

PART 1 - PROCESSES

WHITEPAPER

CODING SAFE AND SECURE APPLICATIONS

The debate about safety and security concerns in high integrity software applications is a hot topic of discussion in modern software management. The need to address these concerns is present in every application, and even more so in the realm of safety-critical systems.

This whitepaper focuses on the commonalities and differences of the coding process and industry coding standards, and details an example of an open source project analyzed with a combined MISRA C:2012 and CERT C ruleset, with the aim of illustrating a solution for developing secure and safe applications.

In this first part we will analyze the different approaches that security and safety-critical standards adopt at process level.

INTRODUCTIONThe debate about safety and security concerns in high integrity software applications is a hot topic. Whether these concerns are seen as two sides of the same problem or identified as completely different issues which have to be treated according to different set of rules and protocols, there is a need to address them properly in every application, especially so as the scope is centered on safety critical systems.

Whilst we do not claim to provide a formal definition of what is secure and what is safe when talking about software development, it is our opinion that safety and security are intrinsically very different but do howev-er share some common themes. As we move from a general view of development processes (for example as those discussed in functional safety standards like IEC 61508 or ISO 26262), and compare the require-ments that are provided by industry-recognized coding standards for high integrity systems against those currently present in coding standards for security-critical software, the common grounds tend to expand.

It is obvious that the discussion over safe and secure features of a language like C or C++ is limited by the nature of the language itself; hence, what tends to emerge are styles and methodologies aimed at preserv-ing these two aspects while considering the application of one of more coding standards.

In this paper, we will focus on the differences and commonalities shown by industry-recognized coding standards and we aim to answer to the question: is it possible to code safe and secure applications?

INTERNET OF (UN)SECURE THINGSThe growth of interconnected devices able to provide advanced services (generally called Internet of Things, IoT) is expected to expand exponentially in the next few years. Recent estimates report that by 2019, shipment of intelligent interconnect-ed devices will approach 7 billion1, but the total number will probably exceed 40 bil-lion2. While promises of efficiency and cost reduction brought by such an impressive evolution are indeed attractive, they carry heavy concerns regarding the price to pay in terms of security exposure.

The recent hack that allowed two security researchers to take remote control of a modern SUV3 reverber-ated worldwide as a wakeup call for manufacturers and customers: if a technologically advanced system such as a modern high-end car can be subject to this kind of attack, what will happen to the most common, low-budget interconnected equipment which will represent the bulk of those many billions of systems four years from now?

25

20

15

10

5

0

2014 2015 2016 2017 2018 2019

Home

Government Infrastructure

Enterprise

Estimated Number of Installed IoT Devices by Sector

Source: Business Insider Intelligence Estimates

© 2016 PROGRAMMING RESEARCH LTD 2

Although the threat is quite well understood, there is a perception that the proper actions to integrate se-curity as a native element able to drive development and business processes in a similar way to functional safety applications, are still to come. When considering that the areas susceptible to malicious interest (so-called attack surfaces) are numerous and heterogeneous, the scenario is all but reassuring. In an intercon-nected complex system like a car, for example, there is code running on ECUs, protocol exchanges in the internal CAN networks, potential architectural weaknesses due to missing segregation between low-severi-ty subsystems, such as infotainment - and more sensitive ones like power control etc.

SAFETY AND SECURITY AT PROCESS LEVELTo ingrain a culture where processes that preserve security and safety coexist efficiently takes time and significant effort. The approach to be taken is by nature holistic and cannot therefore be limited to single compartments or development stages. For example, the SUV hack exploited weaknesses and vulnerabili-ties at many different levels (architecture, service permission, password generation algorithms, etc.)4. As a consequence, a sound product development process should be able to integrate security hardening actions at all levels and allow them to coexist efficiently with the already demanding functional safety requirements - and this is the challenge.

What would happen if we choose to narrow down our focus and concentrate only on software develop-ment? More specifically – what are the choices available to a developer tasked with programming a safety-critical application and the need to be sure that the application is also secure? Assuming that sound measures have been applied at the requirement and design stages, it is then time to choose how to translate them into efficient, secure, high integrity software.

THE SAFETY CRITICAL APPROACH

Functional safety has mainly two family reference standards which deal with software lifecycle organization:

IEC 61508 series and derived standards DO-178B / C (and companion integrative documents, like DO-330)

IEC 61508, “Functional safety of electrical/electronic/programmable electronic safety-related systems”, covers possible hazards caused by failure of the safety functions to be performed by the E/E/PE (electrical/electronic /programmable electronic) safety related systems. Since it may be applied to any safety related system that contains an E/EE/PE device, the scope of applicability is quite broad. Some of the develop-ment phases described (like initial concept, overall scope definition, hazard and risk analysis etc.) may take place even before the final technology to be used has been decided5. Almost all major safety-related industry standards not connected with avionics are derived from IEC 61508.

© 2016 PROGRAMMING RESEARCH LTD 3

At the other end the RTCA DO-178C “Software Considerations in Airborne Systems and Equipment Certifi-cation” (and its companion documents DO-330, DO-331, DO-332 and DO-333) is the standard when consid-ering airborne applications. Created in the US by RTCA and harmonized in the EU by EUROCAE (ED-12B), DO-178C is mandatory for any commercial avionics project looking to achieve FAA certification. The whole DO-178C process standard has a more stringent focus on software than IEC 61508 (obvious just from the title); the software safety level (or IDAL – Item Development Assurance Level) is determined from safety as-sessment and risk analysis and mapped at 5 different levels: A (catastrophic), B, C, D, E (no effect).

For safety applications, the definition of criticality of code has been widely analyzed and there are standard-ized methods to qualify it and define proper means of handling the development process accordingly. Safety integrity levels (SIL) in IEC 61508, automotive SIL (ASIL) in ISO 26262, software SIL (SSIL) in EN 50128 or IDAL in DO-178C are all examples of the same concept - to quantify the risk reduction required for a specific function according to the risk analysis and at the same time to qualify actions to be under-taken to assure that this level is reached. The more catastrophic the impact in case of failure, the higher the integrity level required to implement a specific safety function, which implies more stringent and severe requirements for the software that implements that functionality. If any, the real issue with safety-critical ap-plications is not having a formal, commonly shared process to do this, as the two families described so far approach this issue from different angles.

Almost all industry-recognized functional safety standards (like IEC 61508, ISO 26262, EN 50128) pre-scribe the adoption of “design and coding standards” depending on the targeted safety integrity level (SIL). Even if there is no authoritative indication of what coding standards are suitable for functional safety applications, one of the main references in this respect is MISRA C. ISO 26262-6 acknowledges that – for the C language – MISRA C covers many of the methods required for “Design principles for software unit design and implementation”, and its spread currently reaches all the major safety-critical applications, such as machinery, medical, nuclear power, railways etc.

When considering DO 178B/C, the situation is not so different. These standards require thorough definition and documentation of the software development process. The base set of required documentation and life-cycle artifacts include rich and detailed planning and the application of a coding standard is part of this list:

Software ConfigurationManagement Plan

ConfigurationControl Procedures

SoftwareCodeStandard

SoftwareDesignStandard

SoftwareRequirementStandard

© 2016 PROGRAMMING RESEARCH LTD 4

The common approach shared by coding standards (like MISRA) that aim to provide support for safety-crit-ical applications is to define a subset of the target language avoiding (where possible) or limiting use of features and constructs that might lead to undefined or unspecified behavior. Moreover, practices like tolerating dead or unreachable code, which are perfectly defined from the point of view of the standard but can cause issues when considering traceability and verification, are generally discouraged.

Coding standards designed to be employed in high integrity applications tend to enforce features that produce predictable behavior. MISRA C:2012, for example, discourages the usage of dynamic memory (Dir 4.12 Dynamic memory allocation shall not be used) on the grounds that misuse of Standard Library facilities to manage dynamically allocated memory can lead to undefined behavior (e.g. when memory that was not dynamically allocated is subsequently freed, or if a pointer to freed memory is used in any way) and when the choice is made to use it nonetheless, it prescribes that particular care should be taken to avoid unpredictable outcomes.

Similar concerns are shared by JSF AV C++, a C++ coding standard developed by Lockheed Martin and re-viewed by Bjarne Stroustrup (original author of the C++ language), designed to target the Joint Strike Fighter program. Amongst the general design guidelines which have been driving this project, possibly the main con-cern was reliability: “ […] Executable code should consistently fulfill all requirements in a predictable man-ner,” especially in consideration of its use in a hard real-time system. In order to achieve that, the coding standard subsets the ISO C++ standard excluding all features that can exhibit unpredictable behavior, like for example AV Rule 208: C++ “Exceptions shall not be used (i.e. throw, catch and try shall not be used.)”

PROCESS STANDARDS FOR APPLICATION SECURITY

Information security management at process level is described essentially by the ISO/IEC 27000 family “Information security management”. The best-known standard in this family is ISO/IEC 27001:2003, which specifies the requirements for establish-ing, implementing, maintaining and continuously improving an information security management system (ISMS). It is based on the PDCA (‘plan – do – check – act’) model, shared with all main management system standards like ISO 9001:2015 and ISO 14001:2015. Risk assessment and business impact analysis are used to identify and manage possible risks to confidentiality, in-tegrity and availability of information. A more detailed view on application security is taken by another document of the ISO 27k family, ISO/IEC 27034:2011 “Information technology — Security techniques — Application security”, which provides guidance in defining and implementing information security controls by means of processes integrated in the SDLC. As such, it’s not a software application development standard, however it does rely on existing standards.

An example of SDLC integration proposals is the OWASP Software Assurance Maturity Model (SAMM), which takes the usual OWASP approach based on “cheat sheets” in order to provide sensible footprints to be followed by developers (of web application in this specific case). Another notable effort in this area is provided by CERT, (more on CERT later on) Secure Engineering Risk Analysis (SERA)6, which tries to identify and analyze the impact of design weaknesses early in the SDLC.

CHECK

ACT

PLAN

DO

© 2016 PROGRAMMING RESEARCH LTD 5

Turning our attention to security-oriented coding standards, the scenario is fairly rich and varied. Security concern is common to any type of applications, not only safety-critical ones; it is possible to find secure coding standards for the usual suspects C and C++, as well as Java, Perl, PL/SQL etc. The variety of techniques available to perform proper security assessment on code is quite rich. Different issues can be tracked down using static analysis, dynamic and runtime evaluation, data flow and control flow track-ing, taint analysis, executable analysis and heuristic analysis etc. These techniques can be more or less effective and easy to implement depending on existing support for the selected language, built in facilities, libraries etc.

One of the main reference points for security coding standards is the CERT Division of the Software Engi-neering Institute of Carnegie Mellon University. The CERT Division was set up in 1988 by the CERT Coor-dination Center in response to the Morris worm incident7, and is a trusted provider of operationally relevant cybersecurity research. Amongst other achievements, CERT has for many years been publishing sound coding standards aimed at security enforcement. On their website it is possible to get access to secure coding guidelines for C, C++, Java and Perl. The adoption of CERT C coding standard is quite widespread in the industry; CISCO Systems Inc. officially uses them as a baseline for their product development since October 2011, while Oracle has integrated all of CERT’s secure coding standards into its existing Secure Coding Standard. Oracle previously worked with CERT in authoring The CERT Oracle Secure Coding Standard for Java.

CERT coding standards are directly linked to real world vulnerabilities found in the field by means of the Common Weaknesses Enumeration (CWE). CWE is a community-developed dictionary of software weak-ness types, maintained by MITRE, a not-for-profit corporation originated from MIT’s computer laboratories during WWII to provide engineering and technical guidance for the US federal government. It creates a downloadable list of weaknesses (currently version 2.8 is available), along with practical means to navi-gate the list according to specific relationship contexts. There are XML versions of the database sorted by specific attributes (weaknesses in C, in C++, in mobile applications, etc.), by commonly combined weak-nesses (e.g. Integer Overflow, Buffer Overflow, Unchecked Return Value, NULL Pointer Dereference, etc.) and by hierarchical representation (Resource-Specific Weaknesses, Development Concepts, Weaknesses in OWASP Top Ten, etc.). CWE is related to a broader collection of publicly known information security vulnerabilities, known as CVE (Common Vulnerabilities and Exposures)8, which is now the industry stand-ard for common identification of vulnerabilities. Furthermore, CVE Identifiers, also called CVE-IDs, provide reference points for data exchange for information security products and services. They are also useful for analyzing coverage and effectiveness of tools and services with regard to specific classes of vulnerabilities. NIST’s National Vulnerability Database6, the US government repository of standards-based vulnerability management data, currently hosts more than 73,000 CVE vulnerabilities.

This last grouping also has specific collections for CERT guidelines: Weak-nesses addressed by the CERT C Secure Coding Standard, by the CERT C++ Secure Coding Standard and by the CERT Java Secure Coding Standard. For example, the weakness class “CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer”10 maps to the CERT C and C++ sections ARR (Arrays), STR (Characters and Strings), MEM (Memory Management), FIO (Input Output) and Environment (ENV). On the other end, the weakness class also maps to multiple observed examples; for example CVE-2014-016011, which is the well-known Heartbleed bug on OpenSSL cryptographic library. Hence, there’s a clear connection between guidelines suggested by security coding standards and weaknesses found in field.

© 2016 PROGRAMMING RESEARCH LTD 6

The group behind CERT C Secure Coding Standard also tried to submit it for publication as type 2 or type 3 technical report; the outcome of this effort has been an ISO/IEC Technical Specification (ISO/IEC TS 17961) with the title “Information Technology — Programming languages, their environments and system software interfaces — C Secure Coding Rules”.

SUMMARYDesigning a safety-critical applications project while also optimizing its security can be a demanding task, as most often safety and security require a set of strategies, processes, tools and skills that may not over-lap (or may even conflict). In the first part of this whitepaper, we looked at general aspects of processes aimed at software development for safety critical and secure coding. In the second part we will look at pro-gramming standard aspects and will provide an example of joint safe and secure approach to static analysis of code.

© 2016 PROGRAMMING RESEARCH LTD 7

REFERENCES

1. J. Greenough, “The ‘Internet of Things’ will be the world’s most massive device market and save companies billions of dollars.,” Feb 2015. [Online]. Available: http://uk.businessinsider.com/the-internet-of-things-market-growth-and-trends-2015-2?r=US&IR=T.

2. U. G. C. S. Adviser, “The Internet of Things: making the most of the Second Digital Revolution,” [Online]. Available: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/409774/14-1230-in-ternet-of-things-review.pdf.

3. A. Greenberg, “Hackers remotely kill a Jeep on the highway - with me in it,” July 2015. [Online]. Available: http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/.

4. C. V. Dr. Charlie Miller, “Remote Exploitation of an Unaltered Passenger Vehicle,” 10 August 2015. [Online]. Available: http://illmatics.com/Remote%20Car%20Hacking.pdf.

5. IEC, “IEC 61508 - Functional Safety FAQ 2.0,” [Online]. Available: http://www.iec.ch/functionalsafety/faq-ed2/.

6. CERT, “SERA - Secure Engineering Risk Analysis,” [Online]. Available: https://www.cert.org/cybersecurity-engineering/research/security-engineering-risk-analysis.cfm?.

7. CERT, “About Us,” [Online]. Available: https://www.cert.org/about/.8. C. -. MITRE, “CVE,” [Online]. Available: http://cve.mitre.org/.9. NIST, “National Vulnerability Database,” [Online]. Available: https://nvd.nist.gov/.10. C. -. MITRE, “CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer,”

[Online]. Available: http://cwe.mitre.org/data/definitions/119.html.11. C. -. MITRE, “CVE-2014-0160,” [Online]. Available:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160.

GLOSSARY

ASIL Automotive SIL

CS Coding Standard

CVE Common Vulnerabilities and Exposures

CWE Common Weaknesses Enumeration

E/E/PE Electrical/Electronic/Programmable Electronic

EUROCAE Euro Organisation for Civil Aviation Equipment

FAA Federal Aviation Administration

FOSS Free and Open-Source Software

GPL General Public License

IDAL Item Development Assurance Level

IP Intellectual Property

ISMS Information Security Management System

NIDS Network Intrusion and Detection System

NIST National Institute of Standards and Technology

NVD National Vulnerability Database

OWASP Open Web Application Security Project

RTCA Radio Technical Commission for Aeronautics

SC Safety Critical

SDLC Software Development Life Cycle

SIL Safety Integrity Level

SSIL Software SIL

TQL Tool Qualification Level

UB Undefined Behavior

© 2016 PROGRAMMING RESEARCH LTD 8

DETECT, ENFORCE AND MEASURE

Since 1985, PRQA has pioneered software coding governance in the automotive, aerospace, transport, finance, medical device and energy industries. Supporting both small start-ups and globally recognized brands, we provide sophisticated code analysis, robust defect detection and enforcement of both bespoke and industry coding standards through functional integrity and application security/safety.

PRQA’s industry-leading solutions, QA·C, QA·C++, QA·J and QA·C# offer the most meticulous static analy-sis of commonly used programming languages. Innovations such as multi-threading and resource analysis (MTR) complement this with refined multi-thread inspection of code streams. Used locally or centrally deployed via the Quality Management System QA·Verify, we enable early find/fix at the desktop and on the server side complete control, visibility and history to the decision maker.

ISO 9001 and TickIT certified.

www.programmingresearch.com

ABOUT PRQA

© 2016 PROGRAMMING RESEARCH LTD 9