UAV cybersecurity

Small unmanned airborne vehicles (UAVs) or drones are used by amateurs and professionals on a large scale in many countries. Larger UAVs are also used by the state and by the military. Management of their flight relies on an electronic system that is commanded from a control station connected to the UAV by a communications link. The system and the link could be interfered with by electronic means – a cyberattack. 

Go to the profile of Alistair Munro
Sep 13, 2017
0
0
Upvote 0 Comment

Author(s): Dr Alistair Munro

Abstract

This study discusses how to reduce the opportunities that attackers could exploit to make such attacks and means to reduce their impact – cyber security. The background to general aviation cyber security and the state of regulation is presented, followed by a review of some specific UAV cyber security issues that have been described in the literature. Applying a formal process in a systematic way allows the cyber security requirements to be stated completely, consistently and coherently. An example of use of this process is described for the UAV communications link. The main lesson learned is that technical cyber security measures must be supported by strong commitment by organisations and people to maintain values and behaviours that reduce risk. There remain many lessons that are yet to be learned.

Introduction

This paper brings two topics together that have independently generated at high level of interest for the public, government (and its regulatory agencies), industry and researchers: unmanned airborne vehicles (UAVs) and cyber security. It does not describe in detail a collision of conflicting requirements and solutions, e.g. where novel uses proposed for UAVs present a challenge to established principles and practice of cyber security. It is not concerned either with studies of systems, specific aspects such as threats or vulnerabilities, and solutions, which are well covered in recent published research [1–5], operational studies [6] and in the media [7–9]. Instead it considers how cyber security accreditation principles and practice can be applied to ensure that UAVs are safe to fly and flown safely without electronic interference.

There is a thriving professional UAV operator industry in many countries, flying remotely-piloted aircraft (RPA) under national regulations or special permissions. These UAVs, which weigh typically <20 kg, fly outside the air traffic management (ATM) system at low level in uncontrolled non-segregated airspace in visual line-of-sight. The threats to their cyber security are low level and they have limited capabilities to defend themselves. This is not likely to be the case for larger UAVs that operate outside these constraints.

Having said this, even small UAVs are becoming more complex and will be equipped with sophisticated functions that could be subverted. These include obstacle avoidance and geo-fencing which is intended to proscribe the locations in which a UAV can fly. They will also be required to carry electronic identification.

The objective of this paper is to explain the process of achieving cyber security of the electronic and communications elements of the UAV system. Any element of the system and the communications links and services associated with it is liable to cyberattack. Cyberattacks threaten information in two ways: availability, confidentiality or integrity could be compromised; or introduce new information of unverified provenance, thus lacking authentication and accountability.

Problem statement

The problem is to define efficient and effective means by which the UAV system is protected against cyberattack; how an attack is detected; how to react to it; and the documentation and management of change to prevent it [10].

Organisation of the paper

First we consider: what cyber security is and its interpretation in the aviation domain (What is Cyber security in Aviation?); what a UAV is and the potential weaknesses that it suffers from in terms of cyber security (What is a UAV? and UAV Cyber security Issues). Next, we introduce an outline of the methods that can be used to understand the cyber security requirements and solutions for UAVs (Methods for Assuring UAV Cyber security). A summary of the key requirements that must be fulfilled for one item that is specific to UAS and especially for remotely-piloted systems (RPAS): the command and control system (termed the C2 link) is next (UAV Cyber security Solutions for the C2 link). UAV Cyber security Solutions – Recommendations provide some general guidance about possible solutions that address the problem statement. Finally, we describe how the development of the UAV enterprise has created and will continue to create new challenges and suggest how they could be addressed (Conclusions).

Note: some terms, such as ‘pilot’, have very specific definitions for legal purposes. They are not used in the full formal sense except where this is important to the discussion.

What is cyber security in aviation?

‘Cyber security’ is defined by Oxford Dictionaries as ‘the state of being protected against the criminal or unauthorised use of electronic data, or the measures taken to achieve this’. A search of the Web, e.g. [11] is a starting point for further familiarisation with the topic. The results are typically wide-ranging and give a sense of the breadth of the concerns across government, industry (suppliers and operators) and researchers, and the depth of the issues that have to be addressed. They are also the tip of a large and growing iceberg. More specific scientific and engineering studies will be cited later in this paper.

Information technologies (IT hardware and software), the supporting services and material assets, and the people and organisations involved in operating and using them have weaknesses and vulnerabilities that could leave them open to ‘cyberattack’ – an attempt to compromise an information and communications technology (ICT) system, ranging from intentional unauthorised electronic interference with data (e.g. copying, theft or corruption) through to system damage or destruction.

The ‘state of being protected’ is challenged constantly by cyberattacks, e.g. as outlined in [12], as is the effectiveness of security measures as new threat scenarios emerge, security measures become broken, and exploitable vulnerabilities change, possibly by being exposed through a change of configuration or an upgrade or by the creation of new ones.

Standards for cyber security

The process of establishing ICT cyber security is well supported by International Standards, such as the ISO 27000 series – an overview can be found at [13]. There is another standard that focuses on evaluation criteria, the so-called ‘Common Criteria’ – ISO 15408 – an overview can be found in [14].

