Today’s satellite navigation systems rely on constellations of satellites operating in medium earth orbits in several orbital planes. Each satellite broadcasts a signal containing orbital data and the precise time at which the signal was broadcast. The precise time is generated by a very accurate atomic clock on board the satellite. A satellite navigation receiver is able to determine its position very accurately from this information, if it is receiving signals from four or more satellites simultaneously. There are two types of satellite navigation system currently deployed – Regional Satellite Systems (RSS) or Global Navigation Satellite Systems (GNSS). A cyber attack on the GNSS system could exploit the RF channels used by Receivers for GNSS signal reception, alternatively it could also (at least as easily) exploit the channel used by a Positioning, Navigation and Timing (PNT) system to report its position. Once it is understood that the evolution of GNSS threats does not only have clear parallels with the way that IP threats have evolved, but shares many of the features of a connected network, it can be seen that many of the lessons learned by the Information Security community apply equally as well to the GNSS community.

1. 1
INTRODUCTION
Today’s satellite navigation systems rely on constellations of
satellites operating in medium earth orbits in several orbital
planes. Each satellite broadcasts a signal containing orbital
data and the precise time at which the signal was broadcast.
The precise time is generated by a very accurate atomic clock
on board the satellite. A satellite navigation receiver is able to
determine its position very accurately from this information, if
it is receiving signals from four or more satellites
simultaneously. There are two types of satellite navigation
system currently deployed – Regional Satellite Systems (RSS)
or Global Navigation Satellite Systems (GNSS).
GNSS constellations currently deployed include:
• GPS - US system that became globally operational in 1994
and comprises up to 32 satellites deployed in 6 orbital planes
• GLONASS – Russian Federation System comprising up to
31 satellites
• Beidou – Chinese system comprising 15 satellites currently
with 20 additional satellites planned. Currently Beidou is an
RSS but is planned to be a full GNSS by 2020
• Galileo – European Union system planning to deploy 30
satellites in medium earth orbit in three orbital planes.
Given our reliance on Global Navigation Satellite Systems
(GNSS), in particular GPS, it is not surprising that its
vulnerabilities are attracting a great deal of attention. In the
past year there have been a number of well publicized
incidents which have largely confirmed the theoretical and
experimental work that predicted the vulnerabilities of GNSS.
It is perhaps striking to review the evolution of threats to
GNSS with the way threats in the Internet Protocol (IP) world
developed. In a paper at ENC 2014 in Rotterdam, Theunissen
[1] provided a compelling insight into the parallels between
the manner in which IP threats have developed and the
evolution of both jamming and spoofing attacks against
GNSS.
Theunissen argued that GNSS could reasonably expect the
number of attacks against it to increase in the same manner
that the number of internet hacking attacks has done in recent
years, and that some of those attacks will likely become better
organized. It is certainly becoming easier to mount attacks
against GPS using jammers (as there are many sources of low
cost jammers available to purchase online) or spoofers.
Whilst it has often been stated that GNSS spoofing is too
difficult and too expensive to undertake easily, this turns out
not to be the case – in [2], Ghaddar et al demonstrated that
GPS spoofing can be undertaken with an inexpensive
Software Defined Radio (SDR). The authors stated that the
aim of their project was “to prove that GPS is vulnerable to
spoofing using commercial portable software radio platforms
(e.g. NI-USRP 2920). In other words, we will use the NI-
USRP 2920 to transmit GPS signals that override the actual
satellite signals carrying a fake location of the GPS receiver.”
The low signal strength of GNSS signals when received on the
ground, is the reason that GNSS is vulnerable to attacks using
the RF channel either to jam or spoof the target receiver.
Sometimes the receiver is subject to unintended jamming or
spoofing. TV transmitter harmonics can cause accidental
jamming of GPS signals whereas a GPS repeater broadcasting
on a GPS frequency could cause a nearby GNSS receiver to
report an incorrect position.
Consideration of the whole GNSS System as a whole,
including ground stations, satellite uplinks and downlinks,
augmentation systems and datalinks, is instructive as it allows
us to see that in fact jamming and spoofing events are actually
cyber-events, with GNSS jamming (if it causes receivers to
cease functioning altogether) being the equivalent of a Denial
of Service (DoS) event. In the event that multiple jammers,
spoofers, or a combination of both are used, the attack would
be equivalent to a Distributed Denial of Service (DDoS)
attack.
A cyber attack on the GNSS system could exploit the RF
channels used by Receivers for GNSS signal reception,
alternatively it could also (at least as easily) exploit the
channel used by a Positioning, Navigation and Timing (PNT)
system to report its position. In [3] Balduzzi showed how
hackers could take advantage of the Automatic Identification
System (AIS) employed by many vessels. As the datalink
employed by AIS is unencrypted, the attacks that the author
described are relatively straightforward to implement and in
some cases could produce exactly the same results as a
spoofing attack on the GNSS RF signal channel.
Once it is understood that the evolution of GNSS threats does
not only have clear parallels with the way that IP threats have
evolved, but shares many of the features of a connected
network, it can be seen that many of the lessons learned by the
Information Security community apply equally as well to the
GNSS community.
GNSS Receivers and the Cyber –Threat:
Lessons from the Information Security
Community
Guy Buesnel, David DeSanto, Spirent Communications

