What's needed to ensure safety and security in UAV software

Story

July 31, 2013

Mark Pitchford

LDRA Technology

UAVs are not like the remote control stunt plane you unwrapped on your 10th birthday. In their different guises they can be found in civil airspace or flying as integral players in military missions. That makes unmanned systems? safety and security very serious considerations. Accordingly, ISO 14508 and DO-178 could prove helpful in perpetuating safety and security for unmanned systems. Software tools that automate the processes required by these certification standards are easing the burden.

As a basic concept, the idea of an Unmanned Aerial Vehicle (UAV or “drone”) is “childishly” simple: a miniature plane that can be piloted remotely. The major difference between UAVs and the toys of our childhood is the sophistication of the vehicles themselves and of their navigation and pilot systems. Given that these vehicles enter civil airspace and will continue to do so more and more as they begin to be used for an increasing number of civilian activities, the safety and security of UAV software has become critical. It’s paramount that we raise the stakes in terms of the robustness of the code and minimize its potential vulnerability to hackers.

As early as 2004, NASA’s “Civil UAV Capability Assessment” listed 30 categories of private-sector organizations with a potential interest in UAV use, including those in forestry management, crop dusting, and coastal search and rescue. The number of drones and applications has ballooned since then, and according to The Washington Times, as many as 30,000 UAVs could fly in U.S. airspace by the year 2020.

This expansion in UAV use challenges the FAA’s goal “to provide the safest, most efficient aerospace system in the world.” With no human pilot onboard, the control software is chiefly responsible for maintaining UAV safety and security. And, with no mandated standards in place to govern the safety and security of UAV systems, the proliferation of drones increases the overall risk to our safety and security.

Notably, even if FAA standards are imposed, safety might still be at risk unless security standards are mandated. The 2011 crash of a CIA drone in Iran underlines that unless a system can withstand hacking, safety remains at risk. In that incident, local authorities claimed that they had diverted the vehicle by hacking its GPS. Their claim gained credence when Professor Todd Humphreys of the University of Texas and a group of U.S. researchers hacked a UAV in front of representatives of the U.S. Department of Homeland Security. The team spoofed an onboard GPS receiver by mimicking the actual signals sent to the global positioning device to trick the UAV into following different commands.

To address such a scenario, developers at the U.S. Air Force Institute of Technology are working on a system that enables a UAV, like a human pilot, to supplement GPS navigation with visual feedback by using a camera with pattern-recognition software. Such efforts are only as secure as the security of the software deployed.

Which safety/security standards should be in place

There are two kinds of standards to consider for UAV safety and security:

Process standards describe the development processes to be followed to ensure that the finished product is written in a safe manner (DO-178) or a secure manner (ISO 14508).
Coding standards describe a high-level programming language subset that ensures the software is written as safely (MISRA C) and securely (CERT C) as possible.

Safety is clearly important in UAV development, but a UAV can only be considered safe if it cannot be controlled by a hostile intruder.

ISO 14508 (also know as the “Common Criteria” with reference to the merged documents from which it was derived) is an international process-oriented standard that defines IT security requirements. These requirements are categorized according to seven Evaluation Testing Assurance Levels (EALs), as displayed in Table 1, with EAL 7 representing the most secured system. Security functional requirements include audit, communications, cryptography, data protection, authentication, security management, privacy, and protection of Targets of Evaluation (TOEs). Professor Humphreys’ spoofed GPS signals demonstrated just one resulting vulnerability when these general principles were not applied to UAV communications.

Table 1: ISO 14508 defines a range of Evaluation Assurance Levels (EALs), which determine the process rigor associated with each software component.

(Click graphic to zoom by 1.9x)

Software developed for use in UAVs falls under the guidelines of DO-178, “Software Considerations in Airborne Systems and Equipment Certification.” Both DO-178B and the recently ratified DO-178C provide detailed guidelines for the production of all software for airborne systems and equipment, whether safety-critical or not. As part of these guidelines, DO-178B/C defines Design Assurance Levels (DALs) with Level A involving the most rigorous safeguard against failure. DO-178 translates these DALs into Software Levels, as shown in Table 2. Each software level has associated objectives that must be satisfied during development.

Table 2: DO-178 defines a range of software levels that must be examined and determined for each software component.

(Click graphic to zoom by 1.9x)

