Safety Einführung

Seminar im IdS
Seminar Safety und Security Engineering
Sommersemester 2006
Seminarausarbeitung
Safety Einführung
Benjamin Tzschoppe
18. Juli 2006
Universität Duisburg-Essen · Fachbereich Ingenieurwissenschaften · Abteilung
Informatik
Arbeitsgruppe Software Engineering – Prof. M. Heisel
betreut durch: Dipl.-Inform. Denis Hatebur

INHALTSVERZEICHNIS i
Inhaltsverzeichnis
1 Was ist Sicherheit? 1
1.1 Unterschied Safety und Security . . . . . . . . . . . . . . . . . 1
1.2 Typische Safetyanforderungen . . . . . . . . . . . . . . . . . . 2
1.3 Begriffe und Definitionen . . . . . . . . . . . . . . . . . . . . 3
2 IEC 61508 5
2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Bestandteile der IEC 61508 . . . . . . . . . . . . . . . . . . . 6
2.3 Safety Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Die SIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Warum ist Safety wichtig? 8
3.1 Safety Probleme in der Vergangenheit . . . . . . . . . . . . . 9
4 Anwendung von Safety 9
5 Safety und Security 10
5.1 Unterschiede . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Mögliche Zusammenarbeit . . . . . . . . . . . . . . . . . . . . 12
6 Fazit 12
7 Literatur 14

1 WAS IST SICHERHEIT? 1
1 Was ist Sicherheit?
Sicherheit bezeichnet den Zustand, der frei von vertretbaren Risiken der Beeinträchtigung
ist oder als gefahrenfrei angesehen wird.[Aut06]
Sicherheit kann man auch als Komplement von Risiko definieren, wobei folgende
Risikodefintion zu Grunde liegen soll: ” Das Risiko einer Anlage oder
Tätigkeit ist die Summe über alle (gefährlichen) Ereignisse der Produkte von
Eintrittswahrscheinlichkeit und Schadensausmaß und evtl. (subjektiven) Gewichtungsfaktoren“.[OH]
In der Security-Branche spricht man an Stelle von
gefährlichen Ereignissen auch von ” erfolgreichen Angriffen“.
1.1 Unterschied Safety und Security
Die englische Sprache bietet den Vorteil, dass sie für den Begriff Sicherheit
zwei verschiedene Worte verwendet. Unter Safety versteht man die funktionale
Sicherheit von Maschinen und Anlagen zum Schutz von Mensch,
Maschine und Umwelt. In unserem besonderen Falle die funktionale Sicherheit
von Softwaresystemen zum Schutz von Mensch und Maschine. Unter
Security versteht man dagegen die Sicherheit von Daten gegenüber unberechtigtem
Zugriff von außen. Die Schutzziele sind hier vor allem: Vertraulichkeit,
Integretät und Authentizität. Aber auch die Beweisbarkeit und
Verfügbarkeit von Daten sowie der Schutz vor Image-Schäden (zum Beispiel
durch Rückrufaktionen) [Bac06] Security ist also der Schutz von (Software)-
Systemen von unberechtigten Zugriffen von außen. Safety ist der Schutz
von Softwaresystemen von zum Beispiel Bedienfehlern des Anwenders oder
mögliche Fehler der Technologie. Ein Beispiel kann den Unterschied zwischen
Safety und Security noch ein wenig veranschaulichen. Der Security
Aspekt bei einem Gütertransport mit einem LKW kann zum Beispiel das
Wählen von zufällig ausgesuchten Strecken sein. Oder eine Polizeieskorte die
den Transport begleitet. Solche Maßnahmen dienen eher dazu den Transport
von Zugriffen von beispielsweise Terroristen zu schützen. Zutreffende Safetymaßnahmen
wären das Wählen von ” sicheren“ Fahrzeugen, dies könnte zum
Beispiel ein besondere Tank bei Gefahrguttransporten sein. Aber auch ein
Anti-Blockier-System gehört zu den Safetyaspekten eines Transportes.
Klar aus den Beispielen und der Abgrenzung von Safety und Security werden
nicht nur die beiden Begriffe, sondern auch, dass beide Begriffe auch noch
in anderen Disziplinen eine Rollen spielen. Vor allem in der Elektrotechnik
spielt Safety eine große Rolle.