2. 2
THE GNSS COMMERCIAL MARKET
The use of GNSS has become almost pervasive in many
sectors with the global installed base of GNSS devices passing
2 billion devices in 2013 and predicted to reach 7 billion units
by 2022, an almost four-fold increase that would equate to
almost one for every single person on the planet [4].
GNSS is already used by critical infrastructure such as utility
providers, financial, transport sectors to provide timing or
positional data and growth in new and market spaces such as
the Intelligent Transport sector will use GNSS to provide data
for use in safety critical applications. In all of these market
segments the security of GNSS is of high importance as a
hacking attack could achieve more than just reputational
damage. In all of the applications where 4-dimensional
information is required to enable system operation, the use of
precise timing from GNSS will be essential for time stamping
of transactions and significant damage could occur if incorrect
time information is propagated.
GNSS THREATS
The GLONASS outage that occurred in April 2014 is an event
that deserves some attention. In April 2014 (01 April) the
entire GLONASS constellation commenced the transmission
of incorrect broadcast messages. The messages were highly
inaccurate (up to 200km). Whilst two of the satellites were
corrected within an hour, the problem persisted much longer
for the other orbiting satellites and problems lasted into 02
April. Many GPS + GLONASS Receivers were affected, in
one way or another, with some systems completely failing to
track both GLONASS and GPS satellites. Other GPS+
GLONASS Receivers were unaffected and continued to track
normally. The reason for the failure is still unclear but has
been attributed to incorrect software being uploaded to the
GLONASS satellites. Whilst this event was attributable to
human error, it is also clear that such an event could be caused
by a malicious attack, which would probably require insider
knowledge to carry out. The consequence of this event was a
DDoS which affected many GNSS Receivers that used
GLONASS satellites in their PNT solution.
GPS jamming has become prevalent recently with many
reports from Europe and around the world suggesting that the
use of cigarette lighter type jammers in vehicles to avoid
tracking has become widespread. Whilst these trackers are
often advertised as having very limited range (in the order of
2m or so), this is for saturating the GPS Receiver input with
RF interference so that it ceases to function. However many
of the effects caused by jamming are more subtle. The output
of hazardously misleading information and the fact that
detection systems are able to pick up signals from the jammer
at considerably greater distances tends to suggest that the
ranges at which these small, portable jammers can cause
disruption to GNSS receivers is much greater than the figure
that is quoted in their specification.
Whilst no instance of a deliberate spoofing attack has been
confirmed thus far (excluding for demonstration or
experimental purposes), it should be noted that there have
been instances of unintended spoofing being reported.
Unintended transmission of incorrect GNSS signals can occur
with use of a GNSS Repeater or similar which is radiating at a
higher power level than the authentic GNSS signals. This can
cause a GNSS receiver to lock onto the incorrect signals and
report the position of the repeater as being the user position.
Use of GPS repeaters in unsuitable locations, such as for
production tests in an open workshop, have been reported to
these authors. The risk is not just that GNSS interference
could extend outside the building and affect users, but that a
GPS receiver could be spoofed and tricked into reporting an
incorrect position.
Whilst there has been no official confirmation of a deliberate
spoofing attack so far, [6] presented an interesting account of
the Global Fishing Watch project. Global Fishing watch has
been set-up to monitor illegal fishing boats globally and in real
time. In this article it is claimed that there has been a 59%
increase in the number of ships transmitting incorrect
positioning over the past two years. An example is shown
where a Satellite AIS Receiver, with a receiver footprint
covering the Atlantic Ocean, is receiving data from two ships
in the Pacific Ocean. As it is physically impossible for
transmissions from AIS transponders in the Pacific Ocean to
be received by this satellite, it is clear that they are spoofing
their position in some manner. The author of the article
believed that false navigational data had been entered into
these ships’ AIS transmitter; however it is equally possible
that the GPS receiver itself had been spoofed.
EVOLUTION OF EXPLOITS AND VULNERABILITIES IN
THE INFORMATION SECURITY COMMUNITY
There has been much debate within the Information Security
community for the past twenty years on how exploits targeting
vulnerabilities within products were disclosed. Initially, these
exploits were kept hidden and only shared amongst groups of
hackers or security researchers. With the birth of online
forums like Bugtraq [7], the world of full disclosure was born.
These online forums allowed the creators of exploits of
various levels of maliciousness to post their findings along
with sample code for the users of the Internet to access. This
allowed everyone from security researchers and enterprise
administrators along with hackers to access details about
vulnerabilities within applications and critical systems. Also,
with this new level of unprecedented access, security
researchers and hackers alike could earn levels of credibility
for their findings. This validation continued the cycle with
more and more public disclosure of vulnerabilities and the
birth of additional online outlets for release of exploit content
including mailing lists like the full disclosure mailing list in
July 2002 [8].
With the proliferation of available exploit content along with
information on its intended target, proof-of-concept (PoC)
code started becoming the basis of more advanced tools
including automation of attacks targeting these vulnerable
targets lowering the bar for entry into the world of
exploitation. The best definition of full disclosure comes from
Jay Heiser in “Exposing Infosecurity Hype” [9] where he
stated “The term ‘full disclosure’ is marvelously ambiguous,

