FG Software-Test, Schwaben - asqf.de · INFORMATIK CONSULTING SYSTEMS AG FG Software-Test, Schwaben Security-Aspekte in der Entwicklung –Anders als Safety? Ort: Neu-Ulm Datum 15

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: [email protected]

90+30

mailto:[email protected]

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






─ 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


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?“


Material

(Funktionale) Sicherheit in diversen Szenarien

9

Konzeption,

Common Cause

Verkehrsführung,

Wetter, Human Factor

Systemversagen,

Vogelschlag


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


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


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


Risikograph: Implizites Risikoakzeptanzkriterium

13


Beispiel ASIL-Einstufung - Automotive

14[Sch12]


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


Geforderter Entwicklungsprozess: V-Modell

16


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


18






─ 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


Datenschutz: Art. 2 Abs. 1 GG: Persönlichkeitsrecht ->

Informationelle Selbstbestimmung

21


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)


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


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


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


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


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


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)


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


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


31






─ 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


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


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


Parallele Elemente im Safety- und Security-Prozess

36


[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


Security-Schwachstellen

39


[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


(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


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


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


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


45






─ 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


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


Interessenskonflikt. Beispiele: Implementierungs-

angriff; Seitenkanalangriff; Re-Engineering

49


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


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


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


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


54

Prozess/ Verfahren

Funktionale Anforderungen

ISA99 (International Automation and Control Systems

Security)

[ISA99]


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


https://www.bsi.bund.de/DE/Home/home_node.html

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


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


https://de.wikipedia.org/wiki/EN_ISO_27799

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)


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


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


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)


http://www.opensamm.org/

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


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


Beispiel für eine Security Analyse (CORAS)

64


65






─ 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


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


EU-Datenschutz Grundverordnung (EU-DSGVO)

69

[EU-DSGVO16] Stand: 17.07.2016


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


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


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


Suchmaschine für das Netz der Dinge

73


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]


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


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


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


http://www.autosec.org/pubs/cars-usenixsec2011.pdf

http://www.zehn.de/die-10-groeszten-software-pannen-732-0

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


http://sesamo-project.eu/

http://arxiv.org/pdf/1202.6118.pdf

http://www.ifip.org/wcc2008/site/IFIPSampleChapter.pdf

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


Fragen?

80

Kontakt:

Autor: Dr. Thomas Liedtke

E-Mail: [email protected]


mailto:[email protected]

Documents

FG Software-Test, Schwaben - asqf.de · INFORMATIK CONSULTING SYSTEMS AG FG Software-Test, Schwaben Security-Aspekte in der Entwicklung –Anders als Safety? Ort: Neu-Ulm Datum 15