These standards address the organisational and procedural levels of cyber security. Looking at the part of the iceberg that is below the surface, the ITU-T ICT Security Roadmap ([15], e.g. Part 2) provides a detailed state-of-the-art with a catalogue of around 2000 relevant standards.

Cyber security in aviation

Aviation cyber security has much in common with ICT cyber security but the outcome of system disruption, damage or destruction through a cyberattack could lead to loss of life as well as loss of reputation, revenue or service. This means that cyber security must be addressed when certifying an aviation product – airworthiness of an aircraft or services that support its operation – and during operations. There is evident concern in government and industry about this topic, e.g. [16–18].

Cyberattacks on an aircraft can start at the drawing board and will continue through design, manufacture, maintenance and eventual decommissioning. They can also affect the entire aviation system, which uses many legacy systems and services that make no provision for cyber security.

Case studies

The authors of [19,20] provide some examples reported in the media of the potential cyberattacks that could be made. Although the attackers claim to have altered the flight path of aircraft or modified code in the aircraft avionic systems, there is no evidence that they were successful. The reports confirm nevertheless that known vulnerabilities in current aircraft and aviation systems could be exploitable [21]. Industry and regulators have recently published standards: ED-201 [22], ED-202A [23] and ED-204 [24] that would fill this gap if mandated; and are working on a standard (ED-203A) for evaluation criteria and recommended methods. Work is in progress on a standard for accreditation of ATM service providers (ED-205).

Cyber security and system safety

The integrity required of an aircraft links failure conditions to quantitative limits on the probability (likelihood) of them occurring throughout its life and to the corresponding design assurance level (DAL defined in [25]) required of the hardware and software elements of the aircraft. Thus a ‘catastrophic’ failure condition (multiple fatalities in the air or on the ground) for an Airbus 340 must be ‘extremely improbable’ at 10−9 failures per flying hour; the DAL for systems that might contribute to such a failure is required to be the highest possible. Related airworthiness considerations for UAVs are discussed in [26].

The ‘extremely improbable’ likelihood is based on historical data concerning fatalities and estimates of the contributions of system failure to catastrophic failures. There is no comparable experience that can be used to relate cyber security failures to catastrophic or other, outcomes. Cyber security measures, which are provided by complex hardware or software, must be implemented using a DAL appropriate to estimates of the severity of the failure conditions they may cause. This does not assure effectiveness of the measure to withstand an attack throughout the operational life of the aircraft.

Understanding of, and agreement on, this topic, has not been reached. For now the integration of security measures in an aircraft does not gain any credit for safety in an airworthiness certification. In fact, security measures may compromise the aircraft safety, e.g. by failures that block access to functions critical to safety. They may reduce the performance and reliability of the safe flight of the aircraft by introducing excessive delays in executing safety critical operations.

What is a UAV?

This overview provides a framework for the discussion of cyber security for UAVs, which is inclusive of all types of UAVs, however they are used.

Remotely piloted or autonomous?

The International Civil Aviation Organisation (ICAO) defines the UAV as any aircraft that does not have a pilot on board. The ICAO RPAS Guidance Manual [27] refines this definition by distinguishing the RPAS, which does have a pilot located elsewhere who manages the flight of the RPA, from the autonomous aircraft, which has no pilot.

All RPAs are controlled by the remote pilot using a Remote Pilot Station (RPS) that is connected to the RPA by a command and control link and the communications services that implement the link (termed ‘C2 link’ henceforth) that is used by the pilot to manage the flight of the aircraft. The last hop of the C2 link is provided by a wireless communications channel.

An autonomous UAV, having no pilot and managing its own flight, does not require a C2 link. It can be assumed, however that it will have a means of communicating with a control centre that dispatches it on selected tasks, that it will report its status at regular intervals and alert the despatcher to contingencies. This will require communications services and the last hop will again be wireless.

The term ‘Control Station’ (CS) is used henceforth to include both the RPS and any controlling function that a UAS might use.

National and international regulation for UAVs and cyber security

EASA Basic Regulations do not at present include cyber security for airworthiness so EASA can advise, but not enforce, compliance with the ED-200 standards when certifying an aircraft. The recent EASA Opinion on RPAS [28] does not mention cyber security, although it refers to it by implication, and it introduces two new electronic networked functions: geo-fencing (the RPA only flies where it is allowed to according to information stored in a database) and RPAS identification (a machine readable ‘name’ associated with the RPA). Both of these must be adequately protected against subversion by cyberattack.

The mechanism that regulators use to highlight specific concerns that a manufacturer or operator must address is called a ‘Special Condition’ (SC). EASA has issued several of these that apply to RPAS but not so far concerning cyber security. The Federal Aviation Authority (FAA) has issued several SCs relevant to manned aviation cyber security and these may also apply to certain RPAS.

By contrast, CAP 722 [29] provides quite specific guidance applicable in the UK, including content that is similar to the essence of the ED-200 or ISO 27000 series. Comparable regulations are in place in many countries to enable a wide variety of RPAS to operate.

