Hybrid Planning in Cyber Security Applications Bachelorarbeit an der Universität Ulm

Transkript

1 Universität Ulm Ulm Germany Fakultät für Ingenieurwissenschaften und Informatik Institut für Künstliche Intelligenz Hybrid Planning in Cyber Security Applications Bachelorarbeit an der Universität Ulm Vorgelegt von: Louisa Pragst Gutachter: Prof. Dr. Susanne Biundo-Stephan Betreuer: Felix Richter Dr. Bernd Schattenberg 2013

2 Fassung 29. Oktober 2013 c 2013 Louisa Pragst This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. Satz: PDF-L A TEX 2ε

3 Zusammenfassung Diese Arbeit behandelt die Modellierung wichtiger Aspekte für die Beurteilung der Verwundbarkeit von komplexen Computernetzwerken. Es wird ein hybrider Planungsformalismus eingesetzt, um ein an die von Mark Boddy et al. entwickelte BAMS-Domäne [2][3] angelehntes Domänenmodell zu entwickeln. Dazu wird zunächst der hybride Planungsformalismus erläutert. An die Vorstellung der verwendeten Programme schließt sich eine ausführliche Darstellung des hybriden Domänenmodells, das im Rahmen dieser Arbeit entstanden ist, an. Dabei wird zunächst die BAMS-Domäne eingeführt; es folgt das hybride Modell und die Unterschiede zwischen den Domänen. Im Anschluss werden Modellierungsstrategien, die bei der Erstellung des hybriden Domänenmodells entstanden sind, diskutiert. Das umfasst Vorgehensweisen zur Erstellung von Hierarchien, den Umgang mit Quantoren und bedingten Effekten in hybriden Modellen sowie Taktiken zur Verbesserung der Laufzeit und des Speicherverbrauchs. Darauffolgend werden beispielhafte Planungsprobleme zum vorgestellten hybriden Domänenmodell mit verschiedenen Planungsalgorithmen gelöst und die Ergebnisse evaluiert. Dabei sind einige noch ungelöste Schwierigkeiten aufgefallen, die abschließend diskutiert werden. iii

4

5 Inhaltsverzeichnis 1 Einleitung 1 2 Hybrides Planen POCL- und HTN-Planen Der hybride Planungsformalismus Verwendete Programme PANDA-Editor PANDA Planraumvisualisierer Modellierung BAMS Motivation Vorgehen Umfang Unterschiede zu BAMS Hierarchiebildung Sortenhierarchie Abstrakte Relationen Abstrakte Tasks Disjunktion Rekursion Logisch zusammenhängende Tasks Quantoren und bedingte Effekte Bedingte Effekte Existenzquantor Existenzquantor in der Vorbedingung Existenzquantor in der Nachbedingung Allquantor Umformulierung von Relationen Schrittweise Überprüfung aller Möglichkeiten Abschwächung des Allquantors v

6 Inhaltsverzeichnis 7 Verbesserung von Laufzeit und Speicherverbrauch Sorten Parameterreduktion Zusammenfassen von Tasks Einschränkung der Flexibilität Problemformulierung Beispielhafte Lösung von Problemen Vorgehensweise Planungssysteme Planprobleme Problem Aufbewahrung des Passworts Problem Vernetzung von Rechnern Problem Sicherheitslücken in Programmen Interpretation der Messwerte Schwierigkeiten Gründe für die Größe der Domäne Schwierigkeiten beim Planen Zusammenfassung und Ausblick 57 A Graphische Darstellung des hybriden Domänenmodells 59 vi

7 1 Einleitung Die Sicherheit von IT-Systemen ist von enormer Wichtigkeit und spielt eine immer größere Rolle, je mehr Firmen wichtige Daten digital aufbewahren. Die starke Digitalisierung in unserer Gesellschaft steht in keinem Verhältnis zu dem Aufwand, der zur Sicherung der digitalen Netzwerke aufgebracht wird. Die Größe und Komplexität solcher Netzwerke macht es außerdem sehr schwer für Menschen, mögliche Bedrohungen noch erkennen zu können. Da die Anzahl der Angreifer die der Verteidiger bei weitem übersteigt und die Verteidiger niemals wissen, an welchen Schwachstellen die Angreifer gerade arbeiten, um daraus einen Exploit zu machen, können Verteidiger oft nur postum reagieren und durch Exploits bekannt gewordene Sicherheitslücken schließen. Es besteht hier ein hohes Anwendungspotential für Methoden der Künstlichen Intelligenz, wie z.b. Handlungsplanung und automatisches Schlussfolgern. Netzwerke können automatisch analysiert und mögliche Angriffspläne erstellt werden. Die Relevanz dieses Themas lässt sich an der Vielzahl bereits veröffentlichter Arbeiten diesbezüglich ersehen. In An Algorithm to Find Optimal Attack Paths in Nondeterministic Scenarios [10] wird ein Planmodell vorgestellt, das Angriffspläne unter Berücksichtigung von Unsicherheit über den Erfolg einzelner Planschritte erstellt. Identifying Terrorist Activity with AI Plan Recognition Technology [7] nutzt Planerkennungstechniken um die Priorität und Plausibilität eines Terroralarms zu bewerten. Die Arbeit Trapping Malicious Insiders in the SPDR Web [5] führt ein System ein, das Attacken vorher ahnt oder während ihrer Ausführung bemerkt und entsprechende Gegenmaßnahmen einleitet. Improving Self Defense by Learning from Limited Experience [6] addressiert das Problem immer neuer, unbekannter Angriffe. Es werden verschiedene Ansätze dargestellt, wie aus erfolgten Attacken neue Verteidigungsstrategien abgeleitet werden können. Es gibt auch bereits funktionsfähige Systeme wie ProVerif, das dem Bereich des automatischen Schlussfolgerns zugeordnet wird. ProVerif ist ein kryptographischer Protokollverifizierer, der in Formal Analysis of Authentication in Bluetooth Device Pairing [4] verwendet wurde um den Vorgang der Gerätekoppelung von Bluetooth zu analysieren. Die BAMS 1 -Domäne [2][3], die als Grundlage für das in dieser Arbeit vorgestellte Domänenmodell dient, ist dem Bereich der Handlungsplanung zuzuordnen und spezialisiert sich auf die Aufdeckung von möglichen Angriffen durch malicious insider, also legalen Nutzern eines Systems, die ihre Rechte missbrauchen. Ein Admin erstellt die Planungsprobleme passend zu seinem Netzwerk und analysiert anschließend die von einem Planer gefundene Lösung auf die kritischen Schritte, die den Angriff ermöglicht haben. 1 Behavioral Adversary Modeling System 1

