David Fuhr - OPC is Dead

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
2
3
4
5
OPC, uh, ah! – Was ist das?
SOA What? – Hype Cycle Victims
1001 Seite Spaß: Anatomie eines Standards
Beware! Mögliche Gefährdungen
Aller schlechten Dinge sind vier:
Schwachstellen / Risiken
6 Ausblick und Empfehlungen
2
© HiSolutions 2015 | Präsentation
OPC UA?
 OLE
 (Object
 Linking &
 Embedding)
for
 Process
 Control
„Eine in den 80er Jahren erdachte proprietäre
Microsoft Windows-Technologie, die eigentlich dafür
gemacht war, vor der Erfindung des WWW WordDokumente in PowerPoint-Dokumente zu packen,
dann aber dafür ‚verwendet‘ wurde, Industrieanlagen
zu steuern und im neuen Jahrtausend als WebserviceTechnologie 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äsentation
SOA: 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äsentation
SOA Hype Cycle
2003
„time to plateau“: immer „2-5 Jahre“
2004
2009
2008
2007
2005
2006
7
2010…
© HiSolutions 2015 | Präsentation
Der Multi-Part-Standard OPC UA
OPC UA, Release 1.02 , 2012/2013
8
© HiSolutions 2015 | Präsentation
Security 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äsentation
10
Security Model
Address Space Model
Services
Information Model
Mappings
Profiles
Data Access
Alarms and Conditions
Programs
Historical Access
(Discovery)
Aggregates
0
Overview and Concepts
UMFANG: GUT 1000 SEITEN
200
180
160
140
120
100
80
60
40
20
1
2
3
4
5
6
7
8
9
10
11
12
13
OPC UA, Release 1.02 , 2012/2013
© HiSolutions 2015 | Präsentation
11
Security Model
Address Space Model
Services
Information Model
Mappings
Profiles
Data Access
Alarms and Conditions
Programs
Historical Access
(Discovery)
Aggregates
0
Overview and Concepts
IM ENGEREN SINN SICHERHEITSRELEVANT: CA. 450 S.
200
180
160
140
120
100
80
60
40
20
1
2
3
4
5
6
7
8
9
10
11
12
13
OPC UA, Release 1.02 , 2012/2013
© HiSolutions 2015 | Präsentation
QUANTITATIVE 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äsentation
Gefundene Schwachstellen (Kritikalität aufsteigend)
1.
2.
3.
4.
13
Gut gemeint: Part 2, das „Sicherheitsmodell“ von OPC UA
You don‘t measure what you don‘t measure: „Security Levels“ in OPC UA
Hauptsache verschlüsselt: TLS != TLS
Kein Bock auf Gärtner: Baumartige Abhängigkeiten in der Architektur
© HiSolutions 2015 | Präsentation
1. Gut gemeint: Das Sicherheitsmodell von OPC UA
Part 2 „Security Model“:
Sicherheitskonzept von OPC UA
14
© HiSolutions 2015 | Präsentation
Part 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.2.6
Auditability
4.2.7
Availability
4.3
5
Overview
Security Reconciliation
5.1 Reconciliation of Threats with Security Mechanisms
Security Threats to OPC UA Systems
4.3.1
15
4.4 – 4.12: Architekturprinzipien […]
5.2 Reconciliation of Objectives w. Security Mechanisms
6
Implementation and Deployment considerations
© HiSolutions 2015 | Präsentation
Part 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.2.6
Auditability
4.2.7
Availability
4.3
5
Overview
Security Reconciliation
5.1 Reconciliation of Threats with Security Mechanisms
Security Threats to OPC UA Systems
4.3.1
16
4.4 – 4.12: Architekturprinzipien […]
5.2 Reconciliation of Objectives w. Security Mechanisms
6
Implementation and Deployment considerations
© HiSolutions 2015 | Präsentation
Reconciliation of Threats: „Risikoanalyse“
17
© HiSolutions 2015 | Präsentation
Security 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
Session Hijacking
4.2.1
Overview
4.3.9
4.2.2
Authentication
4.3.10 Rogue Server
4.2.3
Authorization
4.3.11 Compromising User Credentials
4.2.4
Confidentiality
4.2.5
Integrity
4.2.6
Auditability
4.2.7
Availability
4.3
18
4.4 – 4.12: Architekturprinzipien […]
5
5.1 Reconciliation of Threats with Security Mechanisms
5.1.4 Message Spoofing
5.2 Reconciliation of Objectives w. Security Mechanisms
Security Threats to OPC UA Systems
4.3.1
Overview
4.3.2
Message Flooding
Security Reconciliation
6
Implementation and Deployment considerations
© HiSolutions 2015 | Präsentation
Security 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äsentation
Security 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äsentation
Risiko 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äsentation
Reconciliation 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äsentation
Reconciliation of Objectives
OPC UA Part 2: Security Model,
Release 1.02 , 2013
23
© HiSolutions 2015 | Präsentation
Reconciliation 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äsentation
Reconciliation 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äsentation
Security 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äsentation
2. 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äsentation
Security Levels in Part 7: Profiles
OPC UA Part 7: Profiles,
Release 1.02 , 2012
29
© HiSolutions 2015 | Präsentation
Probleme 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äsentation
Interlude: Gefährdungen für SOA
3.3.1 Vorsätzliche Handlungen/Angriffe
 Web Service Interface Probing
 Angriffe auf das XML Parsing System
 External Reference Attacks [XEE]
 SOAP Flooding Attack