3. 3
and therein lies much of the problem. It essentially means to
‘widely disseminate as much information about system
vulnerabilities and attack tools as possible so that potential
victims are as knowledgeable as those who attack them.’”
Full disclosure, by its very nature, exposed the vulnerability to
the product vendor the same time it did to the enterprise as
well as the community at large (which included hackers). This
was very unpopular amongst some enterprises, security
researchers and product vendors who did not feel that exploit
code needed to be available in wide distribution to help
resolve vulnerabilities. Furthermore, it was aiding someone
who had more of a nefarious purpose than it was an enterprise
that wanted to validate that they were protected or vulnerable.
Scott Culp discussed this issue in his paper “It’s Time to End
Information Anarchy” [10] and began to build upon the
building blocks of what is known today as responsible
disclosure. Responsible disclosure, or coordinated disclosure,
builds upon the core concept that security researchers should
notify product vendors like is done with full disclosure. The
main difference is that this disclosure is coordinated between
the discoverer of the vulnerability and the product vendor
affected first. This allows the affected vendor to begin
preparing a software patch or update prior to the public
announcement of the vulnerability. Once a reasonable amount
of time has passed, the vulnerability is announced and
sometimes is accompanied by a statement by the product
vendor that a fix is available immediately or will be available
soon.
Responsible disclosure, like full disclosure, does include its
flaws. Two main criticisms involve time to announcement of
the vulnerability and research compensation. With
responsible disclosure, it may take the product vendor days to
months to patch the vulnerability (depending on the
complexity). This leads to a false sense of security for the
current users of the product who do not know this
vulnerability exists until it is announced. Also, there is no
financial compensation for the security researcher who has
decided to release this vulnerability through responsible
disclosure. This has been addressed through commercial
vulnerability brokers like the Zero Day Initiative (ZDI) [11]
who purchases the exploit and vulnerability research from the
security researcher and then follows a responsible disclosure
process to coordinate and announce the vulnerability.
Even with full and responsible disclosure, there are parts of
the Information Security community, including product
vendors and security researchers, which believe that
nondisclosure is still the best policy. The belief is that
keeping this information secret will protect the enterprise
better than full or responsible disclosure. With nondisclosure,
the product vendor can address the vulnerability and release
updates without public knowledge of exploitability. Vendors
who build and commercialize exploit-based solutions also
favor nondisclosure. Nondisclosure gives a false sense of
security as the vulnerability is not disclosed in any fashion.
As it is not disclosed, this means that there is no knowledge of
who knows what within the Information Security community
and there may be exploits targeting vulnerabilities in which
the product vendor may be unaware. Nondisclosure may, at
times, be the equivalent to the ostrich sticking its head in the
sand.
HOW THE INFORMATION SECURITY COMMUNITY
MANAGES VULNERABILITIES
Regardless of the use of full or responsible disclosure,
reported vulnerabilities need a system by which to track and
measure items such as severity. Furthermore, there should be
multiple ways for reporters to submit their found
vulnerabilities.
Common Vulnerabilities and Exposures (CVE) system [12] is
a system maintained by the MITRE Corporation and
vulnerabilities enumerated by CVE IDs are listed in multiple
online repositories including the United States National
Vulnerability Database (NVD) [13]. The CVE system was
founded in 1999 to help bring common, standardized
identifiers and metrics to vulnerabilities and exploits where
initially every vendor and reporter handled everything
differently. Each CVE ID provides a unique identifier, a
description of the vulnerability, available PoC code when
available and any pertinent resources. The CVE database is
available free for public download and use.
The CVE system, including its free availability, includes
several other key components. It is comprised of participating
CVE Numbering Authorities (CNA) which include MITRE,
software vendors like Adobe, Microsoft, Cisco and Google as
well as third-party coordinators including CERT/CC. It also
includes a scoring system, Common Vulnerability Scoring
System (CVSS), which is used for assessing the severity of the
vulnerability on a scale of 0 to 10 with 7 to 10 considered
high. The assessment criteria [14] measures the base metrics
including the access vector, temporal metrics including the
availability of exploitation techniques and environmental
metrics including the collateral damage potential.
MITRE outlines the CVE ID reservation process on their
website [15]. The process is:
• The security researcher, product vendor or incident
response team requests the amount of CVE ID numbers
needed
• MITRE reserves the CVE ID(s), provides them to the
requester and creates blank, content-free CVE ID(s) on the
CVE website
• The requester shares the provided CVE ID(s) with all
parties involved
• The requester includes the CVE ID(s) in all advisories
• The requester makes the CVE ID(s) public and notifies
MITRE
• MITRE updates the CVE ID(s) on the CVE website to
include the provided details
For researchers who choose to not go through responsible
disclosure and choose to pursue full disclosure, posts to
forums such as Bugtraq will also receive CVE IDs. These will
not go through the same coordination process listed above
however will still end up within the same standardized
structure the CVE system provides.

