SlideShare ist ein Scribd-Unternehmen logo
EN 6.3: IT-Sicherheit und Technischer Datenschutz
Donnerstag,den 31. März 2016
Dozent: Dr. Sven Wohlgemuth <wohlgemuth@acm.org>
Themen
1. IT-Sicherheit und Datenschutz
2. IT-Compliance und IT-Sicherheitsmanagement
3. Sicherheitsmodelle
4. Kryptographie
5. Netzwerksicherheit
6. Sichere Dienste
7. IT-Risikomanagement
8. Risikoidentifizierung
9. Risikoquantifizierung
10. Benutzbare Sicherheit
Industrie
eGovernment
eHealthcare
Energie
Transport
und	mehr …
Soziale Netze
eEducation
Geschäftsziele	/	Regulierungen	 /	Nachhaltigkeit
Internet	of Things	/	Service	Computing
Agenda
3. Sicherheitsmodelle
3.1 Epochen der IT-Sicherheit
3.2 Zugriffskontrolle
3.3 Das Safety Problem
3.4 Nutzungskontrolle
Epochen der IT / Metaphern der Sicherheit
Burg Marktplatz Metropole
Mainframe Internet Ubiquitous Computing
„Die Guten sind drin,
die Schlechten sind
draußen
Server-based Security Client-based Security
autonome	Interaktion
menschliche	Interaktion
Müller und Zahoransky, Telematik 4 Sicherheit und Privatsphäre, 2015
Herausforderung
• Verteidigung der Burg
– Nicht berechtigte Bürger bleiben draußen
Angreifer
• „Outsiders“ oder „Intruders“
Schutzziel
• Zugriffskontrolle und Vertraulichkeit
Lösung
• Strenge Zugangskontrolle (Firewalls) und Intrusion-Detection
Monitors
Epoche Mittelalter
Müller und Zahoransky, Telematik 4 Sicherheit und Privatsphäre, 2015
Mittelalter: Quelle der Angriffe
Der Angreifer saß überwiegend in der eigenen Burg
frühere Mitarbeiter
13%
interne Mitarbeiter
81%
Outsiders
6%
Log und Firewall-
security
Audit Security
Quelle: Data Processing Management Assoc, 1997
Mittelalter: Mangelhafte Abwehr der Burg
38.000
Angriffe
Schutz
24.000 (65%)
erfolgreich
998 (4 %)
erkannt
23.712 (96%)
nicht erkannt!
Nachweis
Quelle: Testangriffe US-Militär, Defense Information Systems Agency, Mai 1996
• Firewalls und Intrusion Detection è Hohe „Dunkelziffer“ unerkannter Angriffe
• Bedarf an Authentifizierung, Autorisierung und Accounting nimmt zu
Mittelalter: Wer ist der (gute) Insider?
Authentifizierung: Erkennung von Kommunikationspartnern, aber…
Sicherheitskonform
Normal
Anormal
Profile
Fehlalarm
Authentifizierung
=
Verlust der Privatsphäre
Sicherheitsgefährdend
Herausforderung
– Aufbauen von Vertrauen
– Dezentrales Sicherheitsbedürfnis
Angreifermodell
– Mann in der Mitte
– „Impersonation“ von Kommunikationspartnern
Themen
– (Korrekte) Mehrseitige Sicherheit
– Sind Sicherheitsmechanismen „korrekt“ bzgl. ihrer Ziele?
à Verifikation bzw. Bewertung von Schwachstellen wird erforderlich
– Vertrauen: Basiert auf Software und Hardware
• Software à Sicherheitsprotokolle
• Hardware à Trusted Computing
Epoche Internet
Müller und Zahoransky, Telematik 4 Sicherheit und Privatsphäre, 2015
Internet: „In Internet nobody knows you are a dog“
Alice
Bob?
Und wenn der Hund „beißt“?
Internet: Mann in der Mitte
Attacke
Einem Angreifer gelingt es, den Kommunikationskanal soweit unter die eigene Kontrolle zu
bringen, dass die „Abgehörten“ nicht feststellen können, ob sie tatsächlich miteinander oder
mit dem Angreifer kommunizieren
Nutzung
– abhängig vom Ziel eines Protokolls
– Angriffe können genutzt werden, um sich unberechtigt Zugang zu Informationen
zu verschaffen, sie zu manipulieren oder komplette Datenverbindungen zu
übernehmen („connection hijacking“)
Mann in der Mitte
Nutzung:
Angriffe können genutzt werden, um sich unberechtigt Zugang zu Informationen zu
verschaffen, sie zu manipulieren oder komplette Datenverbindungen zu übernehmen
(„connection hijacking“).
Beschreibung: Einem Angreifer gelingt es, den Kommunikationskanal so weit unter die
eigene Kontrolle zu bringen, dass die „Abgehörten“ nicht feststellen
können, ob sie tatsächlich miteinander oder mit dem Angreifer
kommunizieren.
- Einkommen
- Kredit
- Versicherungen
- Immobilien
- …
- verheiratet
- Kinder
- …
IDENTITÄT
Führungs-
zeugnis
Karriere
Gesundheit
Finanzen
Familien-
status
Kauf-
verhalten
Name
Geräte-ID
Quelle: Holger Eggs, Günter Müller: „Sicherheit und Vertrauen: Mehrwert im E-Commerce“, Berlin 2001
Schutzobjekt: Identität
IDENTITÄT
Führungs-
zeugnis
Karriere
Gesundheit
Finanzen
Familien-
status
Kauf-
verhalten
Name
Geräte-DI
Privatsphäre
Verfügung über Kollektion,
Zugriff, Veränderung und
die Verteilung persönlicher
Daten
?
?
?
Reputation i
Reputation j
Reputation kSicherheit
Vertrauen
Vorhersehbarkeit des Verhaltens
durch die gewählte Identität
Identität und Sicherheit
Quelle: Holger Eggs, Günter Müller: „Sicherheit und Vertrauen: Mehrwert im E-Commerce“, Berlin 2001
Sicherheit in Schichtenmodellen
Charakteristika:
• Vermittelte und paketbasierte Übertragung
• Weltweit standardisierte Kommunikationsprotokolle
• Fokus auf Verfügbarkeit è generell mehrere Routen zu einem Ziel
Schäfer, Netzwerksicherheit, 2003
Angriffspunkte:
– keine Zertifizierung/ Attestierung der bei Übertragung beteiligten Knoten
➜ komplette Kommunikationsinfrastruktur bis auf eigenes Endsystem
Bedrohung:
– Übertragung im Klartext mittels Standardformaten ermöglicht Informationsgewinnung
[ ] und Modifikation [ ] (Bsp.: http://odem.org/insert_coin/)
– Metainformationen der Pakete ermöglichen präzise Beeinträchtigung [ ] der
Kommunikation (Bsp.: Internetzensur)
Fragen:
– Welchen Komponenten der Infrastruktur kann man überhaupt vertrauen?
– Welche Komponente soll welche Sicherheitsmaßnahmen umsetzen?
Netzwerksicherheit: Struktur
Schäfer, Netzwerksicherheit, 2003
Netzwerksicherheit: Funktion
Angriffspunkte:
– alle Schichten, welche unter jener liegen, die Schutzziele umsetzt
– da keine Sicherheitsvorkehrungen innerhalb der Schichten und keine gesonderte
Sicherheitsschicht è prinzipiell Angriff über jeder Schicht möglich
Bedrohung:
– dieselben wie unter struktureller Betrachtung
Maßnahmen:
– im Sinne der Modularisierung: Umsetzung so früh wie möglich (IPSec)
– im Sinne der Kompatibilität: Umsetzung so spät wie möglich (SSH oder SSL)
Schäfer, Netzwerksicherheit, 2003
Grundlegendes:
– gleiche Bedrohungen wie im Festnetz
– identische Gegenmaßnahmen
Erweiterte Angriffsfläche:
– Zugang zu Diensten wird durch drahtlose Verbindung
einfacher und dementsprechend unsicherer
– Handover und Roaming erzwingt regelmäßige Re-
Authentifizierung
– Schlüsselverwaltung wird wegen des dynamischen
Netzzugangs komplizierter
Besonderes Schutzziel:
– Ort eines Gerätes oder Nutzers wird wichtigste Information
è Schutz der Ortsinformation ist notwendig!
Netzwerksicherheit: Mobilität
Beispiel: Mobiler Bürger
18
Bedrohung durch:
• Ortsinformation
• Spontane Vernetzung
• Personenbezogene Daten
• Dauerhafter Betrieb
• Datenspuren: Verkettbarkeit
• Diebstahl des Gerätes:
Impersonation
Home
Profile
Sven
Wohlgemuth
Date: 09.06.05
Time: 08:00
Read e-mails
IP: 132.15.16.3 Ticket
Profile
Sven
Wohlgemuth
Date: 09.06.05
Time: 08:30
Buy e-ticket
IP: 132.15.16.3
Book
Profile
Sven
Wohlgemuth
Date: 09.06.05
Time: 09:00
Look for books
IP: 132.15.16.3Visitor
Profile
Sven
Wohlgemuth
Date: 09.06.05
Time: 10:00
Visit Roemer
IP: 132.15.16.3
FIDIS
Profile
Sven
Wohlgemuth
Date: 10.06.05
Time: 9:00
FIDIS meeting
IP: 132.15.16.3
Home
Profile
Sven
Wohlgemuth
Date: 09.06.05
Time: 08:00
Read e-mails
IP: 132.15.16.3
Wohnung
Angreifer
Müller und Wohlgemuth, Study on Mobile Identity Management, 2005
Epoche Ubiquitous Computing
Herausforderungen
– Überall, jederzeit, alles für Nachhaltigkeit
– Spontaner zuverlässiger Informationsaustausch
Angreifermodell
– „Mann in den Endknoten“ mit Abhängigkeiten
Themen
– Ist Sicherheit überhaupt technisch machbar?
– Schwerpunkt „Security Engineering“
• Sichere Softwareentwicklung
– Vertrauensaufbau wird erschwert
– Sicherheitsrichtlinien werden wichtiger
• Mechanismen zu deren Implementierung
• Persönliches Risikomanagement
– Resilienz mit skalierbarer Zweitverwendung von
persönlichen Daten
- New processes
- Modified processes
2) Consequences
Economy
Employment
Elderly
Society
Education
Energy
Social infrastructures
- Crime, terrorism, and natural disasters
- Damages/Failure of ICT services
1) Unexpected, inevitable Interferences by
- Cascading interferences
- Interoperability
3) Additional Risk: "Outsider" becomes "Insider"
- Controllability
- Non-availability of services/data
- Non-authorized access to
services/data
- Incorrect data
4) Resultant Interferences by
- Privacy violation
- Physical damages
ICT
Beispiel: Datennutzung mit SNS
Model
Builder
PredictorDatabase
Empfehlungssystem
di
dj
Eigene Abbildung nach(Lam et al. 2006)
Persönliche Daten di, dj, ...
Behörden
Transport
Gesundh
eit
Energie
...
Persönliche Empfehlungen di*, dj*, ...
2 neue Mitglieder/Sekunde
(press.linkedin.com)
...
500+ TB/Tag
(techcrunch.com)
340 Mio Tweets/Tag
(business.twitter.com)
1+ Mrd Suchanfragen/Tag
(www.google.com)
d*i
d*j
Agenda
3. Sicherheitsmodelle
3.1 Epochen der IT-Sicherheit
3.2 Zugriffskontrolle
3.3 Das Safety Problem
3.4 Nutzungskontrolle
Zugriffskontrolle (Access Control)
• Zugriffskontrolle: Schutz einer Systemressource vor unautorisiertem Zugriff
• Bezeichnet notwendige Mechanismen zur Einhaltung einer vorgegebenen
Sicherheitsrichtlinie beim Zugriff eines Subjektes s auf ein Objekt o
• Gegenwärtig: Best Practice (ISO/IEC 27k, BSI Standard-100, ...)
ReferenzmonitorSubjekt ObjektAnfrage gewährt
abgelehnt
Richtlinie
Zugriffskontrolle
Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
Subjekt
– Aktive Einheit
– Initiiert den Zugriff auf Objektressourcen
– Im Kontext von Betriebssystemen
• Prozesse
Objekt
– Passive, zu schützende Einheit
– Speichert gewöhnlich Informationen
– Im Kontext von Betriebssystemen
• Dateien, Verzeichnisse, usw.
Aber: Die Trennung von Objekten und Subjekten ist nicht immer eindeutig
• Eine Prozess sendet eine Nachricht zu einem anderen Prozess.
Ist der empfangende Prozess nun Subjekt oder Objekt?
Objekt und Subjekt
Subjekt Objekt
Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
Universelle Rechte
– Bezeichnen allgemeine,
nicht objektspezifische Operationen
– Beispiel: Zugriffsarten auf Dateisystem
• Lesen, Schreiben, Ausführen
Objektspezifische Rechte
– Beschränkt auf einen festgelegten, funktionalen Kontext
– Bindung an die jeweiligen Objekt
– Beispiel: Objekt-Orientierte Programmierung (OOP)
• Ausführung von Methoden eines Objektes
Zugriffsrechte
Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
• Wichtiges konzeptuelles Modell
– Als physikalische oder logische Einheit
im System nicht unbedingt vorhanden
• Sollte jeden Zugriffsversuch kontrollieren
• Sollte keinen Rechtentzug zwischen Rechtprüfung und entsprechender
Rechtausübung erlauben
– Sonst unzulässiger Rechtzustand
• Muss selbst vor unberechtigtem Zugriff geschützt bzw. isoliert werden
è Trusted Computing Base
Referenzmonitor
Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
• Definiert die Bedingungen,
unter denen einem Subjekt
Zugriff auf ein Objekt gewährt wird
• Definiert eine Beziehung zwischen
Subjekten, Objekten und Zugriffsrechten
• Analog zu einer "Gesetzsammlung"
• Der Ausdruck Sicherheitsrichtlinie wird oft auch in einem weiteren Sinne genutzt
– Spezifikation aller Sicherheitsaspekte eines Systems
inklusive Risiken, Angriffe, Gegenmaßnahmen, usw.
Sicherheitsrichtlinie (Security Policy)
Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
Sicherheitsmarkierung (Labels/Lattice)
Sensitivitätslevel
• HierarchischesAttribut einer Einheit
• Militärisch:
Nicht-klassifiziert < Vertraulich < Geheim
• Kommerziell:
Öffentlich < Sensitiv < Proprietär < Eingeschränkt
Sicherheitskategorien
• Nichthierarchische Gruppierung von Einheiten
• Beispiel:AbteilungA, Abteilung B, Administration
Sicherheitslabel
• Kombination von Sicherheitslevel und –kategorie
– Label: Level x 2Kategorien
• Sicherheitslabel für Sensitivität von
– Subjekten heißen Freigabe (clearences)
– Objekten heißen Klassifizierung (classifications)
Lattice-based	Access	Control
Sandhu 1993
Sandhu, Lattice-based Access Control Models, 1993
Zugriffskontrollmatrix
Rechtzustand eines Systems zu einem Zeitpunkt t gegeben als Matrix
Mt = St x Ot à 2Rechte gegeben
• Spalten Menge Ot von Objekten
• Zeilen Menge St von Subjekten #
• Zelle Entsprechende Menge der Zugriffsrechte
Mt Datei1 Datei2 Datei3 Prozess1 Prozess2
Prozess1
{own,
read,
write}
{own,read,
write}
{read,
write}
Prozess2 {read}
{own,
read}
Prozess3
{own,
write}
{write}
Harrison, Ruzzo und Ullman, Protection in Operating Systems, 1976
ACL (Access Control List)
Jedes Objekt speichert eigeneACL aller
Subjekte, die Zugriff auf Objekt besitzen
Vorteile
• Einfache Bestimmung der Zugriffsrechte auf
gegebenes Objekt
• Rechtrücknahme meist effizient realisierbar
Nachteile
• Aufwändige Kontrolle bei langen ACL
• Skalierbarkeit: Bestimmen der Rechte eines
Subjekts i.d.R. sehr aufwändig
Capability List (Credentials)
Jedes Subjekt speichert eigeneAutorisierung
auf Objekte (Trust Management)
Vorteile
• Einfache Bestimmung der Zugriffsrechte
eines Subjektes
• Kontrolle durch Prüfung des Credentials
Nachteile
• Widerruf von Rechten impliziert u.U. zeitliche
Ungewissheit
• Sicht von Objekte auf Subjekte ist schwierig
Zugriffskontrollmatrix: Repräsentation
Mt Datei1 Datei2 Datei3 Prozess1 Prozess2
Prozess1
{own,
read,
write}
{own,read,
write}
{read,
write}
Prozess2 {read}
{own,
read}
Prozess3
{own,
{write}
Credential-basierte Zugriffskontrolle
• Benutzer können ein Stück der Liste selbst speichern
– Entspricht der Idee eines Ausweises/Eintrittskarte
– Liste ist nur noch implizit vorhanden
• Beim Aktivieren einer Berechtigung legt der Benutzer
dieses Stück der Liste vor, das die entsprechende
Berechtigung enthält
• Problem: Sicherstellen, dass der Nutzer seine
Berechtigungen nicht manipulieren kann
– Entspricht der Echtheitskontrolle eines
Ausweises/einer Eintrittskarte
– Kann mittels Zertifikaten gelöst werden
– Zentraler Vertrauensanker ist notwendig
Zugriffskontrollstrategie: DAC
Discretionary Access Control (DAC)
– Benutzerbestimmbare Strategie (Eigentümer-Prinzip)
• Benutzer ist Eigentümer von seinen Objekten
• Eigentümer kontrolliert Zugangsrechte zu seinen Objekten
– Eigentümer kann jedoch i.a. "Ownership" nicht transferieren
– Beispiel: das Unix-Betriebssystem erlaubt das setzen
von Lese-, Schreib- und Ausführungsrechten für im Besitz befindliche
Dateien
– Flexibles Rechtesystem, aber offen für Fehler
• Alle Benutzer müssen Sicherheitsleitlinie verstehen und anwenden
• Objektbezogene Sicherheitseigenschaften (keine globalen)
– Ohne Berücksichtigung von Benutzungs-, Kommunikations- oder
Kooperationsabhängigkeiten zwischen Objekten
Zugriffskontrollstrategie: MAC
Mandatory Access Control (MAC)
– Systemweite Durchsetzung von Sicherheitsrichtlinien
• "zwingend", da Subjekte Rechte nicht transferieren können
• Unabhängig von Benutzeraktionen
– Formale Autorisierung durch Vergleich von
• Clearances (Freigabelevel der Subjekte)
• Classifications (Sensitivität der Objekte)
• Beispiel: Subjekte können nur auf dominierte Objekte zugreifen
(Objekte gleichen oder niedrigeren Levels)
– Kombinierbar mit DAC
• Systembestimmtes MAC überschreibt jedoch benutzerbestimmtes DAC
• Beispiel: Bell-LaPadula
Dominanz
Dominanz begrenz in Abhängigkeit der
Sicherheitklassen die autorisierten
Zugriffe eines Subjektes s.
Objekt o dominiert Subjekt s
(s wird von o dominiert), falls:
Ein Subjekt kann ein Objekt lesen, falls:
• der Freigabe-Grad (clearance) des Subjektes ist mindestens so hoch wie
der des Objektes
• das Subjekt benötigt Information über alleAbteilungen für die das Objekt
klassifiziert ist
Zugriffskontrollstrategie: RBAC
Role-Based Access Control (RBAC)
• Vom Benutzer ausgeübte Rollen bestimmen seine Zugriffsrechte
• Rolle: Nachbildung von Organisationsstrukturen und Verantwortlichkeiten
– Rollen können überlappende Verantwortlichkeiten besitzen
– Veränderung von Rollen ohne Anpassung individueller Benutzerrechte
• Rechte nicht bezogen auf Subjekte sondern auf durchzuführende Aufgaben
– Subjekte erhalten über Rollenmitgliedschaft Berechtigung zur Ausführung von
Aufgaben
– Subjekte können gemäß ihren Aufgaben mehrere Rollen besitzen
Verwandtschaft zu Gruppenkonzept
• Gruppenkonzept als rudimentäres RBAC
– Aufgabenbezogene Gruppenfestlegung
– Beispiel: jeweils eigene Gruppe für Administratoren und Benutzer
• Rollenkonzept jedoch bringt zusammen
– Menge von Benutzern auf einer Seite (wie bei Gruppen)
– Menge von Berechtigungen auf der anderen (zusätzlich)
Sandhu, Coyne, Feinstein und Youman, Role-Based Access Control Models, 1996
RBAC: Hierarchien
Rollenhierarchien
• Vereinfacht Ausdruck der Sicherheitsrichtlinie
• Nachbilden hierarchischer Organisationsstrukturen
• Beispiel: Kassierer ≤ Kassenprüfer
– Ein Mitglied der Kassenprüfer darf mindestens
auf alle die Objekte zugreifen,
auf die ein Kassierer zugreifen darf
Vererbung der Rollenmitgliedschaft
• Bildung einer partiellen Ordnung auf Rollen R
• Falls rj ≤ ri, dann gilt:
∀s∈S, ri ∈sr(s)⇒ rj ∈sr(s)
Kassierer
Leiter
KundeAngestellter
Kunden-
betreuer
Kassenprüfer
ri rj
rj besitzt auch Rechte von ri
Änderungen in der Zugriffskontrollmatrix
Statische Zugriffsmatrix
– Schutzzustand Mt des Systems invariant über die Zeit
– Mt = M
Dynamische Zugriffsmatrix
– Veränderungen der Matrix Mt durch Systemkommandos
• Löschen oder Erzeugen von Subjekten oder Objekten
• Weitergabe oder Rücknahme von Zugriffsrechten
– Matrix selbst wird ein zu schützendes Objekt
• Berechtigungen für Zustandsänderungen ebenfalls als Recht modelliert
......
d
d, d*
Datenanbieter
/konsument
Daten-
konsument
Datenkonsument
/anbieter
Daten-
anbieter
Zweitnutzung: DynamischErstnutzung: Statisch
Agenda
3. Sicherheitsmodelle
3.1 Epochen der IT-Sicherheit
3.2 Zugriffskontrolle
3.3 Das Safety Problem
3.4 Nutzungskontrolle
Das Safety Problem
State-of-the-art: ISO 270xx, BSI Standard-100 (Zugriffskontrolle)
......
d
Data	provider
/consumer
Data	consumer
Data	consumer
/provider
Data	provider
d,	d*
?
o1 =	d o2 =	d* …
s1 own, r,	w ?	own,	r,	w	?
s2 r,	w own,	r,	w
s3 ?	r,	w	? r
…
General
security
system
Safety ist i.A. nicht-entscheidbar ⇒ Halteproblem der Turing Machine
Wahrscheinlichkeit der Zuverlässigkeit einer Aussage auf die Zukunft = 50%
Harrison et al. 1976Hamlen et al. 2006
Enforcement
Harrison, Ruzzo und Ullman, Protection in Operating Systems, 1976
Das Safety Problem: Modellierung
Modellierung von Sicherheitseigenschaften
– Spezifikation von zulässigen und unzulässigen Rechtzuständen
– Nachweis: nur zulässige Zustände sind erreichbar
• Erreichbarkeit als Entscheidungsfrage
– Bei gegeben Zustand Mt,
in dem ein Subjekt s das Recht r an Objekt o nicht besitzt,
gibt es Nachfolgezustand Mt+n,
in dem das Subjekt s das Recht r an Objekt o wohl besitzt?
• Kann die Erreichbarkeit von Zuständen entschieden werden?
– Hierfür muss dynamisches Verhalten des Systems beschrieben werden
• Folge von Konfigurationen Kt = ( Mt, Ot, St )
• KS0 beschreibt Anfangskonfiguration
nttt
*
S KKKK
nttt
++
−++
====
11
0
|||| 1
ααα
!
Das Safety Problem: Nicht-Entscheidbarkeit
Safety-Problem
– Gibt es für ein beliebiges Regelwerk einenAlgorithmus,
der für Recht r, Subjekten s und Objekte o,
der das Safety-Problem löst?
– Gegeben Kt mit r ∉ Mt( s,o )
– Safety-Problem ist unentscheidbar
• (Harrison, Ruzzo, Ullman, 1976)
• Beweis auf Halteproblem von Turing-Maschine zurückgeführt
),(:|mit osMrKKn ntntt
n
++ ∈=∃
α
Safety dank Spezialfall/Erweiterung
Status Quo: Language-based information flow control
Modell
Natural
Language
Policy
High-Level
Policy
Language
Intermediate-Level
Security Policy
Flow Graph
Low-Level
Enforcement
In der Praxis
Take-grant, Type-safety,
Lattice-based Access Control,
Obligationen
Identität, Kryptographie, sicheres
öffentliches Verzeichnis, Monitor,
Proof-Carrying Code
Dezentralisiertes Trust
Management
HIPAA, (J-)SOX,
KonTraG, 95/46/EC, JP
PII Protection Law, …
Enforcement Classes,
Ponder, ExPDT
Komplexitätstheoretisch,
PKI, Virtualisierung, Testen
ISO/IEC 270xx, BSI
Standard-100, IETF AAA,
NIST SCAP
Social/Knowledge Graph,
Sticky Policies
Spezialfälle der Zugriffskontrolle
• Strikte Ordnung der
Zugriffsrechte
• Symmetrischer Graph
der Zugriffsrechte
• Safety, falls die Graphen
zwischen autorisiert und
nicht-autorisiert getrennt
sind
(es gibt mehr als einen
maximal aufspannenden
Baum)
• Verfügbarkeit von
Daten durch
Deklassifizierung
Lattice-based Access Control
Sandhu 1993
Take-grant
Lipton and Snyder 1977
S1:	u
S2:	u S3:	v
O:	oS3:	w
• Azyklischer Graph
der Zugriffsrechte
• Safety bei x <= 3
Parameter einer
Weitergabe
• Kein irreparabler
Widerruf von Rechten
Type-safety
Sandhu 1992
S1:	u
S2:	u S3:	v
O:	oS3:	w
Sandhu, The Typed Access Matrix Model, 1992
Bell-LaPadula
• Bell und La Padula definierten in 1973 dieses Sicherheitsmodell
– zur formalen Beschreibung der erlaubten Pfaden eines
Informationsflusses
– in einem sicheren IT-System
• Informationsflüsse sind über autorisierte Verbindungen zwischen Subjekten
und Objekten unterschiedlicher Sicherheitsklassen erlaubt.
• Betrachte ein Sicherheitssystem mit den folgenden Eigenschaften:
• Das System spezifiziert
• eine Menge von Subjekten S und
• eine Menge von Objekten O
– Jedes Subjekt s in S und jedes Objekt o in O ist statisch einer
Sicherheitsklasse C(s) und C(o) zugeordnet (kennzeichnen Freigabe
(clearance) und Sicherheitsstufe (classification))
– Die Sicherheitsklassen sind hierarchisch geordnet durch die < Relation
Bell-LaPadula Modell
Einfache Sicherheitseigenschaft:
– Ein Subjekt s darf zum Lesen (read) eines Objektes nur autorisiert sein,
falls C(o) ≦ C(s)
– Die Sicherheitsklasse (clearance) eines Datenkonsumenten muss
mindestens so hoch sein wie die Sicherheitsklasse (classification) der
Information
*-Eigenschaft:
– Ein Subjekt s, das zum Lesen (read) eines Objektes o autorisiert ist, darf
für ein Schreiben (write) in ein Objekt p nur autorisiert sein, falls C(o) ≦
C(p)
– Der Inhalt eines sensitiven Objektes darf nur in Objekte derselben und
einer höheren Sicherheitsstufe geschrieben werden.
Mandatory No-Read-Up
No-Read-Up oder Simple Security-Eigenschaft
• Ein Subjekt s kann nur dann auf ein Objekt o lesend zugreifen,
wenn sein Sicherheitsklasse die des Objektes dominiert
• r ∈ Mt(s,o) ∧ sc(s) ≥ sc(o)
• Beispiel: Ein zu niedrig eingestuftes Subjekt sollte nicht ein geheimes Objekt
lesen können
o
s
o
o
s
s
Lesezugriffe
Zunehmende
Sensitivität
Mandatory No-Write-Down
No-Write-Down oder *-Eigenschaft
• Ein Subjekt s kann nur dann auf ein Objekt o schreibend zugreifen,
wenn die Sicherheitsklasse des Objektes die des Subjektes dominiert
1. append ∈ Mt(s,o) ∧ sc(s) ≤ sc(o)
2. read-write ∈ Mt(s,o) ∧ sc(s) = sc(o)
• Verhindert einen Nachrichtenfluss von einem Subjekte hoher Klasse
zu Objekten niedrigerer Klasse
o
s
o
o
s
s
Schreibzugriffe
Zunehmende
Sensitivität
Bell-LaPadula: Beispiel
o1
o2 s1
o3 o4
o5 s2
app
app
app,r/w
r
r/w
r/w
unklassifiziert
vertraulich
geheim
streng geheim
r,exe
zulässigerInformationsfluss
Bell-LaPadula: Grenzen
Sukzessive Höherstufung von Informationen
• Subjekte können Information von Objekten niedriger Klasse aufnehmen,
diese jedoch nicht an sie zurückfließen lassen
• Zwei Möglichkeiten, wenn solcher Nachrichtenfluss explizit gewünscht
– Temporäres Herabstufen für solche Subjekte (downgrade)
– Einführung von "Trusted Subjects" wie Systemprozessen,
die die No-Write-Down-Regel umgehen können
Blindes Schreiben
• Subjekt s darf Objekt o modifizieren, aufgrund von No-Read-Up anschließend jedoch
nicht lesen
– Bzgl. Integrität problematisch
Statisches Modell
• Erzeugung oder Löschung von Subjekten bzw. Objekten nicht beschrieben
• Änderung von Zugriffsrechten im Modell nicht beschrieben
Dual zu Bell-LaPadula: Biba
• Biba ist das Gegenstück (dual) des Bell-LaPadula Models: Biba definiert
Integritätsstufen ähnlich zu den Vertraulichkeitsstufen von Bell-LaPadula:
no-read-down; no-write-up
• Subjekte und Objekte sind in dem Klassifikationsschema zur Integrität
geordnet: I(s) und I(o).
Einfache Integritätseigenschaften:
Subjekt s kann Lesezugriff (read) auf Objekt o haben, falls:
I(s) ≧ I(o)
Integrität *-Eigenschaft.
Falls Subjekt s Lesezugriff (read) auf Objekt o mit der Integritätsstufe l(o) hat,
dann darf s in Objekt p schreiben nur, falls
l(o) ≧ l(p)
Chinese Wall (Brewer & Nash Modell)
Sicherheitsstrategie aus kommerziellem Bereich
• Modelliert Zugriffsrechte im Finanzbereich
– Verhinderung von unzulässigem Insiderwissen
wenn Kunden direkte Konkurrenten sind
• Beispiele
– Banken, Beratungsfirmen, Börsen
Idee von Chinese Wall
• Berücksichtigung der Zugriffshistorie
– Vorherige Zugriffe einer Person bestimmen ihre zukünftigen Zugriffsrechte
– Wer auf Objekte eines Unternehmens U in einer Konfliktklasse K zugreift,
darf nicht mehr Objekte eines Unternehmens U' ≠ U zugreifen.
• Informationsfluss ohne Restriktion, falls Daten gereinigt sind (anonymisiert)
Zweistufige Objekthierarchie
• Einteilung in unterschiedliche Interessenkonfliktklassen (Branchen)
– z.B.: Banken und Ölgesellschaften
• Einteilung in unterschiedliche Unternehmen innerhalb der Konfliktklassen
– z.B.: Dresdner und Deutsche Bank
Chinese Wall: Beispiel
Ölgesellschaft Bank
BP Aral Dresdner
Interessenskonfliktklassen x
Unternehmen y
o1 o2 o3
o4 o5
o6
Objekte
o9o8
o7
Hypo
Laptop
Chinese Wall: Formaler Schutzzustand
Schutzzustand
Besteht aus zwei Teilen
• Mt Zugriffsmatrix
– Benutzerbestimmbare, universelle Rechte R = { Read, Write, Execute }
• Nt Zugriffshistorie
Zugriffshistorie
• Nt: S x O → 2R
• Nt(s, o) = {r1,..., rn} falls Subjekt s mit den Rechten {r1,..., rn}
auf Objekt o vor dem Zeitpunkt t zugegriffen hat
Chinese Wall: Lese- und Schreibregel
Lesezugriff (Read-Access)
• Nur wenn vorher kein Zugriff stattgefunden hat auf
Objekt eines anderen Unternehmens der gleichen Konfliktklasse
• Ein Zugriffrecht r ∈ { read, execute } auf ein Objekt o ∈ O ist für
ein Subjekt s ∈ S zur Zeit t genau dann gegeben, wenn
r ∈ Mt(s, o) ∧ ∀ o‘∈ O ,
Nt(s, o‘) ≠ Ø ⇒ ( y(o‘) = y(o) ∨ x(o‘) ≠ (o) ∨ y(o‘) =y0 )
Schreibzugriff (Write-Access)
• Nur wenn alle vorherigen Lesezugriffe stattgefunden haben auf
– Objekte des gleichen Unternehmens
– interessensfreien Objekte
• Verhindert einen Informationsfluss zwischen Objekten unterschiedlicher Unternehmen,
auch wenn sie der gleichen Konfliktklasse angehören
• Ein Subjekt s ∈ S erlangt Schreibzugriff auf ein Objekt o
zur Zeit t genau dann, wenn
write ∈ Mt(s, o) ∧ ∀ o‘∈ O ,
read ∈ Nt(s, o‘) ⇒ ( y(o‘) = y(o) ∨ y(o‘)=y0 )
Chinese Wall und Service Computing
Konflikt-
klassen
Pers.
Daten-
sätze
Syshigh
Ground	Truth
Registration	
office
Medical	
treatment
Erforderliche Information	
für Durchsetzung
(zentral durch Syshigh)
Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
Chinese Wall und Service Computing
Konflikt-
klassen
Pers.
Daten-
sätze
Syshigh
Ground	Truth
Registration	
office
Medical	
treatment
Bob David
Explicit/friendship
Implicitly assumed friendship
Erforderliche Information	
für Durchsetzung
(zentral durch Syshigh)
Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
Chinese Wall und Service Computing
Konflikt-
klassen
Pers.
Daten-
sätze
Syshigh
Ground	Truth
Registration	
office
Medical	
treatment
Bob David
Explicit/friendship
Implicitly assumed friendship
Erforderliche Information	
für Durchsetzung
(zentral durch Syshigh)
Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
Zugriffskontrolle skaliert nicht für Service Computing
• Strikte Ordnung der
Zugriffsrechte
Rollenwechsel bei Weitergabe
über Dritte
• Symmetrischer Graph
der Zugriffsrechte
Fehlerausbreitung
• Safety, falls die Graphen
zwischen autorisiert und
nicht-autorisiert getrennt
sind
Gemeinsame Nutzung von
daten-zentrischem Dienst
• Verfügbarkeit von Daten durch
Deklassifizierung
Intern: Zuverlässiger „Big Brother“
Extern: Fehlerausbreitung
Lattice-based Access Control
Sandhu 1993
Take-grant
Lipton and Snyder 1977
S1:	u
S2:	u S3:	v
O:	oS3:	w
• Azyklischer Graph
der Zugriffsrechte
Rollenwechsel bei
Weitergabe über Dritte
• Safety bei x <= 3
Parameter einer
Weitergabe
(Anbieter, Konsument,
Subjekt, Zeit, Zweck, ...)
• Kein irreparabler
Widerruf von Rechten
Datensparsamkeit
Type-safety
Sandhu 1992
S1:	u
S2:	u S3:	v
O:	oS3:	w
Agenda
3. Sicherheitsmodelle
3.1 Epochen der IT-Sicherheit
3.2 Zugriffskontrolle
3.3 Das Safety Problem
3.4 Nutzungskontrolle
Nutzungskontrolle (Usage Control)
1. Zugriff auf Daten
– Provisions sind Bedingungen, die die Zeit bis zum
ersten Zugriff/direkte Erhebung von Daten
(Ground Truth) spezifizieren
– Referenzmonitor erlaubt Zugriff genau dann wenn die
Provisions erfüllt sind
2. Nutzung von Daten
– Obligations sind Bedingungen, die die Zeit nach dem
Zugriff spezifizieren (“Zukunft”)
– Wie können Obligationen durchgesetzt werden?
Beispiel: “Dienst X ist für den Zugriff auf die E-Mailadresse autorisiert, falls es
diese E-Mailadresse nach der Geschäftstransaktion löscht.”
Inquiry Access
Provisions
Obligations
t
1
2 ?
RM
Objekt
Subjekt
Park und Sandhu, The UCONABC Usage Control Model, 2004
Demo: Usage Control mit FTP
Source: Alexander Pretschner @ https://www22.in.tum.de/forschung/distributed-usage-control/
ftp://AlicesFriends.txt
Datenanbieter/
-konsument
Daten-
konsument
Daten-
anbieter
Alice
Bob
Einhaltung einer Obligation
Wann ist eine Obligation verletzt?
Eine Obligation ist zum Zeitpunkt tk verletzt,
falls das Subjekt sich zu dieser Obligation zur Zeit tj verpflichtet hat,
aber sie zu der Zeit tj nicht erfüllt ist, unabhängig von de Zugriffen nach tk.
tj tk
Verpflichtung zu
der Obligation Für jede Entwicklung nach tk
kann die Obligation nicht erfüllt werden
Obligation ist nicht erfüllt
(abhängig von dem Kontrollfluss bis tk)
Obligation
Zeit
Hilty, Basin und Pretschner, On Obligations, 2005
Beispiel: Einhaltung einer Obligation
Obligation: "Sender S muss die Nachricht N innerhalb von 3 Zeiteinheiten senden.”
t0 Sender verpflichtet sich zu der Obligation
t0 zu t3 Falls N bisher nicht gesendet wurde,
dann kann sie bis t3 gesendet werden, um die Obligation zu erfüllen
t4 Obligation kann nicht mehr erfüllt werden; unabhängig von den
weiteren Verlauf der Zugriffe
è Referenzmonitor kann nicht entscheiden, ob eine zeitlich unbeschränkte
Obligation wie “Nachricht N muss irgendwann gesendet werden” verletzt ist
t0 t1 t2 t3 t4
Verpflichtung
zu der Obligation
Letzte Chance, um
N zu senden
Obligation
ist verletzt
Pretschner, Hilty und Basin, Distributed Usage Control, 2006
Eingeschränkte Obligationen
K 1: Eingeschränkt und beobachtbar
• Obligationsbedingung muss innerhalb einer bestimmten Zeitdauer erfüllt werden.
Referenzmonitor kann die beobachten.
• Beispiele
– “Muss die Strafe innerhalb von 5 Tagen bezahlen”
– “Subjekt s ist für die nächsten 5 Tage nicht für einen Lesezugriff auf lokale Dateien
autorisiert.”
K 2: Eingeschränkt und nicht beobachtbar
• Wie K1, nur ein Referenzmonitor kann die Einhaltung (generell) nicht beobachten
• Beispiele
– “Empfänger ist nicht erlaubt die Daten innerhalb der nächsten 5 Tage weiterzugeben”
– “Empfänger muss die Daten innerhalb von 5 Tagen löschen”
Zeit / Verteilung Beobachtbar Nicht beobachtbar
Eingeschränkt K 1 K 2
Invariant K 3 K 4
Pretschner, Hilty und Basin, Distributed Usage Control, 2006
Invariante Obligationen
K 3: Invariant und beobachtbar
• Obligationsbedingung muss immer erfüllt werden.
Referenzmonitor kann die Einhaltung beobachten.
• Beispiele
– “Benutzer immer einen verschlüsselten Kanal”
– “Aktualisiere die Daten wenigstens an jedem 5. Tag”
(bspw. zur Echtzeit-Inventur)
K 4: Invariant und nicht beobachtbar
• Wie K3, nur ein Referenzmonitor kann die Einhaltung (generell) nicht beobachten
• Beispiel
– “Daten dürfen nicht weitergegeben werden.”
Zeit / Verteilung Beobachtbar Nicht beobachtbar
Eingeschränkt K 1 K 2
Invariant K 3 K 4
Pretschner, Hilty und Basin, Distributed Usage Control, 2006
d,	d*d
Datenanbieter/
-konsument
Daten-
konsument
Datenkonsument/-
anbieter
Daten-
anbieter
Zugriffskontrolle
Provisions
Provisions +	Obligationen
Nutzungskontrolle
Durchsetzung	⇒ Open	Data	für	Nutzung	persönlicher	Daten	(Ground Truth)
Open	Data	zu	
Obligationen
Nutzung für Service Computing
Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
Quellen und weiterführende Literatur
• Eggs, H., Müller, G. Sicherheit und Vertrauen: Mehrwert im E-Commerce. Berlin, 2001
• Harrison, M.A., Ruzzo, W.L., Ullman, J.D. Protection in Operating Systems. CACM 19(8),
ACM, 1976
• Hilty, M., Basin, D., Pretschner, A. On Obligations. ESORICS 2005, LNCS 3679, Springer,
2005
• Müller, G., Accorsi, R., Höhn, S., Sackmann, S. Sichere Nutzungskontrolle für mehr
Transparenz in Finanzmärkten. Informatik-Spektrum 33(1), Springer, 2010
• Park, J., Sandhu, R. The UCONABC Usage Control Model. ACM Transactions on Information
and System Security 7(1), ACM, 2004
• Pretschner, A., Hilty, M, Basin, D. Distributed Usage Control. CACM 49(9), ACM, 2006
• Saltzer, J.H., Schroeder, M.D. The Protection of Information in Computer Systems. ACM
Symposium on Operating Systems Principles, 1973
• Sandhu, R. Lattice-Based Access Control Models, Computer 29(11), IEEE, 1993
• Schäfer, G. Netzsicherheit. d-punkt Verlag, 2003
• Wohlgemuth, S., Takaragi, K., Echizen, I. Privacy with Secondary Use of Personal
Information. MKWI 2016

Weitere ähnliche Inhalte

Andere mochten auch

EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-SicherheitsmanagementEN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
Sven Wohlgemuth
 
Privacy in Business Processes - Disclosure of Personal Data to 3rd Parties
Privacy in Business Processes - Disclosure of Personal Data to 3rd PartiesPrivacy in Business Processes - Disclosure of Personal Data to 3rd Parties
Privacy in Business Processes - Disclosure of Personal Data to 3rd Parties
Sven Wohlgemuth
 
Tagging Disclosure of Personal Data to Third Parties to Preserve Privacy
Tagging Disclosure of Personal Data to Third Parties to Preserve PrivacyTagging Disclosure of Personal Data to Third Parties to Preserve Privacy
Tagging Disclosure of Personal Data to Third Parties to Preserve Privacy
Sven Wohlgemuth
 
Privacy-Enhancing Trust Infrastructure for Process Mining
Privacy-Enhancing Trust Infrastructure for Process MiningPrivacy-Enhancing Trust Infrastructure for Process Mining
Privacy-Enhancing Trust Infrastructure for Process Mining
Sven Wohlgemuth
 
Schlüsselverwaltung - Objektorientierter Entwurf und Implementierung
Schlüsselverwaltung - Objektorientierter Entwurf und ImplementierungSchlüsselverwaltung - Objektorientierter Entwurf und Implementierung
Schlüsselverwaltung - Objektorientierter Entwurf und Implementierung
Sven Wohlgemuth
 
Der IT-Sicherheitskatalog ist da!
Der IT-Sicherheitskatalog ist da!Der IT-Sicherheitskatalog ist da!
Der IT-Sicherheitskatalog ist da!
Torben Haagh
 
PersoApp - An Open Source Community for the new German national ID card
PersoApp - An Open Source Community for the new German national ID cardPersoApp - An Open Source Community for the new German national ID card
PersoApp - An Open Source Community for the new German national ID card
Sven Wohlgemuth
 
Digitalisierte bAV
Digitalisierte bAV Digitalisierte bAV
Digitalisierte bAV
Torben Haagh
 
Effizienter mit Kooperationen bei Integra-Partnern
Effizienter mit Kooperationen bei Integra-PartnernEffizienter mit Kooperationen bei Integra-Partnern
Effizienter mit Kooperationen bei Integra-Partnern
Torben Haagh
 

Andere mochten auch (9)

EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-SicherheitsmanagementEN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
EN 6.3: 2 IT-Compliance und IT-Sicherheitsmanagement
 
Privacy in Business Processes - Disclosure of Personal Data to 3rd Parties
Privacy in Business Processes - Disclosure of Personal Data to 3rd PartiesPrivacy in Business Processes - Disclosure of Personal Data to 3rd Parties
Privacy in Business Processes - Disclosure of Personal Data to 3rd Parties
 
Tagging Disclosure of Personal Data to Third Parties to Preserve Privacy
Tagging Disclosure of Personal Data to Third Parties to Preserve PrivacyTagging Disclosure of Personal Data to Third Parties to Preserve Privacy
Tagging Disclosure of Personal Data to Third Parties to Preserve Privacy
 
Privacy-Enhancing Trust Infrastructure for Process Mining
Privacy-Enhancing Trust Infrastructure for Process MiningPrivacy-Enhancing Trust Infrastructure for Process Mining
Privacy-Enhancing Trust Infrastructure for Process Mining
 
Schlüsselverwaltung - Objektorientierter Entwurf und Implementierung
Schlüsselverwaltung - Objektorientierter Entwurf und ImplementierungSchlüsselverwaltung - Objektorientierter Entwurf und Implementierung
Schlüsselverwaltung - Objektorientierter Entwurf und Implementierung
 
Der IT-Sicherheitskatalog ist da!
Der IT-Sicherheitskatalog ist da!Der IT-Sicherheitskatalog ist da!
Der IT-Sicherheitskatalog ist da!
 
PersoApp - An Open Source Community for the new German national ID card
PersoApp - An Open Source Community for the new German national ID cardPersoApp - An Open Source Community for the new German national ID card
PersoApp - An Open Source Community for the new German national ID card
 
Digitalisierte bAV
Digitalisierte bAV Digitalisierte bAV
Digitalisierte bAV
 
Effizienter mit Kooperationen bei Integra-Partnern
Effizienter mit Kooperationen bei Integra-PartnernEffizienter mit Kooperationen bei Integra-Partnern
Effizienter mit Kooperationen bei Integra-Partnern
 

Ähnlich wie EN 6.3: 3 Sicherheitsmodelle

Sicherheitsgipfel - Chancen und Risiken der IT
Sicherheitsgipfel - Chancen und Risiken der ITSicherheitsgipfel - Chancen und Risiken der IT
Sicherheitsgipfel - Chancen und Risiken der IT
Fraunhofer AISEC
 
+ Self Defending Network V2
+ Self Defending Network V2+ Self Defending Network V2
+ Self Defending Network V2
Werner Buhre
 
Cyberrisiken in der Zahnarztpraxis - Prophylaxe
Cyberrisiken in der Zahnarztpraxis  - ProphylaxeCyberrisiken in der Zahnarztpraxis  - Prophylaxe
Cyberrisiken in der Zahnarztpraxis - Prophylaxe
jiricejka
 
Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?
Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?
Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?
lernet
 
Sicherheit für das Energieinformationsnetz
Sicherheit für das EnergieinformationsnetzSicherheit für das Energieinformationsnetz
Sicherheit für das Energieinformationsnetz
Fraunhofer AISEC
 
Web application security
Web application securityWeb application security
Web application security
Oliver Hader
 
Cybersecurity 2013 - Design for Security
Cybersecurity 2013 - Design for SecurityCybersecurity 2013 - Design for Security
Cybersecurity 2013 - Design for Security
Fraunhofer AISEC
 
Wenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und Risiken
Wenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und RisikenWenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und Risiken
Wenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und Risiken
m2m_blog
 
IT-Gefährdungslage / IT-Sicherheit
IT-Gefährdungslage / IT-SicherheitIT-Gefährdungslage / IT-Sicherheit
IT-Gefährdungslage / IT-Sicherheit
Filipe Felix
 
Innovation braucht Sicherheit - Sicherheit braucht Forschung
Innovation braucht Sicherheit - Sicherheit braucht ForschungInnovation braucht Sicherheit - Sicherheit braucht Forschung
Innovation braucht Sicherheit - Sicherheit braucht Forschung
Fraunhofer AISEC
 
Grenzen der Kryptographie
Grenzen der KryptographieGrenzen der Kryptographie
Grenzen der Kryptographie
Hans Mittendorfer
 
Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...
Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...
Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...
Fujitsu Central Europe
 
2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte
2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte
2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte
Kirsten Fiedler
 
Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)
Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)
Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)
Praxistage
 