ICAO addresses the international operation of RPAS beyond visual line-of-sight in non-segregated, controlled and uncontrolled airspace classes using services provided by Air Navigation Service Providers (ANSPs) such as NATS in the UK. Useful information about the work of the ICAO RPAS Panel (RPASP), including cyber security, can be found at [30].

The possibility of international operation will require that cyber security standards are harmonised for airworthiness and operations, which may conflict with established approaches at national level.

UAV cyber security issues

The issues that could give rise to cyber security breaches have to be understood in the context of manned aviation as well as that of UAVs.

UAVs flying in the ATM system

Modern manned aircraft, and the air transportation system in which they operate, are complex cyber-physical systems-of-systems [31] that are supported by communications, navigation and surveillance (CNS) services provided by a wide range of networked ICT systems. Consequently the air transportation system inherits not only the cyber security issues of the ICT systems that it uses but also those that are specific to ATM services.

A UAV flying in controlled airspace must interpret, react and respond to commands and information delivered by ATM services. It will be exposed to cyberattacks on the ATM system. Behaviour of other air users may become unsafe due to successful attack. A UAV that is flying in uncontrolled airspace may use some ATM services or it may not.

Emerging UAS Traffic Management (UTM) concept

NASA identified several years ago a need for air traffic management tailored to the needs of UAS and this concept is being developed rapidly [32]. It has been adopted in Europe where concurrent studies are continuing. UTM spans a broad range of processes and technical solutions that are needed to facilitate the use of ‘established infrastructure to enable and safely manage the widespread use of low-altitude airspace and UAS operations, regardless of the type of UAS’.

The cyber security implications of the UTM technical realisation (the ‘established solutions’), of low-altitude operation by any type of UAS have yet to be studied in detail.

Specific concerns for UAVs

Whether it is flying within or outside the ATM system, the UAV will have additional communications links and specialised functions that support it in flying safely.

Fig 1 shows an illustrative, non-prescriptive breakdown of functions. Many of the functions would be present in a fly-by-wire transport aircraft but others are found only in UAVs. These include: the C3 Datalink Services (air and ground) transported by the C2 link; Detect and Avoid (DAA); and Autonomy.

Fig 1: Flows and elements open to cyberattack on a UAV (source: ASTRAEA)

The ‘Voice Processing’ (VP) function is more speculative. If an autonomous UAV flies in controlled airspace then some means to engage in conversations with human ATC operators and pilots in other aircraft will be needed. VP would include speech recognition of ATC instructions and generation of spoken responses. The controller/pilot vocabulary is limited (provided the controllers and pilots use the prescribed commands) so such a capability could be feasible. It is likely however that it will be superseded by digital messaging protocols, e.g. CPDLC [33].

Attacks could impact all the types of flow shown in Fig 1. Those labelled as ‘Telecommand’, ‘Telemetry’ and ‘Alerts’ are part of the C2 system and could apply to any UAV. Those labelled as ‘Video’ and ‘ATM Services’ add additional pilot and controller/pilot communications functions that are necessary for a UAV integrated in the ATM system.

Note: ’C3’ refers to the combination of C2 messages with air traffic control (ATC) voice and data, and other information or operational services concerned with ATM.

Attacks on the UAS