1 WAS IST SICHERHEIT? 2
Safety
Umwelt
Maschine
Abbildung 1: Safety, Schutz
der Umwelt vor der Maschine
1.2 Typische Safetyanforderungen
Umwelt
Security
Maschine
Abbildung 2: Security, Schutz der
Maschine vor der Umwelt
Spezifische Safetyanforderungen sind vom System abhängig und können von
System zu System variieren. Dennoch gibt es die Möglichkeit typische Safetyanforderungen
darzustellen. Safety bezogene Software bezweckt vor allem
Leben zu schützen. Aber auch die Gesundheit der Menschen und die Umwelt
vor jedlichen Schäden, die das System hervorrufen könnte zu bewahren.
Safety ist dabei im Gegensatz zur Security auf nicht vorsätzliche Ereignisse
fokussiert, sondern auf Ereignisse die zufällig auftreten.
In Safety bezogenden Systemen gibt es zwei Arten von Störfällen. Die erste
Art von Störfall sind die sogenannten incidents. Diese incidents sind zwar
nicht wünschenswert aber nach Safteyregeln legal. Bei dieser Art von Störfall
könnte zum Beispiel eine begrenzte Menge Radioaktivät austreten, die zwar
nicht wünschenswert ist, aber nicht direkt Menschenleben bedroht oder die
Umwelt mit nicht mehr zu reparierenden Schäden belastet.
Liegen die Konsequenzen eines Störfalles außerhalb dieser begrenzten Regeln,
nennt man den Zwischenfall accident. Das dieser Fall schwerwiegender
ist, kann man auch an der Übersetzung von incident und accident sehen.
Im Deutschen bedeutet incident = Störfall sowie accident = Unfall.

1 WAS IST SICHERHEIT? 3
1.3 Begriffe und Definitionen
Dieses Unterkapitel soll dazu dienen einige Begriffe aus der Safetycommunity
vorzustellen, um sie zu einem späteren Zeitpunkt mit den entsprechenden
Securitybegriffen gegenüber zu stellen.

1 WAS IST SICHERHEIT? 4
Begriff Definition
Hazard Eine Situation oder ein Ereignis, dessen Ergebnis einen nicht
wünschenswerten Effekt auf die Umwelt hat. Safety Maßnahmen
zielen normalerweise darauf ab die Härte der Konsequenzen
eines solchen Hazards zu reduzieren. Natürlich wird
auch probiert durch entsprechende Maßnahmen das Risiko
des Eintreten des Hazards überhaupt zu reduzieren (Riskreducing)
Failure Safetymaßnahmen werden getroffen um das System davor
zu schützen, Schäden in der Umwelt anzurichten. Von einem
Failure spricht man, wenn eine dieser Safetymaßnahmen
nicht korrekt funktioniert. Failures in einem Safetysystem
haben meist unerwünschte Resultate zur Folge. Die
Wahrscheinlichkeit, dass ein Failure eintritt kann entweder
durch statistische Werte errechnet werden, oder sie sind
statisch (zum Beispiel Design-Eigenschaften des Systems
wie Wände eines Atomkraftwerkes“). Bei diese Design-
”
Eigenschaften geht man von Naturgesetzen aus, die nicht
gebrochen werden können. Sie können also nicht ausfallen.
Incident Mit Incident bezeichnet man einen Fall, dessen Eintreten
zwar nicht wünschenswert ist, aber dennoch legal. Hierbei
sind weder Menschenleben in Gefahr, noch wird die Umwelt
mit dauerhaften Schäden belastet
Accident Liegen die Konsequenzen eines Failures außerhalb der erlaubten
Grenzwerte spricht man von einem Accident. Ein
Accident ist also der Fall, den es unbedingt gilt zu verhindern.
Risiko Risiko = Eintrittswahrscheinlichkeit×Schadensausmaß,
je höher das Risiko, desto höher ist auch die Einstufung in
den Safety-Integrity Leveln (siehe unten)
Risikoanalyse Die Risikoanalyse wird benutzt um Anforderung an die
Safety-Software zu bestimmen. Typische Beispiel für Risikoanalysen
im Safetybereich sind HAZOP (=Hazard and
Operability study), ETA (=Event Tree Analysis) etc. Es
gibt noch einige weitere Beispiele, in dieser Ausarbeitung
soll aber dort nicht näher drauf eingegangen werden.
Barrier Protection
Safety barriers werden benutzt um verschiedene Stufen des
Schutzes für die umgebende Umwelt zu geben. Die erste Stufe
ist, dass die Software selbst safetybezogen entwickelt wurde.
Die zweite Stufe ist das benutzen von Redundaten Softwaresystemen
(oder Teilen) für die gleiche Funktion. Das
checken von Checksummen und selbstkorrigierende Software
ist die dritte Barriere. Zeitkontrolle und Software Handshakes
(eine Software, die ein Signal erhalten halt, muss eine
Bestätigung schicken, dass das Signal angekommen ist, sonst
wird ein ” Failure“ angezeigt)