Internet of (Every)Thing
Internet of (Every)ThingInternet of (Every)Thing
Internet of (Every)Thing
Fraunhofer AISEC
 
Blockchains in Einkauf und Supply Chain
Blockchains in Einkauf und Supply ChainBlockchains in Einkauf und Supply Chain
Blockchains in Einkauf und Supply Chain
Philipp Roessler
 
Wie sicher ist Ihre IT-Infrastruktur?
Wie sicher ist Ihre IT-Infrastruktur?Wie sicher ist Ihre IT-Infrastruktur?
Wie sicher ist Ihre IT-Infrastruktur?WM-Pool Pressedienst
 
WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...
WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...
WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...
Symantec
 
Cyber Security aus Sicht der Wissenschaft
Cyber Security aus Sicht der WissenschaftCyber Security aus Sicht der Wissenschaft
Cyber Security aus Sicht der Wissenschaft
Fraunhofer AISEC
 

Ähnlich wie EN 6.3: 3 Sicherheitsmodelle (20)

Sicherheitsgipfel - Chancen und Risiken der IT
Sicherheitsgipfel - Chancen und Risiken der ITSicherheitsgipfel - Chancen und Risiken der IT
Sicherheitsgipfel - Chancen und Risiken der IT
 
+ Self Defending Network V2
+ Self Defending Network V2+ Self Defending Network V2
+ Self Defending Network V2
 
