Systemsicherheit Kapitel 2: Sicherheitsanforderungen - Winfried E. Kühnhauser Sommer 2019 - TU Ilmenau
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Systemsicherheit
Kapitel 2: Sicherheitsanforderungen
Winfried E. Kühnhauser
Sommer 2019
Winfried E. Kühnhauser
CSI
Technische Universität Ilmenau
www.tu-ilmenau.de
Systemsicherheit, Sommer 2019 © wk -1-Sicherheitsanforderungen
Sicherheitspolitiken
Modellierung und Spezifikation
Sicherheitsmechanismen
Sicherheitsarchitekturen
Systemsicherheit, Sommer 2019 © wk -2- 2 SicherheitsanforderungenSecurity Engineering
Methodische Entwicklung sicherer IT-Systeme
Requirements Sicherheits-
Engineering anforderungen
Policy Sicherheits-
Engineering politik
Model Sicherheits-
Engineering modell
Architecture Sicherheits-
Engineering architektur
Systemsicherheit, Sommer 2019 © wk -3- 2 SicherheitsanforderungenSicherheitsanforderungen
Ziel
Methodische
Identifikation
Spezifikation
der Sicherheitseigenschaften von IT-Systemen
Systemsicherheit, Sommer 2019 © wk -4- 2 SicherheitsanforderungenEinflussfaktoren
Gesetze
◆ Europäische Datenschutz-Grundverordnung, US Sarbanes-Oxley Act
Verträge
◆ mit Kunden
Zertifizierung
◆ für das IT-Sicherheitsmanagement (ISO 27001)
◆ nach dem deutschen Signaturgesetz, den Common Criteria
firmenspezifische Richtlinien und Vorgaben
◆ Zugang zu kritischen Informationen, Berechtigungsvergabe
firmenspezifische informationstechnische Faktoren
◆ Systemarchitektur
◆ BS, DBMS, Applikationssysteme
→ mehr dazu: Master-Vorlesung „IT-Sicherheitsmanagement“
Systemsicherheit, Sommer 2019 © wk -5- 2 SicherheitsanforderungenKapitelüberblick
Identifikation informationstechnischer Sicherheitsanforderungen
Schwachstellenanalyse Bedrohungsanalyse
Risikoanalyse
vermeiden behandeln tragen
Sicherheitsanforderungen
Sicherheitspolitik
Systemsicherheit, Sommer 2019 © wk -6- 2 Sicherheitsanforderungen2.1 Schwachstellenanalyse
Ziel
Identifikation
menschlicher
organisatorischer
technischer
Verwundbarkeiten eines IT-Systems
Systemsicherheit, Sommer 2019 © wk -7- 2.1 Schwachstellenanalyse2.1.1 Menschliche Schwachstellen
Beispiele
Social Engineering
◆ der Chef, der Freund, die vergiftete Tochter, die wichtige Email
Bequemlichkeit; z.B.
◆ Passworte auf Post-It
◆ Vista Pop-up-Fenster
mangelndes Wissen, z.B.
◆ Einbringung von Schadprogrammen
◆ indirekte Informationsflüsse in Zugriffssteuerungssystemen →
Systemsicherheit, Sommer 2019 © wk -8- 2.1.1 Menschliche SchwachstellenIndirekte Informationsflüsse in Zugriffssteuerungssystemen
ProjectX
Bulletin
Anna Board
F&E ProjectX
Files Bernds
Bernd Notes
To Sales
X
Vertrieb Sales
(„Sales“) Flyer Chris
Systemsicherheit, Sommer 2019 © wk -9- 2.1.1 Menschliche SchwachstellenProjectX
Linux-System, 3 Benutzer: Anna, Bernd, Chris Anna
Bulletin
Board
F&E ProjectX
Files
Bernds
2 Gruppen: Bernd Notes
To Sales
CrewX: Anna (Projektleiterin), Bernd
Sales: Bernd, Chris
Sales
Vertrieb Flyer Chris
Kontext: Linux-Zugriffssteuerungssystem
rw- --- --- 1 Anna CrewX 2019-02-23 17:10 ProjectXFiles
rw- r-- --- 1 Anna CrewX 2019-02-23 17:10 ProjectXBoard
rw- r-- --- 1 Bernd Sales 2019-02-23 17:10 BerndsNotesToSales
rw- --- --- 1 Chris Sales 2019-02-23 17:10 SalesFlyer
Fazit
■ alle 3 Benutzer haben Rechte ihrer Dateien - aus ihrer Sicht - perfekt vergeben
■ gemeinsam haben sie eine Zeitbombe gebaut
Systemsicherheit, Sommer 2019 © wk - 10 - 2.1.1 Menschliche SchwachstellenProjectX
Files
Anna
Anna
Anna ProjectX
CrewX Bulletin
Board
Bernd
Bernd Bernds
Notes
Sales To Sales
Chris
Sales Chris
Flyer
Systemsicherheit, Sommer 2019 © wk - 11 - 2.1.1 Menschliche SchwachstellenFazit: Wirksamkeit wahlfreier Zugriffsschutzsysteme?
Problemursachen
mangelndes Wissen der Akteure
◆ begrenzter Horizont
◆ begrenztes Problembewusstsein
◆ begrenzte Fähigkeiten
Komplexität des Problems
◆ Auswirkungen individueller wahlfreier Rechtevergabe auf systemweite
Sicherheitseigenschaften
begrenzte Möglichkeiten der Akteure
◆ veraltete und ungeeignete Sicherheitsmechanismen
→ fehlende Isolation nicht vertrauenswürdiger Software
→ fehlende Durchsetzung systemweiter Sicherheitspolitiken
Systemsicherheit, Sommer 2019 © wk - 12 - 2.1.1 Menschliche Schwachstellen2.1.2 Organisatorische Schwachstellen
Beispiele
Zutritt zu Räumen
Berechtigungsmanagement
◆ 4-Augen-Prinzip
◆ Need-to-know-Prinzip
◆ Definition von Rollen
Management kryptografischer Schlüssel, z.B.
◆ Erstellung von Zertifikaten
◆ Schlüssel-Backups
→ Master-Vorlesung „IT-Sicherheitsmanagement“
Systemsicherheit, Sommer 2019 © wk - 13 - 2.1.2 Organisatorische Schwachstellen2.1.3 Technische Schwachstellen
Das Problem: Komplexe IT-Systeme ...
... werden in absehbarer Zeit nicht
vollständig, widerspruchsfrei, eindeutig und korrekt spezifiziert sein
→ enthalten Spezifikationsfehler
korrekt implementiert sein
→ enthalten Implementierungsfehler
jeden Tag neu gebaut werden
(viele Schutzmechanismen heutiger IT-Systeme sind > 50 Jahre alt)
→ enthalten konzeptionelle Schwächen
Systemsicherheit, Sommer 2019 © wk - 14 - 2.1.3 Technische SchwachstellenBeispiel: Implementierungsfehler
in privilegierter Systemsoftware
Betriebssystem
sshd-Dämonen, Webserver etc.
Folge
Privilegierte Software kann zur Ausführung von Angriffscode bewegt
werden
Technik
Geschickt geschmiedete Parameter überschreiben Prozedurframe
→ „Buffer Overflow“-Angriff
Systemsicherheit, Sommer 2019 © wk - 15 - 2.1.3 Technische SchwachstellenNotwendiges Wissen
Quellcode eines Prozesses (z.B. eines privilegierten Servers)
Symboltabelle dessen ausgeführten Programms
etwas Compilertechnik
◆ Variablenallokation
◆ Prozeduraufrufmanagement
... und das geht so →
Systemsicherheit, Sommer 2019 © wk - 16 - 2.1.3 Technische SchwachstellenPrinzip
Stack-Layout nach
Prozeduraufruf
kleine
void processSomeMsg(char *msg, Adressen i
int msgSize);
{ char localBuffer[1024];
int i=0; localBuffer
while (iAddress of
library function
“system“
Prinzip
msg: “\0 … \0 / b i n / s h e l l # s y s t e m “
1024 Zeichen Stack-Layout nach
Prozeduraufruf
kleine
void processSomeMsg(char *msg, Adressen i
int msgSize);
{ char localBuffer[1024]; = system(
int i=0; \0 … \0
localBuffer
“/bin/sh“)
/bin/sh
while (iBerühmt: cgiBin-Angriff auf nullhttpd Webserver
CGI (Common Gateway Interface): Schnittstellennorm für Datenaustausch mit
von Webservern aufgerufenen Programmen („plugins”)
vertrauenswürdige CGI-Programme: in bestimmten Verzeichnis („cgiDir“)
Programmcode in nullhttpd zum Aufruf eines CGI-Programms:
char cgiCommand[1024];
char cgiDir[1024]=“/usr/nullhttpd/bin/cgiBin“;
void processCgiRequest(char *msg, int msgSize);
{ int i=0;
while (i2.1.4 Zusammenfassung
Schwachstellen
menschliche
◆ Social Engineering
◆ Bequemlichkeit
◆ mangelndes Wissen
(e.g. über Schadprogramme, Schwächen von Mechanismen)
organisatorische
◆ Zugangsberechtigungen, Schlüsselmanagement
technische
◆ konzeptionelle Systemschwächen
◆ Spezifikations- und Implementierungsfehler
→ ein Zoo; praktische Hilfe beim Finden:
◆ Schwachstellenkataloge ISO 27001, ISO 27002
◆ automatische Werkzeuge (s. 2.2.2)
Systemsicherheit, Sommer 2019 © wk - 20 - 2.1.4 ZusammenfassungSchwachstellenanalyse Bedrohungsanalyse
✓
Risikoanalyse
vermeiden behandeln tragen
Sicherheitsanforderungen
Systemsicherheit, Sommer 2019 © wk - 21 - 2.1.4 Zusammenfassung2.2 Bedrohungsanalyse
Ziel
Identifikation der möglichen
Angriffsziele und Angreifer
Angriffsmethoden und -techniken
→ know your enemy
Weg
Erstellung eines Bedrohungskatalogs:
Identifikation möglicher Angriffsziele
Identifikation möglicher Angreifer
Identifikation möglicher Angriffsmethoden und -techniken
Schadenspotential
Systemsicherheit, Sommer 2019 © wk - 22 - 2.2 Bedrohungsanalyse2.2.1 Angriffsziele und Angreifer
Die Hitlisten
Angriffsziele
wirtschaftliche und politische Macht
finanzieller Gewinn
Schaden anrichten
Herausforderungen meistern
Angreifer
professionelle Organisationen
(beauftragt von Konkurrenzunternehmen, fremden Staaten)
aktive und ehemalige Mitarbeiter
Terroristen
Hacker
Systemsicherheit, Sommer 2019 © wk - 23 - 2.2.1 Angriffsziele und AngreiferBeispiel: Wirtschaftsspionage
Ziel: wirtschaftliche und politische Macht, finanzieller Gewinn
betroffen: High-Tech Industrie
Angreifer
◆ Konkurrenzunternehmen, Staaten (Außenstehende)
→ professionelle Organisationen
◆ Mitarbeiter (Insider)
• regulärer, oft privilegierter Zugang zu IT-Systemen
• hoher Anteil (>40%)
• oft indirekt („Only amateurs attack systems; professionals target people“)
• Alter 30-40 Jahre, männlich
• Abteilungsleiter, Systemadministrator, Programmierer
→ die eigenen Mitarbeiter
Systemsicherheit, Sommer 2019 © wk - 24 - 2.2.1 Angriffsziele und AngreiferBeispiel: Persönliche Bereicherung
Ziel: finanzieller Gewinn (kostspieliger Lebensstil, Krankheit)
Angreifer
◆ Konkurrenzunternehmen
◆ Mitarbeiter
• Alter 40-50 Jahre, Karrierehöhepunkt erreicht, midlife crisis
• männlich
→ regulärer Zugang zu IT-Systemen, Insiderkenntnisse
Beispiel: Schaden anrichten
Ziel: Erpressung, Herausforderungen meistern
Angreifer: Terroristen, Rächer, Psychos
→ kein regulärer Zugang zu IT-Systemen, keine Insiderkenntnisse
Systemsicherheit, Sommer 2019 © wk - 25 - 2.2.1 Angriffsziele und Angreifer2.2.2 Angriffsmethoden
Ausnutzung von Schwachstellen (s. 2.1)
menschliche Schwachstellen
◆ Social Engineering, Bequemlichkeit, Mangel an Wissen
organisatorische Schwachstellen
◆ Berechtigungsmanagement, Schlüsselmanagement, Bauliches
technische Schwachstellen
◆ konzeptionelle Schwächen, Spezifikations- und Implementierungsfehler
Systemsicherheit, Sommer 2019 © wk - 26 - 2.2.2 Angriffsmethoden4 Beispielszenarien
1. Beispiel: Insiderangriff
Angriffsmethode (siehe Beispiel in 2.1.1):
Social Engineering plus
Ausnutzung konzeptioneller Schwachstellen wahlfreien Zugriffsschutzes plus
Schadprogramm
ProjectX
Bulletin
Anna Board
F&E ProjectX
Files Bernds
Bernd
Notes
To Sales
X
Vertrieb Sales
(„Sales“) Flyer Chris
Systemsicherheit, Sommer 2019 © wk - 27 - 2.2.2 Angriffsmethoden2. Beispiel: Schadensprogramme; eine Familienchronik
Trojanische Pferde
Programme, die neben ihrer bekannten Funktion eine weitere, verborgene besitzen
◆ Computerviren
Codesequenzen in trojanischen Pferden, die eine Modifikations- und
Vervielfältigungsfunktion enthalten, oft auch eine Schadensfunktion
◆ Logische Bomben
Codesequenzen in trojanischen Pferden, deren Aktivierung an konkrete Ereignisse
gebunden ist (→ Michelangelo, Chevron)
◆ Hintertüren (backdoors)
Codesequenzen in trojanischen Pferden, deren Aktivierung an den Aufruf einer
verborgenen Funktionen gebunden ist (→ login, ssh)
Würmer, Wurmsegmente
Autonome Programme, sich selbst vervielfältigend; ursprünglich zur Nutzung freier
Rechenkapazität in Netzen entwickelt
Systemsicherheit, Sommer 2019 © wk - 28 - 2.2.2 Angriffsmethoden3. Beispiel: Outsiderangriff
Angriffsmethode (siehe Beispiel in 2.1.3):
Ausnutzung von Implementierungsfehlern
void processSomeMsg(char *msg, i
int msgSize);
{ char localBuffer[1024]; system(
int i=0; \0 … \0 “/bin/sh“)
while (iProfessionelle Angriffstechniken
4. Beispiel: Root Kits
Ziel: vollständige, unsichtbare, nachhaltige Kontrolle über ein IT-System
Methode: Werkzeugkasten für vollautomatisierte Angriffe
Im Werkzeugkasten: Werkzeuge für
vollautomatische Analyse technischer Schwachstellen
vollautomatisches Angriffsmanagement
vollautomatische Installation von Hintertüren
vollautomatisches Tarnsystem
Systemsicherheit, Sommer 2019 © wk - 30 - 2.2.2 AngriffsmethodenAngriffsablauf
Erster Schritt: Schwachstellenanalyse
Werkzeuge suchen Schwachstellen in
◆ aktiven privilegierten Diensten und Dämonen (von außen: port scans)
• Webserver, Remote Zugang (sshd), File Server (ftp), Zeitserver (ntpd),
cupsd, bluetoothd, smbd, ... (z.B.: https://www.wieistmeineip.de)
◆ Konfigurationsdateien
• schwache Passworte, offene Kommunikationsports
◆ Betriebssystemen
• bekannte Implementierungsfehler bestimmter Hersteller/BS-Versionen
Wissensbasis:
◆ umfassende Schwachstellendatenbank
Resultat
systemspezifische Schwachstellensammlung
→ Angriffsmethode und zugehörige Werkzeuge → zweiter Schritt
Systemsicherheit, Sommer 2019 © wk - 31 - 2.2.2 AngriffsmethodenZweiter Schritt: Angriffsmanagement
Fabrikation einer Reihe spezialisierter Software-Bausteine; damit
Nutzung der Schwachstelle so, dass
◆ Server oder Dämonenprozesse
◆ BS
Code des Angreifers mit Root-Privilegien ausführt
dieser Code
◆ installiert zunächst Nebelbomben zum Verstecken des Angriffs
◆ tauscht Originale gegen fabrizierte Softwarekomponenten aus
• Server oder Dämonenprozesse
• Dienstleistungsprogramme und Bibliotheken
• BS-Module
mit
• Hintertüren
• Nebelbomben für zukünftige Angriffe
Systemsicherheit, Sommer 2019 © wk - 32 - 2.2.2 AngriffsmethodenResultate
Hintertüren ermöglichen hochprivilegierten Zugang innerhalb von
Bruchteilen von Sekunden
System mit Servern, Dämonen, Utilities, BS-Modulen des Angreifers
modifiziert
Nebelbomben zum Verbergen dieser Modifikationen und zukünftiger
Angriffe
Systemsicherheit, Sommer 2019 © wk - 33 - 2.2.2 AngriffsmethodenNebelbomben für laufende Angriffe ...
reinigen Logfiles (Einträge über Root Kit Prozesse, Verbindungen)
◆ syslog, kern.log, user.log, daemon.log, auth.log, ...
modifizieren Admin-Utilities
◆ Prozessmanagement (Verbergen laufender Root Kit Prozesse)
• Unix: z.B. ps, top, gnome system manager; Windows: task manager
◆ Dateisystem (Verbergen von Root Kit Dateien)
• ls, explorer, finder
◆ Netzwerk (Verbergen aktiver Root Kit Verbindungen)
• netstat, ifconfig, ipconfig, iwconfig
tauschen BS-Module aus (Verbergen laufender Root Kit Prozesse,
Dateien, Netzwerkverbindungen)
◆ Unix: /proc/..., stat, fstat, pstat
Resultat
Prozesse, Kommunikation, Software des Root Kits werden unsichtbar
Systemsicherheit, Sommer 2019 © wk - 34 - 2.2.2 AngriffsmethodenNachhaltigkeit
Hintertüren für zukünftige Besuche
◆ in Servern (e.g. ssh-Dämon)
◆ in Utilities (e.g. login)
◆ in Bibliotheken (e.g. PAM, pluggable authentication modules)
◆ im BS (e.g. in von Programmen wie sudo benutzten Systemaufrufen)
Modifikationen von Utilities und BS zur Verhinderung des
◆ Abbrechens von Root Kit Prozessen und Kommunikationsverbindungen
(kill, signal)
◆ Entfernens von Root Kit Dateien (rm, unlink)
weitere Nebelbomben zur Tarnung von
◆ Server-, Dämonen-, Bibliotheks-, Utility- und BS-Modifikationen
Systemsicherheit, Sommer 2019 © wk - 35 - 2.2.2 AngriffsmethodenResultate
Verborgener Zugriff auf angegriffenes System
jederzeit
unentdeckbar
hoch privilegiert
extrem schnell
nahezu unverhinderbar
Systemsicherheit, Sommer 2019 © wk - 36 - 2.2.2 AngriffsmethodenMessages
Risiko- und Schadenspotential
Erfolgsaussichten: extrem hoch in heutigen Standardsystemen
◆ gewaltiges Schwachstellenpotenzial
◆ Angriffsgeschwindigkeit
◆ Methodik
◆ Automatisierung
Verteidigung gegen die dunklen Künste: extrem schwierig
◆ Zahl und Ursachen der Schwachstellen
• Zahl der „Sicherheitsupdates“ im letzten Jahr?
• Spezifikations- und Implementierungsfehler, schwache Sicherheitsmechanismen
◆ Angriffsgeschwindigkeit
◆ Nebelbomben
Möglichkeiten der Rettung eines Systems nach einem Angriff: nahe Null
◆ Nebelbomben, BS-Modifikationen
Systemsicherheit, Sommer 2019 © wk - 37 - 2.2.2 AngriffsmethodenMöglichkeiten der Vorbeugung
reaktiv
◆ hmm … (das BS selbst kann zum Feind geworden sein)
präventiv
◆ dieselben Werkzeuge nutzen: Schwachstellenanalyse und Beseitigung
(das machen wir seit Jahren → das 50 Milliarden € Problem...)
◆ korrekte Software schreiben
(das versuchen wir seit Jahren → das 50 Milliarden € Problem...)
→ Security Engineering
◆ neue Paradigmen: politikgesteuerte Systeme
→ mächtigere Basissysteme
◆ neue Mathematik: formale Sicherheitsmodelle
→ Reduktion von Spezifikationsfehlern
◆ neue Sicherheitsarchitekturen
→ Reduktion von Implementierungsfehlern
Systemsicherheit, Sommer 2019 © wk - 38 - 2.2.2 Angriffsmethoden2.2.3 Schadenspotential
Wirtschafts- und Technologiespionage
Verlust politischen Einflusses, der Kontrolle über kritisches Wissen
→ Hochrisiko-Technologien
finanzielle Schäden, Vertragsschaden, Imageschaden:
das 50.000.000.000 € Problem, 40% IT *)
→ Patentinhaber, Technologieführer, Alleinanbieter
Persönliche Bereicherung
finanzielle Schäden
Terrorismus, Hacker etc.
→ Kritische Infrastrukturen (Energie, Wasser, Kommunikation)
→ Schienen-/Luftverkehrsinfrastruktur
→ Finanzsysteme *) Quellen:
Corporate Trust Business Risk & Crisis Management GmbH
Universität Lüneburg
Verfassungsschutzbericht 2007, BfV
Systemsicherheit, Sommer 2019 © wk - 39 - 2.2.3 Schadenspotential2.2.4 Zusammenfassung
Bedrohungsanalyse: Know Your Enemy
Angriffsziele und Angreifer
◆ wirtschaftliche und politische Macht, finanzieller Gewinn
◆ professionelle Organisationen, Insider
Angriffsmethoden und -techniken
◆ Ausnutzung von menschlichen/organisatorischen/technischen
Schwachstellen
→ ein Zoo; praktische Hilfe beim Finden: Profilekataloge
◆ national: IT-Grundschutzkataloge des BSI
◆ international: die Common Criteria
πάντα ῥεῖ
Junges Fachgebiet
→ zahlreiche wissenschaftliche Publikationen (Risk Engineering)
Systemsicherheit, Sommer 2019 © wk - 40 - 2.2.4 ZusammenfassungSchwachstellenanalyse Bedrohungsanalyse
✓ ✓
Risikoanalyse
vermeiden behandeln tragen
Sicherheitsanforderungen
Systemsicherheit, Sommer 2019 © wk - 41 - 2.2.4 Zusammenfassung2.3 Risikoanalyse
Ziel
Identifikation und
Klassifikation
der tatsächlichen Risiken
Weg
Korrelation von Bedrohungen und Schwachstellen
→ Risikokatalog
Klassifikation der Risiken
◆ Ziel: Katalogreduktion
→ Risikomatrix
Systemsicherheit, Sommer 2019 © wk - 42 - 2.3 RisikoanalyseKorrelation von Bedrohungen und Schwachstellen
Ziel
Risikokatalog: n:m-Korrelation
Schwachstellenanalyse Bedrohungsanalyse
n m
Risiko
?
Systemsicherheit, Sommer 2019 © wk - 43 - 2.3 RisikoanalyseBeispiel 1
Implementierungsfehler in
ZS-Schema des DBMs:
Daten könnten unberechtigt
gelesen werden
Professionelle
Schwachstellenanalyse Bedrohungsanalyse
Angriffsteams
Risiko
?
Daten aus DB
werden Dritten
bekannt
Systemsicherheit, Sommer 2019 © wk - 44 - 2.3 RisikoanalyseBeispiel 2
Konzeptionelle Schwachstelle:
ausschließlich DAC-
Zugriffssteuerung
Mitarbeiter in
Schwachstellenanalyse Bedrohungsanalyse
kritischer
Finanzsituation
Risiko
?
Verkauf von
Firmengeheimnissen,
Umleitung von Finanzströmen
Systemsicherheit, Sommer 2019 © wk - 45 - 2.3 RisikoanalyseErgebnis
Risikokatalog
Schwachstellenanalyse Bedrohungsanalyse
Risiko
Ist oft sehr groß ...
Systemsicherheit, Sommer 2019 © wk - 46 - 2.3 RisikoanalyseKlassifikation der Risiken
Wichtiges und weniger wichtiges
Ziel
Katalogreduktion
Weg
Aufstellung einer Risikomatrix; korreliert
Schadenspotential
Eintrittswahrscheinlichkeit
Schadenspotential
Eintrittswahrscheinlichkeit
Systemsicherheit, Sommer 2019 © wk - 47 - 2.3 RisikoanalyseSchadenspotential
Schadenspotential
Abschätzung des Schadenspotentials
Beispielrisiken
Cloud Computing: „Verlust der Integrität der VMs“ Eintrittswahrscheinlichkeit
→ Vertragsstrafen, Vertrauensverlust
Anlagensteuerung: „Manipulation der Frequenzumrichter“
→ Zerstörung der Anlage
kritische Infrastrukturen: „DoS-Angriffe“
→ Versorgungssicherheit
Verkehrsmanagement: „Integrität von Fahrzeugpositionsdaten“
→ GAU
Systemsicherheit, Sommer 2019 © wk - 48 - 2.3 RisikoanalyseAllgemein: Schadenspotential oft anwendungsspezifisch
Beispielrisiko: „Daten aus DB werden Dritten bekannt“
Artikel von Online-Zeitungen
→ geringer Schaden
Kontendaten von Banken
→ kritischer Vertrauensschaden
Prozessleitdaten industrieller Produktionssysteme
→ Verlust der Alleinstellung, existenzkritisch
Abhängig von vielen Faktoren → Gremium
Systemsicherheit, Sommer 2019 © wk - 49 - 2.3 RisikoanalyseEintrittswahrscheinlichkeit
Schadenspotential
Abschätzung der Eintrittswahrscheinlichkeit
Beispielrisiken
Cloud Computing: „Verlust der Integrität der VMs“ Eintrittswahrscheinlichkeit
→ abhängig von Sensitivität der Kundendaten
Anlagensteuerung: „Manipulation der Frequenzumrichter“
→ abhängig von Sensitivität der Anlage (e.g. Stuxnet-Angriff)
kritische Infrastrukturen: „DoS-Angriffe“
→ abhängig von Terrorismusgefahr
Verkehrsmanagement: „Integrität von Flugzeugpositionsdaten“
→ abhängig von Terrorismusgefahr
Systemsicherheit, Sommer 2019 © wk - 50 - 2.3 RisikoanalyseAllgemein: Eintrittswahrscheinlichkeit oft anwendungsspezifisch
Beispielrisiko: „Daten aus DB werden Dritten bekannt“
Artikel von Online-Zeitungen
→ gering; Daten ohnehin über reguläre Schnittstellen verfügbar
Kontendaten von Banken
→ mittel; hoher Aufwand notwendig, Gewinnerwartungen gering
Prozessleitdaten industrieller Produktionssysteme
→ hoch; hohe finanzielle Gewinne durch Konkurrenzunternehmen, Drittstaaten
Abhängig von vielen Faktoren → Gremium
Systemsicherheit, Sommer 2019 © wk - 51 - 2.3 RisikoanalyseEin Beispiel
Schadenspotential
Feststellung des Schadenspotentials
Eintrittswahrscheinlichkeit
Objekt Risiko Schadenspot. Argumentation
Personen- Verlust der normal 1. DSGVO
bezogene Vertraulichkeit 2. Bei Bekanntwerden können
Daten (PD) Daten Betreffenden erheblich
beeinträchtigen
Verlust der gering Fehler können rasch erkannt und
Integrität korrigiert werden
Verlust der gering Ausfälle bis zu einer Woche
Verfügbarkeit können mit manuellen Verfahren
überbrückt werden
Technische Verlust der hoch Verlust der Alleinstellung,
Verfahren (TV) Vertraulichkeit existenzkritisch
Verlust der hoch Stillstand Produktion, Zerstörung
Integrität (vgl. Stuxnet-Szenario)
Verlust der gering Verzögerung Produktion, Backups
Verfügbarkeit vorhanden
Systemsicherheit, Sommer 2019 © wk - 52 - 2.3 RisikoanalyseSchadenspotential
Feststellung der Eintrittswahrscheinlichkeit
Eintrittswahrscheinlichkeit
Objekt Risiko Eintrittsw. Argumentation
Personen- Verlust der normal Zertifizierte Software
bezogene Vertraulichkeit
Daten (PD)
Verlust der gering Zertifizierte Software, Anreiz gering
Integrität
Verlust der normal Zertifizierte Software
Verfügbarkeit
Technische Verlust der hoch hohe finanzielle Gewinne durch Kon-
Verfahren (TV) Vertraulichkeit kurrenzunternehmen, Drittstaaten
Verlust der normal mittleres Schadenspotential,
Integrität Konkurrenzunternehmen oder
Drittstaaten als potentieller
Angreifertypus
Verlust der gering geringes Schadenspotential
Verfügbarkeit
Systemsicherheit, Sommer 2019 © wk - 53 - 2.3 RisikoanalyseResultierende Risikomatrix
ver
TV: Verlust der me der
TV: Verlust
hoch
Integrität TV
i de
Vertraulichkeit
n
Schadenspotential
behVerlust
normal
PD: and der
el n
Vertraulichkeit
gering
PD: Verlust der PD: Verlust der TV: Verlust der
trag
Integrität
e Verfügbarkeit Verfügbarkeit
n
gering normal hoch
Eintrittswahrscheinlichkeit
Systemsicherheit, Sommer 2019 © wk - 54 - 2.3 Risikoanalysevermeiden
untragbares Risiko, keine Verhältnismäßigkeit zw. Kosten/Nutzen
→ Funktionalität weglassen
tragen
Akzeptieren der Risiken
→ evtl. Verringern des Schadenausmaßes z.B. durch Versicherung
behandeln
Definition von Sicherheitsanforderungen
→ Reduzierung der Schadenswahrscheinlichkeit durch systemintegrierte
Sicherheitspolitiken
Systemsicherheit, Sommer 2019 © wk - 55 - 2.3 RisikoanalyseWeitere Kriterien
verfügbare HR, Kosten der IT-Technik
organisatorische und technische Machbarkeit
→ Kosten/Nutzen-Abwägung: Management und Geschäftsbereiche involviert
Systemsicherheit, Sommer 2019 © wk - 56 - 2.3 Risikoanalyse2.4 Zusammenfassung
Schwachstellenanalyse Bedrohungsanalyse
Risikoanalyse
vermeiden behandeln tragen
Sicherheitsanforderungen
Sicherheitspolitik
Systemsicherheit, Sommer 2019 © wk - 57 - 2.4 ZusammenfassungWas fangen wir mit diesem Ergebnis an?
Requirements Sicherheits-
Engineering anforderungen
Policy Sicherheits-
Engineering politik
Model Sicherheits-
Engineering modell
Architecture Sicherheits-
Engineering architektur
Systemsicherheit, Sommer 2019 © wk - 58 - 2.4 ZusammenfassungSie können auch lesen