3.3.2 Organisatorische Mängel
 Unzureichende Berücksichtigung von
Sicherheitsaspekten im SOA Design
 Fehlende oder unzureichende Regelungen/keine
klare Abgrenzung von Verantwortlichkeiten
 Message Eavesdropping
 Fehlendes Notfallvorsorgekonzept/
Sicherheitskonzept/Business Continuity Plan
 Malicious Morphing/Message Tampering
 Unzureichendes Sicherheitsmanagement
 Routing Detours
3.3.3 Menschliche Fehlhandlungen
 Identity Spoofing
 Fehlendes Sicherheitsbewusstsein
(Awareness)/Verantwortungsbedürfnis/Kenntnis
 XML Signature Element Wrapping Attack [XSW]
 Code Injection Attacks (SQLi, XPath-i, LDAPi, XSS)
 Schadsoftware
 Schwachstellen in Backend-Anwendungen
 Brute-Force/Dictionary Attack
 Identity Service Spoofing
 Angriffe auf Registries/Repositories
 Angriffe auf Protokolle („geerbte Bedrohungen“)
 Kryptoanalyse
 Falsche oder ungenügende Implementierungen/
Sicherheitskonfigurationen
 Social Engineering
3.3.4 Technisches Versagen
 Fehlerhafte Hardware
 Fehlerhafte Protokolle/unsichere Algorithmen
3.3.5 Höhere Gewalt
 Naturkatastrophen
SOA Security Kompendium 2.0.1 (2009)
31
© HiSolutions 2015 | Präsentation
Gefährdungen für OPC UA
3.3.1 Vorsätzliche Handlungen/Angriffe
 Web Service Interface Probing
 Angriffe auf das XML Parsing System
 External Reference Attacks [XEE]
 SOAP Flooding Attack
Legende:
 Nicht OPC UA-spezifisch
 Wird im Standard behandelt
 (Eher) implementierungsabhängig
 Nicht im Standard behandelt
 Message Eavesdropping
 Malicious Morphing/Message Tampering
 Routing Detours
 Identity (Service) Spoofing
 XML Signature Element Wrapping Attack [XSW]*
 Code Injection Attacks (SQLi, XPath-i, LDAPi, XSS)*
 Schadsoftware
3.3.3 Menschliche Fehlhandlungen
 Fehlendes Sicherheitsbewusstsein