Cyberrisiken in der Zahnarztpraxis - Prophylaxe
Cyberrisiken in der Zahnarztpraxis  - ProphylaxeCyberrisiken in der Zahnarztpraxis  - Prophylaxe
Cyberrisiken in der Zahnarztpraxis - Prophylaxe
 
Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?
Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?
Andreas Gabriel: IT-Sicherheit als hemmender Faktor für E-Learning?
 
Sicherheit für das Energieinformationsnetz
Sicherheit für das EnergieinformationsnetzSicherheit für das Energieinformationsnetz
Sicherheit für das Energieinformationsnetz
 
Web application security
Web application securityWeb application security
Web application security
 
Cybersecurity 2013 - Design for Security
Cybersecurity 2013 - Design for SecurityCybersecurity 2013 - Design for Security
Cybersecurity 2013 - Design for Security
 
Wenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und Risiken
Wenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und RisikenWenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und Risiken
Wenn Maschinen sprechen - Erfolgsfaktoren für M2M - Chancen und Risiken
 
IT-Gefährdungslage / IT-Sicherheit
IT-Gefährdungslage / IT-SicherheitIT-Gefährdungslage / IT-Sicherheit
IT-Gefährdungslage / IT-Sicherheit
 
Innovation braucht Sicherheit - Sicherheit braucht Forschung
Innovation braucht Sicherheit - Sicherheit braucht ForschungInnovation braucht Sicherheit - Sicherheit braucht Forschung
Innovation braucht Sicherheit - Sicherheit braucht Forschung
 
