Post on 20-Sep-2019
transcript
INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG
FG Software-Test, Schwaben
Security-Aspekte in der
Entwicklung – Anders als Safety?
Ort: Neu-Ulm
Datum 15. September 2016
Stand 637.2
E-Mail: thomas.liedtke@ics-ag.de
90+30
Worum es geht…
2
ASQF | FG Software-Test, Schwaben | Motivation
3
─ Vorstellung (Wer bin ich, wer ist die ICS AG?)
─ Safety vs. Security (Rekapitulation/ Basics)
─ Zielkonflikte (Beispiel eCall)
─ Was macht Security „so schwer“?
─ Was kann man dagegen „versuchen“?
─ Ausblick
Agenda
Dr. Thomas Liedtke
Seit 2007 bei der ICS AG tätig als Leiter der Unit Research & Development
Senior Projektleiter sicherheitsgerichteter Projekte
Leiter Competence Center/ externes Training
Implementierung Software Reifegradmodelle
IT-Sicherheitsbeauftragter nach BSI Grundschutz und 27001
Betrieblicher Datenschutzbeauftragte
Davor:
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
Mobilfunkprojekte (GPRS/ UMTS/ GSM/…)
Bereich Übertragungssysteme: Leiter Supply Chain OND
Leiter des RSLC (Repair Service Logistic Center) Weilimdorf
4
ASQF | FG Software-Test, Schwaben | Vorstellung
5
─ Vorstellung (Wer bin ich, wer ist die ICS AG?)
─ Safety vs. Security (Rekapitulation/ Basics)
─ Zielkonflikte (Beispiel eCall)
─ Was macht Security „so schwer“?
─ Was kann man dagegen „versuchen“?
─ Ausblick
Agenda
6
„gestern“ | Systemgedanke | Top-Down
Bildquelle: Wikipedia
-> sicheres System
Systemgedanke! System „Bahn“
Fahrdienstvorschriften und andere Regelwerke sind mit Blut geschrieben…
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Sicherheitsgrundsatz: Körperliche Abwesenheit ist
besser als Geistesgegenwart
7
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Die Evolution bevorzugt diejenigen die handeln, nicht diejenigen die denken
Beschreibung Safety
Safety: Schutz vor (unbeabsichtigter) Fehlfunktion (bei bestimmungsgemäßer
Verwendung)
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)
Abwesenheit unzumutbarer Risiken
Bei entsprechender Anwendung von Methoden sinkt die Anzahl von Unfällen
Viele bewährte Methoden in Normen festgeschrieben (mathem.; Top down)
Fehler vermeiden; gemachte finden; mit im Betrieb auftretenden umgehen
Im Notfall in sicheren Zustand wechseln
Safety „braucht“ Security
Fragil -> Robust8
„How much Security is safe enough?“
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Material
(Funktionale) Sicherheit in diversen Szenarien
9
Konzeption,
Common Cause
Verkehrsführung,
Wetter, Human Factor
Systemversagen,
Vogelschlag
ASQF | FG Software-Test, Schwaben | Safety vs. Security
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
Anzuwendende Methoden wie z.B. für das Prüfen und Testen
sind abhängig vom SIL „vorgeschrieben“
10
ASQF | FG Software-Test, Schwaben | Safety vs. Security
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.“
11
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Anforderungen an die Softwareprüfung in sicheren
Systemen
Fehlervermeidung:
Fehler so weit wie möglich nicht einbringen (konstruktiv z.B. durch Auswahl entsprechender
Programmiersprachen, Entwicklungsmuster, Coding Rules, …)
Fehlerentdeckung:
Eingebrachte Fehler vor Inbetriebnahme finden, bevor sie sich auswirken können (z.B.
Reviews, Inspektionen, Tests, …)
Fehlerbehandlung:
Auftretende Fehler im Betrieb entsprechend behandeln (z.B. Fail-Safe, Fail-Operation)
Fehlervorhersagen:
Aussagen der Form „in welchem Teil der Software sind
anteilsmäßig wie viele Fehler zu erwarten?“
sollen gemacht werden können
12
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Risikograph: Implizites Risikoakzeptanzkriterium
13
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Beispiel ASIL-Einstufung - Automotive
14[Sch12]
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Bewährte Vorgehensweisen (Safety)
Rollentrennung/ Personaltrennung
Starre horizontale (was leitet sich von was ab) und vertikale
Dokumentenstruktur (Plan -> Spezifikation -> Bericht)
Traceability: Anforderung -> Source Code -> Validierung
Höchstens/ Mindestens semi formale Beschreibungsformen (Anforderungen/
Testspezifikation, …)
(vollständiges) Testen auf jeder (Integrations-) Ebene
Testautomatisierung als Qualitätssicherung
(unabhängige) Validierung auf allen Ebenen: Anpassung der Tests an das
System und die grundlegenden Anforderungen (funktionale und strukturelle
Abdeckung)
Umsetzung der vorgegebenen Methodentabellen
15
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Geforderter Entwicklungsprozess: V-Modell
16
ASQF | FG Software-Test, Schwaben | Safety vs. Security
Beispiel: Teststufen im 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, falschen Schätzungen
von Datenmengen, unrealistischen Annahmen bezüglich der realen Systemumgebung
beruhen17
ASQF | FG Software-Test, Schwaben | Safety vs. Security
18
─ Vorstellung (Wer bin ich, wer ist die ICS AG?)
─ Safety vs. Security (Rekapitulation/ Basics)
─ Zielkonflikte (Beispiel eCall)
─ Was macht Security „so schwer“?
─ Was kann man dagegen „versuchen“?
─ Ausblick
Agenda
Safety vs. Security
19
Themen Safety Security
oberstes Ziel: Safety first Availability first
Verhalten … braucht Security … darf Safety nicht stören
Rückfallmodus Fail safe Fail secure
widersprechende
Implementierungen… will offene Türen … will geschlossene Türen
widersprechende Prozesseziele
… will einfachen leicht
verständlichen/ wartbaren
Code
… will den Code vor Reverse
Engineering schützen
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Vertrauen ist die neue Währung im Internet
20
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Datenschutz: Art. 2 Abs. 1 GG: Persönlichkeitsrecht ->
Informationelle Selbstbestimmung
21
ASQF | FG Software-Test, Schwaben | Zielkonflikte
eCall (emergency Call)
22
Auto
mit
Unfall
Oiriginal
Equipment
Manufacturer
Control Center
Öffentl. Safety
Antwort-Knoten
(PSAP)
Rettungs-
Service
eCall Center
Mobilfunk-
netzbetreiber
(MNO)
Rückruf
(GSM)
Automatischer
eCall (GSM)Rufweiterleitung
(fest)
Alarm (fest,
mobil)
Statistische
Daten (fest)
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Safety-Aspekt -1
eCall ist ein passives Sicherheitssystem
eCall wird
… Unfälle nicht vermeiden
… die Auswirkung wenn es einen Unfall gab lindern (s. Airbag)
Bewertung:
Nach einem schweren Unfall ist die Zeit bis Hilfe eintrifft um Verletzten zu helfen
ein kritischer Faktor
eCall kann durch sofortige präzise (ausführliche) Meldung diese Zeit verkürzen
Passiv Safety/ IVS (In Vehicle System)
23
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Safety-Aspekt -2
ASIL-Bestimmung:
Bestimmung der Versagenswahrscheinlichkeit im Anforderungsfall (PFD)
Parameter:
Durchschnittliche Anzahl Verletzter bei einem gemeldeten Unfall
Prozentzahl Verletzter die auch mit funktionierendem eCall sterben
Rate der Verletzten, die durch rechtzeitige medizinische Versorgung überleben
Untersuchungen kommen zum Schluss, dass bei vollständig abdeckender
Implementierung jährlich 200 – 2.000 Menschen vor dem Sterben bewahrt werden
können
24
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Security-Aspekt -1
mögliche Bedrohungen (Schutzziel Datenschutz/ Data Privacy):
akustische Innenraumüberwachung (zu jeder Zeit)
Fahrzeugverfolgung über das Internet
…
Security Schutzziele
Privacy/ Confidentiality
Access (Zugriff)
Integrity
Verfügbarkeit
25
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Security-Aspekt -2
Möglicherweise übermittelte Daten
Uhrzeit, Unfallzeitpunkt, Position (inkl. Spurrichtung), Grad der Deformierung
Identität des Autos, Fahrzeugtyp/ -klasse,
Mobilnumner der SIM-Karte die für eCall genutzt wird
Anzahl geschlossener Gurte/ belegte Sitzpositionen (-> #Opfer)
Anzahl und Position der ausgelösten Airbags (-> Art und Schwere)
Kilometerzähler Daten/ Black Box:
Lenkung, Beschleunigung, Geschwindigkeit, Bremsmanöver, Geschwindigkeitsprofil
ABS-Bremsdaten, ESP-Daten,
Erlaubte Geschwindigkeit
Antriebsart; Art des Treibstoffes, …
26
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Umfeld Gefährdungen
Telekomprovider (GSM,
mobil, fest, …)
- ausspähen von Daten im Netz durch Dritte
- Transfer von Daten durch Provider
- Transfer von Daten durch Mitarbeiter
- Mithören im Auto ohne aktivem Service
Provider des eCall-
Centers/ Kontrollzentrum
- ausspähen von Daten im Netz durch Dritte
- Transfer von Daten durch Provider
- Transfer von Daten durch Mitarbeiter
- Mithören im Auto ohne aktivem Service
Rettungs-Service …
Original Equipment
Manufacturer- Mißbrauch gesammelter (sensibler) Daten
Security-Aspekt -3
27
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Safety vs. Security
28
• Safety: möglichst viele „nützliche“
Daten, möglichst exakt, redundant,
schneller Zugriff um Notfallservice
zu optimieren
• Security: möglichst wenige
personalisierte/ sensible Daten
ohne Redundanz und Speicherung/
restriktiver Zugriff (minimal set of data)
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Analyse der Daten
29
Requirement: Transfering of car speed in
case of accidentassessment
feasibility from technical point of view yes, available on can bus, can be read from other
control units
safety, passive (minimizing consequences
of an accident)
meaningful, heaviness of accident can be
estimated (kinetic energy at 70 km/h is as double
as high as at 50 km/h)
security (privacy, data protection) problematic could be a conflicting interest with
driver
ASQF | FG Software-Test, Schwaben | Zielkonflikte
Technisch übermittelbare Daten
Uhrzeit, Unfallzeitpunkt, Position (inkl. Spurrichtung), Grad der Deformierung
Identität des Autos, Fahrzeugtyp/ -klasse,
Mobilnumner der SIM-Karte die für eCall genutzt wird
Anzahl geschlossener Gurte/ belegte Sitzpositionen (-> #Opfer)
Anzahl und Position ausgelöster Airbags (-> Art und Schwere)
Kilometerzähler
Black Box-Daten (u.a.):
Lenkung, Beschleunigung, Geschwindigkeit, Bremsmanöver, Geschwindigkeitsprofil
ABS-Bremsdaten, ESP-Daten,
Erlaubte Geschwindigkeit
Antriebsart; Art des Treibstoffes, …
Personenbezogene (sensible) Daten
30
ASQF | FG Software-Test, Schwaben | Zielkonflikte
31
─ Vorstellung (Wer bin ich, wer ist die ICS AG?)
─ Safety vs. Security (Rekapitulation/ Basics)
─ Zielkonflikte (Beispiel eCall)
─ Was macht Security „so schwer“?
─ Was kann man dagegen „versuchen“?
─ Ausblick
Agenda
„heute“ | Komponenten | Things | Bottom-Up
32
„Der Wert von Sicherheit wird oft erst dann erkannt,
wenn sie nicht mehr gewährleistet ist“
-> Virtualität/ Modellierung
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
Beschreibung (IT- und Informations-) Security
Security: Schutz vor (absichtlichen) Angriffen (und Zufällen/ Unglücke)
Stellt Funktionale Korrektheit bei aktiven Attacken sicher (System, Kontrolle,
Zugriffsschutz, …)
Security auch: Maß für Risikoreduktion bzgl. Safety
Schwachstellen werden gezielt gesucht und ausgenutzt (gehandelt)
Funktionalität muss erhalten bleiben
Security darf Safety nicht stören
Performance: Codierte vs. chiffrierte Nachrichten
Organisatorische Maßnahmen (z.B. Identifizierung/ Autentifikation)
Fortgeschrittene computer-kontrollierte Safety-Features vs. Angriffsfläche für
Safety-critical Aktionen (z.B. CAN-Message-Injection [MiVa2014])
Interessenskonflikt; induktiv; bottom up; Antizipieren
Fragil -> Robust -> Antifragil. Emergenz. „fit for the future“33
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
Komplexität und Umfang von Anforderungen an
technische Systeme steigt
Dezentralisierung von Steuerungen:
Verteilung „einfachster“ Anforderungen über mehrere Steuergeräte
Kommunikation von Steuergeräten über mehrere Kanäle/ Busse
Wachsender Einsatz unterschiedlicher „smarte“ Endgeräte und
Bedienungskonzepte:
Integration unterschiedlicher Systeme (z.B. Car2x, IoT, …)
Flexible Tablet-/ Touch-Steuerung/ Funktionsaufruf via App (Security an zweiter Stelle)
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
Offene Schnittstellen (USB, Bluetooth, WLAN, …)
Hang zu immer raffinierteren Services (realisiert in Software)
Industrie 4.0/ IIC/ Industrie du Futur, Internet der Dinge, Losgröße 1, Smart grid,
Smart City, Home Automation, …34
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
Komplexität der Entwicklungsprozesse steigt
Produktlebenszeiten (z.B. „System“ Auto) länger als Lebenszyklen von
Software und Betriebssystemen
Beispiel: eCall Übertragungstechnik vs. Lebensdauer Auto (OTA update? SW IVS)
Embedded-Systeme sind die „Dinge“:
Mehrere Standards für jede Anforderung machen Entwicklungsprozesse komplex
Mögliche Marktsegmentierung macht Economy-of-Scale unsicher
(Konsumgütermarkt, Industrieanwendungen, Cloud-Computing, Telecom-
Infrastrukturen, …)
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 →
Möglichkeit zur hohen Variantenzahl
Vernetzung horizontal und vertikal: Flexibilität, Autonomie, Teleservices
Standardisierung vs. Pragmatismus35
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
Parallele Elemente im Safety- und Security-Prozess
36
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
[GGH15+]
Safety
Security
KRITIS
Privacy
Beispiele für Zielkonflikte
37
Informationelle
SelbstbestimmungZutritt
Transparenz
Logdateien
Einführung in die Informationssicherheit | 4. Safety
Datensparsamkeit
Fortbestand
Firma/ Gesellschaft
Interessenskonflikt:
Mensch vs. Mensch
Korrelation Verkehrstote und Sicherheitseinrichtungen
38
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
Security-Schwachstellen
39
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
[https://web.nvd.nist.gov/view/vuln/statistics-results?adv_search=true&cves=on]
(IT-) Security – Datenschutzmanagement -1
Schutzziele (Assets): schützende Güter: Informationen, Daten, Budget
Zugriff ist zu beschränken/ kontrollieren (s.a. Zutritt, Zugang).
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/
Pseudoanonymisierung
Verfügbarkeit: autorisierten und berechtigten Subjekten ist Zugriff zu fest-
gelegten Zeiten im festgelegten Umfang zu ermöglichen
40
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
(IT-) Security – Datenschutzmanagement -2
Verbindlichkeit/ Zuordenbarkeit: Urheberschaft eines Zugriffs/ Aktion ist im
Nachhinein möglich. Revisionssicherheit/ nicht Abstreitbarkeit
Datenintegrität (integrity): zu schützende Daten können nicht unbemerkt/
unautorisiert manipuliert werden (Rechtefestlegung, Methoden, Signaturen, …)
Informationsvertraulichkeit (confidentitiality): keine unautorisierte
Informationsgewinnung. Datenschutz. (BDSG §9)
Transparenz: Verfahren sind vollständig dokumentiert
Ausführliche Definitionen: Basiswerk: [Eck11]
41
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
Schutzziele
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 (irgendwann) ausgenutzt werden. Bekannte Lücken
müssen also schnell geschlossen (s.a. Zero-Day-Exploit) 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 Safety-
Methoden nicht offenbart werden [Svo10]
Im Vergleich: Safety: Risiken mit sehr kleinen Wahrscheinlichkeiten werden in
weiteren Betrachtungen vernachlässigt
42
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
Security | Lehren
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
(zu damaliger Zeit) Völlig unterschätzt:
Größe der SW-Anteils in Produktionsanlagen
Technische Möglichkeit Laden von Schadsoftware in proprietären Systemen
Hohe Motivation der Angreifer (s.o.)
Potentielle Auswirkungen
43
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
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]
44
ASQF | FG Software-Test, Schwaben | Schwierigkeiten
45
─ Vorstellung (Wer bin ich, wer ist die ICS AG?)
─ Safety vs. Security (Rekapitulation/ Basics)
─ Zielkonflikte (Beispiel eCall)
─ Was macht Security „so schwer“?
─ Was kann man dagegen „versuchen“?
─ Ausblick
Agenda
Security aus Systemsicht
Normen/ Richtlinien für Organisationen/ Produkte Reifegradmodelle; Management
Systeme; Zertifikate
Systembetrachtung: Dekomposition; Assets; Angriffsszenarien;
Rückwirkungsfreiheiten
Secure Coding; Implementierung; Compiler-Optionen
Verifikation und Absicherung auch außerhalb ihrer funktionalen Spec
46
Keine Anforderungen verlieren
Prozess/
Vorgehensmodelldefinition
Management-/
Organisationsprozesse
Datenschutz, Datensicherheit
Risikoanalyse auf Systemebene;
Durchgängigkeit/ kritischer Pfad
Angriffsvektoren/ -szenarien;
Durchgängig sicherer SW-
Entwicklungsprozess
Modellierung/ Coding Standards
Defensiver Code/ MISRA/ CERT C
Penetrationstests; Fuzzy Tests; …
ASQF | FG Software-Test, Schwaben | Strategien
Teststrategien -1
Functional Testing
Erfüllung der Anforderungen (Kryptografie, Authentifizierungsprotokolle)
Abdeckung Sonderfälle/ Performancetests
Statistische Tests mit Zufallszahlen/ Abdeckung
Vulnerability Scanning
Aufspüren bekannter Sicherheitslücken/ -schwächen
(z.B. hartcodierte Passwörter/ offene Ports…)
Analyse der Konfiguration
Scan der Software auf Source- und Binary-Ebene
Schnittstellentests
47
ASQF | FG Software-Test, Schwaben | Strategien
Teststrategien -2
Systematic Fuzzing
Systematisches Einbringen/ Senden von Daten zum Auffinden von undokumentierten
unbekannten Verhalten/ Eigenschaften
Fuzzing von Protokollen/ SW-komponenten (z.B. MP3-Dateihandling)
Penetration Testing
Individuelle Tests um gefundene Schwächen auszunutzen/ Fault Injection um Routinehecks
zu umgehen
Ausnutzen von Implemnetierungsfehlern (z.B. Buffer Overflow)
Ausspähen geschützter Daten/ Manipulation von Nachrichten
Manuelle Vorbereitung und Verifikation der Ergebnisse.
Im Vergleich: Safety:
V-Modell/ Fehlerkombinationen auf jeder System-(Integrations-) Ebene
Verifikation/ Test/ Prüfung (Dinge richtig gemacht)
Validierung (die richtigen Dinge gemacht)
48
ASQF | FG Software-Test, Schwaben | Strategien
Interessenskonflikt. Beispiele: Implementierungs-
angriff; Seitenkanalangriff; Re-Engineering
49
ASQF | FG Software-Test, Schwaben | Strategien
Beispiele für Normen/ Standards im Bereich Security
• to handle the threat of intentional unauthorized electronic interaction to aircraft safety
Luftfahrt: RTCA DO-326A
• Stufen der Vertrauenswürdigkeit (EAL)
Common Criteria für IT Security Evaluation: ISO/ IEC 15408
• ISMS; domänenspezifische Ableitungen
Reihe von Standards der IT-Sicherheit: ISO/ IEC 27k
• Standard on Automotive Cybersecurity – Best Pracitces (USA)
SAE International J3061 – Cybersecurity Guidebook for Cyber-Physical Vehicle Systems
• Management; IT-Grundschutz; Risikomanagement; Notfallmanagement
BSI Grundschutzkataloge
• Leitfaden zur Anwendung der IEC 62443 für elektrische Bahn-Signalanlagen
DIN VDE V 0831-104
• 13-teilige Serie von Normen und Technischen Reports zur IT-Sicherheit von Automatisierungs- und Steuerungssystemen
ISA/ IEC 62443 Industrial Communication Networks
50
ASQF | FG Software-Test, Schwaben | Strategien
Luftfahrt: RTCA DO-326A
Zitat aus der RTCA DO-326A Airworthiness Security Process Specification:
„The guidance of this document adds to current guidance for aircraft
certification to handle the threat of intentional unauthorized electronic
interaction to aircraft safety … and is intended to be used in conjunction
with other applicable guidance material …“
„The document does not address:
Physical security or physical attacks on the aircraft (or ground element)
Airport, Airplane or Air Traffic Service Provider security (e.g. access to airplanes, ground
control facilities, data centers
Communication, navigation, and surveillance services managed by national agencies or
ther international equivalents (e.g. GPS, SBAS, GBAS, ATC communication, ADS-B)
„overall consistency between both processes (rem.: safety and security) should
be maintained, by ensuring that the security process considers the outputs of
the safety assessment process“
51
ASQF | FG Software-Test, Schwaben | Strategien
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,
Überschwemmung, …)
Fahrlässigkeit (Irrtum, Fehlbedienung,
unsachgemäße Bedienung, …)
Vorsatz (Manipulation, Einbruch, Hacking,
Spionage, Sabotage, …)
Technisches Versagen (Stromausfall, HW-Ausfall,
…)
Organisatorische Mängel (unberechtigter Zugriff,
Raubkopie, ungeschultes Personal, …)
52
•Formal verifizierter Entwurf und getestetEAL 7
•Semi-formal verifizierter Entwurf und getestetEAL 6
•Semi-formal entworfen und getestetEAL 5
•Methodisch entwickelt, getestet und durchgesehenEAL 4
•Methodisch getestet und überprüftEAL 3
•Strukturell getestetEAL 2
•Funktionell getestetEAL 1
ASQF | FG Software-Test, Schwaben | Strategien
ISA99: ISA/ IEC 62443
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, elektron. und programmierb. Bahnsignalanlagen
Risiken aufgrund von böswilligen Angriffen
Zusätzliche Anforderungen an Systeme die sich durch Bedrohungen der Security ergeben
Einteilung eines Systems in Zonen und Kanäle -> Komponentenbetrachtung
53
Security
Assurance
Level
Bedeutung
Angriffe Hilfsmittel Wissen Ressource Motivation
SL 1 zufällig/ gelegentlich
SL 2 Absicht einfach allgemein niedrig gering
SL 3 Absicht komplex spezifisch moderat moderat
SL 4 Absicht komplex spezifisch groß hoch
ASQF | FG Software-Test, Schwaben | Strategien
54
Prozess/ Verfahren
Funktionale Anforderungen
ISA99 (International Automation and Control Systems
Security)
[ISA99]
ASQF | FG Software-Test, Schwaben | Strategien
ISO 27k-Reihe -1
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 )
ISO = International Organization for Standardization
55
ASQF | FG Software-Test, Schwaben | Strategien
ISO 27k-Reihe -2
ISO/IEC 27000 – Information security management systems – Overview and vocabulary
ISO/IEC 27001 – Information security management systems – Requirements;
ISO/IEC 27002 – Code of practice for information security management;
ISO/IEC 27003 – Information security management systems – Implementation Guidelines
ISO/IEC 27004 – Information security management measurements
ISO/IEC 27005 – Information security risk management
ISO/IEC 27006 Information technology - Security techniques –
ISO/IEC 27007 Information technology - Guidelines for information security management systems auditing.
ISO/IEC TR 27008 Information technology - Security techniques - Guidance for auditors on information security
management systems controls.
ISO/IEC 27010: Information security management for inter-sector communications (draft)
ISO/IEC 27011: Information security management guidelines for telecommunications organizations
ISO/IEC 27012: Guidelines for Finance
ISO/IEC 27013: Guideline on the integrated implementation of ISO/IEC 20000-1 and ISO/IEC 27001
ISO/IEC 27014: Information security governance framework (draft)
ISO/IEC TR 27015: Information security management systems guidelines for financial and insurance sectors (draft)
ISO/IEC TR 27016: Auditing and Reviews
56
ASQF | FG Software-Test, Schwaben | Strategien
ISO 27k-Reihe -3
ISO/IEC 27017: Security techniques — Code of practice for information security controls for cloud computing services
ISO/IEC 27018: Security techniques — Code of practice for controls to protect personally identifiable information
processed in public cloud computing services
ISO/IEC TR 27019: Information security management guidelines, process control systems specific to the energy
industry
ISO/IEC 27031 business continuity
ISO/IEC 27032 Guidelines for Cybersecurity (herausgegeben im Juli 2012)
ISO/IEC 27033 Revision von ISO 18028 und umfasst sieben Unterteile:
ISO/IEC 27033-1 Guidelines for network security
ISO/IEC 27033-2 Guidelines for the design and implementation of network
ISO/IEC 27033-3 Reference networking scenarios - Threats, design techniques and control issues
ISO/IEC 27033-4 Securing communications between networks using security gateways - Risks, design
techniques and control issues
ISO/IEC 27033-5 Securing virtual private networks - Risks, design techniques and control issues
ISO/IEC 27033-6 Securing communications across networks using Virtual Private Networks
ISO/IEC 27033-7 Guidelines for the design and implementation of network security
ISO/IEC 27034 Guidelines for application security
ISO/IEC 27035 Information security incident management
EN ISO 27799 Sicherheitsmanagement im Gesundheitswesen bei Verwendung der ISO/IEC 2700257
ASQF | FG Software-Test, Schwaben | Strategien
BSI Grundschutzkataloge
58
100-1: Managementsysteme für Informationssicherheit
Anforderungen an das System (ISO 27.000)
100-2: IT-Grundschutz-Vorgehensweise
Wie setzt man 100-1 praktisch um ? (ISO 27.000)
100-3: Risikomanagement
Risikoanalysen für Besonderheiten erstellen (BSI)
100-4: Notfallmanagement
Business Continuity Management (ISO 20.000, ITIL)
Grundschutzkataloge über 5.000 Seiten pdf
Bausteinkataloge (Übergreifende Aspekte, Infrastruktur, IT-Systeme, Netze, Anwendungen)
Gefährdungskataloge (Elementare Gefährdungen, Höhere Gewalt, Organisatorische
Mängel, Menschliche Fehlhandlungen, technisches Versagen, vorsätzliche Handlungen)
Maßnahmenkataloge (Infrastruktur, Organisation, Personal, HW & SW, Kommunikation,
Notfallvorsorge)
ASQF | FG Software-Test, Schwaben | Strategien
BSI Grundschutzkataloge: IT-Grundschutz-
Vorgehensweise
Sicherheits-leitlinie
• Initiierung, Erstellung
• Umsetzung, Aufrechterhaltung
Sicherheits-konzeption
• Strukturanalyse, Organisation, Infrastruktur
• IT-Systeme, Anwendungen, Mitarbeiter
Auswahl
• Dokumentation implementierter Schutzmaßnahmen
• Auswahl zu implementierenden Schutzmaßnahmen
Risiko-Analyse
• Sicherheitsanalyse
• Maßnahmen für hohe und sehr hohe Schutzbedarfe
59
ASQF | FG Software-Test, Schwaben | Strategien
BSI Grundschutzkataloge. Beispiel: Behandlung von
Risiken (BSI 100-3)
Reduktion: weitere
Sicherheits-maßnahmen
Vermeidung: durch Um-
Strukturierung
Übernahme: Akzeptanz
Transfer: Übertrag an eine andere Institution
60
ASQF | FG Software-Test, Schwaben | Strategien
Software Assurance Maturity Model (SAMM)
Open Web Application Security Project (OWASP) www.opensamm.org
Vier kritische Business Funktionen für Organisationen (je drei Security Praktiken):
61
Implic
itsta
rtin
g
Unerfüllte Aktivitäten
Initia
l unte
rsta
ndin
g
Ad hoc Security-Methoden
Incre
asie
eff
icie
ncy
Effektivität der Security-Methoden steigern
Com
pre
hensiv
eM
aste
ry
Beherr-schung der Security-Methoden
s. Auch BSIMM (Building Security In Maturity Model)/ SDL (Security Development Lifecycle)
ASQF | FG Software-Test, Schwaben | Strategien
OWASP Top 10 Angriffe (Web-Anwendungen)
1. (1) Injection
2. (3) Broken Authentication and Session Management
3. (2) Cross-Site Scripting (XSS)
4. (4) Insecure Direct Object References
5. (6) Security Misconfiguration
6. (7) Sensitive Data Exposure
7. (8) Missing Function Level Access Control
8. (5) Cross-Site Request Forgery (CSRF)
9. (-) Using Components with known vulnerabilities
10.(10) Unvalidated Redirects and Forwards
62
ASQF | FG Software-Test, Schwaben | Strategien
CERT „X“ Secure Coding Standard
CERT – Computer Emergency Response Team
Behandlung von Coding Errors die Ursache von Software
Verwundbarkeiten. Wahrscheinlichkeiten für Ausnutzung und
Abhilfe
Kritisches Codieren Fehler die zu Buffer Overflow führen (z.B.
Integer Overflow)
98 Regeln (MISRA C*: 144 Regeln; nicht ausreichend!!)
63
ASQF | FG Software-Test, Schwaben | Strategien
Beispiel für eine Security Analyse (CORAS)
64
ASQF | FG Software-Test, Schwaben | Strategien
65
─ Vorstellung (Wer bin ich, wer ist die ICS AG?)
─ Safety vs. Security (Rekapitulation/ Basics)
─ Zielkonflikte (Beispiel eCall)
─ Was macht Security „so schwer“?
─ Was kann man dagegen „versuchen“?
─ Ausblick
Agenda
Zulassung von Systemen
Zentrale Steuerungen werden von einer (unabhängigen) Kontrolleinheit
überwacht (IEC 61508)
Teile eines Systems sind selbst für Safetyzuständig (Bsp. ABS, Assistenzsysteme, …;
ISO 26262)
Zulassung Produkt/ Serie: Geschlossene
statische Systeme zur Entwicklungszeit
Offene, dynamische (sich selbst
konfigurierende) Systeme zur Betriebszeit
66
Zeit
ASQF | FG Software-Test, Schwaben | Ausblick
Zusammenfassung/ Ausblick | Lösungsansätze
Derzeit verstärkt verfolgt:
Konsequente(re)s "Security by Design" (durch Norm geregelt)
Standardisierung von Protokollen im Internet der Dinge/ Industrie 4.0 wie z.B.
OPC UA/ MQTT/ …
Schulung/ Know-How- und Bewusstseinserhöhung/ Sensibilisierung
„Drang“ zur Zertifizierung
Einsatz von security-proven IT-Komponenten; Security-Gateway, Crypt-
Module
Beobachtung von Anomalien (Vorbeugung von Zero-Day-Exploits)
67
ASQF | FG Software-Test, Schwaben | Ausblick
Zusammenfassung/ Ausblick | Aktuelle Themen
Weitere Stichwörter:
Error seeding/ Honey Pots
Model based testing (MBT) for Security
(auch Fuzzing)
Nichtfunktionale Anforderungen
Emergente Systemeigenschaften
fragil -> robust -> antifragil
Induktiv vs. deduktiv…
Lernende Modelle: Antizipation
Privacy by Design
68
ASQF | FG Software-Test, Schwaben | Ausblick
EU-Datenschutz Grundverordnung (EU-DSGVO)
69
[EU-DSGVO16] Stand: 17.07.2016
ASQF | FG Software-Test, Schwaben | Ausblick
Privacy by Design Prinzipien
70
Proaktiv statt reaktiv; Präventiv statt sanieren
Datenschutz als Default
Datenschutz im Design eingebettet (kein add-on)
Volle Funktionalität, keine Nullsumme
Schutz über den gesamten Lebenszyklus
Sichtbarkeit und Transparenz
Respekt vor Datenschutz der Nutzer
ASQF | FG Software-Test, Schwaben | Ausblick
Privacy Design Strategien - Datenorientiert
Minimise
Menge pb Daten, die verarbeitet wird muss auf ein Minimum beschränkt werden
Select before you collect; anonymisation and use pseudonyms
Hide
Vertraulichkeit: pb Daten können nicht von allen eingesehen werden
Vorsicht bei der Benutzung von ID‘s
Encryption of date; mix networks; unlink certain related events; anonymisation; pseudonyms
Separate
Getrennte Datenhaltung; Tabellen über mehrere DBs; lokale Datenverarbeitung;
keine ID‘s
Keine speziellen Patterns bekannt
Aggregate
Verarbeitung auf oberster Verdichtungsebene bei geringst möglicher Detailtiefe
Aggregation over time; dynamic location granularity; k-anonymity; differential privacy; …71
ASQF | FG Software-Test, Schwaben | Ausblick
Privacy Design Strategien - Prozessorientiert
Inform
Transparenz der Verarbeitung bzgl. Art der Information; Zweck mit welchen
Mitteln
Transparenz bzgl. Informationsschutz; Zugriffsrechte; Zugriff Dritter
Privacy Preferences Platform P3P, Data breach notifications, …
Control
Gegenstück zu Inform: Recht Daten einzusehen, aktualisieren, löschen
User-centric identity management; end-to-end encryption support control
Enforce
Gesetzeskonforme Datenschutzrichtlinie deren Umsetzung eingefordert wird
Access control; Datenschutzmanagement; Digitales Rechtemanagement; Lizenzen
Demonstrate
DSB, Konformität zeigen, Enforce ist unter Kontrolle; Abweichung?
Datenschutzmanagementsysteme; Protokolle; Audits72
ASQF | FG Software-Test, Schwaben | Ausblick
Suchmaschine für das Netz der Dinge
73
ASQF | FG Software-Test, Schwaben | Ausblick
Besondere Anforderungen an kritische Infrastrukturen
(KRITIS)
Kritische Infrastrukturen im Sinne des
§2 IT-Sicherheitsgesetzes sind:
Einrichtungen, Anlagen oder Teile davon die
Den Sektoren Energie, Informationstechnik, und
Telekommunikation, Transport und Verkehr,
Gesundheit, Wasser, Ernährung sowie Finanz- und
Versicherungswesen angehören und …
…von hoher Bedeutung für das funktionieren
des Gemeinwesens sind, weil durch Ausfall oder
Beeinträchtigung erhebliche Versorgungsengpässe
oder Gefährdungen für die öffentliche Sicherheit
eintreten würde.
KRITIS werden durch die Rechtsverordnung (RVO)
nach §10 Abs.1 IT-SiG näher bestimmt
Festlegung durch Branchenspezifischen
Schwellenwerte in den RVO
74
[KRITIS-VO; IT-SG]
ASQF | FG Software-Test, Schwaben | Ausblick
Welche Bereiche aus dem KRITIS Sektor existieren
Ziel des Gesetzes ist die (unbedingte) Verfügbarkeit von
Kritischen Infrastrukturen (KRITIS), u.a. Energie und
Transport & Verkehr, auch bei Cyberangriffen
Fristen zur Umsetzung der RVO erfolgt in zwei Stufen
Korb 1 :Energie, Wasser, Ernährung, IT / TK –
Erbringung des Nachweises bis Mitte 2018
Korb 2 :Transport und Verkehr, Gesundheit,
Finanz- und Versicherungen – Erbringung des
Nachweises bis Ende 2018
75
Überblick der
KRITIS Sektoren
ASQF | FG Software-Test, Schwaben | Ausblick
dimensionSafety
functional
Security
attack
definition by… functional safety/ RAMSdefinition of assets: access, authenticity,
…
prevention of… accidential failures intentional attacks
standards well-known methods in preparation (domain dependent)
kind of hazardtechnical systems harms people and
environment without intention
people harms technical systems by
intention
parameter to define risk levelrisk for life and body/ environment; risk
graph; frequency x damage
attacker view: motivation, intention,
available tools, ressourced, skill, …
techniques FMEA, hazop, FTA, … hazop, CRAMM, CORAS, ATA, …
failures are considered as … independant not independant
severity/ ranking according…safety integrity level/ performance level/
design assurance level/ …
security/ evaluation assurance
(confidence)
operation mode safe under normal conditions further operation in case of attacks
reaction on events … redundancy/ switch into fail-safe state faile-secure, keep normal operation
awareness high: safety first(to) low: security only for safety/
availability first
(known) gaps in a system… will have an impact randomly/ by accident will be exploited someday by someone
implementation simple and easy to understand obfuscation; prevent re-engineering
dependency safety needs security security needs no safety
willingness to pay additionally
for…existing not existing
Zusammenfassung/ Ausblick | Überblick
76
Ausblick
ASQF | FG Software-Test, Schwaben | Ausblick
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 )
[Dam07] Lars-Ola Damm „Early And Cost-Effective Software Fault Detection – Measurement And
Implementation in an Industrial Setting“; Doctoral Dissertation Series No. 2007:09; Blekinge Institute of
Technology; School of Engineering
[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
[GGH+15] Benjamin Glas, Carsten Gebauer, Jochen Hänger, Andreas Heyl, Jürgen Klarmann, Stefan Kriso,
Priyamvadha Vembar, Philipp Wörz, „Integration Challenges“, Konferenz Automotive Safety and Security 2015
IEC-61508] Standard „Functional safety of electrical/electronic/programmable electronic safety-related
systems“
77
ASQF | FG Software-Test, Schwaben | Ausblick
Literatur/ Referenzen -2
[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
[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.
78
ASQF | FG Software-Test, Schwaben | Ausblick
Glossar
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) Level79
ASQF | FG Software-Test, Schwaben | Ausblick
Fragen?
80
Kontakt:
Autor: Dr. Thomas Liedtke
E-Mail: thomas.liedtke@ics-ag.de
ASQF | FG Software-Test, Schwaben | Ausblick