4. 4
A POSSIBLE REPORTING FRAMEWORK FOR GNSS
VULNERABILITIES
Following the assertion that vulnerability disclosure is in fact
the correct course of action, responsible disclosure would
outline the best option for the GNSS community. This will
allow security researchers and product vendors to disclose
vulnerabilities publicly. There are several options on how to
properly set up a reporting framework for GNSS
vulnerabilities. The GNSS community can build its own
solution separate from the Information Security community
where it can control the reporting structure and leave the
system as close to nondisclosure as possible. This may limit
product vendor exposure however as outlined this leads to a
false sense of security. A reporting framework that is too
closed will not support a community of researchers that are
trying to improve the security of the GNSS industry.
A reporting framework for GNSS vulnerabilities that
leverages existing vulnerability reporting systems will allow
the GNSS community to follow responsible disclosure
practices. This reporting framework might include the
following components:
• Partner with MITRE to get the GNSS community set up in
the CVE system
• Communicate with incident response teams like CERT/CC
and provide processes for working with GNSS product
vendors on vulnerability disclosure
• Identify key stakeholders within the GNSS community to
become CNAs
• Create a website similar to Open Sourced Vulnerability
Database (OSVDB) [16] dedicated to GNSS vulnerabilities
managed by the GNSS community with its own identifiers
LESSONS THAT GNSS COULD LEARN FROM THE
INFORMATION SECURITY COMMUNITY
The GNSS community needs to act to not find to itself in the
same place at the Information Security community did in the
early stages of vulnerability disclosure. It is very easy to
default to nondisclosure however this leaves customers and
product vendors exposed to unknown vulnerabilities. The
GNSS community has the advantage that the Information
Security community has been working through these hurdles,
and continues to, for the past two decades. Below are some
lessons learned which the GNSS community can leverage:
• Responsible disclosure allows everyone to win
• Without some form of proper disclosure, threat actors will
take the known threats and use them to leverage against
consumers and product vendors
• Disclosure of vulnerabilities within your product does not
lead to credibility issues
• Time to resolution is the key
• Building a community-based framework will lead to better
adoption within the community
The GNSS community has an opportunity to come together,
learn from the Information Security Community and adopt
best practices to secure its customers.
REFERENCES
[1] So you think you are safe, Theunissen, E, ENC 2014,
Netherlands
[2] Exposing GPS Vulnerabilities: Spoofing with
Programmable Software Radios, Nadim Ghaddar, Marwan
Mattar, Abdul-Amir Yassine, American University of Beirut,
Online,
https://feaapps.aub.edu.lb/feasac_submissions/fullpapers/2/66
0_Exposing%20GPS%20vulnerabilities_Spoofing%20with%2
0Programmable%20Software%20Radios.pdf
[3] AIS Exposed Understanding vulnerabilities and attacks
2.0, Balduzzi, M, Wilhoit, K, Pasta, A, Trend Micro
Research, Blackhat Asia 2014
[4] GNSS Market Report, Issue 3, European GNSS Agency
(GSA), October 2013
[5] Jamming and Spoofing in GPS/GNSS Based Applications
and Services – Threats and Counter Measures, Cuntz, M,
Konovaltsev, A, Dreher, A, Meurer, M, Institute of
Communications and Navigation, German Aerospace Center
(DLR), Future Security: 7th Security Research Conference,
Future Security 2012
[6] Spoofed Satellite Feeds Trouble Google’s Global Fishing
Watch, Neal Ungerleider, Fast Feed, Online
http://www.fastcompany.com/3038863/fast-feed/spoofed-
satellite-feeds-trouble-googles-global-fishing-watch
[7] Vulnerability Disclosure – How do we define Responsible
Disclosure?, Shepherd, S., https://www.sans.org/reading-
room/whitepapers/threats/define-responsible-disclosure-932
[8] Full Disclosure Mailing List –
http://seclists.org/fulldisclosure/
[9] Exposing Infosecurity Hype, Heiser, J., Information
Magazine, Online (from Wayback Machine),
http://web.archive.org/web/20010203140700id_/http://infosec
uritymag.com/articles/january01/columns_curmudgeons_corn
er.shtml
[10] It’s Time to End Information Anarchy, Culp, S.,
Microsoft TechNet, Online (from Wayback Machine),
http://web.archive.org/web/20011109045330/http://www.micr
osoft.com/technet/treeview/default.asp?url=/technet/columns/s
ecurity/noarch.asp
[11] HP TippingPoint Zero Day Initiative –
http://www.zerodayinitiative.com/
[12] Common Vulnerabilities and Exposures –
https://cve.mitre.org/about/index.html
[13] National Institute of Standards and Technology (NIST)
National Vulnerability Database (NVD) – http://nvd.nist.gov/
[14] A Complete Guide to the Common Vulnerability Scoring
System Version 2.0, Mell, P., Scarfone, K., Romanosky, S.,
Online, https://www.first.org/cvss/cvss-guide
[15] Introduction to CVE Identifier Reservation –
https://cve.mitre.org/cve/cna.html
[16] Open Sourced Vulnerability Database (OSVDB) –
http://osvdb.org/

