Abstract. The increased connectivity of critical maritime infrastructure (CMI) systems to digital components and networks have raised concerns of their vulnerability to cyber attacks. Helping to mitigate or inhibit these cyber attacks will require the design and engineering of secure systems. Systems theory has been shown to provide the foundation for a disciplined approach to engineering trustworthy secure cyber-physical systems. In this paper, we use systems theory, and concepts adapted from safety analysis, to develop a systematic mechanism for analysing the security functionalities of assets' interactions in the maritime domain.We use the theory to guide us to discern the system's purpose, likely system losses, potential threats, and to construct system constraints needed to inhibit or mitigate these threats. We also use the theory to develop a trade-o and risk analytic technique applicable for risk assessment and mitigation. As with system safety, security should be built in to systems design rather than added on at the end of development. Our analyses can be used as springboards to a set of principles that help to enunciate the assumptions and system-level security requirements useful as the bases for systems' security validation and verification.

1. Making (Implicit) Security
Requirements Explicit for
Cyber-Physical Systems:
A Maritime Use Case
Security Analysis
Tope Omitola,
Abdolbaghi Rezazadeh,
Michael Butler
1
Presented at the 3rd International Workshop on
Cyber-Security and Functional Safety in Cyber-
Physical Systems (IWCFS 2019), Linz, Austria, August
26 - 29, 2019

2. CONTENT
• Importance of Software Requirements
• Critical Maritime Infrastructure (CMI)
• Security Requirements Analysis for CMI
• System Theoretic Process Analysis (STPA) for Safety
Requirements Analysis
• STPA for Security Requirements Analysis
• STPA for CMI Security Requirements Analysis
• Conclusions
2

3. Importance of
Software Requirements
•System Requirements
are very important
•“Blueprints” everyone on
project works from
3

4. Reason for
Software
Project Failure
• “Unclear Requirements” –
Top 3 or 4 reason why
projects fail –(Standish
Group & Software
Engineering Institute)
• Why “Unclear
Requirements” – One
reason - Implicit
Knowledge NOT made
Explicit Enough 4

5. Requirements Analysis is
Critical to the Success or
Failure of a Project
• Question - How to make the
Requirements Gathering
Explicit Enough
• Requirements analysis
usually done iteratively with
many delicate social and
other trade-offs involved
5

6. CRITICAL MARITIME
INFRASTRUCTURE
(CMI)
• Maritime is V. BIG business
(80% Global Trade)
• Important to Global
Transport and Supply Chains
• Maritime Infrastructure Is
Increasingly Networked
Together (Ships, On-Shore
Based Bridge, Controller)
6

7. CRITICAL MARITIME
INFRASTRUCTURE (CMI)
-- CYBER-THREATS
• Increased Networking
Brings Increased Risk of
Cyber-Threats
• Getting Security
Requirements Right Are
Important First Steps in
Securing CMI
7

8. SOME RELATED WORK IN
SECURITY
REQUIREMENTS ANALYSIS
• THROP: Fault-error-failure
chain model of single
component
• THROP: NOT useful for inter-
connected systems (e.g. CPS)
• STRIDE: Threat-centric
approach. Good approach to
Focus on Threats
• STRIDE: Focuses on Software
Systems – NOT useful for CPS
(H/W + S/W)
8

9. APPLYING STPA TO
SECURITY
REQUIREMENTS
ANALYSIS
• System Theoretic
Process Analysis focuses
on inter-connected
components (H/W &
S/W)
• Useful for CPS
• Usually Applied to
Safety Requirements
9

10. STPA -
Concepts
• Safety Constraints
• A Hierarchical Safety
Control Structure
• Process Models 10

11. THE SEVEN STEPS OF STPA
• State System Purpose
• Identify accidents
• Identify system hazards associated
with accidents
• Construct high-level control
structure
• Translate system hazards to high-
level safety requirements
• Identify Unsafe Control Actions
• Use Results to Create/Improve
Design
11

12. STPA – Applied to Security
STPA – SAFETY STPA - SECURITY
State System Purpose State System Purpose
Identify Accidents Identify System Losses
Identify System Hazards Identify System Threats
Construct Control Structure Construct Control Structure
Translate Hazards into Safety
Requirements
Translate Threats to Security
Constraints
Identify Unsafe Control Actions Identify Insecure Actions
Use Results to Create Design Use Results to Create/Improve
Design 12

13. SYSTEM PURPOSE – MARITIME
COMMS SYSTEM (MNS)
• This may require a few iterations
• “The Provision of Timely, Confidential,
Correct Communication of Navigation
Data, Acknowledgements and Route
Updates between Controller and Ship”
13

