This document discusses securing the navigation of unmanned maritime systems (USVs) through autonomous navigation aids. It explores vulnerabilities in global navigation satellite systems (GNSS) that USVs rely on, such as spoofing, jamming, and meaconing attacks. The document proposes using STAMP (Systems-Theoretic Accident Model and Processes) and STPA (Systems-Theoretic Process Analysis) techniques to analyze hazards and develop safety constraints to mitigate risks from insecure navigation aids. Preliminary analysis identifies potential accidents from an unavailable navigation module, unauthorized disclosure of GNSS data, or receiving non-genuine GNSS information. Next steps include further modeling USV control processing of GNSS data in ST

1. Securing Navigation of
Unmanned Maritime
Systems
Tope Omitola, Jon Downes,
Gary Wills, Mark Zwolinski,
Michael Butler
1

2. Motivation
• USV Autonomy - Navigation Aids for Safety and
Awareness
• Autonomous USVs must avoid ships, docks, floating
debris
• Secure navigation aids - to avoid obstacles
• Secure navigation aids - for situational awareness
• Question we address in this paper: “The Assurance
of security of autonomous navigation and
control in Maritime systems, and USVs in
particular”
• Preliminary work reported, more work is being done in
the area
• Secure navigation aids Key to Situational Awareness

3. Unmanned Surface Vehicles
and Autonomy
• USVs are maritime-based surface vehicles that have different levels of
autonomy
• 6 levels of Autonomy*:
– Level 0: Manned
– Level 1: Under Operator control
– Level 2: Under Directed control of Operator
– Level 3: Delegated; Control is from USV,
Decision-making shared between Operator and USV
– Level 4: Monitored; USV senses
environment. Operator may monitor events
– Level 5: Autonomous; USV senses and reports state of environment, Operator may
monitor events
* Maritime UK. "Being a responsible industry - an industry code of
practice" 2017 Report
3

4. USV Navigation Vulnerabilities and
Possible Hazards
• Global Navigation Satellite Systems (GNSS), e.g. GPS, GLONASS, COMPASS,
GALILEO
• Vulnerabilities
– Very weak signals (-160dB W)
– Signals not encrypted
– Unintentional and Intentional Interference
• Possible Hazards
– Complete failure of USV's GNSS receiver
– Presentation of hazardously misleading navigation data
• Possible Attacks
– Spoofing: broadcast of false signals
– Jamming: intentional interference of signals
– Meaconing: intentional interference & rebroadcasting
signals to confuse
4

5. Security and Hazard Analyses of
the Navigation Component of USVs
• Hazard Analysis important for certifying systems safety
• Traditional Techniques, e.g. HAZOP, FTA, only focus on single
component’s failures and failure events
• Cyber-Physical Systems, such as USVs, have inter-component
interactions, failures and failure events
• We use STAMP and STPA for security and hazard analyses.
• Developed at MIT, both have good track records in inter-component
safety and hazard analyses
• In STPA, failure events, and Accidents, are caused by safety
constraints not successfully enforced
5

6. STAMP’s four components of Controller, the Controlled entity,
Actuators and Sensors
6

7. STAMP’s 4 possible causes
of Accidents
• A control action required for safety was not provided
• An unsafe control action was provided
• A control action required for safety was provided too
early or too late or in the wrong sequence
• A control action required for safety was stopped too
soon or applied too long
7

8. (Some of Possible) Accidents
and Hazards Analyses of Navigation Component
ACCIDENTS HAZARDS
A1. Unavailability of Navigation Module (NM) H1.1 NM receives continuous stream of un-
usable GNSS signals via a jamming attack
H1.2 Malevolent manipulation of hardware
and software layers of NM to alter GNSS data
interpretation
A2. Un-authorised disclosure of GNSS
information
H2. There is un-authorised disclosure of
GNSS information
A3. Received GNSS information are not
genuine
H3.1 GNSS information have been
intentionally altered via a spoofing attack
H3.2 NM receives replayed GNSS signals via
a meaconing attack
H3.3 GNSS information have been un-
intentionally altered (probably due to natural
accident)
A4. Users' Psychological Error H4. Over-reliance of users on provided GNSS
data
A5. Unintentional Radio Frequency (RF)
interference
H6. Noise from nearby RF transmitters
interferes with genuine GNSS signals
8

9. STPA Methodology
9
Control Actions Not Providing Causes Hazard Providing
Causes
Hazard
Wrong Time or
Wrong Order
Causes Hazard
Stopped Too Soon
or Applied Too
Long
NM assures
authenticity of
its software &
hardware
components
UCA1: Malevolent components
installed in NM [H1.2]; UCA2: Unauthorised
principals able to alter GNSS data
interpretation [H1.2, H2, H3.2]
None Same as UCA1 &
UCA2
Same as UCA1 &
UCA2 (Stopped
Too Soon)
NM mitigates
jamming attack
UCA3: Denial of Service attack (of NSS data)
[H1.1, H5]
None Same as UCA3 Same as UCA3
(Stopped Too Soon)
NM provides au-
thorised disclo-
sure of GNSS data
UCA4: Un-authorised entities able
to elicit USV position (information leakage)
and/or able to replay
GNSS information (traffic analyses).
Possibility of taking control of USV &
sabotage mission [H2, H3.1, H3.2]
UCA5: Tampering, i.e., deliberately
destroying or corrupting data [H2, H5]
None Same as UCA4 Same as UCA4
(Stopped Too Soon)

10. Next Steps and Future Work
• Very preliminary investigation of STPA to CPS Autonomy -
Fruitful area of work
• How can we include USV control algorithm processing GNSS data
in STAMP/STPA
• Taxonomy/Hierarchy of Hazards and Risks
• Constructing Safety Constraints to mitigate or stop unsafe control
actions
• Use Event-B to model control actions and safety constraints to
develop framework for security analysis for autonomous
navigation of unmanned marine systems
– Event-B is a formal method for software system design that
provides strong support for rigorous verification using
mathematical techniques
10

11. QUESTIONS
• t.omitola@ecs.soton.ac.uk
11