ICS Master+ - IAS - Universität Stuttgart
15.01.2015
INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG
Ringvorlesung: Forum Software
und Automatisierung
Softwareprüfung für „sichere“
(Safety + Security) Systeme
Name
Dr. Thomas Liedtke
thomas.liedtke@ics-ag.de
Funktion
R&D
Datum
15. Januar 2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Agenda
─
Vorstellung
─
Motivation – Einführung – Einordnung - Methoden
─
Safety - Besonderheiten
─
Safety vs. Security
─
Security - Besonderheiten
─
Zusammenfassung/ Ausblick
2
1
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Vorstellung wer bin ich?
 Dr. Thomas Liedtke
 Seit 01. Dezember 2007 bei der ICS AG tätig als Leiter Research & Development
 Senior Projektleiter sicherheitsgerichteter Projekte
 Leiter Competence Center
 Implementierung Software Reifegradmodelle
 Davor:
 Studium der Informatik mit Nebenfach Mathematik an der Universität Stuttgart
 Promotion Informatik/ Mathematik an der Universität Stuttgart
 14 Jahre bei Alcatel/ Alcatel·Lucent
 Bereich Vermittlungssysteme:
 Qualitätsabteilung/ SPI/ SEPG (CMM)/ Projektleiter für MOD-Projekte der DTAG
 Bereich Mobilfunk:
 Abteilungsleiter in der Entwicklung
 Oberprojektleiter für Mobilfunkprojekte (GPRS/ UMTS/ GSM/…)
 Bereich Übertragungssysteme:
 Leiter Supply Chain OND
 Leiter des RSLC (Repair Service Logistic Center) Weilimdorf
3
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Das Unternehmen
Umsatz in Mio. Euro
Rechtsform Aktiengesellschaft
Grundkapital 2,4 Mio. EUR
12,0
10,0
8,0
Vorstand
Franz-Josef Winkel, Cid Kiefer
6,0
4,0
Aktionäre
Die Familien: Hämer, Winkel und Kiefer
2,0
0,0
1966
Hauptstandort
Stuttgart
Geschäftsstellen
Berlin, Braunschweig, Ingolstadt, Immenstaad,
Leipzig, München, Rüsselsheim, Ulm
1978
1986
1988
2003
2011
1988
2003
2011
Anzahl der Mitarbeiter
140
Anzahl der Mitarbeiter 150+
120
100
Umsatz 12.500.000.- EUR
80
60
Handelsregister
Amtsgericht Stuttgart HRB Nr.: 18569
UST. Id.Nr: DE 147802488
40
20
0
1966
1978
1986
4
2
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Kunden nach Domänen
Automotive
Industrial Solutions
Transportation
Aero Space &
Defence
5
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Philosophie
Partner für den gesamten Produkt Life Cycle
Vordenken
 Machbarkeitsstudien, Evaluierungen
Beraten
Technologien

 Methoden
 Werkzeuge
 Standards
 Prozesse
Umsetzen

Systems und Safety Engineering
 Produkt Design und Entwicklung
 Kapazitäts- und Kompetenzergänzung
 Test und Validierung
 RAM und Safety Management
 Assessment
Betreuen

Maintenance von Software und
Systemen
V
6
3
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Agenda
─
Vorstellung
─
Motivation – Einführung – Einordnung - Methoden
─
Safety - Besonderheiten
─
Safety vs. Security
─
Security - Besonderheiten
─
Zusammenfassung/ Ausblick
7
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Motivation gestern: Spektakulärer Eisenbahnunfall
am Gare Montparnasse (Dienstag, 22.10.1895)
-> Systemgedanke!
8
Bildquelle: Wikipedia
4
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Motivation - heute
-> Virtualität/ Modellierung
„Der Wert von Sicherheit wird oft erst dann erkannt,
wenn sie nicht mehr gewährleistet ist“
9
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Komplexität der Anforderungen an technische
Systeme steigt
Industrie 4.0*)-Anwendungen (u.a. [SESAMO14, Svo10, Bau14]):
 Dezentralisierung von Steuerungen: z.B.: Energiegewinnung/ -verteilung,
wachsender Einsatz "SMARTer"/ unterschiedlichster Endgeräte, MES, Car2x,
einfachste Funktionen werden über mehrere Steuergeräte verteilt, Steuergeräte
kommunizieren über immer mehr Kommunikationskanäle/ Busse miteinander, ...
 Neuartige unterschiedlichste Endgeräte und Bedienungskonzepte: z.B.:
 Flexible Tablet-/ Touch-Steuerung einer begehbaren Maschine,
 Bessere Integration des Menschen (analog Automotive),
 WLAN an Maschinen, …
 Aktoren und Sensoren werden immer leistungsfähiger und intelligenter
 Erhöhte Anzahl von Sicherheitslücken: Jede neue Technologie, die