DO-178 recognizes that software safety must be addressed in a systematic way throughout the development life cycle. To help developers do this, the standard outlines needed processes such as requirements traceability, software design, coding, and the validation and verification that ensure confidence in and the correctness and control of the software. Robust software validation and verification processes enable developers to detect and correct errors introduced during software development.

With respect to software, the overlap between the two standards is considerable, especially with configuration management, software development, quality assurance, verification, and planning. However, DO-178 focuses solely on the safety of the software in the airborne system, while ISO 14508 focuses on system security.

Both DO-178 and ISO 14508 suggest the use of language subsets (or “coding standards”) such as MISRA C:2012 for safety and CERT C or CWE for security. These language subsets consist primarily of lists of constructs and practices for developers to avoid in order to ensure safe or secure code. It is, for example, entirely possible to adhere to coding rules from both MISRA C:2012 and CERT C to gain acceptable levels of safety and security.

Given the anticipation that UAVs will fall under both DO-178 and ISO 14508 standards, development teams should strive to fulfill the aims of both standards moving forward.

It is certainly critical to ensure that the UAV is developed to meet system requirements that ensure safety and security issues are dealt with. However, with increasing market pressure related to UAV development, improvements in time-to-market and development costs are also important. Fortunately, vendors have come a long way in providing tools that automate the processes required by these certification standards (Figure 1). For example, fundamental to both DO-178 and ISO 14508 are requirements traceability, static analysis, and dynamic analysis, and tools are available to help automate the labor-intensive aspects of all three objectives.

Figure 1: Meeting one standard is a challenge; adhering to two such as DO-178 and ISO 14508 is totally daunting. By applying appropriate automation techniques, development teams can minimize the overhead involved.

(Click graphic to zoom by 1.9x)

Requirements traceability tools

Both standards require that high-level requirements are traceable to design documents, that design documents trace to code, and code traces to test – and back up again, from tests through to requirements to gain “bidirectional requirements traceability.”

If requirements could be static and fixed from the outset, then traceability would be relatively straightforward. However, that is rarely the case, and consequently the maintenance of a matrix to show traceability at any particular time becomes a very labor-intensive task.

To help manage this matrix of relationships, requirements-traceability tools link system requirements to software requirements, from the software requirements to design artifacts, and then to source code and the associated test cases. The automated bidirectional tracing of requirements ensures that the developed UAV does exactly what is specified by the final set of requirements – no more, no less, and no matter how often those requirements change (Figure 2).

Figure 2: Requirements traceability is a vital factor in meeting security and safety standards. Dynamically linking high-level requirements to source code and verification tasks ensures that an up-to-date traceability matrix is always maintained.

(Click graphic to zoom by 1.9x)

Static analysis tools

When requirements are established and designs are in place, developing safe and secure source code demands the use of appropriate coding rules. Again, the rules designed to develop safe code are similar to those designed for secure code. For example, many C language features that are unsafe are similarly unsecure.

Notably, it is impractical to manually check for compliance to both the MISRA C and CERT C language subsets. Static analysis automates verification of coding rules. Once the rules are selected, the source code is statically analyzed to highlight the precise location of any rule violations.

Static analysis helps to fulfill other obligations too. For example, it identifies code that is unnecessarily complex and therefore more error prone. And, it confirms that the code does what it’s specified to do. Developers must prove not only that the code functions correctly, but that all code is exercised to a degree appropriate to the criticality of the system.

Dynamic analysis tools

Dynamic analysis tools exercise code as a whole system or piecemeal, by means of unit or integration testing, to show correct functionality. Any code necessary to permit a subsystem to be built and executed is created automatically, and the exercised code is identified.

Cost-effective safety and security

As mentioned earlier, UAV projects are obliged to meet neither DO-178 nor ISO 14508. Even if they were, those standards do not insist either on the use of automated tools or on the automation of the development process. However, the need for UAVs to be safe and secure is vital given their expanded role. Automated requirements traceability coupled with modern static- and dynamic-analysis tools make it viable to meet the exacting demands of such standards in an efficient and cost-effective manner.

Mark Pitchford has more than 25 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. Since 2001, he has specialized in software test, and works throughout Europe and beyond as a Field Applications Engineer with LDRA. He can be contacted at [email protected].

LDRA 855-855-5372 www.ldra.com