8 1 Einleitung Da der Admin im Allgemeinen keine Erfahrung mit der Modellierung von Planungsproblemen haben wird, sollte dieser Vorgang so einfach wie möglich gehalten werden. Darum ist es interessant, dieses Modell in den hybriden Planungsformalismus zu überführen. Das hybride Planen vereinigt kausales Schließen und die Möglichkeit, durch Hierarchien auf einer abstrakten Ebene zu planen (siehe Abschnitt 2). Es ist damit dem menschlichen Planen ähnlich und sowohl die Problemformulierung als auch die zustande kommenden Pläne können leichter von Nutzern ohne Spezialkenntnisse verstanden werden. Durch die Möglichkeit, auf abstrakter Ebene einen auszuführenden Plan anzugeben, ergeben sich außerdem interessante Erweiterungen zum bloßen Finden eines beliebigen Angriffsplans. Man kann beispielsweise gezielt die Verwundbarkeit eines Netzwerkes gegen einen bestimmten Angriffstyp testen oder das Verhalten von Mitarbeitern in den Angriff miteinbeziehen, um daraus allgemeine Verhaltensregeln abzuleiten. Die Aufgabenstellung dieser Arbeit ist, die Möglichkeiten der BAMS-Domäne auf ein hybrides Modell zu übertragen. Eventuell dabei auftretende Probleme müssen gelöst und dokumentiert werden. Abschnitt 2 erläutert den hybriden Planungsformalismus und legt damit die Grundlage für das weitere Verständnis der Arbeit. Im folgenden Abschnitt werden die Programme, die ich für meine Arbeit am hybriden Domänenmodell verwendet habe, vorgestellt. Dazu gehören der PANDA 1 -Editor, PANDA 2, ein Programm zum Lösen von Planungsproblemen, und der Planraumvisualisierer. Die ursprüngliche BAMS-Domäne sowie das von mir entwickelte hybride Domänenmodell werden in Abschnitt 4 eingeführt. Dabei gehe ich auch auf die Vorgehensweise zur Erstellung meines Domänenmodells und die Unterschiede zwischen beiden Modellen ein. Es folgen die bei der Modellierung gewonnenen Erkenntnisse: Vorgehensweisen zum Erstellen von Hierarchien werden in Abschnitt 5 erläutert; Abschnitt 6 behandelt den Umgang mit Quantoren und bedingten Effekten und Abschnitt 7 stellt Strategien zur Verbesserung von Speicherverbrauch und Laufzeit vor. In Abschnitt 8 stelle ich einige Planungsprobleme zum hybriden Modell vor und evaluiere deren Lösung durch verschiedene Planungsalgorithmen. Der darauffolgende Abschnitt behandelt noch ungelöste Probleme, die im Verlauf der Arbeit mit dem hybriden Domänenmodell aufgefallen sind. Im abschließenden Abschnitt fasse ich die Inhalte dieser Arbeit nochmals zusammen und gebe einen Ausblick auf Fragestellungen, die sich aus dieser Arbeit ergeben. 1 Planning and Acting in a Network Decomposition Architecture 2

9 2 Hybrides Planen Für die Modellierung der Domäne verwende ich den Formalismus des hybriden Planens, wie er in From Abstract Crisis to Concrete Relief [1] von Susanne Biundo und Bernd Schattenberg vorgestellt wird. 2.1 POCL- und HTN-Planen Hybrides Planen vereinigt Eigenschaften von POCL 1 - und HTN 2 -Planen. Zum besseren Verständnis gebe ich daher einen kurzen Überblick über diese beiden Planungsansätze, bevor ich auf das hybride Planen eingehe. Wie in allen Planungsformalismen werden im POCL-Planen Aktionen verwendet. Sie können unter bestimmten Voraussetzungen ausgeführt werden und ändern durch ihre Ausführung festgelegte Eigenschaften der Umgebung, für die ein Plan erstellt wird. Beispielsweise kann die Aktion von einem Raum in den anderen gehen nur ausgeführt werden, wenn die Tür zwischen diesen beiden Räumen nicht verschlossen ist. Wird die Aktion ausgeführt, befindet sich die Person danach nicht mehr im ersten Raum, sondern im Zweiten. Soll ein Plan mit POCL-Planen erstellt werden, müssen alle Eigenschaften, die bereits zu Beginn gelten, sowie alle Eigenschaften, die nach Ausführung des Plans gelten sollen, angegeben werden. Es werden dann Aktionen ausgeführt, die die gewünschten Eigenschaften herbeiführen. Das entscheidende Merkmal des POCL-Planens ist das kausale Schließen. Wenn die Ausführung einer Aktion dafür sorgt, dass die Voraussetzungen einer anderer Aktion erfüllt sind und diese Aktion damit ausgeführt werden kann, besteht ein kausaler Zusammenhang zwischen den Aktionen. Solche Beziehungen zwischen Aktionen werden während des Planungsprozesses festgehalten und können für das weitere Planen ausgenutzt werden. Die charakteristische Eigenschaft des HTN-Planens ist die Bildung von Hierarchien bzw. Abstraktionen. Die Aktionen bei dieser Art des Planens können abstrakt oder primitiv sein. Abstrakt wäre z.b. eine Aktion wie eine verschicken, die nicht direkt ausführbar ist. Sie muss in kleinere Teilschritte, die primitiven Aktionen, zerlegt werden. Eine primitive Aktion kann dagegen direkt ausgeführt werden. Beispiele hierfür sind programm öffnen und Absender festlegen. 1 Partial-Order Causal-Link 2 Hierarchical Task Network 3

10 2 Hybrides Planen Anders als beim POCL-Planen stellt man beim HTN-Planen das Ziel nicht darüber dar, dass bestimmte Eigenschaften gelten sollen. Stattdessen werden abstrakte Aktionen angegeben, die in ausführbare Aktionen zerlegt werden müssen. Ein fertiger Plan besteht nur noch aus primitiven Tasks. 2.2 Der hybride Planungsformalismus Der hybride Planungsformalismus wird erstmals in From Abstract Crisis to Concrete Relief [1] vorgestellt und in Hybrid Planning and Scheduling [11] konkretisiert. Ich gebe hier einen Überblick über die Aspekte, die zum Verständnis meiner Arbeit hilfreich sind. Die Semantik des hybriden Planungsformalismus basiert auf einer many-sorted first-order logic, also einer geordneten, quantorenfreien Prädikatenlogik. Die logische Sprache L, die als Basis verwendet wird, ist gegeben durch: L = (Z,, R r, R f, R a, C, V, γ) Dabei bezeichnet Z eine endliche Menge von Sorten. Beispiele für Sorten aus meiner Domäne sind human, host und . Die Menge ist eine Halbordnung auf Z, die die Subsortenbeziehung bezeichnet. Das bedeutet konkret, dass für alle z i, z j, z k Z folgende drei Bedingungen gelten: (z i, z i ) (Reflexivität) (z i, z j ) (z j, z i ) z i = z j (Antisymmetrie) (z i, z j ) (z j, z k ) (z i, z k ) (Transitivität) R r, R f und R a sind Z -sortierte, endliche Mengen von Relationen. Dabei bezeichnet R r rigide, R f flexible und R a abstrakte Relationen. Diese Mengen sind disjunkt. Die Z - Sortierung bedeutet, dass jede Relation r eine Signatur besitzt, die ein Tupel aus einer beliebigen, endlichen Anzahl von Sorten ist. Relationen beschreiben Eigenschaften von oder Beziehungen zwischen Objekten. Beispiele für Relationen sind at host(host, human) und reachable(host, host). C ist eine Menge von Konstanten und V eine Menge von Variablen. Über die Funktion γ : C V Z ist jedem φ C V ist genau eine Sorte zugeordnet. γ ist surjektiv, aber nicht injektiv. Implizit kann φ durch die über definierte Halbordnung weitere Sorten haben. Sei Γ z die Menge aller Konstanten und Variablen, die die Sorte z Z haben. Dann gilt: (φ Γ zi ) ((z i, z j ) ) (φ Γ zj ) φ C V, z i, z j Z Um eine belegte Relation zu erhalten, wird einer Relation r R r R f R a für jede in der Signatur vorkommenden Sorte z Z eine Konstante bzw. Variable φ Γ(z) zugeordnet. Das wird dargestellt als r(φ 1,..., φ n ), wenn die Signatur von r n Sorten enthält. 4