Any function in the UAV and CS could be attacked using internal or external vectors – some detailed analysis is given in [1]. All are vulnerable: the ones that are especially sensitive are outlined in yellow because they are concerned with management of the flight of the UAV and situational awareness of the aircraft’s position, both its own and relative to other traffic. Many functions depend on each other so a successful attack on one could affect several. We describe (but not exhaustively) the main issues as follows:

  • Attack vectors – cyberattacks can be made against ICT infrastructure supporting the UAS and against the elements of the UAS itself. Attacks may originate from diverse cyber-physical sources, such as mobile phones [34] or gaming consoles [35], or be targeted at devices in the built environment [36], SCADA systems [37,38], consumer devices such as home routers, CCTV cameras or other devices that accept updates over the Internet or have undocumented backdoor openings that are insufficiently protected, e.g. a file-server or Web-server or out-dated remote logins. These vectors may exploit vulnerabilities of the UAS while in flight [39–41] and during design, manufacture or maintenance to capture sensitive information or insert false information into the system. The actual attack may be immediate or delayed and brief or prolonged. For example, malware that has been inserted into an avionic function may progressively degrade the performance of the function while concealing the degradation by manipulating the contents of status records.
  • Untrusted sources – functions that depend on external information, such as GPS or ADS-B can be misled, e.g. by substituting normal sources with one that masquerades as a valid alternative – GPS is liable to spoofing in this way, e.g. as reported in [7], and this could affect the integrity of the DAA function or others that rely on accurate positioning.
  • C2 link – Fig 1 splits into two sections separated by the last hop of the logical communications link (the C2 link) between the CS (the lower part) and the UAV (the upper part). The boundary is called the ‘signal-in-space’, representing the end-to-end communications path, including the propagation path between the transmitting and receiving antennas.
  • The signal-in-space can be attacked in various ways. The crudest attack is jamming, a denial-of-service that destroys the availability and/or integrity of information. A UAV has a natural defence against jamming, which is functionally equivalent to a lost C2 link. Pre-programmed actions in its autonomy function will be invoked to maintain safe flight, (some are described in [5]). The loss of the link will be detected by the CS and/or the UAV and must be notified to the pilot, or operator; and reported to the ATM system if the UAV is flying in a controlled airspace. Replication of the C2 link using different frequencies or different technologies will mitigate jamming. Some technologies are more robust than others to jamming but it is unlikely that it can be eliminated.
  • Eavesdropping – if an attacker can eavesdrop on communications link traffic and demodulate and decrypt it (a failure of confidentiality) then it could potentially masquerade as either the UAV or the CS, potentially as the air traffic controller (ATCO) too. As well as attacking by replaying historical valid messages or creating corrupt ones, or denying service by flooding the UAV and CS with messages that congest their memories, it could set up a man-in-the-middle attack, e.g. by manipulating frequency assignments so that it becomes a relay between them. The provenance of messages may apparently continue to be valid and the attack may only be detected by noting an unexpected variation in delay.
  • Certain communications architectures present special challenges for protection against this kind of attack. For example, an approach has been proposed that allows UAVs to forward messages from the C2 system or an ATCO to the controlled UAV that is out of range of the CS or beyond the coverage of terrestrial or satellite communications. The path taken by messages will depend on the disposition of UAVs and it may change. If an attacker is able to substitute itself for one of the intermediate UAVs then it will be able to subvert the operation of the UAS.
  • Attack on a specific function via CNS services: DAA – there are regulatory requirements for a pilot to observe other aircraft, airfield signage and weather and to report and react if necessary, termed ‘see and avoid’. A real-time video stream could provide the pilot with ‘eyes’ on the aircraft and thus a means of compliance. The sensing and image processing performed by a DAA function could supplement this stream. The integrity of the information could be threatened by malware that distorts the information enough that it increases risk and workload significantly. It could also be subverted by corruption of positioning information supplied by external untrustworthy sources or by attackers masquerading as sources of weather or air-traffic information.
  • Interaction with ATM services and ATC – the addition of ATM services increases the complexity of the UAV system and introduces new possibilities for attack. Similar to GPS, the basic information originates outside the UAV and lacks authenticity. It is claimed in [19] that some services can be subverted easily, so some ATC data and ATM information services could be delivered by masquerading attackers.

Fig 1 shows multiple paths for delivering ATM services. They can arrive via the UAV, (C3 Datalink Services – air) or by a ground network (C3 Datalink Services – ground). Delivery via the UAV, so-called ‘ATC Relay’, is the route that is acceptable to regulators and ATM service providers because it requires no change to existing ATM/ATC practice. Arguably this introduces no new vulnerabilities beyond those already outlined. Delivery via the ground, e.g. a broadband Internet service, by contrast opens the UAV system to ICT system vulnerabilities, as well as all the vulnerabilities of the ATM system.

This informal exploration of UAV cyber security concerns illustrates the wide range of technical issues that need to be addressed. The next section describes the methods that can be applied to analysing the complete RPAS to ensure that all issues are identified and addressed in a coherent and consistent way.

Methods for assuring UAV cyber security

The five actions identified in the Problem Statement are supported by a standardised process that is described in more detail here. The process aims to ensure that, because they can be costly, procedures, and physical and technical measures are proportionate to operational risk [28]. It also gives completeness, coherence and consistency in treatment to the concerns listed above and to ensures that the scope of the analysis includes the organisational, people, behaviours and values, process and physical aspects of cyber security that reinforce technical measures.

The steps below are based on the process described in ED-202A, modified slightly to apply to the UAV as a system.

First, the boundary of the UAV must be defined, including the assets (personnel, equipment, services) inside and outside the boundary and the interfaces between them – the ‘system security perimeter’. This step can be supported by applying a method such as UK HMG IS1 Prt1 [42], which generates the target of certification shown in Fig 2.

Fig 2: UAV target of certification (source: ASTRAEA)

Fig 2 identifies interfaces, platforms, services and management activities within the shaded area that, together, form the collection of objects for which measures can be specified that could achieve cyber security. Objects outside the shaded area should not be trusted – either they lack adequate protection or the provenance of information cannot be verified.

The second step is to build a catalogue of threats that the RPAS may suffer, its vulnerabilities and the potential to exploit them – a system threat identification. Many threats (sources and profiles) and attack vectors will be similar to those suffered by ICT systems. For example, the pilot may open an email that contains a virus that could infect the CS or capture and log his keystrokes. Others are threats to the UAV flight control system, sensors and actuators, and the human operators (threats to confidentiality, availability and integrity are discussed in [3,5]), with several technical exploits described in [1] in detail for UAV avionic sub-systems.