14. IDENTIFY SYSTEM LOSSES
Loss (from CS’s perspective) Loss (from Ship’s perspective)
L1: Not receiving ship location
data (affects data
provisioning)
L5: Not receiving navigation data from CS (affects
data provisioning)
L2: Receiving incorrect ship
location data (affects data
correctness)
L6: Receiving incorrect navigation data from CS
(affects data correctness)
L3: Receiving ship location
data v. late (affects timeliness)
L7: Receiving navigation data v. late (affects
timeliness)
L4: Unauthorised agent read
ship location data (affects data
L8: Unauthorised agent read navigation data
(affects data confidentiality) 14

15. IDENTIFY SYSTEM THREATS
Threats Threats
T1 Message
Congestion
T2
Interference
T3 Tampering T4 Injection Attack
T5 Replay Attack T6 Relay Attack
T7 Identity Spoofing T8 Loss of
Communications
Infrastructure
T9 Denial of Service T10 Traffic Analysis
T11 Eaves-dropping 15

16. CONTROL
STRUCTURE
• What are the main components
• What Role does each play
• What are command actions being used to interact

17. TRANSLATE
THREATS TO
SECURITY
CONSTRAINTS
(Some Example
Constraints)
What constraints need to be in place to prevent threat
conditions from occurring?
Threat System Constraint
T1 Message
Congestion
SC1 The system shall be able to prove the
identity of agents during long, probably
intermittent, transactions
T2 Interference SC2 The system shall guarantee against
communication interference between CS
and Ship
T4 Injection Attack SC4 The system shall maintain strong
mutual continuous authentication, of CS
and Ship, during all operations'
transactions
17

18. IDENTIFY (SECURE) AND INSECURE ACTIONS
Malicious Control
Action
Not Providing
Exposes Threats
Providing
Exposes
Threats
Wrong Time or
Wrong Order
Exposes Threats
Stopped
Too Soon
or
Applied
Too Long
Exposes
Threats
Address Resolution
Protocol spoofing
None UCA1. IS, T,
RPA, RLA, IA
As in UCA1 As in UCA1
IP spoofing None As in UCA1 As in UCA1 As in UCA1
Packet Tampering None As in UCA1 As in UCA1 As in UCA1
Eavesdropping None UCA2. Eavesdropping. As in UCA2 As in UCA2
Traffic Analysis
command
None UCA3. Traffic Analysis As in UCA3 As in UCA3
(T: Tampering, I: Interference, IA: Injection Attack, RPA: Replay Attack, RLA: Relay Attack,
IS: Identity Spoofing, DoS: DoS Attack, TA: Traffic Analysis, E: Eavesdropping).
18

19. (Possible) Mitigation Strategies and Techniques –
To Improve System Design
Threat Type Loss Link Mitigation Strategy Mitigation Technique
Identity spoofing L4, L8
(Confidentiality)
Crypto https/ssl
Tampering L2, L6
(Integrity)
Crypto ipsec, ssl
Traffic Analysis L4, L8
(Confidentiality)
Packet padding Message
Encryption
DoS L1, L3, L5, L7
(Availability)
Watch out for
Resource
exhaustion
Network provisioning
using access control lists
19

20. Systematic Security Analysis and System Trade-offs
• Can be used for design trade-offs & to relax system
purpose.
• System’s new purpose: “the provision of timely and
correct communication of navigation data,
acknowledgements and route updates, between SBB
and Ship". (Here, data confidentiality requirement
removed).
• Allows us to reduce system losses of interest, reduce
system threats of interest, system constraints, etc.
20

21. Systematic Security Analysis and System Trade-offs
Purpose Losses Threats Constraints Mit. Strg. Mit. Tech.
Provision of
timely &
correct
communi-
cation
of nav.
data,acks &
updates
between CS
& Ship
L1,
L2,
L3,
L5,
L6,
L7
T1,
T2,
T3,
T4,
T5,
T6,
T7,
T8,
T9
SC1,
SC2,
SC3,
SC4,
SC5,
SC6,
SC7,
SC8,
SC9
Crypt
ographic
& To
watch
out for
exhaustible
resources
(a)
HTTPS/SSL
,
IPSEC,
MACs &
(b) ACLs
HELPED US REMOVE LOSS 8 & THREAT 10; as a result of not including data
confidentiality in Requirement 21

22. SERIOUS THREATS TO CMI
22

23. CONCLUSIONS & FUTURE WORK
•Getting Security Requirements Right Is Very Important
•Systems Theory & Concepts from Safety Analyses (esp.
STPA) useful for security analysis of CMI
•STPA Systematic Approach (The 7 Steps) Can Help Elicit
System Purpose, Identify System Losses & Threats
•Can Help Derive System Constraints Useful To
Construct Mitigation Procedures
•Future Work: Use Event-B to Verify System Constraints
23

24. Questions
• Acknowledgement:
• Work conducted within the ENABLE-S3
project that has received funding from the
ECSEL Joint Undertaking under Grant
Agreement no. 692455.
24