Grenzen der Kryptographie
Grenzen der KryptographieGrenzen der Kryptographie
Grenzen der Kryptographie
 
Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...
Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...
Sicherheit und Vertrauen - Herausforderungen und Chancen in einer digitalen G...
 
2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte
2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte
2021 Bundeskonferenz BAG - Digitale Sicherheit, persönliche Rechte
 
Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)
Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)
Dr. Manfred Wöhrl (Gerichtssachverständiger, Sicherheitsexperte)
 
Internet of (Every)Thing
Internet of (Every)ThingInternet of (Every)Thing
Internet of (Every)Thing
 
Blockchains in Einkauf und Supply Chain
Blockchains in Einkauf und Supply ChainBlockchains in Einkauf und Supply Chain
Blockchains in Einkauf und Supply Chain
 
Wie sicher ist Ihre IT-Infrastruktur?
Wie sicher ist Ihre IT-Infrastruktur?Wie sicher ist Ihre IT-Infrastruktur?
Wie sicher ist Ihre IT-Infrastruktur?
 
WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...
WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...
WHITEPAPER; Achten Sie auf Ihre Daten: Sechs Verlustrisiken für Ihre mobilen ...
 
Wie schützen Sie Ihre Messaging- & Collaboration-Infrastruktur? Lessons learn...
Wie schützen Sie Ihre Messaging- & Collaboration-Infrastruktur? Lessons learn...Wie schützen Sie Ihre Messaging- & Collaboration-Infrastruktur? Lessons learn...
Wie schützen Sie Ihre Messaging- & Collaboration-Infrastruktur? Lessons learn...
 