The third step is to do a (preliminary) system security risk assessment that is specific to an RPAS use-case. This must be matched with the RPAS functional hazard analysis and (preliminary) system safety assessment to assess the potential safety hazards and failure conditions. Hartmann and Steup [5] describe an approach to security risk assessment applied to three RPA use-cases for threats to availability, confidentiality and integrity. There are several risk-assessment tools that address these threats specifically, e.g. PILAR [43] or CORAS [44]. The security risk assessment will generate a collection of security requirements, maturity levels and security effectiveness objectives that are taken forward into the final two steps.

The fourth step is the specification of the security measures that protect the UAV against attack or prevent it happening, detect that an attack has occurred, or is in progress, allow reaction to the attack, and collect information to document it for forensic analysis and improvement of other measures. This requires a security architecture to be defined, which is scenario, solution and technology specific and provides the functions that will fulfil the security requirements. It will define interfaces and functions, e.g. as shown in outline in Figs 1 and 2, respectively. Compliance with any laws, rules and practices directing or regulating the operation and management of any security controls/mechanisms implemented in the functionality of the RPAS must be demonstrated.

The final step is to state the strategy to assure the implementation of the system security architecture and measures, their validation and verification, and the means to ensure their continuing effectiveness. It must identify and define the specific methods of assurance for each significant security function of the RPAS and be traceable to the security requirements. Finally, it must declare how the assurance will be continued throughout the life of the UAV.

An illustrative example of the requirements and some measures applicable to an RPAS C2 link is given in the following section.

UAV cyber security solutions for the C2 link

Work done in the UK ASTRAEA programme provided a complete risk assessment of the UAV C2 link and derived cyber security requirements for the organisation operating a UAV C2 link system, the policies and processes that the organisation must implement, management of people, protection of the physical assets and the technical solutions. The C2 link is modelled by the X2 connection shown in Fig 2.

The UAV type considered by ASTRAEA was a typical commuter jet, of the CS-23 type. The use-case was flight in airspace classes A–C, thus requiring oversight by ATC.

The organisational and process requirements showed a wide range of maturity levels for the various requirements, e.g. the model of [45]. A low level could reflect a low estimate of inherent risk, or that risk could be mitigated by sufficiently high maturity of the underpinning technical measures. Some requirements were specific enough that they define the measure required, e.g. a specific method for generating a cryptographic key, or an encryption method. The analysis highlighted several recurring themes:

  • Time stamping: Secure access to a protected time reference source is fundamental for time-stamping – necessary not only for maintenance of cryptographic integrity but also for coordinating many interactions between components of the UAV system, including C2 message sequencing and authentication. A standard such as ISO 18014 should be used [46].
  • Identity management and authentication: Any object involved in the UAV system must have a verifiable identity, possess a means of authenticating itself, and be granted access according to its role in the system. This applies to people, devices and equipment, services and business assets.
  • Controlling access: The organisation commitment, policy for granting access and the authorisation and access given, (and required processes to ensure policies are correctly implemented) are significant and require a high level of maturity. Processes and tools are needed for preventing intrusion, detecting that intrusion has happened and reacting to it. Authorisations given to people and objects to gain access should be automatically managed and audited.
  • Access controls must be enforced by establishing internal security domains and logical barriers to control flows between them. Rules to allow occasional necessary exceptions may be stated. Remote access from outside, access by portable devices using wireless media, and access to external information should be strictly controlled and protected.
  • When users present themselves to the system and request access, multifactor methods (‘something I have, something I know, something I am’) must be used to identify and authenticate them locally and remotely. Devices must be known by similar electronic criteria.
  • Requirements for physical controls include evidence of authorisation, e.g. a pass, which should identify the bearer according to role category and the areas that can be accessed. The site should be labelled to allow quick verification that an individual is allowed to be present in specific areas.
  • Protecting information in transit and in storage: Cryptographic protection to ensure integrity and confidentiality must be provided for assets (including keys) and information in store or in transit. The encryption mechanism must be adapted to a moderate traffic intensity of (mainly) short messages that may need to be acted on in short timescales. Some cryptographic methods require significant processing to verify the integrity of assets and communicated information and should be chosen with attention to the computational capability of the RPAS and the threat level increase if the protection is breached. Logical and physical separation of software and hardware components is required to prevent leakage of information. Protection of the system boundary and of the system from denial of service attacks is required. Some additional protection is needed for sessions and paths used to access external services. All flows must be protected, (especially those identified in Fig 1) and higher protection may be needed for some categories. There are additional requirements for protecting connectivity required with external organisations and maintaining the trust attributed to them. This includes end-to-end protection at relevant layers and strong mutual authentication when accessing it and name resolution services. The source of IP addresses (the Domain Name Service - DNS) would also have to be secured using the DNS Security Extensions for example [47].
  • Managing cryptographic controls: Key management from creation, through use and up to destruction must be supported by a declared policy for all aspects of cryptographic control management, including a clear association of the keys with people and objects with definition of their roles. This set of requirements requires time-stamping, management of identity and authentication, and protection of information; likewise they depend on a high level of rigour in managing the controls. A trusted PKI must be used, also together with end-to-end protection at relevant layers and strong mutual authentication.