Sicherheitslücken schließt, bringt neue mit sich.
*) Industrie 4.0 hier: Vernetzung von CPS, Anlagen, Fabriken, Steuergeräten zur intelligenten
Fabrik im Internet der Dinge. Massenindividualisierte Produkte: Konsument gestaltet das
Produkt, Produktionsanlagen richten sich danach (autonom)
10
5
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Komplexität der Entwicklungsprozesse steigt
 Anlagenlebenszeiten (Investitionsgüter) werden länger; umgekehrt zu
Lebenszyklen von Software und Betriebssystemen
 Embedded-Systeme sind die „Dinge“:
 Mehrere Standards für jede Anforderung macht Entwicklungsprozesse komplex
 Mögliche Marktsegmentierung macht Economy-of-Scale unsicher
(Konsumgütermarkt, Industrieanwendungen, Cloud-Computing, TelecomInfrastrukturen, …)
 Standardisierung/ Player vs. Kosten
 „Trust“: richtige Technologien zeitnah und vertrauenswürdig liefern
 Infrastruktur für die „smarte“ Fabrik
 Statische Produktionsabläufe entwickeln sich zu dynamischen Prozessketten
 Vernetzung horizontal und vertikal: Flexibilität, Autonomie, Teleservices (z.B. Visual Online
Support), …
11
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Motivation/ Begriffe
 Verschiedene Begriffe sind in verschiedenen Domänen unterschiedlich belegt
 Verifikation: oft: überprüfen, ob Dinge richtig gemacht wurden (vertikal/ unten im V-Modell),
meist direkte Verknüpfung mit der Testdurchführung
 Validierung: oft: überprüfen, ob die richtigen Dinge gemacht wurden (horizontal/ oben im V-
Modell), nachweisen u.U. ohne direkte Testdurchführung
 Integration/ Testen/ Prüfen
…
 Wozu Prüfung?
 Softwaresysteme spielen in einem zunehmend großen Teil des Lebens eine wichtige Rolle:
 Steuerung von Transportmitteln,
 Steuerung von Kraftwerken,
 Assistenzsysteme in Autos,
 Smart Grid, IoT, Industrie 4.0
 Relativ neu: Security!
…
 Gefahr für Leib und Leben, Umwelt, Personenschäden, Sachschäden, finanzielle
Schäden, Imageschäden und Katastrophen sind möglich
12
6
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Berühmte Softwarepannen -> Notwendigkeit
 Fast der 3. Weltkrieg
 Ozonloch
 Ziviles Flugzeug als Kampfjet interpretiert
[DZGSP08]
13
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Prüfen und Testen sind „Vorschrift“…
 Beispiele:
 DIN EN 61508-3:2001 Anhang A - Leitfaden für die Auswahl der Verfahren und Maßnahmen

EN 50128:2011 Anhang A5 – Verifikation und Testen
[IEC-61508]
[EN-50128]
14
7
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Systematischer Ausfall nach IEC 61508-4
Im Folgenden geht es beim Testen/ Prüfen um systematische Ausfälle:
 Systematischer Ausfall (sind zu vermeiden):
 „Systematisches Versagen/ Ausfall, bei dem eindeutig auf eine Ursache geschlossen werden kann,
die nur durch eine Modifikation des Entwurfs oder des Fertigungsprozesses, der Art und Weise des
Betreibens, der Bedienungsanleitung oder anderer Einflussfaktoren beseitigt werden kann.“
 Zufälliger Hardwareausfall (unvorhergesehenes Verhalten ist sicher zu machen):
 „Ausfall, der zu einem zufälligen Zeitpunkt auftritt und der aus einem oder mehreren möglichen
Mechanismen in der Hardware resultiert, die zu einer Verschlechterung der Eigenschaften der
Bauteile führen.“
 Klassifizierung der Fehler anhand folgender Fragen:
 „War der Fehler zum Zeitpunkt der Inbetriebnahme bereits eingebaut?“
 „Ist der Ausfall prinzipiell reproduzierbar?“
 Wichtiges Unterscheidungsmerkmal:
 „Systemausfallraten, die aus zufälligen Hardwareausfällen herrühren, können mit vernünftiger
Genauigkeit statistisch quantifiziert werden, jene die durch systematische Ausfälle entstehen
nicht, weil die Ereignisse, die zu diesen führen, nicht leicht vorausgesagt werden können.“
15
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Anforderungen an die Softwareprüfung
 Fehlervermeidung:
 Fehler wie die auf den vorigen Folien beschriebenen sollten so weit wie möglich
ausgeschlossen werden oder gefunden werden, bevor sie sich auswirken
 Fehlervorhersagen
 Aussagen der Form „in welchem Teil der Software sind anteilsmäßig wie viele Fehler zu
erwarten?“ sollen gemacht werden können
 Risiko =