Cyber Security aus Sicht der Wissenschaft
Cyber Security aus Sicht der WissenschaftCyber Security aus Sicht der Wissenschaft
Cyber Security aus Sicht der Wissenschaft
 

Mehr von Sven Wohlgemuth

A Secure Decision-Support Scheme for Self-Sovereign Identity Management
A Secure Decision-Support Scheme for Self-Sovereign Identity ManagementA Secure Decision-Support Scheme for Self-Sovereign Identity Management
A Secure Decision-Support Scheme for Self-Sovereign Identity Management
Sven Wohlgemuth
 
Competitive Compliance with Blockchain
Competitive Compliance with BlockchainCompetitive Compliance with Blockchain
Competitive Compliance with Blockchain
Sven Wohlgemuth
 
Secure Sharing of Design Information with Blockchains
Secure Sharing of Design Information with BlockchainsSecure Sharing of Design Information with Blockchains
Secure Sharing of Design Information with Blockchains
Sven Wohlgemuth
 
個人情報の有効活用を可能にする (Enabling effective use of personal information)
 個人情報の有効活用を可能にする (Enabling effective use of personal information) 個人情報の有効活用を可能にする (Enabling effective use of personal information)
個人情報の有効活用を可能にする (Enabling effective use of personal information)
Sven Wohlgemuth
 
Privacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity ManagementPrivacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity Management
Sven Wohlgemuth
 
WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...
WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...
WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...
Sven Wohlgemuth
 
Privacy in e-Health
Privacy in e-HealthPrivacy in e-Health
Privacy in e-Health
Sven Wohlgemuth
 
On Privacy in Medical Services with Electronic Health Records
On Privacy in Medical Services with Electronic Health RecordsOn Privacy in Medical Services with Electronic Health Records
On Privacy in Medical Services with Electronic Health Records
Sven Wohlgemuth
 
Privacy with Secondary Use of Personal Information
Privacy with Secondary Use of Personal InformationPrivacy with Secondary Use of Personal Information
Privacy with Secondary Use of Personal Information
Sven Wohlgemuth
 
International Workshop on Information Systems for Social Innovation (ISSI) 2009
International Workshop on Information Systems for Social Innovation (ISSI) 2009International Workshop on Information Systems for Social Innovation (ISSI) 2009
International Workshop on Information Systems for Social Innovation (ISSI) 2009
Sven Wohlgemuth
 
Durchsetzung von Privacy Policies in Dienstenetzen
Durchsetzung von Privacy Policies in DienstenetzenDurchsetzung von Privacy Policies in Dienstenetzen
Durchsetzung von Privacy Policies in Dienstenetzen
Sven Wohlgemuth
 
Privacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity ManagementPrivacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity Management
Sven Wohlgemuth
 
Privacy in Business Processes by Identity Management
Privacy in Business Processes by Identity ManagementPrivacy in Business Processes by Identity Management
Privacy in Business Processes by Identity Management
Sven Wohlgemuth
 
Resilience by Usable Security
Resilience by Usable SecurityResilience by Usable Security
Resilience by Usable Security
Sven Wohlgemuth
 
Sicherheit in einer vernetzten Welt
Sicherheit in einer vernetzten WeltSicherheit in einer vernetzten Welt
Sicherheit in einer vernetzten Welt
Sven Wohlgemuth
 
Solutions for Coping with Privacy and Usability
Solutions for Coping with Privacy and UsabilitySolutions for Coping with Privacy and Usability
Solutions for Coping with Privacy and Usability
Sven Wohlgemuth
 
iManager - nutzer-zentrierter Identitätsmanager
iManager - nutzer-zentrierter IdentitätsmanageriManager - nutzer-zentrierter Identitätsmanager
iManager - nutzer-zentrierter Identitätsmanager
Sven Wohlgemuth
 
ATUS - A Toolkit for Usable Security
ATUS - A Toolkit for Usable SecurityATUS - A Toolkit for Usable Security
ATUS - A Toolkit for Usable Security
Sven Wohlgemuth
 
PersoApp - Secure and User-Friendly Internet Applications
PersoApp - Secure and User-Friendly Internet ApplicationsPersoApp - Secure and User-Friendly Internet Applications
PersoApp - Secure and User-Friendly Internet Applications
Sven Wohlgemuth
 
FIDIS D3.3 Study on Mobile Identity Management
FIDIS D3.3 Study on Mobile Identity ManagementFIDIS D3.3 Study on Mobile Identity Management
FIDIS D3.3 Study on Mobile Identity Management
Sven Wohlgemuth
 

Mehr von Sven Wohlgemuth (20)

A Secure Decision-Support Scheme for Self-Sovereign Identity Management
A Secure Decision-Support Scheme for Self-Sovereign Identity ManagementA Secure Decision-Support Scheme for Self-Sovereign Identity Management
A Secure Decision-Support Scheme for Self-Sovereign Identity Management
 
Competitive Compliance with Blockchain
Competitive Compliance with BlockchainCompetitive Compliance with Blockchain
Competitive Compliance with Blockchain
 
Secure Sharing of Design Information with Blockchains
Secure Sharing of Design Information with BlockchainsSecure Sharing of Design Information with Blockchains
Secure Sharing of Design Information with Blockchains
 
個人情報の有効活用を可能にする (Enabling effective use of personal information)
 個人情報の有効活用を可能にする (Enabling effective use of personal information) 個人情報の有効活用を可能にする (Enabling effective use of personal information)
個人情報の有効活用を可能にする (Enabling effective use of personal information)
 
Privacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity ManagementPrivacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity Management
 
WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...
WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...
WP14 Workshop "From Data Economy to Secure Logging as a Step towards Transpar...
 
Privacy in e-Health
Privacy in e-HealthPrivacy in e-Health
Privacy in e-Health
 
On Privacy in Medical Services with Electronic Health Records
On Privacy in Medical Services with Electronic Health RecordsOn Privacy in Medical Services with Electronic Health Records
On Privacy in Medical Services with Electronic Health Records
 
Privacy with Secondary Use of Personal Information
Privacy with Secondary Use of Personal InformationPrivacy with Secondary Use of Personal Information
Privacy with Secondary Use of Personal Information
 
International Workshop on Information Systems for Social Innovation (ISSI) 2009
International Workshop on Information Systems for Social Innovation (ISSI) 2009International Workshop on Information Systems for Social Innovation (ISSI) 2009
International Workshop on Information Systems for Social Innovation (ISSI) 2009
 
Durchsetzung von Privacy Policies in Dienstenetzen
Durchsetzung von Privacy Policies in DienstenetzenDurchsetzung von Privacy Policies in Dienstenetzen
Durchsetzung von Privacy Policies in Dienstenetzen
 
Privacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity ManagementPrivacy in Business Processes by User-Centric Identity Management
Privacy in Business Processes by User-Centric Identity Management
 
Privacy in Business Processes by Identity Management
Privacy in Business Processes by Identity ManagementPrivacy in Business Processes by Identity Management
Privacy in Business Processes by Identity Management
 
Resilience by Usable Security
Resilience by Usable SecurityResilience by Usable Security
Resilience by Usable Security
 
Sicherheit in einer vernetzten Welt
Sicherheit in einer vernetzten WeltSicherheit in einer vernetzten Welt
Sicherheit in einer vernetzten Welt
 
Solutions for Coping with Privacy and Usability
Solutions for Coping with Privacy and UsabilitySolutions for Coping with Privacy and Usability
Solutions for Coping with Privacy and Usability
 
iManager - nutzer-zentrierter Identitätsmanager
iManager - nutzer-zentrierter IdentitätsmanageriManager - nutzer-zentrierter Identitätsmanager
iManager - nutzer-zentrierter Identitätsmanager
 
ATUS - A Toolkit for Usable Security
ATUS - A Toolkit for Usable SecurityATUS - A Toolkit for Usable Security
ATUS - A Toolkit for Usable Security
 
PersoApp - Secure and User-Friendly Internet Applications
PersoApp - Secure and User-Friendly Internet ApplicationsPersoApp - Secure and User-Friendly Internet Applications
PersoApp - Secure and User-Friendly Internet Applications
 
FIDIS D3.3 Study on Mobile Identity Management
FIDIS D3.3 Study on Mobile Identity ManagementFIDIS D3.3 Study on Mobile Identity Management
FIDIS D3.3 Study on Mobile Identity Management
 