2 IEC 61508 5
2 IEC 61508
2.1 Einführung
Die IEC 61508 ist eine Industrienorm der International Electrotechnical
Commission (IEC) zur Schaffung von sicheren elektrischen, elektronischen
und programmierbar elektronischen (E/E/PE) Systemen, die eine Sicherheitsfunktion
ausführen.
Die aus vier normativen und drei informativen Teilen bestehende Norm hat
eine Gesamtlänge von über 400 Seiten und trägt den Titel ” Funktionale
Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar
elektronischer Systeme“. Sie wurde 1998 veröffentlicht, wovon einige Teile
2000 in einer überarbeiteten Fassung neu veröffentlicht wurden. Das Konzept
der Safety Integrity Levels (SIL) wurde schon 1991 von Def Stan entworfen.
Die IEC hat dieses Konzept als Kernkonzept von IEC 61508 übernommen
und normiert. Vom Europäischen Komitee für Normung (CEN) wurde die
Norm 2001 inhaltsgleich als EN 61508 übernommen. In Deutschland hat
sie als deutsche Fassung unter den Namen DIN EN 61508 und VDE 0803
Gültigkeit, ihre Anwendung ist freiwillig.
Von der Norm erfasst sind alle sicherheitsbezogenen Systeme, die elektrische,
elektronische oder programmierbar elektronische Komponenten (E/E/PES)
enthalten, und deren Ausfall ein maßgebliches Risiko für Mensch oder Umwelt
bedeutet. Sie bezieht sich somit auf keine bestimmte Anwendung. Dazu
gehören Systeme, die auf Anforderung eine Sicherheitsfunktion ausführen,
zum Beispiel das Antiblockiersystem bei einem Kraftfahrzeug, und Systeme,
die auf ständige Ausführung der Sicherheitsfunktion angewiesen sind, zum
Beispiel die Steuerungseinheit einer Trägerrakete. Gemäß der Norm bilden
die Funktionen aller sicherheitsbezogener Systeme die funktionale Sicherheit
des Gesamtsystems. Die IEC 61508 ist als ” Sicherheits-Grundnorm“
ausgewiesen, das heißt sie kann als Basis für anwendungsspezifische Normen
dienen. Zum Beispiel setzt die auf der IEC 61508 basierende IEC 61513 Anforderungen
für sicherheitsrelevante Systeme in einem Kernkraftwerk fest.
Der Geltungsbereich der Norm erstreckt sich über Konzept, Planung, Entwicklung,
Realisierung, Inbetriebnahme, Instandhaltung, Modifikation bis
hin zur Außerbetriebnahme und Deinstallation sowohl des gefahrverusachenden
Systems als auch der sicherheitsbezogenen (risikomindernden) Systeme.
Die Norm bezeichnet die Gesamtheit dieser Phasen als ” gesamten Sicherheitslebenszyklus“.
Zentrales Element ist die Bestimmung von Sicherheitsintegritätsleveln (SIL)
von 1 bis 4, den die Sicherheitsfunktionen des E/E/PES erfüllen müssen, da-

