Cybersecurity for securitycritical infrastructure in the rail sector
Cybersecurity for security-critical infrastructure in the rail sector Prof. Dr. Stefan Katzenbeisser Technische Universität Darmstadt Security Engineering Group Source: AKABahn e. V.
Why care about IT security? 2 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
Last year in Frankfurt… 3 Source: Twitter
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
Safety and Security „security“ (Sicherheit) § § 5 Protection against active attacks. . . who want to cause harm „Intelligent“ attackers, look for weakest spot in the system Norms: ISO 2700 x, BSI Grundschutz, . . . „safety“ (Zuverlässigkeit) § § Protection against errors Errors caused inside the system § Probabilistic techniques § Testing / verification § Norms: EN 50126, EN 50128, EN 50129, . . .
How can attackers penetrate a system? § Attackers can compromise systems using different ways (attack vectors) § Attackers do not have to know the system to break it! buffer overflows / errors in software side channel attacks mod chips weak cryptography 6 Sources: Wikimedia, CASED
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
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
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
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
Future demand: Resilience (1) Resilience of an information system in relation to cybersecurity is characterized by the following abilities: a) The system and the organization shall be prepared for adverse conditions or stress b) The system shall operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential functions c) 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
Future demand: Resilience (2) 100% Functionality Safe Operation Forced to shut down critical safety limit 0% 12 Source: “Resilience: Theory and Applications”, ANL/DIS-12 -1, 2012 Non-Safe Operation
CYSIS – Cybersecurity for Safety-Critical Infrastructures § CYSIS is 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 Signalling systems, vehicles, energy and telecommunication § 13 CYSIS working groups on: § Resilient Infrastructures § Business Continuity Management § ETCS and Security § Security for Safety
Recommendations of CYSIS Recommendations on the implementation of resilient architectures in several domains: § § 14 Communication system Core signalling system Recovery Asset and configuration management
Recommendations of CYSIS, Examples (1) § Data filtering - Data filtering measures shall be included in the network design, especially in conduits 1 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 of integrity 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
Recommendations of CYSIS, Examples (2) § End-to-End protection of the communication (Protect 1) - 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 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
Security architectures for signalling applications (1) Secure Boot Secure Update Partition/ Compartment SIL 4 Object Controller Network IDS Safety-Functions FW/Data Filter Key features: § Multiple Independent Levels of Security (MILS) architecture, Separation kernel § Trusted Platform Module, Trusted Software Stack, Remote Attestation § Anomaly Detection Security-Functions Health Monitor German national research project “HASELNUSS” (DB Netz, TUDA, Fh. G SIT, SYSGO, MEN) Security Kernel Security Monitor TPM Software Stack (TSS) 2. 0 Hardware Platform TPM 2. 0 I/F-1 I/F-2 I/F-3 Eth Bus
Security architectures for signalling 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. Security Apps 2 (IDS, Health Mon, Remote Attestation) Application plane Security App 1 (Firewall) SIL 4 Safety Application (Object Controller)
Operations aspects Detection is hard! Consider false positives! 19 Can/shall we always shut down? Are there clever novel ways to resume safe operations? Source: CYSIS
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 20 Source: Aka. Bahn e. V.
- Slides: 20