11 2.2 Der hybride Planungsformalismus Ich verwende auch die kürzere Schreibweise r( φ). Sind alle Variablen aus φ transitiv an Konstanten gebunden, spricht man von einer gegrundeten Relation. Ein Zustand s ist dann eine Menge von gegrundeten Relationen aus R r R f ; man sagt eine gegrundete Relation r( φ) gilt in Zustand s genau dann, wenn r( φ) s. Ein Task t ist gegeben durch das Tupel ( x, prec, post). Dabei steht x = x 1,..., x n für eine Liste von Variablen aus V. prec und post sind Konjunktionen von Literalen, es können negierte und nicht negierte belegte Relationen r( φ) vorkommen. Sie stellen die Vor- bzw. Nachbedingung für t dar. Die Belegung jeder dieser Relationen r darf dabei nur Konstanten aus C oder Variablen aus x enthalten. Man unterscheidet abstrakte und primitive Tasks, für primitive Tasks gilt, dass in prec Relationen aus R r und R f verwendet werden können, für post aber nur flexible Relationen, da nur deren Gültigkeit durch einen Task verändert werden darf. In abstrakten Tasks können prec und post zusätzlich Relationen aus R a enthalten. Ein primitiver Task kann auf einen Zustand s angewendet werden, wenn alle x x transitiv an Konstanten gebunden sind und prec in s gilt. Dann überführt der Task den Zustand s in einen Zustand s ; das bedeutet, die Menge s wird durch das Hinzufügen bzw. Entfernen der gegrundeten Relationen aus post gerade so verändert, dass post gilt. Abstrakte Tasks können nicht direkt ausgeführt werden, sondern müssen in primitive Tasks zerlegt werden. Aufbauend auf diesen Definitionen wird ein Plan P dargestellt als (T, <, V C, CL). T ist eine endliche Menge der in P vorkommenden Planschritte (l, t). Das Label l dient dazu, mehrfach vorkommende Tasks t voneinander unterscheiden zu können. Die Menge < bezeichnet eine Halbordnung auf T, durch die die Ausführungsreihenfolge vorgegeben wird. Sie enthält die sogenannten Ordnungsconstraints. V C ist eine Menge von Gleichungen und bezeichnet die geltenden Variablenconstraints. Die enthaltenden Gleichungen können für v V, t V C von der Form (v = t) oder (v t) sein. CL ist eine Menge von Tupeln (t i, t j, ψ) mit t i, t j T, die kausale Links darstellen. Ein kausaler Link sichert zu, dass das in der Vorbedingung von t j vorkommende Literal ψ durch die Ausführung von t i erzeugt wird. ψ muss also in der Nachbedingung von t i vorkommen, außerdem darf nach der Ausführung von t i kein anderer Task ψ verändern, bis t j ausgeführt wurde. Solche Pläne werden für die Definition von Dekompositionsmethoden für abstrakte Tasks verwendet. Eine solche Methode m ist als Tupel (t, P, V C) definiert. t ist der abstrakte Task, der zerlegt werden soll und P ist der Plan, der t umsetzt. V C sind Variablenconstraints, die dazu verwendet werden, in t vorkommende Variablen mit Variablen aus P zu identifizieren. Jeder abstrakte Task muss mindestens eine Dekompositionsmethode haben. Da ein abstrakter Task durch mehrere Dekompositionsmethoden zerlegt werden kann, ist die Modellierung möglichst genauer Vor- und Nachbedingungen durch Relationen aus R r und R f stark eingeschränkt. Aus diesem Grund können zusätzlich Relationen aus R a verwendet werden, die für verschiedene andere Relationen stehen können. Durch ein Dekompositionsaxiom a wird festgelegt, mit welchen anderen Ausdrücken eine abstrakte Relation gleichgesetzt werden kann. So können die Vor- und Nachbedingungen 5

12 2 Hybrides Planen verschiedener implementierender Pläne exakt dargestellt werden. a ist definiert als (r, β), wobei r die abstrakte Relation ist und β eine Disjunktion von Ausdrücken β i. Jedes β i stellt eine Möglichkeit dar, r zu konkretisieren, und ist eine Konjunktion von negierten oder unnegierten Relationen aus (R f R r R a ) \ {r}. Für eine abstrakte Relation r( φ) und zerlegende Literale τ x y ( φ x y), x 1,..., n, y 1,..., m, wobei jedes τ x y für eine negierte oder unnegierte Relation stehen kann, repräsentiert (r, β) eine Formel der Form: ( φ : r( φ)) ( φ φ 1 m : τ 1 1 ( φ 1 1 )... τ 1 m( φ 1 m))... ( φ n 1... φ n m : τ n 1 ( φ n 1 )... τ n m( φ n m)) Ein Domänenmodell D ist als Tupel (T, M, A) definiert und basiert auf der logischen Sprache L. Dabei steht T für eine endliche Menge von Tasks, M für eine endliche Menge von Dekompositionsmethoden und und A für eine endliche Menge von Dekompositionsaxiomen. Ein Planproblem P wird durch das Tupel (D, P init ) dargestellt. D ist das Domänenmodell, für das das Problem gelöst werden soll und P init bezeichnet das initiale Tasknetzwerk, einen ersten Plan, der das Problem lösen soll. Dieser Plan enthält zwei spezielle Planschritte, t init und t goal. t init ist der erste Planschritt, der zugehörige Task hat keine Vorbedingung und durch die Nachbedingung wird der Startzustand erzeugt. t goal ist der letzte Planschritt, sein Task hat keine Nachbedingung. Wenn eine Vorbedingung angegeben ist, enthält sie Merkmale des Zielzustandes. Zwischen diesen beiden können weitere Planschritte gegeben sein. Ein Plan ist eine Lösung für ein Planproblem P, wenn er fünf Bedingungen erfüllt. Er darf zum einen keine offenen Vorbedingungen enthalten. Das bedeutet, jedes in einer Vorbedingung vorkommende Literal muss durch einen kausalen Link gestützt werden. Es dürfen außerdem keine kausalen Threats in der Lösung vorkommen. Ein kausaler Threat des kausalen Links (t i, t j, ψ) liegt vor, wenn die Halbordnung es erlaubt, dass t k zwischen t i und t j ausgeführt wird und ψ in der Nachbedingung von t k vorkommt. Es ist dann nicht sichergestellt, dass der kausale Link erfüllt wird. Wenn eines dieser Kriterien verletzt ist, kann der Plan Tasks enthalten, deren Vorbedingung nicht erfüllt ist und die daher nicht ausführbar sind. Ein weiteres Lösungskriterium ist, dass der Plan nur primitive Tasks enthält, denn abstrakte Tasks sind nicht direkt ausführbar. Außerdem muss der Plan eine Verfeinerung des initialen Plans P init sein; das bedeutet, er ist durch die Dekomposition abstrakter Tasks und das Einfügen von Tasks, kausalen Links, Ordnungsconstraints sowie Variablenconstraints aus P init entstanden. Wenn dieses Kriterium verletzt ist, löst der Plan nicht das angegebene Problem. Es könnte ein anderer Anfangszustand mit mehr gültigen Relationen verwendet werden; Merkmale des Zielzustandes könnten entfernt oder vorgegebene Teilpläne nicht in den Lösungsplan aufgenommen werden. Das letzte Lösungskriterium legt fest, dass alle Variablen direkt oder durch transitive Beziehungen an Konstanten gebunden sein müssen. Ist das für eine 6