2 IEC 61508 6
mit das tolerierbare Risiko des gefahrverusachenden Systems nicht überschritten
wird. Mit höherer notwendiger risikomindernder Wirkung des sicherheitsbezogenen
Systems müssen der SIL und somit die Anforderungen an die
Verlässlichkeit des sicherheitsbezogenen Systems steigen.
2.2 Bestandteile der IEC 61508
Im folgendem Unterabschnitt werden nun die einzelnen Bestandteile der IEC
61508 kurz erläutert.
Teil 1: Allgemeine Anforderungen
• Generelles Management der funktionalen Sicherheit (Functional Safety
Management, FSM). Hier werden alle Aktivitäten und Prozessabläufe
für die Entwicklung und das Managen von sicherheitsrelevanten Systemen
definiert.
• Der Sicherheitslebenszyklus und die Anforderungen jeder Phase
• Die SIL Definition und die ” Gefährundungs und Risikoanalyse“ um
ein SIL Ziel des Gesamtsystems zu bestimmen.
• Notwendigkeit von Kompetenzkriterien für Personen, die im sicherheitskritischen
Bereich eingebunden sind.
• Grad der Unabhängigkeit von prüfenden/zertifizierten Personen und
Organisationen
• Anforderungen an die Dokumentation jeder Phase des Sicherheitszyklus
Teil 2 Anforderungen an sicherheitsbezogene Systeme (Hardware)
• Sicherheitslebenszyklus-Aktivitäten, die zur Konzeption und zur Realisierung
der Hardware notwendig sind
• Notwendigkeit die quantitative Ausfallwahrscheinlichkeit der Hardware
zu bestimmen (zu berechnen) und nachzuweisen.
• Techniken und Verfahren zur Beherrschung systematischer Hardwarefehler.
Anforderungen an Software
• Techniken und Verfahren, wie sicherheitsgerichtete Software entwickelt
und dokumentiert sein sollte. Hierbei werden nur systematische Fehler
betrachtet, da es in der Softwareentwicklung keine zufälligen Fehler
geben kann.
• Tabellen mit Anforderungen an Entwicklungstechniken für jeden SIL

2 IEC 61508 7
• Informative Anhänge
Teil 4: Begriffe und Abkürzungen
Teil 5: Beispiele zur Ermittlung der Stufe der Sicherheitsintegrität
• Vier Beispiele zur Einstufung eines Systems in SIL
Teil 6: Anwendungshinweise über Verfahren und Maßnahmen
• Anwendung der IEC61508 2 und 3
• Kalkulation der Hardwarefehler und Ausfallwahrscheinlichkeit
• Berechnung eines ” Diagnosedeckungsgrad“
• Methode zur Bestimmung von ” Common Caus Failures“
• Beispiel zur Anwendung der Anforderungstabellen aus Teil 3 für Softwareentwicklung
Teil 7: Anwendungshinweise über Verfahren und Maßnahmen[IEC98]
2.3 Safety Integrity
Um die SIL zu verstehen, muss im Vorfeld geklärt werden, was Saftey Integrity
bedeutet. Normalerweise sollte wenn eine Funktion des Systems ausfällt
dies nicht direkt zu einem totalen Verlust der Safety Funktion führen. Die
Fehlfunktion soll von einer anderen Funktion des Systems kompensiert werden.
Zum Beispiel kann die Handbremse in einem Auto den Ausfall der normalen
Hydraulikbremse kompensieren. Es kann allerdings sein, dass die Handbremse
das Auto nicht im gleichen Maße zum stehen bekommt, wie die
normalerweise wirkende Hydraulikbremse. Mit anderen Worten, kann eine
Safetyfunktion weitergeführt werden (möglicherweise schwächer) trotz des
Verlustes der eigentlichen Safteyfunktion. Diese Fähigkeit von Safetyfunktionen
effektiv zu wirken, trotz Ausfalls der eigentlich dafür zuständigen
Safetyfunktion nennt man Safety Integrity.
Man erkennt leicht, dass es verschiedene Level von Safety Integrity geben
kann, abhängig davon, wie viele verschiedene Safetyfunktionen das System
hat und wie effektiv diese sind.

