CAAS–NTU CAAS–NTU Joint Joint R&D R&D ATMRI ATMRI CAAS CAAS PROJECT PROJECT
A Study of Cyber Security Threats to Traffic Management of Unmanned Aircraft Systems Final Final Project Project Report Report 23 23 January January 2017 2017
School of of Computer Computer Science Science & & Engineering, Engineering, NTU NTU School Air Traffic Traffic Management Management Research Research Institute, Institute, NTU NTU Air Air Navigation Navigation Services Services Centre Centre of of Excellence Excellence for for ATM ATM Programme Programme Office, Office, CAAS CAAS Air
c 20162017 {SCSE, ATMRI}@NTU Copyright This project involves the following people: -
NG Wee Keong, Project Investigator, SCSE, NTU LAM Kwok Yan, Project Investigator, SCSE, NTU Vasily SIDOROV, Research Fellow, SCSE, NTU Mohamed Faisal B M SALLEH, Deputy Director, ATMRI, NTU LOW Kin Huat, PI, ASBU and ATM Modernisation, ATMRI, NTU KUOK Zhi Qiang, Programme Manager, ATMRI, NTU HO Wei Sean, Head, ANS Centre of Excellence for ATM Programme O ce, CAAS Daniel TAN Ang Tai, Manager, ANS Centre of Excellence for ATM Programme O ce, CAAS
and organizations: - School of Computer Science & Engineering, NTU - Air Tra c Management Research Institute, NTU - Air Navigation Services Centre of Excellence for ATM Programme O ce, CAAS January 2017
Change Log:
Changes in 3rd/4th editions (October 2016): Added preamble to Chapter 4 Cyber Threats to UTMS. Added Section 4.4 Threat Model in UTM Context. Added Chapter 5 Cyber Threats Analysis. Changes in the 5th edition (November 2016):
Signi cantly revised Chapter 3 Critical Assets to Be Protected. Updated Section 5.1.1 Software Components of UTMS. Extended Section 5.3 Attack Surfaces of ADS-B. Updated cyber threat classi cation throughout Chapter 5 Cyber Threats Analysis. Added Chapter 6 Implications for UTM Ecosystem. Multiple minor edits: typos, phrasing, formatting, etc.
Changes in the 6th ( nal) edition (January 2017): Added Chapter 7 Recommendations for Cyber Resilience.
Contents
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1
Project Background
6
1.2
Project Scope
7
1.3
Terminology
8
2
UTMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1
Conventional ATM Versus Future UTM
11
2.2
Cyber Vulnerabilities in UTMS Architecture
13
2.3
Cyber Security Implications
16
3
Critical Assets to Be Protected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1
Assets and Their Categories
18
3.2
Data Assets and Their States of Existence
20
3.3
Assets and Where They are Located
21
3.4
Assets Properties
22
3.5
Cyber Security Implications
23
4
Cyber Threats to UTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1
Definition of Cyber Threat
24
5
4.2
Examples of Cyber Threats
25
4.3
Properties and Characteristics of Cyber Threats
28
4.4
Threat Model in UTM Context
32
5
Cyber Threats Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1
Attack Surfaces of UTMS
5.1.1
Software Components of UTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2
Hardware Components of UTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.3
Communication Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2
Attack Surfaces of UAVs
5.2.1
Direct Attacks (I:1/2.1/2.2 S:1/2.3 T:5 M:2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.2
Wireless Attacks (I:1 S:1/2.1 T:1 M:2/3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.3
Sensor Spoofing (I:1 S:1 T:5 M:2/3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3
Attack Surfaces of ADS-B
5.4
Attack Surfaces of RPS–UAV Communication Channel (I:— S:— T:1 M:—)57
6
Implications for UTM Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1
Security by Design
60
6.2
Implications of Cyber Threats to UTMS Design
61
6.3
Implications of Cyber Threats to C2/C3 Design
63
6.3.1
Scenario 1. Unknown UAVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3.2
Scenario 2. Taken over UAVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.3
Scenario 3. Influenced UAVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.4
Implications of Cyber Threats to Detect-and-Avoid Design
65
6.5
Implications of Cyber Threats to Geo-Fencing Design
67
6.6
Concluding Remarks
68
7
Recommendations for Cyber Resilience . . . . . . . . . . . . . . . . . . . . . . . . 70
7.1
Recommendations
70
7.2
Experiments
75
34
51
56
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction
Cyber security is a concern for any country's critical infrastructures, digital or physical. With the aspiration to valorize Singapore's controlled airspace by allowing unmanned aerial vehicles to engage in civilian and commercial activities, cyber security concerns must be extended to this new form of critical infrastructure. The scope of this study and work is examined in this chapter.
1.1
Project Background There is an increasing trend in Singapore and in the world to exploit Unmanned Aircraft Systems (UAS) for civilian, commercial, public or leisure applications. Like manned aircrafts, UAS tra c must be properly managed in order to ensure that the use of UAS in an urban airspace is safe and brings value and bene ts. A UAS comprises an Unmanned Aerial Vehicle (UAV) (which can be a Remotely Piloted Aircraft (RPA) or a pre-programmed autonomous aircraft), a Remote Pilot (RP), and a Remote Pilot Station (RPS) which maintains a Command and Control (C2) radio communication link to the aircraft. If the UAV is a RPA, the RP will be controlling the aircraft throughout its ight. In the case of an autonomous aircraft, the RP will set the aircraft's ight path prior to the ight; the aircraft will then y using the pre-programmed ight path during ight.
Tra c Management Systems (TMS) are networked computer systems built upon informationcommunication technology (ICT) where human air tra c controllers work in front of com-
1.2 Project Scope
7
puter terminals interacting with tra c management software and communicating with aircraft pilots. TMS are inter-connected to other operational systems via computer networks. In this project, we refer to the tra c management of UAS as UTM (unmanned tra c management) and tra c management systems for UAS as UTMS. This is to bring clarity and distinction to conventional air tra c management (ATM) of manned aircrafts and its respective Air Tra c Management Systems (ATMS):
ATM: Air tra c management of manned aircraft systems ATMS: Tra c management system for ATM UTM: Air tra c management of unmanned aircraft systems UTMS: Tra c management system for UTM
Like any ICT systems, UTMS are susceptible to cyber threats and cyber attacks coming from external ICT systems and from within the organization. Any operational disruption arising from a cyber attack to UTMS is potentially disastrous as UAVs y in urban airspace. A critical technological enabler for a safe UTMS managing UAS air tra c is to have a secure and resilient ICT infrastructure supporting the UTMS. A baseline approach to any cyber security procedure is to conduct a comprehensive identi cation of assets, threats, points of vulnerability, and risks in the environment.
1.2
Project Scope The original project scope for this project is stated here: As UTM and UAS in an urban environment is relatively new, there are relatively few direct sources of information on current developments, and even fewer that address cyber security issues. This study proposes to use the NIST Cybersecurity Framework as a baseline to develop a more targeted approach to address cyber security issues [49]. This approach of building upon the original NIST framework has been used in other sectors such as industrial control systems, nuclear plants, and vehicular systems. The following is a set of tasks to be investigated in this project: The rst step is to understand what we are trying to protect. This includes the systems and the business environments in which they operate. Identi cation of threats and threat use cases. This provides the body of knowledge and guidance on what risks the UTM and UAS are exposed to. Identi cation of critical UTM and UAS systems/sub-systems. This identi cation is required for the security categorization and constituents to be protected. The information to be gathered includes functionalities, system boundaries, architectural description, etc. Identi cation of security controls for UTM and UAS. Identify vulnerabilities and pre-disposing conditions that aect the likelihood that threat events of concern results in adverse impacts. Determine likelihood that threat events occur and its impact. Determine the risk to organization from threat events of concern. Identi cation of assets.
8
Chapter 1. Introduction
Many things can be done to preempt, detect, thwart, and nullify cyber threats to UTM and UAS.
Identi cation of mitigation measures.
1.3
Terminology In order to establish a proper framework of study, this section introduces the terminology that will be used in this research. (Autonomous Aircraft ) An unmanned aircraft that is not fully controlled by the remote pilot. AAs maintain certain level of autonomy and require less ne-grained human control. ADS-B (Automatic Dependent Surveillance Broadcast ) is a surveillance technology in which an aircraft determines its position via satellite navigation and periodically broadcasts it, enabling it to be tracked. The information can be received by air tra c control ground stations in addition to or in lieu of secondary radar. It can also be received by other aircraft to provide situational awareness and allow self separation. ATC (Air Tra c Control ) A service operated by appropriate authority to promote the safe, orderly and expeditious ow of air tra c. ICAO explicitly appends to this definition the duty to prevent aircraftaircraft and aircraftobstruction collisions [23]. ATC Message A command/control message issued by ATC to the UAS through C2 link. ATM (Air Tra c Management ) A term encompassing all systems that assist aircraft to depart from an aerodrome, transit airspace, and land at a destination aerodrome, including air tra c control (ATC), air tra c safety electronics personnel (ATSEP), aeronautical meteorology, air navigation systems (aids to navigation), Air Space Management (ASM), Air Tra c Services (ATS), and Air Tra c Flow Management (ATFM), or Air Tra c Flow and Capacity Management (ATFCM). C2 link (Command and Control link ) The data link between the remotely-piloted aircraft and the remote pilot station for the purposes of managing the ight [36]. C2 link typically supports the following communication tasks: 1. control uplink to UAV: data to modify behavior and state of the UAV; 2. control downlink from UAV: data to indicate the position and status of the UAV; 3. DaA uplink: sensor selection/control and, if applicable, auto response state select (on/o) and override (remote pilot option to cancel the maneuvers); 4. DaA downlink: sensor data and processed sensor information (related to tra c, weather, terrain, airport visual data, etc.), con ict alert and terrain/obstacle alert and maneuver advisories (MA) and, if applicable, DaA automatic response (initiation and description), etc.; 5. data to support UAS handover, uplink and downlink; 6. data to support ight data recording requirements, uplink and downlink. CA (Collision Avoidance ) A maneuver UAV performs to avoid collision with other UAVs, AA
1.3 Terminology
9
static objects, or other aerial entities. Cyber An adjective meaning related to computers, information technology, electronic communications, and control systems. Originates from a Greek word kubern et es that means steersman. Cyber threat Any identi ed eort directed toward access to, ex ltration of, manipulation of, or impairment to the integrity, con dentiality, security, or availability of data, an application, or a federal system, without lawful authority [20]. DaA (Detect-and-Avoid ) As de ned by ICAO, detect-and-avoid is a set of technologies that provide a capability to see, sense or detect con icting tra c or other physical hazards and take appropriate actions in order to ensure the safe execution of the ight of an RPA and to full enable integration of UAVs into the shared airspace. DC An abbreviation for Data Center. Duplex channel (also, full-duplex or double-duplex ) A communication channel that allows communication in both directions, and, unlike half-duplex, allows this to happen simultaneously. GNSS (Global Navigational Satellite System ) A uni ed term for one of the global navigational systems: GPS (USA), GLONASS (Russia), Galileo (EU), BeiDou/COMPASS (China), NAVIC (India). Half-duplex channel A communication channel that provides communication in both directions, but only one direction at a time (not simultaneously). Handover The act of passing piloting control from one remote pilot station to another [36]. ICT (Information-Communication Technology ) This refers to any systems and devices comprising hardware (integrated circuits) and software (computer codes). Most of these systems and devices have a network interface allowing them to connect to the Internet or with other ICT-based systems and devices. Computers, laptops, mobile phones, tablets, wearables, RPAs, etc., are all ICT-based products. ID (Identity ) This refers to a computer-readable attribute that is unique to a single or a collection of entities. In the context of UAVs, each UVA that ies within or crosses into Singapore airspace must have a uniquely identi able attribute that can then be used to retrieve further information about the UAV (company registration, pilot ID, RPS ID, payload, etc.). IFR (Instrument Flight Rules ) A set of rules governing the conduct of ight under instrument meteorological conditions [23]. IMC (Instrument Meteorological Conditions ) Meteorological conditions expressed in terms of visibility, distance from cloud, and ceiling less than the minima speci ed for visual meteorological conditions [23]. LoWC (Loss of well clear ) Situation when another object enters the well clear area of ownship. See also: well clear. RLOS (Radio Line of Sight ) A direct electronic point-to-point contact between a transmitter and a receiver [36]. Radio transmission requires a clear path between antennas known as radio line of sight. Line of sight is the direct free-space path that exists
10
Chapter 1. Introduction
between two points. The following obstructions might obscure a visual link: topographic features, such as mountains; the curvature of the Earth; buildings and other man-made objects; trees. Obstructions that can interfere with visual line of sight can also interfere with radio line of sight. But one must also consider the Fresnel eect. If a hard object, such as a mountain ridge or building, is too close to the signal path, it can damage the radio signal or reduce its strength. This happens even though the obstacle does not obscure the direct, visual line of sight [25]. RPA (Remotely Piloted Aircraft ) A UAV that is fully controlled by a remote pilot. RPAS (Remotely Piloted Aircraft System ) A UAS that includes a remote ying pilot [36]. RPS (Remote Pilot Station ) A properly equipped location of a remote pilot from where he controls the UAV. Self-separation An ability of the aircraft to perform DaA without guidance from the tra c control center. Simplex channel A communication channel that sends information in one direction only. VFR (Visual Flight Rules ) Rules that govern the procedures for conducting ight under visual conditions. The term VFR is also used in the United States to indicate weather conditions that are equal to or greater than minimum VFR requirements. In addition, it is used by pilots and controllers to indicate type of ight plan [23]. VMC (Visual Meteorological Conditions ) Meteorological conditions expressed in terms of visibility, distance from cloud, and ceiling equal to or better than speci ed minima [23]. UAS (Unmanned Aircraft/Aerial System ) A UAV and its associated elements [36]. It can be a remotely piloted aircraft or an autonomous pre-programmed aircraft. UAV (Unmanned Aerial Vehicle ) An aircraft that operates with no pilot onboard [36]. It may be a RPA or a pre-programmed autonomous aircraft. UTM (Unmanned Tra c Management ) A term referring to a speci c type of future ATM, which fully and solely controls UAS. UTM systems (UTMS'es) are supposed to be substantially more autonomous systems compared to typical ATMS'es. Exempli gratia, UTMS should not require human interaction to control each and every UAS; however when needed, UTMS should hand control over a speci c or a group of UAS to a human operator. UTMC or UTM GCS (UTM Center or Ground Control Station ) A ground facility that hosts the UTMS [51]. Well clear A separation standard for aircraft. Is non-speci c in nature and allows for a pilot's subjective assessment when performing maneuvers for this purpose [22]. Requires more strict de nition for UAS tra c [12].
2. UTMS Architecture
To understand the cyber threat surface of UTMS, which is an emerging development in the global arena of UAS tra c management, we need to understand the functional and communication architectural dierences between conventional ATMS that regulates manned aircraft tra c and UTMS which manages tra c for UAS. This understanding prepares us for a deeper understanding of the additional challenges generated by UTMS for UAS tra c management, and the corresponding additional cyber threat surfaces to be protected. We examine these dierences in this chapter.
2.1
Conventional ATM Versus Future UTM The general communication architecture of conventional ATM is shown in Fig. 2.1:
Figure 2.1: Conventional air tra c communication architecture
12
Chapter 2. UTMS Architecture
Figure 2.2: UTMS architecture (Scenario 1)
Manned aircraft's position is tracked by GPS satellite. ATC maintains duplex ATC link with manned aircraft. ATC has air tra c controllers working on computer terminals running tra c control software (ATMS) and communicating with pilots aboard aircrafts. ATMS receives weather information from weather stations and communicates (via 802.1x link) with external ICT systems in the airport. Where UAS are concerned, the communication architecture (in dierent variations) for UTM may be conceptualized as shown in Figs. 2.2 and 2.3: UAV receives location data from a GNSS satellite. RPS controls the UAV via C2 radio link. UAV status information is relayed to RPS (in Scenarios 1 and 2, Fig. 2.2 and 2.3) and UTMC (only in Scenario 1, Fig. 2.2) via radio link. UTMC and RPS maintain a duplex communication link. UTMC has air tra c controllers working on computer terminals running tra c control software (UTMS) and communicating with pilots not aboard aircrafts. The most distinct dierence is that UTMC communicates with the remote pilot in RPS on the ground. UTMC does not maintain a link with the UAV; it only passively receives status update information from the UAS either from the UAV itself (Scenario 1) or from the RPS (Scenario 2). In addition to UAVs of the RPA family, the scope of this work also includes UAVs of the AA (Autonomous Aircraft) family. Increase in autonomy leads to increased complexity,
2.2 Cyber Vulnerabilities in UTMS Architecture
13
Figure 2.3: UTMS architecture (Scenario 2)
which expands the attack surface. We distinguish three subclasses of AAs (Fig. 2.4), in order of increasing autonomy and complexity: Autonomous Navigation: The aircraft during ight is able to navigate its way to the next waypoint given by the RP. Autonomous Flight: The aircraft has an automated control system that controls the take-o, ight, and landing phases of the ight. The aircraft is able to perform a full ight after it is given its destination. The aircraft is also able to include automatic negotiation of the ight plan with the UTMS. Autonomous Operation: The aircraft has an automated control systems that controls all phases of the ight: pre- ight, take-o, ight, landing, after- ight. The aircraft knows the purpose of its operation and is able to decide when to take o, what route to take and, when and where to land. The aircraft exchanges messages and cooperates with other AAs and with the UTMS.
2.2
Cyber Vulnerabilities in UTMS Architecture From the communication architecture perspective, a preliminary identi cation of cyber threats is performed by careful analysis of each edge (a communication link) and node (an entity) in the architecture (Fig. 2.5). Each part of the architecture is subject to a certain set of potential threats, each having its own probability of an attempted attack, probability of a successful attack, and a certain level of damage that could be caused by
14
Chapter 2. UTMS Architecture
Figure 2.4: Dierent modes of operation for RPAs and AAs
a successful attack. UTMC uses an ICT-based UTMS that is susceptible to insider cyber threats and external network cyber threats. These are the two generic cyber threats to any networked ICT systems. UTMC is also facing cyber-physical threats including power outages, connectivity issues, radio signal jamming. RPS may use an ICT-based system for the remote control of UAV. If so, it faces the same cyber threats as the UTMC. UAV faces a wide range of cyber-physical threats: signal jamming, signal spoo ng, radio frequency disruption, and diverse neutralizing technologies. This project aims to perform a more detailed exploration into the aforementioned threats. The two major threats to ICT-based systems are insider threats and network threats. Insider Threats
These are employees in the organization that may intentionally or unknowingly introduce threats and malware (malicious software code) into computer systems. The simplest form of unintentional activity is to click a malicious (but benignly masqueraded) URL link in
2.2 Cyber Vulnerabilities in UTMS Architecture
15
Figure 2.5: Cyber vulnerabilities in UTM communication architecture
an email; use an infected USB thumb drive; open an infected PDF document, MS O ce document, etc. These activities will cause some malware to be (downloaded and) installed into an organization's computers and spread throughout the entire organization's ICT systems. If an employee has malicious intent, he/she may leak system access information (such as password) to a third party that will then gain access to computer(s) in the organization. In the domain of cyber security, employees have been widely acknowledged to be a form of Advanced Persistent Threats. Network Threats
These threats infect a computer system through the Internet whereupon the system is networked. Any networked computer system is constantly receiving probing network traf c from other computer systems from all other the world. If the probes are malicious, they attempt to exploit vulnerabilities in the organization's computer systems to ultimately take control of the systems. For instance, if certain software in the organization's computers has not been patched or updated, they may contain security vulnerabilities. The probes will nd out and exploit these vulnerabilities. Such vulnerabilities may allow some computer codes to be placed into the vulnerable computers. The malicious code will gradually attempt to escalate its access rights in these computers. Such access will allow the malicious code to gain access to content in the computer; or take control of the computer; turning the computer into a bot that can be remote-controlled by another computer (Command and Control Computer). Diverse forms of malicious activities will then take place: data ex ltration, remote monitoring of organization, etc.
16
Chapter 2. UTMS Architecture
Figure 2.6: UTMS manages multiple RPs, which in turn manage multiple UAVs
We give a more detailed coverage of threats in Chapters 4 and 5.
2.3
Cyber Security Implications A preliminary cyber-security inspired exploration into UTM's communication architecture gives rise to a number of issues pertaining to the design of UAS and RPS; the concept of operations (ConOps) of tra c management for UAS; and the design of UTMS. As most work is still in its infancy, it is useful to document these issues as and when they arise. As part of the security infrastructure for UTMS, we propose to stipulate the following to be ground truths: 1. A UAV must have a unique ID (Section 1.3) that can be authenticated to the RP and RPS. 2. A RP must have a unique ID that can be authenticated to the UTMC. A unique RP may be controlling more than one uniquely identi able UAVs (Fig. 2.6). 3. A RPS must have a unique ID that can be authenticated to the UTMC. A RPS may host more than one RPs. 4. The design and speci cation of a secure UTMS must proceed currently with UTM ConOps and airspace design and speci cation as the incorporation of certain security features will impact ConOps and airspace design. For instance, seamless authentication and validation of UAVs must be performed as they cross waypoints in the airspace. 5. UAS must be built with mechanisms to support law enforcement operations (e.g., safely bringing down a UAV for inspection). 6. A UAV in the air may volunteer to act as a sensor (e.g., surveillance, weather, etc.). This helps UTMC to validate the real-time status of the airspace. In a way, such
2.3 Cyber Security Implications
17
UAVs may function as airborne patrol for dierent agencies (environmental, law enforcement, etc.).
3. Critical Assets to Be Protected
When we say that there are cyber threats to an information system and the system must be protected from cyber attacks, we generally mean that there are assets in the information system that must be kept con dential and protected from unauthorized access as such access will attempt to ex ltrate (steal) or alter the assets in such a way as to result in a state of aairs considered to be disastrous to business objectives (air tra c management). What and where are these assets in UTM? Do these assets possess special intrinsic properties or characteristics? We examine these issues in this chapter.
3.1
Assets and Their Categories Identi cation and categorization of assets is essential as it gives a crisp and actionable picture of what it is that we are protecting. In the context of tra c management for UAVs which comprises an eco-system of UTMS, UAVs, RPs, RPS'es, etc., we attempt an exhaustive list of assets and the categories they belong, to the best of our knowledge: A. Data Assets
(refer to Fig. 3.1 for origins of each item below):
1. Aircraft ID: identi cation data for UAVs 2. Flight operational and planning data: data on con rmed routes for future, current, and past ights; data on current aircraft en-route 3. Aircraft status data: position, navigation, timing, speed, health 4. Air tra c surveillance: data on UAVs tra c collected form radars, ADS-B, and/or cameras; data received from ATC regarding the civilian air tra c 5. Meteorological data: current, past and forecast weather conditions 6. Remote pilot ID: identi cation information for the pilot 7. Remote pilot station ID: identi cation information for the pilot station 8. Pilotaircraft communications: command and control communications pilot!aircraft, status communications aircraft!pilot.
3.1 Assets and Their Categories
19
9. UTMSpilot communications: automated and live messages between UTMS and pilot The above assets correspond to real-world concepts that are well understood by an air tra c controller or a pilot in the air tra c domain. In the cyber context, these concepts must be empirically captured as machine-readable data and digitally stored in computer systems. Hence, they represent computer-readable data that can be read and written by software code. As data values (such as aircraft status data) change over time, new data values will be captured and continuously added to digital storage in order to record real world events (such as aircraft ight from one point to another). These data assets are critical and integral to the correct and normal operations of air tra c management. Using software systems that process them, they feed processed information to air tra c controllers who use them to make decisions on air tra c control. As such, the data assets must be protected from cyber threats which aim to compromise the authenticity and integrity of the data values and disrupt normal air tra c control. B. Software Systems Assets
or
Information Systems Assets:
Aircraft Registry: A subsystem for managing (storing, retrieving, verifying) aircraft identi cation data Flight Management Information System: A system for management (aggregating, viewing, modifying) of ight operational data and aircraft status data Air Tra c Information System: A system that aggregates and feeds to where necessary the air tra c surveillance data, including data from ATC Meteorological Data Subsystem (self-explanatory) Remote Pilot Registry: Information system used to store, retrieve, and verify remote pilots' and remote pilot stations' identi cation data Remote Pilot Information Management System: Information system that supports data exchange between UTMS and RP Each of the above assets is software code that run on computer systems to materialize dierent functional objectives. They support air tra c controllers by processing data received from diverse sources (UAVs, remote pilots, meteorological stations, etc.), and feeding processed information to air tra c controllers to assist them in tra c management. Software code computationally manipulates the aforementioned data assets and other relevant data that are required for the overall successful operations of the software systems. Software code may be altered by insider threats (humans) or cyber threats, with the consequence that normal tra c management operations are disrupted. As such, they are at risk and must be protected. C. Physical Assets:
Unmanned aircraft and their payload: The UAV itself and any passive payload (e.g., cargo) it carries Devices onboard: Communication equipment, GNSS signal receiver, etc. Also, active payload of the UAV, e.g., a camera or other sensors.
20
Chapter 3. Critical Assets to Be Protected
Figure 3.1: Locations of assets. The numerals refer to data assets and indicate where these assets originate.
UTMS networking hardware: Infrastructure hardware of the UTMS: wired/wireless networks, network switches, hardware network rewalls, external communication hardware (radio, Internet, phone) UTMS IT hardware: Computers, servers, data storage hardware, specialized equipment Related organizations: Auditors, contractors, etc. Individuals who are by any means authorized to access any of the assets listed above Physical assets are computer hardware, humans, or organizations that revolve around the manipulation of data assets via software system assets. They are either end-users or actuators of these systems. In terms of computer hardware, we need to ensure that any purchased hardware or equipment is free from malicious software bugs. This requires proper system veri cation. From an overall cyber protection perspective, greater bene ts can be reaped by focusing on data assets and software systems assets as they are opened to scrutiny, examination and veri cation. In particular, when the software system assets are custom-designed according to speci cations, it is possible to include cyber security features during the design process. For physical assets which generally come as a closed equipment, there is a greater challenge to determine the cyber vulnerability of the equipment.
3.2
Data Assets and Their States of Existence As mentioned above, data assets are real-world concepts in a digital machine-readable form. As they are stored in computer systems, they exist in several states within and
3.3 Assets and Where They are Located
21
amongst computer systems. At any point in time, they are in one and only one of the following three states: Asset is digitally stored in some parts of the computer system In Motion: Asset is in transit between two parts of a computer system In Use: Asset is being currently used by one or several subsystems At Rest:
When data is at rest, it digitally resides either in one of the long-term storage systems. It could be a hard disk (HDD) or a solid state drive (SSD) within a computer system, a network attached storage (NAS), a passive external media (CD/DVD disks, tapes, unplugged HDDs/SSDs, etc.). The storage may or may not be within the physical premises of the ownerair tra c controller. For instance, if the owner uses cloud services, then the data may reside at some remote cloud storage systems. Data needs to be moved from one venue to another. For instance, the status information of an aircraft during ight will be captured by the sensors aboard the aircraft, temporarily stored in the sensor chip, and eventually transmitted via radio waves to the remote pilot station. During transmission, the data is in transit. Another example is data that is stored in a cloud server is now required by a computer system and is sent via computer networks to the computer system. When data is in use, it is either read and displayed onto a display panel or is undergoing arithmetic or logical operations. For instance, to display the ight path of an aircraft onto the computer screen or the air tra c control dashboard, the latitude and longitude values of each ight segment must be read from computer memory and displayed onto the display panel. Another instance is the distance computation between two ight waypoint; this involves mathematical operations. Technically, data is considered to be in use if it is loaded into operating memory, processor cache or processor registers of a computer system.
3.3
Assets and Where They are Located Data assets are generally located in software systems assets, which are in turn embedded or hosted in physical assets. Figure 3.1 shows where data assets originate from. Each data asset at every moment is either in transit or is at one and only one of the following locations:
UAV (Unmanned Aerial Vehicle) RPS (Remote Pilot Station) UTMC (Unmanned Tra c Management Center) Remote Data Center External Location (GNSS, meteorological, public information)
All of the identi ed software systems assets comprise the UTMS and are hosted (located) within the UTMC. Physical assets could be divided into three categories. UAVs and their active and passive payload are located in the located that we identify as UAV. All the UTMS hardware is
22
Chapter 3. Critical Assets to Be Protected
located within the UTMC. People and external organizations are only considered in the time frames when they are in the vicinity of the UTMC, so their location is assumed to be UTMC.
3.4
Assets Properties As established above, data assets are critical to the correct and normal operations of air tra c management. In order to more precisely describe the major forms of disruptions that may occur, we characterize three properties of data assets as follows: Con dentiality: The intrinsic utility value of a data asset has actionable consequences and must be protected from unauthorized access. For instance, the password (data asset) of a system administrator can be used to gain access to a system to perform critical tasks. If the con dentiality of the password is lost, it can be exploited for malicious intent, such as shutting down the air tra c management system. Many cyber threats aim to gain access into computer systems to access con dential data assets. Integrity: Data assets must not be corrupted or modi ed by unauthorized agents so that the data loses its utility value or increase its disruptive impact. Data assets must only be modi ed by authorized agents. For instance, the latitude and longitude values fX; Y g of an aircraft may be corrupted to become negative values f X; Y g, which are meaningless in the real-world. Another example is that Aircraft ID value cannot be modi ed to re ect a ctitious aircraft. The ight status of a ying aircraft must not be modi ed to indicate that the aircraft is on the ground. Availability: As data assets have utility values, they must be made available for use when they are required. Cyber threats attempt to violate this property by destroying the data, losing the data, keeping the computer system so busy or so slow that it is unable to timely retrieve the data for use, etc. The last form of cyber threats are called Denial of Service (DoS) attacks. These properties could be extrapolated onto other types of assetssoftware and physical. Property of con dentiality of a software or physical asset would require that data assets that are currently within the asset preserved the property of data asset con dentiality. Property of integrity of a software or physical asset would require that data assets that are currently within the asset preserved the property of data asset integrity; that the software or physical asset was not tampered with/damaged by unauthorized agent. Property of availability of a software or physical asset would require that data assets that are currently within the asset preserved the property of data asset availability; that the software or physical asset was accessible within a reasonable time when it is required; that the software or physical asset is not destroyed without authorization.
3.5 Cyber Security Implications
3.5
23
Cyber Security Implications Data assets fully represent the state of the UTM. Whatever happens in real world eventually nds its representation in the data assets within the UTMS. Whatever changes are made to the data assets in the UTMS eventually aects the real world tra c management. With this in mind, data assets could be called the most important assets of the UTMS, which are absolutely critical to the safe and smooth ow of UTM in Singapore. Cyber security of other assets (information systems, hardware, etc.) is important as long it directly aects cyber security of data assets. Therefore, data assets must be protected from all forms of unauthorized access so that their properties are preserved under all circumstances. This leads to the requirement of providing comprehensive cyber security of software systems and physical assets. What are the cyber threats and how do they violate cyber security properties of the identi ed assets? Software systems use operating systems such as Windows, Linux, or others. Tra c management software are applications that operate on top of operating systems. Are the operating systems or application software clean; or have they been preembedded/infected with unknown components? Operating systems, software applications, and other system components send and receive data over communication links, including computer networks. Computer networks are an open gateway that invites network tra c of all sorts, including cyber threats. Humans are also threats to computer systems. They may unknowingly connect a compromised USB thumb drive or external drive to their systems; click a malicious link in an email; open a malicious attachment in an email; etc. They may also harbor malicious intent and inject adversarial code into computer systems. Next chapter considers these and related questions in detail.
4. Cyber Threats to UTMS
To understand cyber threats, it is necessary to rst de ne what a cyber threat is, and what should and should not be considered as a cyber threat. In this chapter, we want to give a concrete de nition as well as examples of what a cyber threat is.
4.1
Definition of Cyber Threat The notion of a cyber threat has many de nitions. One of the more widely used de nitions is the one given by ISO 27005: A
cyber threat
is a potential cause of an incident, that may result in
harm of systems and organization
[16].
A more comprehensive de nition, tied to an information assurance point of view, can be found in Federal Information Processing Standards (FIPS) 200, Minimum Security Requirements for Federal Information and Information Systems by the U.S. National Institute of Standards and Technology (NIST): A
cyber threat
is any circumstance or event with the potential to ad-
versely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modi cation of information, and/or denial of service. It is also the potential for a threat-source to successfully exploit a particular information system vulnerability
[30].
In the context of this work on air tra c management, we derive a more targeted de nition of cyber threats:
4.2 Examples of Cyber Threats A
cyber threat
25
is a potential cause of an incident that may adversely
impact the provisioning of safe and stable unmanned air tra c ; aect data assets (Section 3.1.A), including aircraft data (IDs, status data ), air tra c data
(past,
current and planned ights, air tra c
surveillance, meteorological data ), pilot data
(pilot
IDs, station IDs,
UTMSpilot comms );
aect information systems in UTMS (Section 3.1.B), physical assets (Section 3.1.C) or individuals ;
via cyber means and mechanisms such as network intrusion, unauthorized access, destruction, disclosure, and modi cation of assets, denial of service, etc.
It is important to note that in this de nition, the emphasis is on the means of delivery of the threats and the artifacts aected. For a threat to be considered cyber, at least one of them must be of cyber1 nature. The cause of the threat may not necessarily be cyber. For example, a fallen tree that incapacitates over-the-air communications should be considered a cyber threat even though the reason is purely physical. It aects one of the information system assets in use. On the other hand, a completely non-physical entity such as a computer virus is also a cyber threat.
4.2
Examples of Cyber Threats Computer virus is a good example of a cyber threat. Computer virus is software code pre-programmed to malicious activities, such as stealing data, or holding data owner at ransom (ransomware2 ). Like a biological virus, a computer virus aims to spread to other computers in the organization's network. A computer virus achieves its goals by exploiting system vulnerabilities and deceiving people into performing certain actions. As an example of how a virus could spread and attack, let us examine the vulnerability of Windows operating systems codenamed MSB-MS10-046 (also known as CVE-2010-2568, OSVDB-66387). This vulnerability lies in how Windows OS used to (not anymore after the vulnerability was detected and xed) draw icons of les and applications in the File Explorer: as soon as a vulnerable instance of Windows OS tried to display an icon of an infected shortcut, the virus activated itself, started working on its objective, and tried to spread further through multiple channels. The following listing shows the contents (in hexademical values of bytes and in characters) of a shortcut to a PDF le as shown in Fig. 4.1:
1 See
glossary in Chapter 1.
2 Ransomware
is a class of viruses, which encrypt everything they could on a target computer and then
demand ransom for decryption keys.
26
Chapter 4. Cyber Threats to UTMS
0000-0010: 0000-0020: 0000-0030: 0000-0040: 0000-0050: 0000-0060: 0000-0070: 0000-0080: 0000-0090: 0000-00a0: 0000-00b0: 0000-00c0: 0000-00d0: 0000-00e0: 0000-00f0: 0000-0100: 0000-0110: 0000-0120: 0000-0130: 0000-0140: 0000-0150: 0000-0160: 0000-0170: 0000-0180: 0000-0190: 0000-01a0: 0000-01b0: 0000-01c0: 0000-01d0: 0000-01e0: 0000-01f0: 0000-0200: 0000-0210: 0000-0213:
4c 47 20 49 10 6d 01 54 43 5c 2d 2e 20 70 6e bd 6e bd 1c 62 ef bf 65 6a 72 6f 65 53 bd bd 53 5a 65 74
41 68 68 ef 01 62 1c 4d 3a 44 20 70 53 64 44 58 37 ef 52 65 bf bd 15 63 73 70 6d 50 ef 72 4c 44 72 6f
46 5e 04 bf 52 65 35 53 5c 65 53 64 65 66 6f 55 40 bf 65 72 bd ef 0e 28 5c 5c 62 53 bf 64 58 c9 73 70
Regular ef-ef bf bd 20-52 45 50 ef-bf bd ef bd-42 2e 2e 65-70 6f 72 72-20 32 30 6b-19 03 29 57-6f 72 6b 55-73 65 72 73-6b 74 6f 65-70 74 65 66-1e 2e 2e 70-74 65 6d 19-43 3a 5c 65-5c 44 65 54-4d 53 57 ef-bf bd 36 bd-bd ef bf 70-6f 72 74 20-32 30 31 ef-bf bd 05 bf-bd 08 25 40-ef bf ef ef-bf bd 2d 4a-6f 68 6e 52-65 70 6f 65-72 20 32 ef-bf bd 3d bd-2b c4 ba 24-ef bf bd ef-bf bd e3 ac-ef bf bd 5c-4a 6f 68
shortcut 32-ef bf 4f-52 54 bf-bd 39 ef-bf bd 74-20 2d 31-36 2e 14-ef bf 73-74 61 73-5c 4a 70-5c 52 6d-62 65 5c-52 65 62-65 72 55-73 65 73-6b 74 6f-72 6b ef-bf bd bd-ef bf 20-2d 20 36-2e 70 17-ef bf 04-1f 50 bf-bd 31 1e-1f 36 44-6f 65 72-74 20 30-31 36 78-ef bf ef-bf bd 18-2d ef 88-b7 5a 45-06 1f 6e-44 6f
to bd 7e 49 01 20 70 bd 74 6f 65 72 70 20 72 6f 73 21 bd 53 64 bd 44 53 43 5c 2d 2e bd ef bf 4a 1a 65
a PDF ef-bf 31-2e ef-bf 14-29 53-65 64-66 ef-bf 69-6f 68-6e 70-6f 20-32 6f-72 32-30 73-5c 70-60 74-61 38-55 ef-bf 65-70 66-15 01-15 46-20 50-53 3a-5c 44-65 20-53 70-64 1d-68 bf-bd bd-61 ef-bf 43-3a 5c-44
file bd 08 50 44 bd 42 ef bf 70 74 1c 6c bd 10 6e 31 44 6f 72 74 30 31 74 20 31 36 4a 6f 03 ef 74 69 41 ef bd 49 74 65 0f 40 0c 15 46 69 ef bf 55 73 73 6b 65 70 66 39 48 ef 4f ef 31 53 bd 20 5c 55 65 73
6f 46 39 bd 65 1c 55 37 65 20 36 2d 2e 68 bf 6f bf 1f 6d 76 ef 6c bd 65 74 74 31 bf bf 50 7f 73 6b
LAF....2 Gh^.REPO .h...... I...B... ..Report mber.201 ..5k..). TMSWorks C:\Users \Desktop -.Septem .pdf...\ .Septemb pdf.C:\U nDoe\Des .XUTMSWo
[email protected]. ........ .Report. ber.2016 ........ ......%. e..@.... jc(...-. rs\JohnD op\Repor ember.20 SPS...=x ....+... .rd$.... SLX..... ZD.....E ers\John top
.......o RT~1.PDF .9I...B9 ....)... .-.Septe 6.pdf.l. .......U tation17 \JohnDoe \Report. ber.2016 Report.er.2016. sers\Joh ktop`... rkstatio ..!8UA.. ......I. -.Septem .pdf..@v ........ .PDF.Fil .1SPS... .6C:\Use oe\Deskt t.-.Sept 16.pdf91 ....hH.. .....O.. -...a1SP .ZJ..... ...C:\Us Doe\Desk
In these hexadecimal values it is easy to notice references to the PDF le titled Report - September 2016.pdf, located on a machine called UTMSWorkstation17 in the folder C:\ Users\JohnDoe\Desktop\Reports. A typical virus propagation works as follows, with slight variations: 1. Alice, who is an employee of UTMC, was given a USB thumbdrive already infected with a virus, but unknown to her. 2. Alice plugs the thumbdrive into her workstation, which, say, has network address 192.168.99.100. 3. She then opens the folder with an infected le (see Fig. 4.1).
4.2 Examples of Cyber Threats
27
Figure 4.1: A shortcut to a PDF le with a report
4. As soon as the folder is opened, Windows OS makes an attempt to draw an icon for the le, which activates the virus. Note that there is even no need to open the infected le itself. 5. Once activated, the virus puts a malware (malicious software code) into a public folder in Alice's workstation. The malware is able to do many dierent things such as ex ltrating data, corrupting data, causing denial of service in the organizational network, etc. Suppose Alice's public folder is available to everyone through network path \\192.168.99.100\. In order to masquerade itself, the virus calls the executable code containing malware using an inconspicuous name and puts it in an inconspicuous looking folder, such as Microsoft\Explorer.exe. 6. The virus then looks through Alice's workstation to locate the email program such as Outlook and sends emails to her colleagues with a malformed attachment Reports.zip. 7. Alice's colleague Bob receives an email from Alice, downloads the archive, extracts it on his desktop. Instead of a report, the archive contains a malformed shortcut. As soon as the shortcut is extracted, it invokes the malware in Alice's public folder through network address \\192.168.99.100\Microsoft\Explorer.exe. Now Bob's workstation is infected as well, and the whole cycle repeats.
28
Chapter 4. Cyber Threats to UTMS
Below is the content of the infected shortcut (in hexadecimal format): 0000-0010: 0000-0020: 0000-0030: 0000-0040: 0000-0050: 0000-0060: 0000-0070: 0000-0080: 0000-0090: 0000-0099:
4c 47 97 d0 85 85 30 31 73 65
41 68 d0 85 2e 3a 30 36 6f 2e
46 5e 85 d0 20 69 d0 38 66 2e
ef-ef 20-d0 20-d0 bf-d1 20-d0 d0-bf bf-d1 2e-39 74-5c d1-97
bf 85 bf 97 bf d1 97 39 45 bf
Infected shortcut bd 32-ef bf bd ef-bf d0 bf-d1 97 d0 85-4f d1 97-d0 85 3a 69-d0 d0 85-2b 30 30 d0-bf d1 97-d0 85 21 d0-bf 97 d0-85 d0 bf d1-97 d0 85-5c 6a 5c 5c-31 2e 31-30 30 5c 4d-69 78 70-6c 6f 72 65-72 85 21-2b
bd d0 bf d1 d1 d0 39 63 2e
08 bf d1 97 97 85 32 72 65
6f d1 97 d0 d0 2b 2e 6f 78
LAF....2 Gh^..... ........ ........ ........ .:i..... 00...... 168.99.1 soft\Exp e......!
.......o ....O... ..:i.... +00..... ..!..... .......+ \j\\192. 00\Micro lorer.ex +
The infected shortcut points to malicious executable code located in the local network containing Alice's computer with IP address 192.168.99.100. Note that in order to deceive unsuspecting end users, the malicious executable code is called Explorer.exe, which gives a psychological level of credibility. This speci c vulnerability has been xed, but software as big and complex as operating systems inevitably have many vulnerabilities that are still there. Thus, it is important to continually maintain computer systems, such as applying security xes on a regular basis, updating antivirus software, and following all typical rules of good IT hygiene.
4.3
Properties and Characteristics of Cyber Threats Cyber threats are a big part of any organization's lifecycle nowadays. New cyber threats constantly emerge and cyber attacks are continuously happening throughout the world. Real-time reports by ThreatExpert Ltd.3 indicate an average count of one new cyber threat every several minutes (Fig. 4.2). The real-time world map of cyber attacks by Norse Corp.4 shows hundreds of attacks per second detected by more than 8 million of their network sensors (Fig. 4.4). In 2014 the National Anti-crime Computer Centre for the Protection of Critical Infrastructures (CNAIPIC) reported 1,151 cyber attacks (Fig. 4.3), 161 of which involved web defacement5 , and 50 Distributed Denial of Service6 (DDoS) against institutional Internet websites and Italian critical infrastructure systems. Of these attacks, 64 were system intrusions and 187 compromises due to malware, which had infected the websites of institutional entities and private enterprises [17]. There is a distinction between a threat and an attack. A threat is a wider notion as it includes the full range of potential causes of problems. An attack is a threat that has been 3 http://www.threatexpert.com/ 4 http://www.norse-corp.com/ 5 An
attack carried out against a website with an objective of modifying the contents of the homepage
or of other pages of the website.
6A
denial of service attack that uses an army of infected computers (thus, distributed) to ood the
target system with requests.
4.3 Properties and Characteristics of Cyber Threats
29
Figure 4.2: A real-time report on new cyber threats Source: http://www.threatexpert.com/reports.aspx?tf=1
materialized. An attack has an attacker who performs the attack, whereas a threat does not necessarily have a person or an organization behind it. Moreover, the same threat may be realized either as an attack or not as an attack. As an example, a power outage in UTMC may happen due to water damaging electrical equipment during the rainy season (not an attack), or due to an adversary damaging the power lines (an attack). intentionally
Cyber threats could be categorized and classi ed by multiple attributes. The categories of a cyber threat greatly aect the ways to protect, detect, and mitigate them. Some of the widely adopted categorizations include: Intent: intentional and unintentional threats. As an example, a laptop with credentials of UTMS could be stolenthis is an intentional threat. At the same time, it could have been forgotten in a taxi by a negligent employee7 . Scope: targeted and non-targeted threats. In the case of a targeted threat, UTMS is a primary target. The threat could be speci cally crafted to target UTMS using prior knowledge about how it operates, both from public sources and from data leaks. Leaks could happen through employ7 Laptops
with sensitive data left in cabs are often reported as one of the major sources of data leaks.
30
Chapter 4. Cyber Threats to UTMS
868
187
169 64
Intrusions
50
Defacement
DDoS
Malware
Others
Figure 4.3: Attacks addressed by CNAIPIC in 2014 Source: 2015 Clusit Report
ees, through stolen devices, or through prior attacks. Attacks that have collected information about the system as their primary objective are often called reconnaissance attacks. Non-targeted threats do not have UTMS as a primary target. It could either be a threat that does not have any target (e.g., a natural disaster), or a threat that, for example, targets SCADA8 systems in general and therefore is a threat to UTMS in particular. Source: nation states, criminals, hackers, insiders, etc. The source of the threat greatly aects the consequences of the threat being realized. Threats originating from foreign nations could be aimed at espionage or sabotage of a critical infrastructure system. Criminals are typically after monetary reward, and are likely to be stealing sensitive data that may have a cost in the black market, or hold the target organization at ransom. Hackers could be motivated by glory points or may demand a reward from the target organization for the vulnerability they discovered (so-called, grey hat hackers). Insiders are often motivated by revenge towards the organization that they feel have been unfair to them in some way: over-worked employee, a recently red employee, etc. Channel: network, hijacked hardware, hijacked UAV, human factor, etc. Dierent threats may be realized through dierent channels, and each channel requires its own way of monitoring and threat mitigation. Some threats use multiple channels. For example, viruses have a multitude of ways to enter the system; through email, through USB media (thumbdrives, external HDDs), through local networks using operating system vulnerabilities. One channel of threats is human mistakes; this channel can be mitigated by investing in fool-proo ng critical subsystems, im8 Supervisory
control and data acquisition
4.3 Properties and Characteristics of Cyber Threats
31
Figure 4.4: A real-time map of cyber attacks. Circles show attack targets. Source: http://map.norsecorp.com/
proving user experience to reduce strain, cyber security education of personnel, and many other approaches. It has been repeatedly reported that threats originating from insiders are the most dangerous. Threats of other categories may work in conjunction with an insider, which ampli es the capabilities of the threat. As an example, a hacker that was hired by a foreign nation may oer a monetary reward to an employee who is feeling underpaid for him to assist in an attack on UTMS. Varying sources of cyber threats require dierent types of defense mechanisms. The potential goals of attackers include:
Stealing information Incapacitating (sub-)systems Establishing surveillance Modi cation of information Deletion/corruption of information
Studies on the topic of cyber security distinguish up to ve levels of attacker sophistication: L1: Cyber Vandalism: Adversaries with very limited expertise; they typically conduct non-targeted attacks primarily focused on an organization's perimeter. L2: Cyber Criminals: Adversaries with a limited technical expertise; the typical intent is to acquire critical or sensitive information. L3: Cyber Surveillance: Adversaries that possess moderate expertise; they are capable of executing a multi-stage planned attack; they seek to establish a foothold inside an organization. L4: Cyber Espionage: A very sophisticated version of cyber surveillance; they
32
Chapter 4. Cyber Threats to UTMS
use similar methods and goals but with much greater expertise and resources. L5: Cyber Warfare: Extremely sophisticated and resourceful adversaries; they are capable of long, planned, and coordinated attacks.
4.4
Threat Model in UTM Context A threat model is a comprehensive description of the types of threats that are included in the scope, as based on categorizations discussed above. In this section we establish and discuss the threat model that will be used in this work. A threat model serves two purposes. First, it states what is covered by the analysis of cyber threats to UTMS. By looking at the threat model, one is able to quickly understand if a speci c threat is covered by the analysis. Second, the threat model helps to ensure that we did not miss anything that is to be covered in the analysis. For example, we can pick categories like Accidents, External Forces, and UAVs, and check whether we have a section that covers incidents that happened to UAVs due to external forces. The threat model that is used in this work has four dimenions. All cyber threats are classi ed under a combination of 4 properties: intent, scope, target, and manageability: [I]ntent 1. Intentional Threats 1.1 Malicious Insider:
The threat comes from an insider(s), someone who has certain level of authority in the system according to his/her position in the organization. The insider might have the malicious intent from the beginning or has recently turned malicious. His goals could vary from passive surveillance to active interfering with the system. 1.2 Malicious Outsider: The threat comes from an individual or a group that is external to the organization. An outsider does not have an existing foothold in the organization. His goals could vary from passive surveillance to active interfering with the system. 2. Unintentional Threats 2.1 Hardware/Firmware/Software Failure:
A threat arising from hardware or software malfunctioning with negative consequences. If the reason for malfunctioning is that assets were tampered by an adversary, this falls into one of intentional threats category. 2.2 Accidents: A threat of unintentional accidents, results of human factor, etc. Accidents of human factor nature could be the result of badly designed tools, policies, workplace, etc. [S]cope 1. Targeted:
The source of threat is directly targeting the security of unmanned aviation in Singapore. The attacker may have prior knowledge about the system and use it against it.
4.4 Threat Model in UTM Context
33
2. Non-targeted: 2.1 Sweep Attack:
The threat is targeted at a large number of systems; the UTMS happened to be amongst them. 2.2 External Forces: The threat is a result of external circumstances (natural or man-made). 2.3 Accidents: The threat is a result of negligence or an accident. [T]arget 1. Communication Channel: 2. 3. 4. 5.
The target of the threat is a communication channel between two or more parts of the whole system. IT/Networking Hardware: The target of the threat is the IT/Networking hardware that supports the UTMC operations. Information Systems: The target of the threat is one or more information systems comprising UTMS. RPS: The attack targets remote pilot stations. UAV: The target of the threat is one or more aerial vehicles.
[M]anageability 1. Fully Manageable:
Threats that are fully manageable by UTMC. 2. Partially Manageable: Threats that are not fully manageable by UTMC; e.g., a threat's target or origin is beyond the immediate reach of UTMC. 3. Completely Unmanageable: Threats that UTMC can do nothing to prevent from realizing; e.g., weather conditions.
To categorize cyber threats in this work we will use a short-hand notation to refer to the threat model. For example, for a threat of a malicious outsider exercising a sweep attack on information systems we will use a notation I:1.2 S:2.1 T:3 M:2, which refers to speci c categories of Intent, Scope, Target, and Manageability. A comprehensive analysis of cyber threats to UTMS that is presented in Chapter 5 will apply this model to all the identi ed cyber threats.
5. Cyber Threats Analysis
This chapter shows through the prism of the threat model how the components of the UTM eco-system may be compromised. It is delivered through a systematic analysis of cyber threats to such components of unmanned tra c management as the UAVs, the UTMS, the support infrastructure. In addition, we look into system-wide threats that span across dierent components. Since all components are interconnected through data communication channels, an attack on a single component can propagate its eects throughout the entire system.
5.1
Attack Surfaces of UTMS UTMS is the center piece of the unmanned air tra c eco-system. It is the part with the most responsibility with the greatest impact factor on the eco-system, and having the largest attack surface. We must scrutinize the cyber threats to UTMS. In the asset identi cation stage we have identi ed the cyber-physical assets of the UTMS (Section 3.1); their interconnectivity is shown in Fig. 5.1. Information systems (orange boxes) that run on hardware (green boxes) exchange data assets (orange arrows) with each other and with external entities through Internet and other network/communication channels. They are controlled and otherwise accessed (blue arrows) by users, maintenance sta, and external people and organizations (blue boxes), and are powered by electricity (yellow box and arrows).
5.1.1
Software Components of UTMS The software assets that were identi ed earlier could be split into 4 groups: 1. Client-side application; marked as Apps in Fig. 5.1. These are applications that the sta of UTMC are directly interacting from their end-point devices (workstations,
5.1 Attack Surfaces of UTMS
35
Figure 5.1: Diagram of UTMS cyber-physical components
thin clients, mobile devices, etc). 2. Server-side application; marked as Server Apps in Fig. 5.1. 3. Operating System or OS (same as in Fig. 5.1). Typically, a Windows OS on a workstation and a Windows Server or Linux OS on servers. 4. Firmware (same as in Fig. 5.1). A computer program that implements the logic of a specialized device (e.g., a network router). Depending on the speci c device, it could be a simple program or a full- edged operating system. We consider these groups individually below. A. Information Systems
The typical architecture of enterprise information systems today is a so-called clientserver architecture. This is a general term for an architecture in which each user works with his own instance of a client-side application, which in turn communicates with a central server-side application. Client application serves two main purposes: (1) entry/modi cation of data; (2) presenting data. For entry/modi cation of data, the client application is usually limited to simple input validation. For example, if a user has to input an approved time for a ight, the application checks that the input could be parsed as time; e.g., compare these two inputs (a correct one: 26-Dec-2016 15:23, and one with a typo: 36-Dec-2016 15:23). The input is then sent to a server, which runs more thorough checks against all the data it currently has, and either accepts the input or rejects it and tells the user the reason. The server then sends the latest data to the client application, which shows (presents) it
36
Chapter 5. Cyber Threats Analysis
to the user so that he could act upon it. The clientserver approach proved useful as it solves three major issues in a typical enterprise work ow: 1.
Working with same datasets.
The data stored in information systems is a re ection of happenings in the real world. When UAVs change their location they send updates to the information systems, where data about their positions is updated. Likewise, when a UTMC sta updates UAVs ight plan status to approved in the information system, the remote pilot starts to pilot the UAV according to the ight plan. When the data is scattered among all sta's end-devices, and every sta is working with the data, it is hard to tell which of the slightly dierent versions of the data actually re ect the reality. Moreover, typically the answer is none. The clientserver architecture provides a single source of truth: the server has the only full and correct dataset, clients only work with up-to-date data. 2. Coherent updates. Updating enterprise software is an important and di cult task, as it requires updating the software on many workstations in dierent locations of the enterprise. The de-facto standard of delivering a client-side application in a clientserver architecture is through web browsers such as Chrome, Firefox, or Internet Explorer. Instead of downloading and installing an application, sta go to a speci c internal web address using their browser and immediately access the required application. In this architecture, updating an information system is as simple as updating it once on the server and then forcing users to refresh the page. 3. Thin clients. Since most of the computational work is done on the server, and the client-side application only displays the data and accepts input, which all happens in a web browser, it becomes possible to use any Internet-enabled device such as thin clients1 , smartphones, and tablets to access enterprise applications. This increases productivity as it allows sta to take action even when they are away from the o ce desk, and cuts expenditure on IT infrastructure as thin clients are cheaper than full- edged workstations.
The type of clientserver architecture that is typically found in enterprises today is called a three-tier architecture (Fig. 5.2). It consists of a presentation tierclient-side applications, application tierserver-side applications, and data tiera specialized data repository system. Communication between tiers happens across a local network. Server-Side Applications
We have identi ed six essential software components of the UTMS: Aircraft Registry, Flight Management Information System, Air Tra c Information System, Meteorological Data Subsystem, Remote Pilot Registry, Remote Pilot Information Management System. Overall, these software components (as well as operating systems and hardware rmware) 1 Originally,
a thin client is a low-grade computer, often of a very small form-factor, that is pow-
erful enough only to run a web browser. smartphones and tablets.
Lately, the term became more generic and now also includes
5.1 Attack Surfaces of UTMS
37
Figure 5.2: Three-tier system architecture
are exposed to typical threats to a software system: Internal threats:
(I:2.1 S:1/2.3 T:3 M:2) De ciencies of coding the software that makes it behave unstably and unreliably in speci c scenarios. E.g., if the Air Tra c Information System uses data type unsigned byte to track the overall number of the vehicles in the airspace, the system will start working incorrectly if there are more than 255 aircrafts in the air. Bugs could be created by accident or on purpose. Application logic errors (I:2.1 S:1/2.3 T:3 M:2) A computer program that is written properly from the technical point of view but does the wrong thing. Similarly to bugs, it could be created on purpose or by accident. Unlike bugs, it is much harder to nd using automated tools (e.g., static code analysis). Software bugs
External threats:
(I:1 S:1/2.1 T:3 M:1) A buer over ow, or buer overrun, is an anomaly where a computer program, while writing data to a pre-allocated buer in memory, overruns the buer's boundary and overwrites adjacent memory locations. Contradicting data (I:1 S:1/2.3 T:3 M:1) It is not rare that information systems do not handle data anomalies well. One of the data anomalies is self-contradicting data. Client-side applications that are built under the assumption that the server is the source of truth, may collapse if they cannot make sense out of data they receive from the server. As an example, if the ight plan contains the time of landing that is earlier than the time of take o, whenever the system computes ight duration, it is likely to crash due to inability to handle negative time spans. Invalid data (I:1 S:1/2.3 T:3 M:1) Another data anomaly is invalid data. Typically, client-side systems validate data Buer over ow attacks
38
Chapter 5. Cyber Threats Analysis
before sending to the server. This protects against human errors or malice. Generally, the server expects data that it receives to be always valid. It might not handle well when incoming data is invalid, when an adversary manages to bypass data validation. Examples of invalid data are: Date of flight : 36-Dec-2016non-existent date; Number of flights : Johnexpected a number but got a word instead; etc. Violation of communication protocol (I:1 S:1/2.1/2.3 T:3 M:1) All forms of communication between client-side and server-side applications, and between various server-side applications must abide by communication protocols. Such protocols could be custom-built for the information system or they can be standard universal protocols such as REST, SOAP, CORBA, MQTT, XML-RPC, etc. Systems expect all other systems they interact to follow the communication protocol. They do not always handle well situations when their collocutors start violating the protocol and behaving unexpectedly. Denial of service attacks (I:1 S:1/2.1/2.3 T:3 M:1) A denial of service (DoS) attack is an attempt to make a machine or network resource unavailable to its intended users, such as to temporarily or inde nitely interrupt or suspend services of a host connected to the Internet. DoS attack may also result in the information system falling into an unexpected state after the attack has taken place, which could be used for the next attack. A DoS attack could be a result of a bug or application logic error rather than the actions of a malicious adversary. Input injection attacks (I:1 S:1 T:3 M:1) Input injection is the exploitation of a computer bug that is caused by processing invalid input. Injection is used by an attacker to introduce (or inject) code into a vulnerable computer program and change the course of execution. The result of successful code injection is often disastrous; for instance, code injection is used by some computer worms to propagate themselves. Code injection is the most powerful attack and can be achieved through a combination of some or all of the above methods. Client-Side Applications
Client-side applications in a modern enterprise environment are typically delivered via web browsers as it is an e cient, low-cost, and highly manageable approach. They are prone to the common threats to web applications. Even if the client-side application itself is not web-based, many of the typical threats discussed in this section are still valid. The Open Web Application Security Project (OWASP) has identi ed ten main threats to web applications, which are discussed below in connection to the line of business of a UTM Center. This section presents threat classi cation according to both OWASP threat model and the threat model designed for this report.
5.1 Attack Surfaces of UTMS
39
(1) Injection (I:1/2.2 S:1/2.1/2.3 T:3 M:1) Exploitability
EASY
Security Weakness
Prevalence COMMON
Detectability AVERAGE
Tech. Impact
SEVERE
Realization of an injection attack happens when an interpreting component of the application receives a malformed input. Injection aws are very prevalent, particularly in legacy code. Injections may occur through database queries, commands to operating systems, application launch arguments, XML parsers, etc. Injection aws are easy to discover when examining code, but are often hard to discover via testing. There are automated tools such as scanners and fuzzers that attackers routinely use to nd injection aws. Injection can result in compromising data integrity, data availability, in data destruction, in lack of accountability, and can sometimes lead to complete host takeover. Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources. Threat Agents Anyone who can send untrusted data to the system, including external users, internal users, and administrators. Speci cally, for UTMS the main injection threat agents are RPSs and UAVs, who can malform their communication messages to UTMS to try and hijack components of UTMS. Operational Impact Consequences of injection attacks could range from negligible to extremely severe. In a typical scenario, injection attack could lead to modi cation or corruption of the data in the aected system. Injection attack is also often a gateway inside the system for an attacker, which is used to perform further attacks. Exploitation
(2) Broken Authentication and Session Management (I:1 S:1 T:3 M:1) Exploitability
AVERAGE
Security Weakness
Prevalence WIDESPREAD
Detectability AVERAGE
Tech. Impact
SEVERE
Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, the custom schemes frequently have aws in implementing such procedures as logging in/out, secure password management, remember me, password recovery procedures, account update, etc. Finding such aws can sometimes be di cult, as each implementation is unique. The aws in the authentication/session mechanisms could compromise fully or partially some or all accounts in the system. Once successful, the attacker gains all rights and capabilities in the system that the compromised account has. Privileged accounts are frequently targeted. Attacker uses leaks or aws in the authentication or session management functions (such as exposed accounts, passwords, session IDs) to impersonate users.
Exploitation
40
Chapter 5. Cyber Threats Analysis
Anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Potentially, insiders wanting to disguise their actions. Negligible users who inadvertently expose/compromise their account information. Operational Impact Could lead to full incapacitation of UTMS. In a most probable scenario of this attack, the adversary would be able to a) establish internal surveillance over UTMS operations; b) delete/corrupt/modify/read chunks of data that the compromised account has access to. Threat Agents
(3) Cross-Site Scripting (XSS) (I:1 S:1 T:3 M:1) Exploitability
AVERAGE
Security Weakness
Prevalence VERY WIDESPREAD
Detectability EASY
Tech. Impact
MODERATE
XSS is the most prevalent web application security aw (84% of all security vulnerabilities documented by Symantec as of 2007). XSS aws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are two dierent types of XSS aws: (1) stored and (2) these can occur on the (a) server or (b) on the client.
re ected,
and each of
Detection of most Server XSS aws is fairly easy via testing or code analysis. Client XSS is very di cult to identify. Attackers can execute scripts in a victim's browser to steal account credentials, delete/ corrupt/modify/read data that the compromised user has access to, scam users into giving out classi ed information, plant a virus on a user's computer, etc. Attacker sends text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database. Threat Agents Anyone who can send data to the system, including external users, internal users, and administrators. Depending on system con guration, it could be virtually anybody with Internet access, anybody who can gain remote access to the internal UTMS network (e.g., through valid or stolen VPN access), or anybody who is physically located within the UTMC. Operational Impact Potentially could reach high level of control over UTMS and therefore incapacitate or modify the operations. In a most probable scenario, the adversary can corrupt/steal/modify some data in the system, including access credentials. Could be used as a rst step in a multi-tiered attack. Exploitation
5.1 Attack Surfaces of UTMS
41
(4) Insecure Direct Object References (I:1 S:1 T:3 M:1) Exploitability
EASY
Security Weakness
Prevalence COMMON
Detectability EASY
Tech. Impact
MODERATE
A common approach to building web-based user interfaces is to have the root UI element to reference its components directly by name without checking if the requester has enough privileges to retrieve the component. Instead, application only checks whether the requester has access to the root element, hoping that an unauthorized requester does not know names of interface components and therefore will not be able to request them. This is an example of an ineective practice called security by obscurity, and results in an insecure direct object reference aw. Flaws of this kind are easily detected by testers through parameter manipulation, and could also be easily identi ed by code analysis. Such aws can compromise all the data that can be referenced by the parameter. Unless object references are unpredictable, it is easy for an attacker to access all available data of that type. Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn't authorized for. Threat Agents All potential users of the system. An attack is most likely to originate from a remote pilot. Operational Impact Unless combined with some other severe design aws, the attack most likely results in disclosure of information the requester did not have access to, including information about remote pilots, UAVs, ight plans, civil air tra c, communication data. Exploitation
(5) Security Misconfiguration (I:1 S:1/2.1 T:3 M:1) Exploitability
EASY
Security Weakness
Prevalence COMMON
Detectability EASY
Tech. Impact
MODERATE
Security miscon guration can happen at any level of an application stack, starting from the operating system, to the platform (web or application server, virtual runtime machine, etc.), data-tier applications, frameworks, custom code, and sometimes even hardware. Ensuring that the entire stack is con gured properly requires trained personnel, security maintenance processes in the organization, and automated scanners that are useful for detecting missing patches, miscon gurations, use of default accounts, unnecessary components, etc. Attacker accesses default accounts, unused pages, unpatched aws, unprotected les and directories, etc., to gain unauthorized access to or knowledge of the system.
Exploitation
42
Chapter 5. Cyber Threats Analysis
Anonymous external attackers as well as users with their own accounts that may attempt to compromise the system. Also consider insiders wanting to disguise their actions. Operational Impact The system could be completely compromised without you knowing it. All the data could be stolen or modi ed slowly over time. Recovery costs could be expensive. Threat Agents
(6) Sensitive Data Exposure (I:1.1/2 S:1/2.1/2.3 T:3 M:1) Exploitability
DIFFICULT
Security Weakness
Prevalence UNCOMMON
Detectability AVERAGE
Tech. Impact
SEVERE
There are many ways the sensitive information could be exposed. One of the biggest in uencers is not encrypting the data. Even if the data is encrypted, it is common that inappropriate or weak encryption algorithm was chosen or the en-/decryption keys are stored, managed, or generated insecurely. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have di culty detecting server side aws due to limited access and they are also usually hard to exploit. Failure frequently compromises all data that should have been protected. Typically, this information includes sensitive data such as credentials, personnel personal data, pilots' personal data, ight plans, UAV information such as model, owner, operator, etc. Usually, attackers do not directly break cryptography. Instead, they exploit mistake in implementation and secret management: stealing keys, man-in-themiddle attacks, or stealing clear text data o the server, while in transit, or from the user's browser. Threat Agents Threat ca originate from both internal and external sources. Whoever can gain access to sensitive data and any backups of that data. This includes the data at rest (stored on hard drives), in transit (travelling through networks), and in end user applications. Operational Impact Exposure of data to unauthorized parties. Information could include sensitive data about members of UTM in Singapore, or UTMS access credentials. Could be used as an early stage of a multi-tiered attack.
Exploitation
(7) Missing Function Level Access Control (I:1 S:1 T:3 M:1) Exploitability
EASY
Security Weakness
Prevalence COMMON
Detectability AVERAGE
Tech. Impact
MODERATE
This security aw is often a result of employing an unreliable security by obscurity approach. The aw is in applications not performing proper authorization checks when
5.1 Attack Surfaces of UTMS
43
user requests a certain function. This could be a result of miscon guration of the system, or bad coding. Flaws of this kind are easily detected if there is a proper inventorization of all the system functions and access roles. Such aws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack. Attacker, who is an authorized system user, simply changes the URL or a parameter to a privileged function. Anonymous users could access private functions that aren't protected. Threat Agents Anyone who can send a request to the UTMS. Operational Impact Unauthorized use of unprotected functionality of UTMS. Exploitation
(8) Cross-Site Request Forgery (CSRF) (I:1 S:1 T:3 M:1) Exploitability
AVERAGE
Security Weakness
Prevalence COMMON
Detectability EASY
Tech. Impact
MODERATE
Cross-site request forgery is also often referred to as one-click attack and session riding, and is typically abbreviated as CSRF or XSRF. CSRF is a type of attack that exploits the trust an application-tier application has towards the presentation-tier application (unlike XSS, which exploits the trust a user has for a particular site). Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones. Detection of CSRF aws is fairly easy via penetration testing or code analysis. Attackers can trick victims into performing any state changing operation the victim is authorized to perform, e.g., for pilots: updating account details, requesting a ight plan, registering a UAV, etc.; for personnel: changing ight plans, changing pilots' details, creating an access point for the attacker, etc. Attacker creates forged HTTP requests and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is authenticated, the attack succeeds. Threat Agents Anyone who can load content into your users' browsers, and thus force them to submit a request to your website. Any website or other HTML feed that your users access could do this. Operational Impact If successful, an attacker is able to do everything that the compromised user can do in the system. Exploitation
44
Chapter 5. Cyber Threats Analysis
(9) Using Components with Known Vulnerabilities (I:1 S:1/2.1 T:3 M:1) Exploitability
AVERAGE
Security Weakness
Prevalence WIDESPREAD
Detectability DIFFICULT
Tech. Impact
MODERATE
Virtually every application has these issues because most development teams do not have an established procedure of ensuring that the components they use are up to date. It is also often an issue of personnel professional training and communications between employees: in many cases, the developers are not aware of all the components that are being used in the project. The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could range from minimal to complete host takeover and data compromise. Attacker identi es a weak component through scanning, manual analysis or another source of intel. He customizes the exploit as needed and executes the attack. It gets more di cult if the used component is deep in the application. Threat Agents Some vulnerable components (e.g., framework libraries) can be identi ed and exploited with automated tools, expanding the threat agent pool beyond targeted attackers to include chaotic actors. Operational Impact Varies from negligible to severe, depending on circumstances. Exploitation
(10) Unvalidated Redirects and Forwards (I:1 S:1 T:3 M:1) Exploitability
AVERAGE
Security Weakness
Prevalence UNCOMMON
Detectability EASY
Tech. Impact
MODERATE
Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is speci ed in an unvalidated parameter, allowing attackers to choose the destination page. Unvalidated redirects are easy to detect manually and using automated tools. Unvalidated forwards could be marginally harder to detect. Such redirects may attempt to install malware or trick victims into disclosing passwords or other sensitive information. Unsafe forwards may allow access control bypass. Attacker links to unvalidated redirect and tricks victims into clicking it. Victims are more likely to click on it, since the link is to a valid site. Attacker targets unsafe forward to bypass security checks. Threat Agents Anyone who can trick your users into submitting a request to your website. Any website or other HTML feed that your users use could do this. Operational Impact Most likely to aect remote pilots and could lead to disclosure of their information, stolen access credentials, impersonated actions. Exploitation
5.1 Attack Surfaces of UTMS
45
Data-Tier Applications
Data-tier applicationscolloquially called databasesare one of the most compromised assets according to the 2014 Verizon Data Breach Report [63]. Databases are at the heart of any organization, storing all operational data, including the business-critical and therefore are often a primary target for an attack. One of the reasons for databases to be prone to compromise is that organizations are not protecting these crucial assets well enough. According to IDC, less than 5% of the $27 billion spent on security products directly addressed data storage and management security [34]. At the same time, the vast majority of incidentsmore than 97% according to the Online Trust Alliance's (OTA) report in 2013could have been prevented by implementing simple steps and following best practices and internal controls. Gaining access to the sensitive data gives external and internal adversaries means to quickly ex ltrate valuable data, cause damages and impact business operations. Moreover, in modern reality fully or almost fully managed with the aid of computers, digital data is business operations. In addition to nancial loss or reputation damage, breaches can result in regulatory violations, nes, and legal fees. This section outlines the top ten threats to database systems [35]. These threats are not only relevant to the traditional relational database systems but also to the newer data management technologies such as document-oriented database systems, keyvalue stores, graph databases, and others. 1. Excessive and Unused Privileges (I:1.1/2.2 S:1/2.3 T:3 M:1)
When someone is granted database privileges that exceed the requirements of their job function, these privileges can be abusedintentionally or not. An employee whose job is related to ight plan management should not have access to the data on RPS and UAV registration in the system, and vice versa. It is also often that an employee whose job scope changes or who leaves the organization does not have his data access privileges updated accordingly. In the case of leaving the organization, if the employee departed on bad terms they can use their old privileges to in ict damage. Typically, users end up with excessive privileges due to control mechanisms for job roles not being well de ned or maintained. As a result, users may be granted generic or default access privileges that far exceed their speci c job requirements, or they may simply accumulate such privileges over time. This creates unnecessary risk. 2. Privilege Abuse (I:1.1 S:1 T:3 M:2)
Users may abuse legitimate database privileges for unauthorized purposes. As a n example scenario, an employee may aid an external adversary by approving an illegitimate ight plan, or removing all trace of such ight (e.g., a cross-border ight by a smuggling UAV). While this risk is hard to mitigate, typical approaches to lowering it include ensuring that all actions are properly logged (a property of non-repudiation, i.e., a user that com-
46
Chapter 5. Cyber Threats Analysis
mitted an action cannot deny it), and automated behavioral analysis that alerts security department of unusual patterns. 3. Input Injection (I:1/2.2 S:1/2.1/2.3 T:3 M:1)
There are two major types of database injection attacks: 1) SQL injection that targets traditional database systems, and 2) NoSQL injection that targets other platforms. Injection attacks usually involve inserting (or injecting) unauthorized or malicious statements into the applications' input channels. A successful input injection attack can give an attacker unrestricted access to an entire database. 4. Malware (I:1 S:1/2.1 T:3 M:2)
Cybercriminals, state-sponsored hackers, and spies use advanced attacks that blend multiple tacticssuch as spear phishing2 emails and malwareto penetrate organizations and steal/corrupt/modify business-critical data. Unaware that malware has infected their device, legitimate users become a conduit for the adversaries to access sensitive data in internal networks. 5. Weak Audit Trail (I: S: T:3 M:1)
Full automated logging of all database transactions that involve sensitive data should be a part of any database deployment. Failure to collect detailed audit records of database activity represents a serious organizational risk on many levels (see also paragraph 2. Privilege Abuse). Moreover, having weak database audit mechanisms (or not having them at all) is likely to be at odds with cyber security regulations applicable to government agencies. Easiest and most popular approach is to turn to native audit tools provided by database vendors or rely on ad-hoc and manual solutions, which while better than nothing, posses several serious aws. The records are not detailed enough to support auditing, attack detection, and forensics. Furthermore, native database audit mechanisms are notorious for being resource consuming, which forces many organizations to scale back or eliminate auditing altogether. Finally, most native audit logs of dierent database platforms are not compatible. For example, Oracle Database logs are dierent from MS SQL Server, which, in turn, are dierent from DB2. This imposes a signi cant obstacle to implementing a uniform and scalable audit processes for organizations with heterogeneous database environments. When users access the data-tier application indirectly, via an application-tier application, it can be challenging to understand which database access activity relates to a speci c user. Most audit mechanisms have no awareness who exactly initiated a speci c 2 Phishing
attacks: attacks aiming at shing sensitive information from individuals or businesses, e.g.,
address, full name, banking information, etc. Spear phishing:
a phishing attack that is targeted at a speci c recipient or group thereof to increase
credibility. May address recipient by name, disguise as an email from a friend or a colleague, etc.
5.1 Attack Surfaces of UTMS
47
transaction since all activity is associated with the application's account name. Reporting, visibility, and forensic analysis are hampered because there is no link to the responsible user. Custom applications should be designed with this in mind and provide information necessary for auditing. Finally, users with administrative access to the database, either legitimately or maliciously obtained, can turn o native database auditing to hide fraudulent activity. Audit capabilities and responsibilities should ideally be separate from both database administrators and the database server platform. 6. Storage Media Exposure (I:1.1/2.2 S:1/2.3 T:3 M:1)
Backup storage media is often neglected and is left completely unprotected from attack. As a result, numerous security breaches have involved the theft of database backup disks and tapes. Furthermore, failure to audit and monitor the activities of administrators who have low-level access to sensitive information can put your data at risk. Taking the appropriate measures to protect backup copies of sensitive data and monitor your most highly privileged users is not only a data security best practice, but also mandated by many regulations. 7. Database Security Misconfiguration (I:1 S:1/2.1 T:3 M:1)
It is common to nd vulnerable and un-patched databases, or discover databases that still have default accounts and con guration parameters. However, this is not particular to database systems and is a common issue with any software system. There is a plethora of automated tools, both publicly available and not, that could be used by attackers to nd and exploit vulnerabilities connected to miscon guration. Unfortunately, organizations often struggle to stay on top of maintaining database con gurations, often due to lack of proper personnel training or maintenance processes. Typical issues include high workloads and mounting backlogs for the associated database administrators, complex and time-consuming requirements for testing patches, and the challenge of nding a maintenance window to take down and work on what is often classi ed as a business-critical system. The net result is that it generally takes organizations (at least) months to patch databases, during which time they remain vulnerable. According to the 2014 Independent Oracle User Group (IOUG) Enterprise Data Security Survey, 36% of Oracle users take more than six months to apply a Critical Patch Update, while another 8% have never applied one [62]. Counteracting the issue involves properly designed technology maintenance processes, training personnel on business continuity practices, multi-node software setup con gurations that can withstand node-by-node maintenance. 8. Unmanaged Sensitive Data (I: S:2.3 T:3 M:1)
Organizations typically struggle to maintain an accurate inventory of their databases and the critical data objects contained within them. Forgotten databases may contain sensitive
48
Chapter 5. Cyber Threats Analysis
information, and new databases can emergee.g., in application testing environments without visibility to the security team. Sensitive data in these databases will be exposed to threats if the required controls and permissions are not implemented. Data inventorization processes are mandated or recommended by many general and specialized cyber security frameworks, and should especially be in place in a critical infrastructure system such as UTMS. 9. Denial of Service (I:1 S:1/2.1 T:3 M:2)
Denial of Service (DoS) is a general cyber attack category which results in access to network resources being denied to intended users. This result could be achieved by a multitude of approaches. The most common technique used in database environments is to overload server resources such as memory or CPU either by ooding them by ooding the targeted system with queries, or with a smaller volume of well-crafted queries that consume a disproportionate amount of system resources (e.g., because they lead to recursive look-ups or table operations). The result in either case is the same; the resource-starved servers become unresponsive and, in some instances, even crash. DoS detection and mitigation systems are typically able to de ect common strains of DoS attacks. 10. Limited Security Awareness, Expertise and Education (I: S: T:3 M:1)
In many organizations data and infrastructure grows and transforms faster than the associated security controls. Often this is due to the lack of expertise required to implement, adjust, and evolve the security controls, or due to unenforced policies. According to the Ponemon Institute 2014 Cost of Data Breach Study, in 30% of data breach incidents, the main root cause is classi ed as human factorin other words, a negligent employee or contractor [50]. Human resources management processes that keep the responsible personnel educated on cyber-security and up-to-date with current cyber security landscape are vital for maintaining safety and smooth operation of UTM in Singapore. B. Operating Systems
Operating systems are software systems. All threats that have been identi ed for serverside software components are applicable to operating systems. Since operating systems are much more complex systems that are capable of running other software systems, they are susceptible to the full range of malware threats (viruses). As more complex systems, operating systems have a signi cantly larger amount of input channels, all of which are susceptible to the typical software threats. Threats to operating systems could be classi ed as (I:1 S:1/2.1 T:3). On the whole, operating systems have a large attack surface and require not only a diligent setup, but also installation of security components such as rewalls and antiviruses. This area is extremely well researched and there is a vast amount of techniques and automated tools
5.1 Attack Surfaces of UTMS
49
available for hardening operating systems. C. Firmware
Firmware is software written to a rewriteable chip, such as the BIOS chip, a hard drive controller chip, and so on. Almost every electronic device today has a rewritable rmware chip. Firmware provides control, monitoring and data manipulation of engineered products and systems, and performs direct control of the hardware. Firmwares steadily grow in complexity. From short and simple programs, typical rmware evolved into multi-component multitasking software. Some rmwares are using full- edged operating systems as their basis (e.g., OpenWRT rmware for network routers is based on Linux), and therefore are exposed to all the threats to operating systems. Firmware attacks are occurring on a regular basis, albeit infrequently, since the 1998 CIH computer virus emerged. The experts project a possibility of a higher rate of attacks in future. Many research institutions collaborate with rmware and hardware manufacturers to create more defensible rmware versions, e.g., NIST's (National Institute of Standards and Technology) recent publication of two rmware protection guidance documents: Special Publication 800147 [13] and Special Publication 800155 [53]. The likelihood of real, public, widespread rmware attacks is currently unknown. Infecting rmware is signi cantly harder than infecting regular software due to many reasons. Typical malicious tasksstealing money, passwords, or identitiescan more easily be accomplished using regular software-only malware. One exception: It is easier to brick (make unusable or unbootable) an electronic device with a rmware attack because the attacker just needs to corrupt the rmware code, not modify it. Corruption is pretty easy for a malware programmer. If the rmware gets bricked, recovery could require a chip or motherboard replacement. However, when we talk about SCADA systems such as UTMS, there are two dierences to note. First, simply bricking the hardware is more likely to be a legitimate goal of an attack as it could disrupt the UTM. Second, the attacker is likely to be resourceful enough to perform more complex attacks.
5.1.2
Hardware Components of UTMS Two groups of physical assets are components of UTMS: UTMS networking hardware (network switches, routers, hardware rewalls, DMZs) and UTMS IT hardware (servers, data storages). According to best practices in cyber threat analysis of a cyber-physical system, we consider both cyber and physical components. Two security controls that are important for IT and networking hardware are integrity and availability: Integrity:
(I:2.1 S:2.3 T:2 M:2) A threat of hardware distancing from expected behavior due to issues in rmware Hardware malfunctioning
50
Chapter 5. Cyber Threats Analysis
Figure 5.3: Hardware components of UTMS
or malfunctioning hardware componentseither due to faulty design or to defects acquired while being in use. Tampering with rmware/OS (I:1 S:1/2.1 T:2 M:2) A threat of unauthorized modi cations to the rmware or OS that controls the device to amend the behavior of the device. Tampering with hardware components (I:1 S:1 T:2 M:2) A threat of unauthorized modi cations to the hardware components of the device to amend the behavior of the device. Availability:
(I:2.1 S:2.3 T:2 M:2) A threat of full failure of the device due to issues with the hardware. Firmware failure (I:2.1 S:2.3 T:2 M:2) A threat of full failure of the device due to issues with the rmware. Power outages (I:2.1 S:2.3 T:2 M:2) A threat of the device being temporarily decommissioned due to a power outage.
5.1.3
Hardware failure
Communication Channels We have also identi ed ve communication channels (Fig. 2.2) connected to UTMC. The next paragraphs will discuss threats that are relevant to these channels. We use the notation C:level|I:level|A:level to indicate the threat impact level to con dentiality, integrity and availability. The dierent possible levels are low, high, situational, moderate, or critical. The ISTM classi cation is not directly applicable to communication channels, so for all of the identi ed channels we assume classi cation (I: S: T:1 M:).
5.2 Attack Surfaces of UAVs
(1) ATC
51
$ UTMC
Duplex communication channel used to exchange the air tra c data. The channel is likely to be built on top of regular computer network. UAV tra c data reported by UTMC to ATC: C:nil|I:critical|A:critical Air tra c data reported by ATC to UTMC: C:nil|I:critical|A:critical (2) Weather Station
! UTMC
Simplex channel for transmitting weather information. The channel is likely to be built on top of regular computer network. Weather data reported by Weather Station to UTMC: C:nil|I:high|A:moderate (3) DC
$ UTMC (optional)
A duplex channel that carries all the data ow between the components distributed in Data Center and UTMC. The channel is built on top of the regular computer network. It is not possible to go now into detailed analysis of the data ow going through that channel as it highly depends on the speci c implementation of a UTMS. All data communication between the DC and UTMC: C:moderatel|I:critical|A:critical (4) RPS
$ UTMC
A set of duplex channels between UTMC and remote pilot stations. The channel is built on top of regular computer network.
RPS Id reported by RPS to UTMS: C:low|I:critical|A:low UAV Id reported by RPS to UTMS: C:low|I:critical|A:low Flight plan reported by RPS to UTMS: C:low|I:critical|A:low Operational data given by UTMS to RPS ( ight plan approval information, air tra c information): C:low|I:critical|A:high
(5) UAV
! UTMC (optional)
A set of simplex channels for UAVs (one per UAV) to report its status to the UTMS (e.g., via ADS-B). The communication channel is maintained via a radio link. UAV status (location, elevation, speed, direction, etc.): C:low|I:critical|A:low
5.2
Attack Surfaces of UAVs Potential threats to UAVs can be classi ed into three categories: 1. Attacks that prevent a UAV from behaving as programmed. 2. Attacks that provide false data to the control system or the remote pilot. 3. Attacks that jam one or several data ow channels: communication, control, sensors. Typical UAVs today comprise the following components (Fig. 5.4):
52
Chapter 5. Cyber Threats Analysis
Figure 5.4: Components of the UAV
Main Execution Component A semantic combination of the central processing unit (CPU) and the piloting program it executes. This component is responsible for processing all the data feeds from the sensors and passing controls directly onto Actuators (see below). Magnetometer An instrument for measuring direction. GNSS An instrument for determining current global location. Airspeed & Altimeter Typically, a single instrument that measures both the airspeed and altitude. Wireless Comms Wireless communication with ground stations. Power System Provides power to the entire UAV. Inertial Measurement Unit An instrument for measuring the movement of the UAV. Boot Loader Reset Switch Used to load programs into the Main Execution Component. Actuators Receive commands from Main Execution Component and moves the control surfaces. Manual Flight Control Used to receive commands from RPS and feed them to actuators (Remotely Piloted mode) or to Main Execution Component (Autonomous Navigation or Flight mode). We identify three major feasible attack vectors an adversary may perform towards the UAV:
5.2 Attack Surfaces of UAVs
53
Direct attack: An attacker has direct access to the hard-/software of the UAV and modi es it. Wireless attack: An attacker carries out the attacks through one of the wireless communication channels. Sensor spoo ng: An attacker in uences UAV's sensors to pass malformed or incorrect data.
5.2.1
Direct Attacks (I:1/2.1/2.2 S:1/2.3 T:5 M:2) This type of attacks may happen whenever an adversary has direct access to the UAV or any of its components (I:1 S:1 T:5). An insider (S:1.1) has a better chance of performing a direct attack than an outsider (S:1.2). An attacker is able to then corrupt the data stored on-board, including the main program; install additional components; or modify/substitute existing components. Direct attacks aect the survivability of the UAV, compromise control of the UAV, compromise data reported by the UAV (position, altitude, speed, direction, etc.), and/or compromise the task performed by the UAV. Direct attacks to UAVs are not necessarily a result of malice, it may arise from negligence, human factor, accidents (I:2.2 S:2.3 T:5); e.g., UAV experienced a physical impact during transportation; UAV was not checked for the battery level before ight, etc. Lastly, UAVs under direct attacks could be considered failures of UAV's hardware and/or rmware that happen without external reason and malice (I:2.1 S:2.2 T:5).
5.2.2
Wireless Attacks (I:1 S:1/2.1 T:1 M:2/3) Wireless attacks are realized when an attacker interferes with the UAV-inbound wireless communication channels. The attack might be a targeted attack (S:1) or it is not directly targeted at UAVs (S:2.1), such as general jamming of wireless signals. For a targeted attack, the attacker might try to (1) break the encryption of the communication channel (if present); or (2) impersonate the entity that is authorized to command and control the UAV. When the attacker is unable to perform neither (1) nor (2), he may still try to jam the wireless communication signal. If the attacker is only able to perform (1) but not (2), he might be able to exploit a vulnerability in the authorization mechanism in the UAV (e.g., through a buer over ow attack) and either gain some extent of control or incapacitate the UAV. If the attacker is able to do both (1) and (2), he is likely to gain full control over the UAV. An additional danger inherent to wireless attacks is that the attacker can perform them from an unknown remote location.
54
5.2.3
Chapter 5. Cyber Threats Analysis
Sensor Spoofing (I:1 S:1 T:5 M:2/3) These attacks are directed towards the on-board sensors that detect the environment of the UAV. In the case of an successful attack, the adversary is able to feed false information about the environment to the UAV, which in turn, will aect the decision made by the control program or by the remote pilot. In the sections below we will consider the UAV attack scenarios that appear to be viable. Attacks towards Gain Scheduling
Gain scheduling is a common technique used to control non-linear systems using linear approximationsgains. For example, the propeller RPMs3 required to maintain the altitude of a quadcopter depends on the mass of the quadcopter in a non-linear way: If the quadcopter is twice as heavy, spinning the propellers twice as fast generally would not maintain a stable altitude, it would either be too much or too little. However, for speci c limited ranges of weight, speci c linear gains is good enough. Knowing its own weight, a UAV can switch to an appropriate gain and control the altitude. Another example is that a UAV might have dierent control gains for taking o, landing, and cruising. An attack towards gain scheduling mechanism is an attack that would cause the UAV to switch to an inappropriate gain, which could lead to instability or crash of the vehicle. The means of realization include sensor spoo ng, overriding gains via hacking or tampering, overriding self-awareness information (e.g., tampering with UAV's information about its speci c model, its weight, its aerodynamic properties), or causing a denial of service (DoS) attack on the gain scheduling subsystem of the UAV. Attacks towards Actuators/Sensors
Let us consider the following communication ows between the components of the UAV: Main Execution Component!Actuator: This is a control communication channel; MEC commands the actuator. Actuator!MEC: Actuator reports its status to MEC; e.g., a propeller actuator might report its RPMs. Sensor!MEC: Sensor feeds its sensor data to MEC for it to make decisions (or to pass to the RP for him to make decisions). Possible attacks here include denial of service (commands/data does not reach the actuator) and tampering (commands/data is overridden). The means of realization include overriding actuator state estimates, actuator mappings, or sensor readings; false data injection; denial of service attack. Attacks towards GNSS
UAVs heavily rely on GNSS location data to locate themselves, the ground stations, and their targets. Additionally, UAVs need to report their location so that UTMC is able to 3 Rotations
per minute
5.2 Attack Surfaces of UAVs
55
Figure 5.5: An example of discretization rate attack
schedule and manage tra c. Aecting GNSS data feed could have serious consequences for the speci c UAV and for the UAV tra c in general. Like any sensor device, GNSS readings could be spoofed or denied. We distinguish this into separate attack types as there are counter-measures that target this speci c attack type [64]. Fuzzing Attacks
Fuzzing attacks are a family of commonly used unsupervised attack methods that rely on feeding the target component of a system complete or partially random inputs with an expectation that the component is not 100% fool-proof to unexpected inputs and will eventually crash, switch to wrong mode of operation, or in the best case scenario for an attacker will give him control over itself. Fuzzing attacks may originate within the UAV in the inter-component data ows (e.g., as a result of a direct attack), or from outside if the attacker is able to aect the wireless communication of the UAV with external entities. Discretization Rate Attacks
Digital systems are incapable of processing continuous analog signals. Hence, analog signal is digitized by sampling it with a certain frequency called the discretization rate (or digital update rate ). The sampled points are then used to determine the approximating function, which is then used in further computations. Aecting the rate might lead to wrong approximation function, which may lead to crash or instability of the UAV. Figure 5.5 illustrates how a maliciously lowered digital update rate may lead to confusion. Green dots represent the sampled points, and red and blue lines are two very dierent approximations that both match the sampled dots. Arti cially increased sampling rate may also lead to system instability or uncontrollability as the electronics may not be able to nd an approximation.
56
5.3
Chapter 5. Cyber Threats Analysis
Attack Surfaces of ADS-B (ADS-B) is a surveillance technology in which an aircraft determines its position via satellite navigation and periodically broadcasts it, enabling it to be tracked. The information can be received by air tra c control ground stations as a replacement for secondary radar. It can also be received by other aircraft to provide situational awareness and allow self separation. ADS-B is automatic in that it requires no pilot or external input. It is dependent in that it depends on data from the aircraft's navigation system. Automatic Dependent Surveillance Broadcast
Current implementations of ADS-B systems for aircarft typically have two separate modulesADS-B In and ADS-B Out. ADS-B Out module is used to broadcast aircraft's position two external parties. ADS-B In module is used to receive the broadcasts from other aircraft. Generally, there are concerns that ADS-B signals could be spoofed or corrupted by malice [41, 42, 47, 48]. UAVs will not necessarily have ADS-B In modules installed, but are very likely to have ADS-B Out modules (unless a completely dierent4 technology is chosen/created for aircraft position update feed). ADS-B data tra c is broadcast at 1,090MHz and 978MHz frequencies as a 1Hz data pulse initiated by the aircraft (i.e., unlike SSR, ADS-B is not triggered by interrogation from ground station). Depending on the mode of operation, ADS-B messages are in the range of 50150 bits long; are modulated using Position Pulse Modulation (PPM) or Dierential Phase Shift Keying (DPSK); and with throughput ranging from 1 to 4 Mbps. The speci cation for ADS-B protocol requires messages to carry parity bits to verify the integrity of the message. However, the protocol does not require any authentication or authorization from the aircraft, and there is no encryption of the communication. The way ADS-B works render the system vulnerable to a range of attacks. First, due to the unencrypted nature of the protocol, ADS-B is susceptible to eavesdropping on the communication. This gives a potential adversary live updates on the UAV tra c. Second, this makes it possible for adversaries to inject ghost ights into the system, which will aect both the UTMS and the UAVs with ADS-B In module. Several ights injected in the system like that may lead to the UTMS restructuring the whole UAV tra c due to perceived congestion in certain areas. Ghost aircrafts may also present themselves as unstable and dangerous, which could lead to UTMS geo-fencing the area o to protect other aircrafts. Ghost aircrafts could also trigger Detect-andAvoid procedures in ADS-B In enabled aircraft as an attempt to avoid the ghost. Some researchers pointed out that messing with ADS-B may be used by smugglers. Lastly, the ADS-B signal may be jammed using easily accessible o-the-shelf hardware. It is important to note that in an urban airspace, ADS-B is unlikely to be the only mode of tra c surveillance employed by UTMS. Cross-matching surveillance data from various sources may help eliminate ghost aircrafts. At the same time, even for situations 4 E.g.,
ADS-A (Addressed) or ADS-C (Contract) could be considered as potential candidates.
5.4 Attack Surfaces of RPS–UAV Communication Channel (I:— S:— T:1 M:—)
57
Figure 5.6: ADS-B in conjunction with classic tra c surveillance methods
when ADS-B is the only source of surveillance information, there are techniques that can help eliminate malicious anomalies (e.g., multi-lateration).
5.4
Attack Surfaces of RPS–UAV Communication Channel (I:— S:— T:1 M:—) We have identi ed three modes of UAV autonomous operations and two modes of remotely piloted operations (see Section 2.1). In the following explorations, we determine the threat impact level with respect to con dentiality, integrity, and availability. We use the notation C:level|I:level|A:level where level may be low, high, situational, moderate, or critical.
Figure 5.7: RPARPS communication architecture (Scenario 1)
Figure 5.7 demonstrates the communication architecture of a remotely piloted aircrafts operating in Scenario 1 (see Fig. 2.2). (1) Control sequence: C:low|I:critical|A:critical
58
Chapter 5. Cyber Threats Analysis
(2) Sensor readings: C:low|I:critical|A:critical (3) Status: C:low|I:high|A:low
Figure 5.8: RPARPS communication architecture (Scenario 2)
Figure 5.8 shows the communication architecture of a remotely piloted aircraft operating in Scenario 2 (Fig. 2.3). (1) Control sequence: C:low|I:critical|A:critical (2) Sensor readings: C:low|I:critical|A:critical
Figure 5.9: AARPS communication architecture (Autonomous Navigation)
Figure 5.9 shows the communication architecture of an autonomous aircraft operating in autonomous navigation mode. Data asset with an asterisk is optional. (1) (2) (3) (4)
Waypoint: C:low|I:critical|A:critical Status: C:low|I:critical|A:critical Sensor readings (optional): C:low|I:critical|A:critical Sensor readings: C:nil|I:critical|A:critical
Figure 5.10: AARPSUTMS communication architecture (Autonomous Flight)
Figure 5.10 shows the communication architecture of an autonomous aircraft operating in autonomous ight mode.
5.4 Attack Surfaces of RPS–UAV Communication Channel (I:— S:— T:1 M:—)
(1) (2) (3) (4) (5)
59
Destination: C:low|I:critical|A:low Status: C:low|I:moderate|A:low Status: C:low|I:critical|A:moderate Flight data: C:situational|I:critical|A:high Sensor readings: C:nil|I:critical|A:critical
Figure 5.11: AARPSUTMSAAs communication architecture (Autonomous Operation)
Finally, Figure 5.11 shows the communication architecture of an autonomous aircraft operating in autonomous operation mode. (1) (2) (3) (4) (5) (6)
Destination: C:low|I:critical|A:low Status: C:low|I:moderate|A:low Status: C:low|I:critical|A:moderate Flight data: C:situational|I:critical|A:high Sensor readings: C:nil|I:critical|A:critical Program-speci c data: C:situational|I:situational|A:situational
6. Implications for UTM Ecosystem
In this research we have looked in details into various sides of cyber security of the unmanned aircraft tra c management as a whole, as well as its components. We identi ed essential parts the UTM ecosystem comprises, and drafted possible communication topologies between the parts. We considered the components of the ecosystem on the hardware and software planes, and done a comprehensive research on potential cyber threats to these planes. We took into account the human factor, and considered both remote and hands-on attacks on the components of the system. We analyzed the communication channels between the components, identi ed types of information that travels through the channels, and what are the threats to the channels and information in them. However, before this point we mainly focused on cyber consequences of realized cyber threats. E.g., we stated that a jammed radio signal leads to violation of property of availability for speci c assets but we have not discussed what would that mean for the system. This chapter is intended to show some of the consequences of cyber threats in terms of safety and operational integrity of unmanned tra c management in Singapore, safety of people of Singapore, and national security of the country. With the current study producing a comprehensive look at the cyber threats landscape, future research on cyber security of UTM in Singapore should focus on cyber threat mitigation. E cient and systematic mitigation of cyber threats is only possible if it is taken into consideration from the very start of the project. Otherwise, as it is often seen in practice, cyber incidents response tends to be erratic and inconsistent, incidents go unnoticed, normal system behavior gets erroneously accounted as a security incident, etc.
6.1
Security by Design An important notion of systems engineering is a design approach called secure by design, meaning that the system has been designed from the ground up to be secure. As an im-
6.2 Implications of Cyber Threats to UTMS Design
61
portant part of the design, the system is developed to fully operate under the assumption of constant attack. Certain systems employ an evolution of this idea, often called chaos monkey1 , which is constantly powering o components of the live production system or destroys communication links between them. Most notable user and an inventor of the approach is the media giant Net ix. An emphasis on building security into products counters the all-too-common tendency for security to be an afterthought in development. Addressing existing vulnerabilities and patching security holes as they are found can be a hit-and-miss process and will never be as eective as designing systems to be as secure as possible from the start. The security by design model contrasts with less rigorous approaches including security through obscurity, security through minority and security through obsolescence, which have proven themselves to be ineective. It is important to note that cyber security does not fully comprise technological solutions, and is actually a three-fold notion based on technology, people, and processes [6]. The triad is often called a golden triangle of cyber security [3]. Properly designed and setup technology takes care of all the heavy lifting in ensuring cyber security: encryption, resiliency, fool-proo ng, ltering, reducing human factor, etc. People are considered one of the most in uential factors in cyber security. They could knowingly or unknowingly compromise systems, could willfully or by negligence violate protocols, and might not be aware of consequences of their actions from the point of view of cyber security. Therefore, approaches to human resources management and personnel education need to be designed with cyber security in mind. Lastly, processes are required to ensure sustainable cyber security. Internal processes of the organization need to be designed to include technology maintenance, security incident response actions, security incident information management, self-adjustments in view of changes in cyber threat landscape, etc. It is also important to ensure that people and processes are connected, every process has a manager accountable, who has the authority to enforce the process.
6.2
Implications of Cyber Threats to UTMS Design The amount of cyber threats to UTMS is very high, as it is a large and complex system with a large attack surface, and realization of cyber threats to UTMS leads to, mainly, full or partial disruption of unmanned air tra c. It could aect only certain areas, or certain groups of UAVs, or it could aect the UTM islandwide. This would typically be a result of the more blunt (and therefore more probable) attacks (as well as hardware/software failures), which, if successful, will incapacitate the UTMS and lead to full or partial loss of control over the tra c. 1 Allegedly,
named for the way it wreaks havoc like a wild and armed monkey set loose in a data center.
62
Chapter 6. Implications for UTM Ecosystem
More sophisticated attacks could try and aect the tra c management in a speci c way. This could include diverting tra c to/from speci c areas, assigning UAVs ight plans that increase probability of collisions with other aircraft or static obstacles, issuing an approved ight plan for smuggler UAVs, lifting geo-fences, masking presence of unauthorized UAVs, and many others. In order to secure itself from these, the UTMS has to be designed to include infrastructure redundancy, data integrity technologies in place, tightened hardware and software security policies, personnel education, security incident event management systems (SIEM), and detailed security incident response guidelines. Design of the UTM system involves decisions on the architecture of the system, internal and external communication protocols, software, hardware, as well as requires development of custom hardware, software, and protocols. As it was covered in this report, all these decisions have cyber security implications. In particular, development of custom software and hardware requires implementation of proper SDLs2 . Development of custom protocols requires meticulous cyber security analysis on all stages. Some of the points in UTMS design that require careful consideration in connection with cyber security issues include: How UAS authentication is performed? UTMS needs to be able to reliably authenticate UASs (a combination of RP, RPS and UAV) that are in the airspace under control. Can adversaries impersonate legitimate UASs? Can they prevent authentication of legitimate UASs? Can UTMS detect rogue UAVs or UASs? UTMS needs to be able to detect UASs that are not authenticated, registered with UTMS, or are displaying other kinds of rogue behavior. UTMS therefore needs to have a secondary source of air tra c surveillance, which would enable it to verify tra c information collected directly from UAVs (e.g. through ADS-B) and RPSs. Such secondary sources could be small object radars, low altitude radars, video surveillance, etc. What models are used to predict air tra c? Are the models susceptible to adversarial manipulation? Can an adversary nd and exploit edge cases of the models? Is UTMS software and hardware resilient to cyber threats? Do the critical systems have redundancy? Are security incidents and other activity properly logged? Is the system able to detect intrusion? Is the critical data backed up and are the backups secured? Is data secured? UAV ight trajectories could be highly con dential information of businesses that operate the UAVs [40]. Is critical data stored redundantly? Do systems provide data integrity veri ability? Is data veri ably coming from authorized sources? Is the issue of data availability addressed? Are there clear procedures in response to security incidents? Are the procedures dierent for dierent types of security incidents (e.g., physical tampering, network 2 Secure
Development Lifecycles
6.3 Implications of Cyber Threats to C2/C3 Design
63
attack, virus, etc.)? Does the system need a kill switch in the event of a massive attack, and if yes, how should be implemented?
6.3
Implications of Cyber Threats to C2/C3 Design Modern UAVs require the guidance from a remote pilot at least to a certain extent. Certain UAVs require more than one RPs to operate them [15]. However, the trend is to invert the ratio towards one-RP-many-UAVs [26]. The guidance is delivered from the pilot to the UAV through a C2 (command & control) or C3 (command, control & communication) support infrastructure. C2/C3 is one of the most seminal components of the UTM eco-system. Issues with C2/C3 could lead to full disruption of the UTM in Singapore. Apart from full or partial disruption of UTM, one of the major consequences of compromised C2/C3 infrastructure is unknown or compromised UAVs in the airspace of the city.
6.3.1
Scenario 1. Unknown UAVs Unknown UAVs may not necessarily have a malicious intent (e.g., an amateur ying a UAV to take aerial photos) but regardless of that they could cause serious damage. Since an unknown UAV does not cooperate with the UTMS and generally could not be expected to cooperate with other UAVs through systems like ADS-B, it could disrupt local UAV tra c and require the UTMS to take actions to divert the cooperative tra c away from the area with unknown UAVs in the air. Either through malicious intent or not, an unknown UAV could collide with other UAVs in the air and cause them to fall on the ground, which may lead to people injuries and casualties as well as property damage. In addition to that, unknown UAVs could have a wide range of malicious intent including smuggling and terrorist attacks. Lastly, unknown UAVs could be ghost UAVs, which are only present on the UTMS navigation equipment but do not exist in reality. This could be a result of interfering with ADS-B, radars, air tra c surveillance systems; tampering with UTMS hardware or software; result of a software or hardware error; and many other. The UTM regulator must be ready for the event of unknown UAVs. Ecosystem design must include policies on managing tra c in aected areas, steps to isolate (e.g., through dynamic geo-fencing of the area) and neutralize the unknown UAV, ways to con rm existence of the UAV in the sky (e.g., through secondary tra c surveillance systems) to eliminate false alarms from ghost UAVs. The design of mitigation steps might even employ cyber weapons to neutralize the unknown UAVs. As an example, in several countries the protected state objects are equipped with GPS spoofers that broadcast coordinates of an airport. Most o-the-shelf UAVs have a database of the world airports in their rmware, and would automatically land if they nd themselves in a vicinity of an airport.
64
6.3.2
Chapter 6. Implications for UTM Ecosystem
Scenario 2. Taken over UAVs Adversaries could take over a cooperative UAV and transform it into the state of unknown UAV with all or most of the implications discussed above. This mostly depends on cyber resiliency of the C2/C3 link technology in place. Both the carrier media of the wireless C2/C3 link between the RPSs and UAVs, and the communication protocol could make it easier or harder for adversaries to gain control over the UAV. The regulator should consider carefully which communication technologies to allow, and authentication/authorization capabilities of the communication protocols. It is also worth keeping in mind that in certain scenarios the regulator might have a need to take over the control of a UAV if that would be deemed necessary, therefore, the C2/C3 communication infrastructure should have the capability for transfer of control from pilot to UTMS.
6.3.3
Scenario 3. Influenced UAVs Lastly, the UAVs that do not behave completely as they are supposed to. This might be a result of defects in or tampering with the UAV's hardware or software, interference with the C2/C3 link, external attacks on UAVs sensors, etc. Some examples include partial loss of control over the UAV, or inaccurate or completely wrong status reports from the UAV (e.g., position, altitude, speed, sensor readings). This could lead to erratic behavior of the UAV in the air, failure of detect-and-avoid (DaA) subsystems and consequential collision with other participants of the air tra c or with static objects, entering geo-fenced areas, falling on the ground. The regulator might consider requiring regular servicing of the UAVs (similar to civil cars that are subject to regular vehicle inspection), automatic UAV software integrity checks, DaA design mindful of cyber threats, backup C2/C3 channels, tamper-resistant C2/C3 protocols, and many other approaches to alleviate the threat. Creating a stable and cyber-resilient C2/C3 infrastructure requires, among others, careful consideration of the following topics of importance: How is the C2/C3 signal communicated between RPS and UAV? Radio frequency and an overall radio link infrastructure plays a large role in ensuring that the link is stable in the changing environment (e.g., weather), has enough throughput to support large eets of UAVs in the sky, has acceptable performance metrics such as packet loss rate and latency, is resilient to noise/jamming/data tra c peaks, etc. How is C2/C3 data protected? Protocols that are used for C2/C3 should provide cyber security guarantees from ground up, including veri able integrity, authentication/authorization primitives, optional encryption, optional delivery guarantees, etc. What is the procedure for full or partial loss of C2/C3? There should be clear proce-
6.4 Implications of Cyber Threats to Detect-and-Avoid Design
65
dures and guidelines on actions that need to be taken in the event of full or partial C2/C3 loss. Guidelines must include actions for pilots as well as actions for tra c management o cers. Design might as well include a backup C2/C3 infrastructure that uses dierent technology stack and provides if not full replacement, then at least ways to do graceful and safe degradation of UTM in Singapore. What is the control paradigm? Some of the major control paradigms include [26]: Direct control. RP sends commands to the UAV, and the UAV is reporting its status to the RP. Can an adversary impersonate the RP and issue C2 messages to the UAV? Can an adversary impersonate the UAV and send forged status updates to the RP? Management by consent. UAV performs planning and requests approvals for its decisions from the RP. Can an adversary approve/reject the decision in the RP's stead? Can an adversary in uence UAV's decision making? Management by exception. UAV performs planning and execution of its plan, the RP is able to intervene and amend the plan. Can an adversary in uence UAV's decision making? Can an adversary impersonate the RP and amend the UAV's ight plan?
6.4
Implications of Cyber Threats to Detect-and-Avoid Design Ability of a UAV to avoid static or dynamic obstacles is not only a valuable feature that increases the safety of air tra c, but also a requirement by global and local regulations. E.g., Title 14 Code of Federal Regulations, section 91.113 (14CFR91.113, 2004) requires that the operator of an aircraft sees and avoids other aircraft. This could not be directly applied to UAVs as the pilot is not onboard and might not have a clear visual on the UAV's immediate surrounding. Therefore, UAVs must be equipped with a system that resolves the issue [28]. The system of that kind is called a Detect-and-Avoid (DaA) system. To be more speci c, UAVs must be able to perform self-separation (SS), i.e., stay well clear of other objects either through choosing the ight path or through performing a collision avoidance (CA) maneuver [58]. Some of the important metrics for DaA include statistical probability of a loss of well clear (LoWC) situation, frequency of initiating a CA maneuver, amount of DaA tra c alerts issued by UTMS, aggregate time required to recover from the LoWC. There is a multitude of factors that could aect these metrics. The metrics highly depend on whether the UTMS or the pilot are involved in the DaA or the UAV is taking care of that in a fully autonomous way; what kind of DaA equipment is in use by the UAV; what kind of equipment is in use by the pilot; which technique is used to detect LoWC or potential LoWC; reaction time for between the DaA alert and the CA maneuver [24]; and many others. Implementations of Detect-and-Avoid techniques could be classi ed into cooperative and uncooperative. Cooperative techniques are the ones that work in cooperation with other UAVs. ADS-B In is a typical example of a cooperative DaA technique, as it requires
66
Chapter 6. Implications for UTM Ecosystem
UAVs to share their location information with each other. Uncooperative techniques are the ones that do not rely on external parties and are in full done by the UAV itself. They usually rely on sensors and are divided into active, i.e., the ones that issue a sonar-like signal and then read the response pro le (radar, laser, IR); and passive, i.e., the one that receive external re ected signal (such as a video sensor). As discussed in previous chapters, ADS-B is prone to spoo ng attacks, and therefore a DaA system that only relies on ADS-B is vulnerable. Sensors of the UAV could be physically tampered with, could be remotely blinded, could potentially be deceived. One of the ways to improve resiliency of the DaA is to use at least two dierent methods at once. DaA resiliency may also be aided by feeding the UAVs the general air tra c information from the UTMS: established ight routes and ight plans, information on static objects (e.g., buildings), etc. DaA design issues that are coupled with the cyber security issue include: Who is involved in the DaA procedure: is it just the UAV itself, is it UAV and the pilot, or is it UAV, pilot, and UTMS? Including the pilot in the DaA could be necessary in certain cases as not all UAVs might be equipped with sophisticated DaA systems. Involving UTMS in the DaA is likely to reduce the overall amount of LoWC situations and the eect of CA maneuvers on the tra c as a whole; at the same time it is likely to increase the reaction time. From the cyber security point of view, the more agents there are and the more distributed they are, the more careful and resilient design is required to provide quality of service enough to achieve the prede ned airspace safety threshold (AST). What is the required DaA equipment for a UAV to operate in the airspace of Singapore? Cooperative DaA equipment is yielding better performance but is not always applicable as it requires that all aircraft have it. It also is not applicable to avoiding static obstacles or non-UAV aerial objects. If DaA involves the pilot, what are the requirements for DaA equipment in the RPS? Research shows that choice of RPS DaA equipment (e.g., DaA displays) plays a major role in achieving good DaA metrics [24, 58]. Are UAVs required to have DaA equipment redundancy? I.e., are they required to have at least two sets of DaA equipment that works through dierent sets of sensors? That would help mitigate the risk of intentful or accidental blinding of the UAV's DaA system but would increase the entry threshold into the Singapore airspace. Which models are used to determine whether LoWC has or will happen? Dierent models have their pros and cons. Some models may not be adjust to certain edge cases; some may be too sensitive and initiate CA maneuvering when it is not required; some may be intrinsically vulnerable and be spoofed or fooled by an adversary [43]. If pilot and/or UTMS are involved in the DaA, what is the communication topology? What is the communication protocol? Reliability, resiliency, speed, and integrity of communication is critical to successful DaA procedures.
6.5 Implications of Cyber Threats to Geo-Fencing Design
6.5
67
Implications of Cyber Threats to Geo-Fencing Design A geo-fence is a closed virtual 3-dimesnional shape that separates the airspace into the inside and the outside. In air tra c management, geo-fences are used to restrict ights in certain areaseither to keep the aircraft within certain area, or to keep them outside certain area. Respectively, geo-fences are called keep-in and keep-out. Geo-fences do not necessarily include ground objects and could be located at higher altitudes. Geo-fences could be static and dynamic. Static geo-fencesthe ones that either never or very rarely changecould be used to fence o the UAVs from ights around government/military objects, etc. Dynamic geo-fences could be the ones that turn on and o on schedule or the ones that are dynamically created by UTM o cers as reaction to certain events. Geo-fencing cyber-attack vectors include: Denial of UAVs'/pilots' access to geo-fencing information This could be achieved through Denial of Service attacks on communication channels or on geo-fencing information systems, as well as other attack methods. Unauthorized adding/removing/modifying of geo-fences in the UTMS This could be done through exploitation of UTMS vulnerabilities that would allow an attacker to elevate his privileges or impersonate another agent of the system, through direct access to geo-fencing information system, through malicious or negligent employees and ex-employees, and other methods. Aecting UAVs' perception of geo-fences or their position in relation to geo-fences
This could be achieved through spoo ng GPS signal in the area, impersonating the UTMS to deploy fake updates on geo-fencing to UAVs/pilots, through use of unauthorized geo-fencing beacons (if this geo-fencing technology is in place). Design issues of a resilient geo-fencing technology includes: How geo-fencing information is being delivered to RPs and UAVs? Communication protocols should employ proper authorization/authentication in the UTMS RPS/UTMSUAV communication to provide integrity of the information during transmission and ensure that geo-fencing information originates from the UTMS and not from an unauthorized source. Is geo-fencing information available when needed? If the communication channel is down or the UTMS is experiencing a DoS situation, RPs/UAVs might not be able to receive the geo-fencing information. UTMS should be DoS attack resilient, communication channels should be capable of high rate data transmission, and possibly have redundancy. Static and scheduled dynamic geo-fence information should probably be distributed to pilots before-hand, and not immediately before ight. How are geo-fences described? Generally, a geo-fence is a complex 3-dimesnional shape that must possess certain properties: being a closed shape, not to have selfintersections, etc. If the UTMS or the UAV encounters information about a geo-fence
68
Chapter 6. Implications for UTM Ecosystem
Figure 6.1: Comprehensive cyber security approach
that violates some of these properties, they might enter a state of failure. Data structure that holds geo-fence information should be veri able for correctness and completeness. Are geo-fences respected by UAV rst or by RP rst? Should the pilot have the ability to trespass a geo-fence in the event of a need, or should the UAV be enforcing geo-fences by overriding RP's input [4, 60]?
6.6
Concluding Remarks The unmanned tra c management, a part of smart nation's critical infrastructure, is going to be performed through a complex cyber-physical system with a large cyber attack surface. Cyber security of such system is vital for a smooth ow of the air tra c, for safety of Singaporeans, and for Singapore's national security; and as this report has identi ed, there is a diverse multitude of cyber threats to the UTM ecosystem. To ensure that these criteria are met, cyber security has to be an integral part of the design of the system on all stages, no matter which speci c technologies will be used in the system and which communication topology will be chosen. Most cyber security frameworks suggest a multi-stage iterative approach to execute a comprehensive security protocol. Many of them are either directly based on or are very similar to the general NIST cyber security framework [49]. In a high-level way the approach is well illustrated by Fig. 6.1. There are 4 stages distinguished in the approach: 1. Identify. Identi cation of the assets to protect, what do we want to protect them from, the environment, the entities that comprise the whole system, the existing
6.6 Concluding Remarks
69
risks, and the acceptable risks. 2. Protect. Information collected during Stage 1 is used to design/amend the infrastructure of the UTM ecosystem, employ various techniques and products, train the employees, adjust business processes to incorporate cyber security, develop security incident response protocolsall with the ultimate goal of bringing the risks to the identi ed acceptable levels or lower. 3. Detect. Data is being collected from the security systems and from the employees in order to detect an attempted or a realized security incident. 4. Respond & Recover. In the case of a security incident the system and the employees execute the protocols of security event mitigation, damage control, and business continuity, which were developed in Stage 2, and restore systems. This study has fully covered part 1 of the comprehensive cyber security approach, which was to identify a) assets that comprise the UTM ecosystem; b) relations between the assets in the ecosystem; c) cyber threats to the assets and to the links between them. To ensure cyber security of the UTM ecosystem that is being designed, it is important that the next three stages are given similar high levels of attention from the earliest stages to facilitate e cient embedding of security into the design of the UTM ecosystem. Based on the ndings presented in this report, a preliminary overview of core capabilities of the UTM system has identi ed 6 cyber security related design issues for the UTMS itself, 4 design issues for the C2/C3 infrastructure, 6 for the Detect-and-Avoid capability, and 4 issues in designing the geo-fencing subsystem. In order to ensure safety of the unmanned air tra c in Singapore, the next steps in the design of UTM ecosystem should 1) include work on these identi ed design issues to bring cyber robustness to the system design; and 2) perform deeper analysis of how the UTM capabilities are designed and implemented in order to identify more cyber security related design issues.
7. Recommendations for Cyber Resilience
Unlike traditional safety objective of air tra c management which aims to assure safe separation between aircraft on the airport surface and in the airspace, the safety objective of UTM includes the cyber aspect. As an IT-based system, UTMS is exposed to cyber threats that may disrupt the information resources necessary for UTMS to perform tra c management. However, UTMS is a component within a larger eco-system comprising UAVs, RPs, and RPSes, all of which are exposed to physical threats that will deliver the same disruptions to information resources necessary for UTMS to perform tra c management. When considering the cyber resilience of UTMS, we should adopt a holistic view to include UTMS and the eco-system it is situated within in the scope of focus. We should be looking at cyberphysical resilience instead. In this chapter, we propose an actionable checklist for UTMS and UAS eco-system. The checklist is a listing of guidelines whose adherence will be necessary for cyber safety of UTMS. We also include a comprehensive list of recommended experiments that can be performed on any UTMS prototype to determine its tenacity to cyberphysical resilience.
7.1
Recommendations 1. Recommendations for Software System Health Monitoring
1.1
The system should be equipped with automated monitoring software com[ ] ponents/systems that measure the vital signs of the system and alert when the metrics exceed healthy boundaries.
7.1 Recommendations
71
Real-Time Threat Level
1.2
The system should be equipped with a real-time threat assessment sys[ ] tem and report cumulative status of UTMS subsystems and cyber security infrastructure. System Testing
1.3
The system should undergo thorough unit-testing of components that com- [ ] prise the UTMS and comprehensive integration testing of the entire system. System Redundancy
1.4
Core subsystems should have hot backups. All subsystems should have at [ ] least cold backups. This includes hardware, software components, communication channels. Scalability
1.5
System should automatically provision additional resources when system is experiencing high load.
[ ]
Users and Roles
1.6
Every user in the system must have a unique account that comes with privileges matching the role of the user. Applications and OSes should use one [ ] centralized user management solution (such as Active Directory). Consider multi-factor authorization for all or at least more privileged accounts. Antivirus
1.7
Servers and workstations must be equipped with antivirus software that is con gured to report to a central authority.
[ ]
Con guration Defaults
1.8
All software, operating systems, and rmware must be con gured with security in mind. All default accounts must be removed or changed from default passwords.
[ ]
Unique ID
1.9
All entities represented in the system must be identi able with a unique [ ] ID. This includes remote pilots, remote pilot stations, UAVs, UTMC sta, external people and companies that have access. Non-Repudiation.
1.10
All actions performed by any entity that are re ected in the system state must be attributable to the entity who executed it.
[ ]
Data Backups
1.11
All data relevant to UTM operation must be backed up on a regular basis. [ ] Backup media must be protected. Ghost Detection
1.12
UTMS must be able to detect ghost UAVs and UAVs that are reporting false position/altitude/speed/direction.
[ ]
72
Chapter 7. Recommendations for Cyber Resilience
2. Recommendations for Network & Hardware Demilitarized Zone (DMZ)
2.1
All applications that are intended to be accessed from outside the UTMS (e.g., by remote pilots and by UAVs) should be located in separate sub- [ ] networks. Only these subnetworks (DMZs) shall be exposed to the outer world. Network Segmentation
2.2
The network should be split into smaller subnetworks. All connections between subnetworks, including connections between internal subnetworks [ ] and DMZs, and connections between DMZs should be protected by rewalls. IP Address Management (IPAM)
2.3
All servers should have static IP addresses. IP addresses should be managed by an IPAM tool. Firewall rules should re ect that.
[ ]
Network Tra c Inspection
2.4
2.5 2.6
All internal and external network tra c should go through rewalls. Firewall rules must be built on a whitelist basis (i.e., everything that is not ex[ ] plicitly allowed is denied). Network tra c should undergo deep inspection to detect malware, malicious network activities patterns, unusual network activity. System Integrity Protection
Servers must be equipped with system integrity protection solutions. Denial of Service Protection
Network must be protected by a DDoS protection solution.
[ ] [ ]
Remote Access
2.7
2.8
Remote access to servers and other hardware should be disabled for external origins. If remote access is enabled for some hardware, one should use the same remote access technology throughout (e.g., SSH); make sure it is properly con gured. Wireless Network
None of the subsystems of UTMS should be connected to wireless networks.
[ ]
[ ]
Power Backup
2.9
There must be an emergency power supply that can maintain the system operational for at least 24 hours.
[ ]
3. Recommendations for Flight Tra c Surveillance
3.1
Tracking UAVs
Every UAV must be observable throughout its ight route.
[ ]
7.1 Recommendations
73
Secondary Tra c Surveillance System
3.2
UTMS should be equipped with a secondary tra c surveillance system, which is used to cross-check the information fed by the primary tra c [ ] surveillance system. It could be, e.g., an optical tra c surveillance, or a small objects radar, or another technology.
4. Recommendations for Communications Data Encryption
4.1
All communications within the UTMS and with external parties should be encrypted. Hardware security modules (HSM) should be used.
[ ]
Digital Signatures
4.2
All communication messages both within the UTMS and with external parties should be digitally signed.
[ ]
Fallback Communication Channels
4.3
For every communication channel between UTMS and an external party (RPS, UAV, ATC, etc.), there should be a backup channel that uses a dierent communication technology. E.g., radio connection to RPS should be backed by a 3G/4G connection channel or LoRA channel.
[ ]
Connections Segregation
4.4
Connections between UTMS and dierent groups of external parties should be managed by separate physical endpoints. E.g., a connection between UTMS and RPSs is managed by server A; a connection between UTMS and UAVs is managed by server B.
[ ]
5. Recommendations for UAVs Suitable Cryptographic Module
5.1
UAVs should be equipped with hardware or software modules that provide lightweight, low-power cryptography in order to be able to communicate to UTMS and RPS in encrypted form.
[ ]
GNSS Spoo ng Detection/Mitigation
5.2
UAVs are to be equipped with software or hardware modules that are able to detect GNSS signal spoo ng, or (better) are able to counter the spoo ng.
[ ]
Fail-Safe Auto-Landing
5.3
In the event of communication failure, UAVs should be able to au- [ ] tonomously and safely land at the nearest landing pad. Secondary Communication Technology
5.4
UAVs must be equipped with a secondary communication channel to be used as a backup connection in the event that the primary C2 link is lost. [ ] The secondary communication channel must use a dierent communication technology.
74
Chapter 7. Recommendations for Cyber Resilience
Mandatory UAV Certi cation
5.5
UAVs must undergo mandatory certi cation and registration before they are allowed in urban airspace.
[ ]
6. Recommendations for Remote Pilots and RPSs
6.1
Pilot Certi cation
Pilots must undergo mandatory registration and certi cation.
[ ]
RPS Certi cation
6.2
6.3
Remote pilot stations must undergo mandatory registration and certi ca[ ] tion. RPSes must be protected from unauthorized entry (reinforced walls, code lock, etc.). Minimum Pilot Strength
There should be at least two pilots on duty at the RPS.
[ ]
Secondary Communication Channels
6.4
RPS must be equipped with secondary communication equipment for [ ] backup in the event of primary communication channel failure. This includes communication to UTMS and communication to UAVs.
7. Recommendations for Procedures and Processes Visualization
7.1
There must be up-to-date diagrams of networks and applications compris- [ ] ing the UTMS. Updates
7.2
There must be a procedure for regular software update (applying security xes, updating antivirus de nitions, etc.).
[ ]
Review of Logs
7.3
There must be a procedure in place for regular review of security logs, [ ] antivirus and rewall exception and alike. The procedure must include actions to be taken in the event of a suspected security incident. Security Policies Revision
7.4
Cyber security policies must be present. This includes Internet access policy, email and communication policy, network security policy, encryption policy, BYOD policy. Employees of UTMC should not be allowed to use their own devices (laptops, phones, etc.) at work; no phototaking should be [ ] allowed within the premises of UTMC; nothing must be plugged into the UTMC workstations (USB sticks, phones, etc.); access to Internet/email should be given only on a requirement basis. Security policies must be revised on a yearly basis and after signi cant security incidents.
7.2 Experiments
75
Penetration Testing
7.5
The system must undergo regular penetration tests conducted by third party service provider.
[ ]
User Roles Revision
7.6
As users change roles within the UTMC, new users come, some users go, [ ] there will accumulate artifacts. Users and their roles must be reviewed on a regular basis (at least yearly). Disruption Management Plan
7.7
7.2
There should be a detailed disruption management plan that contains steps to take in the event of a cyber security incident.
[ ]
Experiments Load Spikes Stress-Testing
Service-oriented architecture in combination with comprehensive system monitoring should be able to withstand massive load spikes by automatically performing horizontal scaling of the service that are under pressure. Suggested experiment involves simulation of dierent pro les of system load on dierent parts of UTMS. Pro les could include gradual increase in system load or abrupt spikes of various time span. Time taken to provision additional resources 2) Responsiveness of the system during the whole simulation 3) Time to de-provision resources that are no longer needed 4) Patterns of system degradation with increase in load
1)
[ [ [ [
] ] ] ]
Outage/Failure Stress-Testing
Service-oriented architecture in combination with redundancy should provide capabilities for the system to withstand massive outages without losing functionality and only potentially degrading responsiveness. The experiment is designed to test the system ability to fall back on the backup services when the primary ones are unreachable. What percent of functionality has been degraded after the simulated failure 2) How did the failure aect the responsiveness of the whole system 3) How quickly does the system re-provision failed subsystems and restore in full
1)
[ ] [ ] [ ]
Malformed Inputs
A properly tested system should be resilient against malformed inputs, should it be due to errors or malice. It should also properly work in situations of valid inputs that are the edge cases of the potential input range. Does or does not the system fail on receiving malformed inputs 2) Percentage and pattern of system degradation on malformed inputs
1)
[ ] [ ]
76
Chapter 7. Recommendations for Cyber Resilience
“Ghost” or Misleading UAVs
In this experiment the system should be exposed to 1) UAVs that falsely report their status in various patterns; 2) ghost UAVs. How well does the system detect anomalies without human help 2) How well does the system detect anomalies with human help 3) How quickly does the system detect anomalies
1)
[ ] [ ] [ ]
Communications Fallback and Modification/Forgery
For the communication channels that are selected to be backed by a secondary fallback communication channel in the prototype, this set of experiments will test the switch to the secondary channel when the primary one is blocked. It will also test the ability of the system to detect communications that were tampered with or forged, i.e., sent by and adversary who was trying to impersonate a legitimate system agent. Time to restore functionality using the secondary channel 2) Does the secondary channel have enough throughput 3) Does the secondary channel have low enough latency 4) How well does the system detect tampering with messages 5) How well does the system detect forged messages
1)
[ [ [ [ [
] ] ] ] ]
Penetration Testing
In this experiment the system should be attacked by a hired third-party professional hacker in order to stress-test its ability to withstand real attacks. Were the attackers able to incapacitate at least one subsystem 2) Were the attackers able to steal con dential information 3) Were the attackers able to modify/inject information
1)
[ ] [ ] [ ]
References
[1] Unmanned Aircraft Systems (UAS) Operational Approval. National Policy by U.S. Department of transportation, Federal Aviation Administration, 2013. [2] AIAA. The Connectivity Challenge: Protecting Critical Assets in a Networked World. A Framework for Aviation Cybersecurity. Aug 2013. [3] K. A. Anderson. From Here to MaturityManaging the Information Security Life Cycle. ISACA, 6, 2014. [4] E. M. Atkins. Autonomy as an enabler of economically-viable, beyond-line-of-sight, low-altitude UAS applications with acceptable risk, 2014. [5] R. Austin. Unmanned aircraft systems: UAVS ment, volume 54. John Wiley & Sons, 2011.
design, development and deploy-
[6] S. Barlock, T. Buomante, and F. Rica. Cyber security: it's not just about technology. Technical report, KPMG, 2014. [7] M. Bedford. Unmanned Aircraft System (UAS) Service Demand 20152035. [8] M. o. T. o. S. Bernard Lim. Emerging Threats from Cyber Security in Aviation Challenges and Mitigations, 2014. [9] L. Bianco, P. Dell'Olmo, and A. R. Odoni. New concepts and management. Springer Science & Business Media, 2013. [10] L. Bianco and A. R. Odoni. Large scale in air tra c control. Springer, 1993.
methods in air tra c
computation and information processing
[11] Civil Air Navigation Services Organisation. CANSO Cyber Security and Risk Assessment Guide. Web resource: https://www.canso.org/sites/default/files/CANSO%
78
Chapter 7. Recommendations for Cyber Resilience
20Cyber%20Security%20and%20Risk%20Assessment%20Guide.pdf, accessed on 28 May 2016, published in June 2014. [12] Cook, Stephen P and Brooks, Dallas and Cole, Rodney and Hackenberg, Davis and Raska, Vincent. De ning well clear for unmanned aircraft systems. Proceedings of AIAA Infotech @ Aerospace, AIAA, 481, 2015. [13] D. Cooper, W. Polk, A. Regenscheid, and M. Souppaya. BIOS protection guidelines. NIST Special Publication 800147, 2011. [14] A. Costin and A. Francillon. Ghost in the Air (Tra c): On insecurity of ADS-B protocol and practical attacks on ADS-B devices. Black Hat USA, pages 112, 2012. [15] M. L. Cummings, S. Bruni, S. Mercier, and P. Mitchell. Automation architecture for single operator, multiple uav command and control. Technical report, DTIC Document, 2007. [16] O. I. de Normalización.
ISO/IEC 27005: Information technology-Security tech-
niques Information security risk management.
ISO, 2008.
[17] T. De Zan and F. Di Camillo. The defence of civilian air tra c systems from cyber threats. 2015. [18] M. DeGarmo and G. M. Nelson. Prospective unmanned aerial vehicle operations in the future national airspace system. In AIAA 4th Aviation Technology, Integration and Operations (ATIO) Forum, pages 2023, 2004. [19] D. Delahaye and S. Puechmorel. Wiley & Sons, 2013.
Modeling and optimization of air tra c.
John
[20] Department of Homeland Security. Computer Network Security & Privacy Protection. Web resource: https://www.dhs.gov/xlibrary/assets/privacy/privacy_ cybersecurity_white_paper.pdf, accessed on 22 May 2016, published in 2010. [21] B. Elias. National aviation security policy, strategy, and mode-speci c plans: background and considerations for congress. DTIC Document, 2008. [22] FAA Sponsored Sense and Avoid Workshop. Sense and Avoid (SAA) for Unmanned Aircraft Systems (UAS), October 2009. [23] Federal Aviation Administration. Pilot/Contorller Glossary. Web resource: https: //www.faa.gov/air_traffic/publications/media/pcg_4-03-14.pdf, accessed on 21 May 2016. [24] L. Fern, R. C. Rorie, J. S. Pack, R. J. Shively, and M. H. Draper. An Evaluation of Detect and Avoid (DAA) Displays for Unmanned Aircraft Systems: The Eect of Information Level and Display Location on Pilot Performance. In Proceedings of 15th AIAA Aviation Technology, Integration, and Operations Conference, 2015.
7.2 Experiments
79
[25] Fleeman, Anderson & Bird Corp. Understanding Radio Line of Sight. Web resource: http://www.fab-corp.com/pages.php?pageid=2, accessed on 21 May 2016. [26] J. L. Franke, V. Zaychik, T. M. Spura, and E. E. Alves. Inverting the operator/vehicle ratio: Approaches to next generation UAV command and control. Proceedings of AUVSI Unmanned Systems North America, 2005, 2005. [27] E. Frankenberger, T. Evans, R. Morris, A. B. Othman, A. Webster, A. Verma, B. Hamid, C.-C. Teng, C. Ntrigkogias, D. Sarkar, V. Systems, E. Girgin, G. Digsby, K. Mansson, M. Bjore, M. Keith, and P. d. Souza. CSFI ATC (Air Tra c Control) Cyber Security Project Report. Technical report, July 2015. [28] F. Friedman-Berg, J. Rein, and N. Racine. Minimum visual information requirements for detect and avoid in unmanned aircraft systems. In Proceedings of the Human Factors and Ergonomics Society Annual Meeting, volume 58, pages 5458. SAGE Publications, 2014. [29] J. N. Frye, C. K. Veitch, M. E. Mateski, J. T. Michalski, J. M. Harris, C. M. Trevino, and S. Maruoka. Cyber threat metrics. Mar 2012. [30] C. Furlani.
FIPS 200: Minimum Security Requirements for Federal Information
and Information Systems.
DIANE Publishing Company, 2009.
[31] Gartner, Inc. Five Styles of Advanced Threat Defense Framework, September 2013. [32] M. Heiges, R. Bever, and K. Carnahan. How to Safely Flight Test a UAV Subject to Cyber-Attacks. 2016. [33] E. Iasiello. Getting ahead of the threat: Aviation and cyber security. America, 2013.
Aerospace
[34] IDC. Worldwide Security Products 2011 2014 Forecast IDC February 2011. Technical report, February 2011. [35] Imperva. Top Ten Database Security Threats. Technical report, Imperva, 2015. [36] International Civil Aviation Organization. ICAO's circular 328 AN/190 Unmanned Aircraft Systems (UAS). Web resource: http://www.icao.int/Meetings/UAS/ Documents/Circular%20328_en.pdf, accessed on 21 May 2016. [37] International Civil Aviation Organization. Manual on Remotely Piloted Aircraft Systems (RPAS), 2015. [38] C. W. Johnson. Preparing for cyber-attacks on air tra c management infrastructures: cyber-safety scenario generation. In System Safety, incorporating the Cyber Security Conference 2012, 7th IET International Conference on, pages 16. IET, 2012.
80
Chapter 7. Recommendations for Cyber Resilience
[39] A. Kim, B. Wampler, J. Goppert, I. Hwang, and H. Aldridge. chapter Cyber Attack Vulnerabilities Analysis for Unmanned Aerial Vehicles. Infotech@Aerospace Conferences. American Institute of Aeronautics and Astronautics, Jun 2012. [40] P. H. Kopardekar. Unmanned Aerial System (UAS) Tra c Management (UTM): Enabling Low-Altitude Airspace and UAS Operations. 2014. [41] B. Kovell, B. Mellish, T. Newman, and O. Kajopaiye. Comparative analysis of ADS-B veri cation techniques. The University of Colorado, Boulder, 4, 2012. [42] J. Krozel and D. Andrisani. chapter Independent ADS-B Veri cation and Validation. Aviation Technology, Integration, and Operations (ATIO) Conferences. American Institute of Aeronautics and Astronautics, Sep 2005. [43] S. M. Lee, C. Park, M. A. Johnson, and E. R. Mueller. Investigating Eects of Well Clear De nitions on UAS Sense-And-Avoid Operations in Enroute and Transition Airspace. In 2013 Aviation Technology, Integration, and Operations Conference. American Institute of Aeronautics and Astronautics (AIAA), aug 2013. [44] J. A. Lewis. Assessing the risks of cyber terrorism, cyber war and other threats. Center for Strategic & International Studies Washington, DC, 2002.
cyber
[45] W. Liu, C. Kwon, I. Aljanabi, and I. Hwang. Cyber security analysis for state estimators in air tra c control systems. In AIAA Conference on Guidance, Navigation, and Control, 2012. [46] K. Mans eld, T. Eveleigh, T. H. Holzer, and S. Sarkani. Unmanned aerial vehicle smart device ground control station cyber security threat model. In Technologies for Homeland Security (HST), 2013 IEEE International Conference on, pages 722728, Nov 2013. [47] D. McCallie, J. Butts, and R. Mills. Security analysis of the ADS-B implementation in the next generation air transportation system. International Journal of Critical Infrastructure Protection, 4(2):7887, 2011. [48] D. L. McCallie. Exploring Potential ADS-B Vulnerabilites in the FAA's Nextgen Air Transportation System. Technical report, DTIC Document, 2011. [49] National Institute of Standards and Technology. Framework for Improving Critical Infrastructure Cybersecurity. Web resource: http://www.nist.gov/cyberframework/ upload/cybersecurity-framework-021214.pdf, accessed on 22 May 2016, published in 2014. [50] Ponemon Institute. 2014 Cost of Data Breach Study: Global Analysis. Technical report, May 2014.
7.2 Experiments
81
[51] T. Prevot, J. Rios, P. Kopardekar, J. E. Robinson III, M. Johnson, and J. Jung. chapter UAS Tra c Management (UTM) Concept of Operations to Safely Enable Low Altitude Flight Operations. AIAA Aviation. American Institute of Aeronautics and Astronautics, Jun 2016. [52] L. Purton, H. Abbass, and S. Alam. Identi cation of ADS-B system vulnerabilities and threats. In Australian Transport Research Forum, Canberra, pages 116, 2010. [53] A. Regenscheid and K. Scarfone. BIOS Integrity Measurement Guidelines (Draft). NIST Special Publication 800155, 2011. [54] K. Sampigethaya, R. Poovendran, and L. Bushnell. Secure operation, control, and maintenance of future e-enabled airplanes. Proceedings of the IEEE, 96(12):1992 2007, 2008. [55] K. Sampigethaya, R. Poovendran, and L. Bushnell. Security of future enabled aircraft ad-hoc networks. AIAA Aviation Technology, Integration and Operations (ATIO), 2008. [56] K. Sampigethaya, R. Poovendran, and L. Bushnell. A framework for securing future e-enabled aircraft navigation and surveillance. In AIAA Proceedings, pages 110, 2009. [57] K. Sampigethaya, R. Poovendran, S. Shetty, T. Davis, and C. Royalty. Future EEnabled Aircraft Communications and Security: The Next 20 Years and Beyond. Proceedings of the IEEE, 99(11):20402055, Nov 2011. [58] C. Santiago and E. Mueller. Pilot Evaluation of a UAS Detect-and-Avoid System's Eectiveness in Remaining Well Clear. In Eleventh UAS/Europe Air Tra c Management Research and Development Seminar (ATM2015), 2015. [59] T. Skrzypietz.
Unmanned aircraft systems for civilian missions.
BIGS, 2012.
[60] M. N. Stevens, B. Coloe, and E. M. Atkins. Platform-independent geofencing for low altitude UAS operations. In 15th AIAA Aviation Technology, Integration, and Operations Conference. American Institute of Aeronautics and Astronautics (AIAA), jun 2015. [61] A. R. Thomas.
Aviation security management.
ABC-CLIO, 2008.
[62] Unisphere Research, a Division of Information Today, Inc. 2014 IOUG Enterprise Data Security Survey. Technical report, October 2014. [63] Verizon. 2014 Verizon Data Breach Report. Technical report, 2014. [64] J. S. Warner and R. G. Johnston. GPS Spoo ng Countermeasures. Security Journal, 25(2):1927, 2003.
Homeland
82
Chapter 7. Recommendations for Cyber Resilience
[65] K. W. Williams. A summary of unmanned aircraft accident/incident data: Human factors implications. Technical report, DTIC Document, 2004.