13 2.2 Der hybride Planungsformalismus Variable nicht der Fall, wird nicht festgelegt, welche Konstante verwendet werden soll; der Plan ist damit nicht deterministisch. 7

14

15 3 Verwendete Programme Bei der Erstellung meiner Domäne waren vor allem drei Programme hilfreich. Der PANDA-Editor bietet Unterstützung bei der Erstellung von Domänen und Problemen im Formalismus des hybriden Planens; PANDA 2 kann mithilfe dieser Domänen Lösungen zu eben solchen Problemen finden. Der Planraumvisualisierer stellt den während eines Planungsprozesses explorierten Suchraum graphisch dar. In diesem Abschnitt möchte ich diese Programme kurz vorstellen. 3.1 PANDA-Editor Der PANDA-Editor ist ein graphischer Editor zur Erstellung von hybriden Domänen und Problemen im PANDA-XML-Format. Er wurde an der Universität Ulm vom Institut für Künstliche Intelligenz entwickelt. Um den hybriden Planer PANDA 2 verwenden zu können, müssen sowohl die Domäne als auch das Problem im PANDA-XML-Format vorliegen. Obwohl es grundsätzlich möglich ist, eine solche Datei in jedem beliebigen Editor zu erstellen, wird der Vorgang durch die Verwendung des PANDA-Editors extrem vereinfacht. Der PANDA-Editor bietet eine graphische Oberfläche, mit der Schritt für Schritt Problem bzw. Domäne aufgebaut werden können. Dabei ist es nicht nötig, Kenntnisse über PANDA-XML zu haben. Die XML-Datei wird im Hintergrund automatisch erstellt. Die graphische Oberfläche leitet den Anwender schrittweise durch den Erstellungsprozess und bietet dabei stets nur die Möglichkeiten, die eine korrekte Domäne bzw. ein korrektes Problem zur Folge haben. Abb. 3.1 zeigt beispielhaft die graphische Oberfläche, die verwendet wird, um einen Task zu verändern. Wie man sieht, können nur bereits existierende Relationen als Vorbedingung bestimmt werden, und für diese Relationen können wiederum nur Parameter der richtigen Sorte ausgewählt werden. Durch die begrenzten Möglichkeiten der Interaktion werden von Anfang an Fehler in den erstellten Dokumenten vermieden. Treten dennoch Fehler auf, werden diese vom PANDA-Editor erkannt und angezeigt. Die Wahrscheinlichkeit von schwer zu lokalisierenden Tippfehlern wird ebenfalls drastisch reduziert, da man nur einmal die Namen von Sorten, Relationen, Task, usw. eintippen muss. Bezieht man sich danach auf eines von diesen, wird es aus einer Liste ausgewählt. Man kann also weder bei der Syntax einen Fehler machen, noch versehentlich auf nicht existierende Elemente Bezug nehmen. 9

16 3 Verwendete Programme Abbildung 3.1: Ansicht des PANDA Editors beim Ändern eines Tasks. Die Auswahlmöglichkeiten sind so begrenzt, dass nur Variablen mit der passenden Sorte angegeben werden können. 3.2 PANDA 2 PANDA 2 ist ein Planer, mit dem hybride Planungsprobleme gelöst werden können. Dieses Tool wurde ebenfalls vom Institut für Künstliche Intelligenz der Universität Ulm entwickelt. Es ist eine Weiterentwicklung von PANDA, das auf Hybrid planning and scheduling [11] basiert. Man kann verschiedene Algorithmen als Suchstrategie für PANDA 2 angeben und dazu auch Heuristiken, Tie-Breaker und Flaw-Selection auswählen. Alternativ können auch Planungssysteme, die bereits in der Literatur diskutiert wurden (z.b. RePOP [9] und SHOP2 [8]), verwendet werden. Wird so ein Planungssystem gewählt, werden Algorithmus, Heuristik und alles weitere automatisch dementsprechend festgelegt. Es gibt viele weitere Parameter, die das Suchverhalten modifizieren, alle zu nennen geht an dieser Stelle jedoch zu weit. Jeder Aufruf von PANDA 2 führt zur Anzeige einiger Statistiken. Dazu gehört zum Beispiel die Zeit, die zum Finden einer Lösung gebraucht wird, wie viel Speicher während der Suche verbraucht wird und wie viele Verzweigungen im Durchschnitt vorkommen. Diese Statistiken sind sehr nützlich um das Verhalten verschiedener Suchalgorithmen zu vergleichen. Zusätzlich hat man die Möglichkeit, sich verschiedene Dateien erstellen zu lassen. Ich verwende davon vor allem die Möglichkeit, die kausalen und temporalen Zusammenhänge der gefundenen Lösung als PDF-Datei anzulegen. 10

17 3.3 Planraumvisualisierer Ich verwende dieses Tool, um Fehler in der Domäne und den Problemen zu finden und das Verhalten bei verschiedenen Suchalgorithmen zu untersuchen. Die Ergebnisse dieser Beobachtungen erläutere ich in Kapitel Planraumvisualisierer Am Institut für Künstliche Intelligenz der Universität Ulm wurde ein Planraumvisualisierer entwickelt. Dieses Programm verwendet eine von PANDA 2 erstellte Datei um den explorierten Suchraum als Baum darzustellen. Diese Datei kann von PANDA 2 auch dann erstellt werden, wenn keine Lösung gefunden wurde, z.b. weil ein Zeitlimit überschritten wurde. Jeder Knoten des angezeigten Baumes steht für einen erzeugten Plan, der betrachtet werden kann. Zu jeden erzeugten Plan werden außerdem Informationen über die Modifikationen des initialen Plans, die zu diesem Plan geführt haben, und über die Fehler, die der Plan noch enthält, bereit gestellt. Dieses Tool unterstützt die Fehlersuche in der Domäne und ist außerdem hilfreich, um das Verhalten verschiedener Plansysteme für ein bestimmtes Problem nachzuvollziehen. 11

18

