Making (Implicit) Security Requirements Explicit for Cyber-Physical Systems: A Maritime Use Case Security Analysis
- 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