Some of these themes are not linked to the electronic functions of the C2 link or its operation. The failure of access control or compromise of security keys could however lead to improper use of the C2 link and possible consequential safety hazards.

UAV cyber security solutions – recommendations

The preceding sections What is cyber security in aviation?, What is a UAV?, UAV cyber security issues, UAV methods for assuring UAV cyber security and cyber security solutions for the C2 link have provided a general overview of cyber security in aviation and positioned UAVs in the general context of aviation security. Specific issues for UAVs have been described, albeit briefly, and a method for addressing them comprehensively, completely and consistently has been described. Some typical measures have been outlined for the RPAS C2 link which represents an especially exposed element of a UAS. These measures are based on use of standards or best practices and illustrate the need for organisational commitment and robust processes throughout the UAS life-cycle as much as specific technical solutions.

There are three reasons for presenting the analysis in this high-level abstract way.

First, UASs are very diverse in size and capability and have many potential uses. They do not lend themselves to the type certification methods that are used in manned aviation. EASA’s categorisation of UAS has motivated the authorities to define a framework for ‘specific operational risk assessment’ that recognises the progressive increase of risk as the UAS and its use becomes more complex. UAS integrity requirements track the level of risk but cannot be easily associated with size and capability.

Second, standards often address performance without mandating specific solutions. The ICAO SARPs are sometimes specific but are often generic and high level. Industry and regulators use them to create minimum performance specifications of equipment and services operating within a certain operational safety environment. Regulators will adopt these as acceptable means of compliance (AMC) or Technical Standards Orders. From time to time the regulator will issue SCs and associated AMCs that may modify existing requirements in response to events or new safety requirements.

Third, the aviation security threat environment is constantly evolving. Security measures may become broken, especially cryptographic algorithms. Different measures may interact in ways that are only discovered after some time. New threat sources will emerge and the associated level of threat will fluctuate with the likelihood of attack. New ways of using UAVs or new technologies may create situations that are more liable to attack.

Taking these three observations together, is difficult to state indispensable requirements or point to technical solutions that would be applicable to all forms of UAS, meet all regulatory requirements and be robust enough to survive cyberattacks of types that are not yet known. At this stage, when the UAS industry is evolving so rapidly, it is likely that each case will have to be analysed specifically until a collection of baseline UAS classes and functional models emerges.

It is possible nevertheless to make some general recommendations concerning UAS cyber security to assure availability, confidentiality, integrity, authenticity and accountability. Some repeat the themes identified in the section cyber security solutions for the C2 link. Others are adaptations of requirements related to the procurement of ICT products, e.g. those recently published by ENISA [48]:

  • Robust protection of information exchanged and stored is essential but taking account of the complexity of the UAS and the operational safety environment to ensure that the computational load is manageable. Protocols and algorithms that are known to have failed must not be used. If possible the protection of information exchanged should be based on the identities of the requesting and responding entities. This suggests use of symmetric keys, although this may not be optimal for point-to-multipoint and broadcast communications.
  • Secure access to a protected time reference source is essential. A standard such as ISO 18014 should be used [46].
  • Any object involved in the UAV system must have a verifiable identity, possess a means of authenticating itself and be granted access according to its role in the system. This applies to people, devices and equipment, services, and business assets. Where identities are obtained from external sources, e.g. the DNS, access to those sources must also be secure – end-to-end, with strong mutual authentication.
  • The organisation commitment to processes and policies for establishing, maintaining security must be very strong to ensure that measures are in place to protect the assets of the system against cyberattack, to detect intrusions and attacks, to react to them via suitable contingency measures; and most important to document all aspects of the system and its operation including logging of security related incidents and auditing them to prevent future security breaches as far as possible.
  • The UAS manufacturer must provide comprehensive and understandable documentation about the design of the overall product, describing its architecture, functionalities and protocols, their realisation in hardware or software components, the interfaces and interactions of components with each other and with internal and external services. The documentation shall be updated securely without the need for a permanent reference to external information when there are major changes.
  • The UAS manufacturer shall be able to provide evidence that a managed security by design approach has been used, by itself and its supply chain, including documented secure software development, quality management and information security management processes. It must possess a current valid security certification, such as ISO27001 or equivalent) and a certification of its quality assurance processes, such as ISO 9001 or ISO 17065.
  • Authorisations given to people and objects to gain access should be automatically managed and audited. Access controls must be enforced by establishing internal security domains and logical barriers to control flows between them. Multifactor methods must be used to identify and authenticate people locally and remotely. Access must be based on the least privilege principle, where administrative rights are only used when absolutely necessary, sessions are technically separated and all accounts can be manageable. Rules to allow occasional necessary exceptions may be stated. Remote access from outside, access by portable devices using wireless media, and access to external information should be strictly controlled and protected. Appropriate physical controls and security mechanisms must be in place.
  • Cryptographic controls must be managed robustly – trusted PKI must be used, together with end-to-end protection at relevant layers and strong mutual authentication when accessing it and name resolution services.
  • The UAS must be secure by design – functionalities must be based on well-established security practices and reduced to the strict minimum required for system operations. Functions must have no undocumented features.