19 4 Modellierung Dieser Abschnitt befasst sich mit dem von mir entwickelten hybriden Modell. Es umfasst 55 Sorten, 131 Relationen, 19 Dekompositionsaxiome, 171 Tasks und 100 Methoden. Die Task teilen sich auf 42 abstrakte Tasks und 129 primitive Tasks auf. Durchschnittlich gehören zu jedem abstrakten Task etwa 2,40 Methoden, die maximale Anzahl an Methoden eines Tasks ist fünf. Die maximale Tiefe der Hierarchie ist vier. Die Hierarchie beinhaltet rekursive Aufrufe, wobei nur einfache und keine verschränkte Rekursion verwendet wird. Eine graphische Darstellung des Modells befindet sich in Anhang A. Bevor ich näher auf mein Modell eingehe, stelle ich die BAMS-Domäne vor. Danach gehe ich auf die Motivation für eine Umsetzung der BAMS-Domäne im hybriden Planungsformalismus ein. Es folgt eine Erläuterung meines Vorgehens bei der Erstellung sowie des Funktionsumfangs meines Modells. Zuletzt stelle ich fest, welche Änderungen, die nicht auf den Planungsformalismus zurückzuführen sind, sich zur BAMS-Domäne ergeben haben. 4.1 BAMS BAMS wurde erstmals 2005 von Mark Boddy et al. in Course of Action Generation for Cyber Security Using Classical Planning [2] vorgestellt. Ziel dieser Arbeit war es, Netzwerk-Administratoren bei der Absicherung ihrer Systeme gegen virtuelle Angriffe von verschiedensten Angreifern zu unterstützen. Dazu wurde ein System implementiert, das mögliche Attacken gegen ein gegebenes Netzwerk finden und diese in für Menschen verständlicher Weise darstellen kann. Mithilfe eines solchen Plans ist der Administrator in der Lage, Schwachstellen im Netzwerk zu identifizieren und geeignete Gegenmaßnahmen zu ergreifen. Sie können aber auch genutzt werden, um die Wirksamkeit einer geplanten Sicherheitsvorkehrung vor deren Umsetzung zu verifizieren. Besonderes Gewicht liegt auf der Möglichkeit, die Gefahr durch sogenannte malicious insider, also Angreifer, die legale Benutzer des Systems sind, einzuschätzen. In The Behavioral Adversary Modeling System - Console Based Generator [3] wird die BAMS-Domäne ausführlich beschrieben. Sie basiert auf einem POCL-artigen Planungsformalismus, so dass alle für ein hybrides Planungsmodell benötigten primitiven Tasks bereits enthalten sind. Es sind nur geringe Änderungen nötig. Das BAMS-Domänenmodell wird zur besseren Übersicht von Mark Boddy et al. in einige logische Einheiten unterteilt: , Verschlüsselung, Keylogging, Malware, DMS, 13

20 4 Modellierung Network, Physikalisch und Prozess. Ich fasse hier den Funktionsumfang der einzelnen Bereiche zusammen und zeige Lücken auf. Der bereich ermöglicht das Versenden von s an einen oder mehrere Empfänger. Dabei können ein falscher Absender angegeben, Informationen oder Instruktionen in die geschrieben, die signiert und Anhänge an die gehängt werden. Beim Versenden der können unter Umständen Sniffer, also Programme, die fremde Netzwerkpakete abfangen können, diese mitlesen. Außerdem ist es natürlich möglich, empfangene s zu lesen und deren Anhänge zu öffnen. Enthält ein Anhang einen Virus, infiziert dieser unter gewissen Voraussetzungen Dateien auf dem Rechner. Während für das Versenden von s eine Verbindung zu einem server bestehen muss, fordert BAMS das für das Abrufen von s nicht. Dadurch kann eine auch nur beim Versenden gesnifft werden, nicht aber beim Abrufen. In der BAMS-Domäne enthält der Verschlüsselungsbereich einen Task, mit dem Dateien verschlüsselt werden können, es fehlt aber ein Task, der Dateien wieder entschlüsselt. Weiterhin werden hier wichtige Relationen zum Umgang mit Signaturen und Zertifikaten definiert. Es ist nicht näher definiert, welche Verschlüsselungsverfahren jeweils verwendet werden. Keylogging ermöglicht es, einen Keylogger an einen Rechner anzuschließen. Dieser wird alle über eine Tastatur eingegebenen Informationen mitlesen und speichern. Ein Insider kann ihn dann wieder an sich nehmen und auslesen. Der Malwarebereich enthält Relationen, die verschiedene Arten von Schadsoftware, aber auch Schutzsoftware beschreiben. Ein Programm kann etwa ein Virus, ein Codeinjektor oder ein Virenscanner sein. Außerdem ermöglichen Tasks das Herunterladen oder Schreiben eines Codeinjektors, sowie das Injizieren von Code mit dessen Hilfe, so dass Dateien von fremden Rechnern angesehen werden können. DMS ist die Abkürzung für Document Management System. Ein solches System ermöglicht das gemeinsame Arbeiten an Dokumenten an verschiedenen Rechnern. Man kann sich mit einem Passwort oder einem Zertifikat in dieses System einloggen, um dann ein Dokument anzufordern und es zu lesen. Es fehlen Tasks, um das Dokument zu bearbeiten und sich wieder auszuloggen. Wenn man sich als Admin einloggt, ist es möglich, Passwörter zu ändern oder einer Gruppe Leserechte einzuräumen. Die Verwaltung dieser Daten erfolgt nicht über das normale DMS-Programm, sondern ist nur mit einem NES- Programm möglich. Auch an dieser Stelle ist es nicht möglich, sich auszuloggen, außerdem erscheint es willkürlich, dass nur Leserechte für Gruppen gesetzt werden können. Der Netzwerkbereich definiert wichtige Relationen zur Darstellung der Verbindungen zwischen Rechnern. Es kann angegeben werden, wie die Rechner untereinander verbunden sind und welche Netzwerkgeräte und Firewalls dazwischen liegen. Weitere Relationen beschreiben, welche Pakettypen eine Firewall weiterleitet. Außerdem werden hier alle wichtigen Relationen und Tasks zur Verwendung von Sniffern definiert. Es ist möglich, einen Sniffer zu starten und von ihm gespeicherte Informationen auszulesen. Der physikalische Bereich ermöglicht es, Schlüssel abzulegen und mitzunehmen, Türen aufzuschließen, zu öffnen und durch sie in einen anderen Raum zu gelangen. Obwohl es möglich ist, eine Tür zu schließen, kann sie nicht wieder abgeschlossen werden. Ein 14