3 WARUM IST SAFETY WICHTIG? 8
Abbildung 3: Die Fehlerwahrscheinlichkeit wird in diskrete Ebenen (Level)
unterteilt, in der IEC 61508 gibt es vier verschiedene Ebenen. Für jede Ebene
hat die IEC 61508 Anforderungen gestellt, die das System erfüllen muss.
2.4 Die SIL
Für Safety Funktionen dessen Aufgabe es ist hohe Risiken zu lindern, benötigen
wir ein höheres Level an Safety Integrity als für Safety Funktionen die niedrige
Risiken absichern. Das Äquivalent zu SIL in der Securitycommunity ist
EAL (Evaluation Assurance Level)
Die SIL (= Safety Integration Levels) benutzt vier verschiedene Level.
Angefangen von SIL 1, was die niedrigste Stufe ist bis hin zu SIL 4, was
die höchste Stufe ist. SIL 0 wird dabei für Funktionen benutzt, die keine
Safetyrelevanz haben. Je höher das SIL desto niedriger ist die dazugehörige
tolerierbare Gefährdungsstufe.
3 Warum ist Safety wichtig?
Früher waren viele Systeme entweder safetykritisch oder securitykritisch.
In Zukunft werden viele Systeme wohl beides sein, also Safety- und Securitykritisch.
Der Grund dafür ist, dass immer mehr IT-Systeme in wichtige
Teile unserer Lebens- und Arbeitsumgebung eingebettet werden. Diese
IT-Systeme sind dann meist noch vernetzt, was sowohl in der Safety Entwicklung
als auch in der Security Entwicklung für höhere Ansprüche sorgt.
Gründe für diese Vernetzung von auch sicherheitskritischeren Systemen ist
meist mehr Funktionalität und eine einfacherer Wartung.[Pfi04]
Leider werden Expertenwahrnungen, auch kleine Systeme mit einem hohen
Maß an Safety und Security auszustatten, heruntergespielt. Argumente gegen
eine aufwendigere Entwicklung sind meist: ” So kleine Systeme können
keine ernsthaften Probleme auslösen“. Aber mit der heutigen Vernetzung
von vielen kleinen Systemen können dann viele Fehler zur gleichen Zeit auftreten,
was dann meist doch ernsthafte Probleme auslösen kann.[Pfi04]

4 ANWENDUNG VON SAFETY 9
3.1 Safety Probleme in der Vergangenheit
Wenn man schon über die Bedeutung der Safety in der heutigen Zeit nachdenkt,
lohnt auch ein kurzer Blick zurück, um Safety-Probleme aus der Vergangenheit
zu beleuchten.
Ein Beispiel für das Scheitern eines Softwaresystem in Safety-Fragen, ist der
Absturz der von der ESA (European Space Agency) erbauten und entwickelten
Ariane 5.
Die Ariane 5 startete am 4. Juni 1996 zu ihrem Erstflug, kurze Zeit nach
dem Start sprengte sich die Rakete mit ihrer Nutzlast von vier Cluster-
Satelliten in die Luft.
Ursache war ein Softwarefehler, in den Teilen, die von Ariane 4 übernommen
worden waren. Ariane 5 beschleunigte schneller als Ariane 4, dies führte zu
einem Überlauf einer Variablen des Lenksystems. Dieser erfolgte bei der Umwandlung
einer 64-Bit Gleitpunktzahl für die horizontale Geschwindigkeit
in eine vorzeichenbehaftete 16-Bit-Ganzzahl. Daraus resultierte ein Absturz
des Lenksystems, was dazu führte, dass die Navigationsanlage nur noch Statusdaten
an den OBC (On Board Computer) sandte. Dieser interpretierte
die Daten als echte Fluglage, die natürlich vom eigentlich Kurs abwich, und
ließ die Schubdüsen der Booster bis zum Anschlag schwenken. Dadurch begann
die Rakte auseinander zu brechen und löste das boardeigene Selbstzerstörungssystem
aus, bevor die Bodenkontrolle eingreifen konnte.
Menschen kamen bei diesem Unfall nicht ums Leben, es entstand ein Schaden
von ca. 500 Millionen Dollar.[Hei06]
4 Anwendung von Safety
Erste Umsetzungen der IEC 61508 sind auch im Automobilsektor zu finden.
Ein Beispiel ist die Anwendung der IEC 61508 auf ein Lenksäulenmodul mit
integriertem Lenkwinkelsensor.
In der Automobilindustrie waren bisher immer sicherheitsrelevante Standards
im Entwicklungsprozess, die sich entweder mit Produkten oder mit
Prozessen beschäftigen (z.B. QS 9000 oder TS 16949). Nach der neustem
Stand der Sicherheitstechnik wird die Sicherheit mit einer Kombination aus
Prozess- und Produktanforderungen geregelt. Damit soll Sicherheit nicht in
ein Produkt ” hineingeprüft“ werden. Sondern es soll, genau wie im Qualitätsmanagement
auch, der Sicherheitsaspekt in allen Projekphasen mitberücksichtigt
werden.
In der Organiation des Entwicklungsprozesses wird ein sogenannter Safety-
Manager ergänzt, der besondere Kenntnisse in der Sicherheitstechnik- und

5 SAFETY UND SECURITY 10
Dokumentation besitzt. Er ist für die stetige Umsetzung der zu Beginn festgelegten
Sicherheitsschritte verantwortlich.
Die konkrete Anwendung der IEC 61508 und der darin enthaltenen SILs,
passiert im Ansatz einer Systembetrachtung, die die kritischen, sogenannten
sicherheitsgerichteten Funktionen des Systems nach außen beschreiben.
Dies geschieht mit Hilfe einer Liste solcher Funktionen. Im Beispiel der Anwendung
bei der Firma KOSTAL in der Herstellung von Lenksäulenmodulen
wäre es zum Beispiel: ” es darf kein Lenkwinkel mit mehr als 1 Grad abweichung
gesendet werden“. Diese Funktionen werden dann einem Sicherheitslevel
(Safety-Integrity-Level SIL) zugeordnet, sowie eine zulässige Restfehlerrate,
die nicht überschritten werden darf.
Im gesamten Entwicklungsprozess ist schrittweise abzusichern, dass das Steuergerät
diesen Festlegungen entspricht. Im Gegensatz zur Erfüllung einer hohen
Anzahl von Einzelanforderungen basiert der Ansatz der IEC 61508 auf
einem geschlossenen Ansatz, der das Sicherheitsverhalten des Systems nach
außen spezifiziert. Ergänzend werden qualitative Produktanforderungen in
Abhängigkeit vom Sicherheitslevel gestellt, der grundsätzliche Mindestanforderungen
(wie z.B. Überspannungsschutz) an Sicherheitskritische System
garantiert.
Insbesondere für die Softwareentwicklung bedeutet dies, je nach SIL-Einstufung
verschiedene Maßnahmen im Entwicklungsprozess, z.B. Designreviews, Codereviews
etc.
Diese Mindestmaßnahmen sollen Fehler bzw. deren Auswirkungen reduzieren.[lKG06]
5 Safety und Security
Konzepte von Safety und Security haben eine Menge gemeinsam, schade nur
das die beiden dahinterstehenden Communities so unterschiedlich sind.
Die Menschen der Security-Branche denke meist nur an alte Männer, die
nicht willens sind neue Sachen dazu zu lernen, wenn sie sich die Safety
Community vorstellen sollen. Die Safety Community hingegen denkt über
die Security Leute, dass es die ” Youngsters“ wären, die gerade dabei sind,
dass Rad noch mal neu zu erfinden. Es scheint also eine gewisse Rivalität
zwischen den beiden Gruppen zu herrschen.[MBL]
5.1 Unterschiede
In der Information-Security sind die Hauptziele confidentiality (Vertraulichbarkeit),
integrity (Integrität) und availability (Erreichbarkeit) von Informationen
sicherzustellen. Im Safetybereich sind die Hauptziele hingegen,