5. 5
Guy Buesnel CPhys, AFRIN
Market Segment Leader – Robust Positioning, Navigation and
Timing
Spirent Communications
Guy has more than 16 years’ experience working protecting
GNSS Receivers from emerging threats, having started his
career as a Systems Engineer involved in developing GPS
Adaptive Antenna Systems for Military Users at Raytheon
Systems Limited in the UK.
In 2007, Guy became European GNSS Product Line Manager
at Rockwell Collins UK, responsible for UK and European
GNSS Development activities, before moving to the Satellite
Applications Catapult in June 2013 as Principal Satellite
Navigation Systems Architect.
In May 2014, Guy joined Spirent as Market Segment
Manager–GNSS Vulnerabilities. Guy is responsible for
developing Spirent’s approaches to Robust PNT including the
development of test solutions for GNSS Jamming, Spoofing
and Cyber-attack.
Guy is a Chartered Physicist, a Member of the Institute of
Physics and an Associate Fellow of the Royal Institute of
Navigation. Guy is also a keen blues guitarist.
David DeSanto
Director, Product Management – Application Security
Spirent Communications
David is a network security professional with over 15 years of
product management, security testing, software development
and strategic innovation experience. At Spirent, David focuses
on driving innovation by looking holistically at security
testing and defining product requirements with the primary
goal of making all results repeatable. David is a strong
technical leader with firm understanding of TCP/IP as well as
multiple layer 7 protocols including HTTP, SMTP and SIP.
Prior to Spirent, David was the Director, Product Management
at NSS Labs where his expertise guided the organization in
creating leading security tests and solutions for enterprises,
services providers and network equipment vendors. Prior to
NSS, David was the Chief Innovation Strategist at ICSA Labs
where he set the organization’s direction for testing Network
Firewall, Web Application Firewall, Network IPS, IPSec
VPN, Anti-Spam, Network Anti-Virus, Groupware Anti-Virus
and other security technologies.