It is not proposed that these are mandatory for all UAS. Some will not apply according to the specific UAS. They should be used sensibly and in proportion to the complexity of the UAS and the hazards, and their consequences, associated with its use.

Conclusions

The experience of ICT cyber security is highly relevant to aviation, manned and UAVs. Standards that are already established can be reused, with some adaptation for aviation requirements, especially those concerned with safety-of-life. The link between airworthiness, operational safety and the effectiveness of cyber security measures is for further study. In addition, the regulatory scope is not agreed.

UAV cyber security must be addressed when the aircraft flies in the ATM system in controlled airspace. The ATM system represents a legacy system that provides CNS information that should not be trusted. Dependence on some services that are widely used, such as GPS, is a cause for concern.

Published research focuses on the aircraft, and technical security measures against attack from outside. Attacks by intruders that gain access through other vulnerabilities are likely to be more significant and organisational, process, and people-focused measures are likely to be as important.

A comprehensive risk assessment of the security of UAV C2 link illustrated that these measures are as numerous as the technical controls. Many of them are concerned with identification of objects that participate in a UAV system, authenticating them, and managing their access. Strong technical measures are required to achieve this, supported by high quality cryptographic protection in turn enabled by a reliable secure time reference.

Although the Problem Statement has been addressed in terms of the five actions needed to achieve cyber security, cost-efficiency has not been examined. Many of the measures proposed could apply to any UAV but should be selected proportionate to the risks to life.

While the gaps in regulation will be filled, and the next generation of the ATM system – the Single European Sky, NexGen – offer an opportunity to reduce the dependency on legacy services that cannot be trusted, the UAV operators want to move on, and interest is growing in autonomous UAVs operated on a massive scale as well as RPAS flying in the ATM system. The challenges for UAV cyber security are not addressed yet.