5 SAFETY UND SECURITY 11
Leben, Gesundheit und Umwelt vor dem (Software)-System zu schützen. In
beiden Communities haben sich unterschiedliche Begriffe und unterschiedliche
Techniken etabliert.
Der Begriff Incident“ hat in beiden Communities verschiedene Bedeutun-
”
gen. In der Safety-Community unterscheidet man zwischen Incidents“ und
”
” Accidents“. ” Incidents“ sind legale Zustände, Accidents“ müssen auf je-
”
den Fall vermieden werden.
In der Security-Community sind ” Incidents“ Vorfälle, die es absolut zu vermeiden
gilt. ” Events“ heißen dort die legalen Zuständen, die zwar nicht
wünschenswert aber akzeptabel sind. Unterschiede sind aber auch noch zwischen
den Begriffen ” Failure“ aus der Safetybranche und dem Begriff ” Incident“
aus der Securitybranche. Ein ” Failure“ im Safetyjargon meint, dass
eine oder mehrere Safetymaßnahmen nicht korrekt funktionieren. ” Incident“
wird im Securityjargon sowohl für einen Fehler im System, als auch für einen
Fehler in den Sicherheitsmaßnahmen genutzt.
Ein weitere Unterschied ist, dass Fehler im Sinne von ” Failures“ in der Safety
bezogenden Entwicklung nur zufällig auftreten. Werden diese gewollt
herbeigeführt spricht man auch von Sabotage und das Problem wird an die
Security-Leute weiterdelegiert.
Klar ist auch, dass der Wert von Leben, Gesundheit und Umwelt nicht
von Safetysystem zu Safetysystem unterschiedlich ist, sondern immer gleich
(wichtig) bleibt. Dies ist in Securitybranche unterschiedlich. Zum Beispiel ist
kann das Mitlesen einer privaten E-Mail natürlich nicht so einen hohen Schaden
verursachen wie das Ausspionieren von wichtigen Geschäftsgeheimnissen.
Außerdem kann die Gewichtung der einzelnen Teilbereiche der Security unterschiedlich
sein. Bei wichtigen geschäftlichen E-Mails kann es von sehr
großem Vorteil sein, dass kein Konkurrent diese mitlesen kann. Im E-Commerce
ist hingegen ” availability“ und ” integrity“ wichtiger.
Unterschiede von Safety und Security sind auch in der ” Fehlerbehandlung“
zu sehen. Im Safety-Konzept hat jedes System einen ” sicheren“ Zustand,
der bei ” Failure“ immer erreicht werden kann. Dies kann zum Beispiel ein
Shutdown sein, wenn Safety anders nicht mehr gewährleistet werden kann
(wobei es bei Safetysystemen der Shutdown nicht zwingend immer der ” Sichere
Zustand“ ist, zum Beispiel kann ein Flugzeug, was in 10.000 Metern
höhe fliegt nicht einfach so heruntergefahren werden). Für Security-Systeme
ist der Shutdown selten ein brauchbarer sicherer Zustand. So kann ja gerade
der Shutdown eines Systems in Bezug auf die Ausfallsicherheit ein mögliches
Ziel für einen Angreifer sein.[MBL]