Wahrscheinlichkeit seines Eintretens x Schaden im Falle seines Eintretens
 Risiko soll minimiert werden
 Risikoreduktion durch Verringerung der
Wahrscheinlichkeit mit der ein Fehler
auftritt und durch die Begrenzung der
Konsequenzen von unvermeidbaren
Fehlern
16
8
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Was sind Softwarefehler?
Genaue Unterscheidung, was mit „Fehler“ gemeint ist
 Fehlhandlung (error): Mensch verursacht einen Fehler in der Software
 Fehlerzustand (defect oder fault): im Code einer Software, in einem System
oder in einem Dokument (z.B. inkorrektes Teilprogramm, inkorrekte Anweisung
oder inkorrekte Datendefinition), verursacht durch eine Fehlhandlung, kann zu
einer Fehlerwirkung führen
 Fehlerwirkung/ Fehlverhalten (failure): Wenn der Defekt im Code ausgeführt
wird, kann das System nicht das tun, was es tun sollte (oder etwas tun, was es
nicht tun sollte) und dabei eine Fehlerwirkung hervorrufen oder ausfallen.
 Im Englischen weitere Begriffe: mistake, bug, malfunction, issue, incident, flaw,
vulnerability, error-prone, …
 Beispiel: Telefon funktioniert nicht <- kein Freizeichen <- Codefehler
17
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Bringt Testen Vertrauensgewinn?
Ausführung des
Programms
18
→ Verhalten
(Semantik)
[Lie14]
9
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Grundsätze der Softwareprüfung
 Softwareprüfung kann nur gegen Vorgaben (Anforderungen/
Vergleichsresultate) erfolgen
 Prüfverfahren müssen definiert sein und reproduzierbare Ergebnisse liefern
 Prüfergebnisse müssen dokumentiert werden (Nachvollziehbarkeit)
 Erkannte Fehler müssen (üblicherweise) anschließend korrigiert werden, indem
die Fehlerursachen erkannt und behoben werden
 Systematisch prüfen
 Prüfung planen
 Prüfungen nach Vorschriften durchführen (am besten automatisiert ausführen)
 Nicht nur die Software selbst prüfen, sondern auch alle Dokumente im Umfeld (zum
Beispiel Anforderungen! Siehe Reviews)
 Testen ist:
 „der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines
Softwarebausteines relativ zu vorher festgelegten Anforderungen“ [Den91]
19
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Testen: Ziele und Probleme -1
 Fehlerzustände und –wirkungen nachweisen
 Durch Fehlerhandlungen Fehlerzustände provozieren
 Vertrauen in das Programm erhöhen
 Je weniger gefundene Fehler, desto höheres Vertrauen in die Software (manche nennen das
„Qualität“)
 Fehlerwirkungen vorbeugen
 Je früher Fehler entdeckt werden, …
 … desto billiger die Fehlerkorrektur
 … desto weniger Folgefehler
-> vgl. Methoden, die durch Konstruktion in frühen Phasen Fehler so unwahrscheinlich wie
möglich machen (Abstrakte Spezifikation, Modellierung, Generierung der Testspezifikation ...)
 Aber:
 Vollständiges Testen ist nicht möglich
 Vorsicht vor der Fehlermaskierung
 „keine Fehler“ heißt noch nicht „brauchbares System“
 Korrelation zum Lebenszyklusmodell. Z.B.: „Wie verträgt sich der Anspruch mit dem agilen
Manifest?“
20
10
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Testen: Ziele und Probleme -2
 Wann ist man fertig mit Testen?
 Aufwand verbraucht?
 Es werden wenige/ keine Fehler mehr gefunden?
 Termin für Auslieferung steht an?
 Tester fallen keine neuen Testfälle mehr ein?
 Nie?
 Umfang/ Abdeckungskriterium
 Anforderungsabdeckung
 Äquivalenzklassenabdeckung
 Komponentenabdeckung
 Strukturabdeckung (Instruktionsüberdeckung ; C0, C1, …)
 Integrationsschritteüberdeckung
 Traceabiltiy
 (Rück-)verfolgbarkeit von Anwendungsforderung -> Implementierung (Sourcecode-Funktion)
-> Testfall und zurück
 Keine Anwendung darf vergessen werden (zu implementieren, zu testen, …)
 Kein Sourcecode ohne Funktion
21
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Bewährte Vorgehensweise beim Test
 Rollen beachten (z.B. Testmanager, Testanalyst, Testspezialist, Test-
Automatisierer, Testsupport)
 Personaltrennung (besonders zwischen Entwickler und Tester!)
 Anforderungen/ Testspezifikation: Möglichst formal
 Mit dem Testen so früh wie möglich beginnen
 Nutzung des Pareto-Prinzips (Fehler sind nicht gleichverteilt, sondern häufen
sich)
 Nutzung von Regressiontests und Ergänzung durch neue Tests  der
