Policy-Überwachung mit besonderer Betrachtung unvollständiger
Werbung
Seminararbeit Policy-Überwachung mit besonderer Betrachtung unvollständiger Logs Tobias Görgen 27. Januar 2014 Gutachter: Prof. Dr. Jan Jürjens Dr. Sven Wenzel Prof. Dr. Jan Jürjens Lehrstuhl 14 Software Engineering Fakultät Informatik Technische Universität Dortmund Otto-Hahn-Straße 14 44227 Dortmund http://www-jj.cs.uni-dortmund.de/secse Tobias Görgen [email protected] Matrikelnummer: 133522 Studiengang: Master Informatik Seminar Sicherheit und Softwareengineering Thema: Policy-Überwachung mit besonderer Betrachtung unvollständiger Logs Eingereicht: 27. Januar 2014 Betreuer: Thorsten Humberg Prof. Dr. Jan Jürjens Lehrstuhl 14 Software Engineering Fakultät Informatik Technische Universität Dortmund Otto-Hahn-Straße 14 44227 Dortmund i ii iii Ehrenwörtliche Erklärung Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Dortmund, den 27. Januar 2014 Tobias Görgen iv INHALTSVERZEICHNIS v Inhaltsverzeichnis 1 Einleitung 2 Der Reduce-Algorithmus 2.1 Logik des Algorithmus . . . . . . . . . 2.1.1 Definition . . . . . . . . . . . . 2.1.2 Beispiel . . . . . . . . . . . . . 2.2 Teilstrukturen und deren Semantik . . 2.2.1 Definition Teilstruktur . . . . . 2.2.2 Semantik . . . . . . . . . . . . 2.3 Der Algorithmus . . . . . . . . . . . . 2.3.1 Definition des Algorithmus . . . 2.3.2 Anwendung auf ein Beispiel . . 2.3.3 Eigenschaften des Algorithmus . 2.4 Implementierung . . . . . . . . . . . . 2.5 Zwischenfazit . . . . . . . . . . . . . . 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Temporale Logiken als Mittel zur Überwachung von Policys Laufzeit 3.1 Grundlagen: Lineare temporale Logik . . . . . . . . . . . . . . . . 3.2 Ansätze zur Erweiterung der LTL . . . . . . . . . . . . . . . . . . 3.2.1 Metrische temporale Logik M T L . . . . . . . . . . . . . . 3.2.2 Temporale Prädikatenlogik LCV . . . . . . . . . . . . . . . 3.2.3 Lineare temporale Logik ALC . . . . . . . . . . . . . . . . 3.3 Zwischenfazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 . 3 . 3 . 4 . 5 . 5 . 5 . 6 . 7 . 8 . 9 . 10 . 11 zur . . . . . . . . . . . . 13 13 14 14 15 15 15 4 Policy-Spezifizierung sowie -Analyse 17 4.1 Ansatz mit Identifizierung des Verursachers . . . . . . . . . . . . . . 17 4.2 PrivacyLFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3 HIPAA-Formulierung mittels Prolog-Ansatz . . . . . . . . . . . . . . 18 5 Zusammenfassung und Fazit 21 Literaturverzeichnis 23 vi INHALTSVERZEICHNIS KAPITEL 1. EINLEITUNG 1 1 Einleitung In Zeiten, in denen Technologie immer mehr Einfluss auf das Leben der Menschen nimmt und besonders auch immer weiter in Bereiche eindringt, in denen sie nicht beheimatet ist, sondern nur als Hilfsmittel benutzt wird, wächst auch stetig der Wunsch nach Datenschutz und besonders nach einheitlichen Richtlinien (im weiteren Verlauf der Arbeit als Policys bezeichnet). Besonders in Bereichen in denen sehr sensible private Daten vorherrschen und übermittelt werden, muss es klare, die Daten schützende Regelungen geben. Solche Bereiche sind zum Beispiel der Gesundheitssektor oder der Finanzsektor. Patientendaten, wie Informationen über Behandlungen oder die Krankenhistorie einer Person, sind hochgradig persönliche Daten und dürfen nicht einfach weitergegeben werden. Durch das Wachstum der Informationstechnologie ist das Übermitteln von Krankenakten erheblich vereinfacht worden. So ermöglichen es beispielsweise E-Mails innerhalb von Sekunden eine große Menge Daten von Krankenhaus zu Krankenhaus zu schicken. Ob eine solche Transaktion immer notwendig oder gar gestattet ist, ist eine wichtige Frage, die der Datenschutz klären muss. Auf Grund dieser Herausforderung hat beispielsweise die US-Regierung im Jahr 1996 den The Health Insurance Portability and Accountability Act of 1996“([Con96]) ” verabschiedet, welcher umfangreiche Policys für den Umgang mit privaten Daten im Gesundheitssektor festlegte. Für den Finanzsektor folgte im Jahr 1999 der Gramm” Leach–Bliley Act“([Con99]). Aufgrund des Umfangs dieser Policys entstand der Wunsch Verstöße gegen diese automatisiert zu erkennen, sprich es gab Bedarf für eine automatisierte Überwachung der Einhaltung. Diese Ausarbeitung beschäftigt sich mit der Überwachnung von eben solchen Policys. Ein Algorithmus, der speziell auf den HIPAA zugeschnitten ist, ist hierbei der Reduce-Algorithmus aus Policy Auditing over Incomplete Logs: Theory, Im” plementation and Applications“[GJD11]. Nach dieser Einleitung wird er im Details besprochen und es wird erläutert, was die Vorzüge dieses Algorithmus sind. Der Reduce-Algorithmus zielt dabei besonders auf die Überwachung von unvollständigen Logs ab, sprich Log-Daten, in denen gewisse Informationen aus unterschiedlichen Gründen noch nicht vorhanden sind. In der Realität sind solche unvollständigen Logs weit verbreitet, wobei die Gründe für solche Unvollständigkeiten unterschiedlich sein können. Deshalb hat diese Problemstellung eine besondere praktische Relevanz. Der Reduce-Algorithmus geht dabei iterativ vor und hat als Ziel eine Policy immer weiter zu reduzieren, bis eine Verletzung der Policy auftaucht oder die Einhaltung der Policy bestätigt werden kann. Im darauf folgenden Abschnitt wird sich mit anderen Ansätzen aus der wissenschaftlichen Literatur beschäftigt, die auf dem Einsatz von linearen temporalen Logiken beziehungsweise Erweiterungen darauf basieren. Hier werden insbesondere drei An- 2 sätze besprochen, die die weit verbreitete lineare temporale Logik als Basis benutzen und erweitern, um Logs zur Laufzeit auszuwerten, was ein Unterschied zum ReduceAlgorithmus darstellt. Quellen für diese drei Ansätze sind insbesondere Monitoring ” Algorithms for Metric Temporal Logic Specifications“[TR05], Run-Time Checking ” of Dynamic Properties“[Sok+06] und Runtime Verification Using a Temporal Des” cription Logic“[BBL09]. Im nächsten Abschnitt wird sich dann nochmal mit Methoden zur Policy-Spezifizierung auseinander gesetzt. Unter anderem wird ein Algorithmus aus Privacy and ” Utility in Business Processes“[Bar+07] vorgestellt, der neben einer Policyverletzung auch den Verursacher eben jener identifizieren kann. Außerdem erfolgt noch eine kurze Vorstellung der P rivacyLF P 1 , welches die Logik ist, die von den Autoren des Reduce-Algorithmus entwickelt wurde zur Formalisierung von Policys im amerikanischen Gesundheitssystem. Diese wurde in Experiences in the Logical Specification ” of the HIPAA and GLBA Privacy Laws“[DeY+10] entwickelt und die Anwendung auf eben jene Policys illustriert. Als alternativer Ansatz zur Formalisierung einer Policy wird der Ansatz aus A Formalization of HIPAA for a Medical Messaging ” System“[LMS07] dargestellt, der als Basis Formeln aus der logischen Programmiersprache Prolog benutzt. Zum Schluß wird ein Fazit gezogen und die vorgestellten Techniken noch einmal miteinander in Beziehung gesetzt. 1 Privacy Fixed Point Logic KAPITEL 2. DER REDUCE-ALGORITHMUS 2 3 Der Reduce-Algorithmus In diesem Kapitel wird der Reduce-Algorithmus aus der Primärquelle [GJD11] besprochen. Der Reduce-Algorithmus soll dabei besonders zwei praxisrelevante Probleme lösen, welche auch im Zusammenhang mit den HIPAA und GLBA-Policys auftauchen. Diese sind zum einen unvollständige Logs und zum anderen Policys mit unendlichen Domänen. Der Algorithmus ist durch Ideen der logischen Programmierung inspiriert, in welchen quantifizierte Formeln durch gewisse Bedingungen beschränkt werden. Im ersten Teil wird die Idee des Algorithmus wiedergegeben und die Logik vorgestellt, auf welcher der Algorithmus arbeitet. Das Ganze wird anhand eines übergreifenden Beispiels veranschaulicht. Daraufhin wird sich sowohl mit der räumlichen und zeitlichen Komplexität auseinander gesetzt, als auch mit Faktoren wie Terminierung, Korrektheit und Minimalität. Zusätzlich findet eine Betrachtung der tatsächlichen Implementierung des Algorithmus statt. Hierbei wird auf die unterschiedlichen Komponenten wert gelegt, die die Implementierung bilden. 2.1 Logik des Algorithmus In diesem Abschnitt wird die Logik des Algorithmus dargestellt. Zuerst wird diese Logik definiert und anschließend wird ein Beispiel zum besseren Verständnis gegeben. (vgl [GJD11, S.2]) 2.1.1 Definition Der Reduce-Algorithmus ist ein iterativer Algorithmus. Das bedeutet, er verarbeitet eine Policy zu einer neuen Policy und reduziert diese dabei so weit wie die vorhandenen Informationen es zulassen. Hierbei wird erwartet, dass die Policy in Form einer Prädikatenlogik erste Stufe dargestellt werden kann, die aus folgenden Elementen besteht: Atome P := p(t1 , . . . , tn ) Formeln ϕ := P |>|⊥|ϕ1 ∨ ϕ2 |ϕ1 ∧ ϕ2 |∀~x.(c ⊃ ϕ)|∃~x.(c ∧ ϕ) Restriktionen c := P |>|⊥|c1 ∨ c2 |c1 ∧ c2 |∃x.c Prädikate p sind hierbei Relationen zwischen Termen, während Terme wiederum Variablen und Konstanten darstellen oder zu uninterpretierten Funktionssymbolen hinzugezogen werden. Ein Prädikat wird einer Liste von Termen t1 , . . . , tn zugeordnet. Die bekannten logischen Operatoren haben hier ihre gewöhnliche Bedeutung. Allerdings werden die Quantoren durch den Einsatz von Restriktionen auf eine ge- 4 2.1. LOGIK DES ALGORITHMUS wisse Form beschränkt. ∀~x.(c ⊃ ϕ)1 wird wahr definiert genau dann, wenn alle Instanzen von ~x, die die Restriktion c befriedigen, auch ϕ befriedigen. Genau so ist ∃~x.(c ∧ ϕ) wahr, genau dann wenn eine Belegung ~x existiert, die sowohl c als auch ϕ wahr macht. Um die Terminierung des Algorithmus zu gewährleisten, wird zusätzlich benötigt, dass nur eine endliche Anzahl von Substituten für quantifzierte Variablen die Restriktionen wahr machen. In der Logik wird aus technischen Gründen auf Negationen verzichtet. Im Gegenzug wird angenommen, dass es zu jedem Prädikat p ein duales Prädikat p, gibt mit: p(t1 , . . . , tn ) = > ⇔ p(t1 , . . . , tn ) = ⊥. Daraus wird ein duales ϕ definiert, was sich analog zu der klassischen Negation verhält. So gilt beispielsweise das De Morgansche Gesetz oder die Umkehr von Quantoren bei Einsatz der dualen Formel. Um eine zeitliche Komponente einzufügen wird aus der Domäne von ganzen Zahlen durch τ ein Zeitpunkt in einem Prädikat dargestellt, an dem ein mögliches Ereignis stattgefunden haben kann. Sowohl LTL2 als auch die Erweiterung TPTL3 können in diese Logik überführt werden, damit wird sich aber später weiter beschäftigt. (vgl [GJD11, S.2]) 2.1.2 Beispiel Da der Algorithmus insbesondere für Policys im amerikanischen Gesundheitssystem entwickelt wurde findet das Beispiel auch im Universum des Gesundheitssystem statt. Die zu erstellende Policy sieht in Sprachform ausgedrückt wie folgt aus. Eine Entität darf den Gesundheitsbericht (privat) nur an eine andere Entität schicken, wenn die empfangende Entität der Arzt des Individuums und der Verwendungszweck die Behandlung ist oder wenn das Individuum der Übertragung vorher zugestimmt hat. Diese Aussage umgewandelt in die Logik sieht wie folgt aus: ϕpol = ∀p1 , p2 , m, u, q, t, τ.(sende(p1 , p2 , m, τ ) ∧ zweck(m, u) ∧ markiert(m, q, t)) ⊃ attr in(t, privat) ∨ (arztV on(p2 , q, τ ) ∧ zweck in(u, Behandlung)) ∨ ∃τ 0 .(τ 0 < τ ∧ hatZugestimmt(q, sendeHandlung(p1 , p2 , (q, t)), τ 0 )) Die Formel ist auf den ersten Blick sicherlich nicht sehr einsichtig. Deshalb wird sie nun im Details betrachtet: Am Anfang der Formel befindet sich der Allquantor. Hier stehen p1 und p2 für die schickende und die empfangende Entität. Die Variable m steht für eine Nachricht. u stellt den Sendezweck dar und q ist das Indivduum dessen Informationen verschickt werden. t ist ein Attribut mit dem eine Nachricht versehen sein kann. Darauf folgt das Prädikat sende(p1 , p2 , m, τ ), welches wahr ist, wenn im Log ein Eintrag steht, der besagt, dass die Nachricht m von Entität p1 zu p2 zum Zeitpunkt τ geschickt wurde. Das Prädikat zweck(m, u) wird wahr, wenn die Nachricht m mit dem Zweck u versehen ist. Das Prädikat markiert(m, q, t) heißt, dass die Nachricht m mit dem Attribut t von Individuum q markiert ist. Die beiden Prädikate attr in und zweck in sind spezielle Prädikate, die davon ausgehen, dass die Attribute und Zwecke eine Hierarchie haben. So ist zum Beispiel das Attribut Medikation im Attri1 Mit ⊃ wird in [GJD11] die Implikation bezeichnet, statt dem oft benutzten Pfeil → Lineare temporale Logik 3 Gezeitete lineare temporale Logik 2 KAPITEL 2. DER REDUCE-ALGORITHMUS 5 but Krankengeschichte enthalten (also ist attr in(M edikation, Krankengeschichte) wahr). Für den Zweck wäre ein Beispiel: zweck in(Operation, Behandlung). Das Prädikat arztV on(p2 , q, τ ) ist wahr, wenn p2 Arzt von q zum Zeitpunkt τ ist. Zu guter Letzt bedeutet hatZugestimmt(q, sendeHandlung(p1 , p2 , (q, t)), τ 0 ), dass q der Sendehandlung zum Zeitpunkt τ 0 zugestimmt hat. In Worten formuliert kann man die Policy also zusammenfassen: Wenn p1 an p2 Nachricht m zum Zeitpunkt τ sendet, dann ist das Attribut t nicht privat oder p2 ist zu dem Zeitunkt Arzt von q oder q hat dem Senden vorher zugestimmt. Die Werte von Prädikaten können auf unterschiedliche Art und Weise ermittelt werden. Möglich sind zum Beispiel Nutzereingaben oder Werte in Datenbanken, die sagen, ob ein Prädikat mit den passenden Eingaben wahr ist. Genauer betrachtet wird dies im Abschnitt über die Implementierung des Algorithmus. (vgl [GJD11, S.3]) 2.2 Teilstrukturen und deren Semantik Nachdem im vorherigen Abschnitt die Logik präsentiert wurde, auf welcher der Reduce-Algorithmus arbeitet, wird sich in diesem Kapitel mit Teilstrukturen auseinandergestzt. Teilstrukturen sind hierbei die Informationen, die der Algorithmus benötigt, um eine Policy zu reduzieren. 2.2.1 Definition Teilstruktur Sei D eine (unendliche) Domäne von Termen, dann heißt L Teilstruktur, wenn es eine Abbildung von den Atomen über D auf die Menge {tt, f f, uu} ist. Das Atom P wird als wahr, falsch oder unbekannt in L bezeichnet, wenn L(P ) tt, f f oder uu ist. Durch die mögliche Abbildung auf uu wird die Unvollständigkeit von Logs zum Zeitpunkt der Überprüfung dargestellt. Teilstrukturen decken damit drei Arten von Unvollständigkeit ab (vgl [GJD11, S.3]): • zukünftige Unvollständigkeit - zukünftige Ereignissen können nicht verfügbar sein für einen Algorithmus zur Überprüfung des Logs • Unvollständigkeit durch räumliche Trennung - Daten, die das Überwachungssystem benötigt, können an unterschiedlichen physikalischen Orten liegen • subjektive Unvollständigkeit - manche Daten müssen durch Benutzereingabe abgefragt werden. Der Nutzer ist aber nicht allwissend. Hierdurch kann es zu Unvollständigkeiten kommen. 2.2.2 Semantik Im folgenden wird die Semantik auf Teilstrukturen formalisiert. Diese geschieht mittels der Relation L ϕ, was bedeutet, dass ϕ in der Struktur L wahr ist. Für diese Relation gilt: • L P gdw. L(P ) = tt 6 2.3. DER ALGORITHMUS • L> • L ϕ ∨ ψ gdw. L ϕ oder L ψ • L ϕ ∧ ψ gdw. L ϕ und L ψ • L ∀~x.(c ⊃ ϕ) gdw. für alle ~t ∈ D gilt entweder L c[~t/~x] oder L ϕ[~t/~x] • L ∃~x.(c ∧ ϕ) gdw. ein ~t ∈ D existiert mit: L c[~t/~x] und L ϕ[~t/~x] Für duale Atome gilt: L(P ) = L(P ), mit tt = f f , f f = tt und uu = uu. Eine Formel ϕ ist falsch in L, wenn L ϕ. Diese Semantik efüllt diese zwei Eigenschaften: 1. Konsistenz: Eine Formel ϕ kann nicht gleichzeitig wahr und falsch in L sein 2. Unvollständigkeit: Eine Formel ϕ kann weder wahr noch falsch sein in L System-Logs erweitern sich im Laufe der Zeit immer weiter. Daraus folgt, dass sich die Informationen, die ein Log beinhaltet immer vergrößern. Daraus ergibt sich eine Halbordnung auf den Teilstrukturen. L1 ≤ L2 (L2 erweitert L1 ) bedeutet, dass L2 mehr Informationen enthält als L1 , aber alle Informationen bis auf Ungewissheit in L1 auch in L2 gelten. Formal gilt: L1 ≤ L2 , wenn für alle Atome P , die keine freien Variablen haben, gilt: L1 (P ) ∈ {tt, f f } =⇒ L2 (P ) = L1 (P ) Es ist leicht zu sehen, dass die Erweiterungsrelation monton ist: Aus L1 ≤ L2 und L1 (P ) ϕ folgt, dass L2 (P ) ϕ gilt. (vgl [GJD11, S.4]) 2.3 Der Algorithmus Der grundlegende Gedanke des Algorithmus ist es durch Iteration eine Policy immer weiter zu reduzieren bis als Ergebnis eines Reduce-Aufrufes eine Verletzung (⊥) oder keine Verletzung (>) festgestellt werden kann. Eine einzelne Iteration wird hierbei bezeichnet als reduce(L, ϕ) = ψ. Das Ergebnis ψ eines solchen Aufrufs ist immer eine Restpolicy, die aus den Teilen von ϕ besteht, welche durch den Reduce-Algorithmus noch nicht verifiziert werden konnten. Durch Erweiterung von L auf L0 kann man mit einer erneuten Iteration eine neue Policy generieren, die wieder kleiner ist. Dabei soll der Algorithmus drei Eigenschaften erfüllen: • Terminierung: Jede Iteration terminiert. • Korrektheit: Sei reduce(L, ϕ) = ψ, dann gilt: ∀L0 ≥ L : L0 ϕ ⇔ L0 ψ • Minimalität: Sei reduce(L, ϕ) = ψ, dann gibt es ein Atom P nur in ψ, wenn es auch in ϕ ist und L(P ) = uu Besonders problematisch an der Realisierung des Algorithmus ist der Umgang mit den Quantoren über unendlichen Domänen. Ein naiver Algorithmus würde bei einem Quantor über eine unendliche Domäne oft nicht terminieren. Da es unendliche Domänen gibt (z.B. bei einer Quantifizierung über die unendliche Domäne aller Nachrichten), besteht die Notwendigkeit der Restriktionen, die dafür sorgen, dass KAPITEL 2. DER REDUCE-ALGORITHMUS 7 die Anzahl der relevanten Instanzen x, die als Kandidaten für die jeweilige Formel in Frage kommen, endlich ist. Durch den Einsatz von Techniken der Mode Analyse aus der logischen Programmierung, ist es möglich die Restriktionen auf eine endliche Anzahl befriedigender Instanzen zu begrenzen und diese zu berechnen. Um die Mode Analyse einzusetzen, muss bei Prädikaten angegeben werden, welche sich endlich berechnen lassen und welche nicht. So wäre beim Beispiel bei zweck(m, u) die Nachricht m über eine unendliche Domäne zu bekommen, während der Zweck u aus der Nachricht berechenbar ist. Benötigte Eingaben werden hier mit einem + gekennzeichnet, während berechenbare Ausgaben mit einem - gekennzeichnet werden. Für Zweck wäre also eine passende Kennzeichnung zweck(+, −). Durch Anwendung eines Mode Checks bei angegebenen Mode Informationen kann innerhalb von linearer Zeit garantiert werden, dass es eine endliche Anzahl freier Variablen gibt, die eine Restriktion befriedigen. Für die tatsächliche Berechnung der befriedigenden Belegungen einer Restriktion c wird die Funktion sat(L, c) definiert, die alle Substitute σ berechnet, so dass L cσ, mit der Annahme, dass eine Funktion sat(L, P ) alle Substitute σ für freie Variablen in P berechnet, so dass L P σ. (vgl [GJD11, S.4]) 2.3.1 Definition des Algorithmus In Abbildung 2.1 ist die Definition des Reduce-Algorithmus dargestellt. Abbildung 2.1: Definition des Reduce-Algorithmus aus [GJD11, S.5] 8 2.3. DER ALGORITHMUS Wie bereits erwähnt ist das Vorgehen basiert auf einer iterativen Reduktion der Policys. Geht man von einer Startpolicy ϕ0 und einer Sequenz L1 ≤ L2 ≤ . . . Ln , die man iterativ auf die entstehenden Policys anwendet so ergeben sich ϕ1 , ϕ2 , . . . , ϕn , L1 L2 so dass reduce(Li , ϕi−1 ) = ϕi . Dieser Prozess lässt sich schreiben als ϕ0 −→ ϕ1 −→ Ln ϕn . . . . −→ Bei Atomen entspricht das Verhalten eines Aufrufs des Reduce-Algorithmus den Erwartungen. So ergibt reduce(L, P ) >, ⊥ oder P , wenn L(P ) tt,f f oder uu entspricht. Auch die Verknüpfungen ∨ und ∧, sowie > und ⊥ werden wie gewöhnlich berechnet. Die interessanteren Fälle sind eindeutig, die letzten beiden, wobei diese analog zueinander verlaufen. c Um reduce(∀~x.(c ⊃ ϕ)) zu berechnen, wird zuerst mittels Aufruf von sat(L, c), die endliche Menge aller befriedigenden Instanzen ~x der Restriktion c berechnet. Für jede dieser Instanzen t~1 , . . . , t~n wird jetzt ϕ[~ti /~x] durch einen rekursiven Aufruf des Reduce-Algorithmus zu ψi reduziert. Da alle Instanzen von ϕ halten müssen, ist die Ausgabe folglich ψ1 ∧ · · · ∧ ψ1 ∧ ψ 0 , wobei ψ 0 der Tatsache geschuldet ist, dass andere Instanzen von ~x als t~1 , . . . , t~n nicht betrachtet wurden. Solche Instanzen können in Erweiterungen von L enthalten sein. Für ∃~x.(c ∧ ϕ) verhält sich der Algorithmus analog. c Wie bereits erwähnt berechnet die Funktion sat(L, c) die Menge der befriedigenden c Substitute für die Restriktion c. Dabei ist sat wie folgt definiert: c sat(L, p(t1 , . . . , tn )) = sat(L, p(t1 , . . . , tn )) c sat(L, >) = {•} c sat(L, ⊥) = {} S c c σ + sat(L, c2 σ) sat(L, c1 ∧ c2 ) = c σ∈sat(L,c 1) c c c sat(L, c1 ∨ c2 ) = sat(L, c1 ) ∪ sat(L, c2 ) c c sat(L, ∃x.c) = sat(L, c)\{x} (x frisch) c c Da > immer wahr sein muss, enthält sat(L, >) nur die leere Substitution •. sat(L, ⊥) ist die leere Menge, da es keine Substitution geben kann, die ⊥ befriedigt. Für c1 ∧ c2 nimmt man die befriedigen Instanzen von c1 und verbindet sie mit den befriedigenden Instanzen von c2 σ. Bei c1 ∨ c2 handelt es sich um die Vereinigung der beiden befriedigenden Mengen. Die befriedigenden Instanzen von ∃x.c ergeben sich durch Herausnehmen der Substituten von x. (vgl [GJD11, S.5]) 2.3.2 Anwendung auf ein Beispiel Im Folgenden werden Teilstrukturen mittels des Reduce-Algorithmus auf das Beispiel aus Abschnitt 2.1.2 angewendet. Zur besseren Übersicht sei ~x fest definiert als Sequenz p1 , p2 , m, u, q, t, τ und c(~x) und ϕ(~x) sind durch Pattern Matching die Formeln, die ϕ = ∀~x.(c(~x) ⊃ ϕ(~x)) befriedigen. Desweiteren seien noch ϕ2 und ϕ3 durch Pattern Matching definiert als ϕ(~x) = attr in(t, privat) ∨ ϕ2 (p2 , q, τ, u) ∨ ϕ3 (τ, q, p1 , p2 , t). Sei L eine Teilstruktur, die die folgenden Informationen enthält: 1. Alice sendet an Bob die Nachricht M zum Zeitpunkt 4. Die Nachricht ist markiert, dass sie Informationen über Charlie’s Adresse enthält mit dem Zweck der Bezahlung. KAPITEL 2. DER REDUCE-ALGORITHMUS 9 2. Charlie hat diese Übertragung zum Zeitpunkt 2 gestattet. Aus diesen Informationen folgt: c sat(L, c(~x)) = {σ}, mit σ = [σ → (Alice, Bob, M, Bezahlung, Charlie, Adresse, 4]. Jetzt wird die Definition des Reduce-Algorithmus auf ϕpol angewendet. Das ergibt reduce(L, ϕpol ) = ψ1 ∧ ϕ0pol , mit ψ1 = reduce(L, ϕ(~xσ)) und ϕ0pol = ∀~x.(c(~x) ∧ ~x ∈ / {σ}) ⊃ ϕ(~x). Da ϕ(~x) eine Disjunktion von drei Formeln ist, wo die dritte ϕ3 ist, kann durch Anwendung von 2. gezeigt werden, dass reduce(L, ϕ3 (τ, q, p1 , p2 , t)) als Ergebnis > hat. Das bedeutet, dass es bis hierhin kein Verletzung der Policy gab und wir durch Anwendung des Algorithmus die Restpolicy ϕ0pol erhalten haben. Nun wird eine Erweiterung der Teilstruktur L betrachtet, so dass wir mit neuen Informationen L0 ≥ L erhalten und diese neue Teilstruktur auf die Restpolicy anwenden können. Es kommen die drei folgenden neuen Informationen hinzu. 3. Alice sendet an Bob die Nachricht M’ zum Zeitpunkt 5. Die Nachricht ist markiert, dass sie Informationen über Dan’s Laborbericht enthält mit dem Zweck der Operation. 4. L0 (hatZugestimmt(Dan, a, τ 0 )) = f f für jede Handlung a und jede beliebige Zeit τ 0 , also ist auch insbesondere der Nachricht von Alice nicht zugestimmt worden 5. L0 (ArztV on(Bob, Dan, 5)) = f f , also ist Bob zum Zeitpunkt 5 nicht der Arzt von Dan Daraus folgt: ϕ0pol = ∀~x.(c(~x) ∧ ~x ∈ / {σ}) ⊃ ϕ(~x) war die in der ersten Iteration 0 c 0 , c0 (~x)) = {σ 0 } und ermittelte Restpolicy. Sei nun c (~x) = c(~x) ∧ ~x ∈ / {σ}, mit sat(L σ 0 = [~x → (Alice, Bob, M’, Operation, Dan, Laborbericht,5)]. Durch Anwenden des Reduce-Algorithmus berechnet sich folgendes: reduce(L0 , ϕ0pol ) = ψ2 ∧ ϕ00pol , mit ψ2 = reduce(L0 ϕ(~x)σ 0 ), während ϕ00pol für andere Nachrichten als die beiden genannten gebraucht wird. Durch Einsatz der Informationen 4 und 5 ergibt sich, dass ψ2 = attr in(Laborbericht, privat) ist. Daraus folgt, dass es einen Policyverstoß gab, wenn der Laborbericht als privat eingestuft wurde. Ansonsten war das Senden im Rahmen des Erlaubten. (vgl [GJD11, S.5-6]) 2.3.3 Eigenschaften des Algorithmus Bis hierhin wurde gezeigt, wie der Algorithmus arbeitet und durch ein Beispiel wurde illustriert, wie eine Verfizierung einer Policy mit einer Teilstruktur durch den ReduceAlgorithmus funktioniert. Dabei wurde nur dargestellt, dass der Reduce-Algorithmus in der Lage ist eine Policyverletzung festzustellen, aber nicht den Grund für die Verletzung zu nennen. Dazu ist der Reduce-Algorithmus aber ebenfalls in der Lage. Hierzu muss nicht der Algorithmus angepasst werden, sondern lediglich die Policy muss erweitert werden. Dies kann durch ein neues Prädikat verletzt(~x) realisiert werden, welches für alle ~x unbekannt ist. Eine Policy der Form ϕpol = ∀~x.(c ⊃ ϕ), wird also so erweitert, dass ϕ0pol = ∀~x.(c ⊃ (verletzt(~x) ∨ ϕ)) erhalten wird. Da für diese Policy eine Verletzung entsteht, wenn es eine Variablenbelegung gibt, so 10 2.4. IMPLEMENTIERUNG dass die Restriktion falsch ist, aber die Formel wahr, ergibt sich im Falle einer Verletzung, dass der Reduce-Algorithmus eine Restpolicy in der Form verletzt(~a1 ) ∧ · · · ∧ verletzt(~an ) zurückgibt, so dass alle ~a1 , . . . , ~an die Belegungen sind, die die Policy verletzen. Eine solche Policyerweiterung ist für jede Formel der Logik möglich. (vgl [GJD11, S.6]) In [GJD11] werden zudem noch weitere Eigenschaften des Reduce-Algorithmus präsentiert. Folgende Eigenschaften werden gezeigt: • Partielle Korrektheit und Minimalität (s.o.) • Vollständigkeit: Wenn ϕ den Mode Check besteht, dann existiert auch ein ψ mit: reduce(L, ϕ) = ψ, welches den Mode Check besteht. • Komplexität: reduce(L, ϕ) liegt in den Komplexitätsklassen T IM E(|L|O(|ϕ|) ) und P SP ACE(|ϕ|). 2.4 Implementierung Die Implementierung des Reduce-Algorithmus orientiert sich stark an der mathematischen Definition. Das Programm ist in Standard ML4 geschrieben. Das Programm besteht aus fünf Komponenten, die die Struktur L darstellen und insbesondere eine Auswertung von sat(L, P ) und L(P ) ermöglichen. Als erstes muss jedes Prädikat nach Art der Auswertung kategorisiert werden. Dies wird als Kategorie bezeichnet. In der Implementierung stehen drei Kategorien zur Auswahl: • DB: Das Prädikat ergibt sich aus einem Eintrag in einer Tabelle einer relationalen Datenbank. • EVAL: Das Prädikat ist durch eine berechenbare Operation verifizierbar. (z.B. eine mathematische Berechnung) • SUBJ: Um das Prädikat zu verifzieren muss eine menschliche Eingabe erfolgen. Die zweite Komponente ist eine lookup-Funktion, welche Anfragen in die Datenbank stellen kann um die Prädikate auszuwerten. Aus dieser lookup-Funktion, lässt sich eine sat db(P ) definierten, die alle befriedigenden Belegungen von einem Atom in der Datenbank findet. Drittens muss es eine Funktion eval(P ) geben, die Prädikate der Kategorie EVAL auswerten kann. Als viertes bedarf es einer Funktion isF inal(P ), die angibt, ob durch zusätzliche Eingaben sich die Auswertung des Prädikats noch verändern kann. Zum Beispiel wenn neue Informationen in die Datenbank hinzugefügt werden. Als letztes sind zwei Tabellen (subjWahr und subjFalsch) nötig, die die Prädikate der Kategorie SUBJ beinhalten, die wahr oder falsch sind. Diese Tabellen können zum Beispiel durch eine Front-End von einem menschlichen Benutzer aufgefüllt werden. 4 Meta Language KAPITEL 2. DER REDUCE-ALGORITHMUS Hieraus ergeben sich für die Auswertung sat db(P ) eval(P ) sat(L, P ) = undef iniert 11 von sat folgendes: wenn P in Kategorie DB ist wenn P in Kategorie EVAL ist wenn P in Kategorie SUBJ ist Durch die Definition von sat ist es jetzt auch möglich L(P ) zu definieren: tt ff L(P ) = uu wenn sat(L, P ) = {•} oder P ∈ subjW ahr wenn sat(L, P ) = {} und isF inal(P ) = wahr oder P ∈ subjF alsch andernfalls Dabei ist die Evaluierung von P wahr, wenn es eine befriedigende Belegung gibt oder es in subjWahr ist. Gibt es keine befriedigende Belegung und das Prädikat kann auch nicht mehr wahr werden oder es ist in subjFalsch, dann ist die Evaluierung falsch. Für alle anderen Fälle bleibt das P unbekannt. (vgl [GJD11, S.7]) Zur Optimierung der Implementierung werden in [GJD11, S.7ff] noch einige mögliche Verfahren angesprochen, auf die hier aber nicht weiter eingegangen wird. 2.5 Zwischenfazit Der Reduce-Algorithmus ist ein leistungsstarker Algorithmus zur Überwachung der Einhaltung von Policys mittels Logs. Die Logs können durch die Modellierung der Logik, auf der der Algorithmus arbeitet unvollständig sein und trotzdem evaluiert werden. So schafft der Reduce-Algorithmus, dass die Policys iterativ verkleinert werden. Durch einfache Änderungen an einer Policy ist es zudem möglich nicht nur eine Policy-Verletzung zu erkennen, sondern auch die Ursache für diese zu lokalisieren. Eine große Schwierigkeit, die der Reduce-Algorithmus durch den Einsatz von Restriktionen überwindet, ist die Existenz unendlicher Domänen. Durch Mode Analyse kann der Algorithmus trotzdem garantieren, dass eine Terminierung stattfindet. Andere Logiken lassen sich in die Logik des Reduce-Algorithmus übertragen. In den folgenden Kapiteln wird sich mit weiteren alternativen Ansätzen zum Thema Policy-Überwachung auseinandergesetzt. So ist der Reduce-Algorithmus nicht dafür ausgelegt Policys und Logs während der Laufzeit eines Programms auf Einhaltung zu überprüfen, da der Reduce-Algorithmus von zwei unterschiedlichen Datensätzen für das Log und die Policys ausgeht. Für solche Fälle bedarf es anderer Ansätze, die im nächsten Kapitel skizziert werden. Auch die PrivacyLFP, die Logik auf der die Reduce-Logik basiert, wird zum Schluß genauer vorgestellt. 12 2.5. ZWISCHENFAZIT KAPITEL 3. TEMPORALE LOGIKEN ALS MITTEL ZUR ÜBERWACHUNG VON POLICYS ZUR LAUFZEIT13 3 Temporale Logiken als Mittel zur Überwachung von Policys zur Laufzeit In diesem Kapitel soll sich mit temporalen Logiken auseinandergesetzt werden, die häufig zur Überwachung von Policys zur Laufzeit eingesetzt werden und von denen es in der Literatur viele unterschiedliche Variationen beziehungsweise Erweiterungen gibt. So benutzt zum Beispiel [TR05] die MTL1 , welches eine Erweiterung der LTL ist, in der zusätzlich Zeitintervalle festgelegt werden können. Weitere Beispiele für Beschreibungen von Erweiterungen der temporalen Logiken sind in [Sok+06] und [BBL09] zu finden. In [Sok+06] handelt es sich um die temporale Prädikatenlogik LCV , welche sich besonders mit den Aspekten Ereignisattribute und dynamischer Indexierung von Eigenschaften beschäftigt, während [BBL09] die ALC-LTL vorstellt, welche auf Axiome der Beschreibungslogik ALC zurückgreift und auch auf unvollständig beschriebenen Zuständen arbeiten kann. Der im vorherigen Kapitel betrachtete Reduce-Algorithmus unterscheidet sich von solchen Ansätzen insbesondere dadurch, dass der Reduce-Algorithmus davon ausgeht, dass System-Logs unabhängig von der Ausführung eines Programms ausgelesen werden. Die hier vorgestellten Ansätze sollen eine Auswertung von Logs zur Laufzeit gewährleisten können. Zu Beginn des Kapitels findet eine kurze Beschreibung der linearen temporalen Logik statt. Hierbei sollen vor allem die Grundlagen dieser Logik ins Gedächtnis gerufen werden. Im zweiten Abschnitt des Kapitels folgt dann eine Beschreibung der drei LTL-Erweiterungen M T L, LCV und ALC in genau dieser Reihenfolge. Ziel dieser Abschnitte ist es ein grundlegendes Verständnis für die unterschiedlichen Ansätze der Erweiterungen zu vermitteln und die Breite der möglichen Ansätze in der Wissenschaft aufzuzeigen. 3.1 Grundlagen: Lineare temporale Logik Die lineare temporale Logik ist eine Logik zu Modellierung von Entwicklungen in der Zukunft. So gibt es in ihr Operatoren, mit denen Aussagen über die zukünftige Entwicklung von Pfaden getroffen werden können. Eine passende Definition findet sich in [Roz10]. Neben den üblichen Operatoren, die es in den anderen Logiken gibt (∧, ∨, ¬, . . . ) stehen in der LTL noch die folgenden Operatoren zur Verfügung: • X steht für den Nachfolger • G (alternativ auch ) steht für eine globale Aussage 1 Metric Temporal Logik 14 3.2. ANSÄTZE ZUR ERWEITERUNG DER LTL • F (alternativ auch ) steht dafür, dass eine Formel irgendwann gelten soll (finally) • U steht dafür, dass eine Formel bis irgendwann gelten soll (until) • R steht dafür, dass eine Formel irgendwann aufgelöst wird (release). X und G sind dabei unäre Operatoren, während F, U und R binäre Operationen sind. Also sind Xϕ und ϕU ψ syntaktisch korrekte Formeln, wenn ϕ und ψ auch syntaktisch korrekt sind. Eine LTL-Formel wird dabei auf einen Pfad angewendet, der eine Sequenz von Aussagen ist. Die Formel ist genau dann erfüllt, wenn sie auf der ersten Position des Pfades erfüllt ist. Aufgrund der Eigenschaft, dass die LTL immer Sequenzen von Aussagen beziehungsweise Zuständen ist, lässt sich schon erkennen, dass sie sich dafür eignet, um Programmschritte zu überprüfen. Ein Programmschritt entspricht in diesem Fall einem Zustand der LTL-Formel. LTL-Formeln stellen dann Bedingungen an den Ablauf eines Programmes dar. Diese zu überprüfen ist das Ziel der im folgenden vorgestellten Ansätze. 3.2 Ansätze zur Erweiterung der LTL In diesem Abschnitt werden kurz mehrere Ansätze beschrieben, die unterschiedliche Erweiterungen von LTL darstellen zur Überwachung von Logs zur Laufzeit eines Programms. Dabei wird nicht weiter auf die mathematischen Details eingegangen, sondern es soll lediglich ein grober Überblick über die Ansätze in der Forschung gewährt werden. 3.2.1 Metrische temporale Logik M T L In [TR05] wird mittels der M T L ein Verfahren dargelegt, zur Überwachung eines Programms zur Laufzeit. Dabei wird davon ausgegangen, dass keine Speicherung der Ablaufverfolgung des Programms stattfindet, während dies in anderen Ansätzen passiert. Die M T L ist hierbei eine Erweiterung der klassischen linearen temporalen Logik (LTL), die auf diskrete Zeiteigenschaften verweisen kann. So ist es möglich Zustände der Vergangenheit oder der Zukunft zu modellieren. Als Beispiel sei hier die Formel φU[3,7] ψ zu betrachten. Ihre Bedeutung soll sein, dass ψ vom aktuellen Zeitpunkt aus zwischen 3 und 7 Zeiteinheiten lang noch wahr sein soll und ab dann soll ψ wahr sein. Das angegebene Intervall kann hierbei zwischen 0 und ∞ liegen. Hieraus ergibt sich, dass die LT L ein Spezialfall der M T L ist, in der alle Intervalle [0, ∞) sind. Zusätzlich zu Intervallen ist es noch möglich Kongruenzen anzugeben. Das bedeutet, man kann das periodische Wiederkehren von Aussagen modellieren. Der in [TR05] vorgestellte Algorithmus hat dabei eine räumliche Komplexität von O(m2m ) und eine zeitliche Komplexität von O(m3 23m ), wobei m der Summe aus den Formeln |φ| und die Anzahl aller numerischen Konstanten in φ ist, wobei diese Schranken für manche Spezialfälle noch verbessert werden können. M T L wird hier als ausdrucksstarke und mächtige Logik für Überwachungsanforderungen bezeichnet und die Autoren sind der Meinung, dass der Algorithmus auch für praktische Zwecke einen Nutzen haben kann. Since MTL is an expressive and powerful logic for ” KAPITEL 3. TEMPORALE LOGIKEN ALS MITTEL ZUR ÜBERWACHUNG VON POLICYS ZUR LAUFZEIT15 monitoring requirements, the presented novel and close to optimal algorithms can be used in practical runtime verifcation and testing tools, such as JPaX2 .“([TR05, S.15]) 3.2.2 Temporale Prädikatenlogik LCV In diesem Abschnitt erfolgt eine kurze Vorstellung der in [Sok+06] entwickelten temporalen Prädikatenlogik LCV . Hierbei sei erwähnt, dass LCV einer Erweiterung von LCp ist, die von teilweise den gleichen Autoren in [Kim+04] entwickelt wurde. LCV erweitert die ursprüngliche Logik um zwei Eigenschaften: • Ereignisattribute: Diese Attribute sind zusätzliche Informationen, die ein Ereignis im Log mit sich bringt. So sind möglicherweise die Werte von einem Systemaufruf von größerer Bedeutung. • Dynamische Indexierung von Eigenschaften: Hierbeit wird unterschieden zwischen statischen Objekten, die sich nie oder nur selten ändern und beweglichen Objekten. Bei statischen Objekten steht immer fest, welche Eigenschaften überprüft werden müssen, während bei beweglichen Objekten dynamisch von Fall zu Fall unterschiedliche Sachen abgefragt werden müssen. Ziel der Prädikatenlogik LCV ist es dynamische Eigenschaften von Systemen zu spezifizieren. Praktische Anwendung soll die LCV in Java-MaC3 finden, welche eine Architektur zur Sicherstellung einer korrekten Ausführung von Java-Programmen ist. 3.2.3 Lineare temporale Logik ALC Zum Schluss wird in diesem Kapitel ein Ansatz von [BBL09] vorgestellt, der die LT LErweiterung LT L−ALC aus [BGL08] für einen Algorithmus benutzt. Auch hier wird die LTL erweitert um dynamische Eigenschaften eines Systems zu beschreiben. Diese geschieht mittels der Beschreibungslogik ALC. Die Aufgabe der Verifizierung ist es zu überprüfen, ob alle möglichen Systemabläufe die nötigen Formeln befriedigen. Hierbei setzen die Autoren auf den Einsatz von Büchi-Automaten, die dazu benutzt werden um ω-Sprachen (Mengen über unendlichen Wörten) zu definieren. Der in dieser Arbeit vorgestellte Algorithmus hat eine dreifach exponentiale Laufzeit in Abhängigkeit zu der Größe der Formeln φ. Die Autoren meinen jedoch, dass diese häufig ziemlich klein sind, wodurch dies weniger schwer ins Gewicht fällt. 3.3 Zwischenfazit In diesem Kapitel wurden mehrere Ansätze grob skizziert, die zeigen sollen, dass gerade im Bereich der LT L viele unterschiedliche Entwicklungen in Bezug auf Policyüberwachung voran getrieben werden. Dabei stehen die hier angesprochenen Ansätze nur beispielhaft für eine große Menge wissenschaftlicher Literatur, die sich mit 2 3 Java Path Explorer Monitoring and Checking 16 3.3. ZWISCHENFAZIT dem Bereich auseinander setzt. Diese Ansätze werden am Ende dieser Ausarbeitung noch in Verbindung mit dem Reduce-Algorithmus gesetzt. KAPITEL 4. POLICY-SPEZIFIZIERUNG SOWIE -ANALYSE 4 17 Policy-Spezifizierung sowie -Analyse In diesem Kapitel wird sich mit weiteren alternativen Ansätzen zur Policy-Spezifizierung auseinander gesetzt und diese werden mit dem Reduce-Algorithmus beziehungsweise dessen Logik verglichen. Hierfür eigenen sich zum Beispiel der Ansatz von [Bar+07]. Hier wird ein Algorithmus zur Policy-Überprüfung vorgestellt, der als Besonderheit im Vergleich zum Reduce-Algorithmus auch den Verursacher eines Policybruchs ausfindig machen kann. Ein weiteres Augenmerk wird in diesem Kapitel auf die PrivacyLFP aus [DeY+10] gelegt. Die PrivacyLFP ist hierbei die Logik, auf welche der Reduce-Algorithmus basiert und die zu dem Zweck entwickelt wurde die HIPAA1 - und GLBA2 -Policys zu spezifizieren. In [LMS07] gibt es einen weiteren Ansatz zur Formulierung und Spezifizierung von HIPAA-Policys, welcher als Basis die logische Programmiersprache Prolog hat. 4.1 Ansatz mit Identifizierung des Verursachers Der in [Bar+07] vorgestellte Ansatz setzt sich als Ziel neben einer Policy-Verletzung auch den Verursacher eben jener zu erkennen. Grundlage für den Ansatz ist die bereits in 3.1 vorgestellte LTL. Auch dieser Ansatz hat als Ziel mit unvollständigen Informationen umgehen zu können. Der große Unterschied zum Ansatz des Reduce-Algorithmus ist hier die Identifizierung eines schuldigen Agenten, sprich dem Akteur, der eine Policy-Verletzung auslöst. Der Reduce-Algorithmus ist lediglich dazu in der Lage den Grund für die Aussage zu identifizieren, während hier auch auf die Akteure gezielt wird. Um dies zu realisieren, definieren die Autoren den Begriff der starken Konformität. Dabei ist eine Aktion stark konform zu einer Ablauffolge, wenn es eine fortführende Ausführung gibt, die die Policy befriedigt. Wenn Akteure jetzt erkennen können, ob eine Aktion stark konform ist, dann können sie verhindern, dass sie einen Policy-Verletzung begehen. Zusätzlich wird in [Bar+07] die Verantwortlichkeit für eine Policy-Verletzung wie folgt definiert: Ein Akteur ist verantwortlich für eine Policy-Verletzung, wenn er eine Tätigkeit in der Ablauffolge unternommen hat, die eine Policy-Verletzung verursacht hat. Zur Identifizierung eines verantwortlichen Agenten wird ein Kausalitätsgraph erzeugt, über den sich die Verantwortung für eine Verletzung ableiten kann. 1 2 Health Insurance Portability and Accountability Act Gramm-Leach-Bliley Act 18 4.2. PRIVACYLFP 4.2 PrivacyLFP Die P rivacyLF P ist eine Logik von den Machern des Reduce-Algorithmus, die in [DeY+10] vorgestellt wird. Sie ist dafür konstruiuert, die HIPAA- und GLBA-Policys in einer Logik zu formalisiern. Sie ist der Vorgänger für die Logik, welche hinterher für den Reduce-Algorithmus benutzt wird. In [GJD11] betonen die Autoren, dass die PrivacyLFP, durch leicht anzuwendene Änderungen in die Logik des ReduceAlgorithmus übertragbar ist. Wie der Name schon vermuten lässt, ist P rivacyLF P darauf ausgelegt insbesondere Policys bezüglich Privatsphäre und Datenschutz zu formalisieren. So werden in [DeY+10, Abschnitt 2] mehrere wichtig Konzepte bezüglich Datenschutzpolicys dargelegt, die gleichzeitig eine Herausforderung an die Logik stellen. Diese sind unter anderem: • Der Umgang mit positiven und negativen Regeln: Eine positive Regel erlaubt etwas, während eine negative Regel etwas auf eine Bedingung einschränkt • Kombination von Regeln • Ausnahmen von Regeln • Selbstreferenzierung: Es kann passieren, dass eine Regel rekursionsartig auf sich selbst verweist • Daten-Attribute: Wie bereits in Kapitel 2.1.2 erwähnt, kann es eine Hierarchie der Attribute geben • Dynamische Rollen: Eine Regel kann statt auf bestimmte Personen auf eine Rolle definiert sein. • ... Mit der P rivacyLF P sollen diese Probleme gelöst werden. Dabei setzt die P rivacyLF P auf die LF P , welche neben den üblichen logischen Operatoren auch noch Fixpunktoperatoren zur Verfügung stellt. Dabei gibt es sowohl einen geringsten, als auch einen größten Fixpunktoperator. So ist es zum Beispiel möglich mittels dieser Fixpunkte die natürlichen Zahlen zu definieren: X(x) , (x = 0) ∨ (∃y.(x = y + 1) ∧ X(y)) (vgl. [DeY+10, Abschnitt 3]). Die P rivacyLF P vereinigt hierbei die LF P mit der LT L. So ergibt sich eine mächtige Logik, mit der man in der Lage ist die HIPAA- und GLBA-Policys zu formalisieren. 4.3 HIPAA-Formulierung mittels Prolog-Ansatz Zum Abschluss dieser Ausarbeitung wird der Ansatz von [LMS07], welcher eine alternative Möglichkeit aufzeigt die HIPAA-Policys zu formalisieren und maschinell auszuwerten. Hierfür wird ein Ansatz verfolgt, der sich die Fragmente aus Prolog nimmt, wobei der Einsatz von Negationen limitiert ist. KAPITEL 4. POLICY-SPEZIFIZIERUNG SOWIE -ANALYSE 19 In diesem Ansatz wird eine Nachricht nach acht Kategorien eingeordnet: Zu, V on, Ü ber, Art, Zweck, AlsAntwortauf , ZugestimmtV on und Annahmen. Wobei Zu und V on für den Empfänger bzw. den Absender einer Nachricht stehen. Ü ber ist die Person, über die die Nachricht Informationen enthält. Die Art Kategorie sagt, welche Informationen in der Nachricht enthalten sind und Zweck steht für den Grund der Nachrichtenübertragung. AlsAntwortauf soll benutzt werden, wenn die Nachricht eine Antwort auf eine andere Nachricht ist. ZugestimmtV on weißt auf die Person, die der Übertragung zugestimmt und die Annahmen Kategorie steht für Annahmen, die zum Zeitpunkt der Nachricht gelten. Mathematisch kann dies in ein 8-Tupel zusammengefasst werden, was genau diese Informationen enthält. Eine HIPAA-Policy wird dann als Abbildung von der Menge der 8-Tupel auf {T, F } angesehen. Anhand dieser Definitionen können Aktionen dann kategorisiert werden. So kann man zum Beispiel alle Aktionen in eine Kategorie zusammenfassen, die vom gleichen Absender kommen. Durch solche Kategorisierungen ist es dann möglich bestimmten Aktionen in erlaubte oder verbotene Aktionen einzuordnen. Dies geschieht durch den Einsatz von Prolog-Formeln. Mit diesem Ansatz als Grundlage wurde eine Webinterface geschaffen, welches frei zugänglich ist. Dieses ist unter [Gro] zu finden. 20 4.3. HIPAA-FORMULIERUNG MITTELS PROLOG-ANSATZ KAPITEL 5. ZUSAMMENFASSUNG UND FAZIT 5 21 Zusammenfassung und Fazit In dieser Ausarbeitung wurden unterschiedliche Ansätze von Policyüberwachung vorgestellt, von denen sich die meisten in gewissen Zielsetzungen unterscheiden. Das größte Augenmerk wurde hierbei auf den Reduce-Algorithmus gelegt. Das Ziel vom Reduce-Algorithmus ist insbesondere die Überwachung von Logs basierend auf dem HIPAA. Es wurde dargelegt, wie der Reduce-Algorithmus definiert ist und anhand welcher Logik man eine Policy für den Reduce-Algorithmus auswertbar macht. Die Besonderheit bei diesem Ansatz ist das Einbeziehen von unvollständigen Informationen, wie sie in der Realität wirklich auftreten. So ist der Algorithmus in der Lage auch auf diesen zu arbeiten und eine Policy schrittweise zu reduzieren. Außerdem ist der Algorithmus in der Lage auf unendlichen Domänen zu arbeiten. Es wurde skizziert, wie die tatsächliche Implementierung des Algorithmus von statten ging. Im weiteren Verlauf wurden Ansätze vorgestellt, die ein Log oder einen Programmablauf zur Laufzeit überwachen sollen. Diese Ansätze hatten als Gemeinsamkeit, dass sie als Basis die LTL haben. Diese Ansätze unterscheiden sich gerade durch die Laufzeit Komponente durch den Reduce-Algorithmus. Während dieser eine Trennung von Policy und Informationen über Handlungen vorsieht, werten diese Algorithmen beides miteinander gekoppelt aus. Vorgestellt wurden hierbei Ansätze die auf den Logiken M T L, LCV und LT L − ALC basieren. Zum Schluss wurde noch ein weiterer Ansatz vorgestellt, der sich im Unterschied zum Reduce-Algorithmus auch besonders mit der Identifizierung von Verursachern für Policyverletzungen auseinander setzt, sowie Akteure zu warnen, dass sie eine Policyverletzung begehen könnten. Zusätzlich wurden noch zwei Ansätze diskutiert, die sich mit der Formalisierung der HIPAA-Policys beschäftigten. Das eine war die P rivacyLF P , die der Vorgänger für die Logik des Reduce-Algorithmus ist und eine weitere Formalisierung mittels Grundgedanken der Programmiersprache Prolog. Das Thema Policy-Überwachung ist ein ziemlich breites Thema mit einer Fülle von unterschiedlichen Ansätzen, die alle auf unterschiedliche Ziele hinarbeiten. Ein gemeinsamer Nenner der Ansätze ist meistens die Entwicklung einer Logik, die als Grundgerüst zur Formulierung von Policys dient. Der Reduce-Algorithmus zielt hierbei besonders auf die Überwachung der HIPAA-Policys ab. Er wurde für diesen Zweck entwickelt und eignet sich deshalb nicht so gut für die Überwachung von laufenden Programmen. Hierfür müssen andere Ansätze gefunden werden beziehungsweise existieren andere Ansätze. Für die HIPAA-Policys scheint er aber gut zu arbeiten. So können mit der Logik, alle 84 HIPAA-Policys dargestellt werden und durch den Algorithmus performant überwacht werden. 22 LITERATUR 23 Literatur [Bar+07] Adam Barth u. a. Privacy and Utility in Business Processes“. In: Pro” ceedings of the 20th IEEE Computer Security Foundations Symposium. 2007. [BBL09] Franz Baader, Andreas Bauer und Marcel Lippmann. Runtime Veri” fication Using a Temporal Description Logic“. In: Proceedings of the 7th International Conference on Frontiers of Combining Systems. 2009, S. 149–164. [BGL08] Franz Baader, Silvio Ghilardi und Carsten Lutz. LTL over Description ” Logic Axioms“. In: Proceedings of the 21st International Workshop on Description Logics (DL2008). Bd. 353. CEUR-WS. 2008. [Con96] 104th Congress. Public Law 104-191. 1996. url: http://www.gpo.gov/ fdsys/pkg/PLAW-104publ191/html/PLAW-104publ191.htm (besucht am 27. 01. 2014). [Con99] 106th Congress. Public Law 106-102. 1999. url: http://www.gpo.gov/ fdsys/pkg/PLAW-106publ102/html/PLAW-106publ102.htm (besucht am 27. 01. 2014). [DeY+10] Henry DeYoung u. a. Experiences in the Logical Specification of the ” HIPAA and GLBA Privacy Laws“. In: Proceedings of the 9th Annual ACM Workshop on Privacy in the Electronic Society (WPES). 2010. [GJD11] Deepak Garg, Limin Jia und Anupam Datta. Policy Auditing over Incomplete Logs: Theory, Implementation and Applications. Chicago, Illinois. 2011. [Gro] Stanford Privacy Group. HIPAA Compliance Checker. url: http:// crypto.stanford.edu/privacy/HIPAA/ (besucht am 27. 01. 2014). [Kim+04] M. Kim u. a. Java-MaC: a run-time assurance approach for Java pro” grams“. In: Formal Methods in Systems Design 24.2 (2004), S. 129–155. [LMS07] Peifung E. Lam, John C. Mitchell und Sharada Sundaram. A Forma” lization of HIPAA for a Medical Messaging System“. In: Proceedings on the 6th International Conference on Trust (2007), S. 279–294. [Roz10] Kristin Y. Rozier. Linear Temporal Logic Symbolic Model Checking“. ” In: Computer Science Review (2010). [Sok+06] Oleg Sokolsky u. a. Run-Time Checking of Dynamic Properties“. In: ” Electronic Notes in Theoretical Computer Science 144 (2006), S. 91– 108. 24 [TR05] LITERATUR Prasanna Thati und Grigore Rosu. Monitoring Algorithms for Metric ” Temporal Logic Specifications“. In: Electronic Notes in Theoretical Computer Science 113 (2005), S. 145–162.
