Cybersecurity for security-critical infrastructure in the rail sector

1. Cybersecurityforsecurity-criticalinfrastructure in therailsector Prof. Dr. Stefan Katzenbeisser Technische Universität Darmstadt Security Engineering Group Source: AKABahn e.V. 1

2. Why care about IT security? Sources: http://www.nextgov.com/cybersecurity/2012/01/hackers-manipulated-railway-computers-tsa-memo-says/50498/ http://www.computerweekly.com/news/2240084537/Schoolboy-hacker-derails-Polands-tram-network http://www.express.co.uk/news/uk/688750/Terror-trains-Cyber-attacks-UK-railways-ISIS-hacking 2

3. Last year in Frankfurt… Source: Twitter 3

4. Why care about IT security? • Traditional: focus on safety and not on security • Traditional assumption: closed & proprietary systems(no connections to “outside”, trusted users) • Use of commercial off-the-shelf products(lots of bugs, well-understood) • Presence of active attackers, cannot be dealt with by probabilistic techniques • „Security for Safety“ necessary 4

5. Safetyand Security „security“ (Sicherheit) • Protection against active attacks... • ... who want to cause harm • „Intelligent“ attackers, look for weakest spot in the system • Norms: ISO 2700x, BSI Grundschutz, ... „safety“ (Zuverlässigkeit) • Protection against errors • Errors caused inside the system • Probabilistic techniques • Testing / verification • Norms: EN 50126, EN 50128, EN 50129, ... 5

6. Howcanattackerspenetrate a system? • Attackers can compromise systems using different ways (attack vectors) • Attackers do not have to know the system to break it! sidechannelattacks bufferoverflows /errors in software modchips weakcryptography Sources: Wikimedia, CASED 6

7. Security Engineering: Best Practices „Security is a process, not a product.“ − Bruce Schneier • No „universal“ methodology • „Security Engineering“ consists of the following steps: • Definition of attacker models, identification of assets • Risk management, identification of security measures • „security aware design“ • secure implementation • strategy for support, updates and decommissioning 7

8. Security aware design:system life-cycle • Secure design requirements technical protection processes secure engineering • Secure installation • Secure operation security management! need to fit railway operations rules • Secure disposal 8

9. Security aware design: reacting to a critical incident • It is unrealistic that a system is 100% secure very different to safety case! • Long-term secure operation • Detection of attacks how to handle false positives? • Recovery / Patching safety certification? 9

10. DIN VDE V 0831-104 • Draft standard for IT security in railway signaling systems • Consortium: BSI, DB Netz, EBA, Rohde & Schwarz, SBB, Siemens, Thales, TU Darmstadt, TU Dresden, TÜV • Adaptation of a norm for security in industrial control systems (IEC 62443) to the railway sector • Focus on „security for safety“ • Integration of security aspects into the safety certification process 10

11. Future demand:Resilience (1) Resilience of an information system in relation to cybersecurity is characterized by the following abilities: • The system and the organization shall be prepared for adverse conditions or stress • The system shall operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential functions • The system shall recover to a defined operational state in an acceptable time frame NIST Security and Privacy Controls for Federal Information Systems and Organizations, 2013 11

12. Future demand:Resilience (2) 100% Safe Operation Functionality Non-Safe Operation Source: “Resilience: Theory and Applications”, ANL/DIS-12-1, 2012 Forced to shut down critical safety limit 0% 12

13. CYSIS – Cybersecurity for Safety-Critical Infrastructures • CYSISis an open interdisciplinary working group, founded in 2016 between Deutsche Bahn and TU Darmstadt/CYSEC, to meet the rising challenges on IT security in the railway sector • Main objective of CYSIS is to improve IT security for safety critical railway infrastructures, especially for Control-Command and Signallingsystems, vehicles, energy and telecommunication • CYSISworking groups on: • Resilient Infrastructures • Business Continuity Management • ETCS and Security • Security for Safety 13

14. RecommendationsofCYSIS Recommendations on the implementation of resilient architectures in several domains: • Communication system • Core signalling system • Recovery • Asset and configuration management 14

15. RecommendationsofCYSIS, Examples (1) • Data filtering • Data filtering measures shall be included in the network design, especially in conduits1 between zones of different level of importance. • A failure of the data filter function shall be disclosed and notified immediately. • A violation of security rules shall be notified immediately. • The concept of whitelisting shall be used. • Runtime checks of system integrity • Code, configuration and the integrity of the system or component shall be verifiable (testable) during runtime, even when the system is compromised. • Verification ofintegrity to third parties • The results of runtime checks shall be provided for external assessment. • A process shall be defined to perform runtime checks on a regular basis. • Logging of critical events • Critical events shall be logged. • The integrity of the logged data shall be ensured. 15

16. RecommendationsofCYSIS, Examples (2) • End-to-End protection of the communication (Protect1) • Integrity and authenticity of the transmitted data shall be ensured, especially in open networks. Remark: Confidentiality is in general not a main objective for Control-Command and Signalling systems. • Adaptability (Identify) • The adaptation of IT configurations (e.g., adjustments, patches/updates, substitution of methods) in safety systems shall not lead to a new regulatory approval or certification process. • When using commercial off-the-shelf systems it shall be possible to tailor the system for its specific application (Hardening). • Data aggregation and reaction (Identify, Detect, Recover) • Data about the system status and the related network shall be aggregated and transmitted to a centralized position for further investigations. • A process shall be defined how to react to anomalies. 16

17. Security architectures forsignalling applications (1) Security-Functions Safety-Functions German national researchproject “HASELNUSS”(DB Netz, TUDA, FhG SIT,SYSGO, MEN) Key features: • Multiple Independent Levels of Security (MILS)architecture, Separation kernel • Trusted Platform Module, Trusted Software Stack, Remote Attestation • Anomaly Detection SIL4 Object Controller Partition/ Compartment Health Monitor Network IDS FW/Data Filter Security Kernel Security Monitor Secure Boot Secure Update TPM Software Stack (TSS) 2.0 Hardware Platform TPM2.0 I/F-1 I/F-2 I/F-3 Eth Bus Eth Bus

18. Security architectures forsignalling applications (2) • MILS: supports the coexistence of untrusted and trusted components, based on verifiable separation mechanisms and controlled information flow. • Enables modularized evaluation and certification of a complex system. • Allows the security critical part of system to be certified to high assurance levels. • Separation kernel: separation of applications, information flow control. SIL4 Safety Application (Object Controller) Security Apps 2 (IDS, Health Mon, Remote Attestation) Security App 1 (Firewall) Application plane

19. Operationsaspects Are there clever novel ways to resume safe operations? Detection is hard! Consider false positives! Can/shall we always shut down? Source: CYSIS 19

20. Conclusions • Railway signaling systems become more and more complex. • Currently: focus on „safety“ • Future: „security“ important • New risks emerge: GSM-R, insider threats, Stuxnet, ... • Constant dialogue with the security community necessary • Operational rules need to be aligned with technical measures Source: AkaBahn e.V. 20