Testresistenz entgegenwirken
 Testsautomatisierung um Häufigkeit von Regressionstests erhöhen zu können
 Anpassung der Tests an das System und die grundlegenden Anforderungen
 „Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der
Softwareentwicklung, aber oft die letztmögliche. Je später Fehler entdeckt
werden, desto aufwändiger ist ihre Behebung …“ [Spi04]
22
11
15.01.2015
Sichten auf Programmanalyse
Überblick Analysemethoden
Dynamische
Programmanalyse
4 Schichten Modell
Experimente
Induktion
Beobachtung
Deduktion
Deduktion
Statische
23
Programmanalyse
[Zel03]
23
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Methoden statisch vs. dynamisch
 Review
 Feststellung von Mängeln, Fehlern, Inkonsistenzen, Unvollständigkeiten, Verstößen gegen
Vorgaben, Richtlinien, Standards, Pläne
 Code-Inspektion
 Formalisiertes Review zur Qualitätseinschätzung
 Statische Analyse
 Werkzeuggestütztes Auffinden von Fehlern ohne direkte Ausführung des Systems
 Walkthrough
 Designer/ Programmierer führt Teammitglieder und andere Stakeholder durch ein Software-
Produkt, Teilnehmer stellen Fragen und geben Kommentare ab
 Symbolische Ausführung, Simulation
 Testen
 Intensives Testen von Systemen und Dokumentation kann helfen,
das Risiko, dass Probleme im operativen Betrieb auftreten, zu reduzieren
 Fehler vor der Freigabe in der operativen Verwendung finden und beheben
 Softwaretesten kann auch notwendig sein, um vertragliche oder
gesetzliche Vorgaben oder spezielle Industrienormen zu erfüllen.
24
12
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Unterscheidung Prüf- und Testverfahren
Dynamischer
Test
Symbolischer
Test
Formale
Verifikation
Verifizierende Verfahren
Statische
Analyse
Spezielle
Analysen
Analysierende Verfahren
Testende Verfahren
25
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Agenda
─
Vorstellung
─
Motivation – Einführung – Einordnung - Methoden
─
Safety - Besonderheiten
─
Safety vs. Security
─
Security - Besonderheiten
─
Zusammenfassung/ Ausblick
26
13
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Beschreibung von Safety
Safety: Schutz vor (unbeabsichtigter) Fehlfunktion
 Realisierte Ist-Funktionalität entspricht spezifizierte Soll-Funktionalität
 Funktionalität unter allen (normalen) Betriebsbedingungen
 Dependabilty (Verlässlichkeit), RAMS (Reliability (Zuverlässigkeit), Availability
(Verfügbarkeit), Maintainability, Safety), FuSi (Funktionale Sicherheit)
Safety braucht Security
 Gesicherte Nachrichtenübermittlung Stellwerk zu Weiche
27
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Funktionale Sicherheit in diversen Szenarien
Systemversagen,
Vogelschlag
Verkehrsführung,
Wetter, Human Factor
Material
Systematischer Ausfall vs. Zufälliger Ausfall
28
Konzeption,
Common Cause
Bildquelle: Wikipedia
14
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Risikograph: Implizites Risikoakzeptanzkriterium
29
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Beispiel ASIL-Einstufung - Automotive
[Sch12]
30
15
15.01.2015
Entwicklungsprozesse und deren
Wechselwirkungen
31
Automotive Safety Standard ISO 26262
V
V V
[ISO26262]
32
16
15.01.2015
Vereinfachte Darstellung einer beispielhaften
Struktur von Abhängigkeiten
SoftwareValidierung
Technische
Anforderungen
SoftwareArchitektur
ValidierungsTestspezifikation
Validierungstestprotokoll
IntegrationsPrüfspezifikation
Integrationsprüfbericht
ModellPrüfspezifikation
Modellprüfbericht
ModellDokumentation
Modelle
ModulSpezifikation
ModulPrüfspezifikation
C-Code
33
Modulprüfbericht
Statischer
Analysebericht
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Teststufen im Beispiel V-Modell
 Modultest: Aufdeckung aller Abweichungen der Implementierung von der
Modulspezifikation
 Integrationstest: Aufdeckung von Fehlern in Schnittstellen und im
Zusammenspiel zwischen integrierten Modulen
 Systemtest: Aufdeckung aller Abweichungen des Systemverhaltens in Bezug
auf das in der Anforderungsdefinition spezifizierte Systemverhalten
 Abnahmetest: Aufdecken aller Fehler, die auf Missverständnissen bei
Absprachen zwischen Benutzer und Entwickler, falschen Schätzungen von
Datenmengen, unrealistischen Annahmen bezüglich der realen
Systemumgebung beruhen
34
17
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Testvorgehensweise - Beispiel
1. Vorbereitung des Testobjekts
2. Bereitstellung einer Testumgebung

Simulation der realen Einsatzbedingungen für ein Testobjekt

