Cybersecurity Threats and UVS, Aerospace & Defense Oct. 15

Prévia do material em texto

Aerospace & Defense Technology, October 2015 www.aerodefensetech.com 17
As the use of UASs andUAVs increase in themodern battlefield, theneed to secure these
weapon platforms is of increasing
importance as any flaw could have
catastrophic results. To this end
much work has been carried out re-
cently to first understand the av-
enues through which a cyber-attack
could come and then how to react
when measures meant to protect
against it have failed. 
One expert breaks down the av-
enues of attack into ten different
categories, from which four stand
out: GPS jamming, malware, erro-
neous data transmissions, and ap-
plication code manipulation. The
significance of these avenues of at-
tack is that they target the vehicle
itself in a direct manner. 
On the other hand, others sin-
gle out command/control mes-
sages, spoofing, and software-
based threats as some of the major
risks faced by UAVs in the field.
Others propose a more challeng-
ing attack dubbed “the stealthy
deception attack.” During one
such event an undetected injec-
tion of erroneous information is
performed on a vehicle, which
could affect such critical systems
as navigation. 
A perhaps most unnerving av-
enue of attack is that which comes
from within the vehicle itself. In
this kind of attack the vehicle's
hardware is compromised from in-
ception by hacking either software
encryption keys present inside the chip
itself or even the CAD software suite used
to design it to gain access to said key. 
Another hardware attack pattern in-
volves malicious Trojan-style code
being inserted into the FPGA (field-pro-
grammable gate array) at the time of
manufacturing. This type of threat is
difficult to detect and could lead to se-
vere consequences depending on what
system the tainted integrated circuits
are installed on. 
In response to all this, several solutions
have been proposed with the most com-
mon being supervisory architecture. Su-
pervisory logics compare ideal to actual
system states in hopes of detecting un-
usual system behavior. Many agree that
any solution for cyber-physical systems,
such as UAVs, need to take into account
the physical medium in which they oper-
ate and that there is no one single solu-
tion, but instead a different specific ap-
proach to protect the systems' safety,
security, and sustainability. In this
context a proposed solution from
Cranfield University fits in. 
Low-Level Monitoring 
Cranfield’s system is conceptu-
ally split into two layers that
oversee different aspects of the
system’s behavior, but are im ple -
mented separately due to their
specific characteristics. Figure 1
shows how the mission monitor
layer oversees overall operation of
the platform in terms of what it
was ordered to do, while a lower
layer monitors specific software
features using a generic algorithm
that can be applied to different
software modules by only recon-
figuring its parameters. 
Conceptually speaking the
lower level algorithm works in a
similar manner as a planning al-
gorithm. It monitors the state of
the overseen software module to
determine what actions are legal,
applicable, and appropriate to the
present situation per the follow-
ing definitions: 
• Legal: actions within opera-
tional and physical limits for a
given function; 
• Applicable: actions that can be
physically or computationally
carried out within the present
context; 
• Appropriate: actions that could
be legal and applicable, but against
bespoke rules set by the user. 
Consider the example of a UAV
data link. A legal action could be
defined as the transmission of data
within the electrical capabilities of the
transmitter (i.e., transmission speed and
bandwidth). An illegal action would be
trying to transmit at higher bit rates than
nominally allowed, which in turn could
increase power consumption or even
damage the transmitter. Following on
with the same theme, the action of trans-
mitting video data back to base would be
applicable only if the video camera is
turned on, but not otherwise. Then there
Cranfield University researchers have
developed a monitoring system whose
purpose is to monitor mission profile
implementation at both high level
mission execution and at lower level
software code operation to tackle
specific threats of malicious code and
possible spurious commands received
over a vehicle's data links. 
Countering Cybersecurity 
Threats Against 
Unmanned Vehicle Systems 
Cov ToC + – ➭
➮
AIntro
18 Aerospace & Defense Technology, October 2015Free Info at http://info.hotims.com/55594-750
Cybersecurity
is the case where during a certain seg-
ment of a mission where data transmis-
sion could be used to track and shoot
down the UAV, the user might want to
block the use of the data link by declaring
data transmission inappropriate under
certain circumstances. The importance of
this last category is that data transmission
could be legal and applicable, but the
user could render it inappropriate, hence
blocking its execution. This scheme pro-
vides flexibility and greater level of detail
when determining what actions can be
performed at a given time, which in turn
is useful for intrusion-caused or any other
anomalous system behavior. 
To correctly monitor each software
function (also known as features) under
its authority, the low-level monitoring al-
gorithm is structured in a way that allows
for its operation to be as “generic” as pos-
sible as it could possibly be interacting
with completely different software fea-
tures from one moment to another. 
Na
vi
ga
ti
on
 
