OPC Is Dead - Let's Hide It in a SOA - Risiken der Serviceorientierten Automatisierung - BSI
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
14. IT-SICHERHEITSKONGRESS 2015
OPC Is Dead – Let’s Hide It in a SOA
Risiken der Serviceorientierten Automatisierung
David Fuhr, HiSolutions AG
1
© HiSolutions 2015 | Präsentation v1.2
AGENDA
1 OPC, uh, ah! – Was ist das?
2 SOA What? – Hype Cycle Victims
3 1001 Seite Spaß: Anatomie eines Standards
4 Beware! Mögliche Gefährdungen
5 Aller schlechten Dinge sind vier:
Schwachstellen / Risiken
6 Ausblick und Empfehlungen
2
© HiSolutions 2015 | Präsentation
OPC UA?
OLE
(Object
„Eine in den 80er Jahren erdachte proprietäre
Linking & Microsoft Windows-Technologie, die eigentlich dafür
Embedding) gemacht war, vor der Erfindung des WWW Word-
for Dokumente in PowerPoint-Dokumente zu packen,
dann aber dafür ‚verwendet‘ wurde, Industrieanlagen
Process zu steuern und im neuen Jahrtausend als Webservice-
Control Technologie neu erfunden wurde.“
Unified
Architecture
3
© HiSolutions 2015 | Präsentation
Protokoll für Industrie 4.0
Quelle: Umsetzungsempfehlungen für das
Zuk unftsprojekt Industrie 4.0, Abschlussbericht
des Arbeitskreises Industrie 4.0, April 2013
4
© HiSolutions 2015 | Präsentation
Vorbild: SOA
Quelle: Umsetzungsempfehlungen für das
Zuk unftsprojekt Industrie 4.0, Abschlussbericht
des Arbeitskreises Industrie 4.0, April 2013
5
© HiSolutions 2015 | PräsentationSOA: Hype and Prejudice
„Alle großen weltgeschichtlichen Tatsachen ereignen sich zweimal“
Georg Wilhelm Friedrich Hegel
„Er hat vergessen hinzuzufügen: das eine Mal
als große Tragödie, das andre Mal als lumpige Farce.“
Karl Marx
6
© HiSolutions 2015 | PräsentationSOA Hype Cycle
2003
„time to plateau“: immer „2-5 Jahre“
2004
2009
2008
2007
2005
2006 2010…
7
© HiSolutions 2015 | PräsentationDer Multi-Part-Standard OPC UA
OPC UA, Release 1.02 , 2012/2013
8
© HiSolutions 2015 | PräsentationSecurity in OPC UA
Legende:
Rahmenvorgaben
(nicht normativ)
Sicherheitskonzept
Security-Vorgaben
und -Parameter
Anwendungsspez.
Security-Relevanz
Zukünftige
Security-Relevanz
OPC UA, Release 1.02 , 2012/2013
9
© HiSolutions 2015 | Präsentation10
0
20
80
40
60
120
140
180
100
160
200
1
Overview and Concepts
2
Security Model
3
Address Space Model
4
Services
5
Information Model
6
Mappings
UMFANG: GUT 1000 SEITEN
7
Profiles
8
Data Access
9
Alarms and Conditions
10
Programs
11
Historical Access
12
(Discovery)
13
Aggregates
OPC UA, Release 1.02 , 2012/2013
© HiSolutions 2015 | Präsentation11
0
20
80
40
60
120
140
180
100
160
200
1
Overview and Concepts
2
Security Model
3
Address Space Model
4
Services
5
Information Model
6
Mappings
7
Profiles
8
Data Access
9
Alarms and Conditions
10
Programs
11
Historical Access
12
(Discovery)
13
Aggregates
IM ENGEREN SINN SICHERHEITSRELEVANT: CA. 450 S.
OPC UA, Release 1.02 , 2012/2013
© HiSolutions 2015 | PräsentationQUANTITATIVE EINORDNUNG
BSI-Standard 100-3 23
ISO/IEC 27001:2013 32
ISO/IEC 27001:2005 42
ISO/IEC 27002:2013 90
TLS 1.2 (RFC 5246) 93
BSI-Standard 100-2 95
ISO/IEC 27002:2005 136
OPC UA Release 1.02 1008
Der Herr der Ringe 1008
HTML 5 (WHAT WG) 1156
Die Bibel 1460
IT-Grundschutz-Kataloge 12. EL 2011 4068
IT-Grundschutz-Kataloge 14. EL 2014 4883
1 2 4 8 16 32 64 128 256 512 1024 2048 4096
Logarithmische Skala!
12
© HiSolutions 2015 | PräsentationGefundene Schwachstellen (Kritikalität aufsteigend)
1. Gut gemeint: Part 2, das „Sicherheitsmodell“ von OPC UA
2. You don‘t measure what you don‘t measure: „Security Levels“ in OPC UA
3. Hauptsache verschlüsselt: TLS != TLS
4. Kein Bock auf Gärtner: Baumartige Abhängigkeiten in der Architektur
13
© HiSolutions 2015 | Präsentation1. Gut gemeint: Das Sicherheitsmodell von OPC UA
Part 2 „Security Model“:
Sicherheitskonzept von OPC UA
14
© HiSolutions 2015 | PräsentationPart 2: Security Model
1 Scope 4.3.2 Message Flooding
2 Reference documents 4.3.3 Eavesdropping
3 Terms, definitions, and abbreviations 4.3.4 Message Spoofing
4 OPC UA Security architecture 4.3.5 Message Alteration
4.1 OPC UA Security Environment 4.3.6 Message Replay
4.2 Security Objectives 4.3.7 Malformed Messages
4.2.1 Overview 4.3.8 Server Profiling
4.2.2 Authentication 4.3.9 Session Hijacking
4.2.3 Authorization 4.3.10 Rogue Server
4.2.4 Confidentiality 4.3.11 Compromising User Credentials
4.2.5 Integrity 4.4 – 4.12: Architekturprinzipien […]
4.2.6 Auditability 5 Security Reconciliation
4.2.7 Availability 5.1 Reconciliation of Threats with Security Mechanisms
4.3 Security Threats to OPC UA Systems 5.2 Reconciliation of Objectives w. Security Mechanisms
4.3.1 Overview 6 Implementation and Deployment considerations
15
© HiSolutions 2015 | PräsentationPart 2: Security Model – Security Reconciliation
1 Scope 4.3.2 Message Flooding
2 Reference documents 4.3.3 Eavesdropping
3 Terms, definitions, and abbreviations 4.3.4 Message Spoofing
4 OPC UA Security architecture 4.3.5 Message Alteration
4.1 OPC UA Security Environment 4.3.6 Message Replay
4.2 Security Objectives 4.3.7 Malformed Messages
4.2.1 Overview 4.3.8 Server Profiling
4.2.2 Authentication 4.3.9 Session Hijacking
4.2.3 Authorization 4.3.10 Rogue Server
4.2.4 Confidentiality 4.3.11 Compromising User Credentials
4.2.5 Integrity 4.4 – 4.12: Architekturprinzipien […]
4.2.6 Auditability 5 Security Reconciliation
4.2.7 Availability 5.1 Reconciliation of Threats with Security Mechanisms
4.3 Security Threats to OPC UA Systems 5.2 Reconciliation of Objectives w. Security Mechanisms
4.3.1 Overview 6 Implementation and Deployment considerations
16
© HiSolutions 2015 | PräsentationReconciliation of Threats: „Risikoanalyse“
17
© HiSolutions 2015 | PräsentationSecurity Reconciliation – Beispiel: Message Spoofing
1 Scope 4.3.3 Eavesdropping
2 Reference documents 4.3.4 Message Spoofing
3 Terms, definitions, and abbreviations 4.3.5 Message Alteration
4 OPC UA Security architecture 4.3.6 Message Replay
4.1 OPC UA Security Environment 4.3.7 Malformed Messages
4.2 Security Objectives 4.3.8 Server Profiling
4.2.1 Overview 4.3.9 Session Hijacking
4.2.2 Authentication 4.3.10 Rogue Server
4.2.3 Authorization 4.3.11 Compromising User Credentials
4.2.4 Confidentiality 4.4 – 4.12: Architekturprinzipien […]
4.2.5 Integrity 5 Security Reconciliation
4.2.6 Auditability 5.1 Reconciliation of Threats with Security Mechanisms
4.2.7 Availability 5.1.4 Message Spoofing
4.3 Security Threats to OPC UA Systems 5.2 Reconciliation of Objectives w. Security Mechanisms
4.3.1 Overview 6 Implementation and Deployment considerations
4.3.2 Message Flooding
18
© HiSolutions 2015 | PräsentationSecurity Reconciliation: Message Spoofing
4.3 Threats
5.1 Reconciliation of Threats with OPC UA Security Mechanisms
OPC UA Part 2: Security Model,
Release 1.02 , 2013
19
© HiSolutions 2015 | PräsentationSecurity Reconciliation: Eavesdropping (Abhören)
4.3 Threats
5.1 Reconciliation of Threats with OPC UA Security Mechanisms
OPC UA Part 2: Security Model,
Release 1.02 , 2013
20
© HiSolutions 2015 | PräsentationRisiko Eavesdropping (Abhören)
„OPC UA bietet Verschlüsselung an“ ist nicht ausreichend als Beschreibung
der Maßnahme gegen die Gefährdung „Abhören“
Zusätzlich ist mindestens festzulegen:
Was ist wann zu verschlüsseln? (Und was nicht?)
Mit welchen Verfahren und Parametern?
Wie wird mit Herausforderungen umgegangen?
Schlüsselmanagement (Verteilung, Lifecycle, Skalierbarkeit)
Teilweise Inkompatibilität mit anderen Maßnahmen (etwa Virenschutz)
Bedrohung der Verfügbarkeit durch Verschlüsselung
Notfallplanung
21
© HiSolutions 2015 | PräsentationReconciliation of Objectives
1 Scope
2 Reference documents
3 Terms, definitions, and abbreviations
4 OPC UA Security architecture 5 Security Reconciliation
4.1 OPC UA Security Environment 5.1 Reconciliation of Threats with Security Mechanisms
4.2 Security Objectives 5.2 Reconciliation of Objectives w. Security Mechanisms
4.2.1 Overview 5.2.1 Overview
4.2.2 Authentication 5.2.2 Authentication
4.2.3 Authorization 5.2.3 Authorization
4.2.4 Confidentiality 5.2.4 Confidentiality
4.2.5 Integrity 5.2.5 Integrity
4.2.6 Auditability 5.2.6 Auditability
4.2.7 Availability 5.2.7 Availability
4.3 Security Threats to OPC UA Systems 6 Implementation and Deployment considerations
4.4 – 4.12: Architekturprinzipien […]
22
© HiSolutions 2015 | PräsentationReconciliation of Objectives
OPC UA Part 2: Security Model,
Release 1.02 , 2013
23
© HiSolutions 2015 | PräsentationReconciliation of Objectives
5.2 Reconciliation of Objectives with OPC UA Security Mechanisms
OPC UA Part 2: Security Model,
Release 1.02 , 2013
24
© HiSolutions 2015 | PräsentationReconciliation of Objectives
5.2 Reconciliation of Objectives with OPC UA Security Mechanisms
OPC UA Part 2: Security Model,
Release 1.02 , 2013
25
© HiSolutions 2015 | PräsentationSecurity Reconciliation als verkürzte Risikoanalyse?
Löblich für einen Standard, derart ausführliche Security Considerations
auszuführen
Zusätzlich mindestens notwendig: Untersuchung der
Vollständigkeit der genannten Gefährdungen,
Vollständigkeit der Gegenmaßnahmen sowie
deren ausreichender Stärke.
Kann keine systematische Risikoanalyse ersetzen!
26
© HiSolutions 2015 | Präsentation2. Security Levels: You don‘t measure what you don‘t
measure, oder: Zahlen sind gut!
27
© HiSolutions 2015 | Präsentation„Security Levels“ in OPC UA
Security Levels „1“ bis „3“ werden in Part 7: Profiles
als sog. Conformance Units (CU) verwendet:
Die Beschreibung der CUs SL1-3 ist identisch(!)
Trotz absoluter Zahlen: Keine eigene inhaltliche Bedeutung.
OPC UA Part 7: Profiles,
Release 1.02 , 2012
28
© HiSolutions 2015 | PräsentationSecurity Levels in Part 7: Profiles
OPC UA Part 7: Profiles,
Release 1.02 , 2012
29
© HiSolutions 2015 | PräsentationProbleme derartiger Security Levels
Implizite Labels ohne eigenen Inhaltsbeitrag kann man machen, aber:
1. Gefahr der Verabsolutierung („Security Level 3? Ist doch sehr gut!“)
2. Gefahr der Annahme eines eigenen Beitrags („Schalt‘ einfach noch SL3 an!“)
(dies muss bei Zusammenstellung der Profile nichttrivial beachtet werden)
3. Problem des sinnvollen Matchings einer 1-dimensionalen Skala auf
komplexere Parameter (Ist TLS 1.0 mit MD5 besser oder schlechter
als SSL 3.0 mit SHA1?)
Sicherheitsanforderungen und Risikoanalyse treten in den Hintergrund
30
© HiSolutions 2015 | PräsentationInterlude: Gefährdungen für SOA
3.3.1 Vorsätzliche Handlungen/Angriffe 3.3.2 Organisatorische Mängel
Web Service Interface Probing Unzureichende Berücksichtigung von
Sicherheitsaspekten im SOA Design
Angriffe auf das XML Parsing System
Fehlende oder unzureichende Regelungen/keine
External Reference Attacks [XEE] klare Abgrenzung von Verantwortlichkeiten
SOAP Flooding Attack Fehlendes Notfallvorsorgekonzept/
Message Eavesdropping Sicherheitskonzept/Business Continuity Plan
Malicious Morphing/Message Tampering Unzureichendes Sicherheitsmanagement
Routing Detours 3.3.3 Menschliche Fehlhandlungen
Identity Spoofing Fehlendes Sicherheitsbewusstsein
XML Signature Element Wrapping Attack [XSW] (Awareness)/Verantwortungsbedürfnis/Kenntnis
Code Injection Attacks (SQLi, XPath-i, LDAPi, XSS) Falsche oder ungenügende Implementierungen/
Sicherheitskonfigurationen
Schadsoftware
Social Engineering
Schwachstellen in Backend-Anwendungen
3.3.4 Technisches Versagen
Brute-Force/Dictionary Attack
Fehlerhafte Hardware
Identity Service Spoofing
Fehlerhafte Protokolle/unsichere Algorithmen
Angriffe auf Registries/Repositories
3.3.5 Höhere Gewalt
Angriffe auf Protokolle („geerbte Bedrohungen“)
Naturkatastrophen
Kryptoanalyse
SOA Security Kompendium 2.0.1 (2009)
31
© HiSolutions 2015 | PräsentationGefährdungen für OPC UA
3.3.1 Vorsätzliche Handlungen/Angriffe Legende:
Web Service Interface Probing Nicht OPC UA-spezifisch
Angriffe auf das XML Parsing System Wird im Standard behandelt
External Reference Attacks [XEE] (Eher) implementierungsabhängig
SOAP Flooding Attack Nicht im Standard behandelt
Message Eavesdropping
Malicious Morphing/Message Tampering
Routing Detours
Identity (Service) Spoofing 3.3.3 Menschliche Fehlhandlungen
XML Signature Element Wrapping Attack [XSW]* Fehlendes Sicherheitsbewusstsein
(Awareness)/Verantwortungsbedürfnis/Kenntnis:
Code Injection Attacks (SQLi, XPath-i, LDAPi, XSS)* Falsche oder ungenügende Implementierungen/
Schadsoftware Sicherheitskonfigurationen
Schwachstellen in Backend-Anwendungen
Brute-Force/Dictionary Attack
Angriffe auf Registries/Repositories 3.3.4 Technisches Versagen
Angriffe auf Protokolle („geerbte Bedrohungen“) / Fehlerhafte Protokolle/unsichere Algorithmen
Kryptoanalyse
32
© HiSolutions 2015 | Präsentation3. Einsatz von TLS in OPC UA
X
OPC UA Part 6: Mappings,
Release 1.02 , 2012
33
© HiSolutions 2015 | PräsentationTLS in Profilen (Part 7)
1
keine Spezifizierung!
OPC UA Part 7: Profiles,
Release 1.02 , 2012
34
© HiSolutions 2015 | PräsentationGrund wohl: Beat the BEAST!
Conformance Unit „Security TLS 1.1“:
OPC UA Part 7: Profiles,
Release 1.02 , 2012
(Indirekte Begründung der Beschränkung für TLS 1.0 in der CU für TLS 1.1!?)
Aber: RC4 in TLS muss seit 2013 als gebrochen gelten (www.isg.rhul.ac.uk/tls)
Andererseits ist BEAST heute in allen wichtigen Browsern* „mitigated“…
35
© HiSolutions 2015 | PräsentationTLS 1.0 und 1.1 „nur zu Kompatibilitätszwecken“
*
*
OPC UA Part 7: Profiles,
Release 1.02 , 2012
36
© HiSolutions 2015 | PräsentationImmerhin sicher: TLS 1.2?
RFC 7525 / IETF BCP (Best Current Practice) 195, Mai 2015):
“To maximize interoperability, RFC 5246 mandates
implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher
suite, which is significantly weaker than the cipher suites
recommended here. Implementers should consider the
interoperability gain against the loss in security when
deploying this cipher suite.”
“Unfortunately, many TLS cipher suites were defined that do
not feature forward secrecy, e.g.,
TLS_RSA_WITH_AES_256_CBC_SHA256. This document therefore
advocates strict use of forward-secrecy-only ciphers.”
37
© HiSolutions 2015 | PräsentationGute Absichten sind vorhanden
Part 2: Security Model, 4.6 Security Policies:
In der Praxis geschieht das Update der Profile jedoch nur mit dem Standard:
Also zu selten (ca. alle drei Jahre). Und teilweise auch dann nicht, nicht explizit
oder nicht systematisch.
Und: Warum überhaupt genaue Vorgaben, wenn man dann doch woanders
nachlesen soll?
38
© HiSolutions 2015 | PräsentationSicherheit von TLS
RFC 7525 (Mai 2015) BSI TR-02102 (2014/2015) OPC UA (2012)
SSL (= SHA2 SHA2; für HMAC auch noch SHA1 / unspez. /
SHA1 erlaubt SHA2
Forward Secrecy STRICT empfohlen Nicht möglich
Weitere Vorgaben Keine null ciphers, Keine null ciphers (ind.), Keine Vorgaben für
SHOULD NOT Kompression, sichere oder keine TLS1.1! (u.a. null
sichere Renegotiation, keine Kompression, ciphers möglich)
HMAC-Verkürzung, sichere Renegotiation,
Schlüssellängen, kein Fallback keine HMAC-Verkürz., Keine weiteren
zu SSL, sichere Resumption, Schlüssellängen, Vorgaben
„Strict TLS“ (u.a. HSTS), Schlüsselspeicherung,
Risiken bei DH Exponent reuse Zufallszahlen
39
© HiSolutions 2015 | Präsentation4. Baumartige Abhängigkeiten in der Architektur
„Protocol Stapling“
40
© HiSolutions 2015 | PräsentationSicherheit von XML Encryption
XML Encryption „1.0“ (meist ohne Version): W3C Recommendation 2002
Gebrochen 2011:
“A number of chosen-ciphertext attacks against implementations of this
specification have been published and demonstrated. […]
Note: CBC block encryption algorithms should not be used without
consideration of possibly severe security risks.”
Gefixt: April 2013 mit XML Encryption 1.1
41
© HiSolutions 2015 | Präsentation„Protocol Stapling“
Um XML-Verschlüsselung in OPC UA zu „reparieren“:
1. XML Encryption 1.0 fixen DONE (1 ½ Jahre)
2. WS Security ändern, sodass auf XML Enc 1.1 verwiesen wird ca. 20142016
3. WS SecureConversation anpassen auf das neue WS-Security ca. 2017
4. OPC UA inkl. UA SecureConversation updaten ca. 2019
5. Produkte überarbeiten ca. 2021
6. Ankunft auf dem Markt. ca. 2025 †
42
© HiSolutions 2015 | PräsentationRelevanz der XML Enc-Schwachstelle in OPC UA
Aus zwei Gründen weniger schwerwiegend:
1. Webservice-Modus in OPC UA wird kaum genutzt (und evtl. mittelfristig entfernt)
2. Durch Encrypt-then-Sign bei korrekter Implementierung nur in Kombination mit
weiteren Schwachstellen (z. B. XSW) ausnutzbar
Grundsätzliches Problem des Protocol Stapling bleibt bestehen.
43
© HiSolutions 2015 | PräsentationEmpfehlungen
1. Explizitmachung aller Dependencies (immer mit Version*)
2. Konsistenz durch alle Teile (idealerweise an nur einer Stelle)
3. Modulare Umsetzung von Sicherheitsfunktionen in komplexen Standards –
insbesondere von Kryptographie
4. Auslagerung von „Querschnittsempfehlungen“: vgl. TR-02102
5. Zu diskutieren: Verpflichtung vs. Selbstverpflichtung zur Einhaltung?
6. Regelmäßige „Sicherheitsaudits“ von Dokumenten
Für letzteres notwendig: Entwicklung von Methoden und Tools, ähnlich wie in der
Softwareentwicklung bzw. bei technischen Audits.
* ggf. „und aufwärts“, „>=“, „bis zum Jahr x“, …
44
© HiSolutions 2015 | PräsentationOPC UA 1.03
Ende April 2015 einige Parts als Release Candidates erschienen
Stand für die Analyse noch nicht zur Verfügung
Keine Security Levels mehr (jetzt schon entfernt in den IEC-Versionen)
Alle WS-*-Referenzen entfernt
Forward Secrecy: „something we want to address in the future (most likely with
TLS 1.2 with DH)”
45
© HiSolutions 2015 | PräsentationBSI-Projekt OPC UA
Etwas später gestartet, unabhängig, wesentlich umfangreicher
Läuft noch bis Oktober 2015
Analyse der Spezifikation wurde gerade abgeschlossen
Nun Analyse der Referenzimplementierung (Referenzstack der OPC
Foundation ergänzt um einige weitere Komponenten)
Nach Abschluss Abstimmung mit OPC Foundation („Responsible Disclosure“)
2016 Veröffentlichung eines Teils der Ergebnisse
Schwerpunkt: Empfehlungen für Hersteller, Integratoren und Betreiber
Evtl.: auch Baustein für den neuen IT-Grundschutz
46
© HiSolutions 2015 | PräsentationAusblick
Diskussion mit der OPC Foundation und Herstellern, OPC UA 1.03
BSI: Vorstellung der Ergebnisse 2016
Offene Fragen:
• Komplexität der Standards noch beherrschbar?
• (Und was bedeutet dies für die Implementierungen?)
• Eher hin zu wenigeren, „flacheren“ Standardbäumen?
(z.B. IP/TCP/HTTP/REST)?
Vergleich mit IIC‘s MTConnect:
DACH Security, Hochschule Bonn-Rhein-Sieg, St. Augustin, September 2015
Herzliche Einladung!
47
© HiSolutions 2015 | Präsentation14. IT-SICHERHEITSKONGRESS 2015
HISOLUTIONS BEDANKT
SICH FÜR IHRE
AUFMERKSAMKEIT
HiSolutions AG
Bouchéstraße 12
12435 Berlin
info@hisolutions.com
www.hisolutions.com
+49 30 533 289-0
48
© HiSolutions 2015 | PräsentationSie können auch lesen