Ggf. auch (noch) nicht vorhandener Ressourcen oder Daten oder Nachrichten …
3. Testfallermittlung

Blackbox-Ansätze: Spezifikationsbasiert (Äquivalenzklassenbildung, Grenzwertanalyse,
Ursachen-Wirkungsanalyse, Error Guessing)

Whitebox-Ansätze: Implementierungsbasiert (Anweisungs- / Zweig- / Pfadüberdeckung,
Datenflussanalyse, Symbolischer Test)

Erfahrungsbasierte Verfahren
4. Auswahl geeigneter Testfälle und Testdaten

Meist stichprobenartig, um mit möglichst wenigen Tests möglichst viele Fehler finden zu
können, idealerweise (zum Teil) automatisierbar

welche Abläufe sind wichtig /häufig / typisch, wichtig auch „Randfälle“
5. Testausführung
6. Testauswertung
35
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Testdokumentation nach der IEEE 829
 Übersicht - Testplan
 Testplan: Umfang, Vorgehensweise, Terminplan, Testgegenstände
 Testspezifikation (test specification)
 Testdesignspezifikation: Die im Testplan genannten Vorgehensweisen im Detail.
 Testfallspezifikationen: Die Umgebungsbedingungen, Eingaben und Ausgaben eines jeden
Testfalls.
 Testablaufspezifikationen: In Einzelschritten, wie jeder Testfall durchzuführen ist.
 Test-(Ergebnis-) Beschreibung (test reporting)
 Testobjektübertragungsbericht: Wann wurden welche Testgegenstände an welche Tester
übergeben
 Testprotokoll: Chronologisch alle relevanten Vorgänge bei der Testdurchführung
 Testvorfallbericht: Alle Ereignisse, die eine weitere Untersuchung erforderlich machen.
 Testergebnisbericht: Beschreibt und bewertet die Ergebnisse aller Tests.
36
18
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Agenda
─
Vorstellung
─
Motivation – Einführung – Einordnung - Methoden
─
Safety - Besonderheiten
─
Safety vs. Security
─
Security - Besonderheiten
─
Zusammenfassung/ Ausblick
37
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Safety versus Security
38
19
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Sichere Systeme
Safety
Betriebssicherheit
Security
Angriffssicherheit
Zuverlässigkeit,
Verlässlichkeit
Schutz vor Angriffen
Ausfallsicherheit
Schutz der
Sicherheitsziele gegen
Bedrohungen
Verhinderung v. Schäden
(Personen, Sachen,
Umwelt)
Vertraulichkeit, Integrität,
Verfügbarkeit,
Verbindlichkeit
39
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Safety vs. Security
Safety
Mensch/ Umwelt
M/U darf durch TS nicht
gefährdet werden
Technisches System
Gefährdung des TS
durch M/U darf keine
Konsequenzen haben
Mensch/ Umwelt
Security
TS = Technisches System
M/U = Mensch und Umwelt
40
20
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Agenda
─
Vorstellung
─
Motivation – Einführung – Einordnung - Methoden
─
Safety - Besonderheiten
─
Safety vs. Security
─
Security - Besonderheiten
─
Zusammenfassung/ Ausblick
41
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Beschreibung (IT-) Security
(IT-) Security: Schutz vor (absichtlichen) Angriffen
 Stellt Funktionale Korrektheit bei aktiven Attacken sicher (System, Kontrolle,
Zugriffsschutz, …)
Security darf Safety nicht stören
 Performance: Codierte vs. chiffrierte Nachrichten bei ABS
 Maintainability vs. Obfuscation
 Umso mehr fortgeschrittene computer-kontrollierte Safety-Features verwendet
werden, desto anfälliger sind Safety-critical Aktionen gegenüber Angriffe (s.z.B.
CAN-Message-Injection [MiVa2014])
 Security will i.G. zu Safety geschlossene Türen:
 Geschlolssene Türen zw. Cockpit und Passagieren vs. einfachem Luftdruckausgleich
 Automatisches Türschließen beim Anfahren im Auto vs. einfaches Retten beim Unfall
42
21
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Bemerkungen/ Beispiele
Security Störfälle können die Verlässlichkeit von Systemen beeinträchtigen
 Konsequenz: Limitierung von Nutzbarkeit und Safety bis hin zu (D) Denial of Service
Verlässlichkeit bestimmt die Wahrscheinlichkeit für den Verlust von Security
 SCADA: Attacke durch ungesicherte Kommunikationskanäle (Australien
Maroochy Abwasserunfall, [SM08])
 Automotive: Angriff über ungesicherte Schnittstellen, [CMK+11]
43
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
(IT-) Security -1
Schutzziele (Assets): schützende Güter: Informationen, Daten, Budget
 Zugriff ist zu beschränken/ kontrollieren.
 Nur frei für eindeutig identifizierte (zu verifizieren!) und autorisierte Subjekte
 Authentizität von Subjekten (Echtheit/ Glaubwürdigkeit). Bsp.: Benutzername