References

  1. Kim A. Wampler B.: ‘Cyber attack vulnerabilities analysis for unmanned aerial vehicles’, Aerospace 2012, 2012.
  2. Johnson K. Leveson N.: ‘Investigating safety and cyber security design tradespace for manned-unmanned aerial systems integration using systems theoretic process analysis’. INFORMATIK 2014, 2014.
  3. Javaid A. Y. Sun W. Devabhakturi V. et al.: ‘Cyber security threat analysis and modeling of an unmanned aerial vehicle system’. Homeland Security 2012, 2012.
  4. Birnbaum Z. Dolgikh A. Skormin V. et al.: ‘Unmanned aerial vehicle security using recursive parameter estimation’. Int. Conf. on Unmanned Aircraft Systems, Orlando, Florida, 2014.
  5. Hartmann K. Steup C.: ‘The vulnerability of UAVs to cyberattacks – an approach to the risk assessment’. Fifth Int. Conf. on Cyber Conflict, Tallinn, Estonia, 2013.
  6. Walton H. Moxon R. Chivers H.: ‘Security risk assessment of unmanned systems within European airspace’. EUROCONTROL, 2009.
  7. Infosec Institute: ‘Hacking Drones … Overview of the Main Threats’. Available at http://resources.infosecinstitute.com/hacking-drones-overview-of-the-main-threats/, accessed 12 January 2016 .
  8. Totally Unmanned: ‘UAV Cyber Security: What does it take to hack a Drone?’. Available at http://www.totallyunmanned.com/2014/10/27/uav-cyber-security/, accessed 12 January 2016.
  9. Red Team Journal: ‘Connecting the Dots in Unmanned Aerial Systems and Cyber Security’. Available at http://redteamjournal.com/2015/01/connecting-the-dots-conference/, accessed 12 January 2016.
  10. Amieri A.: ‘The five pillars of information security’, Risk Manag. Mag., 2004, 51, (7), available at https://www.questia.com/magazine/1G1-119615278/the-five-pillars-of-information-security.
  11. Lee M.: ‘Network security’ (IET Engineering and Technology Reference, London, 2014).
  12. ‘The ISO 27000 Directory’, Available at http://www.27000.org/index.htm, accessed 11 January 2016.
  13. ‘Common Criteria Portal’, Available at http://www.commoncriteriaportal.org/, accessed 11 January 2016.
  14. ITU-T: ‘ICT Security Standards Roadmap’, Available at http://www.itu.int/en/ITU-T/studygroups/2013-2016/17/ict/Pages/default.aspx.
  15. UK Centre for the Protection of National Infrastructure: ‘Cyber Security in Civil Aviation’, August 2012.
  16. The American Institute of Aeronautics and Astronautics (AIAA): ‘A framework for aviation cyber security’ (AIAA, 2013).
  17. IATA: ‘Aviation Cyber Security Toolkit’, July 2015. Available at http://www.iata.org/publications/Pages/Cyber-Security.aspx, accessed 12 January 2016.
  18. Teso H.: ‘Hijacking airplanes with an Android phone’, Available at http://www.net-security.org/secworld.php?id=14733, accessed 11 January 2016.
  19. Mail Online: ‘Security researcher tells FBI he took control of a commercial airliner’, Available at http://www.dailymail.co.uk/news/article-3084856/Security-researcher-admits-FBI-hacked-commercial-airline-s-entertainment-took-control-plane-making-climb-fly-sideways.html, accessed 11 January 2016.
  20. Threat Post: ‘EASA warns of aircraft hacking’, Available at https://threatpost.com/european-aviation-agency-warns-of-aircraft-hacking/114987/, accessed 11 January 2016.
  21. EUROCAE Working Group 72 – Aviation Security, ‘ED-201’, EUROCAE.
  22. EUROCAE Working Group 72 – Aviation Security, ‘ED-202A’, EUROCAE.
  23. EUROCAE Working Group 72 – Aviation Security, ‘ED-204’, EUROCAE.
  24. SAE Aerospace: ‘Guidelines for development of civil aircraft and systems (ARP4754A)’ (Society of Automotive Engineers (SAE) International, 2010).
  25. Patchett C. Jump M. Fisher M.: ‘Safety and certification of unmanned aircraft systems’ (IET Engineering Reference, 2015).
  26. ICAO: ‘RPAS guidance manual’ (ICAO, Montreal, Canada, 2015).
  27. EASA: ‘Introduction of a regulatory framework for the operation of unmanned aircraft’ (European Aviation Safety Agency, 2015).
  28. UK Civil Aviation Administration: ‘Unmanned aircraft system operations in UK airspace – guidance’ (CAP 722, UK CAA, 6th edn, 24th March 2016).
  29. ICAO: ‘RPAS Symposium presentations’, ICAO, March 2015. Available at http://www.icao.int/Meetings/RPAS/Pages/default.aspx, accessed 4 January 2016.
  30. Baheti R. Helen G.: ‘Cyber-physical systems’, in SamadT.AnnaswamyA. (Eds): ‘Impact of Control Technology’ (IEEE Control Systems Society, 2011), www.ieeecss.org.
  31. NASA: ‘NASA UTM 2015: The Next Era of Aviation – Documents’. Available at: https://www.utm.arc.nasa.gov/documents.shtml, accessed 20 December 2016.
  32. EUROCONTROL: ‘Frequently Asked Questions about CPDLC’. Available at: www.eurocontrol.int/faq/cpdlc, accessed 23 December 2016.
  33. Cambiaso E. Papaleo G. Aiello M.: ‘SlowDroid: turning a smartphone into a mobile attack vector’. Int. Conf. on Future Internet of Things and Cloud, 2014.
  34. Ebrahimi M. ChenL. : ‘Emerging cyberworld attack vectors: Modification, customization, secretive communications, and digital forensics in PC video games’, 2014, International Conference on Computing, Networking and Communications (ICNC), 2014, pp. 939–944.
  35. Brauchli A. Li D.: ‘A solution based analysis of attack vectors on smart home systems’. Int. Conf. on Cyber Security of Smart cities, Industrial Control System and Communications (SSIC), 2015.
  36. Johnson R. E.: ‘Survey of SCADA Security Challenges and Potential Attack Vectors’. 2010 International Conference for Internet Technology and Secured Transactions, 2010, pp. 1–5.
  37. Ramachandruni R. S. Poornachandran P.: ‘Detecting the network attack vectors on SCADA systems’. 2015 International Conference on Advances in Computing, Communications and Informatics (ICACCI), 2015, pp. 707–712.
  38. Xu X. Petgna L.: ‘Security of unmanned aerial vehicles: dynamic state estimation under cyber-physical attacks’. Int. Conf. on Unmanned Aircraft Systems (ICUAS), 2016.
  39. Hourican B. J. Andrijcic E. Faughnan M. S.: ‘Risk analysis of unmanned aerial vehicle hijacking and methods of its detection’. IEEE Systems and Information Engineering Design Symp., 2013.
  40. GirayS.M.: ‘Anatomy of unmanned aerial vehicle hijacking with signal spoofing’. Sixth Int. Conf. on Recent Advances in Space Technologies, 2013.
  41. Her Majesty’s Government UK: ‘HMG Information Assurance Standard No. 1 Issue 3.5’. October 2009.
  42. PILAR: ‘Risk Analysis and Management’, Available at www.ar-tools.com/en/tools/pilar/index.html, accessed 12 January 2016.
  43. Sourceforge: ‘The CORAS Method’, Available at http://coras.sourceforge.net/, accessed 12 January 2016.
  44. Wikipedia: ‘Capability Maturity Model Integration’, Available at https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration, accessed 8 January 2016.
  45. International Standards Organisation: ‘Information technology – Security Techniques – Timestamping Services’. ISO/IEC JTC-1, Geneva, September 2008.
  46. ‘DNSSEC: DNS Security Extensions – Securing the Domain Name System’, Available at http://www.dnssec.net/, accessed 13 February 2017.
  47. ENISA: ‘Indispensable baseline security requirements for the procurement of secure ICT products and services’ (ENISA, Heraklion, Greece, 2016).
Go to the profile of Alistair Munro

Alistair Munro

Expert in telecommunications, distributed systems and the Internet of Everything, Independent

No comments yet.