6 FAZIT 12
5.2 Mögliche Zusammenarbeit
Für eine engere Zusammenarbeit der beiden konkurrierenden Gemeinschaften
kann man mehrere Gründe aufzählen. Vorteil der Safety-Community
ist, dass ihre Techniken und Methoden schon lange angewandt und getestet
werden. Die Security-Community könnte von den Erfahrungen der Safetygemeinde
lernen und bräucht das ” Rad nicht nocheinmal zu erfinden“.
Auf der anderen Seite werden einige Security-Techniken auch immer wichtiger
für die Safetygemeinde. Es werden in naher Zukunft wohl immer mehr sicherheitskritische
Systeme mit offenen Netzwerken (wie dem WWW) zwecks
RemoteControl oder entfernten Wartungsarbeiten verbunden. Die Integrität
und die Vertraulichkeit von Informationen bekommt dadurch auch für die
Safety-Community eine höhere Bedeutung. So müssen die Safety-Entwickler
ja sicherstellen, dass für die sicherheitskritische Anwendung wichtige Informationen
sicher durchs offene Netzwerk fließen.
Auch verschieden Begrifflichkeiten aus beiden Communities beschreiben ein
ähnliches, wenn nicht sogar ein gleiches Konzept. So sind zum Beispiel ” Hazards“
und ” Threats“ effektiv das Gleiche. Bei ” Hazards“ (Safety) ist die
Eintrittswahrscheinlichkeit der wichtigstes Parameter, bei ” Threats“ (Security)
die Erfolgswahrscheinlichkeit eines Angriffs. Die Konzepte von ” Failures“
(Safety) und ” Incidents“ (Security) sind auch ähnlich. Beide beschreiben
das Eintreten von nicht erwünschten Ereignissen. Einziger Unterschied
ist, dass die ” Failure“ auf die Sicherheitsfunktionen des Safety-Systems beschränkt
sind, bei ” Incidents“ (Security) gibt es keine derartige Beschränkung.
Mit dem Angleichen der Begrifflichkeiten könnten beide Communities auf
die jeweiligen Techniken der anderen Community zurückgreifen. So können
Techniken zur Klassifikation und Bestimmung von ” Hazards“ und zur ” Failure“
Beschreibung auch auf ” Threats“ und ” Incidents“ angwendet werden.
Gerade in der Risikoanalyse können viele Techniken von Safety und Security
ausgetauscht werden.
Auch in der Testphase von Softwareentwicklung können Techniken ausgetauscht
werden. So können formale Methoden um in der Safetybranche zu
zeigen, dass die Safetybedingungen erfüllt sind, auch in der Securitybranche
Andwendung finden.[MBL]
6 Fazit
Safety alleine ohne Security zu betrachten war sehr schwierig, da die beiden
Domänen meist immer im Zusammenhang auftreten. Sinnvoll war dadurch
auch an dieser Stelle der Vergleich von Safety und Security um Unterschiede

6 FAZIT 13
und Gemeinsamkeiten in den Begriffen und in den Techniken klar zu machen.
Hier soll nochmal hervorgehoben werden, dass durch die immer weiter verbreitete
Vernetzung, die Safetygemeinde immer mehr auf die Techniken der
Securitygemeinde (wie zum Beispiel Datenverschlüsselung oder Datenintegrität)
zugreifen muss. Das Ziel sichere Systeme zu entwickeln wird nur gelingen
wenn beide Communities in Zukunft mehr zusammenarbeiten. Die Securitygemeinde
kann dabei vom größeren Erfahrungsschatz und ausgereifteren
Techniken der Safetygemeinde profitieren. Die Synergie der Zusammenarbeit
kann vielleicht helfen in Zukunft kleinere und größere Katastrophen zu
vermeiden.

7 LITERATUR 14
7 Literatur
Literatur
[Aut06] Autoren von Wikipedia.de. Wikipedia.de, 2006.
http://www.wikipedia.de.
[Bac06] Markus Back. Definition ist immer eine Frage der Perspektive, 2006.
http://www.polyscope.ch/UserFiles/File/polyscope/sicherheit-01-
06.pdf.
[Gen06a] Dr. Robert Genser. Critical Infrastructure. 2006.
[Gen06b] Dr. Robert Genser. Security of Safety-Critical Computer Systems
Subgroup. 2006.
[Gmb06] Leopold Kosta GmbH. Erste Umsetzung der IEC 61508. 2006.
[Hei06] Prof. M. Heisel. Embedded Systems, 2006. http://www.fb9dv.uniduisburg.de/se/en/education/ws0506/embsys/index.php.
[IEC98] IEC International Electrotechnical Commission. Functional safety
of electrical/electronic/programmable electronic safty-relevan systems,
1998.
[MBL] Lillian Rostad Inger Anne Tondel Maria B. Line, Odd Nordland.
Safety vs. Security.
[OH] Arno Meyna Olaf H.Peters. Handbuch der Sicherheitstechnik.
[Pfi04] Andreas Pfitzmann. Why safety and security should and will merge.
Why Safety and Security.pdf, 2004.