(Awareness)/Verantwortungsbedürfnis/Kenntnis:
Falsche oder ungenügende Implementierungen/
Sicherheitskonfigurationen
 Schwachstellen in Backend-Anwendungen
 Brute-Force/Dictionary Attack
32
 Angriffe auf Registries/Repositories
3.3.4 Technisches Versagen
 Angriffe auf Protokolle („geerbte Bedrohungen“) /
Kryptoanalyse
 Fehlerhafte Protokolle/unsichere Algorithmen
© HiSolutions 2015 | Präsentation
3. Einsatz von TLS in OPC UA
X
OPC UA Part 6: Mappings,
Release 1.02 , 2012
33
© HiSolutions 2015 | Präsentation
TLS in Profilen (Part 7)
1
keine Spezifizierung!
OPC UA Part 7: Profiles,
Release 1.02 , 2012
34
© HiSolutions 2015 | Präsentation
Grund 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äsentation
TLS 1.0 und 1.1 „nur zu Kompatibilitätszwecken“
*
*
OPC UA Part 7: Profiles,
Release 1.02 , 2012
36
© HiSolutions 2015 | Präsentation
Immerhin 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äsentation
Gute 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äsentation
Sicherheit von TLS
39
RFC 7525 (Mai 2015)
BSI TR-02102 (2014/2015)
OPC UA (2012)
SSL (<= 3.0)
Verboten
Verboten
Verboten
TLS 1.0
SHOULD NOT
Für Kompatibilität
Mit BEAST-Schutz
Für Kompatibilität
Nur RC4 128bit SHA1
TLS 1.1
SHOULD NOT
Für Kompatibilität
Für Kompatibilität
TLS 1.2
MUST PREFER
empfohlen
empfohlen
Hash
>= SHA2
SHA2; für HMAC auch noch
SHA1 erlaubt
SHA1 / unspez. /
SHA2
Forward Secrecy
STRICT
empfohlen
Nicht möglich
Weitere Vorgaben
Keine null ciphers,
SHOULD NOT Kompression,
sichere Renegotiation, keine
HMAC-Verkürzung,
Schlüssellängen, kein Fallback
zu SSL, sichere Resumption,
„Strict TLS“ (u.a. HSTS),
Risiken bei DH Exponent reuse
Keine null ciphers (ind.),
sichere oder keine
Kompression,
sichere Renegotiation,
keine HMAC-Verkürz.,
Schlüssellängen,
Schlüsselspeicherung,
Zufallszahlen
Keine Vorgaben für
TLS1.1! (u.a. null
ciphers möglich)
Keine weiteren
Vorgaben
© HiSolutions 2015 | Präsentation
4. Baumartige Abhängigkeiten in der Architektur
„Protocol Stapling“
40
© HiSolutions 2015 | Präsentation
Sicherheit 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
2. WS Security ändern, sodass auf XML Enc 1.1 verwiesen wird
3. WS SecureConversation anpassen auf das neue WS-Security
4. OPC UA inkl. UA SecureConversation updaten
5. Produkte überarbeiten
6. Ankunft auf dem Markt.
42
DONE (1 ½ Jahre)
ca. 20142016
ca. 2017
ca. 2019
ca. 2021
ca. 2025 †
© HiSolutions 2015 | Präsentation
Relevanz 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äsentation
Empfehlungen
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äsentation
OPC 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äsentation
BSI-Projekt OPC UA








46
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
© HiSolutions 2015 | Präsentation
Ausblick
 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äsentation
14. IT-SICHERHEITSKONGRESS 2015
HISOLUTIONS BEDANKT
SICH FÜR IHRE
AUFMERKSAMKEIT
HiSolutions AG
Bouchéstraße 12
12435 Berlin
[email protected]
www.hisolutions.com
+49 30 533 289-0
48
© HiSolutions 2015 | Präsentation

Download Report