An
al
yz
er
UAV
Subsystem Software 1 Subsystem Software n
Low-Level 
Software 1
Low-Level 
Software 2
Monitor Monitor Monitor
Physical 
Device
Physical 
Device
Physical 
Device
Physical Layer Analysis
Be
ha
vi
or
 C
oh
er
en
ce
Low-Level 
Software n
Figure 1. Cranfield’s system is conceptually split into two layers which oversee different aspects of the
UAV's behavior, but are implemented separately due to their specific characteristics.
Cov ToC + – ➭
➮
AIntro
Each feature object under the moni-
tor's authority must be classifiable as
“primitive.” In other words, it must be
directly in control of a physical task. An
example of this could be one software
function in charge of aileron control or
camera data capture. 
To achieve its goal the monitor ex-
ploits the concept of execution domain.
An execution domain is the set of data
that describes the group of actions that
each feature can carry out. It also in-
cludes the rules for deciding on the le-
gality, applicability, and appropriate-
ness (LAA criteria) of each individual
task, which could be abstract or based
on physical data. Next is the informa-
tion regarding the set of input and out-
put data coming and going from the
feature being evaluated. 
Finally, “safe state” information for
each software feature is provided in case
of intrusion detection. In this case the
lower-level algorithm would pass the
data up to the higher level advising
what actions should be taken to isolate
the suspect feature in order to reduce
the risk exposure of the platform.
The execution of the monitoring sys-
tem conforms to the following steps:
Step 1: Load executive domain data.
Step 2: Read functional I/O.
Step 3: Evaluate LAA criteria.
Step 4: Determine if I/O or any LAA
rules are broken; if so, flag software fea-
ture as suspect of tampering.
Step 5a: If Step 4 proved positive, rec-
ommend higher level algorithm to take
vehicle to the safe state definedfor the
given feature.
Step 5b: If Step 4 is negative, carry on
to next software feature.
Figure 2 illustrates the steps in a graph-
ical format. The function Evaluator takes
in as input argument the name of the
feature to monitor. It then loads in the
matching entry from the Execution Con-
text Database to take a snapshot of the
feature's I/O. This information is passed
on to helper function that examines the
snap shot data and returns NULL if the
I/O combination does not match any
LAA rule, or it returns a structure with
the details of the rule which come pack-
aged together with its recognized I/O.
This low level monitor works similar
to a planner function. Outputs are
treated as states in a “state space” and in-
puts as conditions that are a prerequisite
for such a state to be reached. Therefore
the helper function performs a simple
search of applicable states using both the
output values snapshot together with
the LAA rule set. If there is a match a sec-
ond search is performed to find out
whether the inputs (i.e., the prerequi-
sites) are valid for such a state to exist. If
at least one of these searches proves un-
successful the function returns NULL. By
monitoring at primitive software feature
level the complexity of state search is
Aerospace & Defense Technology, October 2015 19
Small Mechanical Components – 
ONE CONVENIENT SOURCE
9100ASREGIS
TE
RE
D ISO 9001
Timing Belts and Pulleys
Precision Gears 
Gearheads 
Bearings
Clutches and Brakes
Couplings & Universal 
Joints
Shafts, Shaft Accessories 
& Hardware
Technical Support
Customized Design
Online Calculations
Coupling Selector Tool
Download 3D Models
Get Your Free Catalog
Engineered Solutions for a World in Motion
Phone: (516) 328-3300 www.sdp-si.com
Over 130,000 standard items
Free Info at http://info.hotims.com/55594-751
Cybersecurity
Cov ToC + – ➭
➮
AIntro
20 www.aerodefensetech.com Aerospace & Defense Technology, October 2015
Cybersecurity
dramatically reduced and can be per-
formed in a computationally efficient
manner while detecting potential viola-
tions to intended software operation. 
Navigation Analyzer 
The first step to understanding the
operation of the navigation analyzer is
to introduce the concept of “vehicle
stance.” As a mission progresses the
UAV can go through any number of op-
erating conditions. It could be flying to
target, loitering, or even engaging an
enemy. Therefore, to capture this fluctu-
ating environment, a decision making
tree is used to decide what stance to
adopt in the present situation. 
For example, if there are no threats
present in the path of the vehicle as it
moves toward its target, the stance could
be set to “passive-navigation.” If a threat
appears that can be avoided, “avoidance-
navigation” is used. Should the vehicle
come under attack, then “abort-defen-
sive” or “avoid-defensive.” The former
could be employed if the threat cannot
be escaped from while still being able to
continue the mission; if evasion is prob-
able and the mission can be continued,
then the latter would be used. The inner
workings of the stance decision engine
are outside the scope of this work. Suffice
to say that each stance comes with cer-
tain conditions and guidelines that need
to be met and observed. 
Now, in the course of a given assign-
ment a vehicle can adopt a myriad of
trajectories depending on factors like
weather conditions, existing threats and
their positions, fuel consumption, dis-
tance to base, etc. Because of the infi-
nite number of possible combinations,
it would not be efficient to attempt to
use a state space search engine to try
and figure out if the vehicle is heading
in the correct general direction per the
existing stance. To solve this problem
two systems are used in tandem to
monitor that the vehicle is not navigat-
ing in an unexpected manner. 
The first element is an Inertial Naviga-
tion System (INS). Although considered
pricier for the same level of accuracy as a
GPS system, INS devices are stealthy in
that they do not emit or require electro-
magnetic signals for data exchange. The
system that manages the INS can be
hardwired with fixed firmware to pre-
vent any tampering or intrusions from
outside, and in the case that the main
navigation systems are compromised INS
can be used as a backup. 
Second is a cost function. This cost
function weighs in factors such as fuel
consumption projection, distance to
base, and distance to objective to calcu-
late a score for a probable trajectory that
satisfies mission parameters. For exam-
ple, if the vehicle is taken over by a Tro-
jan that changes the existing navigation
waypoint to one further away from
base, the navigation analyzer will com-
pare the new route against the previous
one and will raise a flag when a score
outside a preset threshold is computed. 
Behavior Coherence 
The last stage of Cranfield’s system
works with the decision-making tree to
determine what stance—or what basic
behavioral rules and guidelines—will
govern the actions of the vehicle itself.
This is important as many intrusion
methods seek to alter the way in which a
UAV operates, from the low-level basic
functions to the higher level and more
complex systems. 
Inputs
Feature
Execution
Block
Outputs
Software Feature
2a. Read functional input
1. Load execution 
domain data
3. Evaluate
Execution
Domain
Database
Evaluator
2b. Read functional output
Low-Level Monitor
4. Check if any results
from evaluation step 
violate criteria
Result
5. Communicate
Result
Vehicle Stance Monitor Results and
Warnings
Low-Level
Monitors
Navigation
Analyzer
Navigation Warnings
and Status Flags Intrusion
Detection
Response
Incoherency
Warnings Behavior
Coherence
Energy Consumption Warnings
Physical Layer
Energy Consumption Data
Subsystem A Subsystem B Subsystem n
Figure 2. Graphic depiction of low-level monitor interactions.
Figure 3. To make sure the overall operation of the vehicle is in conformance with set mission goals, an
abstract high-level mission monitor is implemented that verifies energy consumption figures from subsys-
tems are in line with expected parameters; vehicle navigation and control are supervised to ensure maneu-
vers are coherent with actual vehicle stance and mission objectives; and there is coordination with the
lower-level monitor to secure the vehicle in a safe operational state should an intrusion or anomalous
behavior be detected.
Cov ToC + – ➭
➮
AIntro
By setting a behavior profile, or stance,
complexity is reduced as the system must
follow what the stance allows, rendering
other combinations of actions illegal and
non-applicable making monitoring
quicker and more efficient. Figure 4 is the
graphical representation for this behavior
coherence stage. The behavior analyzer
receives guidelines and conditions from
the stance decision engine and extracts
from guidelines a list of subsystems that
should be associated with the set profile.
It is then verified that none of the associ-
ated subsystems have been flagged by the
lower-level monitor of being suspect of
intrusion; and verified that all operating
conditions for the desired profile can be
met. If not, the incoherency flag is raised.
Otherwise, vehicle system information is
monitored for possible behavioral devia-
tions. If a behavioral deviation is de-
tected, the incoherency flag is raised to
have the intrusion detection response
take the vehicle to a known safe state. 
The Table and Figure 5 providean ex-
ample of guideline and condition pars-
ing and evaluation. From parsing the
contents of the Table, the behavior ana-
lyzer knows that it should expect to
have a specific response from the moni-
tor's physical layer, the low-level moni-
tor, and the lighting system itself. 
In the top plot of Figure 5, the power
consumption for the landing lights is
shown. Per the information in the Table,
the trace should stay within the toler-
ance, but it can be seen to start oscillat-
ing after 200 seconds of operation. The
behavior analyzer flags this as a devia-
tion, as shown in the middle plot of Fig-
ure 5, but curiously enough the low-
level monitor does not raise any flags.
This actually comes to exhibit a strong
point of the proposed
system. 
Remember that the
low-level monitor raises
a flag when the output
of a primitive function
does not match what was expected
for a given set of inputs, but what
happens when the primitive func-
tion is behaving as expected yet the
overall subsystem does not? 
Here is when the behavior moni-
tor comes into play. Even when the
low-level monitor cleared the primi-
tive aspect of the lighting system it still
behaved erroneously. These deviations
by the non-primitive features were then
picked up by the higher level behavior
monitor. It is clear then how complete
coverage is provided by the different
system blocks. 
Should the need arise for a platform
to be reconfigured midway through a
given assignment, the following chain
of events would take place for the sys-
tem to allow for such changes without
flagging them as possible intrusions. 
• Prior to departure a set of decoding
frames are shared between controller
and vehicle; these frames should pro-
vide complete secrecy in cryptograph-
ical terms, for example, a set of one-
time pads (OTPs). Each frame should
be paired with a unique identifier
character chain. This chain, in turn,
would be passed through a SHA-like
(secure hash algorithm) encoder and
uploaded into both the control and
vehicle systems. 
• When the vehicle needs to be recon-
figured for a change of mission the
controller would send the new profile
information encoded using one of the
preset OTPs together with the pad's
encoded identifier. Each pad is se-
lected using a uniformly distributed
random variable based selector. 
• The vehicle matches the encoded
identifier with its OTP index and re-
covers the pad. 
• The new profile is decoded and the ve-
hicle is then reconfigured. Since the
mission information is now loaded
any modifications in behavior are not
flagged and the vehicle can proceed. 
Further work will now be carried out
to pair the system with an artificial in-
telligence planner. This new addition
will be in charge of scheduling the ex-
ecution of all required actions neces-
sary for the achievement of the mis-
sion goals. After analyzing the risks
and possible avenues for cyber-attack
on UAS platform it should be clear
how this new functionality could not
be considered without first imple-
menting the monitoring system object
of this work. 
This article is based on SAE Technical paper
2014-01-2131 by Rodrigo Felix, John
Economou, and Kevin Knowles, Cranfield Uni-
veristy, doi: 10.4271/2014-01-2131. 
Aerospace & Defense Technology, October 2015 www.aerodefensetech.com 21
Cybersecurity
Landing Light Power Consumption
Po
w
er
 (
W
)
De
vi
at
io
n 
De
te
ct
io
n
Lo
w
 L
ev
el
De
vi
at
io
n
600
400
200
0
1.5
1
0.5
0
1
0
-1
0 50 100 150 200 250 300 350 400 450
0 50 100 150 200 250 300 350 400 450
0 50 100 150 200 250 300 350 400 450
Time (s)
Figure 5. An atypical response for the landing light behavior described in the Table.
Vehicle Sensor
Information
Stance
Decision
Engine
Guidelines and
Conditions Behavior
Analyzer
Vehicle 
System
Information
Navigator
Analyzer
Incoherency
Warnings
Figure 4. The behavior analyzer receives guidelines and
conditions from the stance decision engine and
extracts from guidelines a list of subsystems that
should be associated with the set profile
Table. Landing-Navigation Stance Extract
Stance System Action Condition
Landing– Lighting Landing light Power 500 Watt
Navigation must be on tolerance 10%
Cov ToC + – ➭
➮
AIntro