EN 6.3: 3 Sicherheitsmodelle

  • 1. EN 6.3: IT-Sicherheit und Technischer Datenschutz Donnerstag,den 31. März 2016 Dozent: Dr. Sven Wohlgemuth <wohlgemuth@acm.org> Themen 1. IT-Sicherheit und Datenschutz 2. IT-Compliance und IT-Sicherheitsmanagement 3. Sicherheitsmodelle 4. Kryptographie 5. Netzwerksicherheit 6. Sichere Dienste 7. IT-Risikomanagement 8. Risikoidentifizierung 9. Risikoquantifizierung 10. Benutzbare Sicherheit Industrie eGovernment eHealthcare Energie Transport und mehr … Soziale Netze eEducation Geschäftsziele / Regulierungen / Nachhaltigkeit Internet of Things / Service Computing
  • 2. Agenda 3. Sicherheitsmodelle 3.1 Epochen der IT-Sicherheit 3.2 Zugriffskontrolle 3.3 Das Safety Problem 3.4 Nutzungskontrolle
  • 3. Epochen der IT / Metaphern der Sicherheit Burg Marktplatz Metropole Mainframe Internet Ubiquitous Computing „Die Guten sind drin, die Schlechten sind draußen Server-based Security Client-based Security autonome Interaktion menschliche Interaktion Müller und Zahoransky, Telematik 4 Sicherheit und Privatsphäre, 2015
  • 4. Herausforderung • Verteidigung der Burg – Nicht berechtigte Bürger bleiben draußen Angreifer • „Outsiders“ oder „Intruders“ Schutzziel • Zugriffskontrolle und Vertraulichkeit Lösung • Strenge Zugangskontrolle (Firewalls) und Intrusion-Detection Monitors Epoche Mittelalter Müller und Zahoransky, Telematik 4 Sicherheit und Privatsphäre, 2015
  • 5. Mittelalter: Quelle der Angriffe Der Angreifer saß überwiegend in der eigenen Burg frühere Mitarbeiter 13% interne Mitarbeiter 81% Outsiders 6% Log und Firewall- security Audit Security Quelle: Data Processing Management Assoc, 1997
  • 6. Mittelalter: Mangelhafte Abwehr der Burg 38.000 Angriffe Schutz 24.000 (65%) erfolgreich 998 (4 %) erkannt 23.712 (96%) nicht erkannt! Nachweis Quelle: Testangriffe US-Militär, Defense Information Systems Agency, Mai 1996 • Firewalls und Intrusion Detection è Hohe „Dunkelziffer“ unerkannter Angriffe • Bedarf an Authentifizierung, Autorisierung und Accounting nimmt zu
  • 7. Mittelalter: Wer ist der (gute) Insider? Authentifizierung: Erkennung von Kommunikationspartnern, aber… Sicherheitskonform Normal Anormal Profile Fehlalarm Authentifizierung = Verlust der Privatsphäre Sicherheitsgefährdend
  • 8. Herausforderung – Aufbauen von Vertrauen – Dezentrales Sicherheitsbedürfnis Angreifermodell – Mann in der Mitte – „Impersonation“ von Kommunikationspartnern Themen – (Korrekte) Mehrseitige Sicherheit – Sind Sicherheitsmechanismen „korrekt“ bzgl. ihrer Ziele? à Verifikation bzw. Bewertung von Schwachstellen wird erforderlich – Vertrauen: Basiert auf Software und Hardware • Software à Sicherheitsprotokolle • Hardware à Trusted Computing Epoche Internet Müller und Zahoransky, Telematik 4 Sicherheit und Privatsphäre, 2015
  • 9. Internet: „In Internet nobody knows you are a dog“ Alice Bob? Und wenn der Hund „beißt“?
  • 10. Internet: Mann in der Mitte Attacke Einem Angreifer gelingt es, den Kommunikationskanal soweit unter die eigene Kontrolle zu bringen, dass die „Abgehörten“ nicht feststellen können, ob sie tatsächlich miteinander oder mit dem Angreifer kommunizieren Nutzung – abhängig vom Ziel eines Protokolls – Angriffe können genutzt werden, um sich unberechtigt Zugang zu Informationen zu verschaffen, sie zu manipulieren oder komplette Datenverbindungen zu übernehmen („connection hijacking“)
  • 11. Mann in der Mitte Nutzung: Angriffe können genutzt werden, um sich unberechtigt Zugang zu Informationen zu verschaffen, sie zu manipulieren oder komplette Datenverbindungen zu übernehmen („connection hijacking“). Beschreibung: Einem Angreifer gelingt es, den Kommunikationskanal so weit unter die eigene Kontrolle zu bringen, dass die „Abgehörten“ nicht feststellen können, ob sie tatsächlich miteinander oder mit dem Angreifer kommunizieren.
  • 12. - Einkommen - Kredit - Versicherungen - Immobilien - … - verheiratet - Kinder - … IDENTITÄT Führungs- zeugnis Karriere Gesundheit Finanzen Familien- status Kauf- verhalten Name Geräte-ID Quelle: Holger Eggs, Günter Müller: „Sicherheit und Vertrauen: Mehrwert im E-Commerce“, Berlin 2001 Schutzobjekt: Identität
  • 13. IDENTITÄT Führungs- zeugnis Karriere Gesundheit Finanzen Familien- status Kauf- verhalten Name Geräte-DI Privatsphäre Verfügung über Kollektion, Zugriff, Veränderung und die Verteilung persönlicher Daten ? ? ? Reputation i Reputation j Reputation kSicherheit Vertrauen Vorhersehbarkeit des Verhaltens durch die gewählte Identität Identität und Sicherheit Quelle: Holger Eggs, Günter Müller: „Sicherheit und Vertrauen: Mehrwert im E-Commerce“, Berlin 2001
  • 14. Sicherheit in Schichtenmodellen Charakteristika: • Vermittelte und paketbasierte Übertragung • Weltweit standardisierte Kommunikationsprotokolle • Fokus auf Verfügbarkeit è generell mehrere Routen zu einem Ziel Schäfer, Netzwerksicherheit, 2003
  • 15. Angriffspunkte: – keine Zertifizierung/ Attestierung der bei Übertragung beteiligten Knoten ➜ komplette Kommunikationsinfrastruktur bis auf eigenes Endsystem Bedrohung: – Übertragung im Klartext mittels Standardformaten ermöglicht Informationsgewinnung [ ] und Modifikation [ ] (Bsp.: http://odem.org/insert_coin/) – Metainformationen der Pakete ermöglichen präzise Beeinträchtigung [ ] der Kommunikation (Bsp.: Internetzensur) Fragen: – Welchen Komponenten der Infrastruktur kann man überhaupt vertrauen? – Welche Komponente soll welche Sicherheitsmaßnahmen umsetzen? Netzwerksicherheit: Struktur Schäfer, Netzwerksicherheit, 2003
  • 16. Netzwerksicherheit: Funktion Angriffspunkte: – alle Schichten, welche unter jener liegen, die Schutzziele umsetzt – da keine Sicherheitsvorkehrungen innerhalb der Schichten und keine gesonderte Sicherheitsschicht è prinzipiell Angriff über jeder Schicht möglich Bedrohung: – dieselben wie unter struktureller Betrachtung Maßnahmen: – im Sinne der Modularisierung: Umsetzung so früh wie möglich (IPSec) – im Sinne der Kompatibilität: Umsetzung so spät wie möglich (SSH oder SSL) Schäfer, Netzwerksicherheit, 2003
  • 17. Grundlegendes: – gleiche Bedrohungen wie im Festnetz – identische Gegenmaßnahmen Erweiterte Angriffsfläche: – Zugang zu Diensten wird durch drahtlose Verbindung einfacher und dementsprechend unsicherer – Handover und Roaming erzwingt regelmäßige Re- Authentifizierung – Schlüsselverwaltung wird wegen des dynamischen Netzzugangs komplizierter Besonderes Schutzziel: – Ort eines Gerätes oder Nutzers wird wichtigste Information è Schutz der Ortsinformation ist notwendig! Netzwerksicherheit: Mobilität
  • 18. Beispiel: Mobiler Bürger 18 Bedrohung durch: • Ortsinformation • Spontane Vernetzung • Personenbezogene Daten • Dauerhafter Betrieb • Datenspuren: Verkettbarkeit • Diebstahl des Gerätes: Impersonation Home Profile Sven Wohlgemuth Date: 09.06.05 Time: 08:00 Read e-mails IP: 132.15.16.3 Ticket Profile Sven Wohlgemuth Date: 09.06.05 Time: 08:30 Buy e-ticket IP: 132.15.16.3 Book Profile Sven Wohlgemuth Date: 09.06.05 Time: 09:00 Look for books IP: 132.15.16.3Visitor Profile Sven Wohlgemuth Date: 09.06.05 Time: 10:00 Visit Roemer IP: 132.15.16.3 FIDIS Profile Sven Wohlgemuth Date: 10.06.05 Time: 9:00 FIDIS meeting IP: 132.15.16.3 Home Profile Sven Wohlgemuth Date: 09.06.05 Time: 08:00 Read e-mails IP: 132.15.16.3 Wohnung Angreifer Müller und Wohlgemuth, Study on Mobile Identity Management, 2005
  • 19. Epoche Ubiquitous Computing Herausforderungen – Überall, jederzeit, alles für Nachhaltigkeit – Spontaner zuverlässiger Informationsaustausch Angreifermodell – „Mann in den Endknoten“ mit Abhängigkeiten Themen – Ist Sicherheit überhaupt technisch machbar? – Schwerpunkt „Security Engineering“ • Sichere Softwareentwicklung – Vertrauensaufbau wird erschwert – Sicherheitsrichtlinien werden wichtiger • Mechanismen zu deren Implementierung • Persönliches Risikomanagement – Resilienz mit skalierbarer Zweitverwendung von persönlichen Daten - New processes - Modified processes 2) Consequences Economy Employment Elderly Society Education Energy Social infrastructures - Crime, terrorism, and natural disasters - Damages/Failure of ICT services 1) Unexpected, inevitable Interferences by - Cascading interferences - Interoperability 3) Additional Risk: "Outsider" becomes "Insider" - Controllability - Non-availability of services/data - Non-authorized access to services/data - Incorrect data 4) Resultant Interferences by - Privacy violation - Physical damages ICT
  • 20. Beispiel: Datennutzung mit SNS Model Builder PredictorDatabase Empfehlungssystem di dj Eigene Abbildung nach(Lam et al. 2006) Persönliche Daten di, dj, ... Behörden Transport Gesundh eit Energie ... Persönliche Empfehlungen di*, dj*, ... 2 neue Mitglieder/Sekunde (press.linkedin.com) ... 500+ TB/Tag (techcrunch.com) 340 Mio Tweets/Tag (business.twitter.com) 1+ Mrd Suchanfragen/Tag (www.google.com) d*i d*j
  • 21. Agenda 3. Sicherheitsmodelle 3.1 Epochen der IT-Sicherheit 3.2 Zugriffskontrolle 3.3 Das Safety Problem 3.4 Nutzungskontrolle
  • 22. Zugriffskontrolle (Access Control) • Zugriffskontrolle: Schutz einer Systemressource vor unautorisiertem Zugriff • Bezeichnet notwendige Mechanismen zur Einhaltung einer vorgegebenen Sicherheitsrichtlinie beim Zugriff eines Subjektes s auf ein Objekt o • Gegenwärtig: Best Practice (ISO/IEC 27k, BSI Standard-100, ...) ReferenzmonitorSubjekt ObjektAnfrage gewährt abgelehnt Richtlinie Zugriffskontrolle Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
  • 23. Subjekt – Aktive Einheit – Initiiert den Zugriff auf Objektressourcen – Im Kontext von Betriebssystemen • Prozesse Objekt – Passive, zu schützende Einheit – Speichert gewöhnlich Informationen – Im Kontext von Betriebssystemen • Dateien, Verzeichnisse, usw. Aber: Die Trennung von Objekten und Subjekten ist nicht immer eindeutig • Eine Prozess sendet eine Nachricht zu einem anderen Prozess. Ist der empfangende Prozess nun Subjekt oder Objekt? Objekt und Subjekt Subjekt Objekt Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
  • 24. Universelle Rechte – Bezeichnen allgemeine, nicht objektspezifische Operationen – Beispiel: Zugriffsarten auf Dateisystem • Lesen, Schreiben, Ausführen Objektspezifische Rechte – Beschränkt auf einen festgelegten, funktionalen Kontext – Bindung an die jeweiligen Objekt – Beispiel: Objekt-Orientierte Programmierung (OOP) • Ausführung von Methoden eines Objektes Zugriffsrechte Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
  • 25. • Wichtiges konzeptuelles Modell – Als physikalische oder logische Einheit im System nicht unbedingt vorhanden • Sollte jeden Zugriffsversuch kontrollieren • Sollte keinen Rechtentzug zwischen Rechtprüfung und entsprechender Rechtausübung erlauben – Sonst unzulässiger Rechtzustand • Muss selbst vor unberechtigtem Zugriff geschützt bzw. isoliert werden è Trusted Computing Base Referenzmonitor Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
  • 26. • Definiert die Bedingungen, unter denen einem Subjekt Zugriff auf ein Objekt gewährt wird • Definiert eine Beziehung zwischen Subjekten, Objekten und Zugriffsrechten • Analog zu einer "Gesetzsammlung" • Der Ausdruck Sicherheitsrichtlinie wird oft auch in einem weiteren Sinne genutzt – Spezifikation aller Sicherheitsaspekte eines Systems inklusive Risiken, Angriffe, Gegenmaßnahmen, usw. Sicherheitsrichtlinie (Security Policy) Saltzer und Schroeder, The Protection of Information in Computer Systems, 1974
  • 27. Sicherheitsmarkierung (Labels/Lattice) Sensitivitätslevel • HierarchischesAttribut einer Einheit • Militärisch: Nicht-klassifiziert < Vertraulich < Geheim • Kommerziell: Öffentlich < Sensitiv < Proprietär < Eingeschränkt Sicherheitskategorien • Nichthierarchische Gruppierung von Einheiten • Beispiel:AbteilungA, Abteilung B, Administration Sicherheitslabel • Kombination von Sicherheitslevel und –kategorie – Label: Level x 2Kategorien • Sicherheitslabel für Sensitivität von – Subjekten heißen Freigabe (clearences) – Objekten heißen Klassifizierung (classifications) Lattice-based Access Control Sandhu 1993 Sandhu, Lattice-based Access Control Models, 1993
  • 28. Zugriffskontrollmatrix Rechtzustand eines Systems zu einem Zeitpunkt t gegeben als Matrix Mt = St x Ot à 2Rechte gegeben • Spalten Menge Ot von Objekten • Zeilen Menge St von Subjekten # • Zelle Entsprechende Menge der Zugriffsrechte Mt Datei1 Datei2 Datei3 Prozess1 Prozess2 Prozess1 {own, read, write} {own,read, write} {read, write} Prozess2 {read} {own, read} Prozess3 {own, write} {write} Harrison, Ruzzo und Ullman, Protection in Operating Systems, 1976
  • 29. ACL (Access Control List) Jedes Objekt speichert eigeneACL aller Subjekte, die Zugriff auf Objekt besitzen Vorteile • Einfache Bestimmung der Zugriffsrechte auf gegebenes Objekt • Rechtrücknahme meist effizient realisierbar Nachteile • Aufwändige Kontrolle bei langen ACL • Skalierbarkeit: Bestimmen der Rechte eines Subjekts i.d.R. sehr aufwändig Capability List (Credentials) Jedes Subjekt speichert eigeneAutorisierung auf Objekte (Trust Management) Vorteile • Einfache Bestimmung der Zugriffsrechte eines Subjektes • Kontrolle durch Prüfung des Credentials Nachteile • Widerruf von Rechten impliziert u.U. zeitliche Ungewissheit • Sicht von Objekte auf Subjekte ist schwierig Zugriffskontrollmatrix: Repräsentation Mt Datei1 Datei2 Datei3 Prozess1 Prozess2 Prozess1 {own, read, write} {own,read, write} {read, write} Prozess2 {read} {own, read} Prozess3 {own, {write}
  • 30. Credential-basierte Zugriffskontrolle • Benutzer können ein Stück der Liste selbst speichern – Entspricht der Idee eines Ausweises/Eintrittskarte – Liste ist nur noch implizit vorhanden • Beim Aktivieren einer Berechtigung legt der Benutzer dieses Stück der Liste vor, das die entsprechende Berechtigung enthält • Problem: Sicherstellen, dass der Nutzer seine Berechtigungen nicht manipulieren kann – Entspricht der Echtheitskontrolle eines Ausweises/einer Eintrittskarte – Kann mittels Zertifikaten gelöst werden – Zentraler Vertrauensanker ist notwendig
  • 31. Zugriffskontrollstrategie: DAC Discretionary Access Control (DAC) – Benutzerbestimmbare Strategie (Eigentümer-Prinzip) • Benutzer ist Eigentümer von seinen Objekten • Eigentümer kontrolliert Zugangsrechte zu seinen Objekten – Eigentümer kann jedoch i.a. "Ownership" nicht transferieren – Beispiel: das Unix-Betriebssystem erlaubt das setzen von Lese-, Schreib- und Ausführungsrechten für im Besitz befindliche Dateien – Flexibles Rechtesystem, aber offen für Fehler • Alle Benutzer müssen Sicherheitsleitlinie verstehen und anwenden • Objektbezogene Sicherheitseigenschaften (keine globalen) – Ohne Berücksichtigung von Benutzungs-, Kommunikations- oder Kooperationsabhängigkeiten zwischen Objekten
  • 32. Zugriffskontrollstrategie: MAC Mandatory Access Control (MAC) – Systemweite Durchsetzung von Sicherheitsrichtlinien • "zwingend", da Subjekte Rechte nicht transferieren können • Unabhängig von Benutzeraktionen – Formale Autorisierung durch Vergleich von • Clearances (Freigabelevel der Subjekte) • Classifications (Sensitivität der Objekte) • Beispiel: Subjekte können nur auf dominierte Objekte zugreifen (Objekte gleichen oder niedrigeren Levels) – Kombinierbar mit DAC • Systembestimmtes MAC überschreibt jedoch benutzerbestimmtes DAC • Beispiel: Bell-LaPadula
  • 33. Dominanz Dominanz begrenz in Abhängigkeit der Sicherheitklassen die autorisierten Zugriffe eines Subjektes s. Objekt o dominiert Subjekt s (s wird von o dominiert), falls: Ein Subjekt kann ein Objekt lesen, falls: • der Freigabe-Grad (clearance) des Subjektes ist mindestens so hoch wie der des Objektes • das Subjekt benötigt Information über alleAbteilungen für die das Objekt klassifiziert ist
  • 34. Zugriffskontrollstrategie: RBAC Role-Based Access Control (RBAC) • Vom Benutzer ausgeübte Rollen bestimmen seine Zugriffsrechte • Rolle: Nachbildung von Organisationsstrukturen und Verantwortlichkeiten – Rollen können überlappende Verantwortlichkeiten besitzen – Veränderung von Rollen ohne Anpassung individueller Benutzerrechte • Rechte nicht bezogen auf Subjekte sondern auf durchzuführende Aufgaben – Subjekte erhalten über Rollenmitgliedschaft Berechtigung zur Ausführung von Aufgaben – Subjekte können gemäß ihren Aufgaben mehrere Rollen besitzen Verwandtschaft zu Gruppenkonzept • Gruppenkonzept als rudimentäres RBAC – Aufgabenbezogene Gruppenfestlegung – Beispiel: jeweils eigene Gruppe für Administratoren und Benutzer • Rollenkonzept jedoch bringt zusammen – Menge von Benutzern auf einer Seite (wie bei Gruppen) – Menge von Berechtigungen auf der anderen (zusätzlich) Sandhu, Coyne, Feinstein und Youman, Role-Based Access Control Models, 1996
  • 35. RBAC: Hierarchien Rollenhierarchien • Vereinfacht Ausdruck der Sicherheitsrichtlinie • Nachbilden hierarchischer Organisationsstrukturen • Beispiel: Kassierer ≤ Kassenprüfer – Ein Mitglied der Kassenprüfer darf mindestens auf alle die Objekte zugreifen, auf die ein Kassierer zugreifen darf Vererbung der Rollenmitgliedschaft • Bildung einer partiellen Ordnung auf Rollen R • Falls rj ≤ ri, dann gilt: ∀s∈S, ri ∈sr(s)⇒ rj ∈sr(s) Kassierer Leiter KundeAngestellter Kunden- betreuer Kassenprüfer ri rj rj besitzt auch Rechte von ri
  • 36. Änderungen in der Zugriffskontrollmatrix Statische Zugriffsmatrix – Schutzzustand Mt des Systems invariant über die Zeit – Mt = M Dynamische Zugriffsmatrix – Veränderungen der Matrix Mt durch Systemkommandos • Löschen oder Erzeugen von Subjekten oder Objekten • Weitergabe oder Rücknahme von Zugriffsrechten – Matrix selbst wird ein zu schützendes Objekt • Berechtigungen für Zustandsänderungen ebenfalls als Recht modelliert ...... d d, d* Datenanbieter /konsument Daten- konsument Datenkonsument /anbieter Daten- anbieter Zweitnutzung: DynamischErstnutzung: Statisch
  • 37. Agenda 3. Sicherheitsmodelle 3.1 Epochen der IT-Sicherheit 3.2 Zugriffskontrolle 3.3 Das Safety Problem 3.4 Nutzungskontrolle
  • 38. Das Safety Problem State-of-the-art: ISO 270xx, BSI Standard-100 (Zugriffskontrolle) ...... d Data provider /consumer Data consumer Data consumer /provider Data provider d, d* ? o1 = d o2 = d* … s1 own, r, w ? own, r, w ? s2 r, w own, r, w s3 ? r, w ? r … General security system Safety ist i.A. nicht-entscheidbar ⇒ Halteproblem der Turing Machine Wahrscheinlichkeit der Zuverlässigkeit einer Aussage auf die Zukunft = 50% Harrison et al. 1976Hamlen et al. 2006 Enforcement Harrison, Ruzzo und Ullman, Protection in Operating Systems, 1976
  • 39. Das Safety Problem: Modellierung Modellierung von Sicherheitseigenschaften – Spezifikation von zulässigen und unzulässigen Rechtzuständen – Nachweis: nur zulässige Zustände sind erreichbar • Erreichbarkeit als Entscheidungsfrage – Bei gegeben Zustand Mt, in dem ein Subjekt s das Recht r an Objekt o nicht besitzt, gibt es Nachfolgezustand Mt+n, in dem das Subjekt s das Recht r an Objekt o wohl besitzt? • Kann die Erreichbarkeit von Zuständen entschieden werden? – Hierfür muss dynamisches Verhalten des Systems beschrieben werden • Folge von Konfigurationen Kt = ( Mt, Ot, St ) • KS0 beschreibt Anfangskonfiguration nttt * S KKKK nttt ++ −++ ==== 11 0 |||| 1 ααα !
  • 40. Das Safety Problem: Nicht-Entscheidbarkeit Safety-Problem – Gibt es für ein beliebiges Regelwerk einenAlgorithmus, der für Recht r, Subjekten s und Objekte o, der das Safety-Problem löst? – Gegeben Kt mit r ∉ Mt( s,o ) – Safety-Problem ist unentscheidbar • (Harrison, Ruzzo, Ullman, 1976) • Beweis auf Halteproblem von Turing-Maschine zurückgeführt ),(:|mit osMrKKn ntntt n ++ ∈=∃ α
  • 41. Safety dank Spezialfall/Erweiterung Status Quo: Language-based information flow control Modell Natural Language Policy High-Level Policy Language Intermediate-Level Security Policy Flow Graph Low-Level Enforcement In der Praxis Take-grant, Type-safety, Lattice-based Access Control, Obligationen Identität, Kryptographie, sicheres öffentliches Verzeichnis, Monitor, Proof-Carrying Code Dezentralisiertes Trust Management HIPAA, (J-)SOX, KonTraG, 95/46/EC, JP PII Protection Law, … Enforcement Classes, Ponder, ExPDT Komplexitätstheoretisch, PKI, Virtualisierung, Testen ISO/IEC 270xx, BSI Standard-100, IETF AAA, NIST SCAP Social/Knowledge Graph, Sticky Policies
  • 42. Spezialfälle der Zugriffskontrolle • Strikte Ordnung der Zugriffsrechte • Symmetrischer Graph der Zugriffsrechte • Safety, falls die Graphen zwischen autorisiert und nicht-autorisiert getrennt sind (es gibt mehr als einen maximal aufspannenden Baum) • Verfügbarkeit von Daten durch Deklassifizierung Lattice-based Access Control Sandhu 1993 Take-grant Lipton and Snyder 1977 S1: u S2: u S3: v O: oS3: w • Azyklischer Graph der Zugriffsrechte • Safety bei x <= 3 Parameter einer Weitergabe • Kein irreparabler Widerruf von Rechten Type-safety Sandhu 1992 S1: u S2: u S3: v O: oS3: w Sandhu, The Typed Access Matrix Model, 1992
  • 43. Bell-LaPadula • Bell und La Padula definierten in 1973 dieses Sicherheitsmodell – zur formalen Beschreibung der erlaubten Pfaden eines Informationsflusses – in einem sicheren IT-System • Informationsflüsse sind über autorisierte Verbindungen zwischen Subjekten und Objekten unterschiedlicher Sicherheitsklassen erlaubt. • Betrachte ein Sicherheitssystem mit den folgenden Eigenschaften: • Das System spezifiziert • eine Menge von Subjekten S und • eine Menge von Objekten O – Jedes Subjekt s in S und jedes Objekt o in O ist statisch einer Sicherheitsklasse C(s) und C(o) zugeordnet (kennzeichnen Freigabe (clearance) und Sicherheitsstufe (classification)) – Die Sicherheitsklassen sind hierarchisch geordnet durch die < Relation
  • 44. Bell-LaPadula Modell Einfache Sicherheitseigenschaft: – Ein Subjekt s darf zum Lesen (read) eines Objektes nur autorisiert sein, falls C(o) ≦ C(s) – Die Sicherheitsklasse (clearance) eines Datenkonsumenten muss mindestens so hoch sein wie die Sicherheitsklasse (classification) der Information *-Eigenschaft: – Ein Subjekt s, das zum Lesen (read) eines Objektes o autorisiert ist, darf für ein Schreiben (write) in ein Objekt p nur autorisiert sein, falls C(o) ≦ C(p) – Der Inhalt eines sensitiven Objektes darf nur in Objekte derselben und einer höheren Sicherheitsstufe geschrieben werden.
  • 45. Mandatory No-Read-Up No-Read-Up oder Simple Security-Eigenschaft • Ein Subjekt s kann nur dann auf ein Objekt o lesend zugreifen, wenn sein Sicherheitsklasse die des Objektes dominiert • r ∈ Mt(s,o) ∧ sc(s) ≥ sc(o) • Beispiel: Ein zu niedrig eingestuftes Subjekt sollte nicht ein geheimes Objekt lesen können o s o o s s Lesezugriffe Zunehmende Sensitivität
  • 46. Mandatory No-Write-Down No-Write-Down oder *-Eigenschaft • Ein Subjekt s kann nur dann auf ein Objekt o schreibend zugreifen, wenn die Sicherheitsklasse des Objektes die des Subjektes dominiert 1. append ∈ Mt(s,o) ∧ sc(s) ≤ sc(o) 2. read-write ∈ Mt(s,o) ∧ sc(s) = sc(o) • Verhindert einen Nachrichtenfluss von einem Subjekte hoher Klasse zu Objekten niedrigerer Klasse o s o o s s Schreibzugriffe Zunehmende Sensitivität
  • 47. Bell-LaPadula: Beispiel o1 o2 s1 o3 o4 o5 s2 app app app,r/w r r/w r/w unklassifiziert vertraulich geheim streng geheim r,exe zulässigerInformationsfluss
  • 48. Bell-LaPadula: Grenzen Sukzessive Höherstufung von Informationen • Subjekte können Information von Objekten niedriger Klasse aufnehmen, diese jedoch nicht an sie zurückfließen lassen • Zwei Möglichkeiten, wenn solcher Nachrichtenfluss explizit gewünscht – Temporäres Herabstufen für solche Subjekte (downgrade) – Einführung von "Trusted Subjects" wie Systemprozessen, die die No-Write-Down-Regel umgehen können Blindes Schreiben • Subjekt s darf Objekt o modifizieren, aufgrund von No-Read-Up anschließend jedoch nicht lesen – Bzgl. Integrität problematisch Statisches Modell • Erzeugung oder Löschung von Subjekten bzw. Objekten nicht beschrieben • Änderung von Zugriffsrechten im Modell nicht beschrieben
  • 49. Dual zu Bell-LaPadula: Biba • Biba ist das Gegenstück (dual) des Bell-LaPadula Models: Biba definiert Integritätsstufen ähnlich zu den Vertraulichkeitsstufen von Bell-LaPadula: no-read-down; no-write-up • Subjekte und Objekte sind in dem Klassifikationsschema zur Integrität geordnet: I(s) und I(o). Einfache Integritätseigenschaften: Subjekt s kann Lesezugriff (read) auf Objekt o haben, falls: I(s) ≧ I(o) Integrität *-Eigenschaft. Falls Subjekt s Lesezugriff (read) auf Objekt o mit der Integritätsstufe l(o) hat, dann darf s in Objekt p schreiben nur, falls l(o) ≧ l(p)
  • 50. Chinese Wall (Brewer & Nash Modell) Sicherheitsstrategie aus kommerziellem Bereich • Modelliert Zugriffsrechte im Finanzbereich – Verhinderung von unzulässigem Insiderwissen wenn Kunden direkte Konkurrenten sind • Beispiele – Banken, Beratungsfirmen, Börsen Idee von Chinese Wall • Berücksichtigung der Zugriffshistorie – Vorherige Zugriffe einer Person bestimmen ihre zukünftigen Zugriffsrechte – Wer auf Objekte eines Unternehmens U in einer Konfliktklasse K zugreift, darf nicht mehr Objekte eines Unternehmens U' ≠ U zugreifen. • Informationsfluss ohne Restriktion, falls Daten gereinigt sind (anonymisiert) Zweistufige Objekthierarchie • Einteilung in unterschiedliche Interessenkonfliktklassen (Branchen) – z.B.: Banken und Ölgesellschaften • Einteilung in unterschiedliche Unternehmen innerhalb der Konfliktklassen – z.B.: Dresdner und Deutsche Bank
  • 51. Chinese Wall: Beispiel Ölgesellschaft Bank BP Aral Dresdner Interessenskonfliktklassen x Unternehmen y o1 o2 o3 o4 o5 o6 Objekte o9o8 o7 Hypo Laptop
  • 52. Chinese Wall: Formaler Schutzzustand Schutzzustand Besteht aus zwei Teilen • Mt Zugriffsmatrix – Benutzerbestimmbare, universelle Rechte R = { Read, Write, Execute } • Nt Zugriffshistorie Zugriffshistorie • Nt: S x O → 2R • Nt(s, o) = {r1,..., rn} falls Subjekt s mit den Rechten {r1,..., rn} auf Objekt o vor dem Zeitpunkt t zugegriffen hat
  • 53. Chinese Wall: Lese- und Schreibregel Lesezugriff (Read-Access) • Nur wenn vorher kein Zugriff stattgefunden hat auf Objekt eines anderen Unternehmens der gleichen Konfliktklasse • Ein Zugriffrecht r ∈ { read, execute } auf ein Objekt o ∈ O ist für ein Subjekt s ∈ S zur Zeit t genau dann gegeben, wenn r ∈ Mt(s, o) ∧ ∀ o‘∈ O , Nt(s, o‘) ≠ Ø ⇒ ( y(o‘) = y(o) ∨ x(o‘) ≠ (o) ∨ y(o‘) =y0 ) Schreibzugriff (Write-Access) • Nur wenn alle vorherigen Lesezugriffe stattgefunden haben auf – Objekte des gleichen Unternehmens – interessensfreien Objekte • Verhindert einen Informationsfluss zwischen Objekten unterschiedlicher Unternehmen, auch wenn sie der gleichen Konfliktklasse angehören • Ein Subjekt s ∈ S erlangt Schreibzugriff auf ein Objekt o zur Zeit t genau dann, wenn write ∈ Mt(s, o) ∧ ∀ o‘∈ O , read ∈ Nt(s, o‘) ⇒ ( y(o‘) = y(o) ∨ y(o‘)=y0 )
  • 54. Chinese Wall und Service Computing Konflikt- klassen Pers. Daten- sätze Syshigh Ground Truth Registration office Medical treatment Erforderliche Information für Durchsetzung (zentral durch Syshigh) Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
  • 55. Chinese Wall und Service Computing Konflikt- klassen Pers. Daten- sätze Syshigh Ground Truth Registration office Medical treatment Bob David Explicit/friendship Implicitly assumed friendship Erforderliche Information für Durchsetzung (zentral durch Syshigh) Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
  • 56. Chinese Wall und Service Computing Konflikt- klassen Pers. Daten- sätze Syshigh Ground Truth Registration office Medical treatment Bob David Explicit/friendship Implicitly assumed friendship Erforderliche Information für Durchsetzung (zentral durch Syshigh) Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
  • 57. Zugriffskontrolle skaliert nicht für Service Computing • Strikte Ordnung der Zugriffsrechte Rollenwechsel bei Weitergabe über Dritte • Symmetrischer Graph der Zugriffsrechte Fehlerausbreitung • Safety, falls die Graphen zwischen autorisiert und nicht-autorisiert getrennt sind Gemeinsame Nutzung von daten-zentrischem Dienst • Verfügbarkeit von Daten durch Deklassifizierung Intern: Zuverlässiger „Big Brother“ Extern: Fehlerausbreitung Lattice-based Access Control Sandhu 1993 Take-grant Lipton and Snyder 1977 S1: u S2: u S3: v O: oS3: w • Azyklischer Graph der Zugriffsrechte Rollenwechsel bei Weitergabe über Dritte • Safety bei x <= 3 Parameter einer Weitergabe (Anbieter, Konsument, Subjekt, Zeit, Zweck, ...) • Kein irreparabler Widerruf von Rechten Datensparsamkeit Type-safety Sandhu 1992 S1: u S2: u S3: v O: oS3: w
  • 58. Agenda 3. Sicherheitsmodelle 3.1 Epochen der IT-Sicherheit 3.2 Zugriffskontrolle 3.3 Das Safety Problem 3.4 Nutzungskontrolle
  • 59. Nutzungskontrolle (Usage Control) 1. Zugriff auf Daten – Provisions sind Bedingungen, die die Zeit bis zum ersten Zugriff/direkte Erhebung von Daten (Ground Truth) spezifizieren – Referenzmonitor erlaubt Zugriff genau dann wenn die Provisions erfüllt sind 2. Nutzung von Daten – Obligations sind Bedingungen, die die Zeit nach dem Zugriff spezifizieren (“Zukunft”) – Wie können Obligationen durchgesetzt werden? Beispiel: “Dienst X ist für den Zugriff auf die E-Mailadresse autorisiert, falls es diese E-Mailadresse nach der Geschäftstransaktion löscht.” Inquiry Access Provisions Obligations t 1 2 ? RM Objekt Subjekt Park und Sandhu, The UCONABC Usage Control Model, 2004
  • 60. Demo: Usage Control mit FTP Source: Alexander Pretschner @ https://www22.in.tum.de/forschung/distributed-usage-control/ ftp://AlicesFriends.txt Datenanbieter/ -konsument Daten- konsument Daten- anbieter Alice Bob
  • 61. Einhaltung einer Obligation Wann ist eine Obligation verletzt? Eine Obligation ist zum Zeitpunkt tk verletzt, falls das Subjekt sich zu dieser Obligation zur Zeit tj verpflichtet hat, aber sie zu der Zeit tj nicht erfüllt ist, unabhängig von de Zugriffen nach tk. tj tk Verpflichtung zu der Obligation Für jede Entwicklung nach tk kann die Obligation nicht erfüllt werden Obligation ist nicht erfüllt (abhängig von dem Kontrollfluss bis tk) Obligation Zeit Hilty, Basin und Pretschner, On Obligations, 2005
  • 62. Beispiel: Einhaltung einer Obligation Obligation: "Sender S muss die Nachricht N innerhalb von 3 Zeiteinheiten senden.” t0 Sender verpflichtet sich zu der Obligation t0 zu t3 Falls N bisher nicht gesendet wurde, dann kann sie bis t3 gesendet werden, um die Obligation zu erfüllen t4 Obligation kann nicht mehr erfüllt werden; unabhängig von den weiteren Verlauf der Zugriffe è Referenzmonitor kann nicht entscheiden, ob eine zeitlich unbeschränkte Obligation wie “Nachricht N muss irgendwann gesendet werden” verletzt ist t0 t1 t2 t3 t4 Verpflichtung zu der Obligation Letzte Chance, um N zu senden Obligation ist verletzt Pretschner, Hilty und Basin, Distributed Usage Control, 2006
  • 63. Eingeschränkte Obligationen K 1: Eingeschränkt und beobachtbar • Obligationsbedingung muss innerhalb einer bestimmten Zeitdauer erfüllt werden. Referenzmonitor kann die beobachten. • Beispiele – “Muss die Strafe innerhalb von 5 Tagen bezahlen” – “Subjekt s ist für die nächsten 5 Tage nicht für einen Lesezugriff auf lokale Dateien autorisiert.” K 2: Eingeschränkt und nicht beobachtbar • Wie K1, nur ein Referenzmonitor kann die Einhaltung (generell) nicht beobachten • Beispiele – “Empfänger ist nicht erlaubt die Daten innerhalb der nächsten 5 Tage weiterzugeben” – “Empfänger muss die Daten innerhalb von 5 Tagen löschen” Zeit / Verteilung Beobachtbar Nicht beobachtbar Eingeschränkt K 1 K 2 Invariant K 3 K 4 Pretschner, Hilty und Basin, Distributed Usage Control, 2006
  • 64. Invariante Obligationen K 3: Invariant und beobachtbar • Obligationsbedingung muss immer erfüllt werden. Referenzmonitor kann die Einhaltung beobachten. • Beispiele – “Benutzer immer einen verschlüsselten Kanal” – “Aktualisiere die Daten wenigstens an jedem 5. Tag” (bspw. zur Echtzeit-Inventur) K 4: Invariant und nicht beobachtbar • Wie K3, nur ein Referenzmonitor kann die Einhaltung (generell) nicht beobachten • Beispiel – “Daten dürfen nicht weitergegeben werden.” Zeit / Verteilung Beobachtbar Nicht beobachtbar Eingeschränkt K 1 K 2 Invariant K 3 K 4 Pretschner, Hilty und Basin, Distributed Usage Control, 2006
  • 65. d, d*d Datenanbieter/ -konsument Daten- konsument Datenkonsument/- anbieter Daten- anbieter Zugriffskontrolle Provisions Provisions + Obligationen Nutzungskontrolle Durchsetzung ⇒ Open Data für Nutzung persönlicher Daten (Ground Truth) Open Data zu Obligationen Nutzung für Service Computing Wohlgemuth, Takaragi und Echizen, Privacy with Secondary Use of Personal Information, 2016
  • 66. Quellen und weiterführende Literatur • Eggs, H., Müller, G. Sicherheit und Vertrauen: Mehrwert im E-Commerce. Berlin, 2001 • Harrison, M.A., Ruzzo, W.L., Ullman, J.D. Protection in Operating Systems. CACM 19(8), ACM, 1976 • Hilty, M., Basin, D., Pretschner, A. On Obligations. ESORICS 2005, LNCS 3679, Springer, 2005 • Müller, G., Accorsi, R., Höhn, S., Sackmann, S. Sichere Nutzungskontrolle für mehr Transparenz in Finanzmärkten. Informatik-Spektrum 33(1), Springer, 2010 • Park, J., Sandhu, R. The UCONABC Usage Control Model. ACM Transactions on Information and System Security 7(1), ACM, 2004 • Pretschner, A., Hilty, M, Basin, D. Distributed Usage Control. CACM 49(9), ACM, 2006 • Saltzer, J.H., Schroeder, M.D. The Protection of Information in Computer Systems. ACM Symposium on Operating Systems Principles, 1973 • Sandhu, R. Lattice-Based Access Control Models, Computer 29(11), IEEE, 1993 • Schäfer, G. Netzsicherheit. d-punkt Verlag, 2003 • Wohlgemuth, S., Takaragi, K., Echizen, I. Privacy with Secondary Use of Personal Information. MKWI 2016