(account) + Passwort/ biometrische Merkmale,… (Credentials)
 Kryptografische Verfahren notwendig bei unsicheren Transportmedien
 Verfügbarkeit: autorisierten und berechtigten Subjekten ist Zugriff zu
ermöglichen
 Verbindlichkeit/ Zuordenbarkeit: Urheberschaft eines Zugriffs/ Aktion ist im
Nachhinein möglich
 Datenintegrität (integrity): zu schützende Daten können nicht unbemerkt/
unautorisiert manipuliert werden (Rechtefestlegung, Methoden)
 Informationsvertraulichkeit (confidentitiality): keine unautorisierte
Informationsgewinnung
Ausführliche Definitionen: Basiswerk: [Eck11]
44
22
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
(IT-) Security -2
 Schutzziele müssen zunächst definiert werden. Diese sind nicht automatisch
gleich Mensch, Leib, Leben und Umwelt
 Eine Sicherheitslücke in der IT-Sicherheit wird – einmal bekannt – mit großer
Wahrscheinlichkeit auch ausgenutzt werden. Bekannte Lücken müssen also
schnell geschlossen werden und können nicht statistisch erfasst werden
 Fehlverhalten sind meist Ergebnisse von Angriffen über mehrere (Zwischen-)
Stufen und nicht unabhängig. Sie können deshalb mit konventionellen SafetyMethoden nicht offenbart werden [Svo10]
 Stuxnet: Schadprogramm um das SCADA-System Simatic S7 (Siemens) zu
stören. Eingesetzt in Teheran in finnischen Geräten um Atomprogramm/
Urananreicherungsanlage oder Kernkraftwerk zu stören.
 10 Jahre Entwicklungszeit mit 5-10 Entwicklern
 1 Jahr um von Experten System nachzubauen
 Kenntnisse über unbekannte Sicherheitslücken mehrere Firmen
 Komplexer Verbreitungsweg
45
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Common Criteria für IT Security Evaluation: ISO/
IEC 15408
International harmonisierte Kriterien zur
Sicherheits-Evaluierung von IT-Technik
Katalog zur Spezifikation von
Sicherheitsanforderungen
Vergleichbarkeit der Ergebnisse von
Evaluierungen
Stufen der Vertrauenswürdigkeit (EAL)
Gefährdungsfaktoren:
 Höhere Gewalt (Blitzschlag, Feuer,
EAL 7
• Formal verifizierter Entwurf
und getestet
EAL 6
• Semi-formal verifizierter
Entwurf und getestet
EAL 5
• Semi-formal entworfen und
getestet
EAL 4
• Methodisch entwickelt,
getestet und durchgesehen
EAL 3
• Methodisch getestet und
überprüft
EAL 2
• Strukturell getestet
EAL 1
• Funktionell getestet
Überschwemmung, …)
 Fahrlässigkeit (Irrtum, Fehlbedienung,
unsachgemäße Bedienung, …)
 Vorsatz (Manipulation, Einbruch, Hacking,
Spionage, Sabotage, …)
 Technisches Versagen (Stromausfall, HW-
Ausfall, …)
 Organisatorische Mängel (unberechtigter
46
Zugriff, Raubkopie, ungeschultes
Personal, …)
23
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Normen/ Richtlinien -1
IT-Sicherheit für industrielle Leitsysteme – Netz- und Systemschutz: ISA 99/ IEC
62443 (Industrial Automation and Control Systems (IACS) Security)
 Empfehlungen für die Entwicklung, den Betrieb und die Beschaffung von IT-
Systemen in elektrischen, elektronischen und programmierbaren
Bahnsignalanlagen
 Risiken aufgrund von böswilligen Angriffen
 Zusätzliche Anforderungen an Systeme die sich durch Bedrohungen der
Security ergeben
Security
Assurance
Level
Bedeutung
Angriffe
Hilfsmittel
SL 1
Wissen
Ressource
Motivation
zufällig/ gelegentlich
SL 2
Absicht
einfach
allgemein
niedrig
gering
SL 3
Absicht
komplex
spezifisch
moderat
moderat
SL 4
Absicht
komplex
spezifisch
groß
hoch
47
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Normen/ Richtlinien -2
Reihe von Standards der IT-Sicherheit: ISO/ IEC 27k
 Erfüllungsgrad zur Konformität
 ISMS (Information Security Management System) kann nach 27001 beurteilt und
zertifiziert werden
 Vorgaben für Risikoanalyse und –bewältigung
 Ergänzbar durch den Grundschutzkatalog der BSI (Bundesamt für Sicherheit in
der Informationstechnik, https://www.bsi.bund.de/DE/Home/home_node.html )
[Wikipedia]
48
24
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Software Assurance Maturity Model (SAMM)
Open Web Application Security Project (OWASP) www.opensamm.org
Vier kritische Business Funktionen für Organisationen:
 Governance: managen von „overall“-SW-Aktivitäten
 Strategie, Metriken, Policy, Compliance, Schulung, Richtlinien, …
 Construction: Definition von Zielen und SW-Entwicklung, Produktmanagement,
Anforderungsanalyse, …
 Risikomanagement, Security-Anforderungen, Sicherheitsarchitektur, …
 Verification: Überprüfung und Test von bei der SW-Entwicklung produzierten
Artefakten
 Design Reviews, Code Reviews, Security Testing, …
 Deployment: Releaseverwaltung, Lieferung, Betrieb in Echtsystemen
49
Effektivität
der SecurityMethoden
steigern
Umfassend
Verstehen
von SecurityMethoden
Erhöhung
Effizienz
Startpunkt
initial
implizit
 Schwächenmanagement, Umgebungen härten, Ermöglichen des Betriebs
Beherrschung der
SecurityMethoden
s. Auch BSIMM (Building Security In Maturity Model)/ SDL (Security Development Lifecycle)
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Lösungskonzepte
Derzeit verstärkt verfolgt:
 Konsequente(re)s "Security by Design" (durch Norm geregelt)
 Standardisierung von Protokollen wie z.B. OPC UA
 Schulung/ Know-How- und Bewusstseinserhöhung/ Sensibilisierung
 „Drang“ zur Zertifizierung
 Einsatz von security-proven IT-Komponenten; Security-Gateway, Chrypt-Module
 Beobachtung von Anomalien (Vorbeugung von Zero-Day-Exploits)
50
25
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Beispiel 1 für Methoden: CORAS
Prozess zur Security-Risiko-Analyse (basierend auf AS/ NZS 4360 (australische/
neuseeländische Risikomanagementnorm (erste international akzeptierte
Risikomanagement-Norm))
Sprache/ Diagramme:
 grafische Sprache zur Unterstützung der Analyse
 Kommunikationsbasis/ Dokumentation
Semantik: schematische Übersetzung vom Diagramm in Sprache
Kalkül: Menge von Regeln für Diagramminterpretation
Editor: Tool zur Unterstützung der Diagrammerstellung
 Freies Tool: http://coras.sourceforge.net/downloads.html
Richtlinie zur optimalen Nutzung
51
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Beispiel 1 für Methoden: CORAS :
Risikomaßnahmen
Gefahren
Unerwünschte
Ereignisse
Assets
Schwachstellen
Angriffs-Szenario
Konsequenzen
RisikoMaßnahmen
52
Wahrscheinlichkeiten
p(Ereignis) +
Konsequenz ->
Risiko
26
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Beispiel 2: Model-Based Security Testing (MBST)
ITEA2-Projekt DIAMONDS (Fraunhofer Institut FOKUS, Berlin) [SGS12]
 Validierung von Software System-Anforderungen bezogen auf Security-
Eigenschaften (Vertraulichkeit, Datenintegrität, Authentizität, Verfügbarkeit, …)
 Systematische und effiziente Spezifikation und Dokumentation von Security-Test-
Objekten, Security-Testfällen und Security-Testsuiten
 Bestandteile:
 Security Funktionale Tests
 Model-Based Fuzzing
 Risiko- und Gefahren-orientiertes Testen
 Security Test-Pattern
 Aussagen der Studie:
 90% aller SW-Security Störfälle werden durch Angreifer, die Schwachstellen kennen
verursacht
 Die meisten Schwachstellen entstehen durch Software-Fehler oder Design-Mängel
 Systematisches Testen erhöht die Wahrscheinlichkeit Fehler und Schwachstellen
während Design aufzudecken.
53
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Agenda
─
Vorstellung
─
Motivation – Einführung – Einordnung - Methoden
─
Safety - Besonderheiten
─
Safety vs. Security
─
Security - Besonderheiten
─
Zusammenfassung/ Ausblick
54
27
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Zusammenfassung/ Ausblick
Weitere Stichwörter:
 Error seeding
 Model based testing
 Design oriented testing
 Toolsqualifikation (normengefordert)
 Nichtfunktionale Anforderungen
 …
55
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Zusammenfassung - Ausblick
Ausblick
Safety
functional
dimension
definition by…
will have an impact randomly/ by accident
simple and easy to understand
safety needs security
definition of assets: access, authenticity,
…
intentional attacks
in preparation (domain dependent)
people harms technical systems by
intention
attacker view: motivation, intention,
available tools, ressourced, skill, …
hazop, CRAMM, CORAS, ATA, …
not independant
security/ evaluation assurance
(confidence)
further operation in case of attacks
faile-secure, keep normal operation
(to) low: security only for safety/
availability first
will be exploited someday by someone
obfuscation; prevent re-engineering
security needs no safety
existing
not existing
functional safety/ RAMS
prevention of…
standards
accidential failures
well-known methods
technical systems harms people and
kind of hazard
environment without intention
risk for life and body/ environment; risk
parameter to define risk level
graph; frequency x damage
techniques
FMEA, hazop, FTA, …
failures are considered as … independant
safety integrity level/ performance level/
severity/ ranking according…
design assurance level/ …
operation mode
safe under normal conditions
reaction on events …
redundancy/ switch into fail-safe state
awareness
(known) gaps in a system…
implementation
dependency
willingness to pay additionally
for…
Security
attack
high: safety first
56
28
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Literatur/ Referenzen -1
 [Bau14] Vortrag Klaus Bauer, “Sicherheit aus dem Blickwinkel einer Maschine”; Kongress
Sicherheit und Automation 2014
 [CMK+11] Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav
Shacham, and Stefan Savage University of California, San Diego; Karl Koscher, Alexei
Czeskis, Franziska Roesner, and Tadayoshi Kohno University of Washington
“Comprehensive Experimental Analyses of Automotive Attack Surfaces”
(http://www.autosec.org/pubs/cars-usenixsec2011.pdf )
 [Den91] Ernst Denert: Software-Engineering. Springer, Berlin 1991, 1992
 [DZGSP08] CHIP, Markus Mandau, http://www.zehn.de/die-10-groeszten-software-pannen-
732-0, 2008
 [Eck11] Claudia Eckert: “IT-Sicherheit: Konzepte – Verfahren – Protokolle”; Oldenbourg
Wissenschaftsverlag; 2011
 [IEC-61508] Standard „Functional safety of electrical/electronic/programmable electronic
safety-related systems“
 [Lie14] „Dynamische Programmanalyse“ Seminar: Verfahren zur Analyse von
Programmcode. Julian Liedtke; 15.12.2014
 [MiVa2014] „A Survey of Remote Automotive Attack Surfaces“; Charlie Miller & Chris
Valasek; Black Hat USA 2014, Las Vegas; 2.- 7. August 2014
57
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Literatur/ Referenzen -2
 [Sch12] Vortrag D. J. Schwarz: „Einführung der ISO 26262 in die Automobilindustrie –
Umfängliche Prozesse nachhaltig in eine laufende Entwicklung integrieren“; 14.02.2012
 [SESAMO14] EU-ARTEMIS-Projekt (http://sesamo-project.eu/ )
 [SGS11] Ina Schieferdecker, Jürgen Großmann, Martin Schneider (Fraunhofer FOKUS;
“Model-Based Security Testing” (http://arxiv.org/pdf/1202.6118.pdf )
 [SM08] Jill Slay, Michael Mille, ifip, International Federation for Information Processing;
Critical Infrastructure Protection; “Chapter 6 LESSONS LEARNED FROM THE MAROOCHY
WATER BREACH” (http://www.ifip.org/wcc2008/site/IFIPSampleChapter.pdf )
 [Spi04] Basiswissen Softwaretest, Andreas Spillner, Tilo Linz, Dpunkt Verlag; Auflage: 2.
überarb. A. (2004)
 [Sto09] Ketil Stolen, SINTEF & UiO, „Security Analysis: The CORAS Approach“
 [Svo10] Milos Svoboda; 8. Safetrans Industrial day; „Safety and Security in Industrial
environments“
 [Zel03] A. Zeller. Program Analysis: A Hierarchy. Proceedings of ICSE Workshop on
Dynamic Analysis, (WODA 2003), 2003.
58
29
15.01.2015
IAS Ringvorlesung: Softwareprüfung für "sichere" Systeme
Glossar
59

BSI = Bundesamt für Sicherheit in der Informationstechnik

BSIMM = Building Security In Maturity Model

CEN = European Committee for Standardization

CRAMM = CCTA Risk Analysis and Management Method

CPS = Cyber-physisches System

DDoS = Distributed Denial of Service (Dienstverweigerung)

EAL = Evaluation Assurance Level

IEC = International Electrotechnical Commission

FOKUS = Fraunhofer Institut für Offene Kommunikationssysteme

ISMS = Information Security Management System

ISA = International Society of Automation

ISO = International Organization for Standardization

ITEA = Information Technology for European Advancement

MBST = Model Based Security Testing

MES = Manufacturing Execution System

OPC UA = OLE (Object Linking and Embedding) for Process Control
Unified Architecture

OWASP = Open Web Application Security Project

SAMM = Software Assurance Maturity Modell

SCADA = Supervisory Control and Data Acquisition
(Überwachen und steuern technischer Systeme)

SDL = Security Development Lifecycle

SEI = Software Engineering Institute

SIL = Safety Integrity Level

S(A)L = Security (Assurance) Level
Fragen/ Diskussion/ AOB
60
30
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising