Safety, Security und Privacy – Abgrenzung in Definition, Bedrohung und Risikoanalyse

Beitragsautor: Marc Schmid, Juli 2018

Abstract

Safety, Security und Privacy werden von der Begrifflichkeit oft miteinander vertauscht oder gleichgesetzt. Dabei unterscheiden sie sich umfassend in ihrer Bedeutung bezüglich Definition und Umfeld sowie möglicher Bedrohungen, Risiken, Angriffszenarien, Vermeidungs- und Abwehrstrategien. In diesem Aufsatz sollen die Unterschiede der Definition, des Bedrohungs- und Schadenspotentials sowie der möglichen Abwehrstrategien dargelegt werden. Der Fokus wird dabei auf die Verwendung dieser Begriffe in der Automatisierungstechnik gelegt.

Motivation / Auslöser

Durch die Digitalisierung werden immer mehr Themen und Arbeitsgebiete mit Computern durchzogen, welche in ihrer bisherigen Ausführung ohne oder mit nur begrenzter Rechnerunterstützung fungierten.

In der Industrie wird unter dem Stichwort Internet of Things oder Industrie 4.0 [4] daran geforscht und gearbeitet, ganze Industriezweige durch den Einsatz von Computern zu optimieren (siehe nachfolgende Grafik).

 (c) www.dfki.de
Abbbildung 1: Einfluss von Software in industriellen Anlagen

Durch die verstärkte Verwendung von Computern in bisher traditionellen Arbeitsfeldern ergeben sich neue Handlungsfelder und auch Optimierungsmöglichkeiten bestehender Handlungsfelder.

Besonders im Bereich der Automatisierungstechnik ergeben sich hier Vorteile, da durch die Verwendung von mehr Sensorik mehr Daten gesammelt werden können und dadurch Vorgänge besser automatisiert werden können, da nicht mehr die Interaktion eines Menschen erforderlich ist.

So können beispielsweise industrielle Anlagen durch die Verwendung von vermehrter (intelligenter) Sensorik mehr Daten erfassen und so automatisch auf Veränderungen reagieren.  Beispielsweise kann eine automatische Anlage ihren momentanen Wartungszustand durch intelligente Werksstücke messen und aufgrund dieser Daten ihre Funktionalität anpassen oder Wartungsmeldungen versenden, um Wartungszyklen zu optimieren.

Allerdings ergeben sich durch die neue Handlungsfelder nicht nur Vorteile. Die Verwendung von neuen Funktionalitäten, vor allem jenen, die nicht mehr der direkten Überwachung durch einen Menschen unterliegen, können neben den zu bringenden Vorteilen auch Gefahren entstehen, welche die Sicherheit gefährden können.

Der Begriff der Sicherheit wird in die Begriffe Safety [3], Security [2] und Privacy [1] unterteilt. Da alle diese Begriffe einen unterschiedlichen Aspekt der Sicherheit betrachten, allerdings alle in fast allen Handlungsfeldern auf unterschiedliche Weise verletzt werden können, soll hier nun die Differenzierung dieser Begriffe im Bereich der Automatisierungstechnik hervorgehoben werden.

Stand der Technik

Safety

Der Begriff der Safety [3] ist vor allem im Bereich von Softwarelösungen in Verbindung mit Maschinen, und damit  in der Automatisierunstechnik, besonders wichtig. Er beschreibt den Schutz vor einer Fehlfunktion, hier eine Fehlfunktion, die durch Fehler der Entwickler entsteht und nicht durch Bösartigkeit anderer Menschen,  der Software und/oder Maschine bei bestimmungsgemäßer Verwendung, welche zu einer Bedrohung von Menschen oder anderen physikalischen Objekten (anderen Maschinen zum Beispiel) führen könnte.

In der Automatisierungstechnik sind solche Funktionalitäten das Loslösen von menschengesteuerten Aktionen hin zu computergesteuerten Aktionen basierend auf gemessenen Daten.

So wird beispielsweise die Überprüfung einer Anlage in festen Intervallen ausgelagert, dass der Verschleiß der Anlage gemessen wird und die Anlage aufgrund dieser Daten entscheidet, wann gewartet werden muss.

Solche automatisierte Mechanismen müssen daraufhin überprüft und zertifiziert werden, dass sie bei korrekter Bedienung auch nur das machen, was spezifiziert und programmiert wurde.

Diese Überprüfung entspricht dann einer Überprüfung, ob die gegebene IST-Funktionalität der spezifizierten SOLL-Funktionalität entspricht. Dies erfordert damit allerdings, dass der gewünschte Zustand jeder Funktionalität auch spezifiziert und festgehalten wurde, damit dagegen geprüft werden kann.

Auch die Prüfung der Funktionalität muss ein solches Verfahren sein, welches alle benötigten Spezifikationen auf eine standardisierte (und eventuelle zertifizierte) Weise überprüfen kann und die Resultate auch replizieren kann.

Für die Softwarekomponenten haben sich schon verschiedene Normen [8] oder Verfahren etabliert (Test-Driven Development, Testautomatisierung, Pareto-Prinzipien im Testen, u.v.m.) welche auf eine standardisierte Weise vorschreiben, wie Softwareartefakte geprüft werden müssen, um die Safety [3] der Anwendung oder Maschine sicherzustellen. Durch systematische Testvorgänge können Fehler zwar erkannt und behoben werden, jedoch kann ein Test nur das Vorhandensein von Fehler feststellen, niemals die völlige Abwesenheit davon. Dennoch müssen unterschiedliche Testverfahren einen erheblichen Teil der Softwareentwicklung ausmachen, um die Safety [3] zu gewährleisten.

Security

Die Securtiy [2] definiert sich dazu als der Schutz von Software/Anlagen gegen absichtliche Angriffe auf die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen, die von der Software/Anlage verwendet/verwaltet werden. Es wird also der Angriff durch einen anderen Menschen oder ein anderes System dadurch beschrieben, welche Schwachstellen in der Programmierung ausnutzen, um Schaden anzurichten oder den eigenen Vorteil unrechtmäßig zu erhöhen.

Auch für die Security [2] müssen die Schutzziele vorher definiert werden, damit gegen diese Ziele geprüft werden kann.  Und auch hier gibt es schon bereits bestehende Verfahren (Functional Testing, Vulnerability Scanning, Systematic Fuzzing, Penetration Testing, CVE, CAPEC (siehe Grafik), CWE, u.v.m.), welche das Testen der Safety [3] erweitern, um Angriffsaspekte erkennen zu können, oder bereits definierte Standards (CERT, (MISRA C*, u.v.m.) sowie bestehende Risikomanagementanalysesysteme für Softwaresysteme.

 (c) capec.mitre.org
Abbildung 2: CAPEC Angriffserkennung

Allerdings sind diese Standards nicht vollständig, da sie nicht alle Angriffsvektoren abdecken können.

In der Kryptographie gibt es mathematische Modelle (wie das Modell nach Dolev-Yao [5] zur Überprüfung von (Netzwerk)-Protokollen auf Angriffsmuster), welche dann für gegebene Umstände beweisen, dass eine Softwarelösung sicher ist.

Diese Modelle sind allerdings in der Realität nicht immer umzusetzen, da sie von Annahmen ausgehen können, welche auf Industrieanlagen nicht gegeben sein müssen.

Standardisierte Protokolle können allerdings die Anlage vor einer Manipulation schützen, wenn sie denn korrekt umgesetzt und betrieben werden.

Privacy

Der Begriff der Privacy [1] beschreibt, dass die Daten, die in einem System erstellt werden (Benutzungsdaten von Nutzern oder Geschäftsdaten der Anlage/Firma), nicht in die Hände Unbefugter gelangen, die die Sensordaten einer Anlage an den Endpunkt der Konkurrenz weiterleiten.

Dies kann bei der Entwicklung der Software durch die Verwendung von standardisierten Designentscheidungen [7] und Techniken, die die Daten schützen (Authentifizierung, Zero-Knowlegde-Beweise („Beweise dass ich ich bin oder ein Geheimnis weiß, ohne zu zeigen, dass ich ich bin oder das Geheimnis zu zeigen“) [6], korrekte Anonymisierung und Pseudonymisierung, u.v.m.), erreicht werden.

Analyse, Diskussion und Bewertung

Es gibt schon viele unterschiedliche Verfahren, um die Sicherheit eines (Software-)Systems zu überprüfen und sicherzustellen. Durch die erhöhte Verwendung von komplexer Softwaresysteme in automatisierten Anlagen ist es auch von größter Wichtigkeit, dass die Sicherheit dieser Anlagen gewährleistet werden kann. Speziell heutzutage, wenn Angriffe von außen kritische Anlagen beschädigen oder missbrauchen können (und die wiederholt erfolgen, wie die Veröffentlichung gestohlener Nutzerdaten oder die Manipulation von Zentrifugen in atomaren Forschungsanstalten zeigt (Stuxnet)).

Trotz der Wichtigkeit des Sicherheitsthemas und trotz der Tatsache, dass im Bereich Security [3] und Privacy [1] viel geforscht wird und es auch schon etablierte Normen und Standards zur Sicherung gibt, bezeugen aktuelle Beispiele von Veröffentlichungen und neuen Angriffen immer wieder, dass diese Methoden nur selten korrekt umgesetzt werden und es weiterhin Arbeit benötigt, um Systeme wirklich sicher zu machen.

Fazit

Die verstärkte Verwendung von Computern bringt vielen Geschäftsfeldern, vor allem jenen im Bereich der Automatisierungstechnik, neue Möglichkeiten und Vorteile. Durch die Möglichkeit, mehr Daten erheben zu können und dies auch zu müssen, um neue Funktionalitäten automatisiert ausführen zu können, entstehen aber auch Nachteile. Die Umsetzung neuer Funktionalitäten führt zum einen dazu, dass diese Funktionalitäten immer komplexer werden (um beispielsweise Menschen zu ersetzen) und dadurch die Safety [3] ihrer Anlage gefährden können. Die Verwendung von Funktionalitäten höhere Komplexität führt mit dazu, dass Anlagen nicht mehr alleine arbeiten können und deshalb Schnittstellen zu anderen Anlagen oder der Außenwelt im allgemeinen benötigen, welche die Anlagen allerdings auch von außen angreifbar machen können (Security [2]).  Die Verwendung von mehr Daten kann dazu führen, dass die Daten Auskünfte über Firmengeheimnisse enthalten können. Die Privacy [1] muss deshalb bei der Entwicklung von Systemen die Sensibilität der Daten im Auge behalten.

Für die Bereiche Security [2], Safety [3] und Privacy [1] gibt es jeweils schon verschiedenste Verfahren und Techniken, um die Korrektheit und Sicherheit des jeweiligen Aspekts zu verbessern oder nach gewissen Anforderungen sicherzustellen.

Allerdings sind diese Anforderungen in ihrer Umsetzung oft teuer oder kompliziert und werden deshalb oft nicht völlig korrekt umgesetzt.

In allen drei Aspekten der Sicherheit gibt es also in allen Handlungsfeldern immer Handlungsbedarf, vor allem, da die Systeme immer komplexer werden und die Angriffe von außen auf alle möglichen Systeme immer weiter zunehmen.

Literatur

  • [1] http://www.businessdictionary.com/definition/privacy.html
  • [2] http://www.businessdictionary.com/definition/security.html
  • [3] http://www.businessdictionary.com/definition/safety.html
  • [4] https://wirtschaftslexikon.gabler.de/definition/industrie-40-54032
  • [5] D. Dolev and A. Yao: On the security of public key protocols. IEEE Transactions in Information Theory, 2(29):198–208, March 1983.
  • [6] Oded Goldreich and Yai Oren: Definitions and properties of zero-knowledge proof systems. Journal of Cryptology, , Volume 7, Issue 1, pp 1–32
  • [7] European Union Agency for Network and Information Security :Privacy and Data Protection by Design – from policy to engineering. December 2014
  • [8] IEEE: Software and systems engineering Software testing. 29119-2-2013

Quellen

Dieser Beitrag entstand nach einem Vortrag im Rahmen der Ringvorlesung „Forum Software und Automatisierung“ am IAS.

Vortragsdatum: 09.11.2017
Vortragender: Dr. Thomas Liedtke, Kugler Maag CIE GmbH
Vortragstitel: Kritische Software: Wie prüft man Safety, Security und Privacy?

Zum Seitenanfang