Security-Aspekte in der Entwicklung Anders als Safety? · DIN EN 61508 -3:2001 Anhang A Leitfaden...

20.04.2016

1

INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG

11. Neu-Ulmer

Test-Engineering-Day 2016

Security-Aspekte in der

Entwicklung – Anders als Safety?Ort: ICS AG

Datum 21. April 2016

Stand 616.3

E-Mail: [email protected]

45+15

Motivation

2

11. Neu-Ulmer Test-Engineering-Day 2016 | Motivation

mailto:[email protected]

20.04.2016

2

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

Vorstellung Referent

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

11. Neu-Ulmer Test-Engineering-Day 2016 | Vorstellung

20.04.2016

3

5






─ Ausblick

Agenda

6

Motivation gestern: Spektakulärer Eisenbahnunfall am

Gare Montparnasse (Dienstag, 22.10.1895)

Bildquelle: Wikipedia

-> sicheres System

Systemgedanke! System „Bahn“

Fahrdienstvorschriften und andere Regelwerke sind mit Blut geschrieben…

11. Neu-Ulmer Test-Engineering-Day 2016 | Safety vs. Security

20.04.2016

4

Sicherheitsgrundsatz: Körperliche Abwesenheit ist

besser als Geistesgegenwart

7


Beschreibung von 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

Fehler vermeiden; gemachte finden; mit im Betrieb auftretenden umgehen

Im Notfall in sicheren Zustand wechseln

Safety „braucht“ Security

Beispiel: Gesicherte Nachrichtenübermittlung Stellwerk zu Weiche

8


„How much Security is safe enough?“

20.04.2016

5

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

[IEC-61508] [EN-50128]


20.04.2016

6

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


20.04.2016

7

Risikograph: Implizites Risikoakzeptanzkriterium

13


Beispiel ASIL-Einstufung - Automotive

14[Sch12]


20.04.2016

8

Bewährte Vorgehensweisen (Safety)

Rollentrennung/ Personaltrennung

Dokumentenstruktur: Plan -> Spezifikation -> Bericht

Traceability: Anforderung -> Source Code -> Validierung

Anforderungen/ Testspezifikation: mindestens semi formal

Mit dem Testen so früh wie möglich (auf jeder Ebene) beginnen

Testsautomatisierung um Häufigkeit von Regressionstests erhöhen zu können

Validierung: Anpassung der Tests an das System und die grundlegenden

Anforderungen (funktionale und strukturelle Abdeckung)

Anwendung von Methodentabellen aus entsprechenden Standards

15


Entwicklungsprozess: V-Modell

16


20.04.2016

9

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, falschen

Schätzungen von Datenmengen, unrealistischen Annahmen bezüglich der realen

Systemumgebung beruhen17


18






─ Ausblick

Agenda

20.04.2016

10

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

11. Neu-Ulmer Test-Engineering-Day 2016 | Zielkonflikte

Informationelle Selbstbestimmung?

20

„Vertrauen ist die neue Währung im Internet“


20.04.2016

11

eCall (emergency Call)

21

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)

22


20.04.2016

12

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 Menschen vor dem Sterben bewahrt werden können

23


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

24


20.04.2016

13

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, …

25


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

26


20.04.2016

14

Safety vs. Security

27

• 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

28

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


20.04.2016

15

29






─ Ausblick

Agenda

Motivation - heute

30

„Der Wert von Sicherheit wird oft erst dann erkannt,

wenn sie nicht mehr gewährleistet ist“

-> Virtualität/ Modellierung

11. Neu-Ulmer Test-Engineering-Day 2016 | Schwierigkeiten

20.04.2016

16

Safety vs. Security

31

Safety

Security

Technisches

System

Mensch/ Umwelt

Mensch/ Umwelt

M/U darf durch TS nicht

gefährdet werden

Gefährdung des TS

durch M/U darf keine

Konsequenzen haben

TS = Technisches System

M/U = Mensch und Umwelt


Sichere Systeme

Safety

Betriebssicherheit

Zuverlässigkeit, Verlässlichkeit

Ausfallsicherheit

Verhinderung v. Schäden (Personen, Sachen,

Umwelt)

Security

Angriffssicherheit

Schutz vor beabsichtigten Angriffen und Zufällen

Schutz der Sicherheitsziele gegen

Bedrohungen

Vertraulichkeit, Integrität, Verfügbarkeit, Verbindlichkeit

32


20.04.2016

17

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, …33


34


20.04.2016

18

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+]

20.04.2016

19

Korrelation Verkehrstote und Sicherheitseinrichtungen

37


Security-Schwachstellen

38


[https://web.nvd.nist.gov/view/vuln/statistics-results?adv_search=true&cves=on]

20.04.2016

20

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, …)

Automotive Security auch: Maß für Risikoreduktion bzgl. Safety

Schwachstellen werden gezielt gesucht und ausgenutzt

Funktionalität muss erhalten bleiben

Security darf Safety nicht stören

Performance: Codierte vs. chiffrierte Nachrichten bei ABS

Maintainability: Verständlichkeit vs. Obfuscation

Fortgeschrittene computer-kontrollierte Safety-Features vs. Angriffsfläche für

Safety-critical Aktionen (z.B. CAN-Message-Injection [MiVa2014])

Interessenskonflikt39


(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


20.04.2016

21

(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 kleiner Wahrscheinlichkeit können in

weiteren Betrachtungen vernachlässigt werden

42


20.04.2016

22

Beispielangriff

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

Völlig unterschätzt:

Wie groß der SW-Anteil inzwischen in Produktionsanlagen

Möglichkeit Laden von Schadsoftwrae in proprietären Systemen

Motivation der Angreifer

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


20.04.2016

23

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; …

11. Neu-Ulmer Test-Engineering-Day 2016 | Strategien

20.04.2016

24

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


20.04.2016

25

Implementierungsangriff vs. Seitenkanalangriff

49


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“

50


20.04.2016

26

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, …)

51

•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


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

52

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


20.04.2016

27

Trend in Richtung Security (62443 1-1)

53


ISO 27k-Reihe

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 )

55[Wikipedia]


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

20.04.2016

28

BSI Grundschutzkataloge

56


100-1: Managementsysteme für Informationssicherheit

100-2: IT-Grundschutz-Vorgehensweise

100-3: Risikomanagement

100-4: Notfallmanagement

Grundschutzkataloge fast 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

57


20.04.2016

29

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

58


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):

59 s. Auch BSIMM (Building Security In Maturity Model)/ SDL (Security Development Lifecycle)


http://www.opensamm.org/

20.04.2016

30

OWASP Top 10 Angriffe

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

60


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!!)

*) Motor Industry Software Reliability Association

61


20.04.2016

31

Beispiel für eine Security Analyse (CORAS)

62


63






─ Ausblick

Agenda

20.04.2016

32

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

64

Zeit

11. Neu-Ulmer Test-Engineering-Day 2016 | 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)

65


20.04.2016

33

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

66


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

67

Ausblick


20.04.2016

34

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“

68


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.

69


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

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

http://sesamo-project.eu/

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

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

20.04.2016

35

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) Level70


Fragen?

71

Kontakt:

Autor: Dr. Thomas Liedtke

E-Mail: [email protected]


mailto:[email protected]

Security-Aspekte in der Entwicklung Anders als Safety? · DIN EN 61508 -3:2001 Anhang A Leitfaden...

Documents

Transcript of Security-Aspekte in der Entwicklung Anders als Safety? · DIN EN 61508 -3:2001 Anhang A Leitfaden...