21 4.2 Motivation Mensch kann außerdem an einem Rechner Platz nehmen und wieder davon aufstehen. Außerdem ist hier die wichtige Relation in room definiert, die den momentanen Standort von physikalischen Objekten angibt. Im Prozessbereich sind wichtige Relationen für die Verwaltung von Dateien definiert, wie zum Beispiel die Zugriffsrechte. Die Tasks beinhalten den Loginvorgang an einem Rechner, das Sperren und Entsperren des Bildschirms, das Starten neuer Programme und das Anweisen und Ausführen eines File Updates. File Updates werden dabei nicht definiert; es ist zu vermuten, dass das Updaten von Programmen auf die neueste Programmversion gemeint ist. Auch in diesem Bereich ist es nicht möglich sich auszuloggen. Um das umzusetzen ist es notwendig, Programme beenden zu können. Außerdem wäre es wünschenswert, wenn auch lokal und nicht nur über das DMS Dateien gelesen, bearbeitet und die Zugriffsrechte geändert werden könnten. Ich orientiere mich in meiner Arbeit stark an dem dargestellten Modell, passe es aber an den Formalismus des hybriden Planens an. Das bedeutet insbesondere, dass ich einige der gegebenen Tasks umformuliere, da hybrides Planen nicht alle der von BAMS verwendeten Quantoren auf primitiver Ebene unterstützt und auch keine Disjunktion in Vorund Nachbedingungen primitiver Tasks zulässt. Außerdem erstelle ich eine Hierarchie, die im ursprünglichen Modell noch nicht vorhanden ist. 4.2 Motivation Die Möglichkeit, Probleme auf abstrakter Ebene als initiale Tasknetzwerke anzugeben, bietet für mögliche Anwender, die die Sicherheit ihres Netzwerks überprüfen möchten, einige Vorteile. Zum einen ist es einfacher ein Planungsproblem zu formulieren. Anwender ohne Erfahrung in der Problemformulierung können auf abstrakter Ebene arbeiten ohne sich mit den Details zu beschäftigen. Manche Anwender interessiert evtl. nur ein bestimmter Angriffstyp, weil dieser besonders wahrscheinlich oder gefährlich ist. Dieser Angriffstyp kann dann als abstrakter Task in das initiale Tasknetzwerk eingefügt werden und das Computernetzwerk wird auf diesen Angriffstyp getestet. Dazu muss natürlich der Angriff bekannt sein und verschiedene Vorgehensweisen im Modell dargestellt werden. Eine weitere interessante Möglichkeit ist, den Tagesablauf eines normalen Angestellten im initialen Tasknetzwerk darzustellen und das Vorgehen des Angreifers offen zu lassen. Man kann dann analysieren, ob bestimmte Verhaltensweisen Angriffe gegen ein Netzwerk begünstigen. Ich richte meinen Fokus auf diese Problematik. 4.3 Vorgehen Bei der Erstellung einer Hierarchie hat man die Wahl zwischen Bottom-Up- und Top- Down-Vorgehen. Für die Überführung eines POCL-basierten Domänenmodells in ein 15

22 4 Modellierung hybrides Domänenmodell ist das Bottom-Up-Prinzip die intuitivere Vorgehensweise, da alle benötigten primitiven Tasks und Relationen schon vorhanden sind. Ich entschiede mich daher für ein Bottom-Up-Vorgehen. In einem ersten Schritt übernehme ich die primitiven Tasks des BAMS-Modells. Dabei folge ich den logischen Einheiten, die in sich geschlossen sind, und übernehme diese schrittweise. So kann ich eine Einheit testen, bevor ich eine neue übernehme und es ist einfacher, Fehler zu finden. Damit erhalte ich eine funktionierende POCL-Domäne. Zu diesem Zeitpunkt gibt es noch keine Hierarchie außer der Sortenhierarchie. Danach beginne ich Verbesserungen an dem Modell vorzunehmen. Zum einen bemühe ich mich, die Domäne vollständiger darzustellen. Die ursprüngliche BAMS-Domäne, wie sie in The Behavioral Adversary Modeling System - Console Based Generator [3] dargestellt wird, weist einige Lücken auf, die ich zu schließen versuche. Die Änderungen, die sich dadurch ergeben haben, beschreibe ich in Abschnitt 4.5. Zum anderen bemühe ich mich Laufzeit und Speicherverbrauch gegenüber meinem ersten Entwurf zu verbessern. Die Details dazu erläutere ich in Abschnitt 7. Im letzten Schritt baue ich eine Hierarchie auf. Ich nutze die Ansätze, die ich in Abschnitt 5 erkläre, um alle potenziellen Möglichkeiten, Hierarchien zu bilden, auszunutzen. Dazu führe ich neue, abstrakte Tasks und Relationen ein, sowie die dazu gehörigen Methoden und Dekompositionsaxiome. 4.4 Umfang Mein Modell übernimmt die Bereiche des BAMS-Modells; damit ist es weitestgehend möglich die gleichen Angriffe zu planen. Dieser Abschnitt dient lediglich der Übersicht über die Möglichkeiten des entwickelten Modells; die Begründung für die Änderungen zur BAMS-Domäne folgt in Abschnitt 4.5. Im bereich ist weiterhin das Versenden von s an mindestens einen Empfänger möglich, wobei der Absender gefälscht werden kann. Der Inhalt der kann nur noch eine Information sein, Instruktionen sind nicht mehr möglich. Das Signieren einer ist weiterhin möglich, eine Signatur wird als spezielle, nicht passwortgeschützte Datei aufgefasst. Sie muss auf dem Host, auf dem die geschrieben wird, zugänglich sein, um die damit signieren zu können. Es wird von einem asymmetrischen Verfahren ausgegangen; der private Schlüssel dient zur Signatur. Der öffentliche Schlüssel wird als bekannt vorausgesetzt, da er öffentlich zugänglich ist. Daher sind keine Schritte zur Überprüfung der Signatur vorgesehen. Auch Anhänge sind weiterhin möglich. Sniffing ist nun sowohl bei der Übertragung an den server als auch beim Abrufen der vom server möglich, da für das Abrufen von s in diesem Modell eine Verbindung zum server bestehen muss. Das Lesen von s und das Öffnen von Anhängen bleibt unverändert. Virale Anhänge können Dateien auf dem Host infizieren. Der Verschlüsselungsbereich enthält zusätzlich zur Verschlüsselung von Dateien nun auch 16

23 4.5 Unterschiede zu BAMS Tasks zu deren Entschlüsselung. Dabei wird von einem symmetrischen Verfahren ausgegangen, das bedeutet, dass derselbe Schlüssel sowohl für das Ver- als auch für das Entschlüsseln verwendet wird. Ein Schlüssel bezeichnet auch in diesem Fall eine spezielle Datei. Diese kann, muss aber nicht, passwortgeschützt sein. Der Keyloggingbereich wird ohne Änderungen aus der BAMS-Domäne übernommen und ermöglicht damit das Anschließen eines Keyloggers an einen Rechner sowie das Auslesen von diesem, wenn man ihn wieder an sich genommen hat. Aus dem Malwarebereich wird der Task zum Herunterladen eines Codeinjektors entfernt, da der Nutzen dieses Schrittes sehr begrenzt ist. Alles weitere aus diesem Bereich wird übernommen. Die Möglichkeiten im Bereich von DMS werden erweitert. Der Einloggvorgang ist derselbe geblieben, man kann sich aber auch wieder ausloggen. Außerdem ist es möglich, Dokumente nicht nur abzurufen, sondern auch zu bearbeiten. Der Admin kann außerdem sämtliche Berechtigungen an einen Dokument ändern. Auch für ihn ist das Einloggen unverändert möglich, mit der zusätzlichen Möglichkeit des Ausloggens. Das Ändern von Passwörtern ist nicht mehr möglich. Im Netzwerkbereich werden grundlegende Änderungen an den Relationen vorgenommen, die darstellbaren Optionen bleiben aber die gleichen. Es werden Verbindungen zwischen Rechnern dargestellt, und Firewalls zur Begrenzung der weitergeleiteten Pakettypen. Das Starten eines Sniffers wurde in den Prozessbereich verlegt, da es letztendlich das Starten eines Programms ist. In diesem Bereich verbleibt der Task zum Auslesen eines Sniffers. Zum physikalischen Bereich wird die Möglichkeit, Türen abzuschließen, hinzugefügt. Außerdem führe ich Relationen ein, die die Darstellung von auf Zetteln notierten Passwörtern ermöglichen. Dazu kommt die Möglichkeit, diese Zettel zu lesen und auf diesem Weg ein Passwort zu erfahren. Zusätzlich werden die Möglichkeiten des BAMS-Systems übernommen. Der Prozessbereich hat starke Änderungen erfahren. Zum Einloggen kommt die Möglichkeit, sich von einem Rechner wieder auszuloggen, hinzu. Man kann Programme starten und beenden. Außerdem ist es möglich, Dateien zu lesen und zu bearbeiten. Das bedeutet auch, dass neue Programmdateien geschrieben werden können. Weiterhin kann der Ersteller einer Datei die Zugriffsrechte dieser Datei verwalten. Es ist nicht mehr möglich, Datei-Updates anzuordnen oder auszuführen. 4.5 Unterschiede zu BAMS Neben den Schritten, die ich vornehme, um aus einem POCL-basierten Domänenmodell ein hybrides zu machen, werden weitere Änderungen gegenüber der BAMS-Domäne vorgenommen. Eine Übersicht ist im Folgenden zu finden. 17

24 4 Modellierung Die Sorte instruction Die BAMS-Domäne führt die Sorte instruction ein. Eine instruction kann mündlich oder über eine erteilt werden und ein Mensch wird daraufhin ein Datei-Update durchführen, wenn ihm die instruction legitim erscheint. Problematisch ist dabei, dass ein Datei-Update nicht definiert wird. Es gibt tatsächlich einige Wege, wie Datei-Updates für einen Angriff auf ein System verwendet werden können, daher wäre die vollständige Umsetzung eines solchen Konzeptes sinnvoll. Allerdings hätte die Domäne für eine sinnvolle Verwendung von Datei-Updates in einem Maße erweitert werden müssen, das die Grenzen dieser Arbeit sprengt. Da der einzige Zweck von instructions darin besteht, Datei-Updates anzuweisen, und diese in der Domäne nicht umgesetzt sind, nehme ich instructions und alle damit verbundenen Relationen und Tasks nicht in meine Domäne auf. Die Sorte process Eine weitere Sorte, die ich nicht übernehme, ist der process. Der Suchraum wird extrem vergrößert, wenn Prozesse berücksichtigt werden, da jedes Programm grundsätzlich mit jedem Prozess laufen kann, wenn er noch nicht verwendet wird. Dazu kommt, dass man viele Prozesse braucht, um nicht eventuell aus Mangel an Prozessen eine Lösung nicht zuzulassen. Der Nutzen ist dagegen sehr gering. Es gibt in BAMS keine Möglichkeit, Prozesse für einen Angriff auszunutzen. Der einzige Vorteil ist eine genauere Abbildung der Realität. Daher entscheide ich mich gegen die Verwendung dieser Sorte. Ungenutzte Relationen Einige Relationen sind in BAMS zwar definiert, werden aber von den Tasks nicht verwendet. Dazu gehören zum Beispiel duped und social skill. Solche Relationen übernehme ich nicht in meine Domäne. Sie geben zwar einen guten Ausblick, in welche Richtung die Domäne noch weiter ausgebaut werden kann, haben aber in der aktuellen Version keine Funktion und sind damit überflüssig. Der Passwort ändern Task Der Task, mit dem DMS-Passwörter vom Admin geändert werden können, wird nicht übernommen. Dieser Task sieht vor, dass als Ergebnis nur dem Admin das neue Passwort bekannt ist. Das entspricht nicht der Realität, üblicherweise kann der Admin das Passwort zwar zurücksetzen, sieht dann das neue Passwort aber nicht. Es würde eine versendet werden, die das neue Passwort enthält. Im Modell festzulegen, dass nach der Ausführung des Taks Passwort ändern immer der 18

25 4.5 Unterschiede zu BAMS Task versenden mit den richtigen Parametern folgen muss, ist sehr aufwendig. Daher ersetze ich den fehlerhaften Task nicht durch eine korrekte Variante und verzichte auf diese Funktionalität. Abschließende Tasks In der gesamten BAMS-Domäne fällt auf, dass man oft nicht die Möglichkeit hat, Aktionen rückgängig zu machen. So kann man sich zum Beispiel nicht ausloggen, Türen abschließen oder Programme schließen. Auf den ersten Blick mag das sinnvoll erscheinen. Wenn das Ziel ist, dass ein Insider eine Datei liest und er sich dazu auf einem Host anmeldet und sie öffnet, ist eine Lösung gefunden. Der Task logout wird nicht in den Plan eingefügt, weil er zum Erreichen des Zieles nicht benötigt wird. Man hat den Eindruck, dass dieser und ähnliche Tasks nie verwendet werden würden und nur unnötig den Suchraum vergrößern, wenn das Modell sie bereit stellt. Wenn sich der Angreifer zur Erledigung seiner Aufgabe aber mit zwei verschiedenen Benutzeraccounts am gleichen Rechner anmelden muss, ist schnell klar, dass er sich ausloggen können muss. Daher füge ich diesen und ähnliche Tasks in meine Domäne ein. file Das BAMS-Modell verwendet eine Sorte file für alle möglichen Arten von Dateien. Durch diesen Ansatz wird der Suchraum sehr groß; aus diesem Grund entschließe ich mich, Subsorten für file einzuführen. Ich unterscheide info file und exe; info file dient zur Darstellung von Dateien, die les- und schreibbar sind und irgendeine Art von Information enthalten. Die Sorte exe steht für Dateien, die Programme enthalten und ausführbar sind. exe wird noch weiter unterteilt in executable und program file. Der Unterschied zwischen diesen Dateitypen ist lediglich, dass executable änderbar ist, program file nicht. Das verkleinert den Suchraum und löst die Problematik, die entsteht, wenn Dateien kopiert werden müssen. Das Kopieren aller Inhalte von einer Datei in eine andere wäre sehr aufwendig. Jede möglicherweise auf einer Datei geltende Relation müsste überprüft und für die neue Datei genauso gesetzt werden. Durch die hohe Anzahl von möglichen Relationen (z.b. Rechte an einer Datei, die für alle ids gelten könnte) wäre eine hohe Anzahl von zusätzlichen Planschritten nötig. Wenn man aber dieselbe Datei auf verschiedenen Rechnern verwendet, wirken sich auch Änderungen an dieser Datei auf allen diesen Rechnern aus. Dieses Problem tritt speziell bei anhängen auf. Das Einführen von executable und program file ermöglicht es dem Problemsteller, zu entscheiden, wann es wichtig ist, eine Programmdatei ändern zu können, und wann es zugunsten der Laufzeit vernachlässigt werden kann. 19

26 4 Modellierung Zusätzlich zu dieser Sortenhierarchie werden auch Tasks neu eingeführt. Bis auf einen einzigen, sehr spezialisierten Task, gibt es in der BAMS-Domäne keine Rechteverwaltung. Diese wird ergänzt, so dass Rechte sowohl erteilt als auch entzogen werden können. Außerdem kommen Tasks hinzu, die die Bearbeitung einer Datei ermöglichen. Man kann Dateien nun nicht nur lesen, sondern auch Informationen oder Programme in Dateien schreiben oder aus ihnen entfernen. program Zur Verkleinerung des Suchraums werden Subsorten für program eingeführt. Unterschieden wird zwischen malware, nochmals unterteilt in transmitter, receiver, injector und sniffer, und norm prog, unterteilt in prog, server, scanner, dms prog, dms server, nes prog und editor. Die entsprechenden Relationen, wie zum Beispiel can transmit documents, werden durch die Subsorten ersetzt. Insider-Einschränkung Einige Tasks der BAMS-Domäne sind nur für Insider ausführbar, obwohl das nicht sinnvoll ist. So können nur Insider s mit Anhängen verschicken. Vermutlich dient dies der Verkleinerung des Suchraumes. Ich entferne ersetze die Sorte insider durch human bei Tasks, die legitime Arbeitsschritte für jeden Angestellten darstellen. Im Verlauf des Tages müssen normale Angestellte solche Arbeitsschritte ausführen. Daher kann nur, wenn die Ausführung solcher Arbeitsschritte auch für normale Angestellte möglich ist, der Tagesablauf eines Angestellten in einem initialen Tasknetzwerk abgebildet werden. Verbindungen zwischen Hosts Die Verbindung zwischen zwei Hosts wird nur noch auf einer sehr abstrakten Ebene dargestellt. Wenn irgendeine Verbindung zwischen zwei Hosts besteht, gilt die Relation reachable(host, host, firewall); die Firewall stellt dabei keine reale Firewall dar, sondern regelt abhängig vom Pakettyp, welche Pakete zwischen den Hosts ausgetauscht werden können. Eine Firewall kann für alle Verbindungen verwendet werden, unabhängig davon, ob in der Realität verschiedene Firewalls zum Einsatz kommen. Die Sorte nd, kurz für Network-Device, wird für einem abstrakten Ansatz nicht mehr benötigt. Dadurch sind keine Angriffe auf die Routingtabellen mehr möglich, diese waren aber in BAMS auch nicht vorgesehen. BAMS verwendet einen realistischeren Ansatz. Es werden alle tatsächlichen Verbindungen zwischen Hosts und Network-Devices mit einer Relation dargestellt und Firewalls stellen reale, an ein bestimmtes Device gebundene Firewalls dar. Sniffing ist immer dann 20

27 4.5 Unterschiede zu BAMS möglich, wenn ein Sniffer auf einem Host läuft, der direkt am gleichen Network-Device angeschlossen ist wie der sendende Host. Das entspricht allerdings nicht der Realität. Sniffing kann immer dann stattfinden, wenn ein Sniffer auf einem Host läuft, der mit einem auf dem Pfad von Absender zu Empfänger liegenden Network-Device verbunden ist. Diese Verbindung muss nicht einmal direkt sein, sondern kann über mehrere andere Network-Devices gehen. Eine Ausnahme bilden Router als Network-Devices, diese können Pakete gezielt weiterleiten und reduzieren damit das Sniffing-Risiko. BAMS hat allerdings nur Hubs und Switches, aber keine Router, vorgesehen. Um nun mit diesem realistischen Ansatz Sniffing darstellen zu können, müsste dafür jedes Mal der kürzeste Pfad von Absender zu Empfänger gefunden werden, auf dem alle laufenden Firewalls den Pakettyp auch weiterleiten. Danach muss außerdem für alle Network-Devices auf dem Pfad überprüft werden, ob mit ihnen irgendwie ein Host mit laufendem Sniffer verbunden ist und ebenfalls alle Firewalls auf diesem Pfad den Pakettyp weiterleiten. Es würden sich unverhältnismäßig viele zusätzliche Planschritte ergeben, um herauszufinden, ob Sniffing möglich ist. Daher habe ich einen abstrakten Ansatz gewählt. Es liegt beim Problemsteller oder einem anderen Programm, zu beurteilen, ob Sniffing möglich ist. Im Problem muss direkt angegeben werden, welche Host miteinander verbunden sind, in welchen Konstellationen Sniffing möglich ist und für welche Pakettypen das jeweils gilt. Man braucht dann nur noch eine Relation zu überprüfen. 21

28

29 5 Hierarchiebildung Eine charakteristische Eigenschaft des hybriden Planens sind die darin enthaltenden Hierarchien. Bei der Verwendung einer Bottom-Up-Vorgehensweise muss man entscheiden, wie man Sorten, Relationen und Tasks zusammenfassen kann, um eine Hierarchie aufbauen. Ich beschreibe an dieser Stelle, in welchen Fällen es sinnvoll sein kann, Hierarchien zu verwenden, und welche Schritte notwendig sind, um die verschiedenen Arten von Hierarchien umzusetzen. 5.1 Sortenhierarchie Die Sortenhierarchie ist nicht nur für die logische Zusammengehörigkeit nützlich, sie erlaubt es auch den Suchraum zu verkleinern, da manche Relationen und Tasks für Subsorten definiert werden können. Ein einfaches Beispiel ist der Task send . Damit der Task ausgeführt werden kann, muss ein Programm ausgeführt werden, das für den E- Mailtransfer geeignet ist. Wählt man dafür die Sorte program, kommen alle Programme, die im Problem definiert sind, in Frage. Das werden in den meisten Anwendungsfällen etwa 10 Programme sein, da es dann für jede Programmfunktionalität ein Programm gibt. Wählt man aber server, gibt es nur noch ein geeignetes Programm. Statt also die Ausführung von 10 Programmen zu überprüfen, muss nur noch dieses eine Programm betrachtet werden. Gleichzeitig können Relationen und Tasks allgemeiner formuliert werden, man muss dadurch nicht ähnliche Tasks mehrfach erstellen. Zum Beispiel führe ich die Sorte sniffable ein, die und info zusammenfasst. Für einen Sniffer gibt es zwischen diesen Sorten keinen Unterschied, er kann beide sniffen. Man kann also für alle Relationen und Tasks, die oder info als Ziel für einen Sniffer vorsehen, die Sorte sniffable verwenden und halbiert damit die Anzahl der dafür benötigten Relationen und Tasks. Wird diese Art der Hierarchie von Anfang an umgesetzt, sind keine besonderen Schritte zur Umsetzung nötig. Wird sie erst später im Modellierungsprozess eingeführt, müssen alle Relationen und Tasks, die eine der Sub- oder Supersorten verwenden, überprüft und gegebenenfalls geändert werden. Wird eine neue Supersorte eingeführt müssen mit hoher Wahrscheinlichkeit Relationen und